Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

[Jesse Keating]

-----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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyrpk4ACgkQ4v2HLvE71NW6IwCbBex8eV/0M2eOmfqTqakx14zC
pDMAnA6iBmjaMC+E87fgp6CvLoxEhAiF
=GFLf
-----END PGP SIGNATURE-----
_______________________________________________
devel-announce mailing list
devel-announce at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce