From jkeating at redhat.com Sun Feb 1 18:11:17 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 01 Feb 2009 10:11:17 -0800 Subject: change in --copyin? In-Reply-To: <20090201101710.282b8511@torg> References: <20090201101710.282b8511@torg> Message-ID: <1233511877.7493.7.camel@localhost.localdomain> On Sun, 2009-02-01 at 10:17 -0600, Clark Williams wrote: > > Jesse is having an issue with --copyin; he's getting a permission > denied when trying to copy the system /etc/hosts to the > chroot /etc/hosts. This is due to the uidManager.dropPrivsForever() > near the top of the --copyin logic block. My question is, do we need to > drop privs there? Seems kinda crippling to --copyin if you can only > copy stuff to /tmp or the homedir in the chroot. > > Or is allowing modification of the chroot environment a security issue > we're not willing to live with? Can we check to see if mock has been > kicked off as root (or does the pam helper logic neuter that)? Hrm, this is kind of scary, mock is trying to prevent this action? The weird thing is that an error is reported that the action was not allowed, yet the end result is that the file is indeed copied. So if we're trying to prevent it, we're not doing a good job. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Michael_E_Brown at dell.com Mon Feb 2 04:34:13 2009 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Sun, 1 Feb 2009 22:34:13 -0600 Subject: change in --copyin? In-Reply-To: <20090201220409.19edba45@torg> References: <20090201101710.282b8511@torg> <1233511877.7493.7.camel@localhost.localdomain> <20090201220409.19edba45@torg> Message-ID: <20090202043412.GA25417@sc1430.michaels-house.net> On Sun, Feb 01, 2009 at 10:04:09PM -0600, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hrm, this is kind of scary, mock is trying to prevent this action? The > > weird thing is that an error is reported that the action was not > > allowed, yet the end result is that the file is indeed copied. So if > > we're trying to prevent it, we're not doing a good job. > > > > I tried it on my laptop and the copy didn't happen. Not sure what's > going on there. > > I went back and looked at the commit where I added the copyin/copyout > options and the uidManager.dropPrivsForever() has always been there. > I'm considering dropping it for --copyin (where we modify the chroot) > but not for --copyout (where we modify the actual filesystem). > > What do you guys think? Well, until we come up with a "real" security policy for mock, the above suggestion sounds reasonable. -- Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jkeating at redhat.com Mon Feb 2 22:19:30 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Feb 2009 14:19:30 -0800 Subject: [Fwd: [PATCH] Use hashlib if available instead of md5] Message-ID: <1233613170.7493.53.camel@localhost.localdomain> -------- Forwarded Message -------- From: Tom "spot" Callaway To: Jesse Keating Subject: [PATCH] Use hashlib if available instead of md5 Date: Mon, 02 Feb 2009 17:18:32 -0500 This patch converts all calls of md5 function to use hashlib if present. The old md5 function is deprecated in Python 2.6, and this silences the warning messages (along with providing a slight performance improvement). Please apply to rawhide. :) ~spot plain text document attachment (koji-use-hashlib-if-available.patch) From 4c76e7ee1f56057d77b0e7e9f0422e7eabedbf10 Mon Sep 17 00:00:00 2001 From: Tom "spot" Callaway Date: Mon, 2 Feb 2009 17:15:31 -0500 Subject: [PATCH] Convert all calls of md5 function to use hashlib if present (Python 2.6 change). --- builder/kojid | 8 ++++++-- cli/koji | 8 ++++++-- hub/kojihub.py | 25 ++++++++++++++++++++----- koji/__init__.py | 8 ++++++-- www/kojiweb/index.py | 9 +++++++-- 5 files changed, 45 insertions(+), 13 deletions(-) diff --git a/builder/kojid b/builder/kojid index b7900db..fe72fdc 100755 --- a/builder/kojid +++ b/builder/kojid @@ -33,7 +33,6 @@ import errno import glob import logging import logging.handlers -import md5 import os import pprint import pwd @@ -242,7 +241,12 @@ def incrementalUpload(fname, fd, path, retries=5, logger=None): break data = base64.encodestring(contents) - digest = md5.new(contents).hexdigest() + try: + import hashlib + digest = hashlib.md5(contents).hexdigest() + except ImportError: + import md5 + digest = md5.new(contents).hexdigest() del contents tries = 0 diff --git a/cli/koji b/cli/koji index 0ec732f..40974c7 100755 --- a/cli/koji +++ b/cli/koji @@ -31,7 +31,6 @@ import base64 import koji import koji.util import fnmatch -import md5 import os import re import pprint @@ -1173,7 +1172,12 @@ def handle_import_sig(options, session, args): previous = session.queryRPMSigs(rpm_id=rinfo['id'], sigkey=sigkey) assert len(previous) <= 1 if previous: - sighash = md5.new(sighdr).hexdigest() + try: + import hashlib + sighash = hashlib.md5(sighdr).hexdigest() + except ImportError: + import md5 + sighash = md5.new(sighdr).hexdigest() if previous[0]['sighash'] == sighash: print _("Signature already imported: %s") % path continue diff --git a/hub/kojihub.py b/hub/kojihub.py index 8a24bec..0965243 100644 --- a/hub/kojihub.py +++ b/hub/kojihub.py @@ -32,7 +32,6 @@ import logging import logging.handlers import fcntl import fnmatch -import md5 import os import pgdb import random @@ -3535,7 +3534,12 @@ def add_rpm_sig(an_rpm, sighdr): #we use the sigkey='' to represent unsigned in the db (so that uniqueness works) else: sigkey = koji.hex_string(sigkey[13:17]) - sighash = md5.new(sighdr).hexdigest() + try: + import hashlib + sighash = hashlib.md5(sighdr).hexdigest() + except ImportError: + import md5 + sighash = md5.new(sighdr).hexdigest() rpm_id = rinfo['id'] # - db entry q = """SELECT sighash FROM rpmsigs WHERE rpm_id=%(rpm_id)i AND sigkey=%(sigkey)s""" @@ -4771,8 +4775,14 @@ class RootExports(object): if size is not None: if size != len(contents): return False if md5sum is not None: - if md5sum != md5.new(contents).hexdigest(): - return False + try: + import hashlib + if md5sum != hashlib.md5(contents).hexdigest(): + return False + except ImportError: + import md5 + if md5sum != md5.new(contents).hexdigest(): + return False uploadpath = koji.pathinfo.work() #XXX - have an incoming dir and move after upload complete # SECURITY - ensure path remains under uploadpath @@ -4831,7 +4841,12 @@ class RootExports(object): fcntl.lockf(fd, fcntl.LOCK_UN) if md5sum is not None: #check final md5sum - sum = md5.new() + try: + import hashlib + sum = hashlib.md5() + except ImportError: + import md5 + sum = md5.new() fcntl.lockf(fd, fcntl.LOCK_SH|fcntl.LOCK_NB) try: # log_error("checking md5sum") diff --git a/koji/__init__.py b/koji/__init__.py index 6e04cb3..89e9783 100644 --- a/koji/__init__.py +++ b/koji/__init__.py @@ -31,7 +31,6 @@ import datetime from fnmatch import fnmatch import logging import logging.handlers -import md5 import os import os.path import pwd @@ -1467,7 +1466,12 @@ class ClientSession(object): fo = file(localfile, "r") #specify bufsize? totalsize = os.path.getsize(localfile) ofs = 0 - md5sum = md5.new() + try: + import hashlib + md5sum = hashlib.md5() + except ImportError: + import md5 + md5sum = md5.new() debug = self.opts.get('debug',False) if callback: callback(0, totalsize, 0, 0, 0) diff --git a/www/kojiweb/index.py b/www/kojiweb/index.py index 1995a19..2eb236e 100644 --- a/www/kojiweb/index.py +++ b/www/kojiweb/index.py @@ -8,7 +8,6 @@ import Cheetah.Filters import Cheetah.Template import datetime import time -import md5 import koji import kojiweb.util @@ -62,7 +61,13 @@ def _genToken(req, tstamp=None): return '' if tstamp == None: tstamp = _truncTime() - return md5.new(user + str(tstamp) + req.get_options()['Secret']).hexdigest()[-8:] + try: + import hashlib + tokensum = hashlib.md5(user + str(tstamp) + req.get_options()['Secret']).hexdigest()[-8:] + except ImportError: + import md5 + tokensum = md5.new(user + str(tstamp) + req.get_options()['Secret']).hexdigest()[-8:] + return tokensum def _getValidTokens(req): tokens = [] -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- From 4c76e7ee1f56057d77b0e7e9f0422e7eabedbf10 Mon Sep 17 00:00:00 2001 From: Tom "spot" Callaway Date: Mon, 2 Feb 2009 17:15:31 -0500 Subject: [PATCH] Convert all calls of md5 function to use hashlib if present (Python 2.6 change). --- builder/kojid | 8 ++++++-- cli/koji | 8 ++++++-- hub/kojihub.py | 25 ++++++++++++++++++++----- koji/__init__.py | 8 ++++++-- www/kojiweb/index.py | 9 +++++++-- 5 files changed, 45 insertions(+), 13 deletions(-) diff --git a/builder/kojid b/builder/kojid index b7900db..fe72fdc 100755 --- a/builder/kojid +++ b/builder/kojid @@ -33,7 +33,6 @@ import errno import glob import logging import logging.handlers -import md5 import os import pprint import pwd @@ -242,7 +241,12 @@ def incrementalUpload(fname, fd, path, retries=5, logger=None): break data = base64.encodestring(contents) - digest = md5.new(contents).hexdigest() + try: + import hashlib + digest = hashlib.md5(contents).hexdigest() + except ImportError: + import md5 + digest = md5.new(contents).hexdigest() del contents tries = 0 diff --git a/cli/koji b/cli/koji index 0ec732f..40974c7 100755 --- a/cli/koji +++ b/cli/koji @@ -31,7 +31,6 @@ import base64 import koji import koji.util import fnmatch -import md5 import os import re import pprint @@ -1173,7 +1172,12 @@ def handle_import_sig(options, session, args): previous = session.queryRPMSigs(rpm_id=rinfo['id'], sigkey=sigkey) assert len(previous) <= 1 if previous: - sighash = md5.new(sighdr).hexdigest() + try: + import hashlib + sighash = hashlib.md5(sighdr).hexdigest() + except ImportError: + import md5 + sighash = md5.new(sighdr).hexdigest() if previous[0]['sighash'] == sighash: print _("Signature already imported: %s") % path continue diff --git a/hub/kojihub.py b/hub/kojihub.py index 8a24bec..0965243 100644 --- a/hub/kojihub.py +++ b/hub/kojihub.py @@ -32,7 +32,6 @@ import logging import logging.handlers import fcntl import fnmatch -import md5 import os import pgdb import random @@ -3535,7 +3534,12 @@ def add_rpm_sig(an_rpm, sighdr): #we use the sigkey='' to represent unsigned in the db (so that uniqueness works) else: sigkey = koji.hex_string(sigkey[13:17]) - sighash = md5.new(sighdr).hexdigest() + try: + import hashlib + sighash = hashlib.md5(sighdr).hexdigest() + except ImportError: + import md5 + sighash = md5.new(sighdr).hexdigest() rpm_id = rinfo['id'] # - db entry q = """SELECT sighash FROM rpmsigs WHERE rpm_id=%(rpm_id)i AND sigkey=%(sigkey)s""" @@ -4771,8 +4775,14 @@ class RootExports(object): if size is not None: if size != len(contents): return False if md5sum is not None: - if md5sum != md5.new(contents).hexdigest(): - return False + try: + import hashlib + if md5sum != hashlib.md5(contents).hexdigest(): + return False + except ImportError: + import md5 + if md5sum != md5.new(contents).hexdigest(): + return False uploadpath = koji.pathinfo.work() #XXX - have an incoming dir and move after upload complete # SECURITY - ensure path remains under uploadpath @@ -4831,7 +4841,12 @@ class RootExports(object): fcntl.lockf(fd, fcntl.LOCK_UN) if md5sum is not None: #check final md5sum - sum = md5.new() + try: + import hashlib + sum = hashlib.md5() + except ImportError: + import md5 + sum = md5.new() fcntl.lockf(fd, fcntl.LOCK_SH|fcntl.LOCK_NB) try: # log_error("checking md5sum") diff --git a/koji/__init__.py b/koji/__init__.py index 6e04cb3..89e9783 100644 --- a/koji/__init__.py +++ b/koji/__init__.py @@ -31,7 +31,6 @@ import datetime from fnmatch import fnmatch import logging import logging.handlers -import md5 import os import os.path import pwd @@ -1467,7 +1466,12 @@ class ClientSession(object): fo = file(localfile, "r") #specify bufsize? totalsize = os.path.getsize(localfile) ofs = 0 - md5sum = md5.new() + try: + import hashlib + md5sum = hashlib.md5() + except ImportError: + import md5 + md5sum = md5.new() debug = self.opts.get('debug',False) if callback: callback(0, totalsize, 0, 0, 0) diff --git a/www/kojiweb/index.py b/www/kojiweb/index.py index 1995a19..2eb236e 100644 --- a/www/kojiweb/index.py +++ b/www/kojiweb/index.py @@ -8,7 +8,6 @@ import Cheetah.Filters import Cheetah.Template import datetime import time -import md5 import koji import kojiweb.util @@ -62,7 +61,13 @@ def _genToken(req, tstamp=None): return '' if tstamp == None: tstamp = _truncTime() - return md5.new(user + str(tstamp) + req.get_options()['Secret']).hexdigest()[-8:] + try: + import hashlib + tokensum = hashlib.md5(user + str(tstamp) + req.get_options()['Secret']).hexdigest()[-8:] + except ImportError: + import md5 + tokensum = md5.new(user + str(tstamp) + req.get_options()['Secret']).hexdigest()[-8:] + return tokensum def _getValidTokens(req): tokens = [] -- 1.6.1.2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Mon Feb 2 22:28:12 2009 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 2 Feb 2009 17:28:12 -0500 Subject: [Fwd: [PATCH] Use hashlib if available instead of md5] In-Reply-To: <1233613170.7493.53.camel@localhost.localdomain> References: <1233613170.7493.53.camel@localhost.localdomain> Message-ID: <20090202222811.GB23577@redhat.com> On Monday, February 02 2009, Jesse Keating said: > This patch converts all calls of md5 function to use hashlib if present. > The old md5 function is deprecated in Python 2.6, and this silences the > warning messages (along with providing a slight performance improvement). Rather than scattering lazy imports in a try except all over the koji code, I wonder if it's worth adding a wrapper in koji.util and only doing the try/except once at the module level there. Probably not speed-critical code, but it would also keep things a little more readable Jeremy From a.badger at gmail.com Mon Feb 2 22:47:42 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 02 Feb 2009 14:47:42 -0800 Subject: [Fwd: [PATCH] Use hashlib if available instead of md5] In-Reply-To: <20090202222811.GB23577@redhat.com> References: <1233613170.7493.53.camel@localhost.localdomain> <20090202222811.GB23577@redhat.com> Message-ID: <4987780E.20305@gmail.com> Jeremy Katz wrote: > On Monday, February 02 2009, Jesse Keating said: >> This patch converts all calls of md5 function to use hashlib if present. >> The old md5 function is deprecated in Python 2.6, and this silences the >> warning messages (along with providing a slight performance improvement). > > Rather than scattering lazy imports in a try except all over the koji > code, I wonder if it's worth adding a wrapper in koji.util and only > doing the try/except once at the module level there. Probably not > speed-critical code, but it would also keep things a little more > readable > Something like: [util.py] try: from hashlib import md5 as md5_constructor except ImportError: from md5 import new as md5_constructor [other.py] from koji.util import md5_constructor digest = md5_constructor(contents).hexdigest() -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Mon Feb 2 23:08:04 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 02 Feb 2009 18:08:04 -0500 Subject: [Fwd: [PATCH] Use hashlib if available instead of md5] In-Reply-To: <20090202222811.GB23577@redhat.com> References: <1233613170.7493.53.camel@localhost.localdomain> <20090202222811.GB23577@redhat.com> Message-ID: <1233616084.27307.14.camel@rosebud> On Mon, 2009-02-02 at 17:28 -0500, Jeremy Katz wrote: > On Monday, February 02 2009, Jesse Keating said: > > This patch converts all calls of md5 function to use hashlib if present. > > The old md5 function is deprecated in Python 2.6, and this silences the > > warning messages (along with providing a slight performance improvement). > > Rather than scattering lazy imports in a try except all over the koji > code, I wonder if it's worth adding a wrapper in koji.util and only > doing the try/except once at the module level there. Probably not > speed-critical code, but it would also keep things a little more > readable > or just have koji import Checksums from yum.misc. since yum does this already. -sv From chenbaozi at gmail.com Thu Feb 5 03:29:54 2009 From: chenbaozi at gmail.com (=?UTF-8?B?6ZmI6bKN5a2c?=) Date: Thu, 5 Feb 2009 11:29:54 +0800 Subject: problems of running koji on CentOS with EPEL packages Message-ID: Hello, I was trying to distribute koji with the rpms from EPEL on CentOS following the instructions of "ServerHowTo". It seems I've made some mistakes that it's said "kojid dead but subsys locked" while I was checking kojid status after having it started successfully. BTW, I was a little confused about how to run a koji environment with the "ServerHowTo" wiki, due to the relationship of those configurations. Chen Baozi -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at ausil.us Thu Feb 5 04:22:21 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 4 Feb 2009 22:22:21 -0600 Subject: problems of running koji on CentOS with EPEL packages In-Reply-To: References: Message-ID: <200902042222.22058.dennis@ausil.us> On Wednesday 04 February 2009 09:29:54 pm ??? wrote: > Hello, > I was trying to distribute koji with the rpms from EPEL on CentOS following > the instructions of "ServerHowTo". It seems I've made some mistakes that > it's said "kojid dead but subsys locked" while I was checking kojid status > after having it started successfully. what do you get when you run "/usr/sbin/kojid -f -c /etc/kojid/kojid.conf" > BTW, I was a little confused about how to run a koji environment with the > "ServerHowTo" wiki, due to the relationship of those configurations. which part was confusing? the howto doesn't really say where to run each piece because each pieces can be run on separate and multiple boxes. for instance fedora runs 2 hubs. multiple builders, a single db box and a single box for serving up the packages. Dennis From gregswift at gmail.com Thu Feb 5 15:03:51 2009 From: gregswift at gmail.com (Greg Swift) Date: Thu, 5 Feb 2009 09:03:51 -0600 Subject: problems of running koji on CentOS with EPEL packages In-Reply-To: References: Message-ID: <4e3f91d70902050703gdcc15feg4b357af1443d9d4b@mail.gmail.com> On 2009-02-04, ??? wrote: > > > BTW, I was a little confused about how to run a koji environment with the > "ServerHowTo" wiki, due to the relationship of those configurations. I had a similar issue when i started playing with koji, and tried making some adjustments to that page. Check it out and let me know if it helps, or if something could use some more clarification. https://fedoraproject.org/wiki/Koji/ServerHowToProposed -greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri Feb 6 01:56:47 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Feb 2009 17:56:47 -0800 Subject: Mock patch to use hosts timezone info in the chroot Message-ID: <1233885408-7854-1-git-send-email-jkeating@redhat.com> This patch copies the host /etc/localtime into the chroot. This allows the chroot to have the same timezone info as the host, which plays into timestamps and such. -- Jes From jkeating at redhat.com Fri Feb 6 01:56:48 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Feb 2009 17:56:48 -0800 Subject: [PATCH] Copy the hosts tzdata (/etc/localtime) into the chroot In-Reply-To: <1233885408-7854-1-git-send-email-jkeating@redhat.com> References: <1233885408-7854-1-git-send-email-jkeating@redhat.com> Message-ID: <1233885408-7854-2-git-send-email-jkeating@redhat.com> --- py/mock/backend.py | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/py/mock/backend.py b/py/mock/backend.py index 2bc63df..6c9bb6e 100644 --- a/py/mock/backend.py +++ b/py/mock/backend.py @@ -263,6 +263,13 @@ class Root(object): # create rpmbuild dir self._buildDirSetup() + # set up timezone to match host + localtimedir = self.makeChrootPath('etc') + localtimepath = self.makeChrootPath('etc', 'localtime') + if os.path.exists(resolvpath): + os.remove(resolvpath) + shutil.copy2('/etc/localtime', localtimedir) + # done with init self._callHooks('postinit') -- 1.6.0.6 From jkeating at redhat.com Fri Feb 6 02:06:59 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Feb 2009 18:06:59 -0800 Subject: Mock patch to use hosts timezone info in the chroot (try 2) Message-ID: <1233886020-8690-1-git-send-email-jkeating@redhat.com> Another try at this. I noticed I used the wrong variable and could have wound up removing /etc/resolv.conf by accident. -- Jes From jkeating at redhat.com Fri Feb 6 02:07:00 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Feb 2009 18:07:00 -0800 Subject: [PATCH] Copy the hosts tzdata (/etc/localtime) into the chroot In-Reply-To: <1233886020-8690-1-git-send-email-jkeating@redhat.com> References: <1233886020-8690-1-git-send-email-jkeating@redhat.com> Message-ID: <1233886020-8690-2-git-send-email-jkeating@redhat.com> --- py/mock/backend.py | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/py/mock/backend.py b/py/mock/backend.py index 2bc63df..6c9bb6e 100644 --- a/py/mock/backend.py +++ b/py/mock/backend.py @@ -263,6 +263,13 @@ class Root(object): # create rpmbuild dir self._buildDirSetup() + # set up timezone to match host + localtimedir = self.makeChrootPath('etc') + localtimepath = self.makeChrootPath('etc', 'localtime') + if os.path.exists(resolvpath): + os.remove(resolvpath) + shutil.copy2('/etc/localtime', localtimedir) + # done with init self._callHooks('postinit') -- 1.6.0.6 From jkeating at redhat.com Fri Feb 6 02:10:43 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Feb 2009 18:10:43 -0800 Subject: Mock patch to use hosts timezone info in the chroot (try 3) Message-ID: <1233886244-8979-1-git-send-email-jkeating@redhat.com> GRRR. git format-patch and /then/ git send-email. *sigh* Here is a third attempt at sending the patch. -- Jes From jkeating at redhat.com Fri Feb 6 02:10:44 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Feb 2009 18:10:44 -0800 Subject: [PATCH] Copy the hosts tzdata (/etc/localtime) into the chroot In-Reply-To: <1233886244-8979-1-git-send-email-jkeating@redhat.com> References: <1233886244-8979-1-git-send-email-jkeating@redhat.com> Message-ID: <1233886244-8979-2-git-send-email-jkeating@redhat.com> --- py/mock/backend.py | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/py/mock/backend.py b/py/mock/backend.py index 2bc63df..86b3fb7 100644 --- a/py/mock/backend.py +++ b/py/mock/backend.py @@ -263,6 +263,13 @@ class Root(object): # create rpmbuild dir self._buildDirSetup() + # set up timezone to match host + localtimedir = self.makeChrootPath('etc') + localtimepath = self.makeChrootPath('etc', 'localtime') + if os.path.exists(localtimepath): + os.remove(localtimepath) + shutil.copy2('/etc/localtime', localtimedir) + # done with init self._callHooks('postinit') -- 1.6.0.6 From chenbaozi at gmail.com Fri Feb 6 03:23:27 2009 From: chenbaozi at gmail.com (=?UTF-8?B?6ZmI6bKN5a2c?=) Date: Fri, 6 Feb 2009 11:23:27 +0800 Subject: problems of running koji on CentOS with EPEL packages Message-ID: Thanks, I think there may be something wrong configuring the "host", because when I tried the command "/usr/sbin/kojid -f" to see what happened, it showed information such as below: Traceback (most recent call last): File "/usr/sbin/kojid", line 2732, in ? main() File "/usr/sbin/kojid", line 68, in main tm = TaskManager() File "/usr/sbin/kojid", line 532, in __init__ self.host_id = session.host.getID() File "/usr/lib/python2.4/site-packages/koji/__init__.py" line 1133, in __call__ return self.__func(self.__name, args, opts) File "/usr/lib/python2.4/site-packages/koji/__init__.py" line 1380, in _callMethod raise err koji.AuthError: No host specified So I'm wondering whether I've made mistakes during configuring "some host". However, I'm really confused about which host it referred. Does it mean the kojihub server? If so, what should I do? I'm now playiing with the whole koji environment at one machine just to see how it works, and plan to run it on several machines to do the real jobs. I guess there must be something wrong with the URL configuration of mine. But I don't know where. From mikem at redhat.com Tue Feb 10 16:42:05 2009 From: mikem at redhat.com (Mike McLean) Date: Tue, 10 Feb 2009 11:42:05 -0500 Subject: problems of running koji on CentOS with EPEL packages In-Reply-To: References: Message-ID: <4991AE5D.8010702@redhat.com> ??? wrote: > Thanks, > I think there may be something wrong configuring the "host", because > when I tried the command "/usr/sbin/kojid -f" to see what happened, it > showed information such as below: > > Traceback (most recent call last): > File "/usr/sbin/kojid", line 2732, in ? > main() > File "/usr/sbin/kojid", line 68, in main > tm = TaskManager() > File "/usr/sbin/kojid", line 532, in __init__ > self.host_id = session.host.getID() > File "/usr/lib/python2.4/site-packages/koji/__init__.py" line > 1133, in __call__ > return self.__func(self.__name, args, opts) > File "/usr/lib/python2.4/site-packages/koji/__init__.py" line > 1380, in _callMethod > raise err > koji.AuthError: No host specified This is happening because kojid is authenticating as a user that is not associated with a build host (or perhaps not authenticating at all). You can't run kojid as a regular user (or anonymously). The hub is trying to determine which host is calling the function and is not finding one. Certain calls can only be executed by build hosts. When you created the host entry (koji add-host ...), an associated user was created with the same name. This is the user that kojid should authenticate as. And just to clarify, the users I'm talking about are the ones internal to koji, not the system users. From chenbaozi at gmail.com Wed Feb 11 01:28:59 2009 From: chenbaozi at gmail.com (=?UTF-8?B?6ZmI6bKN5a2c?=) Date: Wed, 11 Feb 2009 09:28:59 +0800 Subject: problems of running koji on CentOS with EPEL packages Message-ID: > > This is happening because kojid is authenticating as a user that is not > associated with a build host (or perhaps not authenticating at all). You > can't run kojid as a regular user (or anonymously). The hub is trying to > determine which host is calling the function and is not finding one. Certain > calls can only be executed by build hosts. > > When you created the host entry (koji add-host ...), an associated user was > created with the same name. This is the user that kojid should authenticate > as. > > And just to clarify, the users I'm talking about are the ones internal to > koji, not the system users. Thanks. However, how can I associate the kojid user with a build host? Does it mean that I have to configure a DNS to make all this names associate together? Or is there something that I need to configure which I may not have done? At the beginning of wiki " https://fedoraproject.org/wiki/Koji/ServerHowToProposed", it is mentioned that - " > Builders > By default these will be referred to as *kojibuilderX*, but can also > be the hostname(s) of the boxes that will be setup as builders. TODO: can > also or should ? > " I think this may be why I can't make it correctly. What I'm confused now is what the mentioned "hostname(s)". -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregswift at gmail.com Wed Feb 11 04:46:38 2009 From: gregswift at gmail.com (Greg Swift) Date: Tue, 10 Feb 2009 22:46:38 -0600 Subject: problems of running koji on CentOS with EPEL packages In-Reply-To: References: Message-ID: <4e3f91d70902102046x6de6fb41t781b6a4b8e852943@mail.gmail.com> On Tue, Feb 10, 2009 at 19:28, ??? wrote: > This is happening because kojid is authenticating as a user that is not >> associated with a build host (or perhaps not authenticating at all). You >> can't run kojid as a regular user (or anonymously). The hub is trying to >> determine which host is calling the function and is not finding one. Certain >> calls can only be executed by build hosts. >> >> When you created the host entry (koji add-host ...), an associated user >> was created with the same name. This is the user that kojid should >> authenticate as. >> >> And just to clarify, the users I'm talking about are the ones internal to >> koji, not the system users. > > > Thanks. However, how can I associate the kojid user with a build host? Does > it mean that I have to configure a DNS to make all this names associate > together? Or is there something that I need to configure which I may not > have done? > > At the beginning of wiki " > https://fedoraproject.org/wiki/Koji/ServerHowToProposed", it is mentioned > that - " > >> Builders >> By default these will be referred to as *kojibuilderX*, but can also >> be the hostname(s) of the boxes that will be setup as builders. TODO: can >> also or should ? >> > " > I think this may be why I can't make it correctly. What I'm confused now is > what the mentioned "hostname(s)". > Yeah, as you can tell I was even a bit confused by that section (thus the TODO with the question, I was hoping for some input). The impression I got from the original box was that kojibuilder1, kojibuilder2 etc was the naming they were using on their hosts, so by having the username be the same it helped you tie the koji user to the build box. When I implemented this on my network I used the name of the box as the koji userid. This does not cause koji to automatically associate the two, but allows you as the admin to make the association. If someone has a better explanation i'm open to suggestions since my attempt at clarification didn't quite hit the mark. Anyways, in the Builder Setup section you add the host to koji's database and then on the builder you specify the host as the user in /etc/kojid/kojid.conf, these should match. It was my impression that this should match the user name that you created in the SSL configuration. I'm not sure if you are using SSL, and that might be adding to the confusion if you are not *shrug* -greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikem at redhat.com Wed Feb 11 20:17:58 2009 From: mikem at redhat.com (Mike McLean) Date: Wed, 11 Feb 2009 15:17:58 -0500 Subject: problems of running koji on CentOS with EPEL packages In-Reply-To: References: Message-ID: <49933276.5090106@redhat.com> ??? wrote: > Thanks. However, how can I associate the kojid user with a build host? > Does it mean that I have to configure a DNS to make all this names > associate together? Or is there something that I need to configure which > I may not have done? Build hosts need to be tracked in the koji database. You create these entries with the 'koji add-host' command. As I wrote before, this command will also create the associated user of the same name. Whatever name you used when you ran koji add-host, that is the user that kojid needs to authenticate as. > At the beginning of wiki > "https://fedoraproject.org/wiki/Koji/ServerHowToProposed", it is > mentioned that - " > > Builders > By default these will be referred to as /kojibuilderX/, but can > also be the hostname(s) of the boxes that will be setup as builders. > TODO: can also or should ? > > " > I think this may be why I can't make it correctly. What I'm confused now > is what the mentioned "hostname(s)". When you add build hosts in the koji db (with 'koji add-host'), you can give them any name you like. The document linked above presumes you will use names like kojibuilder1, kojibuild2, etc. However it notes that using the hostname (i.e. fqdn) of the machine that kojid will run on is also a reasonable choice. From mikem at redhat.com Wed Feb 11 20:46:54 2009 From: mikem at redhat.com (Mike McLean) Date: Wed, 11 Feb 2009 15:46:54 -0500 Subject: problems of running koji on CentOS with EPEL packages In-Reply-To: <4e3f91d70902102046x6de6fb41t781b6a4b8e852943@mail.gmail.com> References: <4e3f91d70902102046x6de6fb41t781b6a4b8e852943@mail.gmail.com> Message-ID: <4993393E.2000105@redhat.com> Greg Swift wrote: > On Tue, Feb 10, 2009 at 19:28, ??? wrote: >> At the beginning of wiki " >> https://fedoraproject.org/wiki/Koji/ServerHowToProposed", it is mentioned >> that - " >> >>> Builders >>> By default these will be referred to as *kojibuilderX*, but can also >>> be the hostname(s) of the boxes that will be setup as builders. TODO: can >>> also or should ? >>> >> " >> I think this may be why I can't make it correctly. What I'm confused now is >> what the mentioned "hostname(s)". > > Yeah, as you can tell I was even a bit confused by that section (thus the > TODO with the question, I was hoping for some input). The impression I got > from the original box was that kojibuilder1, kojibuilder2 etc was the naming > they were using on their hosts, so by having the username be the same it > helped you tie the koji user to the build box. When I implemented this on > my network I used the name of the box as the koji userid. This does not > cause koji to automatically associate the two, but allows you as the admin > to make the association. If someone has a better explanation i'm open to > suggestions since my attempt at clarification didn't quite hit the mark. The koji database has tables for both hosts and users. Each host has an associated user that the host authenticates as. Due to a bad choice on my part, both the host table and user table have a 'name' column, so it is theoretically possible (if you muck around in the db manually) to create a situation where the name of the host entry is not the same as the name of the associated user entry. /However/ the cli (and the api) do not facilitate this. In all normal situations the name of the host and the name of the associated user will be the same. When you run 'koji add-host', the hub will create both the host and user entries. There is no need to manually add a user for the host, the add-host command will do it for you. If a user of the same name already exists (host or not) the command will fail. You are free to name the hosts anything you like. You do not have to use the fqdn or anything. The user kojid authenticates as determines which host it represents. The machine it is running on is not a direct factor. > Anyways, in the Builder Setup section you add the host to koji's database > and then on the builder you specify the host as the user in > /etc/kojid/kojid.conf, these should match. It was my impression that this > should match the user name that you created in the SSL configuration. I'm > not sure if you are using SSL, and that might be adding to the confusion if > you are not *shrug* Authentication in koji can get messy. Sometimes when getting started, it is easier to start out using password auth and tackle ssl/krb later. Note that you should not use password auth in production. From gregswift at gmail.com Thu Feb 12 01:04:12 2009 From: gregswift at gmail.com (Greg Swift) Date: Wed, 11 Feb 2009 19:04:12 -0600 Subject: problems of running koji on CentOS with EPEL packages In-Reply-To: <4993393E.2000105@redhat.com> References: <4e3f91d70902102046x6de6fb41t781b6a4b8e852943@mail.gmail.com> <4993393E.2000105@redhat.com> Message-ID: <4e3f91d70902111704r25fa67a4geba0a2c0a2e2360@mail.gmail.com> 2009/2/11 Mike McLean > Greg Swift wrote: > > On Tue, Feb 10, 2009 at 19:28, ??? wrote: > >> At the beginning of wiki " > >> https://fedoraproject.org/wiki/Koji/ServerHowToProposed", it is > mentioned > >> that - " > >> > >>> Builders > >>> By default these will be referred to as *kojibuilderX*, but can > also > >>> be the hostname(s) of the boxes that will be setup as builders. TODO: > can > >>> also or should ? > >>> > >> " > >> I think this may be why I can't make it correctly. What I'm confused now > is > >> what the mentioned "hostname(s)". > > > > Yeah, as you can tell I was even a bit confused by that section (thus the > > TODO with the question, I was hoping for some input). The impression I > got > > from the original box was that kojibuilder1, kojibuilder2 etc was the > naming > > they were using on their hosts, so by having the username be the same it > > helped you tie the koji user to the build box. When I implemented this > on > > my network I used the name of the box as the koji userid. This does not > > cause koji to automatically associate the two, but allows you as the > admin > > to make the association. If someone has a better explanation i'm open > to > > suggestions since my attempt at clarification didn't quite hit the mark. > > The koji database has tables for both hosts and users. Each host has an > associated user that the host authenticates as. Due to a bad choice on > my part, both the host table and user table have a 'name' column, so it > is theoretically possible (if you muck around in the db manually) to > create a situation where the name of the host entry is not the same as > the name of the associated user entry. /However/ the cli (and the api) > do not facilitate this. In all normal situations the name of the host > and the name of the associated user will be the same. > > When you run 'koji add-host', the hub will create both the host and user > entries. There is no need to manually add a user for the host, the > add-host command will do it for you. If a user of the same name already > exists (host or not) the command will fail. > > You are free to name the hosts anything you like. You do not have to use > the fqdn or anything. > so in the example: admin-user-name at kojihub$ koji add-host kojibuilder1.example.com i386 x86_64 You could actually just put kojibuilder1 and then in /etc/koji/kojid.conf do this: user = kojibuilder1 If that is the case, awesome.. that through me off because the original documentation used the kojibuilder1.example.com. Should I adjust that to take that into consideration in the Proposed doc? > > The user kojid authenticates as determines which host it represents. The > machine it is running on is not a direct factor. > > > Anyways, in the Builder Setup section you add the host to koji's database > > and then on the builder you specify the host as the user in > > /etc/kojid/kojid.conf, these should match. It was my impression that > this > > should match the user name that you created in the SSL configuration. > I'm > > not sure if you are using SSL, and that might be adding to the confusion > if > > you are not *shrug* > > Authentication in koji can get messy. Sometimes when getting started, it > is easier to start out using password auth and tackle ssl/krb later. > Note that you should not use password auth in production. > I guess i can see that point since the ssl certificates were one of the first things I got hung up on. -greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From cooly at gnome.eu.org Sat Feb 14 17:32:38 2009 From: cooly at gnome.eu.org (Lucian Langa) Date: Sat, 14 Feb 2009 19:32:38 +0200 Subject: mock problems on f10 Message-ID: <1234632758.6586.18.camel@mayday> Hello, I'm having trouble building anything with mock (mock-0.9.13-1.fc10.noarch) for fedora-rawhide-x86_64. The error I'm getting is: rpmdb: Program version 4.5 doesn't match environment version 4.7 This happens even if I do a complete cleanup and reinit. wiping __db* from chroot, rebuilddb locally: rpmdb --dbpath /var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm/ --rebuilddb seems to work but as soon as trying to rebuild any package won't work: mock -r fedora-devel-x86_64 rebuild /root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm --no-clean INFO: mock.py version 0.9.13 starting... State Changed: init plugins State Changed: start INFO: Start(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) Config(fedora-rawhide-x86_64) State Changed: init State Changed: lock buildroot INFO: enabled root cache INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled ccache State Changed: running yum State Changed: setup ERROR: Exception(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) Config(fedora-rawhide-x86_64) 0 minutes 8 seconds INFO: Results and/or logs in: /var/lib/mock//fedora-rawhide-x86_64/result ERROR: Command failed: # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ resolvedep ccache 'gtk+-devel' 'automake' 'libxml-devel' 'audiofile-devel' 'autoconf' 'alsa-lib-devel' 'gettext-devel' rpmdb: Program version 4.5 doesn't match environment version 4.7 error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db3 - (-30972) error: cannot open Packages database in /var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm Traceback (most recent call last): File "/usr/bin/yum", line 29, in yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 229, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 84, in main base.getOptionsConfig(args) File "/usr/share/yum-cli/cli.py", line 184, in getOptionsConfig enabled_plugins=self.optparser._splitArg(opts.enableplugins)) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 192, in _getConfig self._conf = config.readMainConfig(startupconf) File "/usr/lib/python2.5/site-packages/yum/config.py", line 774, in readMainConfig yumvars['releasever'] = _getsysver(startupconf.installroot, startupconf.distroverpkg) File "/usr/lib/python2.5/site-packages/yum/config.py", line 844, in _getsysver idx = ts.dbMatch('provides', distroverpkg) TypeError: rpmdb open failed Thanks, --lucian From martin.langhoff at gmail.com Sat Feb 14 22:02:05 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sun, 15 Feb 2009 11:02:05 +1300 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> Message-ID: <46a038f90902141402x6ef9b899x6d726bc7cb57fded@mail.gmail.com> [ resend - now to the appropriate Fedora list - apologies ] Hi everyone, the olpc XS spin is hitting a problem installing on i586s (and that includes our own XO). The problem seems to be well known -- anaconda composes based on the arch of the build host rather than on the arch requested, as described in: https://fedorahosted.org/revisor/wiki/AnacondaUpdates#TheUnabletoInstalloni586Example2 The revisor conf says "architecture=386", yet we are getting _only_ openssl i686 on the iso, which won't get installed on 586, so everything breaks on the (partially installed) machine. I'm away from my buildbox today -- Jerry's been testing and reports that pungi-driven composes also put an openssl-i386 on the iso, while revisor-driven composes don't. So it sounds like the problem is perhaps in how revisor drives anaconda? Any hints or ideas? It seems to be a well known problem...? (the compose host is a Fedora-9 box, that follows updates.newkey) cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From williams at redhat.com Sun Feb 15 15:11:07 2009 From: williams at redhat.com (Clark Williams) Date: Sun, 15 Feb 2009 09:11:07 -0600 Subject: mock problems on f10 In-Reply-To: <1234632758.6586.18.camel@mayday> References: <1234632758.6586.18.camel@mayday> Message-ID: <20090215091107.64472baa@torg> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 14 Feb 2009 19:32:38 +0200 Lucian Langa wrote: > Hello, > I'm having trouble building anything with mock > (mock-0.9.13-1.fc10.noarch) for fedora-rawhide-x86_64. > The error I'm getting is: rpmdb: Program version 4.5 doesn't match > environment version 4.7 > This happens even if I do a complete cleanup and reinit. > > wiping __db* from chroot, rebuilddb locally: > > rpmdb --dbpath /var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm/ > --rebuilddb > > > seems to work but as soon as trying to rebuild any package won't work: > Sounds like you might have a cached mock root that has an old version of rpm. Try removing /var/lib/mock/cache/fedora-rawhide-x86_64 and see if that fixes it. If not we'll have to dig a little deeper. I'm about to push mock-0.9.14-1 for f10 (it's on rawhide now) and since that moves the cache directory from /var/lib/mock/cache to /var/cache/mock you'll have to rebuild caches again anway. I've been meaning to add that cache clean option. Guess I need to move that up the priority list... Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmYMJEACgkQHyuj/+TTEp07DgCgg3tkiQuXEOLCzd7CzeYtY/t4 33wAnjAuHmgcdXUqzHuI7mfWvh0Z3nPI =RnAp -----END PGP SIGNATURE----- From cooly at gnome.eu.org Sun Feb 15 16:04:13 2009 From: cooly at gnome.eu.org (Lucian Langa) Date: Sun, 15 Feb 2009 18:04:13 +0200 Subject: mock problems on f10 In-Reply-To: <20090215091107.64472baa@torg> References: <1234632758.6586.18.camel@mayday> <20090215091107.64472baa@torg> Message-ID: <1234713853.4578.49.camel@mayday> > Sounds like you might have a cached mock root that has an old version > of rpm. Try removing /var/lib/mock/cache/fedora-rawhide-x86_64 and see > if that fixes it. If not we'll have to dig a little deeper. Wiping entire /var/lib/mock won't help either: mock -r fedora-devel-x86_64 rebuild /root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm INFO: mock.py version 0.9.13 starting... State Changed: init plugins State Changed: start INFO: Start(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) Config(fedora-rawhide-x86_64) State Changed: lock buildroot State Changed: clean State Changed: init State Changed: lock buildroot INFO: enabled root cache INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled ccache State Changed: running yum State Changed: creating cache State Changed: setup ERROR: Exception(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) Config(fedora-rawhide-x86_64) 15 minutes 55 seconds INFO: Results and/or logs in: /var/lib/mock//fedora-rawhide-x86_64/result ERROR: Command failed: # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ resolvedep ccache 'gtk+-devel' 'automake' 'libxml-devel' 'audiofile-devel' 'autoconf' 'alsa-lib-devel' 'gettext-devel' rpmdb: Program version 4.5 doesn't match environment version 4.7 > > I'm about to push mock-0.9.14-1 for f10 (it's on rawhide now) > and since that moves the cache directory from /var/lib/mock/cache > to /var/cache/mock you'll have to rebuild caches again anway. same thing with 0.9.14 cache gets rebuilt but after that same as before: mock -r fedora-devel-x86_64 rebuild /root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm INFO: mock.py version 0.9.14 starting... State Changed: init plugins State Changed: start INFO: Start(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) Config(fedora-rawhide-x86_64) State Changed: lock buildroot State Changed: clean State Changed: init State Changed: lock buildroot Mock Version: 0.9.14 INFO: Mock Version: 0.9.14 INFO: enabled root cache INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled ccache State Changed: running yum State Changed: creating cache State Changed: setup ERROR: Exception(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) Config(fedora-rawhide-x86_64) 13 minutes 27 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result ERROR: Command failed: # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ resolvedep ccache 'gtk+-devel' 'automake' 'libxml-devel' 'audiofile-devel' 'autoconf' 'alsa-lib-devel' 'gettext-devel' rpmdb: Program version 4.5 doesn't match environment version 4.7 From tmz at pobox.com Sun Feb 15 19:29:53 2009 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 15 Feb 2009 14:29:53 -0500 Subject: mock problems on f10 In-Reply-To: <1234713853.4578.49.camel@mayday> References: <1234632758.6586.18.camel@mayday> <20090215091107.64472baa@torg> <1234713853.4578.49.camel@mayday> Message-ID: <20090215192953.GV4505@inocybe.teonanacatl.org> Lucian Langa wrote: > >> Sounds like you might have a cached mock root that has an old version >> of rpm. Try removing /var/lib/mock/cache/fedora-rawhide-x86_64 and see >> if that fixes it. If not we'll have to dig a little deeper. > Wiping entire /var/lib/mock won't help either: > > mock -r fedora-devel-x86_64 > rebuild /root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm > INFO: mock.py version 0.9.13 starting... > State Changed: init plugins > State Changed: start > INFO: Start(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) > Config(fedora-rawhide-x86_64) > State Changed: lock buildroot > State Changed: clean > State Changed: init > State Changed: lock buildroot > INFO: enabled root cache > INFO: enabled yum cache > State Changed: cleaning yum metadata > INFO: enabled ccache > State Changed: running yum > State Changed: creating cache > State Changed: setup > ERROR: Exception(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) > Config(fedora-rawhide-x86_64) 15 minutes 55 seconds > INFO: Results and/or logs > in: /var/lib/mock//fedora-rawhide-x86_64/result > ERROR: Command failed: > # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ > resolvedep ccache 'gtk+-devel' 'automake' 'libxml-devel' > 'audiofile-devel' 'autoconf' 'alsa-lib-devel' 'gettext-devel' > rpmdb: Program version 4.5 doesn't match environment version 4.7 > > >> >> I'm about to push mock-0.9.14-1 for f10 (it's on rawhide now) >> and since that moves the cache directory from /var/lib/mock/cache >> to /var/cache/mock you'll have to rebuild caches again anway. > same thing with 0.9.14 cache gets rebuilt but after that same as before: > > mock -r fedora-devel-x86_64 > rebuild /root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm > INFO: mock.py version 0.9.14 starting... > State Changed: init plugins > State Changed: start > INFO: Start(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) > Config(fedora-rawhide-x86_64) > State Changed: lock buildroot > State Changed: clean > State Changed: init > State Changed: lock buildroot > Mock Version: 0.9.14 > INFO: Mock Version: 0.9.14 > INFO: enabled root cache > INFO: enabled yum cache > State Changed: cleaning yum metadata > INFO: enabled ccache > State Changed: running yum > State Changed: creating cache > State Changed: setup > ERROR: Exception(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) > Config(fedora-rawhide-x86_64) 13 minutes 27 seconds > INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result > ERROR: Command failed: > # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ > resolvedep ccache 'gtk+-devel' 'automake' 'libxml-devel' > 'audiofile-devel' 'autoconf' 'alsa-lib-devel' 'gettext-devel' > rpmdb: Program version 4.5 doesn't match environment version 4.7 How are you running mock? As a user in the mock group? As a user that's not in the mock group? As root? Via sudo? I ran mock as root on a virt box the other day, before any users were set up and I had the same error as above. Once I had a build user setup and part of the mock group, all worked as expected (this was on an F10 guest, running mock 0.9.13). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I am grateful that I am not as judgmental as all those censorious, self-righteous people around me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From cooly at gnome.eu.org Sun Feb 15 20:09:46 2009 From: cooly at gnome.eu.org (Lucian Langa) Date: Sun, 15 Feb 2009 22:09:46 +0200 Subject: mock problems on f10 In-Reply-To: <20090215192953.GV4505@inocybe.teonanacatl.org> References: <1234632758.6586.18.camel@mayday> <20090215091107.64472baa@torg> <1234713853.4578.49.camel@mayday> <20090215192953.GV4505@inocybe.teonanacatl.org> Message-ID: <1234728586.7231.17.camel@mayday> > How are you running mock? As a user in the mock group? As a user > that's not in the mock group? As root? Via sudo? Changing this to an unprivileged user and adding it to mock group works perfectly. Has anything changed lately ? Not having the unprivileged user added to mock group, mock will ask for root password but it will fail to build anything: You are attempting to run "mock" which requires administrative privileges, but more information is needed in order to do so. Authenticating as "root" Password: INFO: mock.py version 0.9.14 starting... State Changed: init plugins State Changed: start INFO: Start(/home/cooly/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) Config(fedora-rawhide-x86_64) State Changed: lock buildroot State Changed: clean State Changed: init ERROR: Could not create dir /var/lib/mock/fedora-rawhide-x86_64/result. Error: [Errno 13] Permission denied: '/var/lib/mock/fedora-rawhide-x86_64/result' From martin.langhoff at gmail.com Mon Feb 16 00:01:08 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 16 Feb 2009 13:01:08 +1300 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <46a038f90902141402x6ef9b899x6d726bc7cb57fded@mail.gmail.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> <46a038f90902141402x6ef9b899x6d726bc7cb57fded@mail.gmail.com> Message-ID: <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> Hi Jeroen, we have revisor on F-9 ignoring the requested arch and building the spin based on the host arch only - is this a known issue? The revisor-made spin we have doesn't work on i586 :-/ more details below... On Sun, Feb 15, 2009 at 10:58 AM, Martin Langhoff wrote: > the olpc XS spin is hitting a problem installing on i586s (and that > includes our own XO). The problem seems to be well known -- anaconda > composes based on the arch of the build host rather than on the arch > requested, as described in: > > https://fedorahosted.org/revisor/wiki/AnacondaUpdates#TheUnabletoInstalloni586Example2 > > The revisor conf says "architecture=386", yet we are getting _only_ > openssl i686 on the iso, which won't get installed on 586, so > everything breaks on the (partially installed) machine. > I'm away from my buildbox today -- Jerry's been testing and reports > that pungi-driven composes also put an openssl-i386 on the iso, while > revisor-driven composes don't. So it sounds like the problem is > perhaps in how revisor drives anaconda? > > Any hints or ideas? It seems to be a well known problem...? > > (the compose host is a Fedora-9 box, that follows updates.newkey) cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kanarip at kanarip.com Mon Feb 16 01:52:08 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 16 Feb 2009 02:52:08 +0100 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> <46a038f90902141402x6ef9b899x6d726bc7cb57fded@mail.gmail.com> <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> Message-ID: <4998C6C8.70103@kanarip.com> Martin Langhoff wrote: > Hi Jeroen, > > we have revisor on F-9 ignoring the requested arch and building the > spin based on the host arch only - is this a known issue? The > revisor-made spin we have doesn't work on i586 :-/ > > more details below... > > On Sun, Feb 15, 2009 at 10:58 AM, Martin Langhoff > wrote: >> the olpc XS spin is hitting a problem installing on i586s (and that >> includes our own XO). The problem seems to be well known -- anaconda >> composes based on the arch of the build host rather than on the arch >> requested, as described in: >> >> https://fedorahosted.org/revisor/wiki/AnacondaUpdates#TheUnabletoInstalloni586Example2 >> >> The revisor conf says "architecture=386", yet we are getting _only_ >> openssl i686 on the iso, which won't get installed on 586, so >> everything breaks on the (partially installed) machine. >> I'm away from my buildbox today -- Jerry's been testing and reports >> that pungi-driven composes also put an openssl-i386 on the iso, while >> revisor-driven composes don't. So it sounds like the problem is >> perhaps in how revisor drives anaconda? >> >> Any hints or ideas? It seems to be a well known problem...? >> >> (the compose host is a Fedora-9 box, that follows updates.newkey) > Hi Martin, Since your first mail, I've tried to reproduce this. I have no problems producing installation media with both openssl.i386 and openssl.i686 in the RPM payload (Packages/ directory) - with either respin mode or without, which I was thinking may have been the issue. This however is using a fresh git clone off of master, not the released version of Revisor on Fedora 9. Are you composing Live media by any chance? I can see how there is no .i386 version of openssl installed. Kind regards, Jeroen van Meeuwen -kanarip From martin.langhoff at gmail.com Mon Feb 16 02:06:45 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 16 Feb 2009 15:06:45 +1300 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <4998C6C8.70103@kanarip.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> <46a038f90902141402x6ef9b899x6d726bc7cb57fded@mail.gmail.com> <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> <4998C6C8.70103@kanarip.com> Message-ID: <46a038f90902151806h50595dd4r8152baab33bddc2b@mail.gmail.com> On Mon, Feb 16, 2009 at 2:52 PM, Jeroen van Meeuwen wrote: > Since your first mail, I've tried to reproduce this. I have no problems > producing installation media with both openssl.i386 and openssl.i686 in the > RPM payload (Packages/ directory) - with either respin mode or without, > which I was thinking may have been the issue. This however is using a fresh > git clone off of master, not the released version of Revisor on Fedora 9. We are not using respin mode, we're creating it from scratch... > Are you composing Live media by any chance? I can see how there is no .i386 > version of openssl installed. No. Just a single disk install iso... cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kanarip at kanarip.com Mon Feb 16 14:17:31 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 16 Feb 2009 15:17:31 +0100 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <46a038f90902151806h50595dd4r8152baab33bddc2b@mail.gmail.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> <46a038f90902141402x6ef9b899x6d726bc7cb57fded@mail.gmail.com> <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> <4998C6C8.70103@kanarip.com> <46a038f90902151806h50595dd4r8152baab33bddc2b@mail.gmail.com> Message-ID: <4999757B.1000001@kanarip.com> Martin Langhoff wrote: > On Mon, Feb 16, 2009 at 2:52 PM, Jeroen van Meeuwen wrote: >> Since your first mail, I've tried to reproduce this. I have no problems >> producing installation media with both openssl.i386 and openssl.i686 in the >> RPM payload (Packages/ directory) - with either respin mode or without, >> which I was thinking may have been the issue. This however is using a fresh >> git clone off of master, not the released version of Revisor on Fedora 9. > > We are not using respin mode, we're creating it from scratch... > Like I said either with or without respin mode, both openssl.i386 and openssl.i686 are pulled into the RPM payload. Can you maybe send me a log file with both Revisor as well as YUM set to debuglevel 9? For Revisor, that's --debug 9, for YUM that's debuglevel= in the appropriate configuration file in /etc/revisor/conf.d/ Thanks, Kind regards, Jeroen van Meeuwen -kanarip From williams at redhat.com Mon Feb 16 14:48:21 2009 From: williams at redhat.com (Clark Williams) Date: Mon, 16 Feb 2009 08:48:21 -0600 Subject: mock problems on f10 In-Reply-To: <1234728586.7231.17.camel@mayday> References: <1234632758.6586.18.camel@mayday> <20090215091107.64472baa@torg> <1234713853.4578.49.camel@mayday> <20090215192953.GV4505@inocybe.teonanacatl.org> <1234728586.7231.17.camel@mayday> Message-ID: <20090216084821.155058f3@torg> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 15 Feb 2009 22:09:46 +0200 Lucian Langa wrote: > > > How are you running mock? As a user in the mock group? As a user > > that's not in the mock group? As root? Via sudo? > Changing this to an unprivileged user and adding it to mock group works > perfectly. Has anything changed lately ? Not having the unprivileged > user added to mock group, mock will ask for root password but it will > fail to build anything: > > We've been changing it over time (but nothing has happened wrt privileges in the past couple of releases). Essentially we start up privileged and pam authenticates us. We do whatever is needed (e.g. create directories, run rpm) as root, then drop privs for the build process. Obviously we haven't got it quite right for the running-as-root case. I suspect just adding root to the 'mock' group would take care of this problem. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmZfL0ACgkQHyuj/+TTEp293ACgpRE3VXq4revSzRaBqnqLcmHr 40IAn0G19hgdqlOSP/d0oIgynGHBBgGs =pFGt -----END PGP SIGNATURE----- From cooly at gnome.eu.org Mon Feb 16 20:10:34 2009 From: cooly at gnome.eu.org (Lucian Langa) Date: Mon, 16 Feb 2009 22:10:34 +0200 Subject: mock problems on f10 In-Reply-To: <20090216084821.155058f3@torg> References: <1234632758.6586.18.camel@mayday> <20090215091107.64472baa@torg> <1234713853.4578.49.camel@mayday> <20090215192953.GV4505@inocybe.teonanacatl.org> <1234728586.7231.17.camel@mayday> <20090216084821.155058f3@torg> Message-ID: <1234815034.20587.172.camel@mayday> On Mon, 2009-02-16 at 08:48 -0600, Clark Williams wrote: > I suspect just adding root to the 'mock' group would take care of this > problem. Just as a note adding root to the 'mock' group (and removing cache dir) won't help. --lucian From giallu at gmail.com Tue Feb 17 11:47:50 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 17 Feb 2009 12:47:50 +0100 Subject: [PATCH] Add --chainbuild option. Message-ID: With this patch, mock grows a --chainbuild option (and a Require on createrepo). The --chainbuild option work by creating a local yum repository in the resultdir path which is used during the BuildRequires installation step. The net result is that, when building more than one srpm in the same run, later builds can find required packages built in previous steps. --- py/mock.py | 11 +++++++++++ py/mock/backend.py | 8 ++++++++ py/mock/util.py | 7 +++++++ 3 files changed, 26 insertions(+), 0 deletions(-) diff --git a/py/mock.py b/py/mock.py index 408b421..a801807 100755 --- a/py/mock.py +++ b/py/mock.py @@ -113,6 +113,11 @@ def command_parse(config_opts): help="chroot name/config file name default: %default", default='default') + parser.add_option("--chainbuild", action="store_true", dest="chainbuild", + help="install all built RPMs in the chroot before continuing" + " with the next one", + default=False) + parser.add_option("--offline", action="store_false", dest="online", default=True, help="activate 'offline' mode.") @@ -216,6 +221,7 @@ def setup_default_config_opts(config_opts, unprivUid): config_opts['build_log_fmt_name'] = "unadorned" config_opts['root_log_fmt_name'] = "detailed" config_opts['state_log_fmt_name'] = "state" + config_opts['chainbuild'] = False config_opts['online'] = True config_opts['internal_dev_setup'] = True @@ -347,6 +353,7 @@ def set_config_opts_per_cmdline(config_opts, options, args): config_opts['cleanup_on_failure'] = False config_opts['online'] = options.online + config_opts['chainbuild'] = options.chainbuild decorate(traceLog()) def do_rebuild(config_opts, chroot, srpms): @@ -366,6 +373,10 @@ def do_rebuild(config_opts, chroot, srpms): log.info("Start(%s) Config(%s)" % (srpm, chroot.sharedRootName)) if config_opts['clean'] and chroot.state() != "clean": chroot.clean() + # if chainbuilding, prepare the local repository + if config_opts['chainbuild']: + mock.util.createRepo( chroot.resultdir ) + chroot.init() chroot.build(srpm, timeout=config_opts['rpmbuild_timeout']) elapsed = time.time() - start diff --git a/py/mock/backend.py b/py/mock/backend.py index 2bc63df..560fb03 100644 --- a/py/mock/backend.py +++ b/py/mock/backend.py @@ -57,6 +57,14 @@ class Root(object): self.chrootgid = config['chrootgid'] self.chrootgroup = 'mockbuild' self.yum_conf_content = config['yum.conf'] + + if config['chainbuild']: + self.yum_conf_content = self.yum_conf_content + '\n'.join([ + '[chainbuild]', + 'name=chainbuild', + 'baseurl=file://%s' % os.path.abspath(self.resultdir) + ]) + self.use_host_resolv = config['use_host_resolv'] self.chroot_file_contents = config['files'] self.chroot_setup_cmd = config['chroot_setup_cmd'] diff --git a/py/mock/util.py b/py/mock/util.py index f52003e..943d4bb 100644 --- a/py/mock/util.py +++ b/py/mock/util.py @@ -262,6 +262,13 @@ def logOutput(fds, logger, returnOutput=1, start=0, timeout=0): logger.debug(tail) return output + +decorate(traceLog()) +def createRepo(path): + cmd = 'createrepo %s' % path + mock.util.do( cmd, shell=True ) + + # logger = # output = [1|0] # chrootPath -- 1.6.0.6 From andreas at bawue.net Tue Feb 17 12:23:15 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 17 Feb 2009 13:23:15 +0100 (CET) Subject: [PATCH] Add --chainbuild option. In-Reply-To: References: Message-ID: On Tue, 17 Feb 2009, Gianluca Sforna wrote: > With this patch, mock grows a --chainbuild option (and a Require on > createrepo). > > The --chainbuild option work by creating a local yum repository in the > resultdir path which is used during the BuildRequires installation > step. > The net result is that, when building more than one srpm in the same > run, later builds can find required packages built in previous steps. Is it really worth it including this in mock? I'm using the same concept here for our in-house builds. But all the logic is part of a shellscript which calls mock for both i386 and x86_64 and fills a "local" repository with the results. This is similar to what plague and AFAIK koji do. Might be worthwile considering that. regards, andreas From giallu at gmail.com Tue Feb 17 12:38:29 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 17 Feb 2009 13:38:29 +0100 Subject: [PATCH] Add --chainbuild option. In-Reply-To: References: Message-ID: On Tue, Feb 17, 2009 at 1:23 PM, Andreas Thienemann wrote: > > Is it really worth it including this in mock? > > I'm using the same concept here for our in-house builds. But all the logic > is part of a shellscript which calls mock for both i386 and x86_64 and > fills a "local" repository with the results. > This is similar to what plague and AFAIK koji do. It's just that I found myself needing this just after seeing: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/97941 and Seth's response: http://article.gmane.org/gmane.linux.redhat.fedora.devel/97950 I'm just sharing what I wrapped up in case someone else find it useful... -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From andreas at bawue.net Tue Feb 17 12:49:47 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 17 Feb 2009 13:49:47 +0100 (CET) Subject: [PATCH] Add --chainbuild option. In-Reply-To: References: Message-ID: On Tue, 17 Feb 2009, Gianluca Sforna wrote: > It's just that I found myself needing this just after seeing: > > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/97941 > > and Seth's response: > http://article.gmane.org/gmane.linux.redhat.fedora.devel/97950 > > I'm just sharing what I wrapped up in case someone else find it useful... Hahaha. You win. :) We've been using something like smock just as a bash script. regards, andreas From jeff at ocjtech.us Tue Feb 17 14:30:50 2009 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 17 Feb 2009 08:30:50 -0600 Subject: [PATCH] yumbase._getConfig() doesn't take any arguments, use yumbase.preconf to set yum up. Message-ID: <1234881050-1280-1-git-send-email-jeff@ocjtech.us> Signed-off-by: Jeffrey C. Ollie --- builder/mergerepos | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/builder/mergerepos b/builder/mergerepos index 4243444..defb8c1 100755 --- a/builder/mergerepos +++ b/builder/mergerepos @@ -95,7 +95,10 @@ class RepoMerge(object): self.mdconf.verbose = True self.mdconf.changelog_limit = 3 self.yumbase = yum.YumBase() - self.yumbase._getConfig('/dev/null', init_plugins=False, debuglevel=2) + self.yumbase.preconf.fn = '/dev/null' + self.yumbase.preconf.init_plugins = False + self.yumbase.preconf.debuglevel = 2 + self.yumbase._getConfig() self.yumbase.conf.cachedir = tempfile.mkdtemp() self.yumbase.conf.cache = 0 self.archlist = arches -- 1.6.0.6 From jeff at ocjtech.us Tue Feb 17 16:29:04 2009 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 17 Feb 2009 10:29:04 -0600 Subject: [PATCH] Add compatibility back in for older versions of Yum. In-Reply-To: <1234881050-1280-1-git-send-email-jeff@ocjtech.us> References: <1234881050-1280-1-git-send-email-jeff@ocjtech.us> Message-ID: <1234888144-23613-1-git-send-email-jeff@ocjtech.us> We would like for Koji to remain compatible with the version of Yum that is shipped with RHEL 5. Signed-off-by: Jeffrey C. Ollie --- builder/mergerepos | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/builder/mergerepos b/builder/mergerepos index defb8c1..cfa3a8d 100755 --- a/builder/mergerepos +++ b/builder/mergerepos @@ -95,10 +95,13 @@ class RepoMerge(object): self.mdconf.verbose = True self.mdconf.changelog_limit = 3 self.yumbase = yum.YumBase() - self.yumbase.preconf.fn = '/dev/null' - self.yumbase.preconf.init_plugins = False - self.yumbase.preconf.debuglevel = 2 - self.yumbase._getConfig() + if hasattr(self.yumbase, 'preconf'): + self.yumbase.preconf.fn = '/dev/null' + self.yumbase.preconf.init_plugins = False + self.yumbase.preconf.debuglevel = 2 + self.yumbase._getConfig() + else: + self.yumbase._getConfig('/dev/null', init_plugins=False, debuglevel=2) self.yumbase.conf.cachedir = tempfile.mkdtemp() self.yumbase.conf.cache = 0 self.archlist = arches -- 1.6.0.6 From jeff at ocjtech.us Tue Feb 17 17:53:59 2009 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 17 Feb 2009 11:53:59 -0600 Subject: [PATCH] Add a test-srpm target to the Makefile. Message-ID: <1234893239-30898-1-git-send-email-jeff@ocjtech.us> --- Makefile | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 7432f31..51196ea 100644 --- a/Makefile +++ b/Makefile @@ -81,6 +81,9 @@ tarball: clean srpm: tarball $(RPM_WITH_DIRS) $(DIST_DEFINES) -bs $(SPECFILE) +test-srpm: tarball + $(RPM_WITH_DIRS) $(DIST_DEFINES) --define "testbuild 1" -bs $(SPECFILE) + rpm: tarball $(RPM_WITH_DIRS) $(DIST_DEFINES) -bb $(SPECFILE) -- 1.6.1.2 From mikeb at redhat.com Tue Feb 17 21:11:28 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 17 Feb 2009 16:11:28 -0500 Subject: [PATCH] Add compatibility back in for older versions of Yum. In-Reply-To: <1234888144-23613-1-git-send-email-jeff@ocjtech.us> References: <1234881050-1280-1-git-send-email-jeff@ocjtech.us> <1234888144-23613-1-git-send-email-jeff@ocjtech.us> Message-ID: <499B2800.3090201@redhat.com> Jeffrey C. Ollie wrote: > We would like for Koji to remain compatible with the version of Yum > that is shipped with RHEL 5. > > Signed-off-by: Jeffrey C. Ollie > --- > builder/mergerepos | 11 +++++++---- > 1 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/builder/mergerepos b/builder/mergerepos > index defb8c1..cfa3a8d 100755 > --- a/builder/mergerepos > +++ b/builder/mergerepos > @@ -95,10 +95,13 @@ class RepoMerge(object): > self.mdconf.verbose = True > self.mdconf.changelog_limit = 3 > self.yumbase = yum.YumBase() > - self.yumbase.preconf.fn = '/dev/null' > - self.yumbase.preconf.init_plugins = False > - self.yumbase.preconf.debuglevel = 2 > - self.yumbase._getConfig() > + if hasattr(self.yumbase, 'preconf'): > + self.yumbase.preconf.fn = '/dev/null' > + self.yumbase.preconf.init_plugins = False > + self.yumbase.preconf.debuglevel = 2 > + self.yumbase._getConfig() > + else: > + self.yumbase._getConfig('/dev/null', init_plugins=False, debuglevel=2) > self.yumbase.conf.cachedir = tempfile.mkdtemp() > self.yumbase.conf.cache = 0 > self.archlist = arches Applied, thanks for the patch! From jeff at ocjtech.us Tue Feb 17 21:32:04 2009 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 17 Feb 2009 15:32:04 -0600 Subject: [PATCH] Add a "sources" target as an alias for "tarball". Message-ID: <1234906324-13530-1-git-send-email-jeff@ocjtech.us> This makes building Koji packages directly from a Koji git repository in Koji possible. Highly self-referential! Signed-off-by: Jeffrey C. Ollie --- Makefile | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 7432f31..fcd4dca 100644 --- a/Makefile +++ b/Makefile @@ -78,6 +78,8 @@ test-tarball: tarball: clean @git archive --format=tar --prefix=$(NAME)-$(VERSION)/ HEAD |bzip2 > $(NAME)-$(VERSION).tar.bz2 +sources: tarball + srpm: tarball $(RPM_WITH_DIRS) $(DIST_DEFINES) -bs $(SPECFILE) -- 1.6.1.3 From james at fedoraproject.org Tue Feb 17 23:59:03 2009 From: james at fedoraproject.org (James Antill) Date: Tue, 17 Feb 2009 18:59:03 -0500 Subject: [PATCH] Add compatibility back in for older versions of Yum. In-Reply-To: <1234888144-23613-1-git-send-email-jeff@ocjtech.us> References: <1234881050-1280-1-git-send-email-jeff@ocjtech.us> <1234888144-23613-1-git-send-email-jeff@ocjtech.us> Message-ID: <1234915143.14699.0.camel@code.and.org> On Tue, 2009-02-17 at 10:29 -0600, Jeffrey C. Ollie wrote: > We would like for Koji to remain compatible with the version of Yum > that is shipped with RHEL 5. > > Signed-off-by: Jeffrey C. Ollie > --- > builder/mergerepos | 11 +++++++---- > 1 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/builder/mergerepos b/builder/mergerepos > index defb8c1..cfa3a8d 100755 > --- a/builder/mergerepos > +++ b/builder/mergerepos > @@ -95,10 +95,13 @@ class RepoMerge(object): > self.mdconf.verbose = True > self.mdconf.changelog_limit = 3 > self.yumbase = yum.YumBase() > - self.yumbase.preconf.fn = '/dev/null' > - self.yumbase.preconf.init_plugins = False > - self.yumbase.preconf.debuglevel = 2 > - self.yumbase._getConfig() > + if hasattr(self.yumbase, 'preconf'): > + self.yumbase.preconf.fn = '/dev/null' > + self.yumbase.preconf.init_plugins = False > + self.yumbase.preconf.debuglevel = 2 > + self.yumbase._getConfig() This line should be deleted, the first line after the if will turn the preconf into the conf. > + else: > + self.yumbase._getConfig('/dev/null', init_plugins=False, debuglevel=2) > self.yumbase.conf.cachedir = tempfile.mkdtemp() > self.yumbase.conf.cache = 0 > self.archlist = arches -- James Antill Fedora From mikeb at redhat.com Wed Feb 18 15:28:05 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Wed, 18 Feb 2009 10:28:05 -0500 Subject: [PATCH] Add compatibility back in for older versions of Yum. In-Reply-To: <1234915143.14699.0.camel@code.and.org> References: <1234881050-1280-1-git-send-email-jeff@ocjtech.us> <1234888144-23613-1-git-send-email-jeff@ocjtech.us> <1234915143.14699.0.camel@code.and.org> Message-ID: <499C2905.8090502@redhat.com> James Antill wrote: > On Tue, 2009-02-17 at 10:29 -0600, Jeffrey C. Ollie wrote: >> We would like for Koji to remain compatible with the version of Yum >> that is shipped with RHEL 5. >> >> Signed-off-by: Jeffrey C. Ollie >> --- >> builder/mergerepos | 11 +++++++---- >> 1 files changed, 7 insertions(+), 4 deletions(-) >> >> diff --git a/builder/mergerepos b/builder/mergerepos >> index defb8c1..cfa3a8d 100755 >> --- a/builder/mergerepos >> +++ b/builder/mergerepos >> @@ -95,10 +95,13 @@ class RepoMerge(object): >> self.mdconf.verbose = True >> self.mdconf.changelog_limit = 3 >> self.yumbase = yum.YumBase() >> - self.yumbase.preconf.fn = '/dev/null' >> - self.yumbase.preconf.init_plugins = False >> - self.yumbase.preconf.debuglevel = 2 >> - self.yumbase._getConfig() >> + if hasattr(self.yumbase, 'preconf'): >> + self.yumbase.preconf.fn = '/dev/null' >> + self.yumbase.preconf.init_plugins = False >> + self.yumbase.preconf.debuglevel = 2 >> + self.yumbase._getConfig() > > This line should be deleted, the first line after the if will turn the > preconf into the conf. Thanks, I've made that change. >> + else: >> + self.yumbase._getConfig('/dev/null', init_plugins=False, debuglevel=2) >> self.yumbase.conf.cachedir = tempfile.mkdtemp() >> self.yumbase.conf.cache = 0 >> self.archlist = arches From wacker at octothorp.org Wed Feb 18 16:10:20 2009 From: wacker at octothorp.org (William F. Acker WB2FLW +1 303 722 7209) Date: Wed, 18 Feb 2009 09:10:20 -0700 (MST) Subject: Error from repoview when composing with pungi. Message-ID: Hi all, I'm not sure which new package might have broken this; I think I succeeded after upgrading yum, but I can't be sure. Here's the spewage. Pungi:ERROR: Got an error from /usr/bin/repoview Pungi:ERROR: Traceback (most recent call last): File "/usr/bin/repoview", line 926, in main() File "/usr/bin/repoview", line 923, in main Repoview(opts) File "/usr/bin/repoview", line 191, in __init__ packages = self.do_packages(repo_data, group_data, pkgnames) File "/usr/bin/repoview", line 554, in do_packages if self.has_changed(pkg_filename, checksum): File "/usr/bin/repoview", line 607, in has_changed scursor.execute(query) sqlite3.IntegrityError: column filename is not unique Saving Primary metadata Saving file lists metadata Saving other metadata Generating sqlite DBs Sqlite DBs complete Traceback (most recent call last): File "/usr/bin/pungi", line 195, in main() File "/usr/bin/pungi", line 99, in main mypungi.doCreaterepo() File "/usr/lib/python2.5/site-packages/pypungi/__init__.py", line 636, in doCreaterepo self._makeMetadata(self.topdir, cachedir, compsfile, repoview=True, repoviewtitle=repoviewtitle) File "/usr/lib/python2.5/site-packages/pypungi/__init__.py", line 612, in _makeMetadata pypungi.util._doRunCommand(repoview, self.logger) File "/usr/lib/python2.5/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/repoview: Traceback (most recent call last): File "/usr/bin/repoview", line 926, in main() File "/usr/bin/repoview", line 923, in main Repoview(opts) File "/usr/bin/repoview", line 191, in __init__ packages = self.do_packages(repo_data, group_data, pkgnames) File "/usr/bin/repoview", line 554, in do_packages if self.has_changed(pkg_filename, checksum): File "/usr/bin/repoview", line 607, in has_changed scursor.execute(query) sqlite3.IntegrityError: column filename is not unique Any ideas? TIA. -- Bill in Denver From skvidal at fedoraproject.org Wed Feb 18 16:16:34 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 18 Feb 2009 11:16:34 -0500 Subject: Error from repoview when composing with pungi. In-Reply-To: References: Message-ID: <1234973794.16686.111.camel@rosebud> On Wed, 2009-02-18 at 09:10 -0700, William F. Acker WB2FLW +1 303 722 7209 wrote: > Hi all, > > I'm not sure which new package might have broken this; I think I > succeeded after upgrading yum, but I can't be sure. > > Here's the spewage. > > Pungi:ERROR: Got an error from /usr/bin/repoview > Pungi:ERROR: Traceback (most recent call last): > File "/usr/bin/repoview", line 926, in > main() > File "/usr/bin/repoview", line 923, in main > Repoview(opts) > File "/usr/bin/repoview", line 191, in __init__ > packages = self.do_packages(repo_data, group_data, pkgnames) > File "/usr/bin/repoview", line 554, in do_packages > if self.has_changed(pkg_filename, checksum): > File "/usr/bin/repoview", line 607, in has_changed > scursor.execute(query) > sqlite3.IntegrityError: column filename is not unique > pretty sure it is b/c of the update to sqlite. The columns will probably need a rename in repoview. I'll check the changelogs on sqlite. -sv From wacker at octothorp.org Wed Feb 18 21:35:52 2009 From: wacker at octothorp.org (William F. Acker WB2FLW +1 303 722 7209) Date: Wed, 18 Feb 2009 14:35:52 -0700 (MST) Subject: Error from repoview when composing with pungi. In-Reply-To: <1234973794.16686.111.camel@rosebud> References: <1234973794.16686.111.camel@rosebud> Message-ID: On Wed, 18 Feb 2009, seth vidal wrote: > On Wed, 2009-02-18 at 09:10 -0700, William F. Acker WB2FLW +1 303 722 > 7209 wrote: >> Hi all, >> >> I'm not sure which new package might have broken this; I think I >> succeeded after upgrading yum, but I can't be sure. >> >> Here's the spewage. >> >> Pungi:ERROR: Got an error from /usr/bin/repoview >> Pungi:ERROR: Traceback (most recent call last): >> File "/usr/bin/repoview", line 926, in >> main() >> File "/usr/bin/repoview", line 923, in main >> Repoview(opts) >> File "/usr/bin/repoview", line 191, in __init__ >> packages = self.do_packages(repo_data, group_data, pkgnames) >> File "/usr/bin/repoview", line 554, in do_packages >> if self.has_changed(pkg_filename, checksum): >> File "/usr/bin/repoview", line 607, in has_changed >> scursor.execute(query) >> sqlite3.IntegrityError: column filename is not unique >> > > > pretty sure it is b/c of the update to sqlite. The columns will probably > need a rename in repoview. I'll check the changelogs on sqlite. > I back leveled sqlite on the build machine which didn't help. I know that's not conclusive since some packages such as Anaconda are downloaded from the repo and never cached. So, before putting the old sqlite into the repo, I checked to see the when I was last successful VS when I installed sqlite. It turns out that both yum and sqlite were installed on 2/5, and my last successful spin was on 2/8. I don't see any packages installed since them that are obviously connected to this problem. BTW, Seth, how is one supposed to use the allowdowngrade plugin for yum. I tried yum --allow-downgrade localinstall sqlite*, with the result the same as if I didn't use the option. localupdate was no better. I had to fall back on "rpm -Uv --oldpackage sqlite*". Thanks. -- Bill in Denver From skvidal at fedoraproject.org Wed Feb 18 21:43:15 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 18 Feb 2009 16:43:15 -0500 Subject: Error from repoview when composing with pungi. In-Reply-To: References: <1234973794.16686.111.camel@rosebud> Message-ID: <1234993395.16686.141.camel@rosebud> On Wed, 2009-02-18 at 14:35 -0700, William F. Acker WB2FLW +1 303 722 7209 wrote: > I back leveled sqlite on the build machine which didn't help. I know > that's not conclusive since some packages such as Anaconda are downloaded > from the repo and never cached. So, before putting the old sqlite into > the repo, I checked to see the when I was last successful VS when I > installed sqlite. It turns out that both yum and sqlite were installed on > 2/5, and my last successful spin was on 2/8. I don't see any packages > installed since them that are obviously connected to this problem. > I'm not sure if this is sqlite anymore - I've been mucking with it today. Oddly on rawhide here I can't make it happen. > BTW, Seth, how is one supposed to use the allowdowngrade plugin for > yum. I tried yum --allow-downgrade localinstall sqlite*, with the result > the same as if I didn't use the option. localupdate was no better. I had > to fall back on "rpm -Uv --oldpackage sqlite*". In most cases, you're not. allowdowngrade sometimes is just not working. It's a long story as to why but it is something that is being worked on - it's just not trivial. -sv From skvidal at fedoraproject.org Thu Feb 19 00:02:32 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 18 Feb 2009 19:02:32 -0500 Subject: Error from repoview when composing with pungi. In-Reply-To: <1234993395.16686.141.camel@rosebud> References: <1234973794.16686.111.camel@rosebud> <1234993395.16686.141.camel@rosebud> Message-ID: <1235001752.16686.160.camel@rosebud> On Wed, 2009-02-18 at 16:43 -0500, seth vidal wrote: > On Wed, 2009-02-18 at 14:35 -0700, William F. Acker WB2FLW +1 303 722 > 7209 wrote: > > > I back leveled sqlite on the build machine which didn't help. I know > > that's not conclusive since some packages such as Anaconda are downloaded > > from the repo and never cached. So, before putting the old sqlite into > > the repo, I checked to see the when I was last successful VS when I > > installed sqlite. It turns out that both yum and sqlite were installed on > > 2/5, and my last successful spin was on 2/8. I don't see any packages > > installed since them that are obviously connected to this problem. > > > > I'm not sure if this is sqlite anymore - I've been mucking with it > today. Oddly on rawhide here I can't make it happen. > > ah ha! My sample size was too small. I found out what was causing the problem somehow we had two packages VLGothic-fonts and vlgothic-fonts - repoview case normalizes for the .html files it makes - hence this problem. Fedora was not supposed to have those two pkgs - it was an oversight and that has been fixed. I'll also change repoview to not case normalize the filenames. -sv From mikem at redhat.com Thu Feb 19 00:51:22 2009 From: mikem at redhat.com (Mike McLean) Date: Wed, 18 Feb 2009 19:51:22 -0500 Subject: koji 1.3.0 Message-ID: <499CAD0A.9090602@redhat.com> The tarball is posted here: https://fedorahosted.org/koji/wiki/KojiRelease (created from koji-1.3.0 tag) Major Changes -------------- Support for external repos new cli commands createrepo tasks now have a higher weight Support for noarch subpackages Support larger hashes Handle different kinds of rpm signatures [mitr] (#127) support file digests other than md5 in the api and web UI Hub configuration via hub.conf use a hub config file instead of PythonOptions scan for handlers once at startup instead of each call now honors KojiDir Remove huge tables from db - rpmfiles, rpmdeps and changelog tables dropped - data pulled from rpms as needed Build srpms in chroots bump the weight of buildSRPMFromSCM Some web ui theming support SiteName option (the name that shows up in the title) move explicit image sizes to css make welcome message customizable Improved security add an auth token to defend against CSRF include the current time in the cookie some changes to the web UI to defend against XSS Hub policies configured in hub.conf enable verbose policy errors without full debug current policies: tag: controls tag, untag, move operations build_from_srpm: controls whether such builds are allowed build_from_repo_id: controls whether such builds are allowed Plugin support kojihub and kojid now have limited plugin support Other Changes ------------- Python-2.6-isms use hashlib if available use subprocess instead of popen2 Builder improved task cleanup check the load average before taking a task make use of createrepo --update optional choose a better arch for noarch builds update the buildArch task weight based on the average duration of a build of the package set %distribution the same way we set %vendor and %packager cleanup before re-taking a freed or reassigned task indicate which log people should look in for build failures make use of --skip-stat configurable use same repo for all buildArch subtasks more fully honor topdir option Web UI show summary and description for rpms and builds group rpms more sensibly (make the build log links correct) remove the dirtyness indicator from the buildrootinfo page (never used) enable displaying of only the latest builds in a tag use ids instead of names in the urls fix the "Watch logs" feature in the web UI to work over SSL cache compiled Cheetah templates update the web UI to conform to XHTML 1.0 Transitional tasks page: rework view selector use kojiweb.publisher (new location) Hub NotifyOnSuccess option honor KojiDir option DisableNotifications option don't blow up when the database contains older base64 encoded task data make a latest link when a new repo completes add createdBefore= and createdAfter= parameters to listBuilds() fix LoginCreatesUser check in resetBuild use CANCELED state instead of FAILED report offline status if: db connection fails there are errors on startup preserve old extra_arches during package list updates Command line new subcommand: search new subcommand: regen-repo new subcommand: remove-tag show package filters correctly in taginfo allow list-tagged to query at an event added --non-latest to untag-pkg subcommand added --old-user flag to set-pkg-owner-global subcommand show buildroot info in rpminfo output show arch in list-buildroot output handle chain-build cases where the build tag is the same as the dest tag Utils don't start kojira by default (#96) fix timestamp checks when deleting repos package koji-gc added purge option to koji-gc added koji-shadow utility for shadow builds Changes related to shadow builds koji-shadow utility allow creation of repos from a specified event allow building from a specific repo id (subject to policy) Miscellaneous add a strict option to multiCall() handle empty multicalls sensibly return a placeholder object while in a multicall enable building Koji from the Koji git repo with Koji [Jeffrey C. Ollie] From martin.langhoff at gmail.com Mon Feb 23 06:48:07 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 23 Feb 2009 19:48:07 +1300 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <4999757B.1000001@kanarip.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> <46a038f90902141402x6ef9b899x6d726bc7cb57fded@mail.gmail.com> <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> <4998C6C8.70103@kanarip.com> <46a038f90902151806h50595dd4r8152baab33bddc2b@mail.gmail.com> <4999757B.1000001@kanarip.com> Message-ID: <46a038f90902222248o436d2602oe330aeab5cde6fb6@mail.gmail.com> On Tue, Feb 17, 2009 at 3:17 AM, Jeroen van Meeuwen wrote: > Can you maybe send me a log file with both Revisor as well as YUM set to > debuglevel 9? Hi Jeroen, last week you mentioned the logs made sense... any news on this track? Did this evolve into a different thread subject and I missed it...? thanks for your help! cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kanarip at kanarip.com Mon Feb 23 12:15:49 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 23 Feb 2009 13:15:49 +0100 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <46a038f90902222248o436d2602oe330aeab5cde6fb6@mail.gmail.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> <46a038f90902141402x6ef9b899x6d726bc7cb57fded@mail.gmail.com> <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> <4998C6C8.70103@kanarip.com> <46a038f90902151806h50595dd4r8152baab33bddc2b@mail.gmail.com> <4999757B.1000001@kanarip.com> <46a038f90902222248o436d2602oe330aeab5cde6fb6@mail.gmail.com> Message-ID: <49A29375.9090709@kanarip.com> Martin Langhoff wrote: > On Tue, Feb 17, 2009 at 3:17 AM, Jeroen van Meeuwen wrote: >> Can you maybe send me a log file with both Revisor as well as YUM set to >> debuglevel 9? > > Hi Jeroen, > > last week you mentioned the logs made sense... any news on this track? > Did this evolve into a different thread subject and I missed it...? > Hi Martin, did I forget to reply with a commit code? Sorry! I did this commit http://git.fedorahosted.org/git/?p=revisor;a=commitdiff;h=c76d857046e931121ab8241a268fd921dfa8960a to prevent F9 and above to end up with no allarch packages being selected. Could you test this and see if it helps? Kind regards, Jeroen van Meeuwen -kanarip From zsethna at technisyst.com.au Tue Feb 24 00:59:31 2009 From: zsethna at technisyst.com.au (Zubin Sethna) Date: Tue, 24 Feb 2009 10:59:31 +1000 Subject: Is koji the right build tool for me? and some newbie questions Message-ID: <5E36C9576865BF46AFD1AB1A81CBF9930268C559@exchange.technisyst.com> Hi all Hope this is the correct mailing list to ask these questions. I've being looking at using koji for our in house project. After perusing the docs I have managed to set up a koji server with the web, xml-rpc, kojira and command line client components working. So now I want to do the client side configuration. Our software project is distributed as RPMs (which is what made me look at koji in the first place) and we build three site specific versions from three different branches in CVS. Reading the ServerBootstrap document on the Fedora wiki has me confused. How do I set up koji to build a set of RPMs from CVS? Our build target is RHEL 4 but so far I have not found any installable RPMs to run kojibuilder on this platform. Does anyone know where I could get a suitable RPM? To build our project we need to install a set of RPMs into the build environment that setup the libraries and header files used during the build process. How does koji handle this? Thanks Zubin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.langhoff at gmail.com Tue Feb 24 02:12:01 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 24 Feb 2009 15:12:01 +1300 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <49A29375.9090709@kanarip.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> <46a038f90902141402x6ef9b899x6d726bc7cb57fded@mail.gmail.com> <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> <4998C6C8.70103@kanarip.com> <46a038f90902151806h50595dd4r8152baab33bddc2b@mail.gmail.com> <4999757B.1000001@kanarip.com> <46a038f90902222248o436d2602oe330aeab5cde6fb6@mail.gmail.com> <49A29375.9090709@kanarip.com> Message-ID: <46a038f90902231812x7fea068du5e58aee0b512bfb7@mail.gmail.com> On Tue, Feb 24, 2009 at 1:15 AM, Jeroen van Meeuwen wrote: > did I forget to reply with a commit code? Sorry! > > I did this commit > http://git.fedorahosted.org/git/?p=revisor;a=commitdiff;h=c76d857046e931121ab8241a268fd921dfa8960a > > to prevent F9 and above to end up with no allarch packages being selected. > Could you test this and see if it helps? Works for Jerry and for me. Fantastic - thanks! Are you planning on updating the F-9 or F-11 packages with it? I built a package based on the F-9 branch branch of your git repo, and the version numbers don't like up with the latest rpm on F-9 (2.1.1-5 vs 2.1.1-7), and I think I saw a minor regresion (the ISO is called Fedora instead of OLPC School Server, .discinfo is correct however) so I'm pretty sure the RPMs in F-9 don't come from there. I was hoping to custom-build rpms based on the exact latest F-9 src plus with this cherry-picked bugfix... cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From jiteshs at marvell.com Tue Feb 24 05:32:10 2009 From: jiteshs at marvell.com (Jitesh Shah) Date: Mon, 23 Feb 2009 21:32:10 -0800 Subject: Is koji the right build tool for me? and some newbie questions In-Reply-To: <5E36C9576865BF46AFD1AB1A81CBF9930268C559@exchange.technisyst.com> References: <5E36C9576865BF46AFD1AB1A81CBF9930268C559@exchange.technisyst.com> Message-ID: <1235453046.10005.8.camel@localhost.localdomain> Hi Zubin, > > Reading the ServerBootstrap document on the Fedora wiki has me > confused. How do I set up koji to build a set of RPMs from CVS? Well, it doesn't require anything special, if you have a working instance of koji. You have to add an entry in the kojibuilder config file under "allowedSCMs", to allow the CVS checkout. and you can run a build as "koji build " You can also check out the chain builds feature. I have a feeling it might be of help to you :) > Our build target is RHEL 4 but so far I have not found any installable > RPMs to run kojibuilder on this platform. Does anyone know where I > could get a suitable RPM? Koji is a noarch pacakge. You can pick the fedora RPMs. > To build our project we need to install a set of RPMs into the build > environment that setup the libraries and header files used during the > build process. How does koji handle this? Koji will build a SRPM from the CVS checkout. Make sure you have the right entries in BuildRequires and Requires in the spec file and koji will do the rest. (Also, make sure that those RPMs are built and tagged appropriately so that koji can make a repo which can be of use to you) Jitesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From zsethna at technisyst.com.au Tue Feb 24 06:40:44 2009 From: zsethna at technisyst.com.au (Zubin Sethna) Date: Tue, 24 Feb 2009 16:40:44 +1000 Subject: Is koji the right build tool for me? and some newbie questions References: <5E36C9576865BF46AFD1AB1A81CBF9930268C559@exchange.technisyst.com> <1235453046.10005.8.camel@localhost.localdomain> Message-ID: <5E36C9576865BF46AFD1AB1A81CBF9930268C656@exchange.technisyst.com> Thanks for the response Jitesh. When I look to see what koji requires for install I get: [zsethna at einstein koji-packages]$ rpm -q --requires -p koji-1.2.0-3.fc7.noarch.rpm warning: koji-1.2.0-3.fc7.noarch.rpm: V3 DSA signature: NOKEY, key ID 4f2a6fd2 /bin/bash /usr/bin/python config(koji) = 1.2.0-3.fc7 pyOpenSSL python(abi) = 2.5 python-krbV >= 1.0.13 rpm-python rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 The problem here is python 2.5 since my build machine runs on RedHat Enterprise Linux 4 (ES) which uses an older version of python and I can't seem to find a python 2.5 RPM that will install on this OS. Also what is python(abi)? Do I have to install a full python 2.5 RPM to satisfy this dependency? Zubin _____ From: fedora-buildsys-list-bounces at redhat.com [mailto:fedora-buildsys-list-bounces at redhat.com] On Behalf Of Jitesh Shah Sent: Tuesday, 24 February 2009 3:32 PM To: Discussion of Fedora build system Subject: Re: Is koji the right build tool for me? and some newbie questions Hi Zubin, > > Reading the ServerBootstrap document on the Fedora wiki has me > confused. How do I set up koji to build a set of RPMs from CVS? Well, it doesn't require anything special, if you have a working instance of koji. You have to add an entry in the kojibuilder config file under "allowedSCMs", to allow the CVS checkout. and you can run a build as "koji build " You can also check out the chain builds feature. I have a feeling it might be of help to you :) > Our build target is RHEL 4 but so far I have not found any installable > RPMs to run kojibuilder on this platform. Does anyone know where I > could get a suitable RPM? Koji is a noarch pacakge. You can pick the fedora RPMs. > To build our project we need to install a set of RPMs into the build > environment that setup the libraries and header files used during the > build process. How does koji handle this? Koji will build a SRPM from the CVS checkout. Make sure you have the right entries in BuildRequires and Requires in the spec file and koji will do the rest. (Also, make sure that those RPMs are built and tagged appropriately so that koji can make a repo which can be of use to you) Jitesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiteshs at marvell.com Tue Feb 24 08:45:55 2009 From: jiteshs at marvell.com (Jitesh Shah) Date: Tue, 24 Feb 2009 00:45:55 -0800 Subject: Is koji the right build tool for me? and some newbie questions In-Reply-To: <5E36C9576865BF46AFD1AB1A81CBF9930268C656@exchange.technisyst.com> References: <5E36C9576865BF46AFD1AB1A81CBF9930268C559@exchange.technisyst.com> <1235453046.10005.8.camel@localhost.localdomain> <5E36C9576865BF46AFD1AB1A81CBF9930268C656@exchange.technisyst.com> Message-ID: <1235464667.12878.5.camel@localhost.localdomain> Hi Zubin, > > > The problem here is python 2.5 since my build machine runs on RedHat > Enterprise Linux 4 (ES) which uses an older version of python and I > can?t seem to find a python 2.5 RPM that will install on this OS. Well, take the git head of koji and run a "make rpm" in your environment. I am running a koji's version on python 2.4 (and it is working fine). > > > Also what is python(abi)? Do I have to install a full python 2.5 RPM > to satisfy this dependency? You can do a --nodeps as soon as your dependency reduces to only python(abi). It is provided on fedora's python RPMs. > > > > Zubin > Jitesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikem at redhat.com Tue Feb 24 16:11:48 2009 From: mikem at redhat.com (Mike McLean) Date: Tue, 24 Feb 2009 11:11:48 -0500 Subject: Is koji the right build tool for me? and some newbie questions In-Reply-To: <5E36C9576865BF46AFD1AB1A81CBF9930268C656@exchange.technisyst.com> References: <5E36C9576865BF46AFD1AB1A81CBF9930268C559@exchange.technisyst.com> <1235453046.10005.8.camel@localhost.localdomain> <5E36C9576865BF46AFD1AB1A81CBF9930268C656@exchange.technisyst.com> Message-ID: <49A41C44.10107@redhat.com> Zubin Sethna wrote: > The problem here is python 2.5 since my build machine runs on RedHat > Enterprise Linux 4 (ES) which uses an older version of python and I > can't seem to find a python 2.5 RPM that will install on this OS. > > > > Also what is python(abi)? Do I have to install a full python 2.5 RPM to > satisfy this dependency? You will need to rebuild koji under RHEL4 (or at least something more RHEL4-ish) if you want to run it on RHEL4. However.... 1) There are some build deps that are missing from RHEL4, you will need to provide them yourself (some may be in epel, others can be rebuilt for RHEL4). I know it is possible to build koji for RHEL4. But... 2) Once built, there are some additional runtime dependencies for koji, some of them indirect (koji-builder requires a recent mock, and mock requires lots of things). I think you can probably get koji-hub and kojira to run under RHEL4 without too much pain. Getting koji-builder on a RHEL4 box is going to be a world of pain (mainly because of mock and yum) -- save yourself the time and use RHEL5 for that. Deps you'll probably need: createrepo git mock python-cheetah python-elementtree python-krbV python-sqlite python-urlgrabber sqlite yum From chenbaozi at gmail.com Wed Feb 25 01:45:02 2009 From: chenbaozi at gmail.com (=?UTF-8?B?6ZmI6bKN5a2c?=) Date: Wed, 25 Feb 2009 09:45:02 +0800 Subject: attribute errors when koji login Message-ID: Hello, After fighting with my carelessness, I finished configuring koji and made it run. Thanks a lot. Now, here comes another problem. When I click the "login link" on the kojiweb, it returns an error such as below: Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py", line 213, in handler published = publish_object(req, object) File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py", line 412, in publish_object return publish_object(req,util.apply_fs_data(object, req.form, req=req)) File "/usr/lib64/python2.4/site-packages/mod_python/util.py", line 439, in apply_fs_data return object(**args) File "/usr/share/koji-web/scripts/index.py", line 155, in login _redirectBack(req, dest, forceSSL=True) File "/usr/share/koji-web/scripts/index.py", line 134, in _redirectBack page = _getBaseURL(req) + '/' + page File "/usr/share/koji-web/scripts/index.py", line 117, in _getBaseURL return req.construct_url(base) AttributeError: 'mp_request' object has no attribute 'construct_url' I searched google. There are some results, but still not clear for me. Is it a bug or something due to some wrong configuration? I was run koji on CentOS with EPEL packages. Chen Baozi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikeb at redhat.com Wed Feb 25 03:34:11 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 24 Feb 2009 22:34:11 -0500 Subject: attribute errors when koji login In-Reply-To: References: Message-ID: <49A4BC33.3040603@redhat.com> ??? wrote: > Hello, > > After fighting with my carelessness, I finished configuring koji and made it > run. Thanks a lot. > > Now, here comes another problem. When I click the "login link" on the > kojiweb, it returns an error such as below: > > Traceback (most recent call last): > > File "/usr/lib64/python2.4/site-packages/mod_python/apache.py", line 299, > in HandlerDispatch > result = object(req) > > File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py", line > 213, in handler > published = publish_object(req, object) > > File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py", line > 412, in publish_object > return publish_object(req,util.apply_fs_data(object, req.form, req=req)) > > File "/usr/lib64/python2.4/site-packages/mod_python/util.py", line 439, in > apply_fs_data > return object(**args) > > File "/usr/share/koji-web/scripts/index.py", line 155, in login > _redirectBack(req, dest, forceSSL=True) > > File "/usr/share/koji-web/scripts/index.py", line 134, in _redirectBack > page = _getBaseURL(req) + '/' + page > > File "/usr/share/koji-web/scripts/index.py", line 117, in _getBaseURL > return req.construct_url(base) > > AttributeError: 'mp_request' object has no attribute 'construct_url' > > I searched google. There are some results, but still not clear for me. Is it > a bug or something due to some wrong configuration? I was run koji on CentOS > with EPEL packages. What version of Koji are you using? That error has been fixed in Koji git for a while, and is available in the latest release, Koji 1.3.1. You'll need to run it on CentOS 5. From chenbaozi at gmail.com Wed Feb 25 11:24:45 2009 From: chenbaozi at gmail.com (=?UTF-8?B?6ZmI6bKN5a2c?=) Date: Wed, 25 Feb 2009 19:24:45 +0800 Subject: attribute errors when koji login Message-ID: Mike Bonnet wrote: > What version of Koji are you using? That error has been fixed in Koji git for a while, and is available in the latest release, Koji 1.3.1. You'll need to run it on CentOS 5. I'm using those koji-1.2.6-1.el5.noarch.rpm koji-utils-1.2.6-1.el5.noarch.rpm koji-builder-1.2.6-1.el5.noarch.rpm koji-web-1.2.6-1.el5.noarch.rpm koji-hub-1.2.6-1.el5.noarch.rpm from EPEL repository on CentOS 5.2. Maybe I should try a newer one. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at ausil.us Wed Feb 25 14:32:52 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 25 Feb 2009 08:32:52 -0600 Subject: attribute errors when koji login In-Reply-To: References: Message-ID: <200902250832.52676.dennis@ausil.us> On Wednesday 25 February 2009 05:24:45 am ??? wrote: > Mike Bonnet wrote: > > What version of Koji are you using? That error has been fixed in Koji > > git for a while, and is available in the latest release, Koji 1.3.1. > > You'll need to run it on CentOS 5. > > I'm using those koji-1.2.6-1.el5.noarch.rpm > koji-utils-1.2.6-1.el5.noarch.rpm koji-builder-1.2.6-1.el5.noarch.rpm > koji-web-1.2.6-1.el5.noarch.rpm koji-hub-1.2.6-1.el5.noarch.rpm from > EPEL repository on CentOS 5.2. Maybe I should try a newer one. 1.3.1 is in EPEL testing. I would recommend that you use it instead. Dennis From zsethna at technisyst.com.au Thu Feb 26 00:53:08 2009 From: zsethna at technisyst.com.au (Zubin Sethna) Date: Thu, 26 Feb 2009 10:53:08 +1000 Subject: Is koji the right build tool for me? and some newbie questions References: <5E36C9576865BF46AFD1AB1A81CBF9930268C559@exchange.technisyst.com> <1235453046.10005.8.camel@localhost.localdomain><5E36C9576865BF46AFD1AB1A81CBF9930268C656@exchange.technisyst.com> <49A41C44.10107@redhat.com> Message-ID: <5E36C9576865BF46AFD1AB1A81CBF9930268C905@exchange.technisyst.com> Yes, it seems too painful to setup kojibuilder on a RHEL 4 box, mainly due to the different version of python required and all the deps for createrepo and mock. It is possible but as you say too much work. My approach is to setup a 'build proxy' build host and modify my build scripts to log into the appropriate RHEL 4 box to do the actual compilation. -----Original Message----- From: fedora-buildsys-list-bounces at redhat.com [mailto:fedora-buildsys-list-bounces at redhat.com] On Behalf Of Mike McLean Sent: Wednesday, 25 February 2009 2:12 AM To: Discussion of Fedora build system Subject: Re: Is koji the right build tool for me? and some newbie questions Zubin Sethna wrote: > The problem here is python 2.5 since my build machine runs on RedHat > Enterprise Linux 4 (ES) which uses an older version of python and I > can't seem to find a python 2.5 RPM that will install on this OS. > > > > Also what is python(abi)? Do I have to install a full python 2.5 RPM to > satisfy this dependency? You will need to rebuild koji under RHEL4 (or at least something more RHEL4-ish) if you want to run it on RHEL4. However.... 1) There are some build deps that are missing from RHEL4, you will need to provide them yourself (some may be in epel, others can be rebuilt for RHEL4). I know it is possible to build koji for RHEL4. But... 2) Once built, there are some additional runtime dependencies for koji, some of them indirect (koji-builder requires a recent mock, and mock requires lots of things). I think you can probably get koji-hub and kojira to run under RHEL4 without too much pain. Getting koji-builder on a RHEL4 box is going to be a world of pain (mainly because of mock and yum) -- save yourself the time and use RHEL5 for that. Deps you'll probably need: createrepo git mock python-cheetah python-elementtree python-krbV python-sqlite python-urlgrabber sqlite yum -- Fedora-buildsys-list mailing list Fedora-buildsys-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From zsethna at technisyst.com.au Thu Feb 26 01:44:47 2009 From: zsethna at technisyst.com.au (Zubin Sethna) Date: Thu, 26 Feb 2009 11:44:47 +1000 Subject: Setting up koji to do builds Message-ID: <5E36C9576865BF46AFD1AB1A81CBF9930268C93D@exchange.technisyst.com> I've managed to set up a working koji client and server. Now I'm trying to figure out how to get it to kick of a build from our CVS repository. What is confusing me is the role of a tag in koji and if it is related to the role of a tag in CVS? Also, can the name of the Makefile koji will look in to the find the srpm target be specified? Thanks Zubin Sethna Test and Integration Engineer Sigtec Pty Ltd Brisbane QLD 4000 Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ocjtech.us Thu Feb 26 03:35:34 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 25 Feb 2009 21:35:34 -0600 Subject: Setting up koji to do builds In-Reply-To: <5E36C9576865BF46AFD1AB1A81CBF9930268C93D@exchange.technisyst.com> References: <5E36C9576865BF46AFD1AB1A81CBF9930268C93D@exchange.technisyst.com> Message-ID: <935ead450902251935i64ce2a47u429796a9ce1c350a@mail.gmail.com> On Wed, Feb 25, 2009 at 7:44 PM, Zubin Sethna wrote: > I?ve managed to set up a working koji client and server. Now I?m trying to > figure out how to get it to kick of a build from our CVS repository. What is > confusing me is the role of a tag in koji and if it is related to the role > of a tag in CVS? They are separate. Koji uses CVS tags to know which revisions of the code to build from. The other tags is Koji are used to group together packages. > Also, can the name of the Makefile koji will look in to the find the srpm > target be specified? No, koji will only run "make sources" in the checked out copy of the sources. It'd be nice to have this be configurable but that will take some code changes. -- Jeff Ollie From martin.langhoff at gmail.com Thu Feb 26 03:38:15 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 26 Feb 2009 16:38:15 +1300 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <46a038f90902231812x7fea068du5e58aee0b512bfb7@mail.gmail.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> <46a038f90902141402x6ef9b899x6d726bc7cb57fded@mail.gmail.com> <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> <4998C6C8.70103@kanarip.com> <46a038f90902151806h50595dd4r8152baab33bddc2b@mail.gmail.com> <4999757B.1000001@kanarip.com> <46a038f90902222248o436d2602oe330aeab5cde6fb6@mail.gmail.com> <49A29375.9090709@kanarip.com> <46a038f90902231812x7fea068du5e58aee0b512bfb7@mail.gmail.com> Message-ID: <46a038f90902251938n6934e399x7e5f527982d9035@mail.gmail.com> On Tue, Feb 24, 2009 at 3:12 PM, Martin Langhoff wrote: > Are you planning on updating the F-9 or F-11 packages with it? Hi Jeroen, - is there a revision coming on the F-9 or F10 branches? - can you check whether the F-9 package (2.1.1-7) matches what's in git? From what I can see, it doesn't, so I can't build a local rvisor pkg I can trust :-/ ... cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kanarip at kanarip.com Thu Feb 26 08:46:27 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 26 Feb 2009 09:46:27 +0100 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <46a038f90902251938n6934e399x7e5f527982d9035@mail.gmail.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> <46a038f90902141402x6ef9b899x6d726bc7cb57fded@mail.gmail.com> <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> <4998C6C8.70103@kanarip.com> <46a038f90902151806h50595dd4r8152baab33bddc2b@mail.gmail.com> <4999757B.1000001@kanarip.com> <46a038f90902222248o436d2602oe330aeab5cde6fb6@mail.gmail.com> <49A29375.9090709@kanarip.com> <46a038f90902231812x7fea068du5e58aee0b512bfb7@mail.gmail.com> <46a038f90902251938n6934e399x7e5f527982d9035@mail.gmail.com> Message-ID: <49A656E3.9060304@kanarip.com> Martin Langhoff wrote: > On Tue, Feb 24, 2009 at 3:12 PM, Martin Langhoff > wrote: >> Are you planning on updating the F-9 or F-11 packages with it? > > Hi Jeroen, > > - is there a revision coming on the F-9 or F10 branches? I'm planning a release for F-10. > - can you check whether the F-9 package (2.1.1-7) matches what's in > git? From what I can see, it doesn't, so I can't build a local rvisor > pkg I can trust :-/ ... > The packages releases are always behind the GIT repo, because the packages get created from what is in the GIT repo (at some point). If I gave you some 2.1.4 revisor packages to test on Fedora 9 (I'm not sure they work but there have been no major changes), are you able to test them? Kind regards, Jeroen From jeff at ocjtech.us Thu Feb 26 15:32:00 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 26 Feb 2009 09:32:00 -0600 Subject: Add a "download-build" command to Makefile.common Message-ID: <935ead450902260732o7f0714dau846f0ad3f9f6ec95@mail.gmail.com> Here's a patch that adds a "download-build" command to Makefile.common -- Jeff Ollie -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-makefile-common-download-build.patch Type: application/octet-stream Size: 1949 bytes Desc: not available URL: From notting at redhat.com Thu Feb 26 16:08:36 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Feb 2009 11:08:36 -0500 Subject: Add a "download-build" command to Makefile.common In-Reply-To: <935ead450902260732o7f0714dau846f0ad3f9f6ec95@mail.gmail.com> References: <935ead450902260732o7f0714dau846f0ad3f9f6ec95@mail.gmail.com> Message-ID: <20090226160836.GC15490@nostromo.devel.redhat.com> Jeffrey Ollie (jeff at ocjtech.us) said: > Here's a patch that adds a "download-build" command to Makefile.common Not that the patch looks incorrect, but what's the usage case for this? Bill From thatch65 at gmail.com Thu Feb 26 16:31:39 2009 From: thatch65 at gmail.com (Thomas Hatch) Date: Thu, 26 Feb 2009 09:31:39 -0700 Subject: kojira repo generation Message-ID: <70d60c3c0902260831h43f999bdrdc324aa70d035c06@mail.gmail.com> We have recently set up a koji server and I am having trouble with tasks completing. I have been waiting for some time (about an hour now) on kojira to generate a new repo for a build tag. I have all of the components set up, and to my konwledge the kojira user has sufficent privileges. I also have properly configued package access via koji-web. Just wondering what else I need to check. -Thanks -Thomas S Hatch Backcountry.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ocjtech.us Thu Feb 26 16:37:44 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 26 Feb 2009 10:37:44 -0600 Subject: kojira repo generation In-Reply-To: <70d60c3c0902260831h43f999bdrdc324aa70d035c06@mail.gmail.com> References: <70d60c3c0902260831h43f999bdrdc324aa70d035c06@mail.gmail.com> Message-ID: <935ead450902260837w577e9a3j8ab168b28c6dc0f8@mail.gmail.com> On Thu, Feb 26, 2009 at 10:31 AM, Thomas Hatch wrote: > We have recently set up a koji server and I am having trouble with tasks > completing.? I have been waiting for some time (about an hour now) on kojira > to generate a new repo for a build tag. > I have all of the components set up, and to my konwledge the kojira user has > sufficent privileges.? I also have properly configued package access via > koji-web. Do you have a host assigned to the createrepo channel? koji list-hosts --channel=createrepo koji add-host-to-channel createrepo Also, the koji 1.3 has a "regen-repo" command that will force a rebuild of a repo but you'll still need a host assigned to the createrepo channel. -- Jeff Ollie From thatch65 at gmail.com Thu Feb 26 17:29:55 2009 From: thatch65 at gmail.com (Thomas Hatch) Date: Thu, 26 Feb 2009 10:29:55 -0700 Subject: kojira repo generation In-Reply-To: <935ead450902260837w577e9a3j8ab168b28c6dc0f8@mail.gmail.com> References: <70d60c3c0902260831h43f999bdrdc324aa70d035c06@mail.gmail.com> <935ead450902260837w577e9a3j8ab168b28c6dc0f8@mail.gmail.com> Message-ID: <70d60c3c0902260929n12b7bc2eode07ac46976cd3ea@mail.gmail.com> I run "koji list-hosts --channel=createrepo" and get: Hostname Enb Rdy Load/Cap Arches Last Update koji.bcinfra.net Y N 0.0/8.0 i386,x86_64 - Seems it is enabled and in the channel, but not ready? On Thu, Feb 26, 2009 at 9:37 AM, Jeffrey Ollie wrote: > On Thu, Feb 26, 2009 at 10:31 AM, Thomas Hatch wrote: > > We have recently set up a koji server and I am having trouble with tasks > > completing. I have been waiting for some time (about an hour now) on > kojira > > to generate a new repo for a build tag. > > I have all of the components set up, and to my konwledge the kojira user > has > > sufficent privileges. I also have properly configued package access via > > koji-web. > > Do you have a host assigned to the createrepo channel? > > koji list-hosts --channel=createrepo > koji add-host-to-channel createrepo > > Also, the koji 1.3 has a "regen-repo" command that will force a > rebuild of a repo but you'll still need a host assigned to the > createrepo channel. > > -- > Jeff Ollie > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ocjtech.us Thu Feb 26 17:32:56 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 26 Feb 2009 11:32:56 -0600 Subject: kojira repo generation In-Reply-To: <70d60c3c0902260929n12b7bc2eode07ac46976cd3ea@mail.gmail.com> References: <70d60c3c0902260831h43f999bdrdc324aa70d035c06@mail.gmail.com> <935ead450902260837w577e9a3j8ab168b28c6dc0f8@mail.gmail.com> <70d60c3c0902260929n12b7bc2eode07ac46976cd3ea@mail.gmail.com> Message-ID: <935ead450902260932u636367a7jb466840e562bd4c8@mail.gmail.com> On Thu, Feb 26, 2009 at 11:29 AM, Thomas Hatch wrote: > I run "koji list-hosts --channel=createrepo" and get: > > Hostname???????????????????? Enb Rdy Load/Cap Arches?????????? Last Update > koji.bcinfra.net???????????? Y?? N??? 0.0/8.0 i386,x86_64????? - > > Seems it is enabled and in the channel, but not ready? Is kojid running? That's the service that does the actual building... -- Jeff Ollie Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From thatch65 at gmail.com Thu Feb 26 17:51:14 2009 From: thatch65 at gmail.com (Thomas Hatch) Date: Thu, 26 Feb 2009 10:51:14 -0700 Subject: kojira repo generation In-Reply-To: <935ead450902260932u636367a7jb466840e562bd4c8@mail.gmail.com> References: <70d60c3c0902260831h43f999bdrdc324aa70d035c06@mail.gmail.com> <935ead450902260837w577e9a3j8ab168b28c6dc0f8@mail.gmail.com> <70d60c3c0902260929n12b7bc2eode07ac46976cd3ea@mail.gmail.com> <935ead450902260932u636367a7jb466840e562bd4c8@mail.gmail.com> Message-ID: <70d60c3c0902260951o5654ce9ga7d59977f1f53593@mail.gmail.com> I keep having problems with it telling me the system is locked until I run a restart, but service kojid status keeps returning the same error service kojid status kojid dead but subsys locked kojid also seems to be dying but the logs yield no real data I think I have a problem in my configs: kojid.conf: [kojid] ; The number of seconds to sleep between tasks ; sleeptime=15 ; The maximum number of jobs that kojid will handle at a time ; maxjobs=10 ; The minimum amount of free space (in MBs) required for each build root ; minspace=8192 ; The directory root where work data can be found from the koji hub ; topdir=/mnt/koji ; The directory root for temporary storage workdir=/tmp/koji ; The directory root for mock mockdir=/var/lib/mock ; The user to run as when doing builds mockuser=kojibuilder ; The vendor to use in rpm headers ; vendor=Koji ; The packager to use in rpm headers ; packager=Koji ; The _host string to use in mock ; mockhost=koji-linux-gnu ; The URL for the xmlrpc server server=http://sunlight.pp.bcinfra.net/kojihub user=koji.bcinfra.net ; The URL for the packages tree pkgurl=http://sunlight.pp.bcinfra.net/pkg/packages ; A space-separated list of hostname:repository[:use_common] tuples that kojid is authorized to checkout from (no quotes). ; Wildcards (as supported by fnmatch) are allowed. ; If use_common is specified and is one of "false", "no", or "0" (without quotes), then kojid will not attempt to checkout ; a common/ dir when checking out sources from the source control system. Otherwise, it will attempt to checkout a common/ ; dir, and will raise an exception if it cannot. ;allowed_scms=scm.example.com:/cvs/example git.example.org:/example svn.example.org:/users/*:no ; The mail host to use for sending email notifications smtphost=sunlight.pp.bcinfra.net ; The From address used when sending email notifications from_addr=Koji Build System ;configuration for SSL athentication ;client certificate cert = /etc/pki/koji/kojibuilder1.pem ;certificate of the CA that issued the client certificate ca = /etc/pki/koji/koji_ca_cert.crt ;certificate of the CA that issued the HTTP server certificate serverca = /etc/pki/koji/koji_ca_cert.crt On Thu, Feb 26, 2009 at 10:32 AM, Jeffrey Ollie wrote: > On Thu, Feb 26, 2009 at 11:29 AM, Thomas Hatch wrote: > > I run "koji list-hosts --channel=createrepo" and get: > > > > Hostname Enb Rdy Load/Cap Arches Last > Update > > koji.bcinfra.net Y N 0.0/8.0 i386,x86_64 - > > > > Seems it is enabled and in the channel, but not ready? > > Is kojid running? That's the service that does the actual building... > > -- > Jeff Ollie > Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at ausil.us Thu Feb 26 17:57:20 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 26 Feb 2009 11:57:20 -0600 Subject: kojira repo generation In-Reply-To: <70d60c3c0902260951o5654ce9ga7d59977f1f53593@mail.gmail.com> References: <70d60c3c0902260831h43f999bdrdc324aa70d035c06@mail.gmail.com> <935ead450902260932u636367a7jb466840e562bd4c8@mail.gmail.com> <70d60c3c0902260951o5654ce9ga7d59977f1f53593@mail.gmail.com> Message-ID: <200902261157.24412.dennis@ausil.us> On Thursday 26 February 2009 11:51:14 am Thomas Hatch wrote: > I keep having problems with it telling me the system is locked until I run > a restart, but service kojid status keeps returning the same error > > ; The URL for the xmlrpc server > server=http://sunlight.pp.bcinfra.net/kojihub > > user=koji.bcinfra.net do you have this same user defined elsewhere? only one session per uer can be active. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mikeb at redhat.com Thu Feb 26 17:59:21 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 26 Feb 2009 12:59:21 -0500 Subject: kojira repo generation In-Reply-To: <70d60c3c0902260951o5654ce9ga7d59977f1f53593@mail.gmail.com> References: <70d60c3c0902260831h43f999bdrdc324aa70d035c06@mail.gmail.com> <935ead450902260837w577e9a3j8ab168b28c6dc0f8@mail.gmail.com> <70d60c3c0902260929n12b7bc2eode07ac46976cd3ea@mail.gmail.com> <935ead450902260932u636367a7jb466840e562bd4c8@mail.gmail.com> <70d60c3c0902260951o5654ce9ga7d59977f1f53593@mail.gmail.com> Message-ID: <49A6D879.4050901@redhat.com> Thomas Hatch wrote: > I keep having problems with it telling me the system is locked until I run a > restart, but service kojid status keeps returning the same error > > service kojid status > kojid dead but subsys locked > > kojid also seems to be dying but the logs yield no real data > > I think I have a problem in my configs: What is the output of openssl x509 -noout -subject -in /etc/pki/koji/kojibuilder1.pem The CN component needs to match the hostname you added with "koji add-host", in your case koji.bcinfra.net. Also, that same certificate may not be used to authenticate any other services or users to the system. You can also run /usr/sbin/kojid --force-lock --verbose --fg as root to run kojid in the foreground and see what errors are reported. > kojid.conf: > > [kojid] > ; The number of seconds to sleep between tasks > ; sleeptime=15 > > ; The maximum number of jobs that kojid will handle at a time > ; maxjobs=10 > > ; The minimum amount of free space (in MBs) required for each build root > ; minspace=8192 > > ; The directory root where work data can be found from the koji hub > ; topdir=/mnt/koji > > ; The directory root for temporary storage > workdir=/tmp/koji > > ; The directory root for mock > mockdir=/var/lib/mock > > ; The user to run as when doing builds > mockuser=kojibuilder > > ; The vendor to use in rpm headers > ; vendor=Koji > > ; The packager to use in rpm headers > ; packager=Koji > > ; The _host string to use in mock > ; mockhost=koji-linux-gnu > > ; The URL for the xmlrpc server > server=http://sunlight.pp.bcinfra.net/kojihub > > user=koji.bcinfra.net > > ; The URL for the packages tree > pkgurl=http://sunlight.pp.bcinfra.net/pkg/packages > > ; A space-separated list of hostname:repository[:use_common] tuples that > kojid is authorized to checkout from (no quotes). > ; Wildcards (as supported by fnmatch) are allowed. > ; If use_common is specified and is one of "false", "no", or "0" (without > quotes), then kojid will not attempt to checkout > ; a common/ dir when checking out sources from the source control system. > Otherwise, it will attempt to checkout a common/ > ; dir, and will raise an exception if it cannot. > ;allowed_scms=scm.example.com:/cvs/example git.example.org:/example > svn.example.org:/users/*:no > > ; The mail host to use for sending email notifications > smtphost=sunlight.pp.bcinfra.net > > ; The From address used when sending email notifications > from_addr=Koji Build System > > ;configuration for SSL athentication > > ;client certificate > cert = /etc/pki/koji/kojibuilder1.pem > > ;certificate of the CA that issued the client certificate > ca = /etc/pki/koji/koji_ca_cert.crt > > ;certificate of the CA that issued the HTTP server certificate > serverca = /etc/pki/koji/koji_ca_cert.crt > > > > > > > On Thu, Feb 26, 2009 at 10:32 AM, Jeffrey Ollie wrote: > >> On Thu, Feb 26, 2009 at 11:29 AM, Thomas Hatch wrote: >>> I run "koji list-hosts --channel=createrepo" and get: >>> >>> Hostname Enb Rdy Load/Cap Arches Last >> Update >>> koji.bcinfra.net Y N 0.0/8.0 i386,x86_64 - >>> >>> Seems it is enabled and in the channel, but not ready? >> Is kojid running? That's the service that does the actual building... >> >> -- >> Jeff Ollie >> Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" >> >> -- >> Fedora-buildsys-list mailing list >> Fedora-buildsys-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list >> > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From thatch65 at gmail.com Thu Feb 26 18:06:04 2009 From: thatch65 at gmail.com (Thomas Hatch) Date: Thu, 26 Feb 2009 11:06:04 -0700 Subject: kojira repo generation In-Reply-To: <49A6D879.4050901@redhat.com> References: <70d60c3c0902260831h43f999bdrdc324aa70d035c06@mail.gmail.com> <935ead450902260837w577e9a3j8ab168b28c6dc0f8@mail.gmail.com> <70d60c3c0902260929n12b7bc2eode07ac46976cd3ea@mail.gmail.com> <935ead450902260932u636367a7jb466840e562bd4c8@mail.gmail.com> <70d60c3c0902260951o5654ce9ga7d59977f1f53593@mail.gmail.com> <49A6D879.4050901@redhat.com> Message-ID: <70d60c3c0902261006x16553ab4w9001697350ece28f@mail.gmail.com> Does the CN component in the .pem need to be a fqdn? And the CN is koji (I thought it needed to be the auth user) Right now I am under the impression that the user in kojid.conf needs to be a fqdn and that the CN in the .pem file needs to match, is this correct? # /usr/sbin/kojid --force-lock --verbose --fg 2009-02-26 11:01:51,706 [INFO] {4098} koji.build:66 Starting up Traceback (most recent call last): File "/usr/sbin/kojid", line 2730, in ? main() File "/usr/sbin/kojid", line 67, in main tm = TaskManager() File "/usr/sbin/kojid", line 530, in __init__ self.host_id = session.host.getID() File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1133, in __call__ return self.__func(self.__name,args,opts) File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1378, in _callMethod raise err koji.AuthError: No host specified On Thu, Feb 26, 2009 at 10:59 AM, Mike Bonnet wrote: > Thomas Hatch wrote: > > I keep having problems with it telling me the system is locked until I > run a > > restart, but service kojid status keeps returning the same error > > > > service kojid status > > kojid dead but subsys locked > > > > kojid also seems to be dying but the logs yield no real data > > > > I think I have a problem in my configs: > > What is the output of > > openssl x509 -noout -subject -in /etc/pki/koji/kojibuilder1.pem > > The CN component needs to match the hostname you added with "koji > add-host", in your case koji.bcinfra.net. Also, that same certificate > may not be used to authenticate any other services or users to the system. > > You can also run > > /usr/sbin/kojid --force-lock --verbose --fg > > as root to run kojid in the foreground and see what errors are reported. > > > kojid.conf: > > > > [kojid] > > ; The number of seconds to sleep between tasks > > ; sleeptime=15 > > > > ; The maximum number of jobs that kojid will handle at a time > > ; maxjobs=10 > > > > ; The minimum amount of free space (in MBs) required for each build root > > ; minspace=8192 > > > > ; The directory root where work data can be found from the koji hub > > ; topdir=/mnt/koji > > > > ; The directory root for temporary storage > > workdir=/tmp/koji > > > > ; The directory root for mock > > mockdir=/var/lib/mock > > > > ; The user to run as when doing builds > > mockuser=kojibuilder > > > > ; The vendor to use in rpm headers > > ; vendor=Koji > > > > ; The packager to use in rpm headers > > ; packager=Koji > > > > ; The _host string to use in mock > > ; mockhost=koji-linux-gnu > > > > ; The URL for the xmlrpc server > > server=http://sunlight.pp.bcinfra.net/kojihub > > > > user=koji.bcinfra.net > > > > ; The URL for the packages tree > > pkgurl=http://sunlight.pp.bcinfra.net/pkg/packages > > > > ; A space-separated list of hostname:repository[:use_common] tuples that > > kojid is authorized to checkout from (no quotes). > > ; Wildcards (as supported by fnmatch) are allowed. > > ; If use_common is specified and is one of "false", "no", or "0" (without > > quotes), then kojid will not attempt to checkout > > ; a common/ dir when checking out sources from the source control system. > > Otherwise, it will attempt to checkout a common/ > > ; dir, and will raise an exception if it cannot. > > ;allowed_scms=scm.example.com:/cvs/example git.example.org:/example > > svn.example.org:/users/*:no > > > > ; The mail host to use for sending email notifications > > smtphost=sunlight.pp.bcinfra.net > > > > ; The From address used when sending email notifications > > from_addr=Koji Build System > > > > ;configuration for SSL athentication > > > > ;client certificate > > cert = /etc/pki/koji/kojibuilder1.pem > > > > ;certificate of the CA that issued the client certificate > > ca = /etc/pki/koji/koji_ca_cert.crt > > > > ;certificate of the CA that issued the HTTP server certificate > > serverca = /etc/pki/koji/koji_ca_cert.crt > > > > > > > > > > > > > > On Thu, Feb 26, 2009 at 10:32 AM, Jeffrey Ollie wrote: > > > >> On Thu, Feb 26, 2009 at 11:29 AM, Thomas Hatch > wrote: > >>> I run "koji list-hosts --channel=createrepo" and get: > >>> > >>> Hostname Enb Rdy Load/Cap Arches Last > >> Update > >>> koji.bcinfra.net Y N 0.0/8.0 i386,x86_64 - > >>> > >>> Seems it is enabled and in the channel, but not ready? > >> Is kojid running? That's the service that does the actual building... > >> > >> -- > >> Jeff Ollie > >> Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" > >> > >> -- > >> Fedora-buildsys-list mailing list > >> Fedora-buildsys-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > >> > > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thatch65 at gmail.com Thu Feb 26 18:25:51 2009 From: thatch65 at gmail.com (Thomas Hatch) Date: Thu, 26 Feb 2009 11:25:51 -0700 Subject: kojira repo generation In-Reply-To: <70d60c3c0902261006x16553ab4w9001697350ece28f@mail.gmail.com> References: <70d60c3c0902260831h43f999bdrdc324aa70d035c06@mail.gmail.com> <935ead450902260837w577e9a3j8ab168b28c6dc0f8@mail.gmail.com> <70d60c3c0902260929n12b7bc2eode07ac46976cd3ea@mail.gmail.com> <935ead450902260932u636367a7jb466840e562bd4c8@mail.gmail.com> <70d60c3c0902260951o5654ce9ga7d59977f1f53593@mail.gmail.com> <49A6D879.4050901@redhat.com> <70d60c3c0902261006x16553ab4w9001697350ece28f@mail.gmail.com> Message-ID: <70d60c3c0902261025l22de1339q39dd0203d86c3d8a@mail.gmail.com> Thanks, I got it! I had to make a new .pem with the proper information. On Thu, Feb 26, 2009 at 11:06 AM, Thomas Hatch wrote: > Does the CN component in the .pem need to be a fqdn? > > And the CN is koji (I thought it needed to be the auth user) > > Right now I am under the impression that the user in kojid.conf needs to be > a fqdn and that the CN in the .pem file needs to match, is this correct? > > # /usr/sbin/kojid --force-lock --verbose --fg > > 2009-02-26 11:01:51,706 [INFO] {4098} koji.build:66 Starting up > Traceback (most recent call last): > File "/usr/sbin/kojid", line 2730, in ? > main() > File "/usr/sbin/kojid", line 67, in main > tm = TaskManager() > File "/usr/sbin/kojid", line 530, in __init__ > self.host_id = session.host.getID() > File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1133, in > __call__ > return self.__func(self.__name,args,opts) > File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1378, in > _callMethod > raise err > koji.AuthError: No host specified > > > > > On Thu, Feb 26, 2009 at 10:59 AM, Mike Bonnet wrote: > >> Thomas Hatch wrote: >> > I keep having problems with it telling me the system is locked until I >> run a >> > restart, but service kojid status keeps returning the same error >> > >> > service kojid status >> > kojid dead but subsys locked >> > >> > kojid also seems to be dying but the logs yield no real data >> > >> > I think I have a problem in my configs: >> >> What is the output of >> >> openssl x509 -noout -subject -in /etc/pki/koji/kojibuilder1.pem >> >> The CN component needs to match the hostname you added with "koji >> add-host", in your case koji.bcinfra.net. Also, that same certificate >> may not be used to authenticate any other services or users to the system. >> >> You can also run >> >> /usr/sbin/kojid --force-lock --verbose --fg >> >> as root to run kojid in the foreground and see what errors are reported. >> >> > kojid.conf: >> > >> > [kojid] >> > ; The number of seconds to sleep between tasks >> > ; sleeptime=15 >> > >> > ; The maximum number of jobs that kojid will handle at a time >> > ; maxjobs=10 >> > >> > ; The minimum amount of free space (in MBs) required for each build root >> > ; minspace=8192 >> > >> > ; The directory root where work data can be found from the koji hub >> > ; topdir=/mnt/koji >> > >> > ; The directory root for temporary storage >> > workdir=/tmp/koji >> > >> > ; The directory root for mock >> > mockdir=/var/lib/mock >> > >> > ; The user to run as when doing builds >> > mockuser=kojibuilder >> > >> > ; The vendor to use in rpm headers >> > ; vendor=Koji >> > >> > ; The packager to use in rpm headers >> > ; packager=Koji >> > >> > ; The _host string to use in mock >> > ; mockhost=koji-linux-gnu >> > >> > ; The URL for the xmlrpc server >> > server=http://sunlight.pp.bcinfra.net/kojihub >> > >> > user=koji.bcinfra.net >> > >> > ; The URL for the packages tree >> > pkgurl=http://sunlight.pp.bcinfra.net/pkg/packages >> > >> > ; A space-separated list of hostname:repository[:use_common] tuples that >> > kojid is authorized to checkout from (no quotes). >> > ; Wildcards (as supported by fnmatch) are allowed. >> > ; If use_common is specified and is one of "false", "no", or "0" >> (without >> > quotes), then kojid will not attempt to checkout >> > ; a common/ dir when checking out sources from the source control >> system. >> > Otherwise, it will attempt to checkout a common/ >> > ; dir, and will raise an exception if it cannot. >> > ;allowed_scms=scm.example.com:/cvs/example git.example.org:/example >> > svn.example.org:/users/*:no >> > >> > ; The mail host to use for sending email notifications >> > smtphost=sunlight.pp.bcinfra.net >> > >> > ; The From address used when sending email notifications >> > from_addr=Koji Build System >> > >> > ;configuration for SSL athentication >> > >> > ;client certificate >> > cert = /etc/pki/koji/kojibuilder1.pem >> > >> > ;certificate of the CA that issued the client certificate >> > ca = /etc/pki/koji/koji_ca_cert.crt >> > >> > ;certificate of the CA that issued the HTTP server certificate >> > serverca = /etc/pki/koji/koji_ca_cert.crt >> > >> > >> > >> > >> > >> > >> > On Thu, Feb 26, 2009 at 10:32 AM, Jeffrey Ollie >> wrote: >> > >> >> On Thu, Feb 26, 2009 at 11:29 AM, Thomas Hatch >> wrote: >> >>> I run "koji list-hosts --channel=createrepo" and get: >> >>> >> >>> Hostname Enb Rdy Load/Cap Arches Last >> >> Update >> >>> koji.bcinfra.net Y N 0.0/8.0 i386,x86_64 - >> >>> >> >>> Seems it is enabled and in the channel, but not ready? >> >> Is kojid running? That's the service that does the actual building... >> >> >> >> -- >> >> Jeff Ollie >> >> Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" >> >> >> >> -- >> >> Fedora-buildsys-list mailing list >> >> Fedora-buildsys-list at redhat.com >> >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list >> >> >> > >> > >> > ------------------------------------------------------------------------ >> > >> > -- >> > Fedora-buildsys-list mailing list >> > Fedora-buildsys-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list >> >> -- >> Fedora-buildsys-list mailing list >> Fedora-buildsys-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.langhoff at gmail.com Thu Feb 26 20:01:03 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 27 Feb 2009 09:01:03 +1300 Subject: Revisor (or Anaconda?) spin - unable to install on i586 In-Reply-To: <49A656E3.9060304@kanarip.com> References: <46a038f90902141358h4ac9c4a9sad175a6147a968dc@mail.gmail.com> <46a038f90902151601g54ca414dn66de3a4bef214f39@mail.gmail.com> <4998C6C8.70103@kanarip.com> <46a038f90902151806h50595dd4r8152baab33bddc2b@mail.gmail.com> <4999757B.1000001@kanarip.com> <46a038f90902222248o436d2602oe330aeab5cde6fb6@mail.gmail.com> <49A29375.9090709@kanarip.com> <46a038f90902231812x7fea068du5e58aee0b512bfb7@mail.gmail.com> <46a038f90902251938n6934e399x7e5f527982d9035@mail.gmail.com> <49A656E3.9060304@kanarip.com> Message-ID: <46a038f90902261201u2d67497cv6e6c303f3810ad20@mail.gmail.com> On Thu, Feb 26, 2009 at 9:46 PM, Jeroen van Meeuwen wrote: > If I gave you some 2.1.4 revisor packages to test on Fedora 9 (I'm not sure > they work but there have been no major changes), are you able to test them? Yes. My only 'compat' concern is with anaconda. If they expect anaconda smarts that aren't there... m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff