Re: architecture qualification season
On 5/7/20 9:41 PM, Paul Gevers wrote:
> Hi
>
> On 02-05-2020 21:53, Paul Gevers wrote:
>> I don't think anybody likes to do it, but we have to discuss the
>> architectures that will be part of bullseye. In the before last IRC
>> meeting I promised I would send this mail, so here we go. Let's see what
>> items we consider a must. Anybody else that wants to step in, feel free
>> to take any action.
>>
>> 1) I haven't heard of new architectures that want to be on board for
>> bullseye.
>>
>> 2) I think we have to ask several parties if they are OK with supporting
>> the existing architectures: porters, DSA and security. I recall [1] DSA
>> had issues with armel, but I believe that has been resolved by building
>> on some other arm boxes, right? Do we already know of other issues?
>
> I found this mail from Niels from the buster release cycle [2]. Going
> through it, it looks like it could be reused nearly completely.
>
>> 3) In the current state, I think it boils down to the question if armel
>> and mipsel should be dropped for bullseye or not. What do we think
>> ourselves? Myself, I've been regularly cursing mipsel for it being so
>> much slower to build packages than most architectures, but I don't think
>> that's enough ;). Also, the limited address space of 32 bit
>> architectures is lowest on mipsel and it is starting to count. I've seen
>> several issues due to it (e.g. rustc), meaning that maintainers of some
>> large packages need to spend serious effort to build their package on
>> mipsel. I feel that several maintainers seriously doubt that effort is
>> well spent.
>
> The 32 bit issue was discussed for buster quite extensively.
There are now also attempts to package binutils64 and gcc-N-64 to build a 64bit
toolchain on at least mipsel and i386. As a maintainer I'm not keen to add
these builds to the binutils and gcc-N packages.
In additions to the concerns in [2], there are also a bunch of mips* patches
which are not yet integrated upstream in binutils and GCC.
mipsel buildds also seem to be the slowest buildds among the buildds for release
architectures.
Matthias
>> [1] https://release.debian.org/bullseye/arch_qualify.html
>
> Paul
>
> [2] https://lists.debian.org/debian-release/2018/06/msg00644.html
>
Reply to: