Re: Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
On Sat, Aug 18, 2018 at 07:01:39PM +0900, Roger Shimizu wrote:
>...
> Yes. In latest ARM BoF of DebConf18, Steve (93sam) informed us that
> he's trying to rebuild all the armhf archive on arm64 box.
> When that's done, we will get to know how many packages need to fix.
> If the number of those packages is limited and can be fixed before
> buster, we can choose this way for both armhf and armel.
Note that armel and armhf will have different problem when building
on arm64.
The armel baseline is low enough that some of the issues with running
armhf code on arm64 are not present when running armel code on arm64.
But armel might have different (currently unknown) issues.
> But if the number is huge that we don't have enough manpower to fix,
> we need to find real machine (such as rack-mounted armhf/armel NAS
> box) to work as buildd.
>...
There are two problems here:
The first is the remote administration side.
Rack-mounted might not even be necessary, but it must be possible to
remotely reset a hung box without a human going to the machine to press
a button.
The second are the hardware specs.
The current armel/armhf buildds each have 4x 1.6 GHz CPUs [1]
and 4 GM RAM.
Both cpu power and amount of RAM are at the lower side of what is
reasonable for a release architecture, and we cannot regress on
either of that.
We need full support in the upstream kernel.
And it has to be hardware we can rely on until mid-2022.
cu
Adrian
[1] these are Marvell PJ4, comparable speed at same frequency
should be approximately Cortex-A9
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: