On 7/8/20 9:21 PM, Paul Gevers wrote: > Hi, > > [Note, this e-mail may look familiar as it is mostly copied over from > the buster call, not much has changed, AFAICT]. > > As part of the interim architecture qualification for bullseye, we > request that DSA, the security team, Wanna build, and the toolchain > maintainers review and update their list of known concerns for bullseye > release architectures. > > Summary of the current concerns and issues: > * DSA have announced a blocking issue for armel and armhf (see below) > * Concerns from DSA about ppc64el and s390x have been carried over from > (stretch and) buster. > * Concerns from the GCC maintainers about i386, armel, armhf, mips64el > and mipsel have been carried over from (stretch and) buster. > > If the issues and concerns from you or your team are not up to date, > then please follow up to this email (keeping debian-release@l.d.o in CC > to ensure we are notified). > > Whilst porters remain ultimately responsible for ensuring the > architectures are ready for release, we do expect that you / your team > are willing to assist with clarifications of the concerns and to apply > patches/changes in a timely manner to resolve the concerns. > > > List of blocking issues by architecture > ======================================= > > The following is a summary from the current architecture qualification > table. > > armel/armhf: > ------------ > > * Undesirable to keep the hardware running beyond 2020. armhf VM > support uncertain. (DSA) > - Source: [DSA Sprint report] > - I was under the impression that this issue has been resolved (at > least for armhf) by now, but we like a fresh statement on this. > > > [DSA Sprint report]: > https://lists.debian.org/debian-project/2018/02/msg00004.html > > > List of concerns for architectures > ================================== > > The following is a summary from the current architecture qualification > table. > > * Concern for ppc64el and s390x: we are dependent on sponsors for > hardware. > (Raised by DSA; carried over from stretch and buster) > > * Concern for armel and armhf: only secondary upstream support in GCC > (Raised by the GCC maintainer; carried over from stretch and buster)
this was wrong, and still is wrong. See https://gcc.gnu.org/gcc-10/criteria.html. arm-linux-gnueabi is listed as a primary platform. The arm-linux-gnueabihf triplet never gained much traction outside of Debian/Ubuntu, so should be included. armel might be special because the use of the libatomics library is mandatory. > * Concern for mips, mips64el, mipsel and ppc64el: no upstream support > in GCC; Debian carries patches in binutils and GCC that haven't been > integrated upstream even after a long time. > (Raised by the GCC maintainer; carried over from stretch and buster) this is wrong for ppc64el (at least I didn't raise that). powerpc64-unknown-linux-gnu is listed as a primary platform. https://gcc.gnu.org/gcc-8/criteria.html explicitly lists the little endian variant, and after checking with upstream it looks like an omission to document that for GCC 9 and GCC 10 as well. A concern that appears to get ignored by the release team is that both mipsel and mips64el are neither a primary or a secondary release architecture. You seem to mention it in the summary, but don't have it in the list of concerns. GCC upstream only lists the bare metal mips*elf target, plus I don't see any other test results getting posted to the gcc-testresults ML besides for the Debian builds. Please also note the 100+ test failures for mips* in binutils, which are not addressed for years. See https://sourceware.org/pipermail/binutils/2020-July/112201.html mipsel now adds another work around to build 64bit compilers to be able to build larger projects (see e.g. binutils64). > Architecture status > =================== > > These are the architectures currently being built for bullseye: > > * Intel/AMD-based: amd64, i386 > * ARM-based: arm64, armel, armhf > * MIPS-based: mipsel, mips64el > * Other: ppc64el, s390x > > If the blocking issues cannot be resolved, affected architectures are at > risk of removal from testing before bullseye is frozen. > > We are currently unaware of any new architectures likely to be ready in > time for inclusion in bullseye. > > On behalf of the release team, > Paul Gevers >
