Matthias Klose <d...@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