On Fri, Jun 29, 2018 at 12:06 PM, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

On 06/29/2018 10:41 AM, Luke Kenneth Casson Leighton wrote:

On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König <uwe@kleine-koenig.org> 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.

from what i gather the rule is that the packages have to be built
native. is that a correct understanding or has the policy changed?

Native in the sense that the CPU itself is not emulated which is the case when building arm32 packages on arm64.

ok. that's clear. thanks john.

I think that building on arm64 after fixing the bug in question is the
way to move forward. I'm surprised the bug itself hasn't been fixed yet, doesn't speak for ARM.

if you mean ARM hardware (OoO), it's too late. systems are out there
with OoO speculative execution bugs in the hardware (and certainly
more to be found), and they're here to stay unfortunately.

if you mean that buildd on 32-bit systems could be modified to pass "-Wl,--no-keep-memory" to all linker phases to see if that results in
the anticipated dramatic reduction in memory usage, that's
straightforward to try, nothing to do with ARM themselves.

l.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)