[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: architecture qualification season



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.

For binutils: there are mips64-default-n64.diff and gold-mips.diff.
I will try to feedback them.

>
> mipsel buildds also seem to be the slowest buildds among the buildds for release
> architectures.
>

I get some new machines, and we will replace some old ones wit them.
They are much faster than the current ones.

> Matthias
>
> >> [1] https://release.debian.org/bullseye/arch_qualify.html
> >
> > Paul
> >
> > [2] https://lists.debian.org/debian-release/2018/06/msg00644.html
> >
>


-- 
YunQiang Su


Reply to: