|
 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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
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-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: Sparc release requalification
On Thu, Aug 20, 2009 at 07:09:44AM +0200, Mike Hommey wrote:
> On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote:
> > 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.
No, we don't need to do that. Thats what is multiarch for.
Bastian
--
Captain's Log, star date 21:34.5...
--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: Sparc release requalification
On Thu, Aug 20, 2009 at 10:45:46AM +0200, Bastian Blank wrote:
> On Thu, Aug 20, 2009 at 07:09:44AM +0200, Mike Hommey wrote:
> > On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote:
> > > 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.
> No, we don't need to do that. Thats what is multiarch for.
It's not intended that multiarch supports switching architectures. Of course
it would help to import some 64bit packages selectively from a sparc64 port
but most of your binaries would still be 32bit with the only partially supported
code generation? Even on a rebuild you would have to pull in the 64bit
libs in a way you build against them by default? (Or would that boil down
to passing another DEB_*_ARCH so that config.guess targets 64bit and stuffing
that into simple packages with arch:sparc?)
Kind regards,
Philipp Kern
--
.''`. Philipp Kern Debian Developer
: :' : http://philkern.de Stable Release Manager
`. `' xmpp: phil@... Wanna-Build Admin
`- finger pkern/key@...
|
|
Re: Sparc release requalification
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
--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: Sparc release requalification
On Thu, Aug 20, 2009 at 10:53:08AM +0200, Philipp Kern wrote:
> It's not intended that multiarch supports switching architectures.
It's also just an upgrade. Or did I miss something that would make it
impossible to replace perl/i386 with perl/amd64?
Bastian
--
Many Myths are based on truth
-- Spock, "The Way to Eden", stardate 5832.3
--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: Sparc release requalification
Bastian Blank a écrit :
> 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.
>
If we are not sure that sparc and s390 (ie 32-bit versions) would be
suitable for squeeze, this is almost sure they won't be suitable for
squeeze+1.
Isn't it the right moment to start a sparc64 and an s390x port, and if
they are ready for squeeze release with them? Almost whatever upgrade
solution you offer will require to have at least one release with both
old and new architecture (like we did for arm -> armel).
Given that we already have sparc and s390 in the archive and that we
also already have 64-bit ports, I don't expect any major problem for
those new ports. Also given quite fast hardware exists for those
architectures, it can probably be done relatively quickly.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@... http://www.aurel32.net--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: Sparc release requalification
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
to happen.
Thanks.
--
Jurij Smakov jurij@...
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: Sparc release requalification
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/--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: Sparc release requalification
On 20.08.2009 16:52, Aurelien Jarno wrote:
> Bastian Blank a écrit :
>> 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.
>>
>
> If we are not sure that sparc and s390 (ie 32-bit versions) would be
> suitable for squeeze, this is almost sure they won't be suitable for
> squeeze+1.
>
> Isn't it the right moment to start a sparc64 and an s390x port, and if
> they are ready for squeeze release with them? Almost whatever upgrade
> solution you offer will require to have at least one release with both
> old and new architecture (like we did for arm -> armel).
>
> Given that we already have sparc and s390 in the archive and that we
> also already have 64-bit ports, I don't expect any major problem for
> those new ports. Also given quite fast hardware exists for those
> architectures, it can probably be done relatively quickly.
this seems to be the way to go, but port maintainers seem to lack enthusiasm or
resources. I'm willing to help, if somebody commits to these ports.
--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: Sparc release requalification
Matthias Klose a écrit :
> On 20.08.2009 16:52, Aurelien Jarno wrote:
>> Bastian Blank a écrit :
>>> 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.
>>>
>> If we are not sure that sparc and s390 (ie 32-bit versions) would be
>> suitable for squeeze, this is almost sure they won't be suitable for
>> squeeze+1.
>>
>> Isn't it the right moment to start a sparc64 and an s390x port, and if
>> they are ready for squeeze release with them? Almost whatever upgrade
>> solution you offer will require to have at least one release with both
>> old and new architecture (like we did for arm -> armel).
>>
>> Given that we already have sparc and s390 in the archive and that we
>> also already have 64-bit ports, I don't expect any major problem for
>> those new ports. Also given quite fast hardware exists for those
>> architectures, it can probably be done relatively quickly.
>
> this seems to be the way to go, but port maintainers seem to lack enthusiasm or
> resources. I'm willing to help, if somebody commits to these ports.
>
I'm willing to help too if such a project is started. Any other volunteer?
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@... http://www.aurel32.net--
To UNSUBSCRIBE, email to debian-s390-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
signature.asc (204 bytes) 