Subject: Can we drop armhf (armv6) after v3.12?

From: Natanael Copa <[email-masked]>
Date: Thu, 28 May 2020 10:47:48 +0200

Hi!

Can we drop the armhf architecture after 3.12 release?

It means that we will continue support armfh with 3.12 for two mor
years, but edge and next release 3.13 will be without armhf.

This means that we effectively drop support for Raspberry pi 1 and
raspberry pi zero which are armv6. This is also the hardware we have
kernel for.

The reason is that there are increasing number of issues that are not
fixed upstream. For example:
https://bugreports.qt.io/browse/QTBUG-65246

We will also need to rebuild all our 32 bit architectures from scratch
when upgrading to musl 1.2 due to time64. It requires significant
effort to do that and it would be nice to only need to do it for x86
and armv7, and drop armhf.

Are there any good reasons to why we should keep armhf?

Are there other reasons to why we should drop it?

-nc

PS. This was previously been discussed for 3.10 release:
https://lists.alpinelinux.org/~alpine/devel/%3C20190404112525.4b04fdeb%40ncopa-desktop.copa.[email-masked]%3E

---

From: Ariadne Conill <[email-masked]>
Date: Thu, 28 May 2020 11:22:50 -0600

Hello,

> raspberry pi zero which are armv6. This is also the hardware we have

I think a better way to go is to continue providing the architecture, but as a 
"community supported" architecture.  I am working on a project to incubate 
architectures that cannot be included in upstream Alpine releases, and perhaps 
we could provide armhf under that umbrella.

These architectures would be rolling release and not supported for any formal 
lifecycle, e.g. they would be edge-only, and if they break, packages are 
disabled on them until somebody has time to fix them.

> https://bugreports.qt.io/browse/QTBUG-65246

This means, for example, that we would not ship Qt on armhf unless somebody 
steps up and fixes it.

> Are there any good reasons to why we should keep armhf?

While it is a niche architecture now, I think it is worth keeping around in 
some form.  Perhaps under the "alpine ports" umbrella I discussed already.

Ariadne

---

From: Pablo Rogina <[email-masked]>
Date: Thu, 28 May 2020 15:12:18 -0300

> This means, for example, that we would not ship Qt on armhf unless somebody

In this particular example, I understand that qt5-qtdeclarative
package [1] will be affected, not just the whole set of Qt5 packages
(i.e. qt5-qtbase, the main one, should ship)

Thanks. Pablo

[1] https://pkgs.alpinelinux.org/package/v3.11/community/armhf/qt5-qtdeclarative

---

From: Oliver Smith <[email-masked]>
Date: Mon, 1 Jun 2020 08:06:53 +0200

Hey all,

FWIW, we have decided to not build postmarketOS' stable channel branch
for armhf. There are still quite some devices in postmarketOS that use
the armhf architecture, but that's mostly because armhf was available in
Alpine before armv7 and nobody switched the architecture yet.

I like Ariadne's proposal of keeping armhf around in Alpine edge as
"community supported", if that is feasible.

Thanks for keeping it supported for such a long time already.

Regards,
Oliver

---

From: [email-masked]
Date: Thu, 28 May 2020 11:19:19 +0200

Dear Natanael,

While I understand supporting many platforms has a burden,
this proposal is a bit of concern as:

- PiZeroW obsolescence is not planned until Jan 2026 at earliest
https://www.raspberrypi.org/products/raspberry-pi-zero-w/
We can expect Pi foundation & quite wide community will then
stay behind it, and provide patches, for most critical components.

- PiZero is officially supported in upstream kernel, and we’ve not
seen any obsolescence notification yet (or I missed it)

- Alpine is a platform of choice for low-ressorce devices, and PiZero
is a perfect illustration of such target.

- While I do not have shipment volume info, it is expected that it
is a pretty big chunk of such tiny SBC category

Would a path with limited support for some demanding UI framework
make it easier to consider?
Many server usecase may not require such UI frameworks.

I hope Alpine will keep armhf for few major releases.
Many thanks for consideration.

> On 28 May 2020, at 10:47, Natanael Copa <[email-masked]> wrote:
> 
> Hi!
>

---

From: [email-masked]
Date: Thu, 9 Jul 2020 11:51:20 +0200

Dear Natanael,

Have you come to a definitive conclusion on this particular matter?
Thank you for consideration and feedback.

Regards.
macmpi.

> On 28 May 2020, at 11:19, [email-masked] wrote:
> 
> Dear Natanael,
>

---

From: Natanael Copa <[email-masked]>
Date: Mon, 17 Aug 2020 12:10:07 +0200

> Thank you for consideration and feedback.

Hi, sorry late response. As Ariadne said, we will keep armhf for now,
but do it on a best effort basis. It means that if some package breaks
on armhf we will need help from upstream or other contributor to fix it
or the package will be removed from armhf repo.

-nc

> > - PiZero is officially supported in upstream kernel, and we*ve not

---

From: "Marcus Rohrmoser" <[email-masked]>
Date: Sun, 16 Aug 2020 23:29:52 +0200

armhf is really dear to me – very small devices using very few energy. Perfect for headless server tasks e.g. websites and e.g. https://l.mro.name/ (not on alpine yet).

Alpine seems IMO a perfect OS for such usecases. Be it Pi Zero or the early Pis.

Headless is IMO sufficient.

Please let's keep armhf!

Cheers,
M

---

From: Ariadne Conill <[email-masked]>
Date: Sun, 16 Aug 2020 15:31:53 -0600

Hello,

> Headless is IMO sufficient.

Don't worry, we plan to keep armhf around, just in a state where armhf 
bugs are not considered release-critical.

However, the armv7 port can run on raspberry pi 2 and newer, AFAIK.

Ariadne

---

From: "Marcus Rohrmoser" <[email-masked]>
Date: Sun, 16 Aug 2020 23:42:32 +0200

Hi,

On 16 Aug 2020, at 23:31, Ariadne Conill wrote:

> Don't worry, we plan to keep armhf around

BIG relief.

> However, the armv7 port can run on raspberry pi 2 and newer, AFAIK.

some ancient Pi 1s and Pi Zeros here which I'd like to run for some more decades to come.

Also just opened a PR to get back OCaml for those tiny ancient machines https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11514 (needs some polish)

Cheers,
M

---

From: Mogens Jensen <[email-masked]>
Date: Fri, 29 May 2020 05:08:32 +0000

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, May 28, 2020 8:47 AM, Natanael Copa <[email-masked]> wrote:

> https://lists.alpinelinux.org/~alpine/devel/<20190404112525.4b04fdeb%40ncopa-desktop.copa.dup.pw>#<[email-masked]>

It would be very sad to see armhf dropped from Alpine. BusyBox,
uClibc/musl and as it says on the frontpage "Small. Simple. Secure",
Alpine has always been about small and embedded devices, so if now
support is going to be removed for some of the most famous embedded
systems, then what's the point?

There are millions of Raspberry Pi 1, Zero and ZeroW that can have a
long and useful life with Alpine. There are NO lightweight and systemd
free distro that are as good as Alpine for these devices (or anything
else).

Most of them lives as small headless servers or do embedded work, so
as already suggested in this thread, maybe there is a middel ground
of not supporting problematic UI stuff?

Thanks to everyone working on Alpine Linux.

Regards,
Mogens Jensen

---

From: Wolf <[email-masked]>
Date: Fri, 29 May 2020 14:23:39 +0200

Hello,

On 2020-05-29 05:08:32 +0000, Mogens Jensen wrote:
> [..]

I would like to express that I also believe approach like this would be
reasonable. Providing just the reasonable subset of packages (so no Qt).

Of course I do not know how much work does doing it like this actually
save.

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.