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

[Florian Weimer]

* Florian Weimer:

>>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>>in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
>
> I'm surprised to read this.  ppc64el features prominently in the
> toolchain work I do (though I personally do not work on the GCC side).

The ppc64le situation has been clarified.  It's now listed explicitly
as a primary architecture, as powerpc64le-unknown-linux-gnu:

  

This has always been the intent, but I can understand that
distributions view powerpc64le-unknown-linux-gnu and
powerpc64-unknown-linux-gnu quite very different things.

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

[Moritz Mühlenhoff]

Paul Gevers wrote:
> 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.

There's nothing really of concern from the security team PoV, we don't
withhold security updates due to missing archs, so the worst case is that
some archs are outdated (happens to openjdk from time to time).

> 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.

I think the porter requirement for i386 should no longer be waived (the
current wiki page still says so).

i386 is legacy hardware for a long time and increasingly starts to lose
upstream support (and most other distros ceased support a well). If there
people who care about i386 for whatever reason, they should form a
debian-i386@ porter list which offers to fix i386-specific issues.

Cheers,
Moritz

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

[Ben Hutchings]

I don't know if this should be a blocker, but the MIPS builders are
still extremely slow for kernel builds.  In the worst case (mipsel:
mipsel-aql-{01,02}) it takes about 41 hours, which is 3 times longer
than the next slowest group of builders (armhf: hasse, henze, holby).
This can be a problem for getting security updates out promptly.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.




signature.asc
Description: This is a digitally signed message part

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

[Matthias Klose]

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/msg4.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
> 

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

[Florian Weimer]

* Paul Gevers:

>  * Concern for armel and armhf: only secondary upstream support in GCC
>(Raised by the GCC maintainer; carried over from stretch and buster)

glibc upstream lately has trouble finding qualified persons to
implement security fixes for the 32-bit Arm architecture.

>  * 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)

I think I said this the last time, but the claim that there is no GCC
upstream support for ppc64le in GCC or binutils does not appear to be
grounded in fact. 8-/

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

[Paul Gevers]

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/msg4.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)

 * 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)


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



signature.asc
Description: OpenPGP digital signature

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

[Mattia Rizzolo]

This thread went OT talking about ports, but oh well…

On Wed, Dec 12, 2018 at 04:03:25AM +0100, Adam Borowski wrote:
> On Tue, Dec 11, 2018 at 09:46:21PM +0100, Gregor Riepl wrote:
> > 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.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

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

[Adam Borowski]

[Oy vey, crosspost list from hell -- not sure how to trim...]

On Tue, Dec 11, 2018 at 09:46:21PM +0100, Gregor Riepl wrote:
> I do think this just reinforces the point that second-class architectures
> should have better, more robust support from the Debian project.

> For example, arch-specific packages most decidedly have a place in Debian

> 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.  What directly defeated me were
binNMUs: with every arch having its own NMU counter and hidden triggers,
this is already a mess.  Add NMUs due to private ported packages, and all
hell breaks loose.

The rest is easy in comparison: a porter team can decide whether to snapshot
testing as unofficial stable; point releases are a matter of running a
buildd job (and fixing failures), same for security.  We'd be able to
concentrate on actual arch-specific issues.

> The main difference should (IMHO) be the amount of support you get: While a
> first-class arch will get faster fixes and a more stable dependency tree,
> other archs will be more "sloppy", for example by not blocking stable releases
> with their own RC bugs etc.

Yeah, a completely one-way relationship: no issue on second-class would
block first-class.

> If this can be fulfilled, I don't think being a second-class arch will be such
> a big deal. Not sure how far Debian is from this goal, but I can understand
> that many DDs and DMs would rather invest their time into projects they have a
> stake in, rather than hardware they don't (or don't want to?) understand.

Yes, x32 suffers from needing obscure and hard to get hardware. :)


Meow!

[1]. The vast majority of security issues are non arch dependent, so blindly
tracking and building first-class security updates gets us nearly all the
way, reducing the work to babysitting buildds and looking into FTBFSes or
yet another whole-new-language-ecosystem getting allowed into stable.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

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

[Gregor Riepl]

Hi Adrian

I do think this just reinforces the point that second-class architectures
should have better, more robust support from the Debian project.

For example, arch-specific packages most decidedly have a place in Debian
(although they should not be the norm). There will always be such packages, as
proven by many that are available on first-class archs but not on second-class
ones (protobuf springs to mind:
https://buildd.debian.org/status/package.php?p=protobuf).

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).

The main difference should (IMHO) be the amount of support you get: While a
first-class arch will get faster fixes and a more stable dependency tree,
other archs will be more "sloppy", for example by not blocking stable releases
with their own RC bugs etc.

If this can be fulfilled, I don't think being a second-class arch will be such
a big deal. Not sure how far Debian is from this goal, but I can understand
that many DDs and DMs would rather invest their time into projects they have a
stake in, rather than hardware they don't (or don't want to?) understand.

Regards,
Greg

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

[John Paul Adrian Glaubitz]

Hello!

On 12/9/18 3:18 PM, Matthias Klose wrote:
> To me it looks sometimes that Debian is used for testing by upstream, and for
> that the mips architectures don't need to be release architectures.

A note on this: If you decide to move MIPS to Debian Ports, you will make the
port unusable to most users as Debian Ports has a rather rudimentary FTP archive
setup which has some annoying side effects.

There is no support for a testing release, there is no support for cruft and the
FTP maintainers will eventually remove any MIPS-only packages from the Debian
archive which don't build on other architectures which usually affects packages
like boot loaders meaning that it will no longer be easily possible to build the
debian-installer package and consequently build installation images. The 32-bit
PowerPC port lost quite a number of users because of this change. Not because 
the
port was not healthy but because people want to be able to install a stable 
release.

Debian unfortunately doesn't have really good support for Tier II 
architectures, it's
either release or something based on unstable that requires extra elbow grease 
from
both users and maintainers.

Please also keep in mind that removing MIPS from the list of release 
architectures
would mean one less open platform on which Debian is supported. Neither anything
based on ARM, x86 or IBM Z provides a true open platform due to the proprietary
nature of these architectures. There are some efforts in this regard on IBM 
POWER,
but the hardware is still rather expensive, unfortunately. I do hope that RISC-V
will catch up in the future though.

I also think that the broad architecture support is one of the selling points 
of Debian
and if we were to limit Debian's architecture support to just ARM, x86, POWER 
and IBM Z,
I fear that Debian would more and more be turned into a mere development 
project for Ubuntu
and other derivatives rather than being an operating system of its own.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Matthias Klose]

On 07.07.18 17:24, YunQiang Su wrote:
> Niels Thykier  于2018年6月28日周四 上午4:06写道：
>> 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)

I don't think anybody objected about the status for armhf.  I didn't follow
armel issues too closely.

>>  * 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.

This is an optimistic view.  While currently not having any RC issues, we still
see mips* specific issues popping up more often than on other release 
architectures.

According to https://gcc.gnu.org/gcc-8/criteria.html there is no mips*-linux*
target listed as either primary or secondary platform. As far as I understand
the mips porters argue that this is covered by mipsisa64-elf, a bare metal
target.  I don't agree with this view, because

 - testing is missing on mips*-linux-* targets.  If you look at
   the gcc-testresults ML, you see only test reports submitted for
   the Debian GCC packages, nothing else.

 - A bare metal target is usually only built/used for C and C++. I
   doubt that other frontends are tested.

 - Configurations like libgcjit are not tested/used upstream, and not
   addressed. See #798710.

The Debian bug tracking for the MIPS port could be better, I usually need some
pings to the MIPS porters to get things forwarded or addressed.

To me it looks sometimes that Debian is used for testing by upstream, and for
that the mips architectures don't need to be release architectures.

Matthias

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

[YunQiang Su]

Niels Thykier  于2018年6月28日周四 上午4:06写道：
>
> 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.
>
> 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.
>  * 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,
> then please follow up to this email (keeping debian-release@l.d.o and
> debian-ports@l.d.o in CC to ensure both parties 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]
>
>
> [DSA Sprint report]:
> https://lists.debian.org/debian-project/2018/02/msg4.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
> ===
>
> These are the architectures currently being built for buster:
>
>  * 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
>


-- 
YunQiang Su

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

[Luke Kenneth Casson Leighton]

spoke again to TL and asked if pine64 would be willing to look at
sponsorship witn rockpro64 boards (the ones that take 4x PCIe): if
someone from debian were to contact him direct he would happily
consider it.

i then asked him if i could cc him into this discussion and he said he
was way *way* too busy to enter into another mailing list discussion,
so if someone from debian emails me privately, off-list, i will then
cc him and/or put them in touch with him on irc.  i can also be
reached on freenode and oftc as "lkcl", if that is easier.

l.

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

[Luke Kenneth Casson Leighton]

On Fri, Jun 29, 2018 at 8:13 PM, Luke Kenneth Casson Leighton
 wrote:
> On Fri, Jun 29, 2018 at 6:59 PM, Jonathan Wiltshire  wrote:
>
>>>  also worth noting, they're working on a 2U rackmount server which
>>> will have i think something insane like 48 Rock64Pro boards in one
>>> full-length case.
>
>> None of this addresses the basic DSA requirement of remote management.
>> Troubling local hands to change a disk once in a while is reasonable; being
>> blocked waiting for a power cycle on a regular basis is not (and I can't
>> imagine hosting sponsors are wild about their employees' time being used
>> for that either).
>
> i know exactly what you mean, i've had to deal with data centres.
> i'll make sure that TL Lim is aware of this, and will ask him if
> there's a way to include remote power-management / power-cycling of
> boards in the planned product or if it's already been thought of.

 TL informs me that all the power and reset signals for all 48 of the
RockPro64s tucked into the full-length 2U case are brought out to the
back panel.  an MCU (or MCUs) or SBC (or SBCs) may therefore be
connected directly to those in order to provide *individual* remote
power / reset management of all 48 RockPro64s.  DIY remote power
management, but it is actual remote power management.

 l.

Re: Arm ports build machines (was Re: 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 8:31 PM, Florian Weimer  wrote:
> * Luke Kenneth Casson Leighton:
>
>>  that is not a surprise to hear: the massive thrashing caused by the
>> linker phase not being possible to be RAM-resident will be absolutely
>> hammering the drives beyond reasonable wear-and-tear limits.  which is
>> why i'm recommending people try "-Wl,--no-keep-memory".
>
> Note that ld will sometimes stuff everything into a single RWX segment
> as a result, which is not desirable.

 florian, thank you for responding: i've put a copy of the insights
that you give into the bugreport at
https://sourceware.org/bugzilla/show_bug.cgi?id=22831#c16

> Unfortunately, without significant investment into historic linker
> technologies (with external sorting and that kind of stuff),

 yes, ah ha!  funnily enough the algorithm that i was asked to create
back in 1988 was an external matrix-multiply, i take it you are
talking about the same thing, where linking is done using explicit
load-process-save cycles rather than relying on swap.

> I don't
> think it is viable to build 32-bit software natively in the near
> future.

  i noted an alternative strategy in the bugreport: if binutils *at
the very least* were to look at the available resident RAM and only
malloc'd and used up to that amount, and kept only a few (or even just
one) object file in memory at a time and did all the linking for that,
it would be infinitely better than the current situation which is
*only going to get worse*.

>   Maybe next year only a few packages will need exceptions, but
> the number will grow with each month.

 well... that ignores the fact that at some point in the next few
years there will be a package that needs 16 GB of resident RAM to
link.   and a few years after that it will be 32 GB.  and that's on
64-bit systems.  the package's name will probably be "firefox", given
the current growth rate.

 does debian *really* want to have to upgrade all 64-bit systems in
the build farm first to 16 GB RAM and then to 32 GB and then to 64
GB??  can the powerpc64 systems and all other 64-bit architectures
even *be* upgraded to 16 GB then 32 GB then 64 GB of RAM??

 basically the problems faced by 32-bit systems are a warning shot
across the bows about ld not really being kept up-to-date with the
increases in software complexity that's being thrown at it.  it's
*NOT* just about 32-bit.

 this problem can basically be faced REactively... or it can be faced
PROactively: the historic linker strategies that you mention are i
feel going to be needed in some years' time *even for 64-bit*.

l.

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

[Florian Weimer]

* Luke Kenneth Casson Leighton:

>  that is not a surprise to hear: the massive thrashing caused by the
> linker phase not being possible to be RAM-resident will be absolutely
> hammering the drives beyond reasonable wear-and-tear limits.  which is
> why i'm recommending people try "-Wl,--no-keep-memory".

Note that ld will sometimes stuff everything into a single RWX segment
as a result, which is not desirable.

Unfortunately, without significant investment into historic linker
technologies (with external sorting and that kind of stuff), I don't
think it is viable to build 32-bit software natively in the near
future.  Maybe next year only a few packages will need exceptions, but
the number will grow with each month.  Building on 64-bit kernels will
delay the inevitable because more address space is available to user
space, but that's probably 12 to 18 month extended life-time for
native building.

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

[Luke Kenneth Casson Leighton]

On Fri, Jun 29, 2018 at 6:59 PM, Jonathan Wiltshire  wrote:

>>  also worth noting, they're working on a 2U rackmount server which
>> will have i think something insane like 48 Rock64Pro boards in one
>> full-length case.

> None of this addresses the basic DSA requirement of remote management.
> Troubling local hands to change a disk once in a while is reasonable; being
> blocked waiting for a power cycle on a regular basis is not (and I can't
> imagine hosting sponsors are wild about their employees' time being used
> for that either).

i know exactly what you mean, i've had to deal with data centres.
i'll make sure that TL Lim is aware of this, and will ask him if
there's a way to include remote power-management / power-cycling of
boards in the planned product or if it's already been thought of.

l.

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

[Lennart Sorensen]

On Fri, Jun 29, 2018 at 06:29:48PM +0200, Geert Uytterhoeven wrote:
> Are you sure you're not interchanging A8 and A9, cfr. Linux kernel commit
> e388b80288aade31 ("ARM: spectre-v2: add Cortex A8 and A15 validation of the
> IBE bit")?

Yes.  That is the main reason the A9 is faster than the A8 at the same
clock speed by quite a bit.

For example http://www.360doc.com/content/12/0806/14/350555_228637047.shtml 
says:
Cortex-A9 has many advanced features for a RISC CPU, such as speculative
data accesses, branch prediction, multi-issuing of instructions,
hardware cache coherency, out-of-order execution and register renaming.
Cortex-A8 does not have these, except for dual-issuing instructions and
branch prediction.

So the A8 still has branch prediction so it can keep the pipeline fed,
even with in order execution.  Spectre isn't really about out-of-order
excution as much as it is about speculative memory accesses which some
in-order execution chips have too.

-- 
Len Sorensen

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

[Jonathan Wiltshire]

On Fri, Jun 29, 2018 at 06:05:55PM +0100, Luke Kenneth Casson Leighton wrote:
>  apologies for repeating it again: this is why i'm recommending people
> try "-Wl,--no-keep-memory" on the linker phase as if it works as
> intended it will almost certainly drastically reduce memory usage to
> the point where it will stay, for the majority of packages, well
> within the 2GB limit i.e. within resident RAM.
[...]
>  most of them won't have native SATA: very few 32-bit ARM systems do.
> GbE is not that common either (so decent-speed network drives are
> challenging, as well).  so they'll almost certainly be USB-based
> (USB-to-SATA, which is known-unreliable), and putting such vast
> amounts of drive-hammering through USB-to-SATA due to thrashing isn't
> going to help :)
[...]
> 
>  the allwinner A20 and R40 are the two low-cost ARM systems that i'm
> aware of that have native SATA.
> 
> 
>  there is however a new devboard that is reasonably cheap and should
> be available really soon: the Rock64Pro (not to be confused with the
> Rock64, which does NOT have PCie), from pine64:
> https://www.pine64.org/?page_id=61454
> 
>  it's one of the first *low-cost* ARM dev-boards that i've seen which
> has 4GB of RAM and has a 4x PCIe slot.  the team have tested it out
> with an NVMe SSD and also 4x SATA PCIe cards: they easily managed to
> hit 20 Gigabits per second on the NVMe drive (2500 mbytes/sec).
> 
>  also worth noting, they're working on a 2U rackmount server which
> will have i think something insane like 48 Rock64Pro boards in one
> full-length case.
> 
>  the Rock64Pro uses the RK3399 which is a 4-core CortexA53 plus 2-core
> CortexA72 for a total 6-core SMP system, all 64-bit.
> 
>  if anyone would like me to have a word with TL Lim (the CEO of
> pine64) i can see if he is willing and able to donate some Rock64Pro
> boards to the debian farm, let me know.

None of this addresses the basic DSA requirement of remote management.
Troubling local hands to change a disk once in a while is reasonable; being
blocked waiting for a power cycle on a regular basis is not (and I can't
imagine hosting sponsors are wild about their employees' time being used
for that either).

Development boards just don't cut it any longer.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

[Luke Kenneth Casson Leighton]

On Fri, Jun 29, 2018 at 5:21 PM, Steve McIntyre  wrote:

>>2G is also way too little memory these days for a new buildd.
>
> Nod - lots of packages are just too big for that now.

 apologies for repeating it again: this is why i'm recommending people
try "-Wl,--no-keep-memory" on the linker phase as if it works as
intended it will almost certainly drastically reduce memory usage to
the point where it will stay, for the majority of packages, well
within the 2GB limit i.e. within resident RAM.

 i'm really not sure why the discussions continue not to take this
into account, repeating the status-quo and accepting "packages are too
big" as if there is absolutely no possible way that this problem may
be solved or even attempted to be solved... ever.  i am very confused
by this.  perhaps it is down to latency in discussions as new people
contribute (but have signficant delay on reading), i don't know.


> Future options
> ==
>
> I understand DSA's reluctance to continue supporting dev boards as
> build platforms - I've been the one working on some of these machines
> in the machine room at Arm, and it's painful when you can't reliably
> reboot or get onto the console of crashed machines. We've also had a
> spate of disk failures recently which has caused extended downtime.

 that is not a surprise to hear: the massive thrashing caused by the
linker phase not being possible to be RAM-resident will be absolutely
hammering the drives beyond reasonable wear-and-tear limits.  which is
why i'm recommending people try "-Wl,--no-keep-memory".

 ... oh, i have an idea which people might like to consider trying.
it's to use "-Wl,--no-keep-memory" on the linker phase of 32-bit
builds.  did i mention that already? :)  it might save some build
hardware from being destroyed if people try using
"-Wl,--no-keep-memory"!


> I'm just in the middle of switching the arm64 machines here to using
> SW RAID to mitigate that in future, and that's just not an option on
> the dev boards. We want to move away from dev boards for these
> reasons, at the very least.

 most of them won't have native SATA: very few 32-bit ARM systems do.
GbE is not that common either (so decent-speed network drives are
challenging, as well).  so they'll almost certainly be USB-based
(USB-to-SATA, which is known-unreliable), and putting such vast
amounts of drive-hammering through USB-to-SATA due to thrashing isn't
going to help :)

 the allwinner A20 and R40 are the two low-cost ARM systems that i'm
aware of that have native SATA.


 there is however a new devboard that is reasonably cheap and should
be available really soon: the Rock64Pro (not to be confused with the
Rock64, which does NOT have PCie), from pine64:
https://www.pine64.org/?page_id=61454

 it's one of the first *low-cost* ARM dev-boards that i've seen which
has 4GB of RAM and has a 4x PCIe slot.  the team have tested it out
with an NVMe SSD and also 4x SATA PCIe cards: they easily managed to
hit 20 Gigabits per second on the NVMe drive (2500 mbytes/sec).

 also worth noting, they're working on a 2U rackmount server which
will have i think something insane like 48 Rock64Pro boards in one
full-length case.

 the Rock64Pro uses the RK3399 which is a 4-core CortexA53 plus 2-core
CortexA72 for a total 6-core SMP system, all 64-bit.

 if anyone would like me to have a word with TL Lim (the CEO of
pine64) i can see if he is willing and able to donate some Rock64Pro
boards to the debian farm, let me know.

l.

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

[Geert Uytterhoeven]

Hi Lennart,

debian-ports -> debian-arm

On Fri, Jun 29, 2018 at 5:00 PM Lennart Sorensen
 wrote:
> On Fri, Jun 29, 2018 at 10:20:50AM +0100, Luke Kenneth Casson Leighton wrote:
> >  in addition, arm64 is usually speculative OoO (Cavium ThunderX V1
> > being a notable exception) which means it's vulnerable to spectre and
> > meltdown attacks, whereas 32-bit ARM is exclusively in-order.  if you
> > want to GUARANTEE that you've got spectre-immune hardware you need
> > either any 32-bit system (where even Cortex A7 has virtualisattion) or
> > if 64-bit is absolutely required use Cortex A53.
>
> The Cortex A8, A7 and A5 are in order.  The A9, A15, A17 etc are out of
> order execution.  So any 32 bit arm worth using is pretty much always
> out of order execution.

Are you sure you're not interchanging A8 and A9, cfr. Linux kernel commit
e388b80288aade31 ("ARM: spectre-v2: add Cortex A8 and A15 validation of the
IBE bit")?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

[Steve McIntyre]

On Fri, Jun 29, 2018 at 11:23:25AM +0200, Julien Cristau wrote:
>On 06/29/2018 09:16 AM, Uwe Kleine-König wrote:
>>>
>>> [DSA Sprint report]:
>>> https://lists.debian.org/debian-project/2018/02/msg4.html
>> 
>> In this report Julien Cristau wrote:
>> 
>>> In short, the hardware (development boards) we're currently using to
>>> build armel and armhf packages aren't up to our standards, and we
>>> really, really want them to go away when stretch goes EOL (expected in
>>> 2020).  We urge arm porters to find a way to build armhf packages in
>>> VMs or chroots on server-class arm64 hardware.
>> 
>> If the concerns are mostly about the hardware not being rackable, there
>> is a rackable NAS by Netgear:
>> 
>>  
>> https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs
>> 
>> with an armhf cpu. Not sure if cpu speed (1.2 GHz) and available RAM (2
>> GiB) are good enough. The machine can run mainline Linux[1]. I think
>> U-Boot doesn't support this machine in mainline though.
>> 
>Rackable, while good, is only part of it.  The main part is remote
>management.  I'm not seeing any mention of ipmi or anything like that in
>the datasheet?
>
>2G is also way too little memory these days for a new buildd.

Nod - lots of packages are just too big for that now.

So, here's a summary of the current build/porter machines we have for
the arm ports.

armel/armhf *only* build machines
=

We're mostly using dev boards to build 32-bit arm stuff yet.

 * 7 Marvell Armada XP machines: dev boards supplied in a box, 4GiB
   RAM - see http://photos.einval.com/gallery/2014_marvell_buildd
   These are nice powerful little machines, but they're a PITA to
   manage for power (won't cold boot without a button push) and serial
   (USB serial exposed only). We have 6 of these as build boxes and 1
   porter box, and I have a spare ready to go into service if
   desired. They *don't* have NEON, so we also still have:

 * 1 Freescale imx53 dev board as a porter box - old, slow Cortex A8
   machine with only 1GiB of RAM. This works better for serial, but
   remote power issues again - needs a button push to cold boot. Will
   happily retire this once we have NEON available by default.

Each of these dev boards only has support for 1 disk, so disk failures
are painful.

arm64 build machines


These are all more normal computers, with better support for remote
power and serial, DIMM slots, multiple disks, etc.

 * APM Mustang (X-Gene 1): officially EOL, but working fine for
   now. Normal server-class machine (although supplied in a small
   desktop case!) with some onboard server management stuff. We
   currently have one of these. We used to have more loaned/hosted by
   Linaro, and I've had an offer of more of these if we're
   interested. They'll build and run A32 (32-bit instruction set) as
   well as A64.

 * Gigabyte MP30-AR0 (X-Gene 1): server systems based on the Mustang
   core - see
   https://b2b.gigabyte.com/Server-Motherboard/MP30-AR0-rev-11#ov
   Capable of building/running A32 and A64.

 * AMD Seattle (Opteron A1100): officially EOL too, but working
   fine. Same as the Softiron 3000, 2U rackmount case. Capable of
   building/running A32 and A64. One of these has just been configured
   to build armhf only.

Future options
==

I understand DSA's reluctance to continue supporting dev boards as
build platforms - I've been the one working on some of these machines
in the machine room at Arm, and it's painful when you can't reliably
reboot or get onto the console of crashed machines. We've also had a
spate of disk failures recently which has caused extended downtime.
I'm just in the middle of switching the arm64 machines here to using
SW RAID to mitigate that in future, and that's just not an option on
the dev boards. We want to move away from dev boards for these
reasons, at the very least.

So, at the moment as far as I can see we're happy with our current
arm64 build machines. They are ageing, so obviously I'm continuing to
look out for new options there as well. *But* my priority is new
options for 32-bit building too. Following standard Debian practice,
we want to build *natively* (i.e. not using cross-building or using
hardware emulation). Building 32-bit code on a 64-bit platform should
not be an issue so long as the platform can also execute that 32-bit
code directly.

I am not aware of any 32-bit Arm *server* platforms shipping
today. Some have existed in the past (e.g. Calxeda), but almost
universally people have moved on to 64-bit now. The awkward thing that
is now becoming more common in the arm64 server world is that quite a
few of the vendors are not seeing any value in A32 support so they're
leaving it out of their CPUs. We'll need to be careful about that.

Options I can see today for new publically available machines are
here. I'm sure I'll have missed something obvious - please feel free
to improve on this list!

 * 

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

[Lennart Sorensen]

On Fri, Jun 29, 2018 at 10:20:50AM +0100, Luke Kenneth Casson Leighton wrote:
>  in addition, arm64 is usually speculative OoO (Cavium ThunderX V1
> being a notable exception) which means it's vulnerable to spectre and
> meltdown attacks, whereas 32-bit ARM is exclusively in-order.  if you
> want to GUARANTEE that you've got spectre-immune hardware you need
> either any 32-bit system (where even Cortex A7 has virtualisattion) or
> if 64-bit is absolutely required use Cortex A53.

The Cortex A8, A7 and A5 are in order.  The A9, A15, A17 etc are out of
order execution.  So any 32 bit arm worth using is pretty much always
out of order execution.

For 64 bit, I think the A35 and A53 are in order while the A57, A72 etc
are out of order.

Of course non Cortex designs vary (I think Marvel's JP4 core was out of
order execution for example).

After all, in general in order execution equals awful performance.

-- 
Len Sorensen

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

[Luke Kenneth Casson Leighton]

On Fri, Jun 29, 2018 at 12:50 PM, Julien Cristau  wrote:

> Everyone, please avoid followups to debian-po...@lists.debian.org.
> Unless something is relevant to *all* architectures (hint: discussion of
> riscv or arm issues don't qualify), keep replies to the appropriate
> port-specific mailing list.

 apologies, julien: as an outsider i'm not completely familiar with
the guidelines.  the reduction in memory-usage at the linker phase
"-Wl,--no-keep-memory" however - and the associated inherent
slowly-inexorably-increasing size is i feel definitely something that
affects all ports.

 it is really *really* tricky to get any kind of traction *at all*
with people on this.  it's not gcc's problem to solve, it's not one
package's problem to solve, it's not any one distros problem to solve,
it's not any one port's problem to solve and so on, *and* it's a
slow-burn problem that's taking *literally* a decade to become more
and more of a problem.  consequently getting reports and feedback to
the binutils team is... damn hard.

l.

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

[Julien Cristau]

On 06/27/2018 10:03 PM, Niels Thykier wrote:
> 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.
> 
Everyone, please avoid followups to debian-po...@lists.debian.org.
Unless something is relevant to *all* architectures (hint: discussion of
riscv or arm issues don't qualify), keep replies to the appropriate
port-specific mailing list.

Thanks,
Julien

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

[Luke Kenneth Casson Leighton]

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

>>  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.

>>  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.

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

[Adam D. Barratt]

On Fri, 2018-06-29 at 11:44 +0100, Luke Kenneth Casson Leighton wrote:
[...]
> On Fri, Jun 29, 2018 at 10:35 AM, Adam D. Barratt
>  wrote:
> 
> > >  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.

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

> > 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?

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.)

Regards,

Adam

Re: 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
 wrote:

>>  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.

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

[Adam D. Barratt]

On Fri, 2018-06-29 at 10:20 +0100, Luke Kenneth Casson Leighton wrote:
[...]
>  debian-riscv has been repeatedly asking for a single zero-impact
> line
> to be included in *one* file in *one* dpkg-related package which
> would
> allow riscv to stop being a NMU architecture and become part of
> debian/unstable (and quickly beyond), for at least six months, now.
> cc'ing the debian-riscv list because they will know the details about
> this.  it's really quite ridiculous that a single one-line change
> having absolutely no effect on any other architecture whatsover is
> not
> being actioned and is holding debian-riscv back because of that.
> 
>  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? Please check your
facts before ranting, particularly with such a wide cross-posting.

Also, ttbomk, the dpkg change landing in stable is not likely to
magically lead to the architecture being added to unstable - a decision
which is not the release team's to make or block. Again, please ensure
you've actually done your research.

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.

Regards,

Adam

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

[Luke Kenneth Casson Leighton]

On Wed, Jun 27, 2018 at 9:03 PM, Niels Thykier  wrote:

> armel/armhf:
> 
>
>  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]

 [other affected 32-bit architectures removed but still relevant]

 ... i'm not sure how to put this other than to just ask the question.
has it occurred to anyone to think through the consequences of not
maintaining 32-bit versions of debian for the various different
architectures?  there are literally millions of ARM-based tablets and
embedded systems out there which will basically end up in landfill if
a major distro such as debian does not take a stand and push back
against the "well everything's going 64-bit so why should *we*
bother?" meme.

 arm64 is particularly inefficient and problematic compared to
aarch32: the change in the instruction set resulted in dropping some
of the more efficiently-encoded instructions that extend a 64-bit
program size, require a whopping FIFTY PERCENT instruction-cache size
increase to compensate for, whch increased power consumption by over
15%.

 in addition, arm64 is usually speculative OoO (Cavium ThunderX V1
being a notable exception) which means it's vulnerable to spectre and
meltdown attacks, whereas 32-bit ARM is exclusively in-order.  if you
want to GUARANTEE that you've got spectre-immune hardware you need
either any 32-bit system (where even Cortex A7 has virtualisattion) or
if 64-bit is absolutely required use Cortex A53.

 basically, abandoning or planning to abandon 32-bit ARM *right now*
leaves security-conscious end-users in a really *really* dicey
position.


> We are currently unaware of any new architectures likely to be ready in
> time for inclusion in buster.

 debian-riscv has been repeatedly asking for a single zero-impact line
to be included in *one* file in *one* dpkg-related package which would
allow riscv to stop being a NMU architecture and become part of
debian/unstable (and quickly beyond), for at least six months, now.
cc'ing the debian-riscv list because they will know the details about
this.  it's really quite ridiculous that a single one-line change
having absolutely no effect on any other architecture whatsover is not
being actioned and is holding debian-riscv back because of that.

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

 l.

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

[Florian Weimer]

* Niels Thykier:

> armel/armhf:
> 
>
>  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]

Fedora is facing an issue running armhf under virtualization on arm64:

  
  

Unless the discussion has moved somewhere where I can't follow it, no
one seems to have solid idea what is going on.  It's also not clear
that this configuration has substantial vendor or community support.
This makes me concerned that virtualization is a viable path forward
here.

(The discussion on the GCC list started off with a misdirection, sorry
about that.  The brief assumption that this was a hardware quirk is
likely quite wrong.)

>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>in GCC
>(Raised by the GCC maintainer; carried over from stretch)

I'm surprised to read this.  ppc64el features prominently in the
toolchain work I do (though I personally do not work on the GCC side).
>From my point of view, it's absolutely not in the same category as the
MIPS-based architectures.

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

[Niels Thykier]

Breno Leitao:
> Hi Niels,
> 
> On 06/27/2018 05:03 PM, Niels Thykier wrote:
> 
>> 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)
> 
> I am not sure if ppc64el should be here. GCC does have a good ppc64el support
> and this is being maintained by some IBM folks.
> 
> Can you elaborate a bit more on this concern for ppc64el?
> 

Hi,

That was a mistake by my part.  Matthias already mentioned that ppc64el
was not a concern and I see I only removed the first but not the second
reference.

Apologies for the confusion.

Thanks,
~Niels

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

[Breno Leitao]

Hi Niels,

On 06/27/2018 05:03 PM, Niels Thykier wrote:

> 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)

I am not sure if ppc64el should be here. GCC does have a good ppc64el support
and this is being maintained by some IBM folks.

Can you elaborate a bit more on this concern for ppc64el?

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

[Niels Thykier]

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.

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.
 * 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,
then please follow up to this email (keeping debian-release@l.d.o and
debian-ports@l.d.o in CC to ensure both parties 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]


[DSA Sprint report]:
https://lists.debian.org/debian-project/2018/02/msg4.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)


Architecture status
===

These are the architectures currently being built for buster:

 * Intel/AMD-based: amd64, i386
 * ARM-based: arm64, armel, armhf
 * MIPS-based: mips, 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



signature.asc
Description: OpenPGP digital signature