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
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
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
> > 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
‐‐‐‐‐‐‐ 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
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.
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>
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, spam@ipik.org wrote:> > 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>
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
Hello,
On 2020-08-16 15:29, Marcus Rohrmoser wrote:
> 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!
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
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
On Thu, 9 Jul 2020 11:51:20 +0200
spam@ipik.org wrote:
> Dear Natanael,> > Have you come to a definitive conclusion on this particular matter?> 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
> > Regards.> macmpi.> > > On 28 May 2020, at 11:19, spam@ipik.org wrote:> > > > 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> > >