From wacker at octothorp.org Fri Jan 1 00:12:48 2010 From: wacker at octothorp.org (William F. Acker WB2FLW +1 303 722 7209) Date: Thu, 31 Dec 2009 17:12:48 -0700 (MST) Subject: How to handel spinning when i686 versions of packages don't make it into the updates repo? In-Reply-To: <1262251832.602.0.camel@tonnant> References: <1262251832.602.0.camel@tonnant> Message-ID: On Thu, 31 Dec 2009, Jon Masters wrote: > On Wed, 2009-12-30 at 00:05 -0700, William F. Acker WB2FLW +1 303 722 > 7209 wrote: > >> I've always noticed that when a package is updated, sometimes the >> i686 version isn't put into the x86_64 repo for updates. > > Can you clarify what you're asking here? It sounds like you're saying > you expect the x86_64 repo to contain i686 packages? > Um, -- well- -- yes. It always does. My concern is that when packages are updated, and there is an i686 and x86_64 version in the original release tree, the updates tree only has the x86_64 version, which is why I ask the question of how to handle it. I could make sure that only the x86_64 version of the package appears on the release I'm spinning, or should I make sure that the updated i686 package is carried to my release if it was present in the original release by Fedora. I hope this clarifies my concern. -- Bill in Denver From mikem at redhat.com Mon Jan 4 16:11:09 2010 From: mikem at redhat.com (Mike McLean) Date: Mon, 04 Jan 2010 11:11:09 -0500 Subject: How to handel spinning when i686 versions of packages don't make it into the updates repo? In-Reply-To: References: Message-ID: <4B42131D.8050708@redhat.com> On 12/30/2009 02:05 AM, William F. Acker WB2FLW +1 303 722 7209 wrote: > I've always noticed that when a package is updated, sometimes the i686 > version isn't put into the x86_64 repo for updates. As a workaround, I Can you give some examples? If multilib content is inconsistent across updates then we really ought to sort that out. From jkeating at redhat.com Mon Jan 4 16:32:36 2010 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 Jan 2010 08:32:36 -0800 Subject: How to handel spinning when i686 versions of packages don't make it into the updates repo? In-Reply-To: <4B42131D.8050708@redhat.com> References: <4B42131D.8050708@redhat.com> Message-ID: <1262622756.32656.1.camel@localhost.localdomain> On Mon, 2010-01-04 at 11:11 -0500, Mike McLean wrote: > On 12/30/2009 02:05 AM, William F. Acker WB2FLW +1 303 722 7209 wrote: > > I've always noticed that when a package is updated, sometimes the i686 > > version isn't put into the x86_64 repo for updates. As a workaround, I > > Can you give some examples? If multilib content is inconsistent across > updates then we really ought to sort that out. > Multilib set is dynamically determined each compose. If the package itself changes in a way that no longer triggers the multilib algorithm, then it will fall out of being multilib. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mikem at redhat.com Mon Jan 4 23:08:20 2010 From: mikem at redhat.com (Mike McLean) Date: Mon, 04 Jan 2010 18:08:20 -0500 Subject: How to handel spinning when i686 versions of packages don't make it into the updates repo? In-Reply-To: <1262622756.32656.1.camel@localhost.localdomain> References: <4B42131D.8050708@redhat.com> <1262622756.32656.1.camel@localhost.localdomain> Message-ID: <4B4274E4.6040707@redhat.com> On 01/04/2010 11:32 AM, Jesse Keating wrote: > Multilib set is dynamically determined each compose. If the package > itself changes in a way that no longer triggers the multilib algorithm, > then it will fall out of being multilib. Is there a mechanism to remove 'fallen' multilib packages? If not, couldn't there be update errors? For that matter, what if the lingering older multilib package contains a security flaw? My apologies if this has been discussed to death elsewhere. From jkeating at redhat.com Tue Jan 5 01:22:44 2010 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 Jan 2010 17:22:44 -0800 Subject: How to handel spinning when i686 versions of packages don't make it into the updates repo? In-Reply-To: <4B4274E4.6040707@redhat.com> References: <4B42131D.8050708@redhat.com> <1262622756.32656.1.camel@localhost.localdomain> <4B4274E4.6040707@redhat.com> Message-ID: <1262654564.32656.9.camel@localhost.localdomain> On Mon, 2010-01-04 at 18:08 -0500, Mike McLean wrote: > Is there a mechanism to remove 'fallen' multilib packages? If not, > couldn't there be update errors? For that matter, what if the lingering > older multilib package contains a security flaw? > > My apologies if this has been discussed to death elsewhere. It is not often that this situation happens, and usually we take a second look at the type of update going in, and whether or not it would be suitable as an update to a stable Fedora release. Alas we cannot always detect this before the push goes live (autoqa will fix this, I hope). I do not know if the stale multilib version gets cleaned up or not. I think there is some code to handle it at anaconda upgrade time where this type of scenario is more likely to occur. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From wacker at octothorp.org Tue Jan 5 21:49:39 2010 From: wacker at octothorp.org (William F. Acker WB2FLW +1 303 722 7209) Date: Tue, 5 Jan 2010 14:49:39 -0700 (MST) Subject: How to handel spinning when i686 versions of packages don't make it into the updates repo? In-Reply-To: <4B42131D.8050708@redhat.com> References: <4B42131D.8050708@redhat.com> Message-ID: On Mon, 4 Jan 2010, Mike McLean wrote: > On 12/30/2009 02:05 AM, William F. Acker WB2FLW +1 303 722 7209 wrote: >> I've always noticed that when a package is updated, sometimes the i686 >> version isn't put into the x86_64 repo for updates. As a workaround, I > > Can you give some examples? If multilib content is inconsistent across > updates then we really ought to sort that out. Just since F12: java-1.6.0-openjdk, gcc, gcc-gfortran, libgfortran, libgomp and cpp More to come, I'm sure. -- Bill in Denver From dan at danny.cz Wed Jan 6 15:09:49 2010 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 06 Jan 2010 16:09:49 +0100 Subject: sign_unsigned.py with custom koji path Message-ID: <1262790589.2277.55.camel@eagle.danny.cz> Hello, I am running private Koji with /opt/koji path instead of the default /mnt/koji. But the sign_unsigned.py script from Fedora Infrastructure has no way to change the path, because it uses koji.pathinfo object that is preinitialized with /mnt/koji. The attached patch makes the path settable by the user. With regards, Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: sign_unsigned-kojipath.patch Type: text/x-patch Size: 1920 bytes Desc: not available URL: