On Fri, Jun 29, 2018 at 12:06 PM, John Paul Adrian Glaubitz <glaub...@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 <u...@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.