Hello Adrian, Meanwhile, we have been testing the current sparc64 port on several development machines, both sun4v and sun4u, and the results are really quite promising: the major packages which we're using are all there, they are functional and up-to-date, and on identical hardware, performance is roughly the same or better compared to wheezy.
> In order for sparc64 to become a release architecture, the buildds and > porter boxes must be maintained by DSA. Currently, all sparc64 > hardware used within Debian is maintained by ports people. > Unfortunately, the hardware acquisition process at Oracle takes quite > long which is why we are still stuck in Debian Ports. Sorry. What's holding us back in migrating some production machines away from wheezy (and replacing some older sun4u hardware with newer sun4u or sun4v machines) is not so much that sparc64 is a ports architecture rather than a release architecture, but that sparc64 as a ports architecture is limited to the Unstable suite, which is too much of a moving target. The DSA team is demanding the availability of redundant hardware under a support contract in order to be able to support sparc64 as a release architecture with a certain quality of service. That is entirely understandable. Unfortunately, that demand for hardware under a support contract is also currently preventing us from testing the sparc64 port against the Testing suite in a more production-like setting, hence preventing us from providing early feedback on the port, even though the Testing suite could probably be built quite easily in its current shape, there was no shortage of hardware offers (without a support contract) to provide the necessary build capacity, and the level of service proposed by the DSA team is not currently requested for the sparc64 port. In fact, there would be nothing wrong with sparc64 being (and staying) a ports architecture, if it were possible for ports architectures to support any suite, instead of just Unstable. Is the build infrastructure and configuration for ports architectures entirely separate from that for release architectures? If hardware was promised by Oracle in such a way that the DSA team is confident their requirements will be met in the near future, would it be possible to make sparc64 a release architecture now, and start building the Testing suite on the existing infrastructure? If not, what are the issues preventing the Testing and Stable suites from being built for ports architectures, and what is needed to resolve those issues? Thanks, Tom
