#256782 has been around for too long!
This needs to be done for bug #288621.
amd64 stable
I should add that the gcc-4.3.4 upgrade i did last night, from the stable tree required recompiling everything... and the current stable version of dev86-0.16.17-r5 buffer bug choked my `emerge -eav world` halfway through a 900-package pull. Not too pleasant to wake up and find that :/
(In reply to comment #3) > I should add that the gcc-4.3.4 upgrade i did last night, from the stable tree > required recompiling everything... There is no need to recompile everything because of this update. and the current stable version of > dev86-0.16.17-r5 buffer bug choked my `emerge -eav world` halfway through a > 900-package pull. Not too pleasant to wake up and find that :/ > You could have keyworded the new version yourself locally.
(In reply to comment #4) > (In reply to comment #3) > > I should add that the gcc-4.3.4 upgrade i did last night, from the stable tree > > required recompiling everything... > > There is no need to recompile everything because of this update. This doesn't make the bug go away. One might also want to optimize his/her system to the maximum, hoping that a new version of gcc will help, change his/her C(XX)FLAGS etc which might require recompiling everything. > and the current stable version of > > dev86-0.16.17-r5 buffer bug choked my `emerge -eav world` halfway through a > > 900-package pull. Not too pleasant to wake up and find that :/ > > > > You could have keyworded the new version yourself locally. Yes, definitely if one was psychic enough to foresee this bug. That is not the solution. When one issues a "emerge -e world", he/she expects this command to re-emerge those 900 packages successfully in, lets say, 12 hours. Its a major failure if only 90 of those packages get emerged in a hour and an error occurs. Twelve hours later the administrator might come back and discover that he/she is 12 hours behind schedule. Not good. That was actually the motivation for me to file this bug.
(In reply to comment #5) > When one issues a "emerge -e world", he/she expects this command to re-emerge > those 900 packages successfully in, lets say, 12 hours. Its a major failure if > only 90 of those packages get emerged in a hour and an error occurs. Twelve > hours later the administrator might come back and discover that he/she is 12 > hours behind schedule. Not good. That was actually the motivation for me to > file this bug. > That's what --keep-going was invented for.
x86 stable, sorry for the hassle, but proper bug dependencies would be fine. Anyway, fixed on x86.
(In reply to comment #6) > (In reply to comment #5) > > When one issues a "emerge -e world", he/she expects this command to re-emerge > > those 900 packages successfully in, lets say, 12 hours. Its a major failure if > > only 90 of those packages get emerged in a hour and an error occurs. Twelve > > hours later the administrator might come back and discover that he/she is 12 > > hours behind schedule. Not good. That was actually the motivation for me to > > file this bug. > > > > That's what --keep-going was invented for. > Thanks for the info! :) Without siding on any case (being pshchic, using emerge more carefully, etc) - I think what we can all agree on is that this is package is a compiler, and will undoubtedly get pulled at critical times, which means that having an ugly duckling sitting in stable and a healthy one in unstable makes absolutely no sense. With that said, the amd64 version works great - please mark as stable :)
amd64 stable, all arches done.
