-----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.
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.
* 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.
PS I had a small misfire in some of the F14 builds, I used the wrong input set of packages. There is a chance that some f14 builds were done unnecessarily. The unnecessary builds will just be ignored and left to expire.
PPS I did not modify my bump script yet to attempt a commit to master and merge to the f14 branch. In the interest of time, I took the easy route and just did commits to the f14 branch. Maintainers can do a merge and fixup after the builds have been done if they wish to have their branches in sync with master once more.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
devel-announce@lists.fedoraproject.org
-
Jesse Keating