Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
On 18/08/18 11:01, Roger Shimizu wrote: On Sat, Aug 18, 2018 at 12:33 PM, Hideki Yamane wrote: Hi, So it'll be super great if you (or your boss) can kindly sponsor some armel/armhf hardwares that support to install 4GB memory. From DebConf18 seesion "Building a Debian Derivative: Lessons Learned and Solutions Found" by Alex Doyle from Cumulus Network, they run "Jessie on Chromebook" as armel build server https://youtu.be/OPsfX5_YCiQ?t=14m39s Thanks for your info! Maybe we can do same thing for armel, it'd be better than using old NAS with larger memory (I know we're trying to build armel/hf packages on arm64 but just a FYI). 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. 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. Personal opinion but (as a derivative maintainer) I really think DSA are being unreasonable here. A buildd does not need to be some critical 100% uptime server, if it occasionally goes down to the point where it can't be recovered remotely then so be it. Arm ports aside I don't think having "server class" hardware available should be a blocker for getting or maintaining a port in Debian. It never has been in the past and I don't see what has changed now. And I think with a serial console and remote power most issues can be resolved remotely. We have been running wandboard quads for raspbian for years and I have never hard a situation I couldn't get out of with remote power and serial console. On the subject of building on arm64 hardware we now do this for some of our builds in raspbian. It *mostly* works but we do see some testsuite failures that we don't see on the wandboards (otoh we have some testsuites that pass on the arm64 box but not the wandboards, go figure) and I have also been having a build hang with rust recently, but other than that I haven't noticed any prblems.
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
Re: Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
On Sat, Aug 18, 2018 at 12:33 PM, Hideki Yamane wrote: > Hi, > >> So it'll be super great if you (or your boss) can kindly sponsor some >> armel/armhf hardwares that support to install 4GB memory. > > From DebConf18 seesion "Building a Debian Derivative: Lessons Learned > and Solutions Found" by Alex Doyle from Cumulus Network, they run > "Jessie on Chromebook" as armel build server > https://youtu.be/OPsfX5_YCiQ?t=14m39s Thanks for your info! > Maybe we can do same thing for armel, it'd be better than using old > NAS with larger memory (I know we're trying to build armel/hf packages > on arm64 but just a FYI). 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. 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. Looking forward to getting the news update from Steve. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
Hi, > So it'll be super great if you (or your boss) can kindly sponsor some > armel/armhf hardwares that support to install 4GB memory. From DebConf18 seesion "Building a Debian Derivative: Lessons Learned and Solutions Found" by Alex Doyle from Cumulus Network, they run "Jessie on Chromebook" as armel build server https://youtu.be/OPsfX5_YCiQ?t=14m39s Maybe we can do same thing for armel, it'd be better than using old NAS with larger memory (I know we're trying to build armel/hf packages on arm64 but just a FYI). -- Hideki Yamane
Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
> On Jul 24, 2018, at 11:20 AM, Steve McIntyre wrote: > > [ Dropped cc to debian-ports etc., switched to debian-arm instead ] > >> As for the hardware, you should watch out for hardware with ARM Cortex Cores. >> Alternatively, X-Gene 1. ThunderX, ThunderX2 and Centriq are definitely not >> supported. > > Agreed on the others, but X-Gene 1 works just fine for A32. Not sure > about later cores... I should have phrased more carefully: ARM Cortex and X-Gene 1 are the ones that work, the others don’t according to Alex. As for the GHC bug, it’s probably a good idea to forward this upstream. Sergei Trofimovich from upstream is extremely good at fixing these things. He has fixed many obscure GHC bugs for Debian Ports architectures. Adrian
Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
[ Dropped cc to debian-ports etc., switched to debian-arm instead ] On Mon, Jul 23, 2018 at 04:11:06PM +0200, John Paul Adrian Glaubitz wrote: >Hi Roger! > >On 07/23/2018 10:42 AM, Roger Shimizu wrote: >> I talked to a few people about keeping armel in buster, during 1st and >> 2nd day in debcamp. >> Seems the blocker is just the buildd server hardware, and memory size it has. > >According to my colleague Alex Graf at SUSE, you can definitely build >ARMv7 on arm64 using chroots. The only problem with chroots is that >"uname -a" shows "armv8" which some userspace applications are stumbling >over. And a few other problems - see my mail in the other sub-thread. >openSUSE/SLE builds armv7 packages in OBS/IBS using a fully emulated system >using KVM. Nod. >As for the hardware, you should watch out for hardware with ARM Cortex Cores. >Alternatively, X-Gene 1. ThunderX, ThunderX2 and Centriq are definitely not >supported. Agreed on the others, but X-Gene 1 works just fine for A32. Not sure about later cores... -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
Hi Roger! On 07/23/2018 10:42 AM, Roger Shimizu wrote: > I talked to a few people about keeping armel in buster, during 1st and > 2nd day in debcamp. > Seems the blocker is just the buildd server hardware, and memory size it has. According to my colleague Alex Graf at SUSE, you can definitely build ARMv7 on arm64 using chroots. The only problem with chroots is that "uname -a" shows "armv8" which some userspace applications are stumbling over. openSUSE/SLE builds armv7 packages in OBS/IBS using a fully emulated system using KVM. As for the hardware, you should watch out for hardware with ARM Cortex Cores. Alternatively, X-Gene 1. ThunderX, ThunderX2 and Centriq are definitely not supported. 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: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
Dear armel/armhf shakeholders, I talked to a few people about keeping armel in buster, during 1st and 2nd day in debcamp. Seems the blocker is just the buildd server hardware, and memory size it has. On Fri, Jun 29, 2018 at 7:04 PM, W. Martin Borgert wrote: > > Quoting Uwe Kleine-König : >> >> 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 > > This seems to be out of stock and discontinued, unfortunately. This is still available in amazon: - https://www.amazon.com/dp/B00MQK14KC > Anyway, I'm relatively sure, that I can convince my boss to sponsor/donate > both armel and armhf hardware for Debian, if that is of any help. Or arm64 > used in "32 bits mode". I think DSA team prefers armel or armhf real hardware (not just developing boards). So it'll be super great if you (or your boss) can kindly sponsor some armel/armhf hardwares that support to install 4GB memory. Thanks! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
