On Tue, Oct 5, 2010 at 11:27 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
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
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 is things that have made it through bodhi as stable.
dist-f14-updates-testing is for things which are currently in
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
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?