-----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
_______________________________________________ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
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
-----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
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/
iEYEARECAAYFAkyrsFUACgkQ4v2HLvE71NXK8QCfZI4SCJeVZi3oHCXyUV1A0yLe ZTsAnihyUnG8Ea+S+wWbSUzjqmbgQThc =Nuah
-----END PGP SIGNATURE-----
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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
-----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
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
-----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
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
-----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
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.
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. */
-----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
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
-----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
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
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
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!
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
--
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.
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
On Wed, Nov 24, 2010 at 8:32 AM, Hans de Goede hdegoede@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.
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
devel@lists.stg.fedoraproject.org
-
Andrea Musuruane -
Hans de Goede -
Jakub Jelinek -
Jesse Keating -
John Reiser -
Mamoru Tasaka -
Michał Piotrowski -
Peter Robinson -
Tim Waugh -
Tom Lane -
Ville Skyttä