[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Stretch bootstrap for sparc64 and sparc, optimized for ultrasparc3

On 09/07/2017 07:05 PM, Tom Turelinckx wrote:
Because I want to move forward with upgrading some of those machines to a newer release,
and replacing some of the Sun Fire-series hardware with SPARC Enterprise-series hardware,
I'm working on bootstrapping Stretch for both sparc64 and sparc, preferably
--with-cpu(-32/-64)=ultrasparc3 instead of ultrasparc.

We are actually planning on implementing Britney for Debian Ports which means that
Debian Ports would also get a testing release. I'm not sure what the current status
is though.

Bootstrapping Stretch for sparc is less straightforward, as the latest/last packages
available from snapshot are from two years ago. Still, there is a large amount of
packages available that is not terribly old. Thanks to excellent work by Helmut Grohne
and others [2], it's also possible to cross-compile a recent version of the most
important packages from source.

But why 32-bit sparc? All the current development happens in sparc64. There isn't
really a point in bootstrapping for sparc these days unless you set the default
CPU to sparv8 to be able to run Debian on a sun4m machine. sun4u or newer machines
should use sparc64.

It took only minimal patches to get rebootstrap to work against Stretch 9.0. It
finishes successfully, and I have repositories available for both sparc and sparc64.
Unfortunately, build-essential is not (yet) fully complete: rebootstrap does not (yet)
produce a native gcc. At jenkins.debian.net, builds considered successful finish in
the same state, so I guess producing all the build dependencies to produce a native
gcc is (currently) out of the scope of rebootstrap.

You can just easily cross-compile a native gcc compiler with sbuild. That's actually
very easy using the cross-build toolchain available in Debian.

Having Stretch repositories with a significant number of packages available for both
sparc64 and sparc would open up a lot of opportunities for testing and actually using
the port, and having them optimized for ultrasparc3 would allow useful performance
testing on a broad range of currently relevant hardware. If I succeed in building the
repositories, I hope to make them public.

I think it makes more sense to help to make Britney and hence testing available in
Debian Ports. Your efforts sound like you're trying to reinvent the wheel in my


 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply to: