Arch qualification for buster: call for DSA, Security, toolchain concerns

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Fri, Jun 29, 2018 at 10:35 AM, Adam D. Barratt

what is the reason why that package is not moving forward?

I assume you're referring to the dpkg upload that's in proposed-updates
waiting for the point release in two weeks time?

i don't know: i'm an outsider who doesn't have the information in
short-term memory, which is why i cc'd the debian-riscv team as they
have current facts and knowledge foremost in their minds. which is
why i included them.

I'm also getting very tired of the repeated vilification of SRM over
this, and if there were any doubt can assure you that it is not
increasing at least my inclination to spend my already limited free
time on Debian activity.

ah. so what you're saying is, you could really do with some extra help?

l.

[Luke Kenneth Casson Leighton]

On Fri, Jun 29, 2018 at 12:23 PM, Adam D. Barratt

Post by Luke Kenneth Casson Leighton
i don't know: i'm an outsider who doesn't have the information in
short-term memory, which is why i cc'd the debian-riscv team as they
have current facts and knowledge foremost in their minds. which is
why i included them.

It would have been wiser to do so *before* stating that nothing was
happening as if it were a fact.

true... apologies.

Post by Luke Kenneth Casson Leighton
ah. so what you're saying is, you could really do with some extra help?

I don't think that's ever been in dispute for basically any core team
in Debian.

:)

That doesn't change the fact that the atmosphere around the change in
question has made me feel very uncomfortable and unenthused about SRM
work. (I realise that this is somewhat of a self-feeding energy
monster.)

i hear ya.

l.

[YunQiang Su]

Hi,
As part of the interim architecture qualification for buster, we request
that DSA, the security team and the toolchain maintainers review and
update their list of known concerns for buster release architectures.
* 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.
* Concerns from the GCC maintainers about armel, armhf, mips, mips64el
and mipsel have been carried over from stretch.
If the issues and concerns from you or your team are not up to date,
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.
------------
* Undesirable to keep the hardware running beyond 2020. armhf VM
support uncertain. (DSA)
- Source: [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)
* Concern for armel and armhf: only secondary upstream support in GCC
(Raised by the GCC maintainer; carried over from stretch)
* Concern for mips, mips64el, mipsel and ppc64el: no upstream support
in GCC
(Raised by the GCC maintainer; carried over from stretch)

This is a misunderstanding as MIPS company had some unrest in recent half year.
Currently we are stable now, and the shape of gcc upstream is also good.

Architecture status
===================
* Intel/AMD-based: amd64, i386
* ARM-based: arm64, armel, armhf
* MIPS-based: mips, mipsel, mips64el

We are plan to drop mips(eb) and keep mipsel/mips64el.

* Other: ppc64el, s390x
If the blocking issues cannot be resolved, affected architectures are at
risk of removal from testing before buster is frozen.
We are currently unaware of any new architectures likely to be ready in
time for inclusion in buster.
On behalf of the release team,
Niels Thykier

[Mattia Rizzolo]

This thread went OT talking about ports, but oh well


The build and package delivery infrastructure should offer the same features
for both first and second class archs, including installer image building for
all "tiers" (stable, testing, unstable).

It seems to me that the important bit is the testing suite. As a (now
lapsed) x32 porter, I tried to implement that on my own (goal being an
unofficial, weakly security supported[1] Jessie for x32). And tracking
testing on my own proved to be too hard.

Pretty much everything of what Adrian is mentioning (above is part of
it), would be fixed if the ports archive were to move to using a full
dak instance.

I know that James was working on adding the few missing features that
would be ports-specific, but I haven't heard an update on that work
since a while.