5:27 p.m.
-----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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
5:43 p.m.
Hi,
2010/10/6 Jesse Keating <jkeating(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
5:56 p.m.
Jesse Keating <jkeating(a)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
5:59 p.m.
New subject: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
Jesse Keating wrote, at 10/06/2010 07:27 AM +9:00:
-----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.
<snip>
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.
How does this strategy go for packages that the latest dist-f14 one
was rebuilt using gcc-4.5.1-3.fc14, and there is newer dist-f14-updates-candidate
one rebuilt using gcc-4.5.1-3.fc14 but no bodhi submission yet?
Regards,
Mamoru
6:10 p.m.
-----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/
iEYEARECAAYFAkyrsFUACgkQ4v2HLvE71NXK8QCfZI4SCJeVZi3oHCXyUV1A0yLe
ZTsAnihyUnG8Ea+S+wWbSUzjqmbgQThc
=Nuah
-----END PGP SIGNATURE-----
6:17 p.m.
-----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/
iEYEARECAAYFAkyrsfkACgkQ4v2HLvE71NW28ACgsfI9FbLwwOtTpyzrpZHeFlcs
mzkAoLutDh5sIvWu+rm9W0K9ESnkrlpj
=oatC
-----END PGP SIGNATURE-----
6:19 p.m.
New subject: 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:59 PM, Mamoru Tasaka wrote:
> 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.
> >
How does this strategy go for packages that the latest dist-f14 one
was rebuilt using gcc-4.5.1-3.fc14, and there is newer dist-f14-updates-candidate
one rebuilt using gcc-4.5.1-3.fc14 but no bodhi submission yet?
Hrm. I'll have to check for this specific scenario and tease out
anything which fits. In these cases I think I'll have to look by hand
at what the differences are between the dist-f14 build and the
dist-f14-updates-candidate build is, and then work with the maintainer
on whether an update should be pushed or a build with the only change
being the gcc update done and pushed instead.
- --
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/
iEYEARECAAYFAkyrsn8ACgkQ4v2HLvE71NVhlACfUyXs6f2tP00/cwc6rZkyyaSB
F/gAnRHUZ46X9gBDODfTBDCCp+8kcMcs
=ffJI
-----END PGP SIGNATURE-----
6:22 p.m.
2010/10/6 Jesse Keating <jkeating(a)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/
iEYEARECAAYFAkyrsFUACgkQ4v2HLvE71NXK8QCfZI4SCJeVZi3oHCXyUV1A0yLe
ZTsAnihyUnG8Ea+S+wWbSUzjqmbgQThc
=Nuah
-----END PGP SIGNATURE-----
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3:34 a.m.
On Tue, Oct 5, 2010 at 11:27 PM, Jesse Keating <jkeating(a)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
3:36 a.m.
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.
3:44 a.m.
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.
*/
5:33 p.m.
-----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/
iEYEARECAAYFAkyuStMACgkQ4v2HLvE71NWrawCfSbZYph918mttaEINTYPbycQe
DoEAn1Grs5kcWtb5vbZYy5DBPEIFDTdD
=koVt
-----END PGP SIGNATURE-----
5:35 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/6/10 1:34 AM, Peter Robinson wrote:
What happens in a case where the packager is about to push a new
version, or there has been a rebuild since the 26th?
In this case my script will detect a new build in either
dist-f14-updates-candidate or dist-f14-updates-testing, and I'll
bump/build and replace the build in an update ticket if it exists.
In the case where a packager is /about/ to push a new version but hasn't
done the build yet, they should contact me to let me know and I can skip
their package.
- --
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/
iEYEARECAAYFAkyuSzIACgkQ4v2HLvE71NXhEwCfbiAO8mkaAdLIzNbJwVb1OQI+
aLkAnR0CE3YKodlbLQToB7S0/teKp+s1
=pgtC
-----END PGP SIGNATURE-----
10:09 a.m.
New subject: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
Hello:
Jesse Keating wrote, at 10/06/2010 07:27 AM +9:00:
-----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.
Would you update the current status of this issue?
For example I checked the current status of ruby-gnome2 (because
I was going to upgrade ruby-gnome2 on F-14) and
- still the latest ruby-gnome2 on F-14 is ruby-gnome2-0.90.2-1.fc14
- this one uses the problematic gcc
- while it seemed that ruby-gnome2 was rebuilt against newer gcc
(with EVR: ruby-gnome2-0.90.2-1.fc14.1), this new ruby-gnome2 was
never pushed into dist-f14 or submitted on bodhi.
So are there any list file which suggests what packages still need
repush (after rebuild or update) for this gcc issue?
Regards,
Mamoru
5:42 p.m.
New subject: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/25/10 8:09 AM, Mamoru Tasaka wrote:
Hello:
Jesse Keating wrote, at 10/06/2010 07:27 AM +9:00:
> -----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.
>
Would you update the current status of this issue?
For example I checked the current status of ruby-gnome2 (because
I was going to upgrade ruby-gnome2 on F-14) and
- still the latest ruby-gnome2 on F-14 is ruby-gnome2-0.90.2-1.fc14
- this one uses the problematic gcc
- while it seemed that ruby-gnome2 was rebuilt against newer gcc
(with EVR: ruby-gnome2-0.90.2-1.fc14.1), this new ruby-gnome2 was
never pushed into dist-f14 or submitted on bodhi.
So are there any list file which suggests what packages still need
repush (after rebuild or update) for this gcc issue?
Regards,
Mamoru
Current status is that almost all the builds are done and in the proper
location. There are a few stragglers, and you may have identified one.
The effort was put on hold as we get Fedora 14 ready for release.
Anything in F14 GA that could be effected will see a post-release update.
As for ruby-gnome2, the build you have in updates-testing, if it goes
stable, will suffice.
- --
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/
iEYEARECAAYFAkzGB7kACgkQ4v2HLvE71NXX/gCfasPcIg7JV9OchitCGWVMpRl7
dnwAoKZ1oUR/GUDotEgdo87EA7uwRHKU
=V1qH
-----END PGP SIGNATURE-----
5:45 p.m.
On 10/5/10 3:27 PM, Jesse Keating wrote:
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.
Now that F14 has shipped and other emergencies have been dealt with, I
got back into this task.
Unfortunately as time has gone on, there is now builds in
dist-f14-updates to deal with as well as dist-f14, so I wanted to ping
the list before I continue.
I've identified a number of published builds that are still potentially
broken in the F14 family, and have fixed builds for many of them. The
real question is what to do with things in dist-f14 or dist-f14-updates
that are potentially bad.
What we did with the first round was to just tag the rebuilds on top of
the previous build, if nothing else had changed. This was deemed safe
enough to bypass updates-testing. That was pre-release though, we're
not post-release, does this thought still stand?
We could tag things directly into dist-f14-updates, bypassing bodhi or
we could create new bodhi update requests for each item and either get
karma or wait for the timeout. We're talking about 72 update requests
that could be filed right now.
There are also a few packages where a "fixed" build doesn't exist yet
due to errors. Those need closer examination.
Finally we have some builds that are in -testing that are potentially
bad. I've replaced those with good builds and re-sent them back to
-testing, the maintainer can choose to push them stable at will.
Here is a list of the current known potentially bad builds and what
action could be or has been taken:
wireshark - Update pending
wildmidi - my rebuild can be tagged
usermode - my build can be tagged
tigervnc - my build can be tagged
tecnoballz - my build can be tagged
tar - Update in testing
syncevolution - update in testing
spamass-milter - my build can be tagged
shiboken - my build can be tagged
rtpproxy - my build can be tagged
raul - my build can be tagged
python-storm - my build can be tagged
python-crypto - my build can be tagged
python - potential update in -candidate; pinged dmalcolm
pycryptopp - my build can be tagged.
pspp - my build can be tagged
plee-the-bear - my build can be tagged
perl-Text-Hunspell - my build can be tagged
openchange - my build can be tagged
nxtrc - my build can be tagged
nasm - update in testing
mutter-moblin - my build can be tagged (and tag into dist-f15)
mutt - my build can be tagged
moblin-panel-status - my build can be tagged
moblin-panel-people - my build can be tagged
moblin-panel-myzone - my build can be tagged
moblin-panel-applications - my build can be tagged
minicom - my build can be tagged
midori - my build can be tagged
meego-panel-datetime - update in testing
matahari - my build can be tagged
libvte-java - spots build can be tagged
libunicapgtk - my build can be tagged
libselinux - update in testing
libpst - my build can be tagged
libnxt - my build can be tagged
libnfc - my build can be tagged
libmutil - my build can be tagged
liblastfm - my build can be tagged
libgtk-java - no build
libgnome-java - no build
libglade-java - no build
libclaw - my build can be tagged
libass - my build can be tagged
lensfun - my build can be tagged
ledger - my build can be tagged
koffice - my build can be tagged
jana - my build can be tagged
jack_capture - my build can be tagged
gtk+extra - my build can be tagged
gstreamer-plugins-bad-free - my build can be tagged
gridsite - my build can be tagged
gretl - update in testing
gnustep-examples - my build can be tagged
glib-java - my build can be tagged
ghostscript - update in candidate, ping owner
ghc-terminfo - my build can be tagged
ghc-pango - my build can be tagged
ghc-gio - no build
ghc-Boolean - my build can be tagged
generatorrunner - my build can be tagged
gedit-vala - my build can be tagged
gcc - update in -candidate, ping jakub
gappa - my build can be tagged
fuse-convmvfs - my build can be tagged
frepple - my build can be tagged
folks - my build can be tagged
flowcanvas - my build can be tagged
elfutils - my build can be tagged
dssi - my build can be tagged
dspam - my build can be tagged
contacts - my build can be tagged
clutter-gtk - fixed build in updates
clutter - my build can be tagged
chktex - my build can be tagged
celt - my build can be tagged
ccache - my build can be tagged
calf - my build can be tagged
bluefish - update in testing
awn-extras-applets - my build can be tagged
avr-gcc - my build can be tagged
atanks - my build can be tagged
apiextractor - my build can be tagged
apcupsd - my build can be tagged
R-ROC - my build can be tagged
http-parser - my build can be tagged
libeio - my build can be tagged
setuptool - my build can be tagged
mailman - update in testing
ldc - removed from updates-testing
igraph - update in testing
busybox - update in testing
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:49 p.m.
On Tue, Nov 23, 2010 at 03:45:26PM -0800, Jesse Keating wrote:
gcc - update in -candidate, ping jakub
Just remove gcc from your list. gcc is bootstrapped, so
the installed gcc only builds first stage, everything else
is built by (one of the) newly built compiler(s).
So, gcc in f14 surely doesn't have that problem in it.
I'll eventually do a f14 gcc errata, but only when I accumulate more
fixes...
Jakub
6:03 p.m.
On 11/23/10 3:49 PM, Jakub Jelinek wrote:
On Tue, Nov 23, 2010 at 03:45:26PM -0800, Jesse Keating wrote:
> gcc - update in -candidate, ping jakub
Just remove gcc from your list. gcc is bootstrapped, so
the installed gcc only builds first stage, everything else
is built by (one of the) newly built compiler(s).
So, gcc in f14 surely doesn't have that problem in it.
I'll eventually do a f14 gcc errata, but only when I accumulate more
fixes...
Jakub
Thanks!
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
7:04 p.m.
New subject: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
On 11/23/2010 03:45 PM, Jesse Keating wrote:
Here is a list of the current known potentially bad builds and what
action could be or has been taken:
Please alphabetize such a list, always! _PLEASE_?
An alphabetized list is several times more effective at communication
because advanced readers can process it more quickly "by eye"
than a list that is in random order. Most mail user agent (MUA) software
provides tools for string search, but using that often takes more time
than a scan-and-PageDown.
apcupsd - my build can be tagged
apiextractor - my build can be tagged
atanks - my build can be tagged
avr-gcc - my build can be tagged
awn-extras-applets - my build can be tagged
bluefish - update in testing
busybox - update in testing
calf - my build can be tagged
ccache - my build can be tagged
celt - my build can be tagged
chktex - my build can be tagged
clutter-gtk - fixed build in updates
clutter - my build can be tagged
contacts - my build can be tagged
dspam - my build can be tagged
dssi - my build can be tagged
elfutils - my build can be tagged
flowcanvas - my build can be tagged
folks - my build can be tagged
frepple - my build can be tagged
fuse-convmvfs - my build can be tagged
gappa - my build can be tagged
gcc - update in -candidate, ping jakub
gedit-vala - my build can be tagged
generatorrunner - my build can be tagged
ghc-Boolean - my build can be tagged
ghc-gio - no build
ghc-pango - my build can be tagged
ghc-terminfo - my build can be tagged
ghostscript - update in candidate, ping owner
glib-java - my build can be tagged
gnustep-examples - my build can be tagged
gretl - update in testing
gridsite - my build can be tagged
gstreamer-plugins-bad-free - my build can be tagged
gtk+extra - my build can be tagged
http-parser - my build can be tagged
igraph - update in testing
jack_capture - my build can be tagged
jana - my build can be tagged
koffice - my build can be tagged
ldc - removed from updates-testing
ledger - my build can be tagged
lensfun - my build can be tagged
libass - my build can be tagged
libclaw - my build can be tagged
libeio - my build can be tagged
libglade-java - no build
libgnome-java - no build
libgtk-java - no build
liblastfm - my build can be tagged
libmutil - my build can be tagged
libnfc - my build can be tagged
libnxt - my build can be tagged
libpst - my build can be tagged
libselinux - update in testing
libunicapgtk - my build can be tagged
libvte-java - spots build can be tagged
mailman - update in testing
matahari - my build can be tagged
meego-panel-datetime - update in testing
midori - my build can be tagged
minicom - my build can be tagged
moblin-panel-applications - my build can be tagged
moblin-panel-myzone - my build can be tagged
moblin-panel-people - my build can be tagged
moblin-panel-status - my build can be tagged
mutter-moblin - my build can be tagged (and tag into dist-f15)
mutt - my build can be tagged
nasm - update in testing
nxtrc - my build can be tagged
openchange - my build can be tagged
perl-Text-Hunspell - my build can be tagged
plee-the-bear - my build can be tagged
pspp - my build can be tagged
pycryptopp - my build can be tagged.
python-crypto - my build can be tagged
python - potential update in -candidate; pinged dmalcolm
python-storm - my build can be tagged
raul - my build can be tagged
R-ROC - my build can be tagged
rtpproxy - my build can be tagged
setuptool - my build can be tagged
shiboken - my build can be tagged
spamass-milter - my build can be tagged
syncevolution - update in testing
tar - Update in testing
tecnoballz - my build can be tagged
tigervnc - my build can be tagged
usermode - my build can be tagged
wildmidi - my rebuild can be tagged
wireshark - Update pending
--
9:42 p.m.
New subject: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
On 11/23/10 5:04 PM, John Reiser wrote:
Please alphabetize such a list, always! _PLEASE_?
An alphabetized list is several times more effective at communication
because advanced readers can process it more quickly "by eye"
than a list that is in random order. Most mail user agent (MUA) software
provides tools for string search, but using that often takes more time
than a scan-and-PageDown.
This wasn't a list of things maintainers needed to perform an action
upon. If it were, I would have sorted it, by package owner. This was
more of just a listing of the actions that /I/ would be doing, a list of
the packages.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:32 a.m.
New subject: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
Hi,
On 11/24/2010 12:45 AM, Jesse Keating wrote:
On 10/5/10 3:27 PM, Jesse Keating wrote:
<snip>
Here is a list of the current known potentially bad builds and what
action could be or has been taken:
wildmidi - my rebuild can be tagged
tecnoballz - my build can be tagged
These 2 are mine and FWIW, I'm ok with directly tagging
the rebuilds into updates
Regards,
Hans
2:33 a.m.
On Wed, Nov 24, 2010 at 8:32 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
Hi,
On 11/24/2010 12:45 AM, Jesse Keating wrote:
> On 10/5/10 3:27 PM, Jesse Keating wrote:
<snip>
>
> Here is a list of the current known potentially bad builds and what
> action could be or has been taken:
>
> wildmidi - my rebuild can be tagged
> tecnoballz - my build can be tagged
These 2 are mine and FWIW, I'm ok with directly tagging
the rebuilds into updates
Actually tecnoballz is mine. But I'm ok with the tagging anyway.
Bye,
Andrea.
3:21 a.m.
Here is a list of the current known potentially bad builds and what
action could be or has been taken:
The below I either maintain or co-maintain.
Ignore, I have another build that needs to be pushed:
syncevolution - update in testing
Fine to tag for F-14, its obsolete in F-15 (I thought it was blocked -
will check):
mutter-moblin - my build can be tagged (and tag into dist-f15)
Happy for all the below to be tagged:
moblin-panel-status - my build can be tagged
moblin-panel-people - my build can be tagged
moblin-panel-myzone - my build can be tagged
moblin-panel-applications - my build can be tagged
jana - my build can be tagged
clutter - my build can be tagged
celt - my build can be tagged
Should be in updates or nearly there:
meego-panel-datetime - update in testing
clutter-gtk - fixed build in updates
Cheers,
Peter
4895
days inactive
4945
days old
23 comments
11 participants
participants (11)
-
Andrea Musuruane -
Hans de Goede -
Jakub Jelinek -
Jesse Keating -
John Reiser -
Mamoru Tasaka -
Michał Piotrowski -
Peter Robinson -
Tim Waugh -
Tom Lane -
Ville Skyttä