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 - [email protected] `. `' Freie Universitaet Berlin - [email protected] `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
