Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
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
>
Reply to: