Koji 1.7.0 release
by Mike McLean
I've just tagged and posted the 1.7.0 release of Koji. The most
significant change is the move from mod_python to mod_wsgi, but there
are a number of other changes also (it's been a while since 1.6.0).
I've written a document for migrating from 1.6.0 to 1.7.0. Look under:
docs/Migrating_to_1.7.txt
Here is the changelog entry:
* Thu May 31 2012 Mike McLean <mikem at redhat.com> - 1.7.0-1
- mod_wsgi support
- mod_python support deprecated
- kojiweb configuration file (web.conf)
- split storage support (build volumes)
- configurable resource limits (hub, web, and kojid)
- drop pkgurl in favor of topurl
- better approach to web themes
- more helpful policy errors
- clearer errors when rpc args do not match function signature
- avoid retry errors on some common builder calls
- don't rely on pgdb._quoteparams
- avoid hosts taking special arch tasks they cannot handle
- kojid: configure yum proxy
- kojid: configure failed buildroot lifetime
- kojid: literal_task_arches option
- support for arm hardware floating point arches
- maven build options: goals, envs, extra packages
- store Maven build output under the standard build directory
- make the list of files ignored in the local Maven repo configurable
- add Maven information to taginfo
- make kojira more efficient using multicalls and caching
- speed up kojira startup
- kojira: configurable sleep time
- kojira: count untracked newRepo tasks towards limits
- kojira: limit non-waiting newRepo tasks
- gssapi support in the messagebus plugin
- grant-permission --new
- improved argument display for list-api command
- moshimoshi
- download task output directly from KojiFilesURL, rather than going
through getfile
- option to show buildroot data in rpminfo command
- show search help on blank search command
- wait-repo: wait for the build(s) to be the latest rather than just present
11 years, 10 months
how to speed up mock
by Farkas Levente
hi,
i've to ask it again what i already asked a few times. is there any way
to speed up mock build?
here is a simple example when i build gstreamer-plugins-bad-free on
rhel-6.2:
-----------------------
2012-05-30 00:45:24,367 - Mock Version: 1.1.22
2012-05-30 00:45:24,377 - State Changed: unpacking root cache
2012-05-30 00:45:27,610 - State Changed: cleaning yum metadata
2012-05-30 00:45:27,639 - State Changed: running yum
2012-05-30 00:45:30,914 - State Changed: unlock buildroot
2012-05-30 00:45:31,026 - State Changed: setup
2012-05-30 00:50:09,980 - State Changed: build
2012-05-30 00:52:34,094 - State Changed: end
-----------------------
as you can see it takes about 5 minutes to setup the buildroot
environment, while it takes 2.5 minutes to build it. so it's still 2
times more the extra stuff compared to the build. even in a case of a
'long' build package (some other package build less then a minutes).
disk space and cache size is not a problem.
any kind of tipp would be welcome.
thanks in advance.
regards.
--
Levente "Si vis pacem para bellum!"
11 years, 11 months
Manually running mock
by Moray Henderson
3 weeks ago, before I went on holiday, I could debug build problems by
logging into my koji build server and get into the mock chroot with
something like
su - kojibuilder -c "mock -v -r koji/slsbox-1.1-build-186-252 --shell"
Now when I try it, it fails with
Traceback (most recent call last):
File "/usr/sbin/mock", line 881, in <module>
main(retParams)
File "/usr/sbin/mock", line 759, in main
sys.exit(chroot.shell(options, cmd))
File "/usr/lib/python2.6/site-packages/mockbuild/backend.py", line 682,
in shell
cmd=cmd)
File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 402, in
doshell
return subprocess.call(cmdstr, preexec_fn=preexec, env=environ,
shell=True)
File "/usr/lib64/python2.6/subprocess.py", line 478, in call
p = Popen(*popenargs, **kwargs)
File "/usr/lib64/python2.6/subprocess.py", line 639, in __init__
errread, errwrite)
File "/usr/lib64/python2.6/subprocess.py", line 1228, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
I've done a mock clean and mock init, and the same thing happens. Anyone
seen anything like that before?
Moray.
"To err is human; to purr, feline."
11 years, 12 months
[PATCH] add a switch for creating the repo without repoview data
by Dan Horák
---
src/bin/pungi.py | 4 +++-
src/pypungi/__init__.py | 2 +-
src/pypungi/config.py | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/bin/pungi.py b/src/bin/pungi.py
index a80e29d..0f69a0f 100755
--- a/src/bin/pungi.py
+++ b/src/bin/pungi.py
@@ -214,8 +214,10 @@ if __name__ == '__main__':
help='Create the source isos (other arch runs must be done)')
parser.add_option("--force", default=False, action="store_true",
help='Force reuse of an existing destination directory (will overwrite files)')
- parser.add_option("--isfinal", default=False, action="store_true",
+ parser.add_option("--isfinal", default=False, action="store_true",
help='Specify this is a GA tree, which causes betanag to be turned off during install')
+ parser.add_option("--norepoview", default=False, action="store_true",
+ help='disable creating of repoview pages')
parser.add_option("--nohash", default=False, action="store_true",
help='disable hashing the Packages trees')
parser.add_option("--full-archlist", action="store_true",
diff --git a/src/pypungi/__init__.py b/src/pypungi/__init__.py
index 059b748..191827d 100644
--- a/src/pypungi/__init__.py
+++ b/src/pypungi/__init__.py
@@ -868,7 +868,7 @@ class Pungi(pypungi.PungiBase):
cachedir = self.config.get('pungi', 'cachedir')
# setup the createrepo call
- self._makeMetadata(self.topdir, cachedir, compsfile, repoview=True, repoviewtitle=repoviewtitle)
+ self._makeMetadata(self.topdir, cachedir, compsfile, repoview=not self.config.get('pungi', 'norepoview'), repoviewtitle=repoviewtitle)
# create repodata for debuginfo
if self.config.getboolean('pungi', 'debuginfo'):
diff --git a/src/pypungi/config.py b/src/pypungi/config.py
index acc9d7a..6cd3a9d 100644
--- a/src/pypungi/config.py
+++ b/src/pypungi/config.py
@@ -45,5 +45,6 @@ class Config(SafeConfigParser):
self.set('pungi', 'alldeps', "True")
self.set('pungi', 'isfinal', "False")
self.set('pungi', 'nohash', "False")
+ self.set('pungi', 'norepoview', "False")
self.set('pungi', 'full_archlist', "False")
--
1.7.7.6
12 years
[PATCH] add gitbuildurl function
by Dan Horák
gitbuildurl returns the SCM URL used to build a specified N-V-R, it's useful
for secondary arches where they can send the URL retrieved from primary koji
to secondary koji with something like
s390-koji build f18 $(koji gitbuildurl foo-1-1.fc18)
---
src/pyrpkg/__init__.py | 11 ++++++++---
src/pyrpkg/cli.py | 18 ++++++++++++++++++
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/pyrpkg/__init__.py b/src/pyrpkg/__init__.py
index bd0e70a..f21a8e8 100644
--- a/src/pyrpkg/__init__.py
+++ b/src/pyrpkg/__init__.py
@@ -1098,8 +1098,8 @@ class Commands(object):
(branch, module))
return output.split()[0]
- def gitbuildhash(self, build):
- """Determine the git hash used to produce a particular N-V-R"""
+ def gitbuildurl(self, build):
+ """Determine the SCM URL used to produce a particular N-V-R"""
# Get the build data from the nvr
self.log.debug('Getting task data from the build system')
@@ -1111,9 +1111,14 @@ class Commands(object):
taskinfo = self.anon_kojisession.getTaskRequest(bdata['task_id'])
# taskinfo is a list of items, first item is the task url.
# second is the build target.
+ return taskinfo[0]
+
+ def gitbuildhash(self, build):
+ """Determine the git hash used to produce a particular N-V-R"""
+
# See if the build target starts with cvs or git
hash = None
- buildsource = taskinfo[0]
+ buildsource = self.gitbuildurl(build)
if buildsource.startswith('cvs://'):
# snag everyting after the last # mark
cvstag = buildsource.rsplit('#')[-1]
diff --git a/src/pyrpkg/cli.py b/src/pyrpkg/cli.py
index 54cad63..572d566 100755
--- a/src/pyrpkg/cli.py
+++ b/src/pyrpkg/cli.py
@@ -156,6 +156,7 @@ class cliClient(object):
self.register_diff()
self.register_gimmespec()
self.register_gitbuildhash()
+ self.register_gitbuildurl()
self.register_giturl()
self.register_import_srpm()
self.register_install()
@@ -461,6 +462,20 @@ defined, packages will be built sequentially.""" %
build to query.')
gitbuildhash_parser.set_defaults(command = self.gitbuildhash)
+ def register_gitbuildurl(self):
+ """Register the gitbuildurl target"""
+
+ gitbuildurl_parser = self.subparsers.add_parser('gitbuildurl',
+ help = 'Print the SCM URL used '
+ 'to build the provided n-v-r',
+ description = 'This will show you \
+ the URL string used to \
+ build the provided build n-v-r')
+ gitbuildurl_parser.add_argument('build',
+ help='name-version-release of the \
+ build to query.')
+ gitbuildurl_parser.set_defaults(command = self.gitbuildurl)
+
def register_giturl(self):
"""Register the giturl target"""
@@ -1001,6 +1016,9 @@ defined, packages will be built sequentially.""" %
def gitbuildhash(self):
print(self.cmd.gitbuildhash(self.args.build))
+ def gitbuildurl(self):
+ print(self.cmd.gitbuildurl(self.args.build))
+
def giturl(self):
print(self.cmd.giturl())
--
1.7.7.6
12 years
mockchain branch in mock
by Seth Vidal
I added a mockchain to mock's git repo today which includes
modifications to include mockchain in mock - include specfile, makefile
and man pages.
Clark, let me know if there is anything else you need to merge this in.
Thanks,
-sv
12 years
pungi --discs option
by Amit Saha
Hello:
I just signed up for this list.
The pungi manual page seemes to suggest a --discs option, whereas if
specified, as a command line argument, says: "pungi: error: no such
option: --discs".
Perhaps the manual page is dated?
Best,
Amit
--
http://echorand.me
12 years
Unable to finish the creation of source ISO on f17
by William F. Acker WB2FLW +1 303 722 7209
Hi all,
When I try to do a Pungi run, my first for f17, I get this.
Traceback (most recent call last):
File "/bin/pungi", line 256, in <module>
main()
File "/bin/pungi", line 160, in main
mypungi.doCreateIsos()
File "/usr/lib/python2.7/site-packages/pypungi/__init__.py", line 1148, in doCreateIsos
pypungi.util._doRunCommand(isohybrid, self.logger)
File "/usr/lib/python2.7/site-packages/pypungi/util.py", line 36, in _doRunCommand
raise OSError, "Got an error from %s: %s" % (command[0], err)
OSError: Got an error from /usr/bin/isohybrid: isohybrid: /home/wacker/bm/17/source/iso/Fedora-17-source-DVD.iso: could not find boot record
My command line is:
sudo pungi -c /home/wacker/.pungi/fedora-install-fedora.ks --ver=17 --sourceisos
I actually do get the ISO, but, of course, the checksum file isn't
created.
I also should mention that I get a lot of unresolvable dependencies
errors, some would go away if I stopped excluding javadoc.
Any ideas?
Tia.
--
Bill in Denver
12 years
koji wsgi support
by Mike McLean
I just pushed a large commit adding wsgi support to koji-hub and
koji-web. This feature had been on the back burner for a while, but the
recent retirement of mod_python in Fedora has forced the issue.
Here's the summary I wrote for the (squashed) commit:
Support wsgi in koji-hub and koji-web
- mod_python still supported, but deprecated
- mod_wsgi is the default
- koji-web now configured via web.conf
- new wsgi-friendly publisher for koji-web
- koji-web now has logging
This is a fairly large change. I've gone out of my way to maintain
compatibility with mod_python, but migration issues are still possible.
Ideally, though, folks will move to mod_wsgi. This will mainly be a
matter of adjusting httpd.conf files and moving koji-web config from
http conf to the new web.conf file. I'll write a longer doc on this
later, but for now:
- see the comments in the example http.conf files for hub and web
- see the example web.conf
- generally the web.conf options have the same name as the old koji-web
PythonOptions
I'm not quite ready to cut a release with this yet, but soon. There
needs to be more testing.
If you opt to try out the new code, please report bugs in our trac:
https://fedorahosted.org/koji/report
12 years
