On Tue, Oct 5, 2010 at 11:27 PM, Jesse Keating <jkeating@xxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > As you might be aware, there was a period of roughly two weeks where a > gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and > Fedora 15. Items built with this could have undefined behavior, which > could lead to data corruption. I was aware but only due to random packages of mine being rebuilt, I was wondering when the details were going to emege. > Unfortunately I'm told that it is impossible to look at a generated > binary and detect whether or not the binary would be effected by this > bug. The only reliable way to tell would be to re-create the build > environment exactly, except replace GCC with one that will detect the > error scenario and print something. As this is a significant amount of > work, I decided instead to just rebuild the potential problem builds. > > I detected all the "latest" builds of packages that had gcc-4.5.1-3.fc14 > in the buildroot, and then further narrowed it down to things which > require rtld(GNU_HASH) to find the things that actually used gcc (since > gcc gets thrown in every buildroot anyway). > > For Fedora 15 this was a simple task. Just find the packages where the > latest build is "bad", bump it and rebuild it. End of story. This work > is already done (except that a few have failed, and I need to follow up > on those). > > For Fedora 14 the matter is much more complicated. Builds are spread > out across 3 main tags, dist-f14, dist-f14-updates-testing, and > dist-f14-updates-candidate. > > dist-f14 is things that have made it through bodhi as stable. > > dist-f14-updates-testing is for things which are currently in > updates-testing > > dist-f14-updates-candidate is for things which could potentially become > an update should the maintainer decide. > > To handle the F14 scene I've come up with this strategy: > * For things tagged in dist-f14 and no newer build elsewhere, do a bump, > build and tag directly into dist-f14. While there is some risk of > breakage, it is quite minimal and with discussion from QA we are willing > to take that chance. This work is ongoing. > > * For things tagged in dist-f14-updates-testing, do a bump, build and > then edit the bodhi ticket to add the new build, and re-push to > updates-testing. This work will begin soon. This unfortunately also has the effect of resetting the timer possibly pushing things out to 14 days, which is some what painful. > * for things tagged in dist-f14-updates-candidate, do a bump and build. > Then look for an open bodhi ticket for that package, adjusting as > needed. If no bodhi ticket is found, do not create a new one, just > leave the build as is. This work will begin soon. > > Using this strategy we should be able to replace potentially bad builds > with corrected ones wherever they might have been published (barring the > failed builds). This message is mostly a heads up as to what's happening. What happens in a case where the packager is about to push a new version, or there has been a rebuild since the 26th? Peter -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
