Re: Intention to drop sparc32 support for Lenny
On Tue, May 22, 2007 at 04:38:04PM +0200, Frans Pop wrote: Do you really think this is a decision that was made lightly? The problem is, and that has been mentioned before, that *there is no upstream maintainer* for sparc32. Unless some people step up and ensure that upstream issues _are_ fixed in a timely manner, sparc32 is effectively dead. OK, not being a SPARC expert myself, I'd still like to see a list of issues or bugs which are worth dropping a whole sub-architecture. Maybe some of them don't even require a SPARC guru to fix them? Maybe some are easy enough so someone could fix them after reading some documentation? In that case I'm willing to have a look at them. This starts to sound like m68k part 2. No, it is completely different as m68k _does_ have a group of enthusiastic people behind it who actually work on upstream issues. sparc32 has none. Well, I just saw three or more sparc32 patches being committed to Linus' git tree today or yesterday, so that may not be quite correct. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
Re: Intention to drop sparc32 support for Lenny
Uwe Hermann wrote: Well, I just saw three or more sparc32 patches being committed to Linus' git tree today or yesterday, so that may not be quite correct. You are missing the point. Those patches were created by enthusiastic users fixing the problems that they have experienced. Until someone volunteers to become the official maintainer Sparc32 is effectively dead. An official maintainer is essential as the point of contact and the person who contantly tests to ensure that changes elsewhere in the kernel have not caused regressions. Without an official maintainer who is going to be responsible for saying that the port is or is not ready for the next kernel release ?. The Sun4d subset of Sparc32 is an example of cumulative bitrot over many years which will take a major effort to resolve. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intention to drop sparc32 support for Lenny
On Mon, Jul 23, 2007 at 02:39:10PM +0200, Uwe Hermann wrote: OK, not being a SPARC expert myself, I'd still like to see a list of issues or bugs which are worth dropping a whole sub-architecture. Maybe some of them don't even require a SPARC guru to fix them? Maybe some are easy enough so someone could fix them after reading some documentation? In that case I'm willing to have a look at them. You can start by setting up your own private infrastructure for a new sparc32 architecture, pointing a couple of buildds at it, and note what breaks. You will need to patch gcc and glibc for your new architecture, as you will need to build for sparcv7 or sparcv8, and we are switching to build for sparcv8plus, as we are targetting ultrasparcs only. Once you have your unofficial port established, it shouldn't be difficult to get sparc32 support into the official packages. Then you can do whatever needs to be done with the kernel. It would be nice to have things working on all sun4c, d, and m machines. Hope this helps. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intention to drop sparc32 support for Lenny
Uwe Hermann [EMAIL PROTECTED] writes: On Tue, May 22, 2007 at 04:38:04PM +0200, Frans Pop wrote: Do you really think this is a decision that was made lightly? The problem is, and that has been mentioned before, that *there is no upstream maintainer* for sparc32. Unless some people step up and ensure that upstream issues _are_ fixed in a timely manner, sparc32 is effectively dead. OK, not being a SPARC expert myself, I'd still like to see a list of issues or bugs which are worth dropping a whole sub-architecture. Maybe some of them don't even require a SPARC guru to fix them? Maybe some are easy enough so someone could fix them after reading some documentation? In that case I'm willing to have a look at them. Regardless of the set of bugs or the difficulty of fixing them, every architecture itself needs Debian porters and upstream support to meet Debian release policy. URL:http://release.debian.org/etch_arch_policy.html I'm not saying that sparc32 can't meet policy; I'm merely saying that such a judgement is unaffected by discussions about the tractability of the existing bugs. Well, I just saw three or more sparc32 patches being committed to Linus' git tree today or yesterday, so that may not be quite correct. The kernel is but one program in Debian. -- \Pinky, are you pondering what I'm pondering? Umm, I think | `\ so, Brain, but three men in a tub? Ooh, that's unsanitary! -- | _o__)_Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intention to drop sparc32 support for Lenny
Slightly like watching a group of boys poking a nearly dead dog. On 23/07/07, Ben Finney [EMAIL PROTECTED] wrote: Uwe Hermann [EMAIL PROTECTED] writes: On Tue, May 22, 2007 at 04:38:04PM +0200, Frans Pop wrote: Do you really think this is a decision that was made lightly? The problem is, and that has been mentioned before, that *there is no upstream maintainer* for sparc32. Unless some people step up and ensure that upstream issues _are_ fixed in a timely manner, sparc32 is effectively dead. OK, not being a SPARC expert myself, I'd still like to see a list of issues or bugs which are worth dropping a whole sub-architecture. Maybe some of them don't even require a SPARC guru to fix them? Maybe some are easy enough so someone could fix them after reading some documentation? In that case I'm willing to have a look at them. Regardless of the set of bugs or the difficulty of fixing them, every architecture itself needs Debian porters and upstream support to meet Debian release policy. URL:http://release.debian.org/etch_arch_policy.html I'm not saying that sparc32 can't meet policy; I'm merely saying that such a judgement is unaffected by discussions about the tractability of the existing bugs. Well, I just saw three or more sparc32 patches being committed to Linus' git tree today or yesterday, so that may not be quite correct. The kernel is but one program in Debian. -- \Pinky, are you pondering what I'm pondering? Umm, I think | `\ so, Brain, but three men in a tub? Ooh, that's unsanitary! -- | _o__)_Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intention to drop sparc32 support for Lenny
Hi, Frans Pop [EMAIL PROTECTED] writes: The problem is, and that has been mentioned before, that *there is no upstream maintainer* for sparc32. Unless some people step up and ensure that upstream issues _are_ fixed in a timely manner, sparc32 is effectively dead. Upstream should really read kernel, right? Kernel development moves too fast for that. Or does it wander too fast? ;-) Thanks, Ludovic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intention to drop sparc32 support for Lenny
Hi, [EMAIL PROTECTED] (Jordan Bettis) writes: Just a thought but if the SPARC32 system got dropped, would it be possible to roll it back to the last known good configuration and then archive that? I think there'd be value in having a working archived distro of the latest software (before abandonment) for people. Agreed. (Maybe Etch _is_ this last known-good configuration?) Thanks, Ludovic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intention to drop sparc32 support for Lenny
The sparc32 port has been struggling for some time. Last month Jurij Smakov, currently the most active Debian Sparc porter, raised the question if support sparc32 should be dropped for Lenny [1]. The main reason is the fact that sparc32 support is no longer being maintained upstream for the kernel [2]. A result of that is that the 2.6.21 kernel is currently broken, which forces the issue. It seems obvious that someone will *eventually* fix sparc32 support in the kernel upstream. Why the rush to kill off the port, without waiting a relatively sane period of time for upstream issues to be fixed? This starts to sound like m68k part 2. I'd suggest waiting, say, 3 months. p.s. Yes I have a sparc32 box and yes it runs debian. --elijah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intention to drop sparc32 support for Lenny
On Tuesday 22 May 2007 16:03, [EMAIL PROTECTED] wrote: The main reason is the fact that sparc32 support is no longer being maintained upstream for the kernel [2]. A result of that is that the 2.6.21 kernel is currently broken, which forces the issue. It seems obvious that someone will *eventually* fix sparc32 support in the kernel upstream. Eventually is not good enough. Why the rush to kill off the port, without waiting a relatively sane period of time for upstream issues to be fixed? Do you really think this is a decision that was made lightly? The problem is, and that has been mentioned before, that *there is no upstream maintainer* for sparc32. Unless some people step up and ensure that upstream issues _are_ fixed in a timely manner, sparc32 is effectively dead. Waiting 3 months (what you apparently consider a sane period) for a fix for major upstream breakage is _not_ acceptable for a release arch. Debian cannot afford to have a broken kernel for a release subarch for that period of time. Kernel development moves too fast for that. If the current issue is fixed in three months, there will probably be 5 new issues that will not be fixed and we'll still not have a working kernel. This starts to sound like m68k part 2. No, it is completely different as m68k _does_ have a group of enthusiastic people behind it who actually work on upstream issues. sparc32 has none. Cheers, FJP pgpc4SbMVAWEy.pgp Description: PGP signature
Re: Intention to drop sparc32 support for Lenny
Frans, Thanks for that pointer. After trawling through some of the mailing lists and searching for bug reports I found Robert Reif's reply indicating this is related to drm and the fact that sparc does not support cmpxcgh at the moment. Still not sure how to exactly reproduce this, but I'll try to kick off a build with drm in it and see what happens. It's a shame, Debian is normally so good at bug management, and now I'm searching for one I cannot find it... If anyone has any more info on this I'd welcome it. Thanks, Martin On Mon, May 21, 2007 at 10:09:49PM +0200, Frans Pop wrote: On Monday 21 May 2007 21:49, Martin Habets wrote: FYI, 2.6.21 is rock solid on my SS20 here. Do you consider it broken just because of some cdrom issues? Or is there more? I don't have more details than this: http://lists.debian.org/debian-kernel/2007/05/msg00305.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Intention to drop sparc32 support for Lenny
The sparc32 port has been struggling for some time. Last month Jurij Smakov, currently the most active Debian Sparc porter, raised the question if support sparc32 should be dropped for Lenny [1]. The main reason is the fact that sparc32 support is no longer being maintained upstream for the kernel [2]. A result of that is that the 2.6.21 kernel is currently broken, which forces the issue. Another reason is that dropping sparc32 support will allow optimization for sparc64 which will result in improved support for the modern sparc systems from Sun and Hitachi. Other distributions have already made this choice. Unless a group of people is willing to commit to providing the needed upstream kernel and toolchain support for sparc32, the Debian project will be forced to drop sparc32 for Lenny. Doing this early in the release cycle has the advantage of allowing sufficient time to work on optimizing support for sparc64. Given the current problems with sparc32 in the 2.6.21 kernel, the final decision on this will be made before the end of this month. Frans Pop [1] http://lists.debian.org/debian-sparc/2007/04/msg00044.html [2] http://marc.info/?l=linux-sparcm=117407830512186w=2 pgpRz8jwQQLvd.pgp Description: PGP signature
Re: Intention to drop sparc32 support for Lenny
On Mon, May 21, 2007 at 12:00:24PM +0200, Frans Pop wrote: The sparc32 port has been struggling for some time. Last month Jurij Smakov, currently the most active Debian Sparc porter, raised the question if support sparc32 should be dropped for Lenny [1]. Fine, as long as you provide 32-bit as well as 64-bit userland. Otherwise many programs will pay a substantial performance penalty, as pointer-heavy programs double their memory and I/O requirements (and Sparc doesn't get any compensating benefit the way x86-64 does from extra registers in 64-bit mode). The GNU toolchain has extensive support for multilibs, and other Linux distros can have 32-bit as well as 64-bit packages installed, but Debian has traditionally forced people to use chroot to run 32-bit programs on a 64-bit OS. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intention to drop sparc32 support for Lenny
On Mon, May 21, 2007 at 09:58:00AM -0700, Joe Buck wrote: Fine, as long as you provide 32-bit as well as 64-bit userland. Otherwise The plan is to continue the existing port, dropping support for 64 bit kernels and allowing use of SPARC v9 instructions rather than to do a new port with 64 bit userspace. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: Intention to drop sparc32 support for Lenny
On Mon, May 21, 2007 at 12:00:24PM +0200, Frans Pop wrote: The sparc32 port has been struggling for some time. Last month Jurij Smakov, currently the most active Debian Sparc porter, raised the question if support sparc32 should be dropped for Lenny [1]. The main reason is the fact that sparc32 support is no longer being maintained upstream for the kernel [2]. A result of that is that the 2.6.21 kernel is currently broken, which forces the issue. Just a thought but if the SPARC32 system got dropped, would it be possible to roll it back to the last known good configuration and then archive that? I think there'd be value in having a working archived distro of the latest software (before abandonment) for people. -- Jordan Bettis -- Chicago Il. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intention to drop sparc32 support for Lenny
On Mon, May 21, 2007 at 09:58:00AM -0700, Joe Buck wrote: On Mon, May 21, 2007 at 12:00:24PM +0200, Frans Pop wrote: The sparc32 port has been struggling for some time. Last month Jurij Smakov, currently the most active Debian Sparc porter, raised the question if support sparc32 should be dropped for Lenny [1]. Fine, as long as you provide 32-bit as well as 64-bit userland. Otherwise many programs will pay a substantial performance penalty, as pointer-heavy programs double their memory and I/O requirements (and Sparc doesn't get any compensating benefit the way x86-64 does from extra registers in 64-bit mode). I think it's going to stay 32 bit userland, just a 64 bit kernel, and maybe some selected 64 bit libraries and programs. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intention to drop sparc32 support for Lenny
On Mon, May 21, 2007 at 07:44:44PM +0100, Mark Brown wrote: The plan is to continue the existing port, dropping support for 64 bit kernels and allowing use of SPARC v9 instructions rather than to do a I, of course, mean *32* bit kernels there. Sorry. *sigh* -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: Intention to drop sparc32 support for Lenny
On Monday 21 May 2007 21:49, Martin Habets wrote: FYI, 2.6.21 is rock solid on my SS20 here. Do you consider it broken just because of some cdrom issues? Or is there more? I don't have more details than this: http://lists.debian.org/debian-kernel/2007/05/msg00305.html pgpP7XiSvJTe8.pgp Description: PGP signature
Re: Intention to drop sparc32 support for Lenny
On Mon, May 21, 2007 at 12:00:24PM +0200, Frans Pop wrote: The sparc32 port has been struggling for some time. Last month Jurij Smakov, currently the most active Debian Sparc porter, raised the question if support sparc32 should be dropped for Lenny [1]. I agree with this intent, as I wrote at the time. The main reason is the fact that sparc32 support is no longer being maintained upstream for the kernel [2]. A result of that is that the 2.6.21 kernel is currently broken, which forces the issue. FYI, 2.6.21 is rock solid on my SS20 here. Do you consider it broken just because of some cdrom issues? Or is there more? Even though David does not actively support sparc32, he does push our patches upstream and creates patches himself (and I for one am very thankfull for that). Another reason is that dropping sparc32 support will allow optimization for sparc64 which will result in improved support for the modern sparc systems from Sun and Hitachi. Other distributions have already made this choice. Unless a group of people is willing to commit to providing the needed upstream kernel and toolchain support for sparc32, the Debian project will be forced to drop sparc32 for Lenny. Doing this early in the release cycle has the advantage of allowing sufficient time to work on optimizing support for sparc64. Given the current problems with sparc32 in the 2.6.21 kernel, the final decision on this will be made before the end of this month. Please include your specific problem(s) here. Cheers, Martin Habets -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
