Re: Summary of the Arm ports BoF at DC18

2018-11-11 Thread Adrian Bunk
On Sun, Oct 28, 2018 at 05:01:05PM +, Steve McIntyre wrote: >... > Hardware setup: I've configured the earlier 3 as buildds in little 1U > cases with 32GiB RAM and mirrored SSDs, but for $reasons they're not > yet installed and running. I'm assuming that a similar spec would be > wanted for aut

Re: Summary of the Arm ports BoF at DC18

2018-10-29 Thread Holger Levsen
On Sun, Oct 28, 2018 at 05:01:05PM +, Steve McIntyre wrote: > I now have 3 more basic Synquacer machines in my posession, ready to > order new cases, RAM, etc. (They ship in desktop cases with a single > 1TB hard drive and 4 GiB of RAM.) Again, I'm hoping to pick more up in > the future, but su

Re: Summary of the Arm ports BoF at DC18

2018-10-28 Thread Antonio Terceiro
On Sun, Oct 28, 2018 at 05:01:05PM +, Steve McIntyre wrote: > >On 20-09-18 10:24, Steve McIntyre wrote: > >> * I'm expecting to pick up several Synquacer machines (24-core Cortex > >>A53) to use for Debian, donated by Linaro. Some will become > >>buildds, wanting to get more to use for

Re: Summary of the Arm ports BoF at DC18

2018-10-28 Thread Steve McIntyre
>On 20-09-18 10:24, Steve McIntyre wrote: >> * I'm expecting to pick up several Synquacer machines (24-core Cortex >>A53) to use for Debian, donated by Linaro. Some will become >>buildds, wanting to get more to use for autopkgtest, debian-ci, >>reproducible builds etc. [UPDATE: 3 of th

Re: Summary of the Arm ports BoF at DC18

2018-09-20 Thread Steve McIntyre
On Thu, Sep 20, 2018 at 09:49:45PM +0200, Paul Gevers wrote: >Hi Steve, > >On 20-09-18 10:24, Steve McIntyre wrote: >> * I'm expecting to pick up several Synquacer machines (24-core Cortex >>A53) to use for Debian, donated by Linaro. Some will become >>buildds, wanting to get more to use f

Re: Summary of the Arm ports BoF at DC18

2018-09-20 Thread Paul Gevers
Hi Steve, On 20-09-18 10:24, Steve McIntyre wrote: > * I'm expecting to pick up several Synquacer machines (24-core Cortex >A53) to use for Debian, donated by Linaro. Some will become >buildds, wanting to get more to use for autopkgtest, debian-ci, >reproducible builds etc. [UPDATE: 3

Summary of the Arm ports BoF at DC18

2018-09-20 Thread Steve McIntyre
[ Please note the cross-post and Reply-To ] Hi folks, As promised, here's a quick summary of what was discussed at the Arm ports BoF session in Hsinchu. Apologies for the delay in posting... Thanks to the awesome efforts of our video team, the session is already online [1]. I've taken

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

2018-06-29 Thread 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

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

2018-06-29 Thread 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. >

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

2018-06-29 Thread 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 wil

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

2018-06-29 Thread 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-m

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

2018-06-29 Thread 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. > T

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

2018-06-29 Thread 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 poin

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

2018-06-29 Thread 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 a

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

2018-06-29 Thread Steve McIntyre
; >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.

Re: Summary of the Arm ports BoF at DC17

2017-09-18 Thread Lennart Sorensen
On Mon, Sep 18, 2017 at 10:50:39AM +0100, Ian Campbell wrote: > On Mon, 2017-09-18 at 10:15 +0100, Edmund Grimley Evans wrote: > > > But it did remind me that on some platforms writing "2" to > > > /proc/sys/abi/cp15_barrier will enable hw support for these > > > instructions, since some platforms

Re: Summary of the Arm ports BoF at DC17

2017-09-18 Thread Ian Campbell
On Mon, 2017-09-18 at 10:15 +0100, Edmund Grimley Evans wrote: > > But it did remind me that on some platforms writing "2" to > > /proc/sys/abi/cp15_barrier will enable hw support for these > > instructions, since some platforms do support them even thought > > they > > are deprecated. It's certain

Re: Summary of the Arm ports BoF at DC17

2017-09-18 Thread Edmund Grimley Evans
> But it did remind me that on some platforms writing "2" to > /proc/sys/abi/cp15_barrier will enable hw support for these > instructions, since some platforms do support them even thought they > are deprecated. It's certainly worth investigating what your hardware > supports. Not necessarily disa

Re: Summary of the Arm ports BoF at DC17

2017-09-18 Thread Ian Campbell
On Sun, 2017-09-17 at 12:59 -0700, Vagrant Cascadian wrote: > On 2017-09-15, Ben Hutchings wrote: > > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote: > > [...] > >> There is optional kernel support to trap the exceptions here > >> and emulate the instructions, but it's really not recommend

Re: Summary of the Arm ports BoF at DC17

2017-09-17 Thread Ben Hutchings
On Sun, 2017-09-17 at 21:30 +0100, Colin Watson wrote: > On Sun, Sep 17, 2017 at 12:59:04PM -0700, Vagrant Cascadian wrote: > > On 2017-09-15, Ben Hutchings wrote: > > > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote: > > > [...] > > > > There is optional kernel support to trap the excepti

Re: Summary of the Arm ports BoF at DC17

2017-09-17 Thread Steve McIntyre
On Fri, Sep 15, 2017 at 07:11:38PM +0100, Ben Hutchings wrote: >On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote: >[...] >> There is optional kernel support to trap the exceptions here >> and emulate the instructions, but it's really not recommended for >> serious use (e.g. on a build machin

Re: Summary of the Arm ports BoF at DC17

2017-09-17 Thread Ben Hutchings
On Sun, 2017-09-17 at 12:59 -0700, Vagrant Cascadian wrote: > On 2017-09-15, Ben Hutchings wrote: > > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote: > > [...] > > > There is optional kernel support to trap the exceptions here > > > and emulate the instructions, but it's really not recomme

Re: Summary of the Arm ports BoF at DC17

2017-09-17 Thread Colin Watson
On Sun, Sep 17, 2017 at 12:59:04PM -0700, Vagrant Cascadian wrote: > On 2017-09-15, Ben Hutchings wrote: > > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote: > > [...] > >> There is optional kernel support to trap the exceptions here > >> and emulate the instructions, but it's really not re

Re: Summary of the Arm ports BoF at DC17

2017-09-17 Thread Vagrant Cascadian
On 2017-09-15, Ben Hutchings wrote: > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote: > [...] >> There is optional kernel support to trap the exceptions here >> and emulate the instructions, but it's really not recommended for >> serious use (e.g. on a build machine!). > [...] > > Why is i

Re: Summary of the Arm ports BoF at DC17

2017-09-15 Thread Wookey
On 2017-09-14 12:58 +0800, Paul Wise wrote: > Wookey, could you add something about the motivation for arm64ilp32 to > the wiki page about it? Will do. But the short version is that it's only useful if you need to run 32-bit code on hardware that only supports the 64-bit execution mode. Such hardw

Re: Summary of the Arm ports BoF at DC17

2017-09-15 Thread Ben Hutchings
On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote: [...] > There is optional kernel support to trap the exceptions here > and emulate the instructions, but it's really not recommended for > serious use (e.g. on a build machine!). [...] Why is it not recommended? Terrible performance, or kno

Re: Summary of the Arm ports BoF at DC17

2017-09-14 Thread Steve McIntyre
On Thu, Sep 14, 2017 at 12:06:13PM +0200, Marco d'Itri wrote: >On Sep 14, Steve McIntyre wrote: > >> The Pine64 [6] is another alternative, based on a mobile CPU. It's >> therefore got limited RAM and I/O. Upstreaming has taken a while, but >> is getting there in current kernel releases. U-Boot he

Re: Summary of the Arm ports BoF at DC17

2017-09-14 Thread Steve McIntyre
nnel and tell doko you are there to >support armel. +1 >Improve the wiki page for armel, move it under the Ports hierarchy and >base it off the port template: > >https://wiki.debian.org/ArmEabiPort >https://wiki.debian.org/Ports >https://wiki.debian.org/PortTemplate > &

Re: Summary of the Arm ports BoF at DC17

2017-09-14 Thread Marco d'Itri
On Sep 14, Steve McIntyre wrote: > The Pine64 [6] is another alternative, based on a mobile CPU. It's > therefore got limited RAM and I/O. Upstreaming has taken a while, but > is getting there in current kernel releases. U-Boot head will work on > the board, including the UEFI implementation ment

Re: Summary of the Arm ports BoF at DC17

2017-09-13 Thread Paul Wise
source package for anything other than virtual machines (x86/ARMv7/ARMv8). It seems to me that u-boot is in a much better position wrt upstream support for ARM *and* for support for UEFI than TianoCore or other options that aren't in Debian like coreboot. > Hector asked about the current st

Summary of the Arm ports BoF at DC17

2017-09-13 Thread Steve McIntyre
[ Please note the cross-post and Reply-To ] Hi folks, As promised, here's a quick summary of what was discussed at the Arm ports BoF session in Montréal. Apologies for the delay in posting... Thanks to the awesome efforts of our video team, the session is already online [1]. I've ta

Re: ARM Ports BoF: armel in buster

2017-09-02 Thread W. Martin Borgert
On 2017-09-03 01:14, John Paul Adrian Glaubitz wrote: > * there are enough crazy people with too much time like Adrian, >Roger and me who are willing to fix stuff This reminds me of something: Thanks to all of you! > So, currently all is good with armel and we can go back to > discussing how

Re: ARM Ports BoF: armel in buster

2017-09-02 Thread John Paul Adrian Glaubitz
On 09/02/2017 11:44 PM, W. Martin Borgert wrote: > Right, most RPi users run Raspbian, but there are also people > - like me :~) - who prefer to run "pure" Debian, even at the > cost of a performance penalty (in case of RPi 1 or Zero). > I imagine, you know (and share) reasons to prefer Debian. Ye

Re: ARM Ports BoF: armel in buster

2017-09-02 Thread W. Martin Borgert
On 2017-08-28 11:19, John Paul Adrian Glaubitz wrote: > Aren't most RPi users running Raspian anyway which is armhf with -march > set to ARMv6? Right, most RPi users run Raspbian, but there are also people - like me :~) - who prefer to run "pure" Debian, even at the cost of a performance penalty (

Re: ARM Ports BoF: armel in buster

2017-09-01 Thread Ian Campbell
On Fri, 2017-09-01 at 19:27 +0300, Adrian Bunk wrote: > [...] > > What matters for buster is gcc 8, and there is no current deprecation > in gcc that would affect the armel port. Thanks for all the info! > armel is a port on borrowed time since it supports old hardware > no longer supported else

Re: ARM Ports BoF: armel in buster

2017-09-01 Thread Adrian Bunk
On Mon, Aug 28, 2017 at 06:57:40PM +0100, Ian Campbell wrote: > On Mon, 2017-08-28 at 06:53 +0800, Paul Wise wrote: > > On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote: > > > > > However, I think armel is time to transit to v5. > > > > As someone who can no longer run Debian stable on his MI

Re: ARM Ports BoF: armel in buster

2017-09-01 Thread Adrian Bunk
On Mon, Aug 28, 2017 at 06:53:54AM +0800, Paul Wise wrote: >... > OTOH the > only relevant hardware for armel these days seems to be RPi, so why > not make armel into armhfv6 instead? Incompatible ABI, your suggestion to move Raspbian as armhfv6 into Debian would therefore have to be a new port.

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread David Goodenough
On Monday, 28 August 2017 16:23:24 BST W. Martin Borgert wrote: > Quoting uhmgawa : > > On 08/28/2017 08:46 AM, W. Martin Borgert wrote: > >> As long as you have enough flash memory (some hundreds of MiB) and RAM > >> (at least 64 MiB, better 128 MiB), Debian runs fine on such hardware > >> in my e

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread John Paul Adrian Glaubitz
On 08/28/2017 10:11 PM, W. Martin Borgert wrote: > This depends on the build process: In my case we build in a > clean environment with all build dependencies pre-installed. > Remember, this is not a generic Debian build process, but a > specialised one for certain packages. I'm pretty sure the st

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread W. Martin Borgert
On 2017-08-28 19:16, John Paul Adrian Glaubitz wrote: > On 08/28/2017 06:30 PM, W. Martin Borgert wrote: > > But my experience is quiet good with this: > > > > ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- dpkg-buildpackage > > -rfakeroot -aarmel ... > > > > I don't remember what the ARCH var

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread John Paul Adrian Glaubitz
On 08/28/2017 07:57 PM, Ian Campbell wrote: >> As someone who can no longer run Debian stable on his MIPS device due >> to the CPU requirements bump in stretch, I'm not sure that bumping >> CPU >> requirements is a good idea in general. If there are actual benefits >> to v5 as the default then bump

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread Ian Campbell
On Mon, 2017-08-28 at 06:53 +0800, Paul Wise wrote: > On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote: > > > However, I think armel is time to transit to v5. > > As someone who can no longer run Debian stable on his MIPS device due > to the CPU requirements bump in stretch, I'm not sure that

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread John Paul Adrian Glaubitz
On 08/28/2017 06:30 PM, W. Martin Borgert wrote: > AFAIK, there is no policy requiring that packages can be cross-build. We are working on something like that, but it's a larger goal. Basically, we're planning to have cross-buildds which will additionally test packages for cross-buidability. One

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread W. Martin Borgert
Quoting uhmgawa : We've done so for Jessie, but it is a rather tedious manual process and one which starts eroding the benefit of project soak on a supported installation footprint. A relief I didn't call out previously is these figures are physical sizes. We can shoe horn in considerably m

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread uhmgawa
On 08/28/2017 10:23 AM, W. Martin Borgert wrote: > Quoting uhmgawa : >> On 08/28/2017 08:46 AM, W. Martin Borgert wrote: >>> As long as you have enough flash memory (some hundreds of MiB) and RAM >>> (at least 64 MiB, better 128 MiB), Debian runs fine on such hardware >>> in my experience. It depen

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread W. Martin Borgert
Quoting uhmgawa : On 08/28/2017 08:46 AM, W. Martin Borgert wrote: As long as you have enough flash memory (some hundreds of MiB) and RAM (at least 64 MiB, better 128 MiB), Debian runs fine on such hardware in my experience. It depends on your applications, of course. Available flash is from 3

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread uhmgawa
On 08/28/2017 08:46 AM, W. Martin Borgert wrote: > Quoting uhmgawa : >> We probably should be leveraging a cross built embedded class distro which >> would place us in that mainstream and solve many of our logistical problems. > > As long as you have enough flash memory (some hundreds of MiB) and R

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread W. Martin Borgert
Quoting uhmgawa : We probably should be leveraging a cross built embedded class distro which would place us in that mainstream and solve many of our logistical problems. As long as you have enough flash memory (some hundreds of MiB) and RAM (at least 64 MiB, better 128 MiB), Debian runs fine on

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread uhmgawa
On 08/27/2017 07:36 PM, W. Martin Borgert wrote: > On 2017-08-28 06:53, Paul Wise wrote: >> On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote: >> >>> However, I think armel is time to transit to v5. >> As someone who can no longer run Debian stable on his MIPS device due >> to the CPU requiremen

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread Mark Morgan Lloyd
On 28/08/17 09:30, John Paul Adrian Glaubitz wrote: On 08/28/2017 12:53 AM, Paul Wise wrote: OTOH the only relevant hardware for armel these days seems to be RPi, so why not make armel into armhfv6 instead? Aren't most RPi users running Raspian anyway which is armhf with -march set to ARMv6? B

Re: ARM Ports BoF: armel in buster

2017-08-28 Thread John Paul Adrian Glaubitz
On 08/28/2017 12:53 AM, Paul Wise wrote: > OTOH the only relevant hardware for armel these days seems > to be RPi, so why not make armel into armhfv6 instead? Aren't most RPi users running Raspian anyway which is armhf with -march set to ARMv6? Bumping armel from soft-fp to ARMv6 hard-fp doesn't s

Re: ARM Ports BoF: armel in buster

2017-08-27 Thread W. Martin Borgert
On 2017-08-28 06:53, Paul Wise wrote: > On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote: > > > However, I think armel is time to transit to v5. > > As someone who can no longer run Debian stable on his MIPS device due > to the CPU requirements bump in stretch, I'm not sure that bumping CPU > r

Re: ARM Ports BoF: armel in buster

2017-08-27 Thread Paul Wise
On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote: > However, I think armel is time to transit to v5. As someone who can no longer run Debian stable on his MIPS device due to the CPU requirements bump in stretch, I'm not sure that bumping CPU requirements is a good idea in general. If there ar

Re: ARM Ports BoF: armel in buster

2017-08-27 Thread Roger Shimizu
On Fri, Aug 18, 2017 at 5:22 AM, John Paul Adrian Glaubitz wrote: > On 08/17/2017 08:49 PM, Philippe Clérié wrote: >> If none of the curent armel porters want to continue working on armel >> for buster that is OK, but dropping armel from testing now would result >> in additional work later for re-

Re: ARM Ports BoF: armel in buster

2017-08-17 Thread Aaro Koskinen
Hi, On Fri, Aug 11, 2017 at 03:04:26PM +0300, Adrian Bunk wrote: > With plenty of v6 Raspberry Pi Zero still being sold today there's > plenty of new v6 hardware available, and Debian should continue to > offer an own root filesystem for such hardware. +1 > Regarding the point that v4 is no lon

Re: ARM Ports BoF: armel in buster

2017-08-17 Thread John Paul Adrian Glaubitz
On 08/17/2017 08:49 PM, Philippe Clérié wrote: > If none of the curent armel porters want to continue working on armel > for buster that is OK, but dropping armel from testing now would result > in additional work later for re-adding it. Roger Shimizu and me are interested in keeping this port as

Re: ARM Ports BoF: armel in buster

2017-08-17 Thread Philippe Clérié
GOn 08/11/2017 08:04 AM, Adrian Bunk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, since I am not in Montréal, I am sending my participation by email: Since Debian dropping popular ports is nothing I consider good for Debian, I hereby step up as armel porter for buster. If none o

Re: ARM Ports BoF: armel in buster

2017-08-11 Thread Wookey
On 2017-08-11 15:04 +0300, Adrian Bunk wrote: > If none of the curent armel porters want to continue working on armel > for buster that is OK, I still have v5 hardware running my house and thus am keen to see it maintained. And it's not simple to upgrade to a new box as it's got heating-control h

ARM Ports BoF: armel in buster

2017-08-11 Thread Adrian Bunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, since I am not in Montréal, I am sending my participation by email: Since Debian dropping popular ports is nothing I consider good for Debian, I hereby step up as armel porter for buster. If none of the curent armel porters want to continue w

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-21 Thread Christoph Biedl
[ Sorry, that fell off screen ] Roger Shimizu wrote... > [CC Vagrant, u-boot pkg maintainer] > > On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl > wrote: > > Paul Wise wrote... > >> > >> Is it possible to put a bootloader like u-boot in the flash partitions > >> and have it load the Linux ker

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-20 Thread Christoph Biedl
Lennart Sorensen wrote... > I actually highly doubt there are that many armv7 boxes running armel. > armhf was a nice performance improvement and worth the hassle to reinstall > if you had such a box in the first place. I think most armel systems > are probably armv5, often the marvell chips. No

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-20 Thread Wouter Verhelst
On Sat, Dec 17, 2016 at 08:15:15PM +0800, Paul Wise wrote: > On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote: > > > Yes, but that still says: > > Ack. > > > I think a proper procedure should involve a script that: > > > > - is packaged in Debian; > > Ack. > > > - checks whether the h

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-18 Thread Paul Wise
On Sun, Dec 18, 2016 at 11:22 PM, Roger Shimizu wrote: > Is there any way to simplify? Remove the obsolete armel binaries where they occur and then mark the packages as NFU on armel: https://wiki.debian.org/ftpmaster_Removals https://wiki.debian.org/PackagesArchSpecific -- bye, pabs https://w

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-18 Thread Roger Shimizu
On Sat, Dec 10, 2016 at 12:22 PM, Wookey wrote: > > We can do poor-mans partial arch by just being fairly agressive about > disabling armel for packages that are broken or not suitable. Not very > clever or efficient, but it is easy to do and requires no infra or > tooling changes at all. So long

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-17 Thread Paul Wise
On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote: > Yes, but that still says: Ack. > I think a proper procedure should involve a script that: > > - is packaged in Debian; Ack. > - checks whether the hardware it's running on has all the hardware >   requirements for the new architectur

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-17 Thread Wouter Verhelst
On Thu, Dec 15, 2016 at 11:19:34AM +0800, Paul Wise wrote: > On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote: > > > One way in which the need to keep armel around would be reduced is if we > > could somehow upgrade from armel machines to armhf ones, without > > requiring a reinstall. > > T

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-16 Thread Vagrant Cascadian
On 2016-12-16, Roger Shimizu wrote: > On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl > wrote: >>> Is it possible to put a bootloader like u-boot in the flash partitions >>> and have it load the Linux kernel and initrd from elsewhere? There's no technical reason this wouldn't be possible, just

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-16 Thread Roger Shimizu
[CC Vagrant, u-boot pkg maintainer] On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl wrote: > Paul Wise wrote... >> >> Is it possible to put a bootloader like u-boot in the flash partitions >> and have it load the Linux kernel and initrd from elsewhere? > > That how I've been running my Dockstar

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-14 Thread Paul Wise
On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote: > One way in which the need to keep armel around would be reduced is if we > could somehow upgrade from armel machines to armhf ones, without > requiring a reinstall. There is a script for that here: https://wiki.debian.org/CrossGrading --

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-14 Thread Wouter Verhelst
On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote: [...asking for armel to be retained...] One way in which the need to keep armel around would be reduced is if we could somehow upgrade from armel machines to armhf ones, without requiring a reinstall. After all, armel has been around

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-14 Thread Lennart Sorensen
On Wed, Dec 14, 2016 at 06:40:22PM +0100, Wouter Verhelst wrote: > On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote: > [...asking for armel to be retained...] > > One way in which the need to keep armel around would be reduced is if we > could somehow upgrade from armel machines to ar

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-13 Thread Kurt Roeckx
On Wed, Dec 07, 2016 at 03:53:31PM +, Steve McIntyre wrote: > AFAIK there are potentially still similar problems with ARMv5 - lack > of architcture-defined barrier primitives for C++11 atomics to > work. (I'd love to be corrected on this if people know better!) This > is one of the key points h

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-12 Thread Timo Jyrinki
2016-12-09 0:12 GMT+02:00 Christoph Biedl : > Same here. My Dockstars (orion5x/kirkwood) still work like a charm and > it gives a bad feeling having to trash them some day just because > there's no support any more. > > On the other hand, they face another problem I guess is typical for > that gene

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-09 Thread Wookey
On 2016-12-07 15:53 +, Steve McIntyre wrote: > On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote: > >I'm ARM porter on armel/marvell (orion5x/kirkwood). > >Stretch will be frozen and released soon, which makes me bit depressed, > >because it means armel will be dropped out of unst

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-09 Thread Ben Hutchings
On Fri, 2016-12-09 at 22:14 +0900, Roger Shimizu wrote: > On Fri, 09 Dec 2016 00:53:17 + > > Ben Hutchings wrote: > > > Also, dedicated tiny flash partitions for the kernel and initrd.  I > > wouldn't be surprised to be find that by the time we want to release > > buster we can't build a usef

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-09 Thread Roger Shimizu
On Fri, 09 Dec 2016 00:53:17 + Ben Hutchings wrote: > Also, dedicated tiny flash partitions for the kernel and initrd. I > wouldn't be surprised to be find that by the time we want to release > buster we can't build a useful kernel that fits into the 2 MB partition > that most of these devic

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-08 Thread Christoph Biedl
Roger Shimizu wrote... > I'm ARM porter on armel/marvell (orion5x/kirkwood). > Stretch will be frozen and released soon, which makes me bit depressed, > because it means armel will be dropped out of unstable/testing as the > conclusion of Cape Town BoF. Same here. My Dockstars (orion5x/kirkwood

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-07 Thread Steve McIntyre
x27;s a quick summary of what was discussed at the ARM >> ports BoF session in Cape Town. > >Thanks for the summary! > >I'm ARM porter on armel/marvell (orion5x/kirkwood). >Stretch will be frozen and released soon, which makes me bit depressed, >because it means armel will

armel after Stretch (was: Summary of the ARM ports BoF at DC16)

2016-12-07 Thread Roger Shimizu
[ intentionally keep d-d CCed ] On Fri, 22 Jul 2016 02:36:05 +0100 Steve McIntyre wrote: > [ Please note the cross-post and Reply-To ] > > Hi folks, > > As promised, here's a quick summary of what was discussed at the ARM > ports BoF session in Cape Town. Thanks fo

Re: Summary of the ARM ports BoF at DC16

2016-08-11 Thread Steve McIntyre
On Thu, Aug 11, 2016 at 11:47:12AM +, Riku Voipio wrote: >On Fri, Jul 22, 2016 at 02:36:05AM +0100, Steve McIntyre wrote: >> armhf >> = >> Current port, first released with Wheezy. Due to cross-distro effort, >> this setup (ARMv7 EABI using VFPv3D-16) is the default supported >> 32-bit ARM

Re: Summary of the ARM ports BoF at DC16

2016-08-11 Thread Riku Voipio
On Fri, Jul 22, 2016 at 02:36:05AM +0100, Steve McIntyre wrote: > armhf > = > Current port, first released with Wheezy. Due to cross-distro effort, > this setup (ARMv7 EABI using VFPv3D-16) is the default supported > 32-bit ARM architecture in all distros now. We've got a couple of > kernel var

Re: ARM64 (was: Summary of the ARM ports BoF at DC16)

2016-07-27 Thread Wookey
On 2016-07-27 00:53 -0400, Jeffrey Walton wrote: > >> The Mustang board is a nice test platform because its an early ARMv8 > >> board. While its ARMv8, it lacks CRC and Crypto extensions. > > > > That's interesting. Having almost given up on any AMD ARM > > hardware ever appearing, I've been consi

Re: ARM64 (was: Summary of the ARM ports BoF at DC16)

2016-07-26 Thread Jeffrey Walton
>> The Mustang board is a nice test platform because its an early ARMv8 >> board. While its ARMv8, it lacks CRC and Crypto extensions. > > That's interesting. Having almost given up on any AMD ARM > hardware ever appearing, I've been considering getting a > Gigabyte MP30-AR0 (which I thought for a

Re: Summary of the ARM ports BoF at DC16

2016-07-24 Thread Sune Vuorela
On 2016-07-22, Steve McIntyre wrote: > is the lack of direct support for C++11 atomics - it's possible to use > a kernel helper to cover for this lack, but performance will be > terrible. This is going to be a real problem for Qt in the very near future. A requirement for qt 5.7 is a c++11 compli

Re: ARM64 (was: Summary of the ARM ports BoF at DC16)

2016-07-24 Thread Wookey
On 2016-07-23 18:46 +, Phil Endecott wrote: > > > Affordable, usable machines are available now, e.g. the Cello > > Is the Cello actually available? 96boards is still saying "pre-order". I have seen one, but that was '1st batch'. I don't know current status, but yes I guess it's still under

Re: ARM64 (was: Summary of the ARM ports BoF at DC16)

2016-07-23 Thread Phil Endecott
> > Affordable, usable machines are available now, e.g. the Cello Is the Cello actually available? 96boards is still saying "pre-order". > There are three other ARM64 gadgets worth mentioning... And the ODROID-C2. (Can someone add that to the list at https://wiki.debian.org/Arm64Port#Hardwar

Re: Summary of the ARM ports BoF at DC16

2016-07-23 Thread Paul Wise
On Fri, Jul 22, 2016 at 9:36 AM, Steve McIntyre wrote: > armel > = > > armel is the longest-running of our current ARM ports in Debian, > starting in 2007. It's starting to become difficult to support. Debian > is the only common distro still supporting ARMv4t. I n

Re: Summary of the ARM ports BoF at DC16

2016-07-22 Thread peter green
On 22/07/16 02:36, Steve McIntyre wrote: Affordable, usable machines are available now, e.g. the Cello Does anyone know what is going on with this. Have boards actually started shipping?

Re: ARM64 (was: Summary of the ARM ports BoF at DC16)

2016-07-22 Thread Marcin Juszkiewicz
W dniu 22.07.2016 o 04:02, Jeffrey Walton pisze: There are three other ARM64 gadgets worth mentioning... * Raspberry Pi 3 Model B (http://www.amazon.com/dp/B01CD5VC92), $38 USD This device has armv8 core but no support for running Linux in 64-bit mode. The Mustang board is a nice test pla

ARM64 (was: Summary of the ARM ports BoF at DC16)

2016-07-21 Thread Jeffrey Walton
> arm64 > = > > Most recent ARM port. All looking good now - we've been mostly able to > move on from Juno development platforms to real server hardware > now. We're using some APM Mustang machines and an AMD Seattle box > hosted by ARM and Linaro at the moment, and even real arm64 server > mac

Summary of the ARM ports BoF at DC16

2016-07-21 Thread Steve McIntyre
[ Please note the cross-post and Reply-To ] Hi folks, As promised, here's a quick summary of what was discussed at the ARM ports BoF session in Cape Town. This year, unfortunately the session did not have video so I can't link to it. I've taken a copy of the Gobby notes f

[cont...@debconf.org: DebConf - talk scheduled: Arm Ports BoF]

2016-06-27 Thread Steve McIntyre
- Forwarded message from cont...@debconf.org - From: cont...@debconf.org Date: Wed, 22 Jun 2016 20:47:07 - To: 93...@debian.org Subject: DebConf - talk scheduled: Arm Ports BoF X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on cheddar.halon.org.uk X-Spam-Level: X-Spam-Status

Re: Summary of the ARM ports BoF at DC15

2015-09-28 Thread Paul Wise
On Wed, Sep 16, 2015 at 9:02 PM, Christoph Biedl wrote: > So add me to your list. I run four Seagate DockStar (v5) and two > Raspberry Pi (v6, first generation). Although bout the latter, I was > hoping for a "arm6hf" port and used armel until then. But with more > recent Pi models AFAIK being arm

Re: Summary of the ARM ports BoF at DC15

2015-09-16 Thread Christoph Biedl
Steve McIntyre wrote... > First released with Lenny, supports ARMv4t & later. QNAS etc. kirkwood > & some freedombox. Toolchain and kernel support upstream are probably > never going away due to the massive number of simple ARM devices still > being made and shipped, however... Quite recently I s

Re: Summary of the ARM ports BoF at DC15

2015-09-14 Thread Rob J. Epping
On September 14, 2015 12:45:03 PM GMT+02:00, JM wrote: >On Fri, Sep 11, 2015 at 5:58 PM, Steve McIntyre >wrote: >> >> Summary: if people care about armel for Stretch, they should make >> noise NOW and convince people it's needed and can/should be supported >> in future. >> > >I'm running Debian o

Re: Summary of the ARM ports BoF at DC15

2015-09-14 Thread Philippe Clérié
This is microATX with 2 Gbe, 210Gbe and 4 SATA III ports. : http://www.eteknix.com/latest-gigabyte-microatx-motherboard-arrives-with-octo-core-armv8-soc/ which is actually on-sale: http://www.ldlc.com/fiche/PB00191584.html But it's server kit so it's 950 EUR. Wookey Good to know that there

Re: Summary of the ARM ports BoF at DC15

2015-09-14 Thread Ian Campbell
On Mon, 2015-09-14 at 15:31 +0200, Paul Wise wrote: > On Mon, Sep 14, 2015 at 2:29 PM, Lucy Wayland wrote: > > On Sat, Sep 12, 2015 at 03:55:38PM +0100, Ian Campbell wrote: > > > On Fri, 2015-09-11 at 16:58 +0100, Steve McIntyre wrote: > > > Does this issue go away entirely if we move from a v4t to

Re: Summary of the ARM ports BoF at DC15

2015-09-14 Thread Edmund Grimley Evans
> SWP and SWPB - these were deprecated in ARMv7 but absent in ARMv8. If I am not mistaken, these were deprecated in ARMv6 already, and they are optional in ARMv7: http://www.google.com/search?q=swp+swpb+armv6+armv7 The QNAP things that people seem keen not to lose support for are ARMv5TE.

Re: Summary of the ARM ports BoF at DC15

2015-09-14 Thread Wookey
+++ Paul Wise [2015-09-14 15:31 +0200]: > On Mon, Sep 14, 2015 at 2:29 PM, Lucy Wayland wrote: > > On Sat, Sep 12, 2015 at 03:55:38PM +0100, Ian Campbell wrote: > >> On Fri, 2015-09-11 at 16:58 +0100, Steve McIntyre wrote: > >> Does this issue go away entirely if we move from a v4t to v5 base, or >

Re: Summary of the ARM ports BoF at DC15

2015-09-14 Thread Paul Wise
On Mon, Sep 14, 2015 at 2:29 PM, Lucy Wayland wrote: > On Sat, Sep 12, 2015 at 03:55:38PM +0100, Ian Campbell wrote: >> On Fri, 2015-09-11 at 16:58 +0100, Steve McIntyre wrote: >> Does this issue go away entirely if we move from a v4t to v5 base, or >> are there also v5 instructions which are (pote

  1   2   >