Re: ARM Ports BoF: armel in buster

[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 we can make it even better :).

+1

Re: ARM Ports BoF: armel in buster

[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.

Yes, but a handful of people don't justify introducing a massive
compatibility breakage in the armel port.  I think the current
situation is optimal as is, which is:

 * the toolchain on armel has currently no known issues
 * over 12200 packages are up to date (more than mips*)
 * there are still lots of users of ARMv4T and ARMv5 hardware
 * there are enough crazy people with too much time like Adrian,
   Roger and me who are willing to fix stuff
 * I am upstreaming as many OpenJDK patches as possible and OpenJDK
   Zero is being improved upstream to keep Matthias happy
 * there is enough beer in the fridge

So, currently all is good with armel and we can go back to
discussing how we can make it even better :).

Good night,

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: ARM Ports BoF: armel in buster

[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 (in case of RPi 1 or Zero).
I imagine, you know (and share) reasons to prefer Debian.

Cheers


signature.asc
Description: PGP signature

Re: ARM Ports BoF: armel in buster

[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 elsewhere, but I am not aware of any serious
> current problems in the toolchain.

Right, my "borrowed time" comment was primarily wrt the v4 baseline we
are currently targeting, since that could break at any time and since
it is already deprecated upstream may not be all that interested. I've
no particular insight into when v5 will face the same situation but as
you say it doesn't appear to be of immediate concern for Buster.

All this seems like a pretty good argument for Roger's original
proposal[0] to move to a v5t baseline which is what started this
subthread.

Ian.

[0] 

Re: ARM Ports BoF: armel in buster

[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 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 bumping it could be a good idea.
> 
> IIRC some important part of the toolchain (gcc?) has bumped their
> baseline to v5 quite a while back, so we are already living on borrowed
> time wrt toolchain support. (This was from an ARM BoF several debconf's
> ago, I can't seem to find a reference right now though).
>...

In 2016 gcc 6 has deprecated (not yet removed) ARM prior to ARMv4t,[1]
which matches the armel baseline.

In 2017 gcc 7 has deprecated the non-Thumb ARMv5 variants
"which have no known implementations".[2]

What matters for buster is gcc 8, and there is no current deprecation
in gcc that would affect the armel port.

armel is a port on borrowed time since it supports old hardware
no longer supported elsewhere, but I am not aware of any serious
current problems in the toolchain.

> Ian.

cu
Adrian

[1] https://gcc.gnu.org/gcc-6/changes.html
[2] https://gcc.gnu.org/gcc-7/changes.html

-- 

   "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: ARM Ports BoF: armel in buster

[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.

> bye,
> pabs

cu
Adrian

-- 

   "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: ARM Ports BoF: armel in buster

[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 experience. It depends on your applications, of course.
> > 
> > Available flash is from 32~64MB depending on platform.  So manual subset
> > of the distro id required and where recurring the effort enters the
> > picture.
> OK, then Debian is probably not an option. I doubt, that one can strip down
> Debian 9 to 32 MiB... Has anybody tried?
Have you looked at the now remerged OpenWRT/LEDE?  They support
lots of little systems like this, and I think several are armel.

David
> 
> >> Debian is supposed to be the "universal operating system". I.e. it is for
> >> server + workstation + embedded + whatever. This is different from most
> >> other Linux distributions.
> > 
> > I applaud that goal.  But the approach of using a native arch build
> > vehicle
> > for the distro also introduces complication for embedded class
> > development.
> > Not insurmountable but additional compared to the cross-build approach
> > typical of embedded linux distros.
> 
> The native build requirement is only affecting Debian itself, not its users
> (people deriving the distribution for their needs or building appliances).
> In my company, we always cross-build our .deb packages for ARM. We do this
> also, if we need to recompile official Debian packages (local backports or
> patched packages). We don't have any armel hardware, that would be fun to
> build packages with.

Re: ARM Ports BoF: armel in buster

[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 standard sbuild build process is generic enough
to be used for all kinds of Debian packages. After all, sbuild is the
standard tool that we're using on the buildds.

I think "specialized" here just means what you're used to using.

>> Or just create chroots for the architectures you need with qemu-debootstrap. 
>> No
>> need to use any fancy containerization fuzz. All you ever needed was a chroot
>> and sbuild, no need for a bigger software stack written in Golang on top of 
>> that.
> 
> No Go/docker here, nor qemu, just systemd-nspawn :~)

qemu-debootstrap is just used for creating the chroot. You cannot create
the chroot on amd64 without qemu because you cannot run the second stage
of debootstrap after running debootstrap --foreign --arch=armel.

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: ARM Ports BoF: armel in buster

[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 variable is used for.
> > Maybe it is not needed.
> 
> You shouldn't be building packages like that if you want to guarantee that 
> they
> will actually work in the target environment since your approach is not 
> building
> in a clean environment. Also, this way you will have to install all build 
> dependencies
> yourself.

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.

> > Yes, we develop for squeeze in a squeeze chroot or VM, and for stretch
> > in a stretch container. Multi-arch makes things easy on stretch, that
> > were difficult on squeeze (dpkg-cross, apt-cross, ...).
>
> Or just create chroots for the architectures you need with qemu-debootstrap. 
> No
> need to use any fancy containerization fuzz. All you ever needed was a chroot
> and sbuild, no need for a bigger software stack written in Golang on top of 
> that.

No Go/docker here, nor qemu, just systemd-nspawn :~)

Re: ARM Ports BoF: armel in buster

[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 bumping it could be a good idea.
> 
> IIRC some important part of the toolchain (gcc?) has bumped their
> baseline to v5 quite a while back, so we are already living on borrowed
> time wrt toolchain support. (This was from an ARM BoF several debconf's
> ago, I can't seem to find a reference right now though).

I don't think that's the case. Even gcc-8 still builds perfectly fine and
so does LLVM. There had been issues with std::future on armel for a long
time due to the lack of atomics in hardware on ARM prior to v7 but this
issue has been resolved in a different way upstream now.

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: ARM Ports BoF: armel in buster

[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 bumping
> CPU
> requirements is a good idea in general. If there are actual benefits
> to v5 as the default then bumping it could be a good idea.

IIRC some important part of the toolchain (gcc?) has bumped their
baseline to v5 quite a while back, so we are already living on borrowed
time wrt toolchain support. (This was from an ARM BoF several debconf's
ago, I can't seem to find a reference right now though).

>  OTOH the
> only relevant hardware for armel these days seems to be RPi, so why
> not make armel into armhfv6 instead?

There are a large number of kirkwood (v5) based NAS and related, e.g.
*plug systems in the wild which are the ones we actually support in
practice today (with the marvell kernel flavour, which I think is the
last one standing in Stretch). Roger enumerated the h/w we have
supported in the past and which we support today in the last few
paragraphs of


Ian.

Re: ARM Ports BoF: armel in buster

[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 step in that direction is Helmut Grohne's rebootstrap [1].

> 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 variable is used for.
> Maybe it is not needed.

You shouldn't be building packages like that if you want to guarantee that they
will actually work in the target environment since your approach is not building
in a clean environment. Also, this way you will have to install all build 
dependencies
yourself.

The proper way is simply to specify the target architecture with "--host" when
using sbuild:

sbuild --host=armel -d stretch --no-arch-all $PACKAGE.dsc

That's it.

Minor problem is that at the moment the necessary cross-build-essential packages
aren't built for all architectures but only for the major ones. But adding the
other architectures is a matter of filing a bug report against 
src:build-essential
and having Matthias upload an updated version. All arm* architectures are 
already
included in any case.

>> At least doing so sidesteps a number of issues including agreement of dynamic
>> library content between the native/cross toolchains such that mixing the 
>> distro
>> and application bits happens under effectively the same runtime libraries.
> 
> Yes, we develop for squeeze in a squeeze chroot or VM, and for stretch
> in a stretch container. Multi-arch makes things easy on stretch, that
> were difficult on squeeze (dpkg-cross, apt-cross, ...).

Or just create chroots for the architectures you need with qemu-debootstrap. No
need to use any fancy containerization fuzz. All you ever needed was a chroot
and sbuild, no need for a bigger software stack written in Golang on top of 
that.

Adrian

> [1] https://jenkins.debian.net/view/rebootstrap/

-- 
 .''`.  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: ARM Ports BoF: armel in buster

[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 more using squashfs, resulting in an acceptable  
image for

even 24MB flash.


This is impressing!


Is cross build generally supported for Debian?  My impression was that it was
not and a native arch build vehicle was requires such that host == target.


AFAIK, there is no policy requiring that packages can be cross-build.
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 variable is used for.
Maybe it is not needed.


At least doing so sidesteps a number of issues including agreement of dynamic
library content between the native/cross toolchains such that mixing  
the distro

and application bits happens under effectively the same runtime libraries.


Yes, we develop for squeeze in a squeeze chroot or VM, and for stretch
in a stretch container. Multi-arch makes things easy on stretch, that
were difficult on squeeze (dpkg-cross, apt-cross, ...).

Re: ARM Ports BoF: armel in buster

[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 depends on your applications, of course.
>>
>> Available flash is from 32~64MB depending on platform.  So manual subset
>> of the distro id required and where recurring the effort enters the picture.
>
> OK, then Debian is probably not an option. I doubt, that one can strip down
> Debian 9 to 32 MiB... Has anybody tried?

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 more using squashfs, resulting in an acceptable image for
even 24MB flash.

>
>>> Debian is supposed to be the "universal operating system". I.e. it is for
>>> server + workstation + embedded + whatever. This is different from most
>>> other Linux distributions.
>>
>> I applaud that goal.  But the approach of using a native arch build vehicle
>> for the distro also introduces complication for embedded class development.
>> Not insurmountable but additional compared to the cross-build approach
>> typical of embedded linux distros.
>
> The native build requirement is only affecting Debian itself, not its users
> (people deriving the distribution for their needs or building appliances).
> In my company, we always cross-build our .deb packages for ARM. We do this
> also, if we need to recompile official Debian packages (local backports or
> patched packages). We don't have any armel hardware, that would be fun to
> build packages with.

Is cross build generally supported for Debian?  My impression was that it was
not and a native arch build vehicle was requires such that host == target.  If
cross builds were actively supported by the project for even a subset of distro
content, that would have simplified matters in our case.

Another rub mixing a native-built distro and cross built application is the 
toolchain
which must be generated from the same source for both native and cross versions.
At least doing so sidesteps a number of issues including agreement of dynamic
library content between the native/cross toolchains such that mixing the distro
and application bits happens under effectively the same runtime libraries.

Re: ARM Ports BoF: armel in buster

[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 32~64MB depending on platform.  So manual subset
of the distro id required and where recurring the effort enters the picture.


OK, then Debian is probably not an option. I doubt, that one can strip down
Debian 9 to 32 MiB... Has anybody tried?


Debian is supposed to be the "universal operating system". I.e. it is for
server + workstation + embedded + whatever. This is different from most
other Linux distributions.


I applaud that goal.  But the approach of using a native arch build vehicle
for the distro also introduces complication for embedded class development.
Not insurmountable but additional compared to the cross-build approach
typical of embedded linux distros.


The native build requirement is only affecting Debian itself, not its users
(people deriving the distribution for their needs or building appliances).
In my company, we always cross-build our .deb packages for ARM. We do this
also, if we need to recompile official Debian packages (local backports or
patched packages). We don't have any armel hardware, that would be fun to
build packages with.

Re: ARM Ports BoF: armel in buster

[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 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 32~64MB depending on platform.  So manual subset
of the distro id required and where recurring the effort enters the picture.

>
> Could you tell us something about your hardware and application?
>

ARM926EJ-S SoC with the usual assortment of peripherals, SPI flash for
u-boot/kernel/userland 32~64MB in current product, 256~512MB DRAM.
Pretty typical for a legacy arm32 embedded linux platform.

The footprint complication primarily arises from the constraint to use SPI flash
and its associated cost / minimal capacity.

>> But support of that architecture
>> was likely never more than a coincidental goal for non-embedded
>> server/workstation distros.
>
> Debian is supposed to be the "universal operating system". I.e. it is for
> server + workstation + embedded + whatever. This is different from most
> other Linux distributions.

I applaud that goal.  But the approach of using a native arch build vehicle
for the distro also introduces complication for embedded class development.
Not insurmountable but additional compared to the cross-build approach
typical of embedded linux distros.

Note there was no technical motivation moving from a DEB to RPM based
distro.  But rather a special case where leverage of preexisting internal RPM
build infrastructure is possible rather than dealing with that additional 
infrastructure
and (self-inflicted) legal process associated the Debian option, or moreover the
largely "drop in" use of Yocto/OE.

Re: ARM Ports BoF: armel in buster

[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 such hardware
in my experience. It depends on your applications, of course.

Could you tell us something about your hardware and application?


But support of that architecture
was likely never more than a coincidental goal for non-embedded
server/workstation distros.


Debian is supposed to be the "universal operating system". I.e. it is for
server + workstation + embedded + whatever. This is different from most
other Linux distributions.

Re: ARM Ports BoF: armel in buster

[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 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 bumping it could be a good idea. OTOH the
>> only relevant hardware for armel these days seems to be RPi, so why
>> not make armel into armhfv6 instead?
> The most relevant hardware is probably RPi 1 and RPi Zero.
> But there are also many ARM9EJ-S based devices used in
> industrial applications (hardware with long life cycles).
> If I'm not mistaken this is v5 without FP unit, right?

Yes it is.

This conversation caught my eye as we've been leveraging Debian for years
to create a custom armel userland for an arm926ej-s core SoC.  Internal
licensing politics have us switching to an RPM based distro where the armel
situation is much worse, with ARMv5 having been abandoned after F18.
So we needed to reach quite far back for a binary distro to get ourselves
bootstrapped and even then we're building packages which AFAIK aren't
seeing significant (or any) build and soak elsewhere.  In doing so we're
conceptually taking on a self-support burden as ARMv7 is the only mainstream
arm32 ABI still supported by the project.

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.
The underlying issue in all of this being server/workstation class distros
evolving away from what was then more mainstream arm32 platforms but
now has been left to the embedded linux world.  The "long life cycles" for
this arm32 application area is quite true.  But support of that architecture
was likely never more than a coincidental goal for non-embedded
server/workstation distros.

Re: ARM Ports BoF: armel in buster

[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? Bumping armel from soft-fp to ARMv6 hard-fp doesn't seem to
make much sense to me though.


For the record, we're running pukka Debian on top of the Raspbian Jessie 
kernel etc. on roughly a dozen RPis here.


We found that to be the preferable combination since we needed KDE and 
found that it didn't play nicely with the Raspbian display subsystem, 
although we might reconsider that now that Raspbian "Stretch" is available.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

Re: ARM Ports BoF: armel in buster

[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 seem to
make much sense to me though.

I mean, if you want modern ARM32 support, you need to go to ARMv7 anyway
because that's what most upstream seem assume for native code generator
support (GHC, OpenJDK-9, ...) and other performance benefits these days,
simply because ARMv7 brings lots of improvements to the instruction set,
in particular proper support for atomics.

Again, armel is currently perfectly usable and stable - *as is* - so I
don't see why that topic is brought up so often for discussion. I could
understand the discussion if armel was in a similar situation as m68k
or sh4 which still need lots of work which is why they are just around
10,500 packages being up-to-date. armel, OTOH, has over 12,200 packages
up-to-date, that's almost the same amount of packages as arm64 or ppc64el.

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: ARM Ports BoF: armel in buster

[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
> requirements is a good idea in general. If there are actual benefits
> to v5 as the default then bumping it could be a good idea. OTOH the
> only relevant hardware for armel these days seems to be RPi, so why
> not make armel into armhfv6 instead?

The most relevant hardware is probably RPi 1 and RPi Zero.
But there are also many ARM9EJ-S based devices used in
industrial applications (hardware with long life cycles).
If I'm not mistaken this is v5 without FP unit, right?

Re: ARM Ports BoF: armel in buster

[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 are actual benefits
to v5 as the default then bumping it could be a good idea. OTOH the
only relevant hardware for armel these days seems to be RPi, so why
not make armel into armhfv6 instead?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: ARM Ports BoF: armel in buster

[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-adding it.
>
> Roger Shimizu and me are interested in keeping this port as well. That's
> why I am happy to help wherever I can.

Yes, I still have a few armel/marvell devices.
So I want my devices are working towards buster release.

>> 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.
>
> Yep. That's my main point as well. Technology has come to a point where
> even rather old hardware is still very useful for small embedded
> applications. The appeal comes mainly from the very low costs as well
> as low power consumption. Also, I would argue that especially in third
> world countries, old ARM hardware is still widely used.
>
>> And for users with v5 hardware there are not many alternatives.
>>
>> This year I have been one of the people who continuously follow
>> FTBFS on the buildds for all release architectures and report bugs.
>> armel is not in a bad shape, basically at the level of armhf.
>
> I agree. With over 12200 binary packages being up-to-date, I don't see
> any particular problems. I recently fixed openjdk-9 on armel and will
> fix anything that people throw at me ;).

I'm also working on kernel related issues on armel.
I just fixed #870185 this week.

On Fri, Aug 18, 2017 at 7:26 AM, Aaro Koskinen  wrote:
> 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 longer used anywhere else, there are
>> two possibilities for raising the baseline that could be considered for
>> buster:
>>
>> v4 -> v5
>> I am not sure any v4 hardware with a kernel recent enough for buster
>> exists, but the benefits of the baseline increase are also unclear.
>
> There are at least OMAP1 boards that are v4t (ARM925T) and work fine
> with the current mainline kernel.

However, I think armel is time to transit to v5.

Debian ever supported iop32x, ixp4xx, kirkwood, mv78xx0, orion5x, and
versatile as armel flavour. In 2014, support for iop32x, ixp4xx, and mv78xx0
were dropped by Debian kernel, and in 2016, versatile was dropped. [0]
With the merging of orion5x and kirkwood, now Debian supports marvell
as the only one flavour in armel.

[0] 
https://anonscm.debian.org/cgit/kernel/linux.git/log/debian/config/armel/defines

So I don't see any reason we should keep armv4t.
Just like "i386" can drop i386/i486/i586 [1], armel can also drop armv4t and
support starting from armv5 smoothly.

[1] https://lists.debian.org/debian-devel-announce/2016/05/msg1.html

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Re: ARM Ports BoF: armel in buster

[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 longer used anywhere else, there are 
> two possibilities for raising the baseline that could be considered for 
> buster:
> 
> v4 -> v5
> I am not sure any v4 hardware with a kernel recent enough for buster
> exists, but the benefits of the baseline increase are also unclear.

There are at least OMAP1 boards that are v4t (ARM925T) and work fine
with the current mainline kernel.

A.

Re: ARM Ports BoF: armel in buster

[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 well. That's
why I am happy to help wherever I can.

> 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.

Yep. That's my main point as well. Technology has come to a point where
even rather old hardware is still very useful for small embedded
applications. The appeal comes mainly from the very low costs as well
as low power consumption. Also, I would argue that especially in third
world countries, old ARM hardware is still widely used.

> And for users with v5 hardware there are not many alternatives.
> 
> This year I have been one of the people who continuously follow
> FTBFS on the buildds for all release architectures and report bugs.
> armel is not in a bad shape, basically at the level of armhf.

I agree. With over 12200 binary packages being up-to-date, I don't see
any particular problems. I recently fixed openjdk-9 on armel and will
fix anything that people throw at me ;).

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: ARM Ports BoF: armel in buster

[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 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.

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.

And for users with v5 hardware there are not many alternatives.

This year I have been one of the people who continuously follow
FTBFS on the buildds for all release architectures and report bugs.
armel is not in a bad shape, basically at the level of armhf.

Much of the perception of armel being broken might actually just be a
perception that does feed itself.
An example for that:
Due to a recent binutils regression (#869768) hundreds of Haskell
packages FTBFS on arm64 when built with binutils from unstable.
Since this is the arm64 port noone makes a big deal of it.
Had the same regression happened on armel, I'm sure I would have
already seen an angry rant on IRC asking when the broken armel
port will finally be dropped.

Looking at the current status (as of stretch) there are only
two major issues I am aware of:

The (not security-supported) Node.js is not available on armel,
and this doesn't cause serious problems.

Half of the stretch release architectures have the problem of no Rust
even in unstable, and this will already be a problem for stretch with
the new Firefox ESR next year.

As advised by Steve I checked what known toolchain issues exist on armel,
and I found two:

#866354 - The backport of the fix for the gcc bug that caused #820535
to gcc-6 in stretch and the upstream implementation in gcc-7 ended up
having the same symbols at different versions. Now that gcc-7 is default
this is fixable with a set of uploads/binNMUs and Breaks.

#868779 - clang in unstable and stretch defaults to building for
v6 instead of v4. The combination of v6 not being affected and
clang not being used for that much made that slip into the release.
I can pinpoint the problem, but I have not yet settled on what is
the best way for fixing.

Regarding the point that v4 is no longer used anywhere else, there are
two possibilities for raising the baseline that could be considered for
buster:

v4 -> v5
I am not sure any v4 hardware with a kernel recent enough for buster
exists, but the benefits of the baseline increase are also unclear.

v4 -> v6
This would kill Debian on v5, which would not be nice.
The strongest rationale I could see would be if this would be
required for making Rust work on armel.[1]

cu
Adrian

[1] Rust has Tier 2 support for v6 and Tier 3 support for v5.
 Bringing the v5 support down to v4 looks at first sight simple,
 getting Rust working properly on v4/v5 is a challenge of unknown size.

- -- 


"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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlmNnUoACgkQiNJCh6LY
mLEDig//eWVl5OMTxpPeeN0zMp+u1cPfbza7Fe8xtkIfWkUTlS0tSSjgnwCmJSs0
Cl13pxQDEZy5YDI90wXrqFVIs3bYMTQrp6PD8PjMQnF/9KvGQYamqsID2EP4DXQr
eUlAif+aA2DbzeawgPcrJOJq6Q/BO369jAKONENwz1QbTn32FBk0ul7tBVxU4YY7
yB5Zkp5z87NrRyiewK4xkv22pOhd7M8zB4CWInIf8KWNNIWBv1iIJIHizj/6hNls
Ti3EbClP6ve8tCqBPflTJjNo6XufAEz+xGsw+lOypWt77BIt0TvmueqdYmImyTdE
0CzfuXubA7bxTUWp7AEaZ2XicugKcuVIaw6k7Ff0Be3JnV0qXEW7p698YPfX9Rtt
DCDUbNJl4sVh5rhUni6W++hh4yLkbqHhKw0yiK9wrWuOTGgmzNIaNNCxmKUDtzz5
Ta0gVVViqngQc+E1zxMl2PaemLJxvj7l1P2jRSo1dC63V/6NLxYEezm+P20FPzET
jy9h2tEjn+tqx/6NnaWq5g6zRStQ/ufBZ8tlNTqfIEoynx1p4v0JAaqDMS2EQNfJ
jxFwr0Cx2syMrG/slMf0THIGIwz2v0P1LejUi+IqSyTHOdPWbazqMZkFpUQQtj3Q
Aa78rwfoX86WHD41XS1iyvCFP34KuTKgCHTSSIc+rMN/sM01Qjg=
=xy4t
-END PGP SIGNATURE-



Great! Sounds like I'm going to keep my QNAPs for a while longer than I 
expected.


--
Philippe

--
The trouble with common sense it that it is so uncommon.

Re: ARM Ports BoF: armel in buster

[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 hardware attached. So I've not lost interest.

(It's currently still running 'arm', not 'armel', which of course is
no longer upgraded because we stopped maintaining it. It'd be nice to
have it less than 6 years out of date sometime.)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

ARM Ports BoF: armel in buster

[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 working on armel 
for buster that is OK, but dropping armel from testing now would result 
in additional work later for re-adding it.

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.

And for users with v5 hardware there are not many alternatives.

This year I have been one of the people who continuously follow
FTBFS on the buildds for all release architectures and report bugs.
armel is not in a bad shape, basically at the level of armhf.

Much of the perception of armel being broken might actually just be a 
perception that does feed itself.
An example for that:
Due to a recent binutils regression (#869768) hundreds of Haskell 
packages FTBFS on arm64 when built with binutils from unstable.
Since this is the arm64 port noone makes a big deal of it.
Had the same regression happened on armel, I'm sure I would have
already seen an angry rant on IRC asking when the broken armel
port will finally be dropped.

Looking at the current status (as of stretch) there are only
two major issues I am aware of:

The (not security-supported) Node.js is not available on armel,
and this doesn't cause serious problems.

Half of the stretch release architectures have the problem of no Rust 
even in unstable, and this will already be a problem for stretch with 
the new Firefox ESR next year.

As advised by Steve I checked what known toolchain issues exist on armel,
and I found two:

#866354 - The backport of the fix for the gcc bug that caused #820535
to gcc-6 in stretch and the upstream implementation in gcc-7 ended up 
having the same symbols at different versions. Now that gcc-7 is default 
this is fixable with a set of uploads/binNMUs and Breaks.

#868779 - clang in unstable and stretch defaults to building for
v6 instead of v4. The combination of v6 not being affected and
clang not being used for that much made that slip into the release.
I can pinpoint the problem, but I have not yet settled on what is
the best way for fixing.

Regarding the point that v4 is no longer used anywhere else, there are 
two possibilities for raising the baseline that could be considered for 
buster:

v4 -> v5
I am not sure any v4 hardware with a kernel recent enough for buster
exists, but the benefits of the baseline increase are also unclear.

v4 -> v6
This would kill Debian on v5, which would not be nice.
The strongest rationale I could see would be if this would be
required for making Rust work on armel.[1]

cu
Adrian

[1] Rust has Tier 2 support for v6 and Tier 3 support for v5.
Bringing the v5 support down to v4 looks at first sight simple,
getting Rust working properly on v4/v5 is a challenge of unknown size.

- -- 

   "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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlmNnUoACgkQiNJCh6LY
mLEDig//eWVl5OMTxpPeeN0zMp+u1cPfbza7Fe8xtkIfWkUTlS0tSSjgnwCmJSs0
Cl13pxQDEZy5YDI90wXrqFVIs3bYMTQrp6PD8PjMQnF/9KvGQYamqsID2EP4DXQr
eUlAif+aA2DbzeawgPcrJOJq6Q/BO369jAKONENwz1QbTn32FBk0ul7tBVxU4YY7
yB5Zkp5z87NrRyiewK4xkv22pOhd7M8zB4CWInIf8KWNNIWBv1iIJIHizj/6hNls
Ti3EbClP6ve8tCqBPflTJjNo6XufAEz+xGsw+lOypWt77BIt0TvmueqdYmImyTdE
0CzfuXubA7bxTUWp7AEaZ2XicugKcuVIaw6k7Ff0Be3JnV0qXEW7p698YPfX9Rtt
DCDUbNJl4sVh5rhUni6W++hh4yLkbqHhKw0yiK9wrWuOTGgmzNIaNNCxmKUDtzz5
Ta0gVVViqngQc+E1zxMl2PaemLJxvj7l1P2jRSo1dC63V/6NLxYEezm+P20FPzET
jy9h2tEjn+tqx/6NnaWq5g6zRStQ/ufBZ8tlNTqfIEoynx1p4v0JAaqDMS2EQNfJ
jxFwr0Cx2syMrG/slMf0THIGIwz2v0P1LejUi+IqSyTHOdPWbazqMZkFpUQQtj3Q
Aa78rwfoX86WHD41XS1iyvCFP34KuTKgCHTSSIc+rMN/sM01Qjg=
=xy4t
-END PGP SIGNATURE-