Re: Sparc release requalification
On 18.08.2009 22:43, Jurij Smakov wrote: Hello, I would like to point out that sparc release requalification is currently placing it in at risk position for squeeze release. The most serious problems with the port are lack of developer involvement (there is currently one active porter/developer known to the release team, Bernd Zeimetz) and the fact that current mixed 64-bit kernel with 32-bit userspace setup is not supported upstream (CC'ing doko for comment). The current configuration for a biarch toolchain defaulting to 32-bit isn't that well supported. The 32-bit compiler defaults to v8 hardware which isn't available anymore. The biarch setup tightly couples v9 and newer processor support to 64-bit, so switching to a 64-bit userland would offer better use of current hardware besides targeting a comparable setup as other distributions. Newer projects like llvm don't target 32-bit sparc anymore, while they do for 64-bit. I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. For both variants the toolchain is almost in place. glibc and binutils don't need modifications, gcc needs some libraries be built as biarch on sparc. zlib is already built as biarch on sparc. gmp and mpfr are already built as biarch on other archs, ppl and cloog would be good to have, but we could start without the graphite optimizations as well. I can prepare the changes for gcc, but will not help with any other transition work. [CCing debian-s390, because there are plans for a switch to s390x as well] Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? Bastian -- He's dead, Jim. -- McCoy, The Devil in the Dark, stardate 3196.1 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. Bastian -- Star Trek Lives! -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. ... which will be needed anyways. So your choice is actually between doing it and doing it plus some extra intermediate work. Mike -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
