Re: architecture qualification season

[Aurelien Jarno <aurelien@aurel32.net>]

On 2020-05-15 08:23, YunQiang Su wrote:
> Matthias Klose <doko@debian.org> 于2020年5月14日周四 下午11:45写道：
> >
> > 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.
> 
> bintuils64 is in our repo now.
> 
> >
> > 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.
> 
> For gcc, there are 2 patch for ffi. It is strange that gcc upstream
> hasn't sync libffi for long.

I have sent a patch sometimes ago to sync the mips part from upstream
libffi [1]. It has been rejected as the solution is to sync the full
libffi from upstream. However there have been many commits from other
architectures that have been accepted contrary to the mips one, and both
trees have now diverged, with some patches applied on the GCC side but
not propagated to the libffi side. In short it's a huge work touching
many architectures.

Aurelien

[1] https://gcc.gnu.org/legacy-ml/gcc-patches/2019-08/msg00304.html

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net