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