On 06.09.2009 16:49, Jurij Smakov wrote:
On Thu, Aug 20, 2009 at 12:20:01PM +0200, Matthias Klose wrote:
On 19.08.2009 16:33, 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.No, "just" a subset that an update from 32->64bit userland does work. Again, I don't know how big this subset will be.Matthias, can you please make a definite statement on whether you, as a toolchain maintainer, are willing to support the existing 32-bit userland with a 64-bit kernel, or you consider a transition to 64-bit userland a necessary condition for sparc to be released with squeeze. This will be an important factor for the release team to determine what is going
the port is currently using 4.3 as the default, I do plan to make 4.4 the default unless port maintainers object [1]. Ubuntu karmic already uses 4.4 as the default, but as a community port sparc doesn't get the same attention as other ports. Please see [2] for current problems with sparc. I do not plan to invest significant time in fixing build issues on sparc for squeeze.
I do commit to prepare binutils and gcc-4.4 for a sparc64 port if this should happen for squeeze.
Matthias [1] http://lists.debian.org/debian-release/2009/09/msg00239.html [2] http://qa.ubuntuwire.org/ftbfs/