From eklitzke at gmail.com Wed Nov 1 07:45:33 2006 From: eklitzke at gmail.com (Evan Klitzke) Date: Tue, 31 Oct 2006 23:45:33 -0800 Subject: plague-server issues (4.4.1) In-Reply-To: <1162309001.3155.9.camel@localhost.localdomain> References: <1162309001.3155.9.camel@localhost.localdomain> Message-ID: On 10/31/06, Dan Williams wrote: > can you insert the extra print to find out what the error is? > > except socket.error, e: > if e[0] == 98: # Address already in use > print "Error: couldn't bind to address '%s:%s'. Is the server already running?" % (hostname, port) > os._exit(1) > print "Other error: %s" % e > > Obviously there should be a catch-all there so this wouldn't happen, but > I'm curious what the error is. Here is the surprising answer to the problem... I added the print statement and got (-2, 'Name or service not known'). That sort of surprised me because I was running with host=localhost. I tried pinging localhost and sure enough, the name couldn't be resolved. It turns out that FC6 has this little gem in /etc/hosts: ::1 localhost.localdomain localhost I changed it to 127.0.0.1 and the problem went away. Frankly I'm kind of surprised that IPv6 didn't just work anyway... I guess this is a bug for someone else though ;-) From jstodaro at us.ibm.com Wed Nov 1 15:11:26 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Wed, 1 Nov 2006 10:11:26 -0500 Subject: PATCH: depsolve-kill fix for plague-0.5.0 In-Reply-To: <1162317645.3155.40.camel@localhost.localdomain> Message-ID: Dan Williams wrote on 10/31/2006 01:00:45 PM: > On Fri, 2006-10-27 at 02:01 -0400, Joe Todaro wrote: > > > > Hi, > > > > Has anyone ever seen a yum/depsolve-related error like this before in > > their *plague-0.5.0* build environment, and then tried *killing* the > > job that had caused it? This was problem three of three which I had > > mentioned in my previous posts. And it too had surfaced last week > > while we started stress-testing our buildsystem. Actually, the error > > you see below in itself was *not* the problem (we knew how to fix > > that) -- rather, it was the fact that we were *unable* to kill the job > > (plague-client kill 204) that was responsible for causing the error. > > Fix has been committed to HEAD, attaching the patch for your > convenience. Thank You - very much appreciated! Joe > > Thanks! > Dan > > > ====== THE ERROR ====== > > 204 (fuse-sshfs): Starting tag 'fuse-sshfs-1_6-4_ocrhel4' on target > > 'oc-rhel4-pre' > > 204 (fuse-sshfs): Requesting depsolve... > > 204 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386', > > 'i686']. > > Exception in thread PackageJob: 204/fuse-sshfs: > > Traceback (most recent call last): > > File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap > > self.run() > > File "/usr/share/plague/server/PackageJob.py", line 86, in run > > self._pkg_job.process() > > File "/usr/share/plague/server/PackageJob.py", line 753, in process > > if func(): > > File "/usr/share/plague/server/PackageJob.py", line 618, in > > _stage_depsolve > > if self._arch_deps_solved(arch) == False: > > File "/usr/share/plague/server/PackageJob.py", line 562, in > > _arch_deps_solved > > except yum.Errors.PackageSackError, exc: > > AttributeError: 'module' object has no attribute 'PackageSackError' > > > > ====== OUR FIX ====== > > We updated line 680 in the *die* method of the > > */usr/share/plague/server/PackageJob.py * module. Here's the patch: > > > > > > Again, can someone please review the fix.. We just want to make sure > > that it won't come back to *haunt* us later on / or possibly even be > > *masking* another problem. Thank you. > > > > -Joe > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > [attachment "old-yum-fixes.patch" deleted by Joe Todaro/Poughkeepsie/IBM] -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstodaro at us.ibm.com Wed Nov 1 18:34:07 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Wed, 1 Nov 2006 13:34:07 -0500 Subject: PATCH: depsolve-kill fix for plague-0.5.0 In-Reply-To: <1162317645.3155.40.camel@localhost.localdomain> Message-ID: Dan Williams wrote on 10/31/2006 01:00:45 PM: > On Fri, 2006-10-27 at 02:01 -0400, Joe Todaro wrote: > > > > Hi, > > > > Has anyone ever seen a yum/depsolve-related error like this before in > > their *plague-0.5.0* build environment, and then tried *killing* the > > job that had caused it? This was problem three of three which I had > > mentioned in my previous posts. And it too had surfaced last week > > while we started stress-testing our buildsystem. Actually, the error > > you see below in itself was *not* the problem (we knew how to fix > > that) -- rather, it was the fact that we were *unable* to kill the job > > (plague-client kill 204) that was responsible for causing the error. > > Fix has been committed to HEAD, attaching the patch for your > convenience. OK, I've installed the patch, restarted the server, and submitted the build request. Here's the error that occurred this time: 364 (fuse-sshfs): Starting tag 'fuse-sshfs-1_6-4_ocrhel4' on target 'oc-rhel4-pre' 364 (fuse-sshfs): Requesting depsolve... 364 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386']. Exception in thread PackageJob: 364/fuse-sshfs: Traceback (most recent call last): File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap self.run() File "/usr/share/plague/server/PackageJob.py", line 93, in run self._pkg_job.process() File "/usr/share/plague/server/PackageJob.py", line 741, in process if func(): File "/usr/share/plague/server/PackageJob.py", line 609, in _stage_depsolve if self._arch_deps_solved(arch) == False: File "/usr/share/plague/server/PackageJob.py", line 513, in _arch_deps_solved base.log = logger.Logger(threshold=threshold, file_object=sys.stdout) NameError: global name 'logger' is not defined Thanks again! Joe > > Thanks! > Dan > > > ====== THE ERROR ====== > > 204 (fuse-sshfs): Starting tag 'fuse-sshfs-1_6-4_ocrhel4' on target > > 'oc-rhel4-pre' > > 204 (fuse-sshfs): Requesting depsolve... > > 204 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386', > > 'i686']. > > Exception in thread PackageJob: 204/fuse-sshfs: > > Traceback (most recent call last): > > File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap > > self.run() > > File "/usr/share/plague/server/PackageJob.py", line 86, in run > > self._pkg_job.process() > > File "/usr/share/plague/server/PackageJob.py", line 753, in process > > if func(): > > File "/usr/share/plague/server/PackageJob.py", line 618, in > > _stage_depsolve > > if self._arch_deps_solved(arch) == False: > > File "/usr/share/plague/server/PackageJob.py", line 562, in > > _arch_deps_solved > > except yum.Errors.PackageSackError, exc: > > AttributeError: 'module' object has no attribute 'PackageSackError' > > > > ====== OUR FIX ====== > > We updated line 680 in the *die* method of the > > */usr/share/plague/server/PackageJob.py * module. Here's the patch: > > > > > > Again, can someone please review the fix.. We just want to make sure > > that it won't come back to *haunt* us later on / or possibly even be > > *masking* another problem. Thank you. > > > > -Joe > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > [attachment "old-yum-fixes.patch" deleted by Joe Todaro/Poughkeepsie/IBM] -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstodaro at us.ibm.com Wed Nov 1 19:25:05 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Wed, 1 Nov 2006 14:25:05 -0500 Subject: (Upd:) Re: PATCH: depsolve-kill fix for plague-0.5.0 In-Reply-To: Message-ID: Joe Todaro/Poughkeepsie/IBM wrote on 11/01/2006 01:33:47 PM: > Dan Williams wrote on 10/31/2006 01:00:45 PM: > > > On Fri, 2006-10-27 at 02:01 -0400, Joe Todaro wrote: > > > > > > Hi, > > > > > > Has anyone ever seen a yum/depsolve-related error like this before in > > > their *plague-0.5.0* build environment, and then tried *killing* the > > > job that had caused it? This was problem three of three which I had > > > mentioned in my previous posts. And it too had surfaced last week > > > while we started stress-testing our buildsystem. Actually, the error > > > you see below in itself was *not* the problem (we knew how to fix > > > that) -- rather, it was the fact that we were *unable* to kill the job > > > (plague-client kill 204) that was responsible for causing the error. > > > > Fix has been committed to HEAD, attaching the patch for your > > convenience. > > OK, I've installed the patch, restarted the server, and submitted the > build request. > > Here's the error that occurred this time: > > 364 (fuse-sshfs): Starting tag 'fuse-sshfs-1_6-4_ocrhel4' on target > 'oc-rhel4-pre' > 364 (fuse-sshfs): Requesting depsolve... > 364 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386']. > Exception in thread PackageJob: 364/fuse-sshfs: > Traceback (most recent call last): > File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap > self.run() > File "/usr/share/plague/server/PackageJob.py", line 93, in run > self._pkg_job.process() > File "/usr/share/plague/server/PackageJob.py", line 741, in process > if func(): > File "/usr/share/plague/server/PackageJob.py", line 609, in _stage_depsolve > if self._arch_deps_solved(arch) == False: > File "/usr/share/plague/server/PackageJob.py", line 513, in > _arch_deps_solved > base.log = logger.Logger(threshold=threshold, file_object=sys.stdout) > NameError: global name 'logger' is not defined I got it working tho in the meantime by removing the code 'logger.' from the beginning of the command on the next line: base.log = logger.Logger(threshold=threshold, file_object=sys.stdout) Here's the new error message, by the way, successfully reporting a package dependency we need t fix: 366 (fuse-sshfs): Requesting depsolve... 366 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386']. Exception in thread PackageJob: 366/fuse-sshfs: Traceback (most recent call last): File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap self.run() File "/usr/share/plague/server/PackageJob.py", line 93, in run self._pkg_job.process() File "/usr/share/plague/server/PackageJob.py", line 743, in process if func(): File "/usr/share/plague/server/PackageJob.py", line 610, in _stage_depsolve if self._arch_deps_solved(arch) == False: File "/usr/share/plague/server/PackageJob.py", line 548, in _arch_deps_solved pkg = base.returnPackageByDep(dep) File "__init__.py", line 1342, in returnPackageByDep YumBaseError: No Package found for fuse-devel Thanks so much!! Joe > > Thanks again! > Joe > > > > > Thanks! > > Dan > > > > > ====== THE ERROR ====== > > > 204 (fuse-sshfs): Starting tag 'fuse-sshfs-1_6-4_ocrhel4' on target > > > 'oc-rhel4-pre' > > > 204 (fuse-sshfs): Requesting depsolve... > > > 204 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386', > > > 'i686']. > > > Exception in thread PackageJob: 204/fuse-sshfs: > > > Traceback (most recent call last): > > > File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap > > > self.run() > > > File "/usr/share/plague/server/PackageJob.py", line 86, in run > > > self._pkg_job.process() > > > File "/usr/share/plague/server/PackageJob.py", line 753, in process > > > if func(): > > > File "/usr/share/plague/server/PackageJob.py", line 618, in > > > _stage_depsolve > > > if self._arch_deps_solved(arch) == False: > > > File "/usr/share/plague/server/PackageJob.py", line 562, in > > > _arch_deps_solved > > > except yum.Errors.PackageSackError, exc: > > > AttributeError: 'module' object has no attribute 'PackageSackError' > > > > > > ====== OUR FIX ====== > > > We updated line 680 in the *die* method of the > > > */usr/share/plague/server/PackageJob.py * module. Here's the patch: > > > > > > > > > Again, can someone please review the fix.. We just want to make sure > > > that it won't come back to *haunt* us later on / or possibly even be > > > *masking* another problem. Thank you. > > > > > > -Joe > > > -- > > > Fedora-buildsys-list mailing list > > > Fedora-buildsys-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > [attachment "old-yum-fixes.patch" deleted by Joe Todaro/Poughkeepsie/IBM] -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From arechenberg at resurgent.com Fri Nov 3 13:56:38 2006 From: arechenberg at resurgent.com (Andrew Rechenberg) Date: Fri, 03 Nov 2006 08:56:38 -0500 Subject: Mock - Anyway to override Obsoletes tag? Message-ID: <1162562198.12629.12.camel@cinshrlnxws01.shermfin.com> Good morning, I'm trying to use mock to build some Asterisk RPMs and mock is evidently using an Obsoletes tag in opal(-devel) to override a BuildRequires I have in my spec for openh323(-devel). I've built openh323(-devel) for FC6 and I've created a local repo and placed that local repo in the mock config for fedora-6-i386-core.cfg. The mock yum finds my openh323 RPMs (I can see if find it in the root.log) but I guess since opal contains an Obsoletes: openh323 tag mock is installing opal instead of my openh323 RPM. Obviously my build fails because it can't find the openh323 files it needs to properly build. Is there anyway to override the Obsoletes tag? Do I need to rebuild my openh323 RPM with another tag inside it's SPEC file? Please CC: me on any responses as I'm subscribed. Thanks, Andy. Confidentiality Notice: This e-mail message including attachments, if any, is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient, but do not wish to receive communications through this medium, please so advise the sender immediately. From rdieter at math.unl.edu Fri Nov 3 15:39:39 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Nov 2006 09:39:39 -0600 Subject: Mock - Anyway to override Obsoletes tag? References: <1162562198.12629.12.camel@cinshrlnxws01.shermfin.com> Message-ID: Andrew Rechenberg wrote: > Good morning, > > I'm trying to use mock to build some Asterisk RPMs and mock is evidently > using an Obsoletes tag in opal(-devel) to override a BuildRequires I > have in my spec for openh323(-devel). > > I've built openh323(-devel) for FC6 and I've created a local repo and > placed that local repo in the mock config for fedora-6-i386-core.cfg. > The mock yum finds my openh323 RPMs (I can see if find it in the > root.log) but I guess since opal contains an Obsoletes: openh323 tag > mock is installing opal instead of my openh323 RPM. Unversioned Obsoletes are bad, mm'kay? imo, file a bug against opal. In the meantime, maybe adding to your mock config something like: [main] ... exclude=opal* will do the trick. -- Rex From jstodaro at us.ibm.com Mon Nov 6 04:48:21 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Sun, 5 Nov 2006 23:48:21 -0500 Subject: PATCH: plague-0.5.0: PackageJob.py: NameError _and_ YumBaseError (unable to kill its job) Message-ID: ---- PROBLEM # 1 ---- Depsolve step keeps crashing due to a typo in the script: 364 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386']. Exception in thread PackageJob: 364/fuse-sshfs: [...snip...] > File "/usr/share/plague/server/PackageJob.py", line 513, in > _arch_deps_solved > base.log = logger.Logger(threshold=threshold, file_object=sys.stdout) > NameError: global name 'logger' is not defined ---- PROBLEM # 2 ---- Unable to kill any job that fails due to a missing package/s in the yum repos: > File "/usr/share/plague/server/PackageJob.py", line 548, in _arch_deps_solved > pkg = base.returnPackageByDep(dep) > File "__init__.py", line 1342, in returnPackageByDep > YumBaseError: No Package found for fuse-devel ---- PATCH ---- Here's the patch that resolved the above 2 problems for us: ----- REQUEST ---- Can someone please review it... especially the fix to PROBLEM # 2, that could potentially be masking a bigger problem.. Here's the code for your convenience (...these are the updates we made to the _latest_ version of PackageJob.py): $ cd /usr/share/plague/server $ diff PackageJob.py PackageJob.py.working 513c513 < base.log = logger.Logger(threshold=threshold, file_object=sys.stdout) --- > base.log = Logger(threshold=threshold, file_object=sys.stdout) 698c698 < if self._curstage == 'waiting': --- > if self._curstage in ['waiting', 'depsolve']: Thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PackageJob.py-NameError+YumBaseError-fix.patch Type: application/octet-stream Size: 957 bytes Desc: not available URL: From sodarock at gmail.com Thu Nov 9 00:16:31 2006 From: sodarock at gmail.com (John Villalovos) Date: Wed, 8 Nov 2006 16:16:31 -0800 Subject: Patch to buildsys-build.spec to support SuSE SLES Message-ID: <5e61b72f0611081616q5ab90ac1mf8a21ab124d7ecae@mail.gmail.com> Attached is a patch which adds support for SuSE Linux Enterprise Server (SLES) to the buildsys-build.spec file. It is kind of ugly, since they use a lot of RPMS in their build environment. I haven't tried to trim it. I used the information from Matt Domsch that he has posted at http://linux.dell.com/files/mock/buildgroups/sles10/i386/ I hope this is useful for others. John -------------- next part -------------- A non-text attachment was scrubbed... Name: buildsys-build.diff Type: application/octet-stream Size: 3274 bytes Desc: not available URL: From jkeating at redhat.com Thu Nov 9 01:38:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 8 Nov 2006 20:38:22 -0500 Subject: Announcing pungi-0.1.0 Message-ID: <200611082038.25862.jkeating@redhat.com> I am pleased (and scared) to announce the 0.1.0 release of pungi. This is the first release and thus it is a bit rough around the edges, but I firmly believe in release early release often. With this release pungi has the ability to gather packages and their deps from a given repo or set of repos, run anaconda tools to make installable trees, and create CD and DVD isos (DVD only if you ask for more than one CD). I have included some reference config files and a comps file I have been using to develop with. Currently pungi needs to be ran on the architecture you are composing for, although one could use mock with setarch as well. See README for more details on design and usage of pungi. To download pungi, visit http://linux.duke.edu/projects/pungi/release/ and pick up either the tarball, the source rpm, or the Fedora Core 6 binary rpm. Mercurial repo is http://linux.duke.edu/projects/pungi Discussion regarding the use or development of pungi happens on the fedora-buildsys-list mailing list: http://www.redhat.com/mailman/listinfo/fedora-buildsys-list Currently bugs are not tracked anywhere other than my inbox, I will most likely rectify this situation soon, but for now email works. Enjoy! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ndbecker2 at gmail.com Thu Nov 9 01:55:50 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 08 Nov 2006 20:55:50 -0500 Subject: Announcing pungi-0.1.0 References: <200611082038.25862.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > I am pleased (and scared) to announce the 0.1.0 release of pungi. This is > the first release and thus it is a bit rough around the edges, but I > firmly believe in release early release often. > > With this release pungi has the ability to gather packages and their deps > from a given repo or set of repos, run anaconda tools to make installable > trees, > and create CD and DVD isos (DVD only if you ask for more than one CD). I > have included some reference config files and a comps file I have been > using > to develop with. Currently pungi needs to be ran on the architecture you > are > composing for, although one could use mock with setarch as well. See > README for more details on design and usage of pungi. > > To download pungi, visit http://linux.duke.edu/projects/pungi/release/ and > pick up either the tarball, the source rpm, or the Fedora Core 6 binary > rpm. > Mercurial repo is http://linux.duke.edu/projects/pungi Discussion > regarding the use or development of pungi happens on the > fedora-buildsys-list mailing > list: http://www.redhat.com/mailman/listinfo/fedora-buildsys-list > Currently bugs are not tracked anywhere other than my inbox, I will most > likely rectify this situation soon, but for now email works. > > Enjoy! > Cool. In README, should that test be --version 6.89, rather than --release 6.89? From jkeating at redhat.com Thu Nov 9 02:22:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 8 Nov 2006 21:22:50 -0500 Subject: Announcing pungi-0.1.0 In-Reply-To: References: <200611082038.25862.jkeating@redhat.com> Message-ID: <200611082122.50732.jkeating@redhat.com> On Wednesday 08 November 2006 20:55, Neal Becker wrote: > In README, should that test be --version 6.89, rather than --release 6.89? fixed in hg. ta! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ndbecker2 at gmail.com Thu Nov 9 11:29:50 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 09 Nov 2006 06:29:50 -0500 Subject: Announcing pungi-0.1.0 References: <200611082038.25862.jkeating@redhat.com> Message-ID: Tried the test. Just went round in circles saying "finding deps for ..." or some words to that effect. I let it run overnight. Never got out of that loop. From jkeating at redhat.com Thu Nov 9 13:24:46 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 08:24:46 -0500 Subject: Announcing pungi-0.1.0 In-Reply-To: References: <200611082038.25862.jkeating@redhat.com> Message-ID: <200611090824.49538.jkeating@redhat.com> On Thursday 09 November 2006 06:29, Neal Becker wrote: > Tried the test. Just went round in circles saying "finding deps for ..." > or some words to that effect. I let it run overnight. Never got out of > that loop. What arch did you run it on, and did you change the comps file at all? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Nov 9 13:36:53 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 08:36:53 -0500 Subject: Announcing pungi-0.1.0 In-Reply-To: <200611090824.49538.jkeating@redhat.com> References: <200611082038.25862.jkeating@redhat.com> <200611090824.49538.jkeating@redhat.com> Message-ID: <200611090836.53753.jkeating@redhat.com> On Thursday 09 November 2006 08:24, Jesse Keating wrote: > On Thursday 09 November 2006 06:29, Neal Becker wrote: > > Tried the test. ?Just went round in circles saying "finding deps for ..." > > or some words to that effect. ?I let it run overnight. ?Never got out of > > that loop. > > What arch did you run it on, and did you change the comps file at all? oh wait, I forgot about this. There was/is a bug in yum that made package comparison not work quite right. It was fixed upstream and I thought we issued an update for FC6 that would resolve this. Seth? Jeremy? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Thu Nov 9 13:51:58 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 09 Nov 2006 08:51:58 -0500 Subject: Announcing pungi-0.1.0 In-Reply-To: <200611090836.53753.jkeating@redhat.com> References: <200611082038.25862.jkeating@redhat.com> <200611090824.49538.jkeating@redhat.com> <200611090836.53753.jkeating@redhat.com> Message-ID: <1163080318.13997.0.camel@cutter> On Thu, 2006-11-09 at 08:36 -0500, Jesse Keating wrote: > On Thursday 09 November 2006 08:24, Jesse Keating wrote: > > On Thursday 09 November 2006 06:29, Neal Becker wrote: > > > Tried the test. Just went round in circles saying "finding deps for ..." > > > or some words to that effect. I let it run overnight. Never got out of > > > that loop. > > > > What arch did you run it on, and did you change the comps file at all? > > oh wait, I forgot about this. There was/is a bug in yum that made package > comparison not work quite right. It was fixed upstream and I thought we > issued an update for FC6 that would resolve this. 1. it was in 3.0-6 2. it's included in the yum 3.0.1 release tarball. -sv From jkeating at redhat.com Thu Nov 9 14:00:54 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Nov 2006 09:00:54 -0500 Subject: Announcing pungi-0.1.0 In-Reply-To: <1163080318.13997.0.camel@cutter> References: <200611082038.25862.jkeating@redhat.com> <200611090836.53753.jkeating@redhat.com> <1163080318.13997.0.camel@cutter> Message-ID: <200611090900.55086.jkeating@redhat.com> On Thursday 09 November 2006 08:51, seth vidal wrote: > 1. it was in 3.0-6 Actually I just verified that it missed 3.0-6. My test box had yum patched locally :/ > 2. it's included in the yum 3.0.1 release tarball. I'm asking our yum maintainer(s) to issue an update for FC-6 so that this will work correctly. It should work in rawhide too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Fri Nov 10 04:34:11 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 09 Nov 2006 22:34:11 -0600 Subject: Initial EPEL mock config Message-ID: <1163133251.6548.5.camel@vader.jdub.homelinux.org> Hi All, Below is an initial EPEL config. I'm not quite sure where packages will go, and I'm not sure if the CentOS base and updates are correct but I thought I would get this discussion started since EPEL is starting to move. Please review and let me know your thoughts. Again, this is just an example for now. thx, josh #!/usr/bin/python -tt import os config_opts['root'] = 'epel-4-i386' config_opts['target_arch'] = 'i386' config_opts['yum.conf'] = """ [main] cachdir=/var/cache/yum debuglevel=1 logfile=/var/log/yum.log reposdir=/dev/null retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 # repos [core] name=base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os [update] name=updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates [groups] name=groups baseurl=http://buildsys.fedoraproject.org/buildgroups/rhel4/i386/ [extras] name=epel mirrorlist=http://fedora.redhat.com/download/mirrors/epel-4 [local] name=local baseurl=http://buildsys.fedoraproject.org/plague-results/epel-4/ From dennis at ausil.us Fri Nov 10 05:28:01 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 9 Nov 2006 23:28:01 -0600 Subject: Initial EPEL mock config In-Reply-To: <1163133251.6548.5.camel@vader.jdub.homelinux.org> References: <1163133251.6548.5.camel@vader.jdub.homelinux.org> Message-ID: <200611092328.02803.dennis@ausil.us> On Thursday 09 November 2006 22:34, Josh Boyer wrote: > Hi All, > > Below is an initial EPEL config. I'm not quite sure where packages will > go, and I'm not sure if the CentOS base and updates are correct but I > thought I would get this discussion started since EPEL is starting to > move. > > Please review and let me know your thoughts. Again, this is just an > example for now. > > thx, > josh > > #!/usr/bin/python -tt > import os > config_opts['root'] = 'epel-4-i386' > config_opts['target_arch'] = 'i386' > > config_opts['yum.conf'] = """ > [main] > cachdir=/var/cache/yum > debuglevel=1 > logfile=/var/log/yum.log > reposdir=/dev/null > retries=20 > obsoletes=1 > gpgcheck=0 > assumeyes=1 > > # repos CentOS ones look good except we should hardcode the arch and version we are not going to have that info on the local system. [core] name=base mirrorlist=http://mirrorlist.centos.org/?release=4&arch=i386&repo=os [update] name=updates mirrorlist=http://mirrorlist.centos.org/?release=4&arch=i386&repo=updates [groups] name=groups baseurl=http://buildsys.fedoraproject.org/buildgroups/rhel4/i386/ [extras] name=epel mirrorlist=http://fedora.redhat.com/download/mirrors/epel-4 we should have it added to the mirror system so that users will get current local mirrors [local] name=local baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/ thats the correct url missing the fedora- -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From jwboyer at jdub.homelinux.org Fri Nov 10 14:40:36 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 10 Nov 2006 08:40:36 -0600 Subject: Initial EPEL mock config In-Reply-To: <200611092328.02803.dennis@ausil.us> References: <1163133251.6548.5.camel@vader.jdub.homelinux.org> <200611092328.02803.dennis@ausil.us> Message-ID: <1163169636.16990.1.camel@vader.jdub.homelinux.org> On Thu, 2006-11-09 at 23:28 -0600, Dennis Gilmore wrote: > > # repos > CentOS ones look good except we should hardcode the arch and version we are > not going to have that info on the local system. Ah right. > > > [core] > name=base > mirrorlist=http://mirrorlist.centos.org/?release=4&arch=i386&repo=os > > [update] > name=updates > mirrorlist=http://mirrorlist.centos.org/?release=4&arch=i386&repo=updates > > [groups] > name=groups > baseurl=http://buildsys.fedoraproject.org/buildgroups/rhel4/i386/ > > [extras] > name=epel > mirrorlist=http://fedora.redhat.com/download/mirrors/epel-4 > > we should have it added to the mirror system so that users will get current > local mirrors Yes, I agree. > > [local] > name=local > baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/ > > thats the correct url missing the fedora- So what exactly would be the full URL then? I'm slightly confused. josh From dennis at ausil.us Fri Nov 10 16:58:56 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 10 Nov 2006 10:58:56 -0600 Subject: Initial EPEL mock config In-Reply-To: <1163169636.16990.1.camel@vader.jdub.homelinux.org> References: <1163133251.6548.5.camel@vader.jdub.homelinux.org> <200611092328.02803.dennis@ausil.us> <1163169636.16990.1.camel@vader.jdub.homelinux.org> Message-ID: <200611101059.00802.dennis@ausil.us> Once upon a time Friday 10 November 2006 8:40 am, Josh Boyer wrote: > On Thu, 2006-11-09 at 23:28 -0600, Dennis Gilmore wrote: > > > [local] > > name=local > > baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/ > > > > thats the correct url missing the fedora- > > So what exactly would be the full URL then? I'm slightly confused. that is the coreect url you had http://buildsys.fedoraproject.org/plague-results/4-epel/ Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mail-lists at karan.org Sat Nov 11 01:21:59 2006 From: mail-lists at karan.org (Karanbir Singh) Date: Sat, 11 Nov 2006 01:21:59 +0000 Subject: Initial EPEL mock config In-Reply-To: <1163133251.6548.5.camel@vader.jdub.homelinux.org> References: <1163133251.6548.5.camel@vader.jdub.homelinux.org> Message-ID: <455525B7.9080102@karan.org> Josh Boyer wrote: With this : > gpgcheck=0 > assumeyes=1 > mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os you really dont want mirrorurls from outside mirror.centos.org ... just my 2 bits worth.. - KB -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq From dcbw at redhat.com Mon Nov 13 20:26:58 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 13 Nov 2006 15:26:58 -0500 Subject: PATCH: plague-0.5.0: PackageJob.py: NameError _and_ YumBaseError (unable to kill its job) In-Reply-To: References: Message-ID: <1163449618.9199.5.camel@localhost.localdomain> On Sun, 2006-11-05 at 23:48 -0500, Joe Todaro wrote: > > ---- PROBLEM # 1 ---- Depsolve step keeps crashing due to a typo in > the script: > > 364 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386']. > Exception in thread PackageJob: 364/fuse-sshfs: > [...snip...] > > File "/usr/share/plague/server/PackageJob.py", line 513, in > > _arch_deps_solved > > base.log = logger.Logger(threshold=threshold, > file_object=sys.stdout) > > NameError: global name 'logger' is not defined Fixed, thanks! > > ---- PROBLEM # 2 ---- Unable to kill any job that fails due to a > missing package/s in the yum repos: > > > File "/usr/share/plague/server/PackageJob.py", line 548, in > _arch_deps_solved > > pkg = base.returnPackageByDep(dep) > > File "__init__.py", line 1342, in returnPackageByDep > > YumBaseError: No Package found for fuse-devel What version of yum do you have on this machine? The versions of the yum python libraries are a bit confusing here; and that's probably where the error is coming from. It appears that an unexpected error is getting thrown, and we need to catch that error. However, I'm not sure where exactly it's coming from to catch it. Can you try to get this error again and then paste in about 10 lines of code from around the Line # in PackageJob.py that this backtrace comes from? (ie, line 548 here), and mark the line numbers too? The fix you posted for this hunk isn't the "correct" fix; that would be to catch the exception and to re-throw it as a DepSolveError as is done for the other 'execpt' blocks around there. Cheers, Dan > > ---- PATCH ---- > > Here's the patch that resolved the above 2 problems for us: > > > > ----- REQUEST ---- > > Can someone please review it... especially the fix to PROBLEM # 2, > that could potentially be masking a bigger problem.. > > Here's the code for your convenience (...these are the updates we made > to the _latest_ version of PackageJob.py): > > $ cd /usr/share/plague/server > $ diff PackageJob.py PackageJob.py.working > 513c513 > < base.log = logger.Logger(threshold=threshold, > file_object=sys.stdout) > --- > > base.log = Logger(threshold=threshold, > file_object=sys.stdout) > 698c698 > < if self._curstage == 'waiting': > --- > > if self._curstage in ['waiting', 'depsolve']: > > > Thanks, > Joe > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From jeroen.janssen at gmail.com Tue Nov 14 13:16:53 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Tue, 14 Nov 2006 14:16:53 +0100 Subject: pungi & checking dependencies? Message-ID: Hello, I'm trying to run the latest pungi on a fresh Fedora Core 6 installation. >From the README it states how to test it, so I ran (as root) the following command: pungi --comps /etc/pungi/comps.xml \ --yumconf /etc/pungi/yum.conf.i386 --destdir /srv/pungi \ --cachedir /srv/pungi/cache --arch i386 --release 6.89 \ --discs 1 (note I'm going for an i386 installation, this is different from the README). Now I'm looking at a large list of "Checking deps of" logging, pungi has been using 14m CPU, 117Mb Virt Memory and no sign of 'real' progress. A small snippet of the output: Checking deps of libgcc.i386 Checking deps of python.i386 Checking deps of glibc.i386 Checking deps of glib2.i386 Checking deps of glibc.i686 Checking deps of glibc.i686 Checking deps of glibc.i686 Checking deps of glibc.i386 Checking deps of glibc.i686 Checking deps of glibc.i686 Checking deps of glibc.i686 Checking deps of glibc.i386 Checking deps of glibc.i386 Checking deps of glibc.i686 Checking deps of bash.i386 Checking deps of glibc.i386 Checking deps of beecrypt.i386 Checking deps of glibc.i386 Checking deps of glibc.i686 Checking deps of glibc.i386 Checking deps of basesystem.noarch Checking deps of bzip2-libs.i386 Checking deps of glibc.i686 * Any idea if this is expected to behave as I am currently seeing? * How long should it take on a P4 3GHz with 512Mb RAM? * Is it normal that glibc tends to be 'checked' a lot? Best regards, Jeroen Janssen From jkeating at redhat.com Tue Nov 14 13:34:49 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Nov 2006 08:34:49 -0500 Subject: pungi & checking dependencies? In-Reply-To: References: Message-ID: <200611140834.50088.jkeating@redhat.com> On Tuesday 14 November 2006 08:16, Jeroen Janssen wrote: > * Any idea if this is expected to behave as I am currently seeing? > > * How long should it take on a P4 3GHz with 512Mb RAM? > > * Is it normal that glibc tends to be 'checked' a lot? There is a bug with the shipped yum of FC6 that makes yum not able to mark any two package objects as being equal, so pungi gets lost in an infinite loop of resolving deps it doesn't already have. I do believe there is a yum update in updates-testing that will fix this issue, as does the yum in rawhide. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Tue Nov 14 14:44:44 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Tue, 14 Nov 2006 15:44:44 +0100 Subject: pungi & checking dependencies? In-Reply-To: <200611140834.50088.jkeating@redhat.com> References: <200611140834.50088.jkeating@redhat.com> Message-ID: On 11/14/06, Jesse Keating wrote: > On Tuesday 14 November 2006 08:16, Jeroen Janssen wrote: > > * Any idea if this is expected to behave as I am currently seeing? > > > > * How long should it take on a P4 3GHz with 512Mb RAM? > > > > * Is it normal that glibc tends to be 'checked' a lot? > > There is a bug with the shipped yum of FC6 that makes yum not able to mark any > two package objects as being equal, so pungi gets lost in an infinite loop of > resolving deps it doesn't already have. I do believe there is a yum update > in updates-testing that will fix this issue, as does the yum in rawhide. Ok, thanks for the information.. I upgraded to yum-3.0.1-2.fc6.noarch.rpm from a local fedora/updates/testing/6/i386/ mirror and it seems to work ok now (dependency checks are finished), pungi is now doing other things :) I'll let you know on the progress. Best regards, Jeroen Janssen From esammons at hush.com Tue Nov 14 21:00:29 2006 From: esammons at hush.com (Earl) Date: Tue, 14 Nov 2006 16:00:29 -0500 Subject: pungi + existing rpm base Message-ID: <20061114210030.CDF0DDA84C@mailserver8.hushmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse, Thanks for creating pungi! Any ideas on how to utilize pungi with an exisintg rpm base? i.e. I already have a hacked up remastering process and an existing dir full of standard Fedora CORE plus some custom RPMs and I would like to try pungi out on it? Maybe create a comps.xml based on the dir full of RPMs then create a local yum repo with all of the RPMs? If thats it, how do you create comps.xml from a dir full of RPMs? Other suggestions? Earl -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wkYEARECAAYFAkVaR8IACgkQk7+e+4lPSm2BBgCgl7445VAa5pT7fUU7EZL96xMtpzcA n2MzP+YMy6Yc6HnSCX6NYce7ZMNb =p1Lu -----END PGP SIGNATURE----- From jkeating at redhat.com Tue Nov 14 22:07:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Nov 2006 17:07:22 -0500 Subject: pungi + existing rpm base In-Reply-To: <20061114210030.CDF0DDA84C@mailserver8.hushmail.com> References: <20061114210030.CDF0DDA84C@mailserver8.hushmail.com> Message-ID: <200611141707.25730.jkeating@redhat.com> On Tuesday 14 November 2006 16:00, Earl wrote: > Any ideas on how to utilize pungi with an exisintg rpm base? ?i.e. > I already have a hacked up remastering process and an existing dir > full of ?standard Fedora CORE plus some custom RPMs and I would > like to try pungi out on it? > > Maybe create a comps.xml based on the dir full of RPMs then create > a local yum repo with all of the RPMs? ?If thats it, how do you > create comps.xml from a dir full of RPMs? > > Other suggestions? The first step is indeed creating a repo out of it. After that, yeah, welcome to the hell that is comps :/ I really don't want comps to be the interface that users are exposed to in the future, but for now it is. Luckily since pungi does dep resolution, you don't need to list every single package. Instead what you need to list is the high level packages you care about (plus kernel) and allow dep resolution to figure out exactly what you need. I'd take the comps.xml pungi ships with and just replace the package names with which packages you want. Experiment with the high level packages and see what pungi pulls in for deps until you get the set that has the functionality you want. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Wed Nov 15 07:54:06 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Wed, 15 Nov 2006 08:54:06 +0100 Subject: pungi & checking dependencies? In-Reply-To: References: <200611140834.50088.jkeating@redhat.com> Message-ID: Hi, Btw... I got the following error when trying the test commandline from the README: usage: ./pungi [options] pungi: error: no such option: --release So I ran without the --release option and after a lot of crunching I got a Fedora-test-i386-disc1.iso . However when I try to boot from this iso (with qemu) I get the error that "The Fedora CD was not found in any of your CDROM drives". So it seems I'm (still) doing something wrong. Are there some configuration files/examples of howto run pungi that results in something that is "known to work correctly"? Best regards, Jeroen Janssen On 11/14/06, Jeroen Janssen wrote: > On 11/14/06, Jesse Keating wrote: > > On Tuesday 14 November 2006 08:16, Jeroen Janssen wrote: > > > * Any idea if this is expected to behave as I am currently seeing? > > > > > > * How long should it take on a P4 3GHz with 512Mb RAM? > > > > > > * Is it normal that glibc tends to be 'checked' a lot? > > > > There is a bug with the shipped yum of FC6 that makes yum not able to mark any > > two package objects as being equal, so pungi gets lost in an infinite loop of > > resolving deps it doesn't already have. I do believe there is a yum update > > in updates-testing that will fix this issue, as does the yum in rawhide. > > Ok, thanks for the information.. > > I upgraded to yum-3.0.1-2.fc6.noarch.rpm from a local > fedora/updates/testing/6/i386/ mirror and it seems to work ok now > (dependency checks are finished), pungi is now doing other things :) > > I'll let you know on the progress. > > Best regards, > > Jeroen Janssen > From jkeating at redhat.com Wed Nov 15 12:36:45 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 07:36:45 -0500 Subject: pungi & checking dependencies? In-Reply-To: References: Message-ID: <200611150736.46047.jkeating@redhat.com> On Wednesday 15 November 2006 02:54, Jeroen Janssen wrote: > Btw... I got the following error when trying the test commandline from > the README: > > usage: ./pungi [options] > pungi: error: no such option: --release > > So I ran without the --release option and after a lot of crunching I > got a Fedora-test-i386-disc1.iso . > However when I try to boot from this iso (with qemu) I get the error > that "The Fedora CD was not found in any of your CDROM drives". > > So it seems I'm (still) doing something wrong. > > Are there some configuration files/examples of howto run pungi that > results in something that is "known to work correctly"? This was my fault in the package release. The REAME should have read --version not --release. I fixed it in upstream hg, but I haven't issued a package update yet. I've been doing exactly what the README states (modulo /release/version/) and it results in bootable CDs/DVDs. Have you modified the comps file at all? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Wed Nov 15 14:08:25 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Wed, 15 Nov 2006 15:08:25 +0100 Subject: pungi & checking dependencies? In-Reply-To: <200611150736.46047.jkeating@redhat.com> References: <200611150736.46047.jkeating@redhat.com> Message-ID: Hi, I yum.conf.i386 I updated the mirrorlist to state: mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=core-6&arch=i386 After this I got a 434Mb iso file that works ok (I can boot it & perform an installation). So, maybe because I was using the rawhide (testing?) mirrorlist, that caused it to fail before? --- Jeroen Janssen On 11/15/06, Jesse Keating wrote: > On Wednesday 15 November 2006 02:54, Jeroen Janssen wrote: > > Btw... I got the following error when trying the test commandline from > > the README: > > > > usage: ./pungi [options] > > pungi: error: no such option: --release > > > > So I ran without the --release option and after a lot of crunching I > > got a Fedora-test-i386-disc1.iso . > > However when I try to boot from this iso (with qemu) I get the error > > that "The Fedora CD was not found in any of your CDROM drives". > > > > So it seems I'm (still) doing something wrong. > > > > Are there some configuration files/examples of howto run pungi that > > results in something that is "known to work correctly"? > > This was my fault in the package release. The REAME should have > read --version not --release. I fixed it in upstream hg, but I haven't > issued a package update yet. > > I've been doing exactly what the README states (modulo /release/version/) and > it results in bootable CDs/DVDs. Have you modified the comps file at all? > > -- > Jesse Keating > Release Engineer: Fedora > > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > > From jkeating at redhat.com Wed Nov 15 14:13:29 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 09:13:29 -0500 Subject: pungi & checking dependencies? In-Reply-To: References: <200611150736.46047.jkeating@redhat.com> Message-ID: <200611150913.30083.jkeating@redhat.com> On Wednesday 15 November 2006 09:08, Jeroen Janssen wrote: > So, maybe because I was using the rawhide (testing?) mirrorlist, that > caused it to fail before? Quite possibly. Rawhide may not be the most stable target for testing. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Wed Nov 15 14:28:40 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Wed, 15 Nov 2006 15:28:40 +0100 Subject: pungi & minimal installation iso? Message-ID: Hi, I was wondering what exactly is needed in the comps.xml to create a minimal (fedora core 6) installation CD (the list of packages that are a absolute minimum to have) If I make an 'empty' list, pungi fails because the list is empty :) If if leave out anaconda-runtime, the building of the iso fails. Apparently anaconda-runtime pulls a lot of stuff into the iso (xorg for example). If I wanted to create an installation CD (with kickstart) that shouldn't have xorg "during" install, is this possible with the default anaconda packages? Or does this require customization (if at all possible?) Should I ask these questions on another mailinglist? Best regards, Jeroen Janssen From jkeating at redhat.com Wed Nov 15 14:33:57 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 09:33:57 -0500 Subject: pungi & minimal installation iso? In-Reply-To: References: Message-ID: <200611150934.00639.jkeating@redhat.com> On Wednesday 15 November 2006 09:28, Jeroen Janssen wrote: > I was wondering what exactly is needed in the comps.xml to create a > minimal (fedora core 6) installation CD (the list of packages that are > a absolute minimum to have) > > If I make an 'empty' list, pungi fails because the list is empty :) > If if leave out anaconda-runtime, the building of the iso fails. > > Apparently anaconda-runtime pulls a lot of stuff into the iso (xorg > for example). > > If I wanted to create an installation CD (with kickstart) that > shouldn't have xorg "during" install, is this possible with the > default anaconda packages? Or does this require customization (if at > all possible?) Should I ask these questions on another mailinglist? Currently you can't do this with pungi, due to the way that Anaconda works. I could make pungi use a different set of packages to do the buildinstall than what it ships, but changes in Anaconda are coming so that you don't need all the gui stuff at buildinstall time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Wed Nov 15 14:40:14 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Wed, 15 Nov 2006 15:40:14 +0100 Subject: pungi bug with cache on 2nd run? Message-ID: Hi, In pypungi/gather.py line 123 there is an os.link call that results in a OSError [errno 17] file already exists. This happens when running pungi for the second time (without cleaning up the cache directory. My guess is this is a slight 'copy-paste' bug, but I'm not sure. Can you please confirm this? Best regards, Jeroen Janssen From jkeating at redhat.com Wed Nov 15 14:43:31 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 09:43:31 -0500 Subject: pungi bug with cache on 2nd run? In-Reply-To: References: Message-ID: <200611150943.31362.jkeating@redhat.com> On Wednesday 15 November 2006 09:40, Jeroen Janssen wrote: > In pypungi/gather.py line 123 there is an os.link call that results in > a OSError [errno 17] file already exists. > > This happens when running pungi for the second time (without cleaning > up the cache directory. My guess is this is a slight 'copy-paste' bug, > but I'm not sure. Can you please confirm this? The cache directory can stay "dirty", the rest of the target directory tree must go. You're seeing it try to copy from the cache to the target directory and the target directory already has the file there / already exists. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From orion at cora.nwra.com Thu Nov 16 18:47:56 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 16 Nov 2006 11:47:56 -0700 Subject: Problem with file: URLs Message-ID: <455CB25C.6050906@cora.nwra.com> I'm trying with the following yum.conf.x86_64: [main] cachedir=/tmp/fist #keepcache=0 #debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release tolerant=1 exactarch=1 obsoletes=1 gpgcheck=1 reposdir=./ #plugins=1 metadata_expire=1800 #exclude=\*.i?86 # repos [core] name=core baseurl=file:///data/sw1/fedora/core/6/x86_64/os/ enabled=1 [updates-released] name=updates baseurl=file:///data/sw1/fedora/core/updates/6/x86_64/ enabled=1 [extras] name=extras baseurl=file:///data/sw1/fedora/extras/6/x86_64/ enabled=1 [local] name=local baseurl=file:///data/sw1/fedora/CoRPMS/6/x86_64/ enabled=1 pungi runs through the dependencies then chokes on the first download: Downloading pango-1.14.6-2.fc6.i386.rpm Traceback (most recent call last): File "/usr/bin/pungi", line 100, in ? main() File "/usr/bin/pungi", line 42, in main mygather.downloadPackages() File "/usr/lib/python2.4/site-packages/pypungi/gather.py", line 132, in downloadPackages os.link(local, os.path.join(pkgdir, os.path.basename(remote))) OSError: [Errno 2] No such file or directory but it is there: # ls -l /data/sw1/fedora/core/updates/6/x86_64/pango-1.14.6-2.fc6.i386.rpm -rw-r--r-- 1 537 537 336675 Oct 30 11:53 /data/sw1/fedora/core/updates/6/x86_64/pango-1.14.6-2.fc6.i386.rpm (Pdb) print local pungi/cache/pango-1.14.6-2.fc6.i386.rpm (Pdb) print pkgdir ./6/x86_64/os/Fedora (Pdb) print os.path.basename(remote) pango-1.14.6-2.fc6.i386.rpm Looks like repo.getPackage(pkg) doesn't actually do anything if it is a file: url: repo.getPackage(pkg) os.link(local, os.path.join(pkgdir, os.path.basename(remote))) so there is nothing to link when we get to os.link. Looks like for file: urls we'll need to find the path to the package in the repo and link (or copy, if needed) that -- Orion Poplawski System Administrator 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 16 21:38:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Nov 2006 16:38:22 -0500 Subject: Problem with file: URLs In-Reply-To: <455CB25C.6050906@cora.nwra.com> References: <455CB25C.6050906@cora.nwra.com> Message-ID: <200611161638.25552.jkeating@redhat.com> On Thursday 16 November 2006 13:47, Orion Poplawski wrote: > Looks like repo.getPackage(pkg) doesn't actually do anything if it is a > file: url: > > ? ? ? ? ? ? ?repo.getPackage(pkg) > ? ? ? ? ? ? ?os.link(local, os.path.join(pkgdir, os.path.basename(remote))) > > so there is nothing to link when we get to os.link. ?Looks like for > file: urls we'll need to find the path to the package in the repo and > link (or copy, if needed) that Yeah, I found this bug the other day, whoops :/ I'll be adding a work around. For now, you could turn your file:/// repo into a http://localhost repo with little effort, if it will keep you going. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jstodaro at us.ibm.com Sat Nov 18 03:43:00 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Fri, 17 Nov 2006 22:43:00 -0500 Subject: PATCH: plague-0.5.0: PackageJob.py: NameError _and_ YumBaseError (unable to kill its job) In-Reply-To: <1163449618.9199.5.camel@localhost.localdomain> Message-ID: Dan Williams wrote on 11/13/2006 03:26:58 PM: > On Sun, 2006-11-05 at 23:48 -0500, Joe Todaro wrote: > > > > ---- PROBLEM # 1 ---- Depsolve step keeps crashing due to a typo in > > the script: > > > > 364 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386']. > > Exception in thread PackageJob: 364/fuse-sshfs: > > [...snip...] > > > File "/usr/share/plague/server/PackageJob.py", line 513, in > > > _arch_deps_solved > > > base.log = logger.Logger(threshold=threshold, > > file_object=sys.stdout) > > > NameError: global name 'logger' is not defined > > Fixed, thanks! My pleasure - glad to help. > > > > > ---- PROBLEM # 2 ---- Unable to kill any job that fails due to a > > missing package/s in the yum repos: > > > > > File "/usr/share/plague/server/PackageJob.py", line 548, in > > _arch_deps_solved > > > pkg = base.returnPackageByDep(dep) > > > File "__init__.py", line 1342, in returnPackageByDep > > > YumBaseError: No Package found for fuse-devel > > What version of yum do you have on this machine? yum-2.4.2-2 > The versions of the > yum python libraries are a bit confusing here; and that's probably where > the error is coming from. It appears that an unexpected error is > getting thrown, and we need to catch that error. However, I'm not sure > where exactly it's coming from to catch it. Can you try to get this > error again and then paste in about 10 lines of code from around the > Line # in PackageJob.py that this backtrace comes from? (ie, line 548 > here), and mark the line numbers too? 537 try: 538 base.doSackSetup(archlist) 539 except yum.Errors.RepoError, exc: 540 raise DepError(str(exc)) 541 542 for dep in srpm.requiresList(): 543 if dep.startswith("rpmlib("): 544 continue 545 if use_repomd: 546 try: 547 pkg = base.returnPackageByDep(dep) 548 except repomd.mdErrors.PackageSackError, exc: 549 raise DepError(str(exc)) 550 else: 551 try: 552 pkg = base.returnPackageByDep(dep) 553 except yum.Errors.PackageSackError, exc: 554 raise DepError(str(exc)) 555 except yum.Errors.YumBaseError, exc: 556 raise DepError(str(exc)) 557 except DepError, exc: 558 self._last_depsolve_error = str(exc) 559 print "%s (%s/%s): Depsolve Error: %s" % (self.uid, self.package, arch, str(exc)) 560 success = False > > The fix you posted for this hunk isn't the "correct" fix; Actually, it wasn't intended to "fix" the (YumBaseError) problem itself -- rather it was just intended to provide us with a means by which we'd be able to "recover* from the negative effects of the problem, which was a plague-server that wouldn't allow us to *kill* the associated buildjob because the buildjob wasn't in "waiting" state -- it was in "depsolve" which is where it got stuck. Anyway, recycling the plague-server did not help -- it just kept restarting the buildjob which just kept failing in the same place even after we downloaded the missing package (fuse-devel) to the yum repo and ran the createrepo command in-between plague-server restarts. > that would be > to catch the exception and to re-throw it as a DepSolveError as is done > for the other 'execpt' blocks around there. > > Cheers, > Dan > > > > > ---- PATCH ---- > > > > Here's the patch that resolved the above 2 problems for us: > > > > > > > > ----- REQUEST ---- > > > > Can someone please review it... especially the fix to PROBLEM # 2, > > that could potentially be masking a bigger problem.. > > > > Here's the code for your convenience (...these are the updates we made > > to the _latest_ version of PackageJob.py): > > > > $ cd /usr/share/plague/server > > $ diff PackageJob.py PackageJob.py.working > > 513c513 > > < base.log = logger.Logger(threshold=threshold, > > file_object=sys.stdout) > > --- > > > base.log = Logger(threshold=threshold, > > file_object=sys.stdout) > > 698c698 > > < if self._curstage == 'waiting': > > --- > > > if self._curstage in ['waiting', 'depsolve']: > > > > > > Thanks, > > Joe > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen.janssen at gmail.com Sat Nov 18 12:39:23 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Sat, 18 Nov 2006 13:39:23 +0100 Subject: OpenSUSE Build Service? Message-ID: Hi, I'm not sure if this is the correct Fedora mailinglist, but has anyone had a look at the OpenSuSe Build Service pages ( http://en.opensuse.org/Build_Service )? There are two presentations (from FOSDEM) about it and it seems they have also done some experimenting with building non SuSe distributions with this build system (like Fedora Core 4). Is this something that also could benefit the Fedora Project? Best regards, Jeroen Janssen From fedora at leemhuis.info Sat Nov 18 12:55:48 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 18 Nov 2006 13:55:48 +0100 Subject: OpenSUSE Build Service? In-Reply-To: References: Message-ID: <455F02D4.9090903@leemhuis.info> Jeroen Janssen schrieb: > I'm not sure if this is the correct Fedora mailinglist, but has anyone > had a look at the OpenSuSe Build Service pages ( > http://en.opensuse.org/Build_Service )? I posted some thoughts some days ago here: https://www.redhat.com/archives/fedora-advisory-board/2006-November/msg00124.html > Is this something that also could benefit the Fedora Project? I don't think so. I think we should make Fedora {Core,Extras,Alternatives,Legacy,Whatever} so good and flexible that something like that is not needed normally. Just my 2 cent. Cu thl From jeroen.janssen at gmail.com Sat Nov 18 14:32:57 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Sat, 18 Nov 2006 15:32:57 +0100 Subject: OpenSUSE Build Service? In-Reply-To: <455F02D4.9090903@leemhuis.info> References: <455F02D4.9090903@leemhuis.info> Message-ID: On 11/18/06, Thorsten Leemhuis wrote: > > Is this something that also could benefit the Fedora Project? > > I don't think so. I think we should make Fedora > {Core,Extras,Alternatives,Legacy,Whatever} so good and flexible that > something like that is not needed normally. Just my 2 cent. Well I was thinking about this in relation with Fedora's Plague Server ( http://www.fedoraproject.org/wiki/Projects/Plague ) which seems to have somewhat of a similar purpose : * Plague is a distributed package build system, suitable for building a whole Linux distribution (like Fedora Core), or for building additional packages (like Fedora Extras) * The openSUSE Build Service provides an infrastructure for the open development of future SUSE Linux-based distributions. Both have a "compile-farm architecture" for different target platform (archs). The projects seem to solve similar problems. --- Jeroen Janssen From jkeating at redhat.com Sat Nov 18 15:09:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 18 Nov 2006 10:09:17 -0500 Subject: OpenSUSE Build Service? In-Reply-To: References: <455F02D4.9090903@leemhuis.info> Message-ID: <200611181009.21666.jkeating@redhat.com> On Saturday 18 November 2006 09:32, Jeroen Janssen wrote: > The projects seem to solve similar problems. I think the major point here is that plague is open source, and all our rpms/srpms are freely available. You can setup your own "Fedora" buildfarm to build your packages. With OpenSuSE's buildstuff, can you get their build software? Can you install it on your own systems, tweak it for your own needs? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen.janssen at gmail.com Sat Nov 18 15:30:57 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Sat, 18 Nov 2006 16:30:57 +0100 Subject: OpenSUSE Build Service? In-Reply-To: <200611181009.21666.jkeating@redhat.com> References: <455F02D4.9090903@leemhuis.info> <200611181009.21666.jkeating@redhat.com> Message-ID: On 11/18/06, Jesse Keating wrote: > On Saturday 18 November 2006 09:32, Jeroen Janssen wrote: > > The projects seem to solve similar problems. > > I think the major point here is that plague is open source, and all our > rpms/srpms are freely available. You can setup your own "Fedora" buildfarm > to build your packages. With OpenSuSE's buildstuff, can you get their build > software? Can you install it on your own systems, tweak it for your own > needs? Well, maybe I should have mentioned it, but that is exactly my point : the OpenSuSe Build Service is also open source (GPLv2) . See also http://forge.novell.com/modules/xfmod/project/?opensuse for access to the sources. So basically, there are (at least) two opensource 'buildfarm' systems that are being developed now. I know that there are probably a lot differences between the SuSe and RedHat distributions, but it makes sense to me to check if their build system and plague can benefit from each other. --- Jeroen Janssen From jaroslav at aster.pl Sat Nov 18 15:31:15 2006 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Sat, 18 Nov 2006 16:31:15 +0100 Subject: OpenSUSE Build Service? In-Reply-To: <200611181009.21666.jkeating@redhat.com> References: <200611181009.21666.jkeating@redhat.com> Message-ID: <200611181631.23065.jaroslav@aster.pl> Dnia sobota, 18 listopada 2006 16:09, Jesse Keating napisa?: > On Saturday 18 November 2006 09:32, Jeroen Janssen wrote: > > The projects seem to solve similar problems. (...) > With OpenSuSE's buildstuff, can you get their > build software? Can you install it on your own systems, tweak it for your > own needs? In theory: yes ;) In practice: I didn't manage to browse project repository with this WebSVN (or whatever). I didn't manage to fetch sources via svn (although they provide an url - it doesn't work). Besides, IMVHO Novell-M$ agreement is a big obstacle here as well. -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Sun Nov 19 23:28:11 2006 From: dcbw at redhat.com (Dan Williams) Date: Sun, 19 Nov 2006 18:28:11 -0500 Subject: OpenSUSE Build Service? In-Reply-To: References: Message-ID: <1163978891.2881.17.camel@localhost.localdomain> On Sat, 2006-11-18 at 13:39 +0100, Jeroen Janssen wrote: > Hi, > > I'm not sure if this is the correct Fedora mailinglist, but has anyone > had a look at the OpenSuSe Build Service pages ( > http://en.opensuse.org/Build_Service )? > > There are two presentations (from FOSDEM) about it and it seems they > have also done some experimenting with building non SuSe distributions > with this build system (like Fedora Core 4). > > Is this something that also could benefit the Fedora Project? Having already written most of Plague by the time OSBS came out, I read over pretty much everything about it when it was announced last year. The purpose of the two do seem to overlap; however OSBS appears to have a much larger scope. It appears to try to be the one-stop shop for building _everything_ for any distribution with any build system or source-control system; which is fine. The pitch in those slides was basically "build your release packages on our buildsystem." I don't think we want such a wide scope and fuzzy focus. I think Fedora is better served by a specific, targetted system that builds _Fedora_ packages. That's a fairly parochial attitude, but one which I think is in the best interest of Fedora. Given that everyone working on and admining the Fedora Extras buildsystem is a volunteer, we don't need to be spreading our resources out even further supporting something like the OSBS. We should be concentrating on building excellent packages for Fedora, and arguably nothing else; we cannot be everything to everybody or we are doomed to fail. The building of packages is such an important and code piece of a distribution that it cannot _not_ be under the control of the project, and it cannot _not_ be _accountable_ to the project. As more of the Core responsibility gets spun out to the wider Fedora project, this only becomes more critical. We need to be able to admin the systems, we need to be able fix problems when they arise, we need to be able to demonstrate accountability and security of the buildsystem. Without that, there is no trust in the integrity of the distribution. Cheers, Dan > Best regards, > > Jeroen Janssen > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From dcbw at redhat.com Sun Nov 19 23:32:17 2006 From: dcbw at redhat.com (Dan Williams) Date: Sun, 19 Nov 2006 18:32:17 -0500 Subject: OpenSUSE Build Service? In-Reply-To: <200611181009.21666.jkeating@redhat.com> References: <455F02D4.9090903@leemhuis.info> <200611181009.21666.jkeating@redhat.com> Message-ID: <1163979137.2881.20.camel@localhost.localdomain> On Sat, 2006-11-18 at 10:09 -0500, Jesse Keating wrote: > On Saturday 18 November 2006 09:32, Jeroen Janssen wrote: > > The projects seem to solve similar problems. > > I think the major point here is that plague is open source, and all our > rpms/srpms are freely available. You can setup your own "Fedora" buildfarm > to build your packages. With OpenSuSE's buildstuff, can you get their build > software? Can you install it on your own systems, tweak it for your own > needs? Yeah, you can: http://en.opensuse.org/Build_Service#Build_Service_Source_Code While that says that "the forge svn server is having checkout problems" those problems appear to be solved as I could check out the sources. Dan > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From dcbw at redhat.com Sun Nov 19 23:34:31 2006 From: dcbw at redhat.com (Dan Williams) Date: Sun, 19 Nov 2006 18:34:31 -0500 Subject: PATCH: plague-0.5.0: PackageJob.py: NameError _and_ YumBaseError (unable to kill its job) In-Reply-To: References: Message-ID: <1163979271.2881.23.camel@localhost.localdomain> On Fri, 2006-11-17 at 22:43 -0500, Joe Todaro wrote: > > Dan Williams wrote on 11/13/2006 03:26:58 PM: > > > On Sun, 2006-11-05 at 23:48 -0500, Joe Todaro wrote: > > > > > > ---- PROBLEM # 1 ---- Depsolve step keeps crashing due to a typo > in > > > the script: > > > > > > 364 (fuse-sshfs): Starting depsolve for arches: ['x86_64', > 'i386']. > > > Exception in thread PackageJob: 364/fuse-sshfs: > > > [...snip...] > > > > File "/usr/share/plague/server/PackageJob.py", line 513, in > > > > _arch_deps_solved > > > > base.log = logger.Logger(threshold=threshold, > > > file_object=sys.stdout) > > > > NameError: global name 'logger' is not defined > > > > Fixed, thanks! > > My pleasure - glad to help. > > > > > > > > > ---- PROBLEM # 2 ---- Unable to kill any job that fails due to a > > > missing package/s in the yum repos: > > > > > > > File "/usr/share/plague/server/PackageJob.py", line 548, in > > > _arch_deps_solved > > > > pkg = base.returnPackageByDep(dep) > > > > File "__init__.py", line 1342, in returnPackageByDep > > > > YumBaseError: No Package found for fuse-devel > > > > What version of yum do you have on this machine? > > yum-2.4.2-2 Ok, can you do the following, so we can find out which module YumBaseError lives in in yum-2.4.2/yum-utils: grep -r "YumBaseError" /usr/lib/python2.3/site-packages (or if you have python 2.4, use python2.4 instead of course). Thanks, Dan > > > The versions of the > > yum python libraries are a bit confusing here; and that's probably > where > > the error is coming from. It appears that an unexpected error is > > getting thrown, and we need to catch that error. However, I'm not > sure > > where exactly it's coming from to catch it. Can you try to get this > > error again and then paste in about 10 lines of code from around the > > Line # in PackageJob.py that this backtrace comes from? (ie, line > 548 > > here), and mark the line numbers too? > > 537 try: > 538 base.doSackSetup(archlist) > 539 except yum.Errors.RepoError, exc: > 540 raise DepError(str(exc)) > 541 > 542 for dep in srpm.requiresList(): > 543 if dep.startswith("rpmlib("): > 544 continue > 545 if use_repomd: > 546 try: > 547 pkg = base.returnPackageByDep(dep) > 548 except repomd.mdErrors.PackageSackError, > exc: > 549 raise DepError(str(exc)) > 550 else: > 551 try: > 552 pkg = base.returnPackageByDep(dep) > 553 except yum.Errors.PackageSackError, exc: > 554 raise DepError(str(exc)) > 555 except yum.Errors.YumBaseError, exc: > 556 raise DepError(str(exc)) > 557 except DepError, exc: > 558 self._last_depsolve_error = str(exc) > 559 print "%s (%s/%s): Depsolve Error: %s" % > (self.uid, self.package, arch, str(exc)) > 560 success = False > > > > > The fix you posted for this hunk isn't the "correct" fix; > > Actually, it wasn't intended to "fix" the (YumBaseError) problem > itself -- rather it was just intended to provide us with a means by > which we'd be able to "recover* from the negative effects of the > problem, which was a plague-server that wouldn't allow us to *kill* > the associated buildjob because the buildjob wasn't in "waiting" > state -- it was in "depsolve" which is where it got stuck. Anyway, > recycling the plague-server did not help -- it just kept restarting > the buildjob which just kept failing in the same place even after we > downloaded the missing package (fuse-devel) to the yum repo and ran > the createrepo command in-between plague-server restarts. > > > that would be > > to catch the exception and to re-throw it as a DepSolveError as is > done > > for the other 'execpt' blocks around there. > > > > Cheers, > > Dan > > > > > > > > ---- PATCH ---- > > > > > > Here's the patch that resolved the above 2 problems for us: > > > > > > > > > > > > ----- REQUEST ---- > > > > > > Can someone please review it... especially the fix to PROBLEM # 2, > > > that could potentially be masking a bigger problem.. > > > > > > Here's the code for your convenience (...these are the updates we > made > > > to the _latest_ version of PackageJob.py): > > > > > > $ cd /usr/share/plague/server > > > $ diff PackageJob.py PackageJob.py.working > > > 513c513 > > > < base.log = logger.Logger(threshold=threshold, > > > file_object=sys.stdout) > > > --- > > > > base.log = Logger(threshold=threshold, > > > file_object=sys.stdout) > > > 698c698 > > > < if self._curstage == 'waiting': > > > --- > > > > if self._curstage in ['waiting', 'depsolve']: > > > > > > > > > Thanks, > > > Joe > > > -- > > > Fedora-buildsys-list mailing list > > > Fedora-buildsys-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From dcbw at redhat.com Mon Nov 20 00:14:17 2006 From: dcbw at redhat.com (Dan Williams) Date: Sun, 19 Nov 2006 19:14:17 -0500 Subject: OpenSUSE Build Service? In-Reply-To: <1163978891.2881.17.camel@localhost.localdomain> References: <1163978891.2881.17.camel@localhost.localdomain> Message-ID: <1163981657.2881.46.camel@localhost.localdomain> On Sun, 2006-11-19 at 18:28 -0500, Dan Williams wrote: > On Sat, 2006-11-18 at 13:39 +0100, Jeroen Janssen wrote: > > Hi, > > > > I'm not sure if this is the correct Fedora mailinglist, but has anyone > > had a look at the OpenSuSe Build Service pages ( > > http://en.opensuse.org/Build_Service )? > > > > There are two presentations (from FOSDEM) about it and it seems they > > have also done some experimenting with building non SuSe distributions > > with this build system (like Fedora Core 4). > > > > Is this something that also could benefit the Fedora Project? > > Having already written most of Plague by the time OSBS came out, I read > over pretty much everything about it when it was announced last year. > > The purpose of the two do seem to overlap; however OSBS appears to have > a much larger scope. It appears to try to be the one-stop shop for > building _everything_ for any distribution with any build system or > source-control system; which is fine. The pitch in those slides was > basically "build your release packages on our buildsystem." > > I don't think we want such a wide scope and fuzzy focus. I think Fedora > is better served by a specific, targetted system that builds _Fedora_ > packages. That's a fairly parochial attitude, but one which I think is > in the best interest of Fedora. Given that everyone working on and > admining the Fedora Extras buildsystem is a volunteer, we don't need to > be spreading our resources out even further supporting something like > the OSBS. We should be concentrating on building excellent packages for > Fedora, and arguably nothing else; we cannot be everything to everybody > or we are doomed to fail. > > The building of packages is such an important and code piece of a > distribution that it cannot _not_ be under the control of the project, > and it cannot _not_ be _accountable_ to the project. As more of the > Core responsibility gets spun out to the wider Fedora project, this only > becomes more critical. We need to be able to admin the systems, we need > to be able fix problems when they arise, we need to be able to > demonstrate accountability and security of the buildsystem. Without > that, there is no trust in the integrity of the distribution. This doesn't mean that code could be shared, of course, given compatible licensing. dan > Cheers, > Dan > > > Best regards, > > > > Jeroen Janssen > > > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From skvidal at linux.duke.edu Mon Nov 20 03:45:42 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 19 Nov 2006 22:45:42 -0500 Subject: OpenSUSE Build Service? In-Reply-To: <1163978891.2881.17.camel@localhost.localdomain> References: <1163978891.2881.17.camel@localhost.localdomain> Message-ID: <1163994342.11791.24.camel@cutter> On Sun, 2006-11-19 at 18:28 -0500, Dan Williams wrote: > Having already written most of Plague by the time OSBS came out, I read > over pretty much everything about it when it was announced last year. > > The purpose of the two do seem to overlap; however OSBS appears to have > a much larger scope. It appears to try to be the one-stop shop for > building _everything_ for any distribution with any build system or > source-control system; which is fine. The pitch in those slides was > basically "build your release packages on our buildsystem." > > I don't think we want such a wide scope and fuzzy focus. I think Fedora > is better served by a specific, targetted system that builds _Fedora_ > packages. That's a fairly parochial attitude, but one which I think is > in the best interest of Fedora. Given that everyone working on and > admining the Fedora Extras buildsystem is a volunteer, we don't need to > be spreading our resources out even further supporting something like > the OSBS. We should be concentrating on building excellent packages for > Fedora, and arguably nothing else; we cannot be everything to everybody > or we are doomed to fail. > > The building of packages is such an important and code piece of a > distribution that it cannot _not_ be under the control of the project, > and it cannot _not_ be _accountable_ to the project. As more of the > Core responsibility gets spun out to the wider Fedora project, this only > becomes more critical. We need to be able to admin the systems, we need > to be able fix problems when they arise, we need to be able to > demonstrate accountability and security of the buildsystem. Without > that, there is no trust in the integrity of the distribution. > I agree with Dan's assessment. Furthermore, he's done a great job giving fedora a buildsystem and we should continue to enhance it. Additionally, it might be starting to be a good time to be afraid of things with Novell's copyright over them. We'll never know what patents we might be treading upon and only allowed to use provided we're not with a company. -sv From jstodaro at us.ibm.com Tue Nov 21 15:50:53 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Tue, 21 Nov 2006 10:50:53 -0500 Subject: PATCH: plague-0.5.0: PackageJob.py: NameError _and_ YumBaseError (unable to kill its job) In-Reply-To: <1163979271.2881.23.camel@localhost.localdomain> Message-ID: Dan Williams wrote on 11/19/2006 06:34:31 PM: > On Fri, 2006-11-17 at 22:43 -0500, Joe Todaro wrote: > > > > Dan Williams wrote on 11/13/2006 03:26:58 PM: > > > > > On Sun, 2006-11-05 at 23:48 -0500, Joe Todaro wrote: > > > > > > > > ---- PROBLEM # 1 ---- Depsolve step keeps crashing due to a typo > > in > > > > the script: > > > > > > > > 364 (fuse-sshfs): Starting depsolve for arches: ['x86_64', > > 'i386']. > > > > Exception in thread PackageJob: 364/fuse-sshfs: > > > > [...snip...] > > > > > File "/usr/share/plague/server/PackageJob.py", line 513, in > > > > > _arch_deps_solved > > > > > base.log = logger.Logger(threshold=threshold, > > > > file_object=sys.stdout) > > > > > NameError: global name 'logger' is not defined > > > > > > Fixed, thanks! > > > > My pleasure - glad to help. > > > > > > > > > > > > > ---- PROBLEM # 2 ---- Unable to kill any job that fails due to a > > > > missing package/s in the yum repos: > > > > > > > > > File "/usr/share/plague/server/PackageJob.py", line 548, in > > > > _arch_deps_solved > > > > > pkg = base.returnPackageByDep(dep) > > > > > File "__init__.py", line 1342, in returnPackageByDep > > > > > YumBaseError: No Package found for fuse-devel > > > > > > What version of yum do you have on this machine? > > > > yum-2.4.2-2 > > Ok, can you do the following, so we can find out which module > YumBaseError lives in in yum-2.4.2/yum-utils: > > grep -r "YumBaseError" /usr/lib/python2.3/site-packages $ grep -rn "YumBaseError" /usr/lib/python2.3/site-packages /usr/lib/python2.3/site-packages/yum/__init__.py:174: raise Errors.YumBaseError, 'Setting up TransactionSets before config class is up' /usr/lib/python2.3/site-packages/yum/__init__.py:358: raise Errors.YumBaseError, errstring /usr/lib/python2.3/site-packages/yum/__init__.py:550: callback, raise yum.Errors.YumBaseError on problems""" /usr/lib/python2.3/site-packages/yum/__init__.py:650: output based on callback, raise yum.Errors.YumBaseError on problems""" /usr/lib/python2.3/site-packages/yum/__init__.py:1321: raise Errors.YumBaseError, 'Invalid versioned dependency string, try quoting it.' /usr/lib/python2.3/site-packages/yum/__init__.py:1323: raise Errors.YumBaseError, 'Invalid version flag' /usr/lib/python2.3/site-packages/yum/__init__.py:1337: except Errors.YumBaseError, e: /usr/lib/python2.3/site-packages/yum/__init__.py:1338: raise Errors.YumBaseError, 'No Package found for %s' % depstring /usr/lib/python2.3/site-packages/yum/__init__.py:1342: raise Errors.YumBaseError, 'No Package found for %s' % depstring /usr/lib/python2.3/site-packages/yum/__init__.py:1348: If the list is empty, raise Errors.YumBaseError""" /usr/lib/python2.3/site-packages/yum/__init__.py:1397: raise Errors.YumBaseError, 'Invalid versioned dependency string, try quoting it.' /usr/lib/python2.3/site-packages/yum/__init__.py:1399: raise Errors.YumBaseError, 'Invalid version flag' Binary file /usr/lib/python2.3/site-packages/yum/__init__.pyc matches /usr/lib/python2.3/site-packages/yum/Errors.py:22:class YumBaseError(exceptions.Exception): /usr/lib/python2.3/site-packages/yum/Errors.py:27:class LockError(YumBaseError): /usr/lib/python2.3/site-packages/yum/Errors.py:29: YumBaseError.__init__(self) /usr/lib/python2.3/site-packages/yum/Errors.py:33:class DepError(YumBaseError): /usr/lib/python2.3/site-packages/yum/Errors.py:35: YumBaseError.__init__(self) /usr/lib/python2.3/site-packages/yum/Errors.py:38:class RepoError(YumBaseError): /usr/lib/python2.3/site-packages/yum/Errors.py:40: YumBaseError.__init__(self) /usr/lib/python2.3/site-packages/yum/Errors.py:43:class ConfigError(YumBaseError): /usr/lib/python2.3/site-packages/yum/Errors.py:45: YumBaseError.__init__(self) /usr/lib/python2.3/site-packages/yum/Errors.py:48:class MiscError(YumBaseError): /usr/lib/python2.3/site-packages/yum/Errors.py:50: YumBaseError.__init__(self) /usr/lib/python2.3/site-packages/yum/Errors.py:53:class GroupsError(YumBaseError): /usr/lib/python2.3/site-packages/yum/Errors.py:55: YumBaseError.__init__(self) Binary file /usr/lib/python2.3/site-packages/yum/Errors.pyc matches Binary file /usr/lib/python2.3/site-packages/yumex/yum24XBase.pyc matches /usr/lib/python2.3/site-packages/yumex/yumexBase.py:72:class YumexError( yum.Errors.YumBaseError ): /usr/lib/python2.3/site-packages/yumex/yumexBase.py:74: yum.Errors.YumBaseError.__init__( self ) /usr/lib/python2.3/site-packages/yumex/yumexBase.py:615: except yum.Errors.YumBaseError, e: /usr/lib/python2.3/site-packages/yumex/yumexBase.py:640: except Errors.YumBaseError, e: /usr/lib/python2.3/site-packages/yumex/yumexBase.py:675: raise yum.Errors.YumBaseError( errstring ) /usr/lib/python2.3/site-packages/yumex/yumexBase.py:685: raise yum.Errors.YumBaseError( errstring ) /usr/lib/python2.3/site-packages/yumex/yumexBase.py:695: raise yum.Errors.YumBaseError( errstring ) /usr/lib/python2.3/site-packages/yumex/yumexBase.py:724: raise yum.Errors.YumBaseError( errstring ) /usr/lib/python2.3/site-packages/yumex/yumexBase.py:800: Will raise YumBaseError if there's a problem /usr/lib/python2.3/site-packages/yumex/yumexBase.py:817:# raise yum.Errors.YumBaseError, \ /usr/lib/python2.3/site-packages/yumex/yumexBase.py:832: raise yum.Errors.YumBaseError( /usr/lib/python2.3/site-packages/yumex/yumexBase.py:843: raise yum.Errors.YumBaseError, \ /usr/lib/python2.3/site-packages/yumex/yumexBase.py:864: raise yum.Errors.YumBaseError, \ /usr/lib/python2.3/site-packages/yumex/yumexBase.py:870: raise yum.Errors.YumBaseError, \ /usr/lib/python2.3/site-packages/yumex/yumexBase.py:881: raise yum.Errors.YumBaseError, errmsg /usr/lib/python2.3/site-packages/yumex/yumexBase.py:885: raise yum.Errors.YumBaseError, errmsg Binary file /usr/lib/python2.3/site-packages/yumex/yumexBase.pyc matches /usr/lib/python2.3/site-packages/yumex/yum24XBase.py:44: InstallError = UpdateError = yum.Errors.YumBaseError Line #'s included. Thanks, Joe > > (or if you have python 2.4, use python2.4 instead of course). > > Thanks, > Dan > > > > > > > The versions of the > > > yum python libraries are a bit confusing here; and that's probably > > where > > > the error is coming from. It appears that an unexpected error is > > > getting thrown, and we need to catch that error. However, I'm not > > sure > > > where exactly it's coming from to catch it. Can you try to get this > > > error again and then paste in about 10 lines of code from around the > > > Line # in PackageJob.py that this backtrace comes from? (ie, line > > 548 > > > here), and mark the line numbers too? > > > > 537 try: > > 538 base.doSackSetup(archlist) > > 539 except yum.Errors.RepoError, exc: > > 540 raise DepError(str(exc)) > > 541 > > 542 for dep in srpm.requiresList(): > > 543 if dep.startswith("rpmlib("): > > 544 continue > > 545 if use_repomd: > > 546 try: > > 547 pkg = base.returnPackageByDep(dep) > > 548 except repomd.mdErrors.PackageSackError, > > exc: > > 549 raise DepError(str(exc)) > > 550 else: > > 551 try: > > 552 pkg = base.returnPackageByDep(dep) > > 553 except yum.Errors.PackageSackError, exc: > > 554 raise DepError(str(exc)) > > 555 except yum.Errors.YumBaseError, exc: > > 556 raise DepError(str(exc)) > > 557 except DepError, exc: > > 558 self._last_depsolve_error = str(exc) > > 559 print "%s (%s/%s): Depsolve Error: %s" % > > (self.uid, self.package, arch, str(exc)) > > 560 success = False > > > > > > > > The fix you posted for this hunk isn't the "correct" fix; > > > > Actually, it wasn't intended to "fix" the (YumBaseError) problem > > itself -- rather it was just intended to provide us with a means by > > which we'd be able to "recover* from the negative effects of the > > problem, which was a plague-server that wouldn't allow us to *kill* > > the associated buildjob because the buildjob wasn't in "waiting" > > state -- it was in "depsolve" which is where it got stuck. Anyway, > > recycling the plague-server did not help -- it just kept restarting > > the buildjob which just kept failing in the same place even after we > > downloaded the missing package (fuse-devel) to the yum repo and ran > > the createrepo command in-between plague-server restarts. > > > > > that would be > > > to catch the exception and to re-throw it as a DepSolveError as is > > done > > > for the other 'execpt' blocks around there. > > > > > > Cheers, > > > Dan > > > > > > > > > > > ---- PATCH ---- > > > > > > > > Here's the patch that resolved the above 2 problems for us: > > > > > > > > > > > > > > > > ----- REQUEST ---- > > > > > > > > Can someone please review it... especially the fix to PROBLEM # 2, > > > > that could potentially be masking a bigger problem.. > > > > > > > > Here's the code for your convenience (...these are the updates we > > made > > > > to the _latest_ version of PackageJob.py): > > > > > > > > $ cd /usr/share/plague/server > > > > $ diff PackageJob.py PackageJob.py.working > > > > 513c513 > > > > < base.log = logger.Logger(threshold=threshold, > > > > file_object=sys.stdout) > > > > --- > > > > > base.log = Logger(threshold=threshold, > > > > file_object=sys.stdout) > > > > 698c698 > > > > < if self._curstage == 'waiting': > > > > --- > > > > > if self._curstage in ['waiting', 'depsolve']: > > > > > > > > > > > > Thanks, > > > > Joe > > > > -- > > > > Fedora-buildsys-list mailing list > > > > Fedora-buildsys-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > > > > > -- > > > Fedora-buildsys-list mailing list > > > Fedora-buildsys-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubler at pingtel.com Wed Nov 22 03:21:57 2006 From: dhubler at pingtel.com (Douglas Hubler) Date: Wed, 22 Nov 2006 03:21:57 +0000 (UTC) Subject: automate rpm signing? Message-ID: The Fedora website http://fedora.redhat.com/About/security/ mentions Fedora builds are automatically signed. How is this done? rpm --addsign requires user input and is not gpg-aware http://lists.gnupg.org/pipermail/gnupg-users/2004-January/021302.html From dennis at ausil.us Wed Nov 22 03:43:43 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 21 Nov 2006 21:43:43 -0600 Subject: automate rpm signing? In-Reply-To: References: Message-ID: <200611212143.43688.dennis@ausil.us> On Tuesday 21 November 2006 21:21, Douglas Hubler wrote: > The Fedora website > http://fedora.redhat.com/About/security/ > mentions Fedora builds are automatically signed. How is this done? rpm > --addsign requires user input and is not gpg-aware > http://lists.gnupg.org/pipermail/gnupg-users/2004-January/021302.html You can automate it by not putting a password on the gpgkey. most of the rpms are manually signed for this reason. and all of extras are manually signed. the only automated signed would be in rawhide and i think they are generally not signed at all. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From jkeating at redhat.com Wed Nov 22 03:57:08 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Nov 2006 22:57:08 -0500 Subject: automate rpm signing? In-Reply-To: References: Message-ID: <200611212257.11927.jkeating@redhat.com> On Tuesday 21 November 2006 22:21, Douglas Hubler wrote: > The Fedora website > ?http://fedora.redhat.com/About/security/ > mentions Fedora builds are automatically signed. How is this done? rpm > --addsign requires user input and is not gpg-aware This seems to be false information (for now). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From esammons at hush.com Wed Nov 22 12:04:27 2006 From: esammons at hush.com (Earl) Date: Wed, 22 Nov 2006 07:04:27 -0500 Subject: automate rpm signing? Message-ID: <20061122120429.0C0972283E@mailserver9.hushmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hmm... I've had this in my .rpmmacros for quite some time now. Although it does require user input unless you are brave enough not to have a passphrase for you key Yikes!, it works fine with GPG for me... %_signature gpg %_gpg_name Earl On Tue, 21 Nov 2006 22:21:57 -0500 Douglas Hubler wrote: >rpm --addsign requires user input and is not gpg-aware > http://lists.gnupg.org/pipermail/gnupg-users/2004- >January/021302.html > >-- >Fedora-buildsys-list mailing list >Fedora-buildsys-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wkYEARECAAYFAkVkOvYACgkQk7+e+4lPSm2ceACeLznsZqLVpDNrqgcfXXud051usg4A nAqJh5K1bRUicjRjCrxA4GI7ib4P =Zj78 -----END PGP SIGNATURE----- From mail-lists at karan.org Wed Nov 22 12:09:05 2006 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 22 Nov 2006 12:09:05 +0000 Subject: automate rpm signing? In-Reply-To: <200611212143.43688.dennis@ausil.us> References: <200611212143.43688.dennis@ausil.us> Message-ID: <45643DE1.8020307@karan.org> Dennis Gilmore wrote: > On Tuesday 21 November 2006 21:21, Douglas Hubler wrote: >> The Fedora website >> http://fedora.redhat.com/About/security/ >> mentions Fedora builds are automatically signed. How is this done? rpm >> --addsign requires user input and is not gpg-aware >> http://lists.gnupg.org/pipermail/gnupg-users/2004-January/021302.html > You can automate it by not putting a password on the gpgkey. most of the rpms > are manually signed for this reason. and all of extras are manually signed. > the only automated signed would be in rawhide and i think they are generally > not signed at all. > iirc, even with a blank passwd, rpm's default behavior is to ask for a password anyway, 'expect' knows what to do :) - KB -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq From dennis at ausil.us Wed Nov 22 15:34:54 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 22 Nov 2006 09:34:54 -0600 Subject: automate rpm signing? In-Reply-To: <45643DE1.8020307@karan.org> References: <200611212143.43688.dennis@ausil.us> <45643DE1.8020307@karan.org> Message-ID: <200611220934.55057.dennis@ausil.us> Once upon a time Wednesday 22 November 2006 6:09 am, Karanbir Singh wrote: > Dennis Gilmore wrote: > > On Tuesday 21 November 2006 21:21, Douglas Hubler wrote: > >> The Fedora website > >> http://fedora.redhat.com/About/security/ > >> mentions Fedora builds are automatically signed. How is this done? rpm > >> --addsign requires user input and is not gpg-aware > >> http://lists.gnupg.org/pipermail/gnupg-users/2004-January/021302.html > > > > You can automate it by not putting a password on the gpgkey. most of the > > rpms are manually signed for this reason. and all of extras are manually > > signed. the only automated signed would be in rawhide and i think they > > are generally not signed at all. > > iirc, even with a blank passwd, rpm's default behavior is to ask for a > password anyway, > > 'expect' knows what to do :) ive never tried so im not 100% sure. i had assumed that if i put no password on the key i wouldnt be prompted. but i would not trust a situation like that so i wont impose that on my users. :) Dennis From oliver at linux-kernel.at Thu Nov 23 08:14:46 2006 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 23 Nov 2006 09:14:46 +0100 Subject: automate rpm signing? In-Reply-To: <200611220934.55057.dennis@ausil.us> References: <200611212143.43688.dennis@ausil.us> <45643DE1.8020307@karan.org> <200611220934.55057.dennis@ausil.us> Message-ID: <45655876.1020603@linux-kernel.at> On 11/22/2006 04:34 PM, Dennis Gilmore wrote: > Once upon a time Wednesday 22 November 2006 6:09 am, Karanbir Singh wrote: >> Dennis Gilmore wrote: >>> On Tuesday 21 November 2006 21:21, Douglas Hubler wrote: >>>> The Fedora website >>>> http://fedora.redhat.com/About/security/ >>>> mentions Fedora builds are automatically signed. How is this done? rpm >>>> --addsign requires user input and is not gpg-aware >>>> http://lists.gnupg.org/pipermail/gnupg-users/2004-January/021302.html >>> You can automate it by not putting a password on the gpgkey. most of the >>> rpms are manually signed for this reason. and all of extras are manually >>> signed. the only automated signed would be in rawhide and i think they >>> are generally not signed at all. >> iirc, even with a blank passwd, rpm's default behavior is to ask for a >> password anyway, >> >> 'expect' knows what to do :) > > ive never tried so im not 100% sure. i had assumed that if i put no password > on the key i wouldnt be prompted. but i would not trust a situation like > that so i wont impose that on my users. :) Yes, rpm always asks... And yes, expect knows what to do: #!/usr/bin/expect set p "" set f [lindex $argv 0] spawn rpm --resign $f expect "Enter pass phrase:" send -- "$p\r" expect eof The other way; Use perl ( http://search.cpan.org/~nanardon/RPM4-0.20/lib/RPM4.pm). RPM4 also knows how to do it... Best, Oliver From jeroen.janssen at gmail.com Thu Nov 23 15:40:43 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Thu, 23 Nov 2006 16:40:43 +0100 Subject: Pungi & seperating needed RPMs for Anaconda / Installation? Message-ID: Hi, When building an installation CD with pungi, the packages needed for Anaconda need to also be present in the 'repository'. (this is probably generic for building an Anaconda installer?) Is there a way to differentiate between RPMs that are needed for Anaconda and the RPMs that should end up as 'installable' on the disc?. Example: baseurl_anaconda=http://...FC6.url.../ baseurl=http://..MyOwn.url.../ Here 'baseurl_anaconda' is some place that Anaconda can get RPMs from (the PACKAGES from Anaconda upd-instroot) and 'base_url' is the place for 'installable' RPMs. Any thoughts? Best regards, Jeroen Janssen From jaroslav at aster.pl Thu Nov 23 20:35:19 2006 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Thu, 23 Nov 2006 21:35:19 +0100 Subject: Pungi & seperating needed RPMs for Anaconda / Installation? In-Reply-To: References: Message-ID: <200611232135.29649.jaroslav@aster.pl> Hi, Dnia czwartek, 23 listopada 2006 16:40, Jeroen Janssen napisa?: > Hi, > > When building an installation CD with pungi, the packages needed for > Anaconda need to also be present in the 'repository'. (this is > probably generic for building an Anaconda installer?) Last time I have used it (anaconda scripts) - there was a separation. I've had two separate directories with RPMS (one for installer, the other for the distro). Because of that feature I've been able to have different kernel versions in distro and installer. -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Nov 24 02:15:19 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 23 Nov 2006 21:15:19 -0500 Subject: Pungi & seperating needed RPMs for Anaconda / Installation? In-Reply-To: References: Message-ID: <200611232115.22883.jkeating@redhat.com> On Thursday 23 November 2006 10:40, Jeroen Janssen wrote: > Any thoughts? I've talked with the anaconda folks, and they want to change how some of the stage files are created, so that you don't need a lot of the crud at tree build time, just enough to poke at the kernel and create the boot images. The rest of the stuff (languages, gui files, etc..) would be created when the anaconda-runtime rpm is built in the buildsystem. This would reduce the number of 'needed for building the tree' packages that wouldn't be _in_ the tree already. Because of this I haven't put any logic in Pungi to separate the two package sets. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Nov 25 15:10:23 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 25 Nov 2006 16:10:23 +0100 Subject: buildsys misconfigured Message-ID: <20061125161023.239f7451.bugs.michael@gmx.net> FC-6]$ make build /usr/bin/plague-client build SDL_image SDL_image-1_2_5-2_fc6 fc6 Package SDL_image enqueued. Job ID: 22289. > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22289 22289: SDL_image-1.2.5-2.fc7 (building) Where does the .fc7 come from? This is the FC-6 branch! From dennis at ausil.us Sat Nov 25 15:22:08 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 25 Nov 2006 09:22:08 -0600 Subject: buildsys misconfigured In-Reply-To: <20061125161023.239f7451.bugs.michael@gmx.net> References: <20061125161023.239f7451.bugs.michael@gmx.net> Message-ID: <200611250922.13224.dennis@ausil.us> Once upon a time Saturday 25 November 2006 9:10 am, Michael Schwendt wrote: > FC-6]$ make build > /usr/bin/plague-client build SDL_image SDL_image-1_2_5-2_fc6 fc6 > Package SDL_image enqueued. Job ID: 22289. > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22289 > > 22289: SDL_image-1.2.5-2.fc7 (building) > > Where does the .fc7 come from? This is the FC-6 branch! ill look at it tonight, im just about to walk out the door. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Nov 25 17:28:09 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 25 Nov 2006 18:28:09 +0100 Subject: plague-client list Message-ID: <20061125182809.75c0b9d8.bugs.michael@gmx.net> $ plague-client list Error: an error ocurred communicating with the server. ' Message-ID: <20061125182813.75236bcd.bugs.michael@gmx.net> Is this supposed to read "Status: needsign/success"? $ plague-client detail 22289 Detail for Job ID 22289 (SDL_image): -------------------------------------------------------------------------------- Source: SDL_image-1_2_5-2_fc6 Target: fedora-6-extras Submitter: bugs.michael at gmx.net Status: needsign/ Archjobs: i386: hammer2.fedora.redhat.com done/done x86_64: xenbuilder1.fedora.redhat.com done/done ppc: ppc3.fedora.redhat.com done/done From jaroslav at aster.pl Sat Nov 25 22:22:24 2006 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Sat, 25 Nov 2006 23:22:24 +0100 Subject: anaconda-runtime requirements Message-ID: <200611252322.33316.jaroslav@aster.pl> Hi, are there any reasons for anaconda-runtime requiring anaconda? Because of this requirement, when I want to play with anaconda-runtime (eg. pungi), I also have to install some completely unnecessary packages, like libdhcp6client or pyparted. regards, -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Nov 25 22:45:32 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 25 Nov 2006 23:45:32 +0100 Subject: Truncated x86_64 build results from hammer2 Message-ID: <20061125234532.11fc52a7.bugs.michael@gmx.net> Build job 22303 (hammer2 for x86_64) produced a truncated x86_64 rpm: http://buildsys.fedoraproject.org/build-status/job.psp?uid=22303 Should be above 5MiB in size, but is only 114688 bytes short: $ rpm -Kv kile-1.9.3-1.fc3.1.x86_64.rpm error: kile-1.9.3-1.fc3.1.x86_64.rpm: headerRead failed $ stat kile-1.9.3-1.fc3.1.x86_64.rpm File: `kile-1.9.3-1.fc3.1.x86_64.rpm' Size: 114688 Blocks: 232 IO Block: 4096 regular file Device: 811h/2065d Inode: 32325671 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Access: 2006-11-25 17:38:08.000000000 -0500 Modify: 2006-11-25 12:15:34.000000000 -0500 Change: 2006-11-25 12:15:34.000000000 -0500 From jkeating at redhat.com Sun Nov 26 14:19:34 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 26 Nov 2006 09:19:34 -0500 Subject: anaconda-runtime requirements In-Reply-To: <200611252322.33316.jaroslav@aster.pl> References: <200611252322.33316.jaroslav@aster.pl> Message-ID: <200611260919.37921.jkeating@redhat.com> On Saturday 25 November 2006 17:22, Jaroslaw Gorny wrote: > Hi, > are there any reasons for anaconda-runtime requiring anaconda? > Because of this requirement, when I want to play with anaconda-runtime (eg. > pungi), I also have to install some completely unnecessary packages, like > libdhcp6client or pyparted. This is a better question for the anaconda-devel list. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Sun Nov 26 15:42:21 2006 From: dcbw at redhat.com (Dan Williams) Date: Sun, 26 Nov 2006 10:42:21 -0500 Subject: plague-client list In-Reply-To: <20061125182809.75c0b9d8.bugs.michael@gmx.net> References: <20061125182809.75c0b9d8.bugs.michael@gmx.net> Message-ID: <1164555741.4059.0.camel@localhost.localdomain> On Sat, 2006-11-25 at 18:28 +0100, Michael Schwendt wrote: > $ plague-client list > Error: an error ocurred communicating with the server. > ' parent_uid=5 > ---snip--- (400K of parent_uid=...) Don't list all jobs :) In any case, the server needs to limit the CLI clients request size. dan > > $ plague-client list status needsign > (same here) > > $ plague-client list result success > (same here) > > $ plague-client list status failed > Error: connection to the server timed out. '(110, 'Operation timed out.')' > > $ plague-client list status building > (same here) > > $ plague-client list email myemailaddress > (works) > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From giallu at gmail.com Sun Nov 26 16:52:16 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 26 Nov 2006 17:52:16 +0100 Subject: plague-client list In-Reply-To: <1164555741.4059.0.camel@localhost.localdomain> References: <20061125182809.75c0b9d8.bugs.michael@gmx.net> <1164555741.4059.0.camel@localhost.localdomain> Message-ID: On 11/26/06, Dan Williams wrote: > On Sat, 2006-11-25 at 18:28 +0100, Michael Schwendt wrote: > > $ plague-client list > > Error: an error ocurred communicating with the server. > > ' > parent_uid=5 > > ---snip--- (400K of parent_uid=...) > > Don't list all jobs :) In any case, the server needs to limit the CLI > clients request size. this is the same I hit the very first time I tried plague... Now a probably naive question: is there a reason why "plague-client list" builds a full list of parent_uid's in the WHERE clause instead of just stopping the query at "archjobs"? From dennis at ausil.us Sun Nov 26 17:35:08 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 26 Nov 2006 11:35:08 -0600 Subject: plague-client list In-Reply-To: <20061125182809.75c0b9d8.bugs.michael@gmx.net> References: <20061125182809.75c0b9d8.bugs.michael@gmx.net> Message-ID: <200611261135.08814.dennis@ausil.us> try plague-client list status needsign uid_gt 22000 the problem is the command is returning too much data. On Saturday 25 November 2006 11:28 am, Michael Schwendt wrote: > $ plague-client list > Error: an error ocurred communicating with the server. > ' complex\nDETAIL: Nesting depth exceeds maximum expression depth > 10000.\nHINT: Increase the configuration parameter "max_expr_depth".\n\' > in \'SELECT jobid, parent_uid, starttime, endtime, arch, builder_addr, > status, builder_status FROM archjobs WHERE parent_uid=5 > ---snip--- (400K of parent_uid=...) > > $ plague-client list status needsign > (same here) > > $ plague-client list result success > (same here) > > $ plague-client list status failed > Error: connection to the server timed out. '(110, 'Operation timed out.')' > > $ plague-client list status building > (same here) > > $ plague-client list email myemailaddress > (works) > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -- Dennis Gilmore, RHCE Proud Australian From dennis at ausil.us Mon Nov 27 04:04:14 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 26 Nov 2006 22:04:14 -0600 Subject: buildsys misconfigured In-Reply-To: <200611250922.13224.dennis@ausil.us> References: <20061125161023.239f7451.bugs.michael@gmx.net> <200611250922.13224.dennis@ausil.us> Message-ID: <200611262204.14823.dennis@ausil.us> On Saturday 25 November 2006 9:22 am, Dennis Gilmore wrote: > Once upon a time Saturday 25 November 2006 9:10 am, Michael Schwendt wrote: > > FC-6]$ make build > > /usr/bin/plague-client build SDL_image SDL_image-1_2_5-2_fc6 fc6 > > Package SDL_image enqueued. Job ID: 22289. > > > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22289 > > > > 22289: SDL_image-1.2.5-2.fc7 (building) > > > > Where does the .fc7 come from? This is the FC-6 branch! > > ill look at it tonight, im just about to walk out the door. > > Dennis Michael, Ive looked at this and it has to be something at your end not updated. i checked out SDL_image and did a make build and everything is correct http://buildsys.fedoraproject.org/build-status/job.psp?uid=22395 22395: SDL_image-1.2.5-3.fc6 (building) -- Dennis Gilmore, RHCE Proud Australian From bugs.michael at gmx.net Mon Nov 27 09:38:53 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 27 Nov 2006 10:38:53 +0100 Subject: buildsys misconfigured In-Reply-To: <200611262204.14823.dennis@ausil.us> References: <20061125161023.239f7451.bugs.michael@gmx.net> <200611250922.13224.dennis@ausil.us> <200611262204.14823.dennis@ausil.us> Message-ID: <20061127103853.6b1c5a9f.bugs.michael@gmx.net> On Sun, 26 Nov 2006 22:04:14 -0600, Dennis Gilmore wrote: > On Saturday 25 November 2006 9:22 am, Dennis Gilmore wrote: > > Once upon a time Saturday 25 November 2006 9:10 am, Michael Schwendt wrote: > > > FC-6]$ make build > > > /usr/bin/plague-client build SDL_image SDL_image-1_2_5-2_fc6 fc6 > > > Package SDL_image enqueued. Job ID: 22289. > > > > > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22289 > > > > > > 22289: SDL_image-1.2.5-2.fc7 (building) > > > > > > Where does the .fc7 come from? This is the FC-6 branch! > > > > ill look at it tonight, im just about to walk out the door. > > > > Dennis > Michael, > > Ive looked at this and it has to be something at your end not updated. i > checked out SDL_image and did a make build and everything is correct > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22395 > 22395: SDL_image-1.2.5-3.fc6 (building) No way. Look again. I've quoted the plague-client command-line above. From dennis at ausil.us Tue Nov 28 16:06:20 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 28 Nov 2006 10:06:20 -0600 Subject: buildsys misconfigured In-Reply-To: <20061127103853.6b1c5a9f.bugs.michael@gmx.net> References: <20061125161023.239f7451.bugs.michael@gmx.net> <200611262204.14823.dennis@ausil.us> <20061127103853.6b1c5a9f.bugs.michael@gmx.net> Message-ID: <200611281006.20379.dennis@ausil.us> On Monday 27 November 2006 3:38 am, Michael Schwendt wrote: > On Sun, 26 Nov 2006 22:04:14 -0600, Dennis Gilmore wrote: > > On Saturday 25 November 2006 9:22 am, Dennis Gilmore wrote: > > > Once upon a time Saturday 25 November 2006 9:10 am, Michael Schwendt wrote: > > > > FC-6]$ make build > > > > /usr/bin/plague-client build SDL_image SDL_image-1_2_5-2_fc6 fc6 > > > > Package SDL_image enqueued. Job ID: 22289. > > > > > > > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22289 > > > > > > > > 22289: SDL_image-1.2.5-2.fc7 (building) > > > > > > > > Where does the .fc7 come from? This is the FC-6 branch! > > > > > > ill look at it tonight, im just about to walk out the door. > > > > > > Dennis > > > > Michael, > > > > Ive looked at this and it has to be something at your end not updated. > > i checked out SDL_image and did a make build and everything is correct > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22395 22395: > > SDL_image-1.2.5-3.fc6 (building) > > No way. Look again. I've quoted the plague-client command-line above. i did exactly the same set of steps you posted FC-6]$ make build /usr/bin/plague-client build SDL_image SDL_image-1_2_5-3_fc6 fc6 Package SDL_image enqueued. Job ID: 22438. http://buildsys.fedoraproject.org/build-status/job.psp?uid=22438 shows 22438: SDL_image-1.2.5-3.fc6 (building) and older job that failed http://buildsys.fedoraproject.org/build-status/job.psp?uid=22084 shows 22084: linphone-1.5.1-1.fc6 (failed) the only thing i can think of is that your common dir is out of date. -- Dennis Gilmore, RHCE Proud Australian From bugs.michael at gmx.net Tue Nov 28 19:09:54 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 28 Nov 2006 20:09:54 +0100 Subject: buildsys misconfigured In-Reply-To: <200611281006.20379.dennis@ausil.us> References: <20061125161023.239f7451.bugs.michael@gmx.net> <200611262204.14823.dennis@ausil.us> <20061127103853.6b1c5a9f.bugs.michael@gmx.net> <200611281006.20379.dennis@ausil.us> Message-ID: <20061128200954.c2abfd04.bugs.michael@gmx.net> On Tue, 28 Nov 2006 10:06:20 -0600, Dennis Gilmore wrote: > On Monday 27 November 2006 3:38 am, Michael Schwendt wrote: > > On Sun, 26 Nov 2006 22:04:14 -0600, Dennis Gilmore wrote: > > > On Saturday 25 November 2006 9:22 am, Dennis Gilmore wrote: > > > > Once upon a time Saturday 25 November 2006 9:10 am, Michael Schwendt > wrote: > > > > > FC-6]$ make build > > > > > /usr/bin/plague-client build SDL_image SDL_image-1_2_5-2_fc6 fc6 > > > > > Package SDL_image enqueued. Job ID: 22289. > > > > > > > > > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22289 > > > > > > > > > > 22289: SDL_image-1.2.5-2.fc7 (building) > > > > > > > > > > Where does the .fc7 come from? This is the FC-6 branch! > > > > > > > > ill look at it tonight, im just about to walk out the door. > > > > > > > > Dennis > > > > > > Michael, > > > > > > Ive looked at this and it has to be something at your end not updated. > > > i checked out SDL_image and did a make build and everything is correct > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22395 22395: > > > SDL_image-1.2.5-3.fc6 (building) > > > > No way. Look again. I've quoted the plague-client command-line above. > i did exactly the same set of steps you posted > FC-6]$ make build > /usr/bin/plague-client build SDL_image SDL_image-1_2_5-3_fc6 fc6 > Package SDL_image enqueued. Job ID: 22438. > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22438 > > shows 22438: SDL_image-1.2.5-3.fc6 (building) > > and older job that failed > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22084 > > shows 22084: linphone-1.5.1-1.fc6 (failed) > > the only thing i can think of is that your common dir is out of date. Eeek, why would you think that? Can you explain the theory behind that? Where would the "fc7" come from if I had an old FC-6 checkout? Look closely at the command-line I've quoted. Here it is once more: | FC-6]$ make build | /usr/bin/plague-client build SDL_image SDL_image-1_2_5-2_fc6 fc6 As you can see, the tag is "fc6", the target is "fc6", the branch is FC-6. Now compare with: http://buildsys.fedoraproject.org/build-status/job.psp?uid=22289 Notice: | 22289: SDL_image-1.2.5-2.fc7 (needsign) | Logs: http://buildsys.fedoraproject.org/logs/fedora-6-extras/22289-SDL_image-1.2.5-2.fc7/ In i386: | SDL_image-1.2.5-2.fc7.src.rpm And here: http://buildsys.fedoraproject.org/logs/fedora-6-extras/22289-SDL_image-1.2.5-2.fc7/i386/job.log Somebody please explain where "fc7" comes from. From dennis at ausil.us Tue Nov 28 19:39:31 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 28 Nov 2006 13:39:31 -0600 Subject: buildsys misconfigured In-Reply-To: <20061128200954.c2abfd04.bugs.michael@gmx.net> References: <20061125161023.239f7451.bugs.michael@gmx.net> <200611281006.20379.dennis@ausil.us> <20061128200954.c2abfd04.bugs.michael@gmx.net> Message-ID: <200611281339.32097.dennis@ausil.us> > > i did exactly the same set of steps you posted > > FC-6]$ make build > > /usr/bin/plague-client build SDL_image SDL_image-1_2_5-3_fc6 fc6 > > Package SDL_image enqueued. Job ID: 22438. > > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22438 > > > > shows 22438: SDL_image-1.2.5-3.fc6 (building) > > > > and older job that failed > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22084 > > > > shows 22084: linphone-1.5.1-1.fc6 (failed) > > > > the only thing i can think of is that your common dir is out of date. > > Eeek, why would you think that? Can you explain the theory behind that? > Where would the "fc7" come from if I had an old FC-6 checkout? > > Look closely at the command-line I've quoted. Here it is once more: > | FC-6]$ make build > | /usr/bin/plague-client build SDL_image SDL_image-1_2_5-2_fc6 fc6 > > As you can see, the tag is "fc6", the target is "fc6", the branch > is FC-6. yes i clearly see that and it is wrong i don't know where the .fc7 came from. I did a fresh checkout of SDL_image and ran the exact same commands and got the expected result. I could be way out in left field. but the only thing i thought was perhaps you had an old common tree that had FC-6 pointing at devel. its a wild guess nothing more. I was unable to see a pattern of it in the buildsys to know for sure -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From bugs.michael at gmx.net Tue Nov 28 22:01:14 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 28 Nov 2006 23:01:14 +0100 Subject: buildsys misconfigured In-Reply-To: <200611281339.32097.dennis@ausil.us> References: <20061125161023.239f7451.bugs.michael@gmx.net> <200611281006.20379.dennis@ausil.us> <20061128200954.c2abfd04.bugs.michael@gmx.net> <200611281339.32097.dennis@ausil.us> Message-ID: <20061128230114.0f0a8eac.bugs.michael@gmx.net> On Tue, 28 Nov 2006 13:39:31 -0600, Dennis Gilmore wrote: > > > > i did exactly the same set of steps you posted > > > FC-6]$ make build > > > /usr/bin/plague-client build SDL_image SDL_image-1_2_5-3_fc6 fc6 > > > Package SDL_image enqueued. Job ID: 22438. > > > > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22438 > > > > > > shows 22438: SDL_image-1.2.5-3.fc6 (building) > > > > > > and older job that failed > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=22084 > > > > > > shows 22084: linphone-1.5.1-1.fc6 (failed) > > > > > > the only thing i can think of is that your common dir is out of date. > > > > Eeek, why would you think that? Can you explain the theory behind that? > > Where would the "fc7" come from if I had an old FC-6 checkout? > > > > Look closely at the command-line I've quoted. Here it is once more: > > | FC-6]$ make build > > | /usr/bin/plague-client build SDL_image SDL_image-1_2_5-2_fc6 fc6 > > > > As you can see, the tag is "fc6", the target is "fc6", the branch > > is FC-6. > yes i clearly see that and it is wrong i don't know where the .fc7 came from. > I did a fresh checkout of SDL_image and ran the exact same commands and got > the expected result. I could be way out in left field. but the only thing i > thought was perhaps you had an old common tree that had FC-6 pointing at > devel. its a wild guess nothing more. I was unable to see a pattern of it > in the buildsys to know for sure 1) "FC-6" branch never points at "devel". 2) An old common/branches can have "devel" point at ".fc6" instead of ".fc7". 3) The plague-client command-line does NOT contain anything like "devel" or "fc7". Only "fc6". 4) The buildsys was asked to build an fc6-tagged package for target fc6, but built a fc7 src.rpm. I'm out of here. If nobody has fixed it, it might come back. From dennis at ausil.us Tue Nov 28 22:50:05 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 28 Nov 2006 16:50:05 -0600 Subject: buildsys misconfigured In-Reply-To: <20061128230114.0f0a8eac.bugs.michael@gmx.net> References: <20061125161023.239f7451.bugs.michael@gmx.net> <200611281339.32097.dennis@ausil.us> <20061128230114.0f0a8eac.bugs.michael@gmx.net> Message-ID: <200611281650.06967.dennis@ausil.us> On Tuesday 28 November 2006 16:01, Michael Schwendt wrote: > 1) "FC-6" branch never points at "devel". I know this > 2) An old common/branches can have "devel" point at ".fc6" instead of > ".fc7". > > 3) The plague-client command-line does NOT contain anything like "devel" > or "fc7". Only "fc6". i know that and i could not repoduce your problem > 4) The buildsys was asked to build an fc6-tagged package for target fc6, > but built a fc7 src.rpm. Yes and i have not yet worked out why it did. Could you tar up your cvs tree so that i can disect it to see if it gives me any clues. > I'm out of here. If nobody has fixed it, it might come back. I said i was pulling at strings. I hope it comes back so we can reliably repoduce it and fix it. I really am trying to help -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From bugs.michael at gmx.net Wed Nov 29 01:07:06 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 29 Nov 2006 02:07:06 +0100 Subject: buildsys misconfigured In-Reply-To: <200611281650.06967.dennis@ausil.us> References: <20061125161023.239f7451.bugs.michael@gmx.net> <200611281339.32097.dennis@ausil.us> <20061128230114.0f0a8eac.bugs.michael@gmx.net> <200611281650.06967.dennis@ausil.us> Message-ID: <20061129020706.a9804f0e.bugs.michael@gmx.net> On Tue, 28 Nov 2006 16:50:05 -0600, Dennis Gilmore wrote: > On Tuesday 28 November 2006 16:01, Michael Schwendt wrote: > > 1) "FC-6" branch never points at "devel". > I know this In the previous message you wrote: | but the only thing i thought was perhaps you had an old common | tree that had FC-6 pointing at devel. its a wild guess nothing | more. This would not lead to the same symptoms. Assume the following: Case 1: No "FC-6" branch and old "common" checkout. I would run "make build" in "devel" (where else?), which is still at ".fc6". But the job would target "devel", not "fc6"! Case 2: "FC-6" branch and old "common" checkout. I would run "make build" in "FC-6", which has no corresponding entry in the "common/branches" file. Would that work and produce good plague-client arguments which target "fc6"? Also note that no new tag was created, but an old tag was re-used. > > 2) An old common/branches can have "devel" point at ".fc6" instead of > > ".fc7". > > > > 3) The plague-client command-line does NOT contain anything like "devel" > > or "fc7". Only "fc6". > i know that and i could not repoduce your problem Interesting would be any theory, where the .fc7 (for the generated src.rpm) can come from when nothing in the plague-client args contains "fc7". > > 4) The buildsys was asked to build an fc6-tagged package for target fc6, > > but built a fc7 src.rpm. > Yes and i have not yet worked out why it did. Could you tar up your cvs tree > so that i can disect it to see if it gives me any clues. Why? The local CVS working-copy is irrelevant. Everything is encoded in here: /usr/bin/plague-client build SDL_image SDL_image-1_2_5-2_fc6 fc6 It is a client that does not use CVS at all. From tibbs at math.uh.edu Wed Nov 29 01:33:07 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Nov 2006 19:33:07 -0600 Subject: buildsys misconfigured In-Reply-To: <20061129020706.a9804f0e.bugs.michael@gmx.net> References: <20061125161023.239f7451.bugs.michael@gmx.net> <200611281339.32097.dennis@ausil.us> <20061128230114.0f0a8eac.bugs.michael@gmx.net> <200611281650.06967.dennis@ausil.us> <20061129020706.a9804f0e.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Interesting would be any theory, where the .fc7 (for the generated MS> src.rpm) can come from when nothing in the plague-client args MS> contains "fc7". Forgive me if it's already been covered in this discussion, but doesn't the final package name actually come from whatever the buildsys-macros packages defines the %dist tag to be? (Assuming, of course, that the package uses the %dist macro in its Release: tag.) So it's possible that if the wrong buildsys-macros package got installed into the mock chroot somehow, the package could come out with the wrong name regardless of how plague-client was called or which CVS tag the buildsys checked out. All it would take to get the wrong buildsys macro installed would be a typo in the mock config file. But that should result in all packages for that distro version getting the wrong %dist tag, and this seems to be an isolated case. - J< From paul at city-fan.org Wed Nov 29 08:13:37 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 29 Nov 2006 08:13:37 +0000 Subject: buildsys misconfigured In-Reply-To: References: <20061125161023.239f7451.bugs.michael@gmx.net> <200611281339.32097.dennis@ausil.us> <20061128230114.0f0a8eac.bugs.michael@gmx.net> <200611281650.06967.dennis@ausil.us> <20061129020706.a9804f0e.bugs.michael@gmx.net> Message-ID: <1164788017.30297.0.camel@metropolis.intra.city-fan.org> On Tue, 2006-11-28 at 19:33 -0600, Jason L Tibbitts III wrote: > >>>>> "MS" == Michael Schwendt writes: > > MS> Interesting would be any theory, where the .fc7 (for the generated > MS> src.rpm) can come from when nothing in the plague-client args > MS> contains "fc7". > > Forgive me if it's already been covered in this discussion, but > doesn't the final package name actually come from whatever the > buildsys-macros packages defines the %dist tag to be? (Assuming, of > course, that the package uses the %dist macro in its Release: tag.) > > So it's possible that if the wrong buildsys-macros package got > installed into the mock chroot somehow, the package could come out > with the wrong name regardless of how plague-client was called or > which CVS tag the buildsys checked out. > > All it would take to get the wrong buildsys macro installed would be a > typo in the mock config file. But that should result in all packages > for that distro version getting the wrong %dist tag, and this seems to > be an isolated case. Perhaps a misconfiguration on one, rarely-used builder? Paul. From dhubler at pingtel.com Wed Nov 29 20:51:51 2006 From: dhubler at pingtel.com (Douglas Hubler) Date: Wed, 29 Nov 2006 20:51:51 +0000 (UTC) Subject: automate rpm signing? References: Message-ID: Thanks all for your post it's helped me invalidate folklore about surpressing password prompting and allow me to automate via the helpful expect script that was posted. I'm down to the fact I cannot get rpm signature checking to work with subkeys. I posted to rpm list http://article.gmane.org/gmane.linux.redhat.rpm.general/11244 From jstodaro at us.ibm.com Wed Nov 29 21:58:49 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Wed, 29 Nov 2006 16:58:49 -0500 Subject: automate rpm signing? In-Reply-To: Message-ID: Douglas Hubler wrote on 11/29/2006 03:51:51 PM: > Thanks all for your post it's helped me invalidate folklore about surpressing > password prompting and allow me to automate via the helpful expect script that > was posted. Here, in fact I made some enhancements to the script a couple days ago. I used to code in Tcl/Expect (and Perl) in a past life, before I was introduced to Python!(; See what you can do with it. Joe > > I'm down to the fact I cannot get rpm signature checking to work > with subkeys. > I posted to rpm list > http://article.gmane.org/gmane.linux.redhat.rpm.general/11244 > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: extras-signer.ex Type: application/octet-stream Size: 2150 bytes Desc: not available URL: From ndbecker2 at gmail.com Thu Nov 9 13:28:31 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 09 Nov 2006 13:28:31 -0000 Subject: Announcing pungi-0.1.0 In-Reply-To: <200611090824.49538.jkeating@redhat.com> References: <200611082038.25862.jkeating@redhat.com> <200611090824.49538.jkeating@redhat.com> Message-ID: <200611090828.23144.ndbecker2@gmail.com> On Thursday 09 November 2006 8:24 am, Jesse Keating wrote: > On Thursday 09 November 2006 06:29, Neal Becker wrote: > > Tried the test. Just went round in circles saying "finding deps for ..." > > or some words to that effect. I let it run overnight. Never got out of > > that loop. > > What arch did you run it on, and did you change the comps file at all? x86_64. FC6 machine with pretty much everything installed. No, didn't change comps. I don't usually use yum (I prefer smart), so maybe my yum configs aren't up to date on this machine - in that case they are whatever came with FC6. From ndbecker2 at gmail.com Thu Nov 9 13:54:00 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 09 Nov 2006 13:54:00 -0000 Subject: Announcing pungi-0.1.0 In-Reply-To: <1163080318.13997.0.camel@cutter> References: <200611082038.25862.jkeating@redhat.com> <200611090836.53753.jkeating@redhat.com> <1163080318.13997.0.camel@cutter> Message-ID: <200611090853.55354.ndbecker2@gmail.com> On Thursday 09 November 2006 8:51 am, seth vidal wrote: > On Thu, 2006-11-09 at 08:36 -0500, Jesse Keating wrote: > > On Thursday 09 November 2006 08:24, Jesse Keating wrote: > > > On Thursday 09 November 2006 06:29, Neal Becker wrote: > > > > Tried the test. Just went round in circles saying "finding deps for > > > > ..." or some words to that effect. I let it run overnight. Never > > > > got out of that loop. > > > > > > What arch did you run it on, and did you change the comps file at all? > > > > oh wait, I forgot about this. There was/is a bug in yum that made > > package comparison not work quite right. It was fixed upstream and I > > thought we issued an update for FC6 that would resolve this. > > 1. it was in 3.0-6 > 2. it's included in the yum 3.0.1 release tarball. > > -sv rpm -q yum yum-3.0-6