FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-05-2010, 10:27 PM
Jesse Keating
 
Default Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

-----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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2010, 10:43 PM
Michał Piotrowski
 
Default Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

Hi,

2010/10/6 Jesse Keating <jkeating@redhat.com>:
> -----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.

Is there somewhere a list of packages potentially broken on F14?

Regards,
Michal

>
> 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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel-announce
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2010, 10:56 PM
Tom Lane
 
Default Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

Jesse Keating <jkeating@redhat.com> writes:
> 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 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).

Could you provide a list of the packages you are intending to rebuild?
Or at least the exact dates where the bad gcc was in use?

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2010, 11:10 PM
Jesse Keating
 
Default Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/5/10 3:43 PM, Micha? Piotrowski wrote:
> Is there somewhere a list of packages potentially broken on F14?

http://fpaste.org/7dvk/ is a list of "broken" F14 builds. The syntax is:

packagename : detected bad build : tag that build is in

This was generated a few days ago, so many of the packages have had
newer builds by now. I'm just using this as a "starting point" for the
scripts which actually execute the bump/build.

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

iEYEARECAAYFAkyrsFUACgkQ4v2HLvE71NXK8QCfZI4SCJeVZi 3oHCXyUV1A0yLe
ZTsAnihyUnG8Ea+S+wWbSUzjqmbgQThc
=Nuah
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2010, 11:17 PM
Jesse Keating
 
Default Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/5/10 3:56 PM, Tom Lane wrote:
> Could you provide a list of the packages you are intending to rebuild?

See my reply to Michal

> Or at least the exact dates where the bad gcc was in use?

The bad gcc was tagged into dist-f14 on Fri Sep 10 20:24:00 2010. It
would have been in the buildroots a short time after, whenever the next
newRepo command completed.

The fixed gcc was tagged into dist-f14 on Sun Sep 26 20:50:11 2010. It
would have been in the buildroots a short time after, whenever the next
newRepo command completed.

That is your window for when potentially bad builds happened.

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

iEYEARECAAYFAkyrsfkACgkQ4v2HLvE71NW28ACgsfI9FbLwwO tTpyzrpZHeFlcs
mzkAoLutDh5sIvWu+rm9W0K9ESnkrlpj
=oatC
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2010, 11:22 PM
Michał Piotrowski
 
Default Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

2010/10/6 Jesse Keating <jkeating@redhat.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/5/10 3:43 PM, Micha? Piotrowski wrote:
>> Is there somewhere a list of packages potentially broken on F14?
>
> http://fpaste.org/7dvk/ is a list of "broken" F14 builds. ┬*The syntax is:

Thanks. I hope that all of these packages will soon be rebuilded

Regards,
Michal

>
> packagename : detected bad build : tag that build is in
>
> This was generated a few days ago, so many of the packages have had
> newer builds by now. ┬*I'm just using this as a "starting point" for the
> scripts which actually execute the bump/build.
>
> - --
> 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/
>
> iEYEARECAAYFAkyrsFUACgkQ4v2HLvE71NXK8QCfZI4SCJeVZi 3oHCXyUV1A0yLe
> ZTsAnihyUnG8Ea+S+wWbSUzjqmbgQThc
> =Nuah
> -----END PGP SIGNATURE-----
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-06-2010, 08:34 AM
Peter Robinson
 
Default Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

On Tue, Oct 5, 2010 at 11:27 PM, Jesse Keating <jkeating@redhat.com> 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-06-2010, 08:36 AM
Peter Robinson
 
Default Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

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

While in some cases this might be OK there is alot of packages that
have already diverged from rawhide.... I'm thinking of the gnome-3
stuff amongst others.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-06-2010, 08:44 AM
Tim Waugh
 
Default Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

On Tue, 2010-10-05 at 15:27 -0700, Jesse Keating wrote:
> 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.

For this sort of thing I would have thought that separate commits on
whichever branches need changing would be fine. Git's merging (if/when
each maintainer decides to merge branches) ought to be able to handle
that.

I don't think that merging "backwards" from master to f14 would be a
good idea. Wouldn't that bring "rawhide"-y changes into f14? For
example, ghostscript's master branch uses ghostscript-9.00 -- merging
master into f14 would cause havoc.

Or have I misunderstood what you are saying?

Tim.
*/

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-07-2010, 10:33 PM
Jesse Keating
 
Default Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/6/10 1:44 AM, Tim Waugh wrote:
> On Tue, 2010-10-05 at 15:27 -0700, Jesse Keating wrote:
>> 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.
>
> For this sort of thing I would have thought that separate commits on
> whichever branches need changing would be fine. Git's merging (if/when
> each maintainer decides to merge branches) ought to be able to handle
> that.
>
> I don't think that merging "backwards" from master to f14 would be a
> good idea. Wouldn't that bring "rawhide"-y changes into f14? For
> example, ghostscript's master branch uses ghostscript-9.00 -- merging
> master into f14 would cause havoc.
>
> Or have I misunderstood what you are saying?
>
> Tim.
> */
>
>

For a large number of packages, master and f14/master are identical, as
they have been merged together. These packages are kept in "sync"
across the releases, usually when upstream is only putting out bugfix
updates and the like. My script did not do anything to detect this kind
of scenario and play accordingly, which in this case would have been to
make the rebuild bump on master, then merge it back to f14/master.

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

iEYEARECAAYFAkyuStMACgkQ4v2HLvE71NWrawCfSbZYph918m ttaEINTYPbycQe
DoEAn1Grs5kcWtb5vbZYy5DBPEIFDTdD
=koVt
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 01:28 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org