[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ARM Ports BoF: armel in buster

GOn 08/11/2017 08:04 AM, Adrian Bunk wrote:
Hash: SHA512


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

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]


[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



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


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

Reply to: