From sergio at sergiomb.no-ip.org Thu Nov 1 15:09:32 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Thu, 01 Nov 2007 15:09:32 +0000 Subject: [Patch] for pungi-1.1.8-1.fc8 build on fedora 7 Message-ID: <1193929772.3053.5.camel@localhost.localdomain> Hi, To fix this error: Pungi.Gather:INFO: Finished downloading packages. Traceback (most recent call last): File "/usr/bin/pungi", line 178, in main() File "/usr/bin/pungi", line 68, in main mygather.makeCompsFile() File "/usr/lib/python2.5/site-packages/pypungi/gather.py", line 397, in makeCompsFile ourcomps.writelines(compslines[start:end]) UnboundLocalError: local variable 'start' referenced before assignment -------------- next part -------------- A non-text attachment was scrubbed... Name: gather.py.patch Type: text/x-patch Size: 578 bytes Desc: not available URL: From mikeb at redhat.com Mon Nov 5 23:56:36 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 05 Nov 2007 18:56:36 -0500 Subject: RFC - Patch - koji SCM generalization In-Reply-To: <1193166878.18349.121.camel@rxm-581b.stl.gtri.gatech.edu> References: <1193163187.18349.96.camel@rxm-581b.stl.gtri.gatech.edu> <1193164256.4427.11.camel@burren.boston.redhat.com> <1193166878.18349.121.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <1194306996.15920.23.camel@burren.boston.redhat.com> On Tue, 2007-10-23 at 15:14 -0400, rob myers wrote: > On Tue, 2007-10-23 at 14:30 -0400, Mike Bonnet wrote: > > On Tue, 2007-10-23 at 14:13 -0400, rob myers wrote: > > > attached is a patch that attempts to generalize checking out the > > > components used to build an SRPM. this patch supports CVS, GIT, and > > > SVN, but only CVS and SVN have been tested. the idea is to provide the > > > infrastructure for different SCM systems to be configured at run-time so > > > that users can choose their favorite system. > > > > It would also be nice if rather than assuming the existence of the > > "common/" module and hard-coding the "make srpm" command, there was some > > way to specify what modules were necessary to checkout, and what command > > to run to create a srpm. This should probably be configurable > > per-repository. It might make sense to add a new database table to > > store this information in a more flexible way than possible with the > > config files. > > the existing design is (currently) sufficient for my needs. what you > describe is more flexible and is probably a better design, but is it > needed? > > > However, this is a great start. I'm going to review the patch more > > carefully, and I'll see about merging it soon (after possibly removing > > the scmtype config option I mentioned earlier). > > thanks for your feedback, and remove cruft as necessary. :) The patch has been committed to Koji: http://git.fedoraproject.org/?p=hosted/koji;a=commit;h=27ac942683d8bbfd28c3b6bbc8475b4cbada0c2c I made some pretty significant changes to make the SCM class more object-y, remove some code duplication, make it more configurable at runtime, etc., but the framework setup in the original patch is there. I've tested it fairly completely and everything seems to be working as expected. Note that when using the "+ssh://" access methods, you're responsible for getting the required login credentials (host keys, private keys, Kerberos tickets) into the right place on the builders yourself. Thanks for the patch Rob, and if you have any other suggestions or improvements, please let me know. Keep those patches coming! :) From rob.myers at gtri.gatech.edu Tue Nov 6 16:16:49 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Tue, 06 Nov 2007 11:16:49 -0500 Subject: RFC - Patch - koji SCM generalization In-Reply-To: <1194306996.15920.23.camel@burren.boston.redhat.com> References: <1193163187.18349.96.camel@rxm-581b.stl.gtri.gatech.edu> <1193164256.4427.11.camel@burren.boston.redhat.com> <1193166878.18349.121.camel@rxm-581b.stl.gtri.gatech.edu> <1194306996.15920.23.camel@burren.boston.redhat.com> Message-ID: <1194365809.18349.238.camel@rxm-581b.stl.gtri.gatech.edu> On Mon, 2007-11-05 at 18:56 -0500, Mike Bonnet wrote: > > The patch has been committed to Koji: > > http://git.fedoraproject.org/?p=hosted/koji;a=commit;h=27ac942683d8bbfd28c3b6bbc8475b4cbada0c2c > > I made some pretty significant changes to make the SCM class more > object-y, remove some code duplication, make it more configurable at > runtime, etc., but the framework setup in the original patch is there. > I've tested it fairly completely and everything seems to be working as > expected. Note that when using the "+ssh://" access methods, you're > responsible for getting the required login credentials (host keys, > private keys, Kerberos tickets) into the right place on the builders > yourself. mike- your patch is much tidier than mine, thanks for fixing it up! i really like the removal of scmtype from the configuration file. i'm mixed on the removal of scmusername because i'm not sure that koji clients should specify the username used by the koji builder to perform ssh checkouts. however, while i thought it worth pointing out, it does not seem too big a deal to disclose this username. i did some testing with my svn+ssh repository and found the patch below necessary- it creates ../common only if it does not already exist. diff --git a/builder/kojid b/builder/kojid index b436a19..5c5d665 100755 --- a/builder/kojid +++ b/builder/kojid @@ -2506,7 +2507,8 @@ class SCM(object): (self.scmtype, ' '.join(update_checkout_cmd), os.path.basename(logfile)) # Required by Dist CVS layout - os.symlink('%s/common' % scmdir, '%s/../common' % sourcedir) + if not os.path.exists('%s/../common' % sourcedir): + os.symlink('%s/common' % scmdir, '%s/../common' % sourcedir) def get_options(): """process options from command line and config file""" thanks again for adding this functionality to koji. :) rob. From mikeb at redhat.com Tue Nov 6 20:33:45 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 06 Nov 2007 15:33:45 -0500 Subject: RFC - Patch - koji SCM generalization In-Reply-To: <1194365809.18349.238.camel@rxm-581b.stl.gtri.gatech.edu> References: <1193163187.18349.96.camel@rxm-581b.stl.gtri.gatech.edu> <1193164256.4427.11.camel@burren.boston.redhat.com> <1193166878.18349.121.camel@rxm-581b.stl.gtri.gatech.edu> <1194306996.15920.23.camel@burren.boston.redhat.com> <1194365809.18349.238.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <1194381225.20536.2.camel@localhost.localdomain> On Tue, 2007-11-06 at 11:16 -0500, rob myers wrote: > On Mon, 2007-11-05 at 18:56 -0500, Mike Bonnet wrote: > > > > The patch has been committed to Koji: > > > > http://git.fedoraproject.org/?p=hosted/koji;a=commit;h=27ac942683d8bbfd28c3b6bbc8475b4cbada0c2c > > > > I made some pretty significant changes to make the SCM class more > > object-y, remove some code duplication, make it more configurable at > > runtime, etc., but the framework setup in the original patch is there. > > I've tested it fairly completely and everything seems to be working as > > expected. Note that when using the "+ssh://" access methods, you're > > responsible for getting the required login credentials (host keys, > > private keys, Kerberos tickets) into the right place on the builders > > yourself. > > mike- > > your patch is much tidier than mine, thanks for fixing it up! i really > like the removal of scmtype from the configuration file. i'm mixed on > the removal of scmusername because i'm not sure that koji clients should > specify the username used by the koji builder to perform ssh checkouts. > however, while i thought it worth pointing out, it does not seem too big > a deal to disclose this username. > > i did some testing with my svn+ssh repository and found the patch below > necessary- it creates ../common only if it does not already exist. > > diff --git a/builder/kojid b/builder/kojid > index b436a19..5c5d665 100755 > --- a/builder/kojid > +++ b/builder/kojid > @@ -2506,7 +2507,8 @@ class SCM(object): > (self.scmtype, ' '.join(update_checkout_cmd), > os.path.basename(logfile)) > > # Required by Dist CVS layout > - os.symlink('%s/common' % scmdir, '%s/../common' % sourcedir) > + if not os.path.exists('%s/../common' % sourcedir): > + os.symlink('%s/common' % scmdir, '%s/../common' % > sourcedir) > > def get_options(): > """process options from command line and config file""" > > thanks again for adding this functionality to koji. :) The patch looks good, I've applied it. Just out of curiousity, where did the common/ directory come from, an svn:external? From rob.myers at gtri.gatech.edu Tue Nov 6 21:22:55 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Tue, 06 Nov 2007 16:22:55 -0500 Subject: RFC - Patch - koji SCM generalization In-Reply-To: <1194381225.20536.2.camel@localhost.localdomain> References: <1193163187.18349.96.camel@rxm-581b.stl.gtri.gatech.edu> <1193164256.4427.11.camel@burren.boston.redhat.com> <1193166878.18349.121.camel@rxm-581b.stl.gtri.gatech.edu> <1194306996.15920.23.camel@burren.boston.redhat.com> <1194365809.18349.238.camel@rxm-581b.stl.gtri.gatech.edu> <1194381225.20536.2.camel@localhost.localdomain> Message-ID: <1194384175.32312.25.camel@rxm-581b.stl.gtri.gatech.edu> On Tue, 2007-11-06 at 15:33 -0500, Mike Bonnet wrote: > On Tue, 2007-11-06 at 11:16 -0500, rob myers wrote: > > > > i did some testing with my svn+ssh repository and found the patch below > > necessary- it creates ../common only if it does not already exist. > > > > diff --git a/builder/kojid b/builder/kojid > > index b436a19..5c5d665 100755 > > --- a/builder/kojid > > +++ b/builder/kojid > > @@ -2506,7 +2507,8 @@ class SCM(object): > > (self.scmtype, ' '.join(update_checkout_cmd), > > os.path.basename(logfile)) > > > > # Required by Dist CVS layout > > - os.symlink('%s/common' % scmdir, '%s/../common' % sourcedir) > > + if not os.path.exists('%s/../common' % sourcedir): > > + os.symlink('%s/common' % scmdir, '%s/../common' % > > sourcedir) > > > > def get_options(): > > """process options from command line and config file""" > > The patch looks good, I've applied it. Just out of curiousity, where > did the common/ directory come from, an svn:external? nope nothing fancy; it is just another dir sitting at the same level as all the packages. thanks again. rob. From pmeyer at themeyerfarm.com Tue Nov 6 21:46:52 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Tue, 06 Nov 2007 14:46:52 -0700 Subject: [Patch] for pungi-1.1.8-1.fc8 build on fedora 7 In-Reply-To: <1193929772.3053.5.camel@localhost.localdomain> References: <1193929772.3053.5.camel@localhost.localdomain> Message-ID: <4730E0CC.8060107@themeyerfarm.com> Sergio Monteiro Basto wrote: > Hi, > To fix this error: > Pungi.Gather:INFO: Finished downloading packages. > Traceback (most recent call last): > File "/usr/bin/pungi", line 178, in > main() > File "/usr/bin/pungi", line 68, in main > mygather.makeCompsFile() > File "/usr/lib/python2.5/site-packages/pypungi/gather.py", line 397, > in makeCompsFile > ourcomps.writelines(compslines[start:end]) > UnboundLocalError: local variable 'start' referenced before assignment > > > I get this error when building F7 on a Newly rolled F8 platform. pungi-1.1.9-1.fc8 yum-3.2.7-1.fc8 From pmeyer at themeyerfarm.com Tue Nov 6 22:26:38 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Tue, 06 Nov 2007 15:26:38 -0700 Subject: [Patch] for pungi-1.1.8-1.fc8 build on fedora 7 In-Reply-To: <4730E0CC.8060107@themeyerfarm.com> References: <1193929772.3053.5.camel@localhost.localdomain> <4730E0CC.8060107@themeyerfarm.com> Message-ID: <4730EA1E.3090209@themeyerfarm.com> Phil Meyer wrote: > Sergio Monteiro Basto wrote: >> Hi, >> To fix this error: >> Pungi.Gather:INFO: Finished downloading packages. >> Traceback (most recent call last): >> File "/usr/bin/pungi", line 178, in >> main() >> File "/usr/bin/pungi", line 68, in main >> mygather.makeCompsFile() >> File "/usr/lib/python2.5/site-packages/pypungi/gather.py", line 397, >> in makeCompsFile >> ourcomps.writelines(compslines[start:end]) >> UnboundLocalError: local variable 'start' referenced before assignment >> >> >> > I get this error when building F7 on a Newly rolled F8 platform. > > pungi-1.1.9-1.fc8 > > yum-3.2.7-1.fc8 Applied the patch and F7 built! Thanks! From rob.myers at gtri.gatech.edu Thu Nov 8 21:35:50 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Thu, 08 Nov 2007 16:35:50 -0500 Subject: RHEL 5.1 Message-ID: <1194557750.4531.51.camel@rxm-581b.stl.gtri.gatech.edu> I know RHEL is a bit off topic for this list, but bear with me. I import all the RHEL5 bits into koji and then use koji to build rpms for RHEL5. The release of RHEL 5.1 gave me a few kinks to work out: The RHEL5 supplementary channel includes some noarch packages which do not come with source rpms. This breaks the assumption in mash that excludearch and exclusive arch can safely be initialized on SRPMS only. I know that mash is not designed for this use case, but I thought it might be worth pointing out. The patch I used is below. diff --git a/mash/__init__.py b/mash/__init__.py index b02d6c8..6e7a496 100644 --- a/mash/__init__.py +++ b/mash/__init__.py @@ -209,6 +209,18 @@ class Mash: # now deal with noarch for pkg in noarch: for target_arch in self.config.arches: + + # if excludearch is not set this build likely has no src.rpm + # so set excludearch and exclusivearch from the binary + if pkg['build_id'] fg not in excludearch: + path = os.path.join(koji.pathinfo.build(builds_hash[pkg['build_id']]), koji.pathinfo.rpm(pkg)) + fn = open(path, 'r') + hdr = koji.get_rpm_header(fn) + excludearch[pkg['build_id']] = hdr['EXCLUDEARCH'] + exclusivearch[pkg['build_id']] = hdr['EXCLUSIVEARCH'] + fn.close() + continue + if (excludearch[pkg['build_id']] and has_any(masharch.compat[target_arch], excludearch[pkg['build_id']])) or \ (exclusivearch[pkg['build_id']] and not has_any(masharch.compat[target_arch], exclusivearch[pkg['build_id']])): print "Excluding %s.%s from %s due to EXCLUDEARCH/EXCLUSIVEARCH" % (pkg['name'], pkg['arch'], target_arch) Another problem was that I had already imported RHEL 5.1 beta, which has the same rpms in RHEL 5.1 signed with a different key- one that I do not have access to. Since I wanted the rpms written out with the release key, I added a function take the 5.1 release sighdrs and add them to the previously imported RHEL 5.1 beta rpms. Would anyone else ever need this functionality? The patch I used is below. diff --git a/hub/kojihub.py b/hub/kojihub.py index f9ba39a..c5a1261 100644 --- a/hub/kojihub.py +++ b/hub/kojihub.py @@ -4706,6 +4706,15 @@ class RootExports(object): context.session.assertPerm('sign') return add_rpm_sig(an_rpm, base64.decodestring(data)) + def addRPMSigByPath(self, an_rpm, path): + """Store a signature header for an rpm + + an_rpm: N-V-R.a (for example) + path: the path to the signed rpm + """ + context.session.assertPerm('sign') + return add_rpm_sig(an_rpm, koji.rip_rpm_sighdr(path)) + findBuildID = staticmethod(find_build_id) getTagID = staticmethod(get_tag_id) getTag = staticmethod(get_tag) Comments? rob. From mikeb at redhat.com Thu Nov 8 21:56:31 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 08 Nov 2007 16:56:31 -0500 Subject: RHEL 5.1 In-Reply-To: <1194557750.4531.51.camel@rxm-581b.stl.gtri.gatech.edu> References: <1194557750.4531.51.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <1194558991.10036.3.camel@localhost.localdomain> On Thu, 2007-11-08 at 16:35 -0500, rob myers wrote: > I know RHEL is a bit off topic for this list, but bear with me. I > import all the RHEL5 bits into koji and then use koji to build rpms for > RHEL5. The release of RHEL 5.1 gave me a few kinks to work out: > > The RHEL5 supplementary channel includes some noarch packages which do > not come with source rpms. This breaks the assumption in mash that > excludearch and exclusive arch can safely be initialized on SRPMS only. > I know that mash is not designed for this use case, but I thought it > might be worth pointing out. The patch I used is below. > > diff --git a/mash/__init__.py b/mash/__init__.py > index b02d6c8..6e7a496 100644 > --- a/mash/__init__.py > +++ b/mash/__init__.py > @@ -209,6 +209,18 @@ class Mash: > # now deal with noarch > for pkg in noarch: > for target_arch in self.config.arches: > + > + # if excludearch is not set this build likely has no src.rpm > + # so set excludearch and exclusivearch from the binary > + if pkg['build_id'] fg > not in excludearch: > + path = os.path.join(koji.pathinfo.build(builds_hash[pkg['build_id']]), koji.pathinfo.rpm(pkg)) > + fn = open(path, 'r') > + hdr = koji.get_rpm_header(fn) > + excludearch[pkg['build_id']] = hdr['EXCLUDEARCH'] > + exclusivearch[pkg['build_id']] = hdr['EXCLUSIVEARCH'] > + fn.close() > + continue > + > if (excludearch[pkg['build_id']] and has_any(masharch.compat[target_arch], excludearch[pkg['build_id']])) or \ > (exclusivearch[pkg['build_id']] and not has_any(masharch.compat[target_arch], exclusivearch[pkg['build_id']])): > print "Excluding %s.%s from %s due to EXCLUDEARCH/EXCLUSIVEARCH" % (pkg['name'], pkg['arch'], target_arch) > > > Another problem was that I had already imported RHEL 5.1 beta, which has > the same rpms in RHEL 5.1 signed with a different key- one that I do not > have access to. Since I wanted the rpms written out with the release > key, I added a function take the 5.1 release sighdrs and add them to the > previously imported RHEL 5.1 beta rpms. Would anyone else ever need this > functionality? The patch I used is below. > > diff --git a/hub/kojihub.py b/hub/kojihub.py > index f9ba39a..c5a1261 100644 > --- a/hub/kojihub.py > +++ b/hub/kojihub.py > @@ -4706,6 +4706,15 @@ class RootExports(object): > context.session.assertPerm('sign') > return add_rpm_sig(an_rpm, base64.decodestring(data)) > > + def addRPMSigByPath(self, an_rpm, path): > + """Store a signature header for an rpm > + > + an_rpm: N-V-R.a (for example) > + path: the path to the signed rpm > + """ > + context.session.assertPerm('sign') > + return add_rpm_sig(an_rpm, koji.rip_rpm_sighdr(path)) > + > findBuildID = staticmethod(find_build_id) > getTagID = staticmethod(get_tag_id) > getTag = staticmethod(get_tag) > > > Comments? Does the "koji import-sig" command not do what you want? From rob.myers at gtri.gatech.edu Thu Nov 8 22:25:19 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Thu, 08 Nov 2007 17:25:19 -0500 Subject: RHEL 5.1 In-Reply-To: <1194558991.10036.3.camel@localhost.localdomain> References: <1194557750.4531.51.camel@rxm-581b.stl.gtri.gatech.edu> <1194558991.10036.3.camel@localhost.localdomain> Message-ID: <1194560719.4531.54.camel@rxm-581b.stl.gtri.gatech.edu> On Thu, 2007-11-08 at 16:56 -0500, Mike Bonnet wrote: > Does the "koji import-sig" command not do what you want? looks like it does exactly what i want. i think i was grepping in the wrong dir again. :) thanks for the suggestion, and sorry for the noise! rob. From notting at redhat.com Fri Nov 9 18:05:25 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 9 Nov 2007 13:05:25 -0500 Subject: RHEL 5.1 In-Reply-To: <1194557750.4531.51.camel@rxm-581b.stl.gtri.gatech.edu> References: <1194557750.4531.51.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <20071109180525.GA4063@nostromo.devel.redhat.com> rob myers (rob.myers at gtri.gatech.edu) said: > diff --git a/mash/__init__.py b/mash/__init__.py > index b02d6c8..6e7a496 100644 > --- a/mash/__init__.py > +++ b/mash/__init__.py > @@ -209,6 +209,18 @@ class Mash: > # now deal with noarch > for pkg in noarch: > for target_arch in self.config.arches: > + > + # if excludearch is not set this build likely has no src.rpm > + # so set excludearch and exclusivearch from the binary > + if pkg['build_id'] fg > not in excludearch: > + path = os.path.join(koji.pathinfo.build(builds_hash[pkg['build_id']]), koji.pathinfo.rpm(pkg)) > + fn = open(path, 'r') > + hdr = koji.get_rpm_header(fn) > + excludearch[pkg['build_id']] = hdr['EXCLUDEARCH'] > + exclusivearch[pkg['build_id']] = hdr['EXCLUSIVEARCH'] > + fn.close() > + continue > + > if (excludearch[pkg['build_id']] and has_any(masharch.compat[target_arch], excludearch[pkg['build_id']])) or \ > (exclusivearch[pkg['build_id']] and not has_any(masharch.compat[target_arch], exclusivearch[pkg['build_id']])): > print "Excluding %s.%s from %s due to EXCLUDEARCH/EXCLUSIVEARCH" % (pkg['name'], pkg['arch'], target_arch) Looks sane, added. Thanks! Bill From rob.myers at gtri.gatech.edu Fri Nov 9 18:47:22 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Fri, 09 Nov 2007 13:47:22 -0500 Subject: RHEL 5.1 In-Reply-To: <20071109180525.GA4063@nostromo.devel.redhat.com> References: <1194557750.4531.51.camel@rxm-581b.stl.gtri.gatech.edu> <20071109180525.GA4063@nostromo.devel.redhat.com> Message-ID: <1194634042.19631.4.camel@rxm-581b.stl.gtri.gatech.edu> On Fri, 2007-11-09 at 13:05 -0500, Bill Nottingham wrote: > rob myers (rob.myers at gtri.gatech.edu) said: > > + # so set excludearch and exclusivearch from the binary > > + if pkg['build_id'] fg > > not in excludearch: > > + path = os.path.join(koji.pathinfo.build(builds_hash[pkg['build_id']]), koji.pathinfo.rpm(pkg)) > > Looks sane, added. Thanks! looks like i tried to fg my mailer rather than my terminal, but hopefully you noticed that before applying. :) sorry for the sloppiness, and thanks for applying. rob. From jeff at osuosl.org Tue Nov 13 04:02:13 2007 From: jeff at osuosl.org (Jeff Sheltren) Date: Mon, 12 Nov 2007 20:02:13 -0800 Subject: Mock 0.8.x available In-Reply-To: <20071021222258.GA26458@humbolt.us.dell.com> References: <20071021222258.GA26458@humbolt.us.dell.com> Message-ID: <65B2F9EB-DA14-4043-B30D-27ADDC763F00@osuosl.org> On Oct 21, 2007, at 3:22 PM, Michael E Brown wrote: > Mock users, > > I have posted a new version of mock for review and comments. > > RPM download: http://linux.dell.com/libsmbios/download/mock/ > mock-0.8.1/ > Git repository: http://linux.dell.com/git/mock-v2.git Hi Michael, I think this is great -- thanks a lot for all the work you've put into the update. I've tried it out a bit on both EL5 and FC6 and I haven't been able to get it working at all. On both systems, a mock -r rebuild gives me the following error: Error: Command(/usr/bin/yum --installroot /var/lib/mock/fedora-7-i386/ root install buildsys-build) failed. See logs for output. The yum error that shows up in root.log is: 2007-11-12 19:49:38,210 - trace_decorator.py:21:DEBUG: ENTER: do(('/ usr/bin/yum --installroot /var/lib/mock/fedora-7-i386/root install buildsys-build', None, 0, True, 0), {}) 2007-11-12 19:49:38,211 - util.py:156:DEBUG: Run cmd: /usr/bin/yum -- installroot /var/lib/mock/fedora-7-i386/root install buildsys-build 2007-11-12 19:49:38,211 - util.py:163:DEBUG: Executing timeout(0): / usr/bin/yum --installroot /var/lib/mock/fedora-7-i386/root install buildsys-build 2007-11-12 19:49:38,569 - util.py:181:DEBUG: Loading "installonlyn" plugin 2007-11-12 19:49:38,569 - util.py:181:DEBUG: Setting up Install Process 2007-11-12 19:49:38,569 - util.py:181:DEBUG: Setting up repositories 2007-11-12 19:49:38,570 - util.py:181:DEBUG: No Repositories Available to Set Up 2007-11-12 19:49:38,570 - util.py:181:DEBUG: Reading repository metadata in from local files 2007-11-12 19:49:38,570 - util.py:181:DEBUG: Parsing package install arguments 2007-11-12 19:49:38,570 - util.py:181:DEBUG: Traceback (most recent call last): 2007-11-12 19:49:38,570 - util.py:181:DEBUG: File "/usr/bin/yum", line 29, in ? 2007-11-12 19:49:38,571 - util.py:181:DEBUG: yummain.main(sys.argv[1:]) 2007-11-12 19:49:38,571 - util.py:181:DEBUG: File "/usr/share/yum- cli/yummain.py", line 94, in main 2007-11-12 19:49:38,571 - util.py:181:DEBUG: result, resultmsgs = base.doCommands() 2007-11-12 19:49:38,571 - util.py:181:DEBUG: File "/usr/share/yum- cli/cli.py", line 381, in doCommands 2007-11-12 19:49:38,571 - util.py:181:DEBUG: return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds) 2007-11-12 19:49:38,572 - util.py:181:DEBUG: File "/usr/share/yum- cli/yumcommands.py", line 134, in doCommand 2007-11-12 19:49:38,572 - util.py:181:DEBUG: return base.installPkgs(extcmds) 2007-11-12 19:49:38,572 - util.py:181:DEBUG: File "/usr/share/yum- cli/cli.py", line 553, in installPkgs 2007-11-12 19:49:38,572 - util.py:181:DEBUG: exactmatch, matched, unmatched = \ 2007-11-12 19:49:38,572 - util.py:181:DEBUG: File "/usr/lib/ python2.4/site-packages/yum/packageSack.py", line 360, in matchPackageNames 2007-11-12 19:49:38,573 - util.py:181:DEBUG: unmatched = list(unmatched) 2007-11-12 19:49:38,573 - util.py:181:DEBUG: TypeError: iteration over non-sequence 2007-11-12 19:49:38,573 - trace_decorator.py:32:DEBUG: EXCEPTION: Command(/usr/bin/yum --installroot /var/lib/mock/fedora-7-i386/root install buildsys-build) failed. See logs for output. I get the same error when using different mock roots. Am I just doing something completely wrong? For the fc6 box: $ rpm -q yum yum-3.0.6-1.fc6 $ rpm -q mock mock-0.8.1-1.fc6 The mock configs are unchanged from those included in the RPM. Which actually brings me to my 2nd "problem" in that the old mock rpm used to mark /etc/mock/*cfg as config(noreplace) IIRC, and now it only claims ownership of the directory. The end result seems to be that the new package completely blows away all custom configs that were in / etc/mock. Was this done deliberately due to config file changes? Thanks, Jeff From Michael_E_Brown at dell.com Tue Nov 13 16:06:33 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 13 Nov 2007 10:06:33 -0600 Subject: Mock 0.8.x available In-Reply-To: <65B2F9EB-DA14-4043-B30D-27ADDC763F00@osuosl.org> References: <20071021222258.GA26458@humbolt.us.dell.com> <65B2F9EB-DA14-4043-B30D-27ADDC763F00@osuosl.org> Message-ID: <20071113160632.GA18768@humbolt.us.dell.com> On Mon, Nov 12, 2007 at 08:02:13PM -0800, Jeff Sheltren wrote: > On Oct 21, 2007, at 3:22 PM, Michael E Brown wrote: > > >Mock users, > > > > I have posted a new version of mock for review and comments. > > > >RPM download: http://linux.dell.com/libsmbios/download/mock/ > >mock-0.8.1/ Ah. I forgot that I had made a 'test' release of mock and put it up there. Can you try the latest 0.8.7 release? > >Git repository: http://linux.dell.com/git/mock-v2.git I dont always keep this git repo up-to-date unless I'm actually posting something for review on the mailing list. I think our mirror scripts got stuck and this hasnt been resynced in a week or two. > > Hi Michael, I think this is great -- thanks a lot for all the work > you've put into the update. > > I've tried it out a bit on both EL5 and FC6 and I haven't been able to > get it working at all. On both systems, a mock -r rebuild > gives me the following error: > Error: Command(/usr/bin/yum --installroot /var/lib/mock/fedora-7-i386/ > root install buildsys-build) failed. See logs for output. > > The yum error that shows up in root.log is: > 2007-11-12 19:49:38,210 - trace_decorator.py:21:DEBUG: ENTER: do(('/ > usr/bin/yum --installroot /var/lib/mock/fedora-7-i386/root install > buildsys-build', None, 0, True, 0), {}) > 2007-11-12 19:49:38,211 - util.py:156:DEBUG: Run cmd: /usr/bin/yum -- > installroot /var/lib/mock/fedora-7-i386/root install buildsys-build > 2007-11-12 19:49:38,211 - util.py:163:DEBUG: Executing timeout(0): / > usr/bin/yum --installroot /var/lib/mock/fedora-7-i386/root install > buildsys-build > 2007-11-12 19:49:38,569 - util.py:181:DEBUG: Loading "installonlyn" > plugin > 2007-11-12 19:49:38,569 - util.py:181:DEBUG: Setting up Install Process > 2007-11-12 19:49:38,569 - util.py:181:DEBUG: Setting up repositories > 2007-11-12 19:49:38,570 - util.py:181:DEBUG: No Repositories Available > to Set Up > 2007-11-12 19:49:38,570 - util.py:181:DEBUG: Reading repository > metadata in from local files These are messages from yum... Can you check /var/lib/mock/fedora-7-i386/root/etc/yum.conf to see that it looks 'sane'? Do you have direct internet access? > 2007-11-12 19:49:38,570 - util.py:181:DEBUG: Parsing package install > arguments > 2007-11-12 19:49:38,570 - util.py:181:DEBUG: Traceback (most recent > call last): > 2007-11-12 19:49:38,570 - util.py:181:DEBUG: File "/usr/bin/yum", > line 29, in ? > 2007-11-12 19:49:38,571 - util.py:181:DEBUG: > yummain.main(sys.argv[1:]) > 2007-11-12 19:49:38,571 - util.py:181:DEBUG: File "/usr/share/yum- > cli/yummain.py", line 94, in main > 2007-11-12 19:49:38,571 - util.py:181:DEBUG: result, resultmsgs = > base.doCommands() > 2007-11-12 19:49:38,571 - util.py:181:DEBUG: File "/usr/share/yum- > cli/cli.py", line 381, in doCommands > 2007-11-12 19:49:38,571 - util.py:181:DEBUG: return > self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, > self.extcmds) > 2007-11-12 19:49:38,572 - util.py:181:DEBUG: File "/usr/share/yum- > cli/yumcommands.py", line 134, in doCommand > 2007-11-12 19:49:38,572 - util.py:181:DEBUG: return > base.installPkgs(extcmds) > 2007-11-12 19:49:38,572 - util.py:181:DEBUG: File "/usr/share/yum- > cli/cli.py", line 553, in installPkgs > 2007-11-12 19:49:38,572 - util.py:181:DEBUG: exactmatch, matched, > unmatched = \ > 2007-11-12 19:49:38,572 - util.py:181:DEBUG: File "/usr/lib/ > python2.4/site-packages/yum/packageSack.py", line 360, in > matchPackageNames > 2007-11-12 19:49:38,573 - util.py:181:DEBUG: unmatched = > list(unmatched) > 2007-11-12 19:49:38,573 - util.py:181:DEBUG: TypeError: iteration over This is all a yum traceback. Your yum is having some problems... > non-sequence > 2007-11-12 19:49:38,573 - trace_decorator.py:32:DEBUG: EXCEPTION: > Command(/usr/bin/yum --installroot /var/lib/mock/fedora-7-i386/root > install buildsys-build) failed. See logs for output. > > I get the same error when using different mock roots. Am I just doing > something completely wrong? For the fc6 box: > $ rpm -q yum > yum-3.0.6-1.fc6 > $ rpm -q mock > mock-0.8.1-1.fc6 Can you please try 0.8.7, which is the latest released version? Take the srpm and use mock on a F7/F8 machine to build an RPM for RHEL5 using the shipped config file. I'm not sure if I released 0.8.1 to fedora or not... I have two build machines running FC6, and I have tested mock there and it works ok. There is one known 'issue' that appears to me to be cosmetic (traceback on exit) but otherwise it functions ok. > The mock configs are unchanged from those included in the RPM. Which > actually brings me to my 2nd "problem" in that the old mock rpm used > to mark /etc/mock/*cfg as config(noreplace) IIRC, and now it only > claims ownership of the directory. The end result seems to be that > the new package completely blows away all custom configs that were in / > etc/mock. Was this done deliberately due to config file changes? ?? %files ... %config(noreplace) %{_sysconfdir}/%{name}/*.cfg %config(noreplace) %{_sysconfdir}/%{name}/*.ini This hasnt changed, so they should all still be config(noreplace). So, before I make a release, I run a release test. It is doc/releasetest.sh in the git repo. It basically rebuilds mock using each config shipped with mock. This ensures that I ship only working config files and that mock works with each config. -- Michael From jeff at osuosl.org Tue Nov 13 23:12:50 2007 From: jeff at osuosl.org (Jeff Sheltren) Date: Tue, 13 Nov 2007 15:12:50 -0800 Subject: Mock 0.8.x available In-Reply-To: <20071113160632.GA18768@humbolt.us.dell.com> References: <20071021222258.GA26458@humbolt.us.dell.com> <65B2F9EB-DA14-4043-B30D-27ADDC763F00@osuosl.org> <20071113160632.GA18768@humbolt.us.dell.com> Message-ID: On Nov 13, 2007, at 8:06 AM, Michael E Brown wrote: > > Can you please try 0.8.7, which is the latest released version? Take > the > srpm and use mock on a F7/F8 machine to build an RPM for RHEL5 using > the > shipped config file. I'm not sure if I released 0.8.1 to fedora or > not... Yep, sorry for the noise, I didn't realize I was using an older version. After rebuilding 0.8.7 for EL5, it mostly works, but I have noticed on bug so far. In my configs, I have a mock repo defined using file:///some/path which is an NFS mounted directory (handled by automount). Now, if that is not currently mounted and I run mock, then yum in mock gives an error that the repodata isn't found for that repo. At that point I can run the 'mount' command, see that automount has mounted the directory, and then if I re-run mock it will complete the setup/build successfully. Since this appears to be yum reporting the problem and not mock I'm not sure what the old mock was doing that somehow I never had this problem before. Doing an 'ls' on the directory to get it auto-mounted before running mock also avoids the problem. Aside from that issue (and the logging messages you mentioned), things seem to be working fine so far... Thanks, Jeff From Michael_E_Brown at dell.com Wed Nov 14 18:25:46 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 14 Nov 2007 12:25:46 -0600 Subject: automounter vs mock (shared-subtrees) was Re: Mock 0.8.x available In-Reply-To: References: <20071021222258.GA26458@humbolt.us.dell.com> <65B2F9EB-DA14-4043-B30D-27ADDC763F00@osuosl.org> <20071113160632.GA18768@humbolt.us.dell.com> Message-ID: <20071114182545.GA10930@humbolt.us.dell.com> On Tue, Nov 13, 2007 at 03:12:50PM -0800, Jeff Sheltren wrote: > On Nov 13, 2007, at 8:06 AM, Michael E Brown wrote: > > > >Can you please try 0.8.7, which is the latest released version? Take > >the > >srpm and use mock on a F7/F8 machine to build an RPM for RHEL5 using > >the > >shipped config file. I'm not sure if I released 0.8.1 to fedora or > >not... > > Yep, sorry for the noise, I didn't realize I was using an older > version. After rebuilding 0.8.7 for EL5, it mostly works, but I have > noticed on bug so far. In my configs, I have a mock repo defined > using file:///some/path which is an NFS mounted directory (handled by > automount). Now, if that is not currently mounted and I run mock, > then yum in mock gives an error that the repodata isn't found for that > repo. At that point I can run the 'mount' command, see that automount > has mounted the directory, and then if I re-run mock it will complete > the setup/build successfully. This is because mock now clone()'s itself and creates a new namespace before exe()-ing the mock.py code. Your automounter is not sharing the new namespace that mock creates. You can fix this by running: # mount --make-rshared / You can put it in your /etc/rc.local. I was not able to find out the syntax to put this into /etc/fstab, which is where I think it goes. -- Michael From bugs.michael at gmx.net Wed Nov 14 21:42:09 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 14 Nov 2007 22:42:09 +0100 Subject: Mock 0.8.x available In-Reply-To: <20071021222258.GA26458@humbolt.us.dell.com> References: <20071021222258.GA26458@humbolt.us.dell.com> Message-ID: <20071114224209.c44e2488.bugs.michael@gmx.net> Hi! I've been working on fixing Plague 0.4.4.1 (and Plague in cvs) for Fedora 8 (and 7). The following test package works for me so far: http://mschwendt.fedorapeople.org/plague/plague-0.4.4.1-5.fc8.20071114.src.rpm For those, who test the cvs version of Plague 0.5.0 (tickets in bugzilla say so), there are at least two patches necessary to make it work on F7+F8 and with mock >= 0.8: http://mschwendt.fedorapeople.org/plague-0.5.0-fedora8.patch http://mschwendt.fedorapeople.org/plague-cvs-mock-0.8.patch -- Michael Schwendt Fedora release 8 (Werewolf) - Linux 2.6.23.1-49.fc8 loadavg: 1.84 1.55 1.48 From orion at cora.nwra.com Wed Nov 14 22:46:32 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 14 Nov 2007 15:46:32 -0700 Subject: automounter vs mock (shared-subtrees) was Re: Mock 0.8.x available In-Reply-To: <20071114182545.GA10930@humbolt.us.dell.com> References: <20071021222258.GA26458@humbolt.us.dell.com> <65B2F9EB-DA14-4043-B30D-27ADDC763F00@osuosl.org> <20071113160632.GA18768@humbolt.us.dell.com> <20071114182545.GA10930@humbolt.us.dell.com> Message-ID: <473B7AC8.7060607@cora.nwra.com> Michael E Brown wrote: > On Tue, Nov 13, 2007 at 03:12:50PM -0800, Jeff Sheltren wrote: >> Yep, sorry for the noise, I didn't realize I was using an older >> version. After rebuilding 0.8.7 for EL5, it mostly works, but I have >> noticed on bug so far. In my configs, I have a mock repo defined >> using file:///some/path which is an NFS mounted directory (handled by >> automount). Now, if that is not currently mounted and I run mock, >> then yum in mock gives an error that the repodata isn't found for that >> repo. At that point I can run the 'mount' command, see that automount >> has mounted the directory, and then if I re-run mock it will complete >> the setup/build successfully. > > This is because mock now clone()'s itself and creates a new namespace > before exe()-ing the mock.py code. Your automounter is not sharing the > new namespace that mock creates. You can fix this by running: > > # mount --make-rshared / > > You can put it in your /etc/rc.local. > > I was not able to find out the syntax to put this into /etc/fstab, which > is where I think it goes. The problem I'm seeing is that a mock instance runs, it accesses file:///data/sw1/... which is automounted for that process, but then I cannot access /data/sw1 for any other process until the first mock quits. mount --make-rshared / doesn't seem to help. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jkeating at redhat.com Thu Nov 15 01:35:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Nov 2007 20:35:08 -0500 Subject: Koji patches for no longer creating hardlinks for package repodata Message-ID: <20071114203508.50528e7a@redhat.com> We've talked about ways of making new repo tasks faster, and one of the big speedups is no longer making a tree of hardlinks to run createrepo over. Recently createrepo gained[1] the ability to read from an include list. Paired with the option to specify a baseurl to make everything relative from, we can now run createrepo directly on the packages/ dir, using the include file (generated from the list of packages we /would/ have hardlinked), use an http url as the baseurl (so that static-repos continue to work) and skip the hardlink step all together. An added bonus is that when a static-repo expires, the metadata you may be working with will continue to reference valid package URLS so your transaction will continue without failure. While I was working with this code, I also noticed that we can stop creating a buildsys-build rpm and instead rely on the groupdata in the repodata and just use 'groupinstall buildsys-build' as are chroot init command. Add to that we were unnecessarily linking comps.xml files into each arch directory of a repo directory, when instead we can just reference the one we create in groups/ when creating repodata. Since we no longer need to make the buildgroups rpm, the PrepRepo task in kojid is no longer needed. I took the one part that it was still usefully doing (asking the hub to prep the repo dirs) and move it up to the NewRepo task. This saves a task creation and pickup/handoff. I introduced a config item in kojid.conf, which is pkgurl. This is used as the baseurl component to the repodata and should be the url which leads to the packages/ directory. Finally, since the repodata itself will continue to live in the same expected locations, builders can continue to consume the repodata via nfs. But since the repodata itself references http, yum will use http to download the packages to populate the buildroot. We just have to ensure that the url used in pkgurl is not only valid in the outside world (so that static-repos continue to work) but valid within the buildsystem structure as well. I've committed my changes to a git tree (cloned from tip today) here: http://jkeating.fedorapeople.org/git/koji/ Feedback would be welcome. We're going to get the createrepo change into RHEL5.2 (along with --update support) with the idea that when we refresh the Fedora buildsystem machines in early December, we'll go with RHEL5 and perhaps a newer createrepo package. Ideally we'd get the changes I've made into koji beforehand so that we can release a new build of koji during the refresh. [1] https://lists.dulug.duke.edu/pipermail/rpm-metadata/2007-November/000812.html -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Michael_E_Brown at dell.com Thu Nov 15 17:31:17 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 15 Nov 2007 11:31:17 -0600 Subject: Mock 0.8.x available In-Reply-To: <20071114224209.c44e2488.bugs.michael@gmx.net> References: <20071021222258.GA26458@humbolt.us.dell.com> <20071114224209.c44e2488.bugs.michael@gmx.net> Message-ID: <20071115173116.GB20247@humbolt.us.dell.com> On Wed, Nov 14, 2007 at 10:42:09PM +0100, Michael Schwendt wrote: > Hi! > > I've been working on fixing Plague 0.4.4.1 (and Plague in cvs) for Fedora > 8 (and 7). The following test package works for me so far: > > http://mschwendt.fedorapeople.org/plague/plague-0.4.4.1-5.fc8.20071114.src.rpm > > For those, who test the cvs version of Plague 0.5.0 (tickets in bugzilla > say so), there are at least two patches necessary to make it work on > F7+F8 and with mock >= 0.8: > > http://mschwendt.fedorapeople.org/plague-0.5.0-fedora8.patch > http://mschwendt.fedorapeople.org/plague-cvs-mock-0.8.patch Do we need to have a more-stable interface between mock and plague? I set up plague sometime in the distant, distant past and actually hacked on it a bit. From what I remember, it had to read the state file because the old version of mock could sometimes exit before it had dropped the init state, or that mock could exit too quickly in the build state. (I dont remember all the details...) I think I have resolved most of those issues with mock 0.8.x. You should be able to rely on the mock return code at least to tell you if it succeeded or failed. Using the mock plugin interface, we could probably very easily write a plague interface that is stable if you need more information about state changes. That would be much more sustainable and reliable than parsing stdout. -- Michael From dcbw at redhat.com Thu Nov 15 19:12:28 2007 From: dcbw at redhat.com (Dan Williams) Date: Thu, 15 Nov 2007 14:12:28 -0500 Subject: Mock 0.8.x available In-Reply-To: <20071114224209.c44e2488.bugs.michael@gmx.net> References: <20071021222258.GA26458@humbolt.us.dell.com> <20071114224209.c44e2488.bugs.michael@gmx.net> Message-ID: <1195153948.15950.0.camel@localhost.localdomain> On Wed, 2007-11-14 at 22:42 +0100, Michael Schwendt wrote: > Hi! > > I've been working on fixing Plague 0.4.4.1 (and Plague in cvs) for Fedora > 8 (and 7). The following test package works for me so far: > > http://mschwendt.fedorapeople.org/plague/plague-0.4.4.1-5.fc8.20071114.src.rpm Do you want to own plague? I don't really want to, and somebody with the ability to devote more attention to it probably should. Dan > For those, who test the cvs version of Plague 0.5.0 (tickets in bugzilla > say so), there are at least two patches necessary to make it work on > F7+F8 and with mock >= 0.8: > > http://mschwendt.fedorapeople.org/plague-0.5.0-fedora8.patch > http://mschwendt.fedorapeople.org/plague-cvs-mock-0.8.patch > From bugs.michael at gmx.net Fri Nov 16 00:16:50 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 16 Nov 2007 01:16:50 +0100 Subject: Mock 0.8.x available In-Reply-To: <1195153948.15950.0.camel@localhost.localdomain> References: <20071021222258.GA26458@humbolt.us.dell.com> <20071114224209.c44e2488.bugs.michael@gmx.net> <1195153948.15950.0.camel@localhost.localdomain> Message-ID: <20071116011650.d23792f8.bugs.michael@gmx.net> On Thu, 15 Nov 2007 14:12:28 -0500, Dan Williams wrote: > On Wed, 2007-11-14 at 22:42 +0100, Michael Schwendt wrote: > > Hi! > > > > I've been working on fixing Plague 0.4.4.1 (and Plague in cvs) for Fedora > > 8 (and 7). The following test package works for me so far: > > > > http://mschwendt.fedorapeople.org/plague/plague-0.4.4.1-5.fc8.20071114.src.rpm > > Do you want to own plague? I don't really want to, and somebody with > the ability to devote more attention to it probably should. My only interest has been in keeping it working, because it's still used for EPEL and Livna/RPMFusion, and first it seemed as if python2.5 and sqlite3 break the code badly. I haven't spent enough time on examining all the changes in 0.5.0 in cvs, except for adding fixes. Until a few days ago I didn't know about the tickets in bugzilla and the problems on F7+F8, because my only Plague instance is on F6. Early December Fedora Extras will be EOL'ed, however, and with it my direct relationship with Plague will end, too. How long the Extras buildsys will still be used for EPEL, I don't know. Time is better spent on tools and looking into recent changes in bodhi. From bugs.michael at gmx.net Fri Nov 16 00:17:24 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 16 Nov 2007 01:17:24 +0100 Subject: Mock 0.8.x available In-Reply-To: <20071115173116.GB20247@humbolt.us.dell.com> References: <20071021222258.GA26458@humbolt.us.dell.com> <20071114224209.c44e2488.bugs.michael@gmx.net> <20071115173116.GB20247@humbolt.us.dell.com> Message-ID: <20071116011724.83190a2d.bugs.michael@gmx.net> On Thu, 15 Nov 2007 11:31:17 -0600, Michael E Brown wrote: > > For those, who test the cvs version of Plague 0.5.0 (tickets in bugzilla > > say so), there are at least two patches necessary to make it work on > > F7+F8 and with mock >= 0.8: > > > > http://mschwendt.fedorapeople.org/plague-0.5.0-fedora8.patch > > http://mschwendt.fedorapeople.org/plague-cvs-mock-0.8.patch > > Do we need to have a more-stable interface between mock and plague? Dropping command-line args and changing status-file contents certainly is something that ought to be avoided after the gold release of the distribution. Fedora 7, on the other hand, broke Plague already with Python 2.5 and SQLite 3. With a working QA team, this would have been communicated/announced somewhere prior to F7. > I set up plague sometime in the distant, distant past and actually > hacked on it a bit. From what I remember, it had to read the state file > because the old version of mock could sometimes exit before it had > dropped the init state, or that mock could exit too quickly in the build > state. (I dont remember all the details...) Yes, sounds right. There's code in there that marks a build as failed despite a zero exit code returned by mock. Surprisingly, a few months ago (in September?) the old work-around broke the FE buildsys frequently because it read the state file not quickly/often enough and misinterpreted mock's exit. (most recent mock is not installed everywhere!) Nowadays, reading the state file is mostly for eye-candy, to display "prepping" instead of "building" for the long time it can take to complete a build root with remote repository downloads. The mock exit code is evaluated, and deleting a few more lines of code would get rid of what is left from the old work-around. > I think I have resolved most of those issues with mock 0.8.x. You should > be able to rely on the mock return code at least to tell you if it > succeeded or failed. See other reply in this thread. All that matters to me is to keep a pair of plague+mock working for e.g. CentOS4 or 5. From sodarock at gmail.com Fri Nov 16 02:10:55 2007 From: sodarock at gmail.com (John Villalovos) Date: Thu, 15 Nov 2007 18:10:55 -0800 Subject: What replaced plague Message-ID: <5e61b72f0711151810y5706cc4dq69899646b6533616@mail.gmail.com> I get the impression that another program has replaced plague for doing the distributed build stuff. Can someone tell me what it is and a link to a site with more info? Thanks! John From tmz at pobox.com Fri Nov 16 02:27:47 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 15 Nov 2007 21:27:47 -0500 Subject: What replaced plague In-Reply-To: <5e61b72f0711151810y5706cc4dq69899646b6533616@mail.gmail.com> References: <5e61b72f0711151810y5706cc4dq69899646b6533616@mail.gmail.com> Message-ID: <20071116022747.GB320@psilocybe.teonanacatl.org> John Villalovos wrote: > I get the impression that another program has replaced plague for > doing the distributed build stuff. > > Can someone tell me what it is and a link to a site with more info? Koji: http://hosted.fedoraproject.org/projects/koji -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Suppose I were a member of Congress, and suppose I were an idiot. But, I repeat myself. -- Mark Twain -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From Michael_E_Brown at Dell.com Fri Nov 16 15:26:13 2007 From: Michael_E_Brown at Dell.com (Michael_E_Brown at Dell.com) Date: Fri, 16 Nov 2007 09:26:13 -0600 Subject: potential patch References: <473DB14A.5010003@redhat.com> Message-ID: Better patch: @@ -264,7 +264,7 @@ def main(retParams): log_cfg = ConfigParser.ConfigParser() logging.config.fileConfig(log_ini) log_cfg.read(log_ini) - except (IOError, OSError), e: + except (IOError, OSError, ConfigParser.NoSectionError), e: log.error("Could not find required logging config file: %s" % log_ini) sys.exit(50) About branching: If they ever upgrade fedoraproject.org to a non-ancient version of git, that would be fine. With git >= 1.5, you can delete remote branches. With older git, there is no way to remove a remote branch. Are there any other changes you are needing for cross-building? -- Michael -----Original Message----- From: Clark Williams [mailto:williams at redhat.com] Sent: Fri 11/16/2007 9:03 AM To: Brown, Michael E Subject: potential patch -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael, I'm porting our cross-build environment to use the new mock (0.8.8+) and ran into a small issues. Evidently the ConfigParser stuff doesn't barf if the input configfile doesn't exist, so you get a very strange error about "no formatters section exists" or something similar. What do you think of the change below? I'm still struggling with how I should push these sorts of changes back to the main git repo. I wonder if we shouldn't have michael,clark, and jessie branches up there so we could just push to that for review then merge to master? Dunno... Clark - From 5add76128fcc10555264392307d5da998a05401b Mon Sep 17 00:00:00 2001 From: Clark Williams Date: Thu, 15 Nov 2007 09:20:01 -0600 Subject: [PATCH] fix for no logging.ini situation - --- src/mock.py | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/mock.py b/src/mock.py index 08832dd..9954dcf 100755 - --- a/src/mock.py +++ b/src/mock.py @@ -260,12 +260,15 @@ def main(retParams): # reconfigure logging in case config file was overridden log_ini = os.path.join(config_path, config_opts["log_config_file"]) + if not os.path.exists(log_ini): + log.error("Could not find required logging config file: %s" % log_ini) + sys.exit(50) try: log_cfg = ConfigParser.ConfigParser() logging.config.fileConfig(log_ini) log_cfg.read(log_ini) except (IOError, OSError), e: - - log.error("Could not find required logging config file: %s" % log_ini) + log.error("Error configuring logging: %s" % e) sys.exit(50) # set up logging format strings - -- 1.5.3.4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHPbFJHyuj/+TTEp0RAga1AJ0ddE0ReUVdJpqGwSIHuFQqmhimEACgpej2 WX/yAWX3mo+J7GoS20t9JLg= =OQg0 -----END PGP SIGNATURE----- From williams at redhat.com Fri Nov 16 16:40:44 2007 From: williams at redhat.com (Clark Williams) Date: Fri, 16 Nov 2007 10:40:44 -0600 Subject: potential patch In-Reply-To: References: <473DB14A.5010003@redhat.com> Message-ID: <473DC80C.2040008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael_E_Brown at Dell.com wrote: > Better patch: > > @@ -264,7 +264,7 @@ def main(retParams): > log_cfg = ConfigParser.ConfigParser() > logging.config.fileConfig(log_ini) > log_cfg.read(log_ini) > - except (IOError, OSError), e: > + except (IOError, OSError, ConfigParser.NoSectionError), e: > log.error("Could not find required logging config file: %s" % log_ini) > sys.exit(50) Thanks, I'll drop that in > > > About branching: > If they ever upgrade fedoraproject.org to a non-ancient version of git, that would be fine. With git >= 1.5, you can delete remote branches. With older git, there is no way to remove a remote branch. Yeah, we need to bug Jessie about that. > > Are there any other changes you are needing for cross-building? Don't know yet. I'm running into an SELinux problem where useradd is being denied for mockbuild. Haven't really got a clue as to why, other than it's happening in a chroot. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHPcgMHyuj/+TTEp0RAu2EAJ9ONaama09+8vmVycWtvRAQP9+zpQCg3oEt ITBY5edMNsCblvZ6jgAx1qA= =/MQL -----END PGP SIGNATURE----- From Michael_E_Brown at dell.com Fri Nov 16 16:49:14 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 16 Nov 2007 10:49:14 -0600 Subject: potential patch In-Reply-To: <473DC80C.2040008@redhat.com> References: <473DB14A.5010003@redhat.com> <473DC80C.2040008@redhat.com> Message-ID: <20071116164913.GA24822@humbolt.us.dell.com> On Fri, Nov 16, 2007 at 10:40:44AM -0600, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael_E_Brown at Dell.com wrote: > > Better patch: > > > > @@ -264,7 +264,7 @@ def main(retParams): > > log_cfg = ConfigParser.ConfigParser() > > logging.config.fileConfig(log_ini) > > log_cfg.read(log_ini) > > - except (IOError, OSError), e: > > + except (IOError, OSError, ConfigParser.NoSectionError), e: > > log.error("Could not find required logging config file: %s" % log_ini) > > sys.exit(50) > > Thanks, I'll drop that in I committed it a few mins ago with a couple other things I was doing... :) > > Are there any other changes you are needing for cross-building? > > Don't know yet. I'm running into an SELinux problem where useradd is being denied for > mockbuild. Haven't really got a clue as to why, other than it's happening in a chroot. Hmm... I run all my machines in enforcing mode and I havent seen a problem. I *do* see an selinux denial for useradd that seems to be non-fatal, since it completes. -- Michael From doug.chapman at hp.com Sat Nov 17 02:31:06 2007 From: doug.chapman at hp.com (Doug Chapman) Date: Fri, 16 Nov 2007 21:31:06 -0500 Subject: adding debug files to tree with pungi Message-ID: <1195266666.12764.8.camel@phobos> I have been working on building Fedora 8 ia64 trees with pungi. I have it working for the normal binary and source rpms but I want to be able to use it to add the debuginfo rpms to the tree. The closest I have been able to get this to work was to add *debuginfo to the %packages section of my pungi .ks file. This however just adds the debuginfo packages in 8/ia64/os/Packages/ instead of 8/ia64/debuginfo/ where I find them on other Fedora distros. Can this be done with pungi? btw, I am running the F8 version of pungi: pungi-1.1.9-1.fc8 thanks, - Doug From jkeating at redhat.com Sat Nov 17 02:38:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Nov 2007 21:38:07 -0500 Subject: adding debug files to tree with pungi In-Reply-To: <1195266666.12764.8.camel@phobos> References: <1195266666.12764.8.camel@phobos> Message-ID: <20071116213807.27f7fc60@redhat.com> On Fri, 16 Nov 2007 21:31:06 -0500 Doug Chapman wrote: > Can this be done with pungi? > > btw, I am running the F8 version of pungi: pungi-1.1.9-1.fc8 It can't be done directly with pungi at this time. Pungi has mostly been used to take "Everything" style trees and distill it down to a specific installable set. that's not to say that at some point in the future pungi wouldn't handle debuginfo, I just haven't added the code or options for it yet. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Nov 17 16:12:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 17 Nov 2007 11:12:46 -0500 Subject: Koji patches for no longer creating hardlinks for package repodata In-Reply-To: <20071114203508.50528e7a@redhat.com> References: <20071114203508.50528e7a@redhat.com> Message-ID: <20071117111246.43f6a14c@redhat.com> On Wed, 14 Nov 2007 20:35:08 -0500 Jesse Keating wrote: > I've committed my changes to a git tree (cloned from tip today) here: > > http://jkeating.fedorapeople.org/git/koji/ > > Feedback would be welcome. I've rebased this repo against current git. Attached is a diff of the result of applying all the commits from the above repo. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: koji-no-createrepo-hardlinks.patch Type: text/x-patch Size: 9170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Sun Nov 18 22:01:40 2007 From: opensource at till.name (Till Maas) Date: Sun, 18 Nov 2007 23:01:40 +0100 Subject: mock: enable gpgcheck for f8 config file Message-ID: <200711182301.40871.opensource@till.name> Hiyas, now that the groups repo is not used anymore in mock, imho the gpgcheck option can be enabled by default and only be disabled for the local repo. It will only need the required gpg-keys be included in the mock rpm and some more lines in the config files. I will write a patch for this if you will apply it. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From Michael_E_Brown at dell.com Mon Nov 19 08:01:59 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 19 Nov 2007 02:01:59 -0600 Subject: mock: enable gpgcheck for f8 config file In-Reply-To: <200711182301.40871.opensource@till.name> References: <200711182301.40871.opensource@till.name> Message-ID: <20071119080158.GD6174@humbolt.us.dell.com> On Sun, Nov 18, 2007 at 11:01:40PM +0100, Till Maas wrote: > Hiyas, > > now that the groups repo is not used anymore in mock, imho the gpgcheck option > can be enabled by default and only be disabled for the local repo. It will > only need the required gpg-keys be included in the mock rpm and some more > lines in the config files. I will write a patch for this if you will apply > it. This sounds reasonable. I can queue it up for 0.8.9. As long as the patch is sane, I dont see why we cant do something like this. -- Michael From astrand at cendio.se Wed Nov 21 10:40:15 2007 From: astrand at cendio.se (=?UTF-8?Q?Peter_=C3=85strand?=) Date: Wed, 21 Nov 2007 11:40:15 +0100 (CET) Subject: A few Pungi questions Message-ID: Hi, I have a few questions about Pungi: * When running the text based Anaconda from the resulting ISO, all packages are selectable, not just those that are included in the custom dist. Is this a known limitation? Any other problems with the text based Anaconda, to watch out for? * How can I create a CD that automatically uses a kickstart file? Revisor seems to support this, but we're using Pungi. I've found http://www.redhat.com/archives/fedora-buildsys-list/2007-June/msg00098.html, but perhaps there's a better way to do this? * Where can I find documentation on the "special" Kickstart options that Pungi understands, are there any others than "repo"? I also wonder if anyone has a minimal KS (but with X11) file to be used as a template. Best regards, --- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Link?ping Phone: +46-13-21 46 00 From kanarip at kanarip.com Wed Nov 21 10:55:29 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 11:55:29 +0100 Subject: A few Pungi questions In-Reply-To: References: Message-ID: <47440EA1.1070901@kanarip.com> Peter ?strand wrote: > Hi, I have a few questions about Pungi: > > * When running the text based Anaconda from the resulting ISO, all > packages are selectable, not just those that are included in the custom > dist. Is this a known limitation? Any other problems with the text based > Anaconda, to watch out for? > As far as I can see, anaconda uses comps to determine what groups to display. If you have some third party packages, create a third party repository with a comps.xml and pungi should write out a merged comps file. > > * How can I create a CD that automatically uses a kickstart file? Revisor > seems to support this, but we're using Pungi. I've found > http://www.redhat.com/archives/fedora-buildsys-list/2007-June/msg00098.html, > but perhaps there's a better way to do this? > Using pungi's different 'stages' that you can enable and disable, first compose a 'tree' -but not yet build an ISO, then copy in to that tree your ks.cfg and modify isolinux/isolinux.cfg to 'append ks'. Then run the final pungi stages. > > * Where can I find documentation on the "special" Kickstart options that > Pungi understands, are there any others than "repo"? > > I also wonder if anyone has a minimal KS (but with X11) file to be used as > a template. > A minimal ks with X11 seems to me like you need: %packages --nobase @base-x %end It'll pull in dependencies for @base-x, but not add the @core group. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Nov 21 13:26:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 08:26:02 -0500 Subject: A few Pungi questions In-Reply-To: References: Message-ID: <20071121082602.529bcbff@redhat.com> On Wed, 21 Nov 2007 11:40:15 +0100 (CET) Peter ?strand wrote: > * Where can I find documentation on the "special" Kickstart options > that Pungi understands, are there any others than "repo"? Jeroen answered the other questions for me. "repo" isn't a "special" kickstart option. It's used by anaconda to access additional repositories during install. The only "special" thing that pungi uses is a partition type of "iso" to indicate how large you want your isos to be. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From astrand at cendio.se Wed Nov 21 13:47:14 2007 From: astrand at cendio.se (=?UTF-8?Q?Peter_=C3=85strand?=) Date: Wed, 21 Nov 2007 14:47:14 +0100 (CET) Subject: A few Pungi questions In-Reply-To: <47440EA1.1070901@kanarip.com> References: <47440EA1.1070901@kanarip.com> Message-ID: > > * When running the text based Anaconda from the resulting ISO, all > > packages are selectable, not just those that are included in the custom > > dist. Is this a known limitation? Any other problems with the text based > > Anaconda, to watch out for? > > > > As far as I can see, anaconda uses comps to determine what groups to display. > If you have some third party packages, create a third party repository with a > comps.xml and pungi should write out a merged comps file. I've verified that a comps file is indeed created (DESTDIR/VERSION/i386/os/repodata/NAME-VERSION-comps.xml), but it contains all packages, for example scribus, even though this RPM is not included. Somehow, the GUI Anaconda seems to "hide" the packages that are not available, while the text based Anaconda doesn't. > > * How can I create a CD that automatically uses a kickstart file? Revisor > > seems to support this, but we're using Pungi. I've found > > http://www.redhat.com/archives/fedora-buildsys-list/2007-June/msg00098.html, > > but perhaps there's a better way to do this? > > > > Using pungi's different 'stages' that you can enable and disable, first > compose a 'tree' -but not yet build an ISO, then copy in to that tree your > ks.cfg and modify isolinux/isolinux.cfg to 'append ks'. Then run the final > pungi stages. Thanks. I wonder if this is the approach Revisor uses? > > I also wonder if anyone has a minimal KS (but with X11) file to be used as a > > template. > > > > A minimal ks with X11 seems to me like you need: > > %packages --nobase > @base-x > %end It seems anaconda-runtime is required as well. Also, the resulting installer crashes when trying to install the bootloader. I guess I need to add Grub as well. Rgds, --- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Link?ping Phone: +46-13-21 46 00 From jkeating at redhat.com Wed Nov 21 14:11:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 09:11:38 -0500 Subject: A few Pungi questions In-Reply-To: References: <47440EA1.1070901@kanarip.com> Message-ID: <20071121091138.6a35ef39@redhat.com> On Wed, 21 Nov 2007 14:47:14 +0100 (CET) Peter ?strand wrote: > I've verified that a comps file is indeed created > (DESTDIR/VERSION/i386/os/repodata/NAME-VERSION-comps.xml), but it > contains all packages, for example scribus, even though this RPM is > not included. > > Somehow, the GUI Anaconda seems to "hide" the packages that are not > available, while the text based Anaconda doesn't. Hrm, sounds like maybe a bug in the Anaconda text mode. > > %packages --nobase > > @base-x > > %end > > It seems anaconda-runtime is required as well. > > Also, the resulting installer crashes when trying to install the > bootloader. I guess I need to add Grub as well. Yeah, I haven't yet hardcoded a list of absolutely needed for compose packages. # Compose Needs anaconda-runtime iscsi-initiator-utils memtest86+ vnc-server is what I have listed in the config that made F8. Of course, I'm relying upon grub coming in from core group, and a few other things from other groups. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Wed Nov 21 15:06:56 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 16:06:56 +0100 Subject: A few Pungi questions In-Reply-To: References: <47440EA1.1070901@kanarip.com> Message-ID: <47444990.8080206@kanarip.com> Peter ?strand wrote: >>> * When running the text based Anaconda from the resulting ISO, all >>> packages are selectable, not just those that are included in the custom >>> dist. Is this a known limitation? Any other problems with the text based >>> Anaconda, to watch out for? >>> >> As far as I can see, anaconda uses comps to determine what groups to display. >> If you have some third party packages, create a third party repository with a >> comps.xml and pungi should write out a merged comps file. > > I've verified that a comps file is indeed created > (DESTDIR/VERSION/i386/os/repodata/NAME-VERSION-comps.xml), but it contains > all packages, for example scribus, even though this RPM is not included. > > Somehow, the GUI Anaconda seems to "hide" the packages that are not > available, while the text based Anaconda doesn't. > That could very well be true; I haven't looked at how anaconda does the text interface all too well. > >>> * How can I create a CD that automatically uses a kickstart file? Revisor >>> seems to support this, but we're using Pungi. I've found >>> http://www.redhat.com/archives/fedora-buildsys-list/2007-June/msg00098.html, >>> but perhaps there's a better way to do this? >>> >> Using pungi's different 'stages' that you can enable and disable, first >> compose a 'tree' -but not yet build an ISO, then copy in to that tree your >> ks.cfg and modify isolinux/isolinux.cfg to 'append ks'. Then run the final >> pungi stages. > > Thanks. I wonder if this is the approach Revisor uses? > Revisor doesn't have these stages you can run separately, although Revisor development is on it's way to fully enable modules to hook into different stages of the process. Anyway what Revisor does is compose a tree, then inserts the kickstart file as /ks.cfg and modifies isolinux.cfg appending a "Install with kickstart" bootloader menu option. So, similar to what you would do with pungi but without the stages and manual changes. > >>> I also wonder if anyone has a minimal KS (but with X11) file to be used as a >>> template. >>> >> A minimal ks with X11 seems to me like you need: >> >> %packages --nobase >> @base-x >> %end > > It seems anaconda-runtime is required as well. > > Also, the resulting installer crashes when trying to install the > bootloader. I guess I need to add Grub as well. > Hmm, yes. I forgot; Revisor forcibly adds these required packages -regardless of whether you've selected them or not-, unless you override the variable in the configuration files. Kind regards, Jeroen van Meeuwen -kanarip From astrand at cendio.se Thu Nov 22 20:23:46 2007 From: astrand at cendio.se (=?UTF-8?Q?Peter_=C3=85strand?=) Date: Thu, 22 Nov 2007 21:23:46 +0100 (CET) Subject: A few Pungi questions In-Reply-To: <20071121082602.529bcbff@redhat.com> References: <20071121082602.529bcbff@redhat.com> Message-ID: >> * Where can I find documentation on the "special" Kickstart options >> that Pungi understands, are there any others than "repo"? > >Jeroen answered the other questions for me. > >"repo" isn't a "special" kickstart option. It's used by anaconda to >access additional repositories during install. The only "special" >thing that pungi uses is a partition type of "iso" to indicate how >large you want your isos to be. Thanks! Is there any documentation on the Kickstart format? http://docs.fedoraproject.org/install-guide/f8/en_US/sn-automating-installation.html is very brief. More specifically, I wonder: * Why and when was %end introduced? * Is it still required that %packages is at the end of the KS file? * Why is "mouse" not allowed any longer? Best regards, --- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Link?ping Phone: +46-13-21 46 00 From sergio at sergiomb.no-ip.org Thu Nov 22 20:52:06 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Thu, 22 Nov 2007 20:52:06 +0000 Subject: A few Pungi questions In-Reply-To: References: <20071121082602.529bcbff@redhat.com> Message-ID: <1195764726.17346.1.camel@localhost.localdomain> On Thu, 2007-11-22 at 21:23 +0100, Peter ?strand wrote: > * Why and when was %end introduced? python upgrade, at f7 you must not have it, in f8 python you need %end Best regards, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From wacker at octothorp.org Fri Nov 23 02:28:50 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Thu, 22 Nov 2007 19:28:50 -0700 (MST) Subject: Unable to create a distro on multiple disks with Pungi. Message-ID: Hi all, I can create a very nice DVD with Pungi if I don't specify the number of discs to use. I'm running F8 with pungi-1.1.9 that comes with F8. I figure that right number of discs for a respin of what comes with F8 should be five. When I ask for five discs "--discs=5", I get a DVD sized disc1 and the rest have empty Packages directories. I also get a DVD ISO file, but the size of DISC1 and DVD, different from each other, isn't the size of the DVD when requested alone. I can't tell if the problem is in Pungi or Splitdistro. When I do the SRPMS stage using five discs, I get five proper CD sized ISO files and a proper DVD ISO file. Any ideas? TIA. -- Bill in Denver From astrand at cendio.se Fri Nov 23 09:26:27 2007 From: astrand at cendio.se (=?UTF-8?Q?Peter_=C3=85strand?=) Date: Fri, 23 Nov 2007 10:26:27 +0100 (CET) Subject: A few Pungi questions In-Reply-To: <1195764726.17346.1.camel@localhost.localdomain> References: <20071121082602.529bcbff@redhat.com> <1195764726.17346.1.camel@localhost.localdomain> Message-ID: >> * Why and when was %end introduced? > >python upgrade, at f7 you must not have it, in f8 python you need %end F7 has Python 2.5.0 while F8 has Python 2.5.1. Is this what you are referring to? This seems very strange to me. Or are you perhaps referring to pykickstart? I have yet another question: I've found out about the %ksappend. How is this different from %include? The lack of KS documentation is problematic. I've found /usr/share/doc/pykickstart-1.19/kickstart-docs.txt, but it only contains "Page AnacondaKickstart not found.". After some Googling, I found http://www.redhat.com/archives/kickstart-list/2007-September/msg00032.html which refers to http://fedoraproject.org/wiki/AnacondaKickstart, which doesn't exist any more. But http://fedoraproject.org/wiki/Anaconda/Kickstart seems quite nice, and it explains %end, although %ksappend is still not documented. The page above says "The %packages section should be closed with %end, though this is not yet required.". Is this true for F8? Regards, --- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Link?ping Phone: +46-13-21 46 00 From astrand at cendio.se Fri Nov 23 09:51:15 2007 From: astrand at cendio.se (=?UTF-8?Q?Peter_=C3=85strand?=) Date: Fri, 23 Nov 2007 10:51:15 +0100 (CET) Subject: Pungi gathering - too many kernels Message-ID: I have a KS file that looks like: %packages --nobase @core @base-x kernel @hardware-support -fedora-logos # Compose Needs anaconda-runtime #iscsi-initiator-utils memtest86+ #vnc-server %end Despite this, *all* kernels gets shipped: Pungi.Gather.INFO: Checking deps of xorg-x11-drv-nouveau.i386 yum.verbose.YumBase.DEBUG: Matched xorg-x11-server-Xorg - 1.3.0.0-33.fc8.i386 to require for xorg-x11-server-Xorg Pungi.Gather.INFO: Added xorg-x11-server-Xorg.i386 for xorg-x11-drv-nouveau.i386 yum.verbose.YumBase.DEBUG: Matched kernel - 2.6.23.1-42.fc8.i586 to require for kernel-drm-nouveau yum.verbose.YumBase.DEBUG: Matched kernel - 2.6.23.1-42.fc8.i686 to require for kernel-drm-nouveau yum.verbose.YumBase.DEBUG: Matched kernel-PAE - 2.6.23.1-42.fc8.i686 to require for kernel-drm-nouveau yum.verbose.YumBase.DEBUG: Matched kernel-PAE-debug - 2.6.23.1-42.fc8.i686 to require for kernel-drm-nouveau yum.verbose.YumBase.DEBUG: Matched kernel-debug - 2.6.23.1-42.fc8.i686 to require for kernel-drm-nouveau yum.verbose.YumBase.DEBUG: Matched kernel-debug - 2.6.23.1-49.fc8.i686 to require for kernel-drm-nouveau yum.verbose.YumBase.DEBUG: Matched kernel - 2.6.23.1-49.fc8.i586 to require for kernel-drm-nouveau yum.verbose.YumBase.DEBUG: Matched kernel-PAE-debug - 2.6.23.1-49.fc8.i686 to require for kernel-drm-nouveau yum.verbose.YumBase.DEBUG: Matched kernel-PAE - 2.6.23.1-49.fc8.i686 to require for kernel-drm-nouveau yum.verbose.YumBase.DEBUG: Matched kernel - 2.6.23.1-49.fc8.i686 to require for kernel-drm-nouveau Pungi.Gather.INFO: Added kernel-PAE.i686 for xorg-x11-drv-nouveau.i386 Pungi.Gather.INFO: Added kernel-debug.i686 for xorg-x11-drv-nouveau.i386 Pungi.Gather.INFO: Added kernel-PAE-debug.i686 for xorg-x11-drv-nouveau.i386 Pungi.Gather.INFO: Added kernel.i586 for xorg-x11-drv-nouveau.i386 Pungi.Gather.INFO: Added kernel.i686 for xorg-x11-drv-nouveau.i386 Is this really correct? The normal "kernel" package provides kernel-drm-nouveau, so why is it necessary to pull in all other kernel packages? To me, it looks like the dependency resolver is not satisfied with one package fulfilling the dependencies, but rather includes all. Regards, --- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Link?ping Phone: +46-13-21 46 00 From jkeating at redhat.com Fri Nov 23 14:47:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 Nov 2007 09:47:16 -0500 Subject: Unable to create a distro on multiple disks with Pungi. In-Reply-To: References: Message-ID: <20071123094716.5b87066e@redhat.com> On Thu, 22 Nov 2007 19:28:50 -0700 (MST) "William F. Acker WB2FLW +1-303-722-7209" wrote: > I can create a very nice DVD with Pungi if I don't specify the > number of discs to use. I'm running F8 with pungi-1.1.9 that comes > with F8. I figure that right number of discs for a respin of what > comes with F8 should be five. When I ask for five discs "--discs=5", > I get a DVD sized disc1 and the rest have empty Packages > directories. I also get a DVD ISO file, but the size of DISC1 and > DVD, different from each other, isn't the size of the DVD when > requested alone. I can't tell if the problem is in Pungi or > Splitdistro. When I do the SRPMS stage using five discs, I get five > proper CD sized ISO files and a proper DVD ISO file. Any ideas? Interesting. Do you have a part of type iso in your kickstart file? Without a defined iso part size, pungi doesn't target any specific size. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Nov 23 14:50:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 Nov 2007 09:50:09 -0500 Subject: Pungi gathering - too many kernels In-Reply-To: References: Message-ID: <20071123095009.1b83e42e@redhat.com> On Fri, 23 Nov 2007 10:51:15 +0100 (CET) Peter ?strand wrote: > Is this really correct? The normal "kernel" package provides > kernel-drm-nouveau, so why is it necessary to pull in all other > kernel packages? To me, it looks like the dependency resolver is not > satisfied with one package fulfilling the dependencies, but rather > includes all. That is correct. Dep resolving to create an install tree is different than dep solving at install time. This is because we have no idea what the user will choose as far as packages at install time, so we need to make sure all possible resolvers for deps are included. Once the user goes to install, and they've say selected they want (or need) kernel-PAE, then that particular kernel will satisfy all requirements on kernel. But if instead they want or need kernel.i586, that will take the place instead. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Fri Nov 23 17:11:29 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 23 Nov 2007 18:11:29 +0100 Subject: A few Pungi questions In-Reply-To: References: <20071121082602.529bcbff@redhat.com> Message-ID: <474709C1.6040606@kanarip.com> Peter ?strand wrote: >>> * Where can I find documentation on the "special" Kickstart options >>> that Pungi understands, are there any others than "repo"? >> Jeroen answered the other questions for me. >> >> "repo" isn't a "special" kickstart option. It's used by anaconda to >> access additional repositories during install. The only "special" >> thing that pungi uses is a partition type of "iso" to indicate how >> large you want your isos to be. > > Thanks! Is there any documentation on the Kickstart format? > http://docs.fedoraproject.org/install-guide/f8/en_US/sn-automating-installation.html > is very brief. More specifically, I wonder: > > * Why and when was %end introduced? > I don't know why but I do know when: in the middle of the Fedora release cycle breaking anaconda because it appended %end (until it got to 1.19). > * Is it still required that %packages is at the end of the KS file? > "The end" here is relative. %pre and %post can come after %packages still, it is merely that all the other statements, such as partitioning and install/upgrade or text/graphical, etc... are in the beginning. Maybe a better way to put it is to imagine the kickstart split in two sections: one must come first and holds all the answers to the different stages of the installation process, the other -that must be last- holds %pre, %post and %packages. > * Why is "mouse" not allowed any longer? > I'm not sure what you mean by 'mouse'. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Fri Nov 23 17:19:29 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 23 Nov 2007 18:19:29 +0100 Subject: Pungi gathering - too many kernels In-Reply-To: References: Message-ID: <47470BA1.9030901@kanarip.com> Peter ?strand wrote: > I have a KS file that looks like: > > %packages --nobase [...snip...] If you want the type of granular control so that you resolve deps during compose just like you do during install time (like, when you know what you are doing and you want to trim off the fat), you can use Revisor, which -by default- doesn't resolve dependencies this way, until you specify --respin. Kind regards, Jeroen van Meeuwen -kanarip From astrand at cendio.se Fri Nov 23 18:07:43 2007 From: astrand at cendio.se (=?UTF-8?Q?Peter_=C3=85strand?=) Date: Fri, 23 Nov 2007 19:07:43 +0100 (CET) Subject: A few Pungi questions In-Reply-To: <474709C1.6040606@kanarip.com> References: <20071121082602.529bcbff@redhat.com> <474709C1.6040606@kanarip.com> Message-ID: On Fri, 23 Nov 2007, Jeroen van Meeuwen wrote: > > * Is it still required that %packages is at the end of the KS file? > > > > "The end" here is relative. %pre and %post can come after %packages still, it > is merely that all the other statements, such as partitioning and > install/upgrade or text/graphical, etc... are in the beginning. > > Maybe a better way to put it is to imagine the kickstart split in two > sections: one must come first and holds all the answers to the different > stages of the installation process, the other -that must be last- holds %pre, > %post and %packages. Thanks, seems consistent with my experience as well. > > * Why is "mouse" not allowed any longer? > > > > I'm not sure what you mean by 'mouse'. A "mouse" item was earlier allowed. See for example http://wideopen.com/docs/manuals/linux/RHL-6.1-Manual/ref-guide/s1-kickstart-file.html: "To define the type of mouse your system has, you must use the mouse keyword. " Regards, --- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Link?ping Phone: +46-13-21 46 00 From wacker at octothorp.org Fri Nov 23 18:24:59 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Fri, 23 Nov 2007 11:24:59 -0700 (MST) Subject: Unable to create a distro on multiple disks with Pungi. In-Reply-To: <20071123094716.5b87066e@redhat.com> References: <20071123094716.5b87066e@redhat.com> Message-ID: On Fri, 23 Nov 2007, Jesse Keating wrote: > On Thu, 22 Nov 2007 19:28:50 -0700 (MST) > "William F. Acker WB2FLW +1-303-722-7209" wrote: > >> I can create a very nice DVD with Pungi if I don't specify the >> number of discs to use. I'm running F8 with pungi-1.1.9 that comes >> with F8. I figure that right number of discs for a respin of what >> comes with F8 should be five. When I ask for five discs "--discs=5", >> I get a DVD sized disc1 and the rest have empty Packages >> directories. I also get a DVD ISO file, but the size of DISC1 and >> DVD, different from each other, isn't the size of the DVD when >> requested alone. I can't tell if the problem is in Pungi or >> Splitdistro. When I do the SRPMS stage using five discs, I get five >> proper CD sized ISO files and a proper DVD ISO file. Any ideas? > > Interesting. Do you have a part of type iso in your kickstart file? > Without a defined iso part size, pungi doesn't target any specific size. I have: part iso --size=70000 Needless to say, I've been playing with the size with no joy. Thanks. -- Bill in Denver From devrim at CommandPrompt.com Fri Nov 23 19:46:26 2007 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Fri, 23 Nov 2007 11:46:26 -0800 Subject: Problems starting kojid: SSL issues Message-ID: <1195847186.7571.30.camel@localhost.localdomain> Hi, Following the guidelines on wiki, I am trying to install koji. So far, I could run web interface, but I have problems with SSL things. Koji init script claims that it starts kojid, but I can't see it in the processes. Looking it a bit deeper, I can confirm that the SSL certificates that I entered in kojid.conf are not correct. The question is: Which certificates will I use for kojid? I have generated some certs as described in the wiki... Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kanarip at kanarip.com Fri Nov 23 22:57:43 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 23 Nov 2007 23:57:43 +0100 Subject: A few Pungi questions In-Reply-To: References: <20071121082602.529bcbff@redhat.com> <474709C1.6040606@kanarip.com> Message-ID: <47475AE7.2010708@kanarip.com> Peter ?strand wrote: >>> * Why is "mouse" not allowed any longer? >>> >> I'm not sure what you mean by 'mouse'. > > A "mouse" item was earlier allowed. See for example > http://wideopen.com/docs/manuals/linux/RHL-6.1-Manual/ref-guide/s1-kickstart-file.html: > Really though, documentation comes from upstream... Not a copy of a Red Hat 6.1 Manual (that had been EOL since ~2000). Take a look at: http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/en-US/RHEL510/Installation_Guide/s1-kickstart2-options.html instead. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Sat Nov 24 01:05:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 Nov 2007 20:05:57 -0500 Subject: Unable to create a distro on multiple disks with Pungi. In-Reply-To: References: <20071123094716.5b87066e@redhat.com> Message-ID: <20071123200557.17f67504@redhat.com> On Fri, 23 Nov 2007 11:24:59 -0700 (MST) "William F. Acker WB2FLW +1-303-722-7209" wrote: > I have: part iso --size=70000 > Needless to say, I've been playing with the size with no joy. Ok. I'm perfectly willing to accept that there might be bugs in the split media code path. I haven't used pungi to make split media in quite a few pungi releases (since Fedora doesn't create them) so I could have screwed something up. I'll be testing that code path maybe this weekend to see if I can figure out what's going on. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From astrand at cendio.se Sat Nov 24 15:54:44 2007 From: astrand at cendio.se (=?UTF-8?Q?Peter_=C3=85strand?=) Date: Sat, 24 Nov 2007 16:54:44 +0100 (CET) Subject: A few Pungi questions In-Reply-To: <47475AE7.2010708@kanarip.com> References: <20071121082602.529bcbff@redhat.com> <474709C1.6040606@kanarip.com> <47475AE7.2010708@kanarip.com> Message-ID: On Fri, 23 Nov 2007, Jeroen van Meeuwen wrote: > > A "mouse" item was earlier allowed. See for example > > http://wideopen.com/docs/manuals/linux/RHL-6.1-Manual/ref-guide/s1-kickstart-file.html: > > > > Really though, documentation comes from upstream... Not a copy of a Red Hat > 6.1 Manual (that had been EOL since ~2000). Yes, I know, I was just a little bit lazy and gave an URL to one of the first Google hits. Perhaps RH has a copy available as well, but redhat.com is quite slow to use, IMHO. > Take a look at: > > http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/en-US/RHEL510/Installation_Guide/s1-kickstart2-options.html This page confirms that the mouse keyword is deprecated, but doesn't explain why. Regards, --- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Link?ping Phone: +46-13-21 46 00 From oliver at linux-kernel.at Mon Nov 26 09:03:44 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 26 Nov 2007 10:03:44 +0100 Subject: Problems starting kojid: SSL issues In-Reply-To: <1195847186.7571.30.camel@localhost.localdomain> References: <1195847186.7571.30.camel@localhost.localdomain> Message-ID: <474A8BF0.3040904@linux-kernel.at> On 11/23/2007 08:46 PM, Devrim G?ND?Z wrote: > Hi, > > Following the guidelines on wiki, I am trying to install koji. So far, I > could run web interface, but I have problems with SSL things. > > Koji init script claims that it starts kojid, but I can't see it in the > processes. Looking it a bit deeper, I can confirm that the SSL > certificates that I entered in kojid.conf are not correct. > > The question is: Which certificates will I use for kojid? I have > generated some certs as described in the wiki... You need to have the root certificate that you created in place (ca), the one you create at "Generate CA". serverca is the same - at least in my setup. And then you need the kojid certificate that you created during "Generate kojid certificate"; This must include the private and the public cert of course.... You might also want to take a look at my page: http://wiki.linux-kernel.at/index.php/Koji The Fedora Koji Wiki is the enhanced version of my page, but there might be one or the other hint, that will help you... -of From astrand at cendio.se Mon Nov 26 10:39:00 2007 From: astrand at cendio.se (=?UTF-8?Q?Peter_=C3=85strand?=) Date: Mon, 26 Nov 2007 11:39:00 +0100 (CET) Subject: Confirming predefined partition layout using kickstart Message-ID: Using F8 and Kickstart, we want to predefine everything about partitions, but also let the user confirm that the disk is going to be wiped. I thought this could be done with just: partition / --fstype ext3 --size=1600 --asprimary partition swap --recommended But to my surprise, this does not work: The installer complains about "Could not allocate requested partitions". If we are using: zerombr clearpart --all --initlabel partition / --fstype ext3 --size=1600 --asprimary partition swap --recommended ...things works great, but then there's no confirmation. A workaround could be to have the confirmation dialog in some other step of the installation, it's OK if it's displayed from ISOLINUX or at the start of Anaconda or something like that. Any ideas? Regards, --- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Link?ping Phone: +46-13-21 46 00 From katzj at redhat.com Mon Nov 26 15:05:01 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Nov 2007 10:05:01 -0500 Subject: A few Pungi questions In-Reply-To: References: <20071121082602.529bcbff@redhat.com> <474709C1.6040606@kanarip.com> <47475AE7.2010708@kanarip.com> Message-ID: <1196089501.3328.22.camel@localhost.localdomain> On Sat, 2007-11-24 at 16:54 +0100, Peter ?strand wrote: > This page confirms that the mouse keyword is deprecated, but doesn't > explain why. Because there's no need to specify it with current systems -- the right thing gets detected and set up automagically Jeremy From katzj at redhat.com Mon Nov 26 15:07:22 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Nov 2007 10:07:22 -0500 Subject: Confirming predefined partition layout using kickstart In-Reply-To: References: Message-ID: <1196089642.3328.25.camel@localhost.localdomain> On Mon, 2007-11-26 at 11:39 +0100, Peter ?strand wrote: > Using F8 and Kickstart, we want to predefine everything about partitions, > but also let the user confirm that the disk is going to be wiped. I > thought this could be done with just There's really not a great way of doing this. You can use the 'interactive' keyword to go through every screen but then you're going to go through everything. And there are still some oddities. You could go with the route of popping up a dialog in %pre for confirmation if that's all you really want. Jeremy PS kickstart-list is really a better place for this sort of discussion From katzj at redhat.com Mon Nov 26 15:07:25 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Nov 2007 10:07:25 -0500 Subject: A few Pungi questions In-Reply-To: References: <20071121082602.529bcbff@redhat.com> <1195764726.17346.1.camel@localhost.localdomain> Message-ID: <1196089645.3328.27.camel@localhost.localdomain> On Fri, 2007-11-23 at 10:26 +0100, Peter ?strand wrote: > >> * Why and when was %end introduced? > > > >python upgrade, at f7 you must not have it, in f8 python you need %end > > F7 has Python 2.5.0 while F8 has Python 2.5.1. Is this what you are > referring to? This seems very strange to me. > > Or are you perhaps referring to pykickstart? It is pykickstart, not python in general. > I have yet another question: I've found out about the %ksappend. How is > this different from %include? ksappend takes a url and is a one-shot. %include allows for some nesting and is generally more flexible. Realistically, we should probably deprecate the use of %ksappend in favor of %include > The lack of KS documentation is problematic. I've found > /usr/share/doc/pykickstart-1.19/kickstart-docs.txt, but it only contains > "Page AnacondaKickstart not found.". After some Googling, I found > http://www.redhat.com/archives/kickstart-list/2007-September/msg00032.html > which refers to http://fedoraproject.org/wiki/AnacondaKickstart, which > doesn't exist any more. But > http://fedoraproject.org/wiki/Anaconda/Kickstart seems quite nice, and it > explains %end, although %ksappend is still not documented. That's the right page. Unfortunately, the pages got moved around without a heads-up to some package maintainers, so our automated grabbing of the docs into the packages failed :( > The page above says "The %packages section should be closed with %end, > though this is not yet required.". Is this true for F8? Yes. And realistically, it'll be a while before it's required just due to the fact that there's a lot of legacy to support. But using it is an incredibly good idea and it allows you to do some cool things such as config inheritance. For example, you can have one kickstart config with all of your site default configs. Then, you can have a machine specific config which %include's the default ks.cfg. Without %end, you can only really do %post, %packages, etc in one of the configs -- with it, you can easily have any of them in both and have consistent parsing of the state. Jeremy From jkeating at redhat.com Mon Nov 26 19:19:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Nov 2007 14:19:48 -0500 Subject: Unable to create a distro on multiple disks with Pungi. In-Reply-To: <20071123200557.17f67504@redhat.com> References: <20071123094716.5b87066e@redhat.com> <20071123200557.17f67504@redhat.com> Message-ID: <20071126141948.498d39a9@redhat.com> On Fri, 23 Nov 2007 20:05:57 -0500 Jesse Keating wrote: > > I have: part iso --size=70000 > > Needless to say, I've been playing with the size with no joy. > > Ok. I'm perfectly willing to accept that there might be bugs in the > split media code path. I haven't used pungi to make split media in > quite a few pungi releases (since Fedora doesn't create them) so I > could have screwed something up. I'll be testing that code path maybe > this weekend to see if I can figure out what's going on. Oops. I should have commented in the .ks file that the size is in megs. You just asked for a 70gig~ CD size (: I did a run with size=690 and got properly sized isos. Can you try again? Also, there is an updated release of pungi in updates-testing for F8 that corrects the config file to point at the released repos, and a few other minor bugfixes. Can you please use that for your retry? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wacker at octothorp.org Mon Nov 26 20:09:00 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Mon, 26 Nov 2007 13:09:00 -0700 (MST) Subject: Unable to create a distro on multiple disks with Pungi. In-Reply-To: <20071126141948.498d39a9@redhat.com> References: <20071123094716.5b87066e@redhat.com> <20071123200557.17f67504@redhat.com> <20071126141948.498d39a9@redhat.com> Message-ID: On Mon, 26 Nov 2007, Jesse Keating wrote: > On Fri, 23 Nov 2007 20:05:57 -0500 > Jesse Keating wrote: > > Oops. I should have commented in the .ks file that the size is in > megs. You just asked for a 70gig~ CD size (: I did a run with > size=690 and got properly sized isos. Can you try again? > > Also, there is an updated release of pungi in updates-testing for F8 > that corrects the config file to point at the released repos, and a few > other minor bugfixes. Can you please use that for your retry? > I don't see the new pungi in either the i386 or SRPMS directories on updates testing. I'll stand by for another location and keep checking for it to be pushed. I think I've been able to talk my user base out of Cd's, but it's probably a good idea to test it thoroughly. Thanks for the help. -- Bill in Denver From jkeating at redhat.com Mon Nov 26 20:19:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Nov 2007 15:19:15 -0500 Subject: Unable to create a distro on multiple disks with Pungi. In-Reply-To: References: <20071123094716.5b87066e@redhat.com> <20071123200557.17f67504@redhat.com> <20071126141948.498d39a9@redhat.com> Message-ID: <20071126151915.4c7a28ca@redhat.com> On Mon, 26 Nov 2007 13:09:00 -0700 (MST) "William F. Acker WB2FLW +1-303-722-7209" wrote: > I don't see the new pungi in either the i386 or SRPMS directories on > updates testing. I'll stand by for another location and keep > checking for it to be pushed. I think I've been able to talk my user > base out of Cd's, but it's probably a good idea to test it thoroughly. Looks like the push is still ongoing. You can steal it directly from the koji store (a signed version even!): http://koji.fedoraproject.org/packages/pungi/1.1.10/1.fc8/data/signed/30c9ecf8/noarch/pungi-1.1.10-1.fc8.noarch.rpm -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wacker at octothorp.org Tue Nov 27 00:59:43 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Mon, 26 Nov 2007 17:59:43 -0700 (MST) Subject: Unable to create a distro on multiple disks with Pungi. In-Reply-To: <20071126151915.4c7a28ca@redhat.com> References: <20071123094716.5b87066e@redhat.com> <20071123200557.17f67504@redhat.com> <20071126141948.498d39a9@redhat.com> <20071126151915.4c7a28ca@redhat.com> Message-ID: On Mon, 26 Nov 2007, Jesse Keating wrote: > On Mon, 26 Nov 2007 13:09:00 -0700 (MST) > "William F. Acker WB2FLW +1-303-722-7209" wrote: > >> I don't see the new pungi in either the i386 or SRPMS directories on >> updates testing. I'll stand by for another location and keep >> checking for it to be pushed. I think I've been able to talk my user >> base out of Cd's, but it's probably a good idea to test it thoroughly. > > Looks like the push is still ongoing. You can steal it directly from > the koji store (a signed version even!): > > http://koji.fedoraproject.org/packages/pungi/1.1.10/1.fc8/data/signed/30c9ecf8/noarch/pungi-1.1.10-1.fc8.noarch.rpm OK, I don't know if it was the new version or that I specified the size correctly this time. Five proper ISOs were built plus a DVD. The strange thing is that, when I ask for discs, I get a DVD over 2MB larger than if I just ask for the DVD. A simple ls -1R of the two loop mounted trees compares the same. Go figure. I'd like to take this opportunity to say how much I enjoy being able to use Pungi. I've been at this project since RHL-7.1, hacking shell scripts to use buildinstall and the other tools. Now, all I have to do is to make some minor adjustments to the KS file, wrap the command and its arguments into a script that I call "pungify" and I'm good to go. Thanks again. -- Bill in Denver From wacker at octothorp.org Tue Nov 27 05:29:30 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Mon, 26 Nov 2007 22:29:30 -0700 (MST) Subject: Pungi doesn't implant Checksums in the rescue ISO. Message-ID: Hi, all, I notice that in F7 and F8, there's no check sum in the primary volume descriptor in the rescue ISO. I *think* that there used to be a check sum in earlier releases. In any case, shouldn't we have a way of verifying the rescue disk in the event the SHA1SUM file isn't readily available? -- Bill in Denver From astrand at cendio.se Tue Nov 27 08:09:43 2007 From: astrand at cendio.se (=?UTF-8?Q?Peter_=C3=85strand?=) Date: Tue, 27 Nov 2007 09:09:43 +0100 (CET) Subject: Confirming predefined partition layout using kickstart In-Reply-To: <1196089642.3328.25.camel@localhost.localdomain> References: <1196089642.3328.25.camel@localhost.localdomain> Message-ID: On Mon, 26 Nov 2007, Jeremy Katz wrote: > > Using F8 and Kickstart, we want to predefine everything about partitions, > > but also let the user confirm that the disk is going to be wiped. I > > thought this could be done with just > You could go with the route of popping up a dialog in %pre for > confirmation if that's all you really want. Thanks for your help. I've tried a %pre solution now and it seems to work great. Here's what I did: %pre --interpreter /usr/bin/python TTY = 3 import os import sys import snack import time import fcntl import termios pid = os.fork() if pid != 0: os.wait() os._exit(0) os.system("chvt %d" % TTY) fd = os.open("/dev/tty%d" % TTY, os.O_RDWR) os.dup2(fd, 0) os.dup2(fd, 1) os.dup2(fd, 2) sys.stdin = os.fdopen(0, "r") sys.stdout = os.fdopen(1, "w") sys.stderr = os.fdopen(2, "w") os.setsid() fcntl.ioctl(fd, termios.TIOCSCTTY, 1) screen = snack.SnackScreen() if "reboot" == snack.ButtonChoiceWindow(screen, "WARNING", "WARNING! All data on your hard disk will be DELETED!", buttons=["reboot", "continue"]): os.system("reboot") while 1: time.sleep(10) screen.finish() os.system("chvt %d" % 1) %end Best regards, --- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Link?ping Phone: +46-13-21 46 00 From jkeating at redhat.com Tue Nov 27 12:42:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Nov 2007 07:42:55 -0500 Subject: Pungi doesn't implant Checksums in the rescue ISO. In-Reply-To: References: Message-ID: <20071127074255.604c4eec@redhat.com> On Mon, 26 Nov 2007 22:29:30 -0700 (MST) "William F. Acker WB2FLW +1-303-722-7209" wrote: > I notice that in F7 and F8, there's no check sum in the primary > volume descriptor in the rescue ISO. I *think* that there used to be > a check sum in earlier releases. In any case, shouldn't we have a > way of verifying the rescue disk in the event the SHA1SUM file isn't > readily available? It's worth checking to see if Anaconda's mediacheck would be able to handle the rescue image, or whatever we name it this time around (http://fedoraproject.org/wiki/Anaconda/Features/SecondStageInstallSource) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Nov 27 13:31:32 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 27 Nov 2007 08:31:32 -0500 Subject: Pungi doesn't implant Checksums in the rescue ISO. In-Reply-To: References: Message-ID: <1196170292.15904.16.camel@localhost.localdomain> On Mon, 2007-11-26 at 22:29 -0700, William F. Acker WB2FLW +1-303-722-7209 wrote: > I notice that in F7 and F8, there's no check sum in the primary volume > descriptor in the rescue ISO. I *think* that there used to be a check sum > in earlier releases. In any case, shouldn't we have a way of verifying > the rescue disk in the event the SHA1SUM file isn't readily available? I don't think we've generally had it there in the rescue image. But you're probably right that we should. Jeremy From astrand at cendio.se Tue Nov 27 14:47:33 2007 From: astrand at cendio.se (=?UTF-8?Q?Peter_=C3=85strand?=) Date: Tue, 27 Nov 2007 15:47:33 +0100 (CET) Subject: Confirming predefined partition layout using kickstart In-Reply-To: References: Message-ID: > That's a lot of python for a confirmation box. Have you looked at using dialog? Last time I checked, dialog was not available in the installation environment. Also, most of the code is for changing virtual console. This would be necessary even with the dialog binary. But if anyone has a smaller solution, please let me know. Best regards, Peter ?strand > -----Original Message----- > From: kickstart-list-bounces at redhat.com [mailto:kickstart-list-bounces at redhat.com] On Behalf Of Peter ?strand > Sent: Tuesday, November 27, 2007 12:10 AM > To: Discussion of Fedora build system; kickstart-list at redhat.com > Subject: Re: Confirming predefined partition layout using kickstart > > On Mon, 26 Nov 2007, Jeremy Katz wrote: > > > > Using F8 and Kickstart, we want to predefine everything about > > > partitions, but also let the user confirm that the disk is going to > > > be wiped. I thought this could be done with just > > > You could go with the route of popping up a dialog in %pre for > > confirmation if that's all you really want. > > Thanks for your help. I've tried a %pre solution now and it seems to work great. Here's what I did: > > %pre --interpreter /usr/bin/python > TTY = 3 > import os > import sys > import snack > import time > import fcntl > import termios > pid = os.fork() > if pid != 0: > os.wait() > os._exit(0) > os.system("chvt %d" % TTY) > fd = os.open("/dev/tty%d" % TTY, os.O_RDWR) os.dup2(fd, 0) os.dup2(fd, 1) os.dup2(fd, 2) sys.stdin = os.fdopen(0, "r") sys.stdout = os.fdopen(1, "w") sys.stderr = os.fdopen(2, "w") > os.setsid() > fcntl.ioctl(fd, termios.TIOCSCTTY, 1) > screen = snack.SnackScreen() > if "reboot" == snack.ButtonChoiceWindow(screen, "WARNING", > "WARNING! All data on your hard disk will be DELETED!", > buttons=["reboot", "continue"]): > os.system("reboot") > while 1: time.sleep(10) > screen.finish() > os.system("chvt %d" % 1) > %end > > > Best regards, > --- > Peter ?strand ThinLinc Chief Developer > Cendio AB http://www.cendio.se > Wallenbergs gata 4 > 583 30 Link?ping Phone: +46-13-21 46 00 > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > --- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Link?ping Phone: +46-13-21 46 00 From wacker at octothorp.org Tue Nov 27 18:29:22 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Tue, 27 Nov 2007 11:29:22 -0700 (MST) Subject: Pungi doesn't implant Checksums in the rescue ISO. In-Reply-To: <1196170292.15904.16.camel@localhost.localdomain> References: <1196170292.15904.16.camel@localhost.localdomain> Message-ID: On Tue, 27 Nov 2007, Jeremy Katz wrote: > On Mon, 2007-11-26 at 22:29 -0700, William F. Acker WB2FLW > +1-303-722-7209 wrote: >> I notice that in F7 and F8, there's no check sum in the primary volume >> descriptor in the rescue ISO. I *think* that there used to be a check sum >> in earlier releases. In any case, shouldn't we have a way of verifying >> the rescue disk in the event the SHA1SUM file isn't readily available? > > I don't think we've generally had it there in the rescue image. But > you're probably right that we should. Thanks. BTW, there's no implanted check sum in the src stuff either. Thanks for putting the check sum implanting stuff in /usr/bin when you split the package. It makes it useful for anyone wanting to use that verification strategy with whatever ISOs they might create, music, video, books or whatever. -- Bill in Denver From paul at city-fan.org Fri Nov 30 16:17:52 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 30 Nov 2007 16:17:52 +0000 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <20071031062512.GB2487@humbolt.us.dell.com> References: <20071031062512.GB2487@humbolt.us.dell.com> Message-ID: <475037B0.8090302@city-fan.org> Michael E Brown wrote: > I need a little bit of help understanding what the > 'libselinux-mock.so' LD_PRELOAD was supposed to be doing. I released and > pushed out mock-0.8 without this. I have rebuilt most of rawhide with > this new mock version and have not seen anything that I directly can say > was a failure due to this being missing, so I am sort of not seeing the > point. > > I have searched around as much as I can to try to understand why > this was put into place. From what I can understand, it was only put in > in the FC2 timeframe to fix some problems with the selinux policy on the > host machine. These *appear* to have been fixed in the host selinux > policy, so again, i dont see a reason to keep this around. > > Jesse mentioned on IRC, though, that this might be needed, so I pose > this question. I've a local branch set up with the 0.8.x code and the > LD_PRELOAD put back in. So, I can quickly spin a new release with this > back in if it is actually needed. So far, I havent convinced myself it > is needed, though... > > Could somebody please enlighten me? I suspect it was there to convince rpm that selinux was disabled and hence prevent it from trying to set the contexts of installed files. If rpm doesn't set the context, the files are installed as mock_var_lib_t (assuming my policy module from the wiki is loaded), and this is a "neutral" type that doesn't cause any problems. However, if rpm sets the contexts of files it installs, it'll set things like /sbin/ldconfig to ldconfig_exec_t, and there is now a transition defined in policy from unconfined_t to ldconfig_exec_t. The result of this is that some processes such as ldconfig get run "confined" in the chroot and fail as a result because not *all* file contexts are set up as they would be on the host system, which is what the policy is set up for. I've not quite figured out all te ins and outs of it but a tell-tale sign of there being a problem is to look (ls -lZ) at the root directories of your chroots and see if they look like this: /var/lib/mock/fedora-2-i386-core/root: drwxr-xr-x root root system_u:object_r:bin_t:s0 bin drwxr-xr-x root root system_u:object_r:boot_t:s0 boot drwx------ root mock system_u:object_r:mock_var_lib_t:s0 builddir drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 dev drwxr-xr-x root root system_u:object_r:etc_t:s0 etc drwxr-xr-x root root system_u:object_r:home_root_t:s0 home drwxr-xr-x root root system_u:object_r:root_t:s0 initrd drwxr-xr-x root root system_u:object_r:lib_t:s0 lib drwxr-xr-x root root system_u:object_r:mnt_t:s0 mnt drwxr-xr-x root root system_u:object_r:usr_t:s0 opt drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 proc drwxr-x--- root root system_u:object_r:user_home_dir_t:s0 root drwxr-xr-x root root system_u:object_r:bin_t:s0 sbin drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 selinux drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 sys drwxrwxrwt root root system_u:object_r:tmp_t:s0 tmp drwxr-xr-x root root system_u:object_r:usr_t:s0 usr drwxr-xr-x root root system_u:object_r:var_t:s0 var rather than this: /var/lib/mock/fedora-3-i386-core/root: drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 bin drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 boot drwx------ paul mock system_u:object_r:mock_var_lib_t:s0 builddir drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 dev drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 etc drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 home drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 initrd drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 lib drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 media drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 mnt drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 opt drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 proc drwxr-x--- root root system_u:object_r:mock_var_lib_t:s0 root drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 sbin drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 selinux drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 srv drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 sys drwxrwxrwt root root system_u:object_r:mock_var_lib_t:s0 tmp drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 usr drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 var (it's best to remove any cache or existing root and generate a fresh one) I'd like to try a version with the LD_PRELOAD back in if possible. Paul. From Michael_E_Brown at dell.com Fri Nov 30 19:35:57 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 30 Nov 2007 13:35:57 -0600 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <475037B0.8090302@city-fan.org> References: <20071031062512.GB2487@humbolt.us.dell.com> <475037B0.8090302@city-fan.org> Message-ID: <20071130193556.GC4039@humbolt.us.dell.com> On Fri, Nov 30, 2007 at 04:17:52PM +0000, Paul Howarth wrote: > Michael E Brown wrote: > > I need a little bit of help understanding what the > >'libselinux-mock.so' LD_PRELOAD was supposed to be doing. I released and > >pushed out mock-0.8 without this. I have rebuilt most of rawhide with > >this new mock version and have not seen anything that I directly can say > >was a failure due to this being missing, so I am sort of not seeing the > >point. > > > > I have searched around as much as I can to try to understand why > >this was put into place. From what I can understand, it was only put in > >in the FC2 timeframe to fix some problems with the selinux policy on the > >host machine. These *appear* to have been fixed in the host selinux > >policy, so again, i dont see a reason to keep this around. > > > > Jesse mentioned on IRC, though, that this might be needed, so I pose > >this question. I've a local branch set up with the 0.8.x code and the > >LD_PRELOAD put back in. So, I can quickly spin a new release with this > >back in if it is actually needed. So far, I havent convinced myself it > >is needed, though... > > > > Could somebody please enlighten me? > > I suspect it was there to convince rpm that selinux was disabled and > hence prevent it from trying to set the contexts of installed files. If > rpm doesn't set the context, the files are installed as mock_var_lib_t > (assuming my policy module from the wiki is loaded), and this is a > "neutral" type that doesn't cause any problems. However, if rpm sets the > contexts of files it installs, it'll set things like /sbin/ldconfig to > ldconfig_exec_t, and there is now a transition defined in policy from > unconfined_t to ldconfig_exec_t. The result of this is that some > processes such as ldconfig get run "confined" in the chroot and fail as > a result because not *all* file contexts are set up as they would be on > the host system, which is what the policy is set up for. > > I've not quite figured out all te ins and outs of it but a tell-tale > sign of there being a problem is to look (ls -lZ) at the root > directories of your chroots and see if they look like this: > > /var/lib/mock/fedora-2-i386-core/root: > drwxr-xr-x root root system_u:object_r:bin_t:s0 bin > drwxr-xr-x root root system_u:object_r:boot_t:s0 boot > drwx------ root mock system_u:object_r:mock_var_lib_t:s0 builddir > drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 dev > drwxr-xr-x root root system_u:object_r:etc_t:s0 etc > drwxr-xr-x root root system_u:object_r:home_root_t:s0 home > drwxr-xr-x root root system_u:object_r:root_t:s0 initrd > drwxr-xr-x root root system_u:object_r:lib_t:s0 lib > drwxr-xr-x root root system_u:object_r:mnt_t:s0 mnt > drwxr-xr-x root root system_u:object_r:usr_t:s0 opt > drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 proc > drwxr-x--- root root system_u:object_r:user_home_dir_t:s0 root > drwxr-xr-x root root system_u:object_r:bin_t:s0 sbin > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 selinux > drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 sys > drwxrwxrwt root root system_u:object_r:tmp_t:s0 tmp > drwxr-xr-x root root system_u:object_r:usr_t:s0 usr > drwxr-xr-x root root system_u:object_r:var_t:s0 var > > rather than this: > /var/lib/mock/fedora-3-i386-core/root: > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 bin > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 boot > drwx------ paul mock system_u:object_r:mock_var_lib_t:s0 builddir > drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 dev > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 etc > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 home > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 initrd > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 lib > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 media > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 mnt > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 opt > drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 proc > drwxr-x--- root root system_u:object_r:mock_var_lib_t:s0 root > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 sbin > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 selinux > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 srv > drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 sys > drwxrwxrwt root root system_u:object_r:mock_var_lib_t:s0 tmp > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 usr > drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 var > > (it's best to remove any cache or existing root and generate a fresh one) > > I'd like to try a version with the LD_PRELOAD back in if possible. Well you can look at current fedora mock and run mock -r fedora-8-x86_64 init On my local machine (with selinux enabled), I see that everything is labelled with "var_lib_t", like this: $ ls -lZ drwxr-xr-x root root user_u:object_r:var_lib_t bin drwxr-xr-x root root user_u:object_r:var_lib_t boot drwx------ michael_e_brown mock user_u:object_r:var_lib_t builddir drwxrwxr-x root root user_u:object_r:var_lib_t dev ... cut ... There is a current git branch with the selinux changes ported at: git clone http://linux.dell.com/git/mock.git git checkout -b selinux origin/selinux I'm thinking about it a bit, and I think that the root cache might affect this a little, because it tars/untars the chroot fs. I'll need to do some experiments to see if there is any difference with/without root cache enabled. -- Michael From guillaume.degremont at hp.com Thu Nov 15 16:22:37 2007 From: guillaume.degremont at hp.com (Degremont, Guillaume) Date: Thu, 15 Nov 2007 16:22:37 -0000 Subject: Koji server installation Message-ID: <23E35216F25BB24EADD5BD0D7BFA341171F4698F3D@G3W1112.americas.hpqcorp.net> Hello, I am currently working on deploying a small build system based on mock/koji The system is very simple, just one server hosting the builds and koji (another buidl system may be added later, but that is not the issue at thje present time). I am having some troubles deploying koji. The only document I have found is the ServerHowTo (http://fedoraproject.org/wiki/Koji/ServerHowTo). I retrieved the koji, koji-hub, koji-web and koji-utils packages and installd them successfully on my server. I configured koji to use SSL following the guidelines. Not being a SSL expert, I think I did not do any error, but it was tricky since filenames change between the certificate creation section and the kojihub/kojweb/kojid configuration sections. and I configured all 4 servers (kojihub, kojiweb, kojira, kojid) to be hosted on the same server, named murray. However, when I try to use koji, I get the following error: [koji at murray ~]$ koji add-user userTest Kerberos authentication failed: 'No credentials cache found' (-1765328189) [koji at murray ~]$ I have modified the /etc/koji.conf (though it is not mentioned in the How To) as follows, to ensure it will use SSL: [root at murray ~]# more /etc/koji.conf [koji] ;configuration for koji cli tool ;url of XMLRPC server server = http://murray.mysite.hp.com/kojihub ;url of web interface weburl = http://murray.mysite.hp.com/koji ;url of package download site pkgurl = http://murray.mysite.hp.com/packages ;path to the koji top directory topdir = /mnt/koji ;configuration for SSL athentication ;client certificate cert = /etc/kojiweb/clients/certs/koji.cert ;certificate of the CA that issued the client certificate ca = /etc/kojiweb/clients/koji_ca_cert.crt ;certificate of the CA that issued the HTTP server certificate serverca = /etc/kojiweb/clients/koji_ca_cert.crt koji_ca_cert.crt being the ca certificate I generated and koji.cert a certificate I generated for the koji user. This is my first problem. Can anyone help me on this ? My other problem is with the servers. I configured my apache and started it to have the kojihub and kojiweb started. I then want to perform some add--user, add-host commands. But I get the message "unable to connect to server". [root at murray ~]# koji --noauth add-host murray.mysite.hp.com i386 x86_64 Error: Unable to connect to server With the following logs from httpd: [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: Traceback (most recent call last): [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch\n result = object(req) [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/share/koji-hub/kojixmlrpc.py", line 278, in handler\n context.cnx = koji.db.connect(opts.get("KojiDebug",False)) [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/lib/python2.4/site-packages/koji/db.py", line 128, in connect\n conn = pgdb.connect(**opts) [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/lib/python2.4/site-packages/pgdb.py", line 383, in connect\n dbtty, dbuser, dbpasswd) [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: InternalError: could not connect to server: Connection refused\n\tIs the server running on host "murray.mysite.hp.com" and accepting\n\tTCP/IP connections on port 5432?\n Do you know what it comes from ? I can supply my other conf files, if needed. But I strictly followed the Howto nstructions for the configuration files. Reagrds, Guillaume Degremont PS: for security related reasons, I replaced the ipaddress with X.X.X.X and changed the hostname and fully qualified domain name with dummy ones ^^