Re: deltarpms not working since rawhide was signed
Chuck Anderson (c...@wpi.edu) said: The infrastructure should either delete and regenerate drpms after the rpm signatures have changed or they should use the code fragment from https://fedorahosted.org/koji/ticket/38#comment:3 to attach rpm signatures to deltarpms. That's *really* hard, as there's not any state to track when packages have been signed out from under the prior delta rpms. The simplest solution would be to just nuke the old ones by hand. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
On Mon, 27 Apr 2009, Bill Nottingham wrote: Chuck Anderson (c...@wpi.edu) said: The infrastructure should either delete and regenerate drpms after the rpm signatures have changed or they should use the code fragment from https://fedorahosted.org/koji/ticket/38#comment:3 to attach rpm signatures to deltarpms. That's *really* hard, as there's not any state to track when packages have been signed out from under the prior delta rpms. The simplest solution would be to just nuke the old ones by hand. when they are signed? or nuke them in createrepo? -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
Seth Vidal (skvi...@fedoraproject.org) said: That's *really* hard, as there's not any state to track when packages have been signed out from under the prior delta rpms. The simplest solution would be to just nuke the old ones by hand. when they are signed? or nuke them in createrepo? When rawhide becomes signed, nuke the old drpnms by hand in the tree we're diffing against, so they're not carried forward. If createrepo wants to do signature checking of drpms when it's creating the metadata, it can, and that would also fix this. But that's more work. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
On Mon, 27 Apr 2009, Bill Nottingham wrote: Seth Vidal (skvi...@fedoraproject.org) said: That's *really* hard, as there's not any state to track when packages have been signed out from under the prior delta rpms. The simplest solution would be to just nuke the old ones by hand. when they are signed? or nuke them in createrepo? When rawhide becomes signed, nuke the old drpnms by hand in the tree we're diffing against, so they're not carried forward. If createrepo wants to do signature checking of drpms when it's creating the metadata, it can, and that would also fix this. But that's more work. Yah - I kinda wonder if it is worth the time to check all of them to weed out the no-longer valid ones. -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
deltarpms not working since rawhide was signed
As stated by Jonathan Dieter in the bug below, deltarpms are mucking up rawhide updates right now because the drpms were created before the packages were signed, and the signed versions don't match the deltarpm reconstructed versions. For me at least, this is causing a problem because I'm not using a mirrorlist right now (too many problems with metalink mismatches). So when yum fails to accept the drpm-patched package, the yum update just fails outright because there are no more mirrors to get the full updated package from. Is there anything that can be done on the infastructure side as proposed below? https://bugzilla.redhat.com/show_bug.cgi?id=497459 Comment #2 From Jonathan Dieter (jdie...@gmail.com) 2009-04-24 11:18:36 EDT (-) [reply] --- This is not a deltarpm bug or a yum-presto bug, but rather an Infrastructure bug. The deltarpm was created before the target rpm was gpg signed. So it does indeed build to a valid rpm with exactly the same data as the downloaded rpm, but without the signature. Because it's not exactly the same file, yum refuses to use it and redownloads the full (signed) rpm (which is what it should do). The infrastructure should either delete and regenerate drpms after the rpm signatures have changed or they should use the code fragment from https://fedorahosted.org/koji/ticket/38#comment:3 to attach rpm signatures to deltarpms. Not sure how to reassign to Infrastructure. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
On Fri, Apr 24, 2009 at 06:12:12PM -0400, Chuck Anderson wrote: As stated by Jonathan Dieter in the bug below, deltarpms are mucking up rawhide updates right now because the drpms were created before the packages were signed, and the signed versions don't match the deltarpm reconstructed versions. For me at least, this is causing a problem because I'm not using a mirrorlist right now (too many problems with metalink mismatches). can you elaborate on this point? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
On Fri, 24 Apr 2009, Chuck Anderson wrote: As stated by Jonathan Dieter in the bug below, deltarpms are mucking up rawhide updates right now because the drpms were created before the packages were signed, and the signed versions don't match the deltarpm reconstructed versions. For me at least, this is causing a problem because I'm not using a mirrorlist right now (too many problems with metalink mismatches). So when yum fails to accept the drpm-patched package, the yum update just fails outright because there are no more mirrors to get the full updated package from. Is there anything that can be done on the infastructure side as proposed below? https://bugzilla.redhat.com/show_bug.cgi?id=497459 Comment #2 From Jonathan Dieter (jdie...@gmail.com) 2009-04-24 11:18:36 EDT (-) [reply] --- This is not a deltarpm bug or a yum-presto bug, but rather an Infrastructure bug. The deltarpm was created before the target rpm was gpg signed. So it does indeed build to a valid rpm with exactly the same data as the downloaded rpm, but without the signature. Because it's not exactly the same file, yum refuses to use it and redownloads the full (signed) rpm (which is what it should do). The infrastructure should either delete and regenerate drpms after the rpm signatures have changed or they should use the code fragment from https://fedorahosted.org/koji/ticket/38#comment:3 to attach rpm signatures to deltarpms. Not sure how to reassign to Infrastructure. Just so this doesn't get forgotten about I've created a rel-eng ticket: https://fedorahosted.org/rel-eng/ticket/1637 -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
I'm seeing the metalink problem and will investigate the cause. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -Original Message- From: Matt Domsch matt_dom...@dell.com Date: Fri, 24 Apr 2009 18:02:35 To: fedora-infrastructure-list@redhat.com Subject: Re: deltarpms not working since rawhide was signed On Fri, Apr 24, 2009 at 06:12:12PM -0400, Chuck Anderson wrote: As stated by Jonathan Dieter in the bug below, deltarpms are mucking up rawhide updates right now because the drpms were created before the packages were signed, and the signed versions don't match the deltarpm reconstructed versions. For me at least, this is causing a problem because I'm not using a mirrorlist right now (too many problems with metalink mismatches). can you elaborate on this point? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
On Sat, 25 Apr 2009, Matt Domsch wrote: I'm seeing the metalink problem and will investigate the cause. I haven't actually sat down and looked at this yet, is it completely a metalink problem or are there two different things going on? -Mike -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -Original Message- From: Matt Domsch matt_dom...@dell.com Date: Fri, 24 Apr 2009 18:02:35 To: fedora-infrastructure-list@redhat.com Subject: Re: deltarpms not working since rawhide was signed On Fri, Apr 24, 2009 at 06:12:12PM -0400, Chuck Anderson wrote: As stated by Jonathan Dieter in the bug below, deltarpms are mucking up rawhide updates right now because the drpms were created before the packages were signed, and the signed versions don't match the deltarpm reconstructed versions. For me at least, this is causing a problem because I'm not using a mirrorlist right now (too many problems with metalink mismatches). can you elaborate on this point? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
On Fri, Apr 24, 2009 at 07:15:51PM -0500, Mike McGrath wrote: On Sat, 25 Apr 2009, Matt Domsch wrote: I'm seeing the metalink problem and will investigate the cause. I haven't actually sat down and looked at this yet, is it completely a metalink problem or are there two different things going on? metalinks are definitely sometimes wrong. For example, a repomd.xml file for updates/10/x86_64 that updated at -rw-r--r-- 1 263 mirrors 2391 Apr 24 19:35 repomd.xml was not being reported in the metalink at Date: Fri, 24 Apr 2009 23:15:02 GMT and I'm not yet sure why. update-master-directory-list is running a little more often than twice an hour on average, and the mirrorlist cache is updating every hour as expected. So the data is either not getting picked up during u-m-d-l runs, or is somehow not getting from the DB into the mirrorlist cache. If you see me monkey with u-m-d-l on bapp1, that's what I'm trying to figure out... -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
On Fri, Apr 24, 2009 at 07:15:51PM -0500, Mike McGrath wrote: On Sat, 25 Apr 2009, Matt Domsch wrote: I'm seeing the metalink problem and will investigate the cause. I haven't actually sat down and looked at this yet, is it completely a metalink problem or are there two different things going on? the drpm issue is completely different from the metalink problem. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
On Fri, Apr 24, 2009 at 07:44:50PM -0500, Matt Domsch wrote: If you see me monkey with u-m-d-l on bapp1, that's what I'm trying to figure out... Found it... update-master-directory-list was trying to be smart and failed. If it saw that a directory's ctime hadn't changed, it skipped it and moved on. But, a directory's ctime won't change if one of its _subdirectories' ctime_ changes. Because u-m-d-l runs every 30 minutes or so, it appears to catch tree updates mid-flight. In one run it sees updates/10/x86_64/ has changed, but that repodata/ under that has not (yet). So it marks updates/10/x86_64 as changed and moves on. On the next pass, updates/10/x86_64 of course _has not changed_, but it's repodata subdir has. This is what it was missing... It would skip processing the repodata subdir. (and yes, this would throw off the crawler too, which people have been complaining about being added and removed from the list somewhat randomly...) I'm working on a fix, which will involve changing update-master-directory-list. But that should be the only change. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
