~alpine/devel

6 6

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

Details
Message ID
<20200528104748.4d37ede5@ncopa-desktop.copa.dup.pw>
DKIM signature
missing
Download raw message
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.dup.pw%3E#%3CCAGP1gyPCsaHh+85g0QX-Cu40K-5Vd7xqLTV2aGiUgUr+RdrdFQ@mail.gmail.com%3E
Details
Message ID
<B10D4884-BC26-4ADE-8FBB-0AEF787E1831@ipik.org>
In-Reply-To
<20200528104748.4d37ede5@ncopa-desktop.copa.dup.pw> (view parent)
DKIM signature
missing
Download raw message
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 <ncopa@alpinelinux.org> wrote:
> 
> 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.dup.pw%3E#%3CCAGP1gyPCsaHh+85g0QX-Cu40K-5Vd7xqLTV2aGiUgUr+RdrdFQ@mail.gmail.com%3E
Ariadne Conill
Details
Message ID
<1687182.jfqktxE8f0@localhost>
In-Reply-To
<20200528104748.4d37ede5@ncopa-desktop.copa.dup.pw> (view parent)
DKIM signature
missing
Download raw message
Hello,

On Thursday, May 28, 2020 2:47:48 AM MDT Natanael Copa wrote:
> 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.

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.

> The reason is that there are increasing number of issues that are not
> fixed upstream. For example:
> 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.

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

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
Pablo Rogina
Details
Message ID
<CAL5OxRsvrnddvhcLZVHWg+h7kTujoPwh68KOHdNCxfjMj+BMzw@mail.gmail.com>
In-Reply-To
<1687182.jfqktxE8f0@localhost> (view parent)
DKIM signature
missing
Download raw message
> > The reason is that there are increasing number of issues that are not
> > fixed upstream. For example:
> > 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.

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
Mogens Jensen
Details
Message ID
<UjmbGTbMc9ox1g-j_O0zOwXhhss532Q7UAZNrdL3iQ6p5St6-0LqO9HxbPlntnrqkvyIgXulkSw6k1LK-ETP4hx6We9eTR5mgbLrc7e21sg=@protonmail.com>
In-Reply-To
<20200528104748.4d37ede5@ncopa-desktop.copa.dup.pw> (view parent)
DKIM signature
missing
Download raw message
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, May 28, 2020 8:47 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:

> 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/<20190404112525.4b04fdeb%40ncopa-desktop.copa.dup.pw>#<CAGP1gyPCsaHh+85g0QX-Cu40K-5Vd7xqLTV2aGiUgUr+RdrdFQ@mail.gmail.com>

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
Wolf
Details
Message ID
<20200529122339.i7nry3adlls6ikap@wolfsden.cz>
In-Reply-To
<UjmbGTbMc9ox1g-j_O0zOwXhhss532Q7UAZNrdL3iQ6p5St6-0LqO9HxbPlntnrqkvyIgXulkSw6k1LK-ETP4hx6We9eTR5mgbLrc7e21sg=@protonmail.com> (view parent)
DKIM signature
missing
Download raw message
Hello,

On 2020-05-29 05:08:32 +0000, Mogens Jensen wrote:
> [..]
> 
> 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?

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.
Oliver Smith
Details
Message ID
<18f38ba3-c899-b287-ec4a-6b3f2dae23f6@postmarketos.org>
In-Reply-To
<1687182.jfqktxE8f0@localhost> (view parent)
DKIM signature
missing
Download raw message
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

Ariadne Conill:
> Hello,
> 
> On Thursday, May 28, 2020 2:47:48 AM MDT Natanael Copa wrote:
>> 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.
> 
> 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.
> 
>> The reason is that there are increasing number of issues that are not
>> fixed upstream. For example:
>> 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.
> 
>> 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?
> 
> 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
>