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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux