Re: GCC 4.2 transition
* Aurelien Jarno ([EMAIL PROTECTED]) [070721 00:33]: On Fri, Jul 20, 2007 at 10:48:32PM +0200, Andreas Barth wrote: * Aurelien Jarno ([EMAIL PROTECTED]) [070720 21:15]: We (glibc maintainers) plan to do a change in glibc first. We will drop libc6-sparcv9 and change the optimizations of libc6 to SPARC v9 from SPARC v8. Doing it on the glibc first have the advantage that we can put a check in the preinst script to stop the installation on a SPARC v8 system. As libc6 is installed on all systems, that should prevent system breakages with SIGILL on random packages. This is already implemented in the SVN, and we plan to do the upload on Sunday. I hope this doesn't yet include another shlib bump (though it would be good if the sparc v9 binaries have one). Given the current situation wrt the transitions, we won't bump the shlib, though strictly speaking that should be necessary. Actually, I would like to see an shlib bump before gcc is changed (so that gcc and all binaries built by the new gcc depend on the new glibc). However, I agree that it is currently a unfortunate time for such a change. So, some ideas come to my mind: 1. delay glibc upload until glib transitioned to testing 2. do another upload with shlib bump after glib transitioned to testing, and wait with gcc to that upload. (there might be better combinations, but none comes currently to my mind) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
Andreas Barth a écrit : * Aurelien Jarno ([EMAIL PROTECTED]) [070721 00:33]: On Fri, Jul 20, 2007 at 10:48:32PM +0200, Andreas Barth wrote: * Aurelien Jarno ([EMAIL PROTECTED]) [070720 21:15]: We (glibc maintainers) plan to do a change in glibc first. We will drop libc6-sparcv9 and change the optimizations of libc6 to SPARC v9 from SPARC v8. Doing it on the glibc first have the advantage that we can put a check in the preinst script to stop the installation on a SPARC v8 system. As libc6 is installed on all systems, that should prevent system breakages with SIGILL on random packages. This is already implemented in the SVN, and we plan to do the upload on Sunday. I hope this doesn't yet include another shlib bump (though it would be good if the sparc v9 binaries have one). Given the current situation wrt the transitions, we won't bump the shlib, though strictly speaking that should be necessary. Actually, I would like to see an shlib bump before gcc is changed (so that gcc and all binaries built by the new gcc depend on the new glibc). However, I agree that it is currently a unfortunate time for such a change. So, some ideas come to my mind: 1. delay glibc upload until glib transitioned to testing 2. do another upload with shlib bump after glib transitioned to testing, and wait with gcc to that upload. (there might be better combinations, but none comes currently to my mind) We really wants to do an upload of the glibc soon to fix various things. What about the following combination: 1. Upload glibc without the shlib bump, but with the switch to SPARC V9 optimizations + check in the preinst script. 2. Upload glibc with shlib bump when the release team think it is the good time to do that. 3. Upload gcc with the switch to SPARC V9 optimizations. We may repeat the step 1 a few times. Ideally there should be almost now difference between the upload in step 1 and in step 2 (except the shlib bump) to ensure the version could go very quickly to testing. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
* Aurelien Jarno ([EMAIL PROTECTED]) [070721 18:51]: Andreas Barth a écrit : So, some ideas come to my mind: 1. delay glibc upload until glib transitioned to testing 2. do another upload with shlib bump after glib transitioned to testing, and wait with gcc to that upload. (there might be better combinations, but none comes currently to my mind) We really wants to do an upload of the glibc soon to fix various things. What about the following combination: 1. Upload glibc without the shlib bump, but with the switch to SPARC V9 optimizations + check in the preinst script. That means binaries built against it can still run on sparc v8 hardware, right? 2. Upload glibc with shlib bump when the release team think it is the good time to do that. 3. Upload gcc with the switch to SPARC V9 optimizations. That sounds like my 2. to me, so ok with me. Perhaps wait for another few hours so that another release team member might cluebat me in case I missed something before doing the upload 1.. We may repeat the step 1 a few times. Ideally there should be almost now difference between the upload in step 1 and in step 2 (except the shlib bump) to ensure the version could go very quickly to testing. That would be great indeed (and BTW, gcc could build-depend on the new glibc version on sparc to make sure it really depend on that version). (Weaker alternative would be to just shlib-bump gcc by adding the dependency information on sparc by hand, but that doesn't prevent newer binaries to go to testing without glibc, so probably a bad idea.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Sat, Jul 21, 2007 at 07:27:44PM +0200, Andreas Barth wrote: * Aurelien Jarno ([EMAIL PROTECTED]) [070721 18:51]: Andreas Barth a écrit : So, some ideas come to my mind: 1. delay glibc upload until glib transitioned to testing 2. do another upload with shlib bump after glib transitioned to testing, and wait with gcc to that upload. (there might be better combinations, but none comes currently to my mind) We really wants to do an upload of the glibc soon to fix various things. What about the following combination: 1. Upload glibc without the shlib bump, but with the switch to SPARC V9 optimizations + check in the preinst script. That means binaries built against it can still run on sparc v8 hardware, right? There is no ABI change, so yes they can still run on SPARC v8 hardware, as long as the glibc is not upgraded to the SPARC v9 optimized version (but that should never happen given we refuse such upgrades in the preinst script). -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GCC 4.2 transition
The plans for the GCC 4.2 transition were described in http://lists.debian.org/debian-devel-announce/2007/06/msg8.html Does any port still need to stick with GCC 4.1 for a while? Feedback from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show objections against the transition. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Fri, 2007-07-20 at 10:16 +0200, Matthias Klose wrote: Does any port still need to stick with GCC 4.1 for a while? Feedback from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show objections against the transition. I have objections :) http://bugs.debian.org/433629 Yes, it's pretty odd, but recompiling the whole kernel tree with gcc 4.2 causes my usbhid to totally not work. johannes signature.asc Description: This is a digitally signed message part
Re: GCC 4.2 transition
On Fri, Jul 20, 2007 at 11:33:01AM +0200, Johannes Berg [EMAIL PROTECTED] wrote: On Fri, 2007-07-20 at 10:16 +0200, Matthias Klose wrote: Does any port still need to stick with GCC 4.1 for a while? Feedback from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show objections against the transition. I have objections :) http://bugs.debian.org/433629 Yes, it's pretty odd, but recompiling the whole kernel tree with gcc 4.2 causes my usbhid to totally not work. I have another objection. I'd like all mozilla security updates to be built before gcc 4.2 becomes the default, because they don't build correctly yet, and I am (still) waiting for an upstream comment on how to fix it. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Fri, Jul 20, 2007 at 11:51:47AM +0200, Mike Hommey wrote:
On Fri, Jul 20, 2007 at 11:33:01AM +0200, Johannes Berg [EMAIL PROTECTED]
wrote:
On Fri, 2007-07-20 at 10:16 +0200, Matthias Klose wrote:
Does any port still need to stick with GCC 4.1 for a while? Feedback
from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show
objections against the transition.
I have objections :)
http://bugs.debian.org/433629
Yes, it's pretty odd, but recompiling the whole kernel tree with gcc 4.2
causes my usbhid to totally not work.
I have another objection. I'd like all mozilla security updates to be built
before gcc 4.2 becomes the default, because they don't build correctly yet,
and I am (still) waiting for an upstream comment on how to fix it.
On a more general note, I'd like to see xulrunner/nss built and
depending packages[0] built so we can get the fixes into testing easier
before this is started.
Cheers,
Neil
[0] Most of: http://security-tracker.debian.net/tracker/status/dtsa-candidates
--
int getRandomNumber() {
return 4; // chosen by fair dice roll. guaranteed to be random.
}
// http://xkcd.com/c221.html
signature.asc
Description: Digital signature
Re: GCC 4.2 transition
On Fri, Jul 20, 2007 at 10:16:27AM +0200, Matthias Klose wrote: The plans for the GCC 4.2 transition were described in http://lists.debian.org/debian-devel-announce/2007/06/msg8.html Does any port still need to stick with GCC 4.1 for a while? Feedback from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show objections against the transition. According to Bastian Blank, gcc 4.2 currently produces broken sparc kernel images. Another thing which comes to mind: we have recently announced that sparc32 machines are not going to be supported in lenny. Transition to the new gcc version seems like a perfect time to turn on the ultrasparc specific optimizations in gcc by default. Do you think it is feasible? I currently have no idea what breakage such a change might cause. Best regards, -- Jurij Smakov [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
Jurij Smakov a écrit : On Fri, Jul 20, 2007 at 10:16:27AM +0200, Matthias Klose wrote: The plans for the GCC 4.2 transition were described in http://lists.debian.org/debian-devel-announce/2007/06/msg8.html Does any port still need to stick with GCC 4.1 for a while? Feedback from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show objections against the transition. According to Bastian Blank, gcc 4.2 currently produces broken sparc kernel images. Another thing which comes to mind: we have recently announced that sparc32 machines are not going to be supported in lenny. Transition to the new gcc version seems like a perfect time to turn on the ultrasparc specific optimizations in gcc by default. Do you think it is feasible? I currently have no idea what breakage such a change might cause. We (glibc maintainers) plan to do a change in glibc first. We will drop libc6-sparcv9 and change the optimizations of libc6 to SPARC v9 from SPARC v8. Doing it on the glibc first have the advantage that we can put a check in the preinst script to stop the installation on a SPARC v8 system. As libc6 is installed on all systems, that should prevent system breakages with SIGILL on random packages. This is already implemented in the SVN, and we plan to do the upload on Sunday. Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
* Aurelien Jarno ([EMAIL PROTECTED]) [070720 21:15]: Jurij Smakov a écrit : On Fri, Jul 20, 2007 at 10:16:27AM +0200, Matthias Klose wrote: The plans for the GCC 4.2 transition were described in http://lists.debian.org/debian-devel-announce/2007/06/msg8.html Does any port still need to stick with GCC 4.1 for a while? Feedback from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show objections against the transition. According to Bastian Blank, gcc 4.2 currently produces broken sparc kernel images. Another thing which comes to mind: we have recently announced that sparc32 machines are not going to be supported in lenny. Transition to the new gcc version seems like a perfect time to turn on the ultrasparc specific optimizations in gcc by default. Do you think it is feasible? I currently have no idea what breakage such a change might cause. We (glibc maintainers) plan to do a change in glibc first. We will drop libc6-sparcv9 and change the optimizations of libc6 to SPARC v9 from SPARC v8. Doing it on the glibc first have the advantage that we can put a check in the preinst script to stop the installation on a SPARC v8 system. As libc6 is installed on all systems, that should prevent system breakages with SIGILL on random packages. This is already implemented in the SVN, and we plan to do the upload on Sunday. I hope this doesn't yet include another shlib bump (though it would be good if the sparc v9 binaries have one). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Fri, Jul 20, 2007 at 10:48:32PM +0200, Andreas Barth wrote: * Aurelien Jarno ([EMAIL PROTECTED]) [070720 21:15]: Jurij Smakov a écrit : On Fri, Jul 20, 2007 at 10:16:27AM +0200, Matthias Klose wrote: The plans for the GCC 4.2 transition were described in http://lists.debian.org/debian-devel-announce/2007/06/msg8.html Does any port still need to stick with GCC 4.1 for a while? Feedback from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show objections against the transition. According to Bastian Blank, gcc 4.2 currently produces broken sparc kernel images. Another thing which comes to mind: we have recently announced that sparc32 machines are not going to be supported in lenny. Transition to the new gcc version seems like a perfect time to turn on the ultrasparc specific optimizations in gcc by default. Do you think it is feasible? I currently have no idea what breakage such a change might cause. We (glibc maintainers) plan to do a change in glibc first. We will drop libc6-sparcv9 and change the optimizations of libc6 to SPARC v9 from SPARC v8. Doing it on the glibc first have the advantage that we can put a check in the preinst script to stop the installation on a SPARC v8 system. As libc6 is installed on all systems, that should prevent system breakages with SIGILL on random packages. This is already implemented in the SVN, and we plan to do the upload on Sunday. I hope this doesn't yet include another shlib bump (though it would be good if the sparc v9 binaries have one). Given the current situation wrt the transitions, we won't bump the shlib, though strictly speaking that should be necessary. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
