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, 2 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, 3 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, 3 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
11 years, 4 months
[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
11 years, 4 months
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
11 years, 4 months
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
11 years, 4 months
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
11 years, 4 months
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
11 years, 4 months