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
opinion.
Adrian
--
.''`. 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: