Bring ARM into the fold?

solskogen · 2023-12-08 09:21:14

Is it time to bring Arch Linux ARM into the fold of Arch Linux?
The GNU toolchain of ALARM is now very behind, and the developers are dead silent about why. There little to no response on pull requests on the github page, and while it seems like there is activity on their PKGBUILDs repo, it almost seems to me that it is some kind of automatic jobs being run.

WorMzy · 2023-12-08 09:33:43

These are end-user support forums, and not actively frequented by 'decision makers'. You may have more luck reaching your target audience using the arch-general mailing list.

https://lists.archlinux.org/postorius/l … linux.org/

Trilby · 2023-12-08 13:56:19

If what you say / imply is correct that their devs / packagers are not keeping up, why would we want to add that to our community?

I gather you are not actually suggesting merging and bringing those devs / packagers along, but instead suggesting that arch devs take over ARM packages, right? But if the limiting factor is the lack of person-hours to properly maintain those packages, allocating that same amount of work to a smaller set of people would not help and would not likely be welcomed by the people you'd hope to dump that work on.

Of course if you were willing to volunteer to take on some of that work, that'd be good. But if this was the case, you'd not make your current proposal here, you'd just contribute over on archlinuxarm.

solskogen · 2023-12-08 14:15:13

I think that there's a lot of work being done in Arch Linux that Arch Linux ARM would benefit from. IF the few developers that are left wants to be a part of this proposed merge, that would be of course very very welcome.
There are people who wants to volunteer already that cannot because there is just dead silence from the core developers of ALARM. I'm one of them.

merlock · 2023-12-08 14:37:23

solskogen wrote:

There are people who wants to volunteer already that cannot because there is just dead silence from the core developers of ALARM. I'm one of them.

So what's stopping you from assembling a team and forking the project (like manjaro and their ilk)?

solskogen · 2023-12-08 15:05:56

Because I don't want yet another fork. The last time a fork did something good was when GCC and EGCS split. I'd rather want the exact opposite.

jclds139 · 2023-12-08 16:54:50

solskogen wrote:

Because I don't want yet another fork. The last time a fork did something good was when GCC and EGCS split. I'd rather want the exact opposite.

While I wasn't around for that split I definitely agree on the sentiment here. And an ALARM fork would just end up dividing the already sparse ARM side of things, particularly since ALARM is already the package source for most of Manjaro ARM.

On the subject of package maintenance falling behind, the biggest problems right now seem to not be "ARM-specific", but just that they don't have an adequate "staging → testing → core/extra" pipeline to do manage full rebuilds regularly when toolchain updates happen. I suspect that there are sufficient volunteers (like solskogen and myself, possibly even including the current core ALARM developers) who would contribute to the ARM-specific packaging changes, but can't also manage an entirely separate distribution with its own infrastructure as is currently the case.

Basically, my argument is that Arch-ARM is maintainable if it was part of Arch proper, but not as an independent distribution as it currently stands. As a backup plan, if the core Arch devs are against this idea could we try to reach out to Manjaro to see if the core packaging could be maintained as part of them?

drzee99 · 2023-12-11 13:54:27

I'm maintaining the AWS Arch Linux AMIs (https://wiki.archlinux.org/title/Arch_L … b_Services).

With AWS and Cloud Computing in general pivoting more and more to ARM based architectures (Graviton 2 and 3) it would be great to also have AMIs for ARM CPUs and It wold IMHO even be better to have this as part of the standard Arch project.

The PKGBUILD system is already capable of managing multiple architectures and for many packages they only need to be recompiled for ARM to make them work.

Even the kernel, I have been compiling the standard Arch Project kernels on ARM by basically only changing the 'arch=(x86_64)' to 'arch=(arm64)' and it works! (ok need a specific kernel config file, but generating the default from the kernel for arm64 worked just fine). IMHO most of the packages in the official Arch Linux repos should compile just fine on ARM.

I had been playing with using the Arch ARM packages (https://archlinuxarm.org/packages) as a base and then providing a secondary Arch REPO where I would release the latest builds of the Linux Kernel for ARM at the same pace as the x86_64 Arch version and also a ARM version of the cloud_init tools (which do not exist in the ALARM repo) to provide AMIs for ARM on AWS.

I had it 90% working when I discovered that it looked like ALARM had stalled ... and put the project on standby for now.

I would be happy to contribute.

IMHO Arch Linux as a project should take the next step and embrace Cloud and ARM architecture in the official project. I'm afraid if not done then Arch Linux over time will become obsolete.

ARM32Enthusiast · 2023-12-14 05:06:19

solskogen wrote:

Because I don't want yet another fork. The last time a fork did something good was when GCC and EGCS split. I'd rather want the exact opposite.

What if the fork's aim was to simply be Arch Linux ARM but actually maintained? It could exist until there's change in the regular badly maintained official Arch Linux ARM. ARM64 support is just plain bad on Arch Linux ARM (ALARM) and ARMv7h support is even worse. Could you call Arch Linux ARM in its current state 'Arch Linux' if a significantly large number of the packages and PKGBUILDs for it are severely out of date? In fact, ALARM is still ships Glibc 2.35 and main stable kernel for ARM64 and ARMv7h is stuck on Linux kernel 6.2, so not a great look at all. I could keep going, but if you invest some time to look at what's going on over there, it's clearly a dead project. An example of what ALARM could have been is something similar to postmarketOS (the rolling release version). I think I might be interested in contributing to ALARM here and there. I've noticed that a lot of PRs go ignored for some unexplained reason. I don't see the ALARM community as a community that isn't willing to maintain the project, but rather a community whose maintainer who refuses to accept anything from his community.

Last edited by ARM32Enthusiast (2023-12-14 06:08:49)

solskogen · 2023-12-14 07:06:07

I don't think you and I disagree on much :-) That's the reason why I started this thread. I have to admit that I don't care /that/ much about armv7, having just aarch64/arm64 would suffice /for me/. There's been little to no response on my mail to arch-general mailing list, will try the developer one today.

ARM32Enthusiast · 2023-12-14 07:11:57

ARMv7h isn't really difficult to maintain either, and I think it would be great if the main ALARM maintainer would start allowing actual community support. On ALARM's official webpage, you even see the phrase "Community Supported Devices" when in reality, the community isn't actually able to have any contributions merged.

solskogen · 2023-12-14 07:20:12

I totally agree with you, that's why I created this thread. But I can't do it alone, heck there's a lot of stuff happening behind the scenes of maintaining a linux distribution that I have no knowledge of, still if I can help by maintaining some PKGBUILDs, I'd be more than happy to help. Getting the toolchain and kernels up-to-date would be my first priority.

ARM32Enthusiast · 2023-12-14 07:25:03

I mainly got into ARM Linux because of an ARM ChromeBook I purchased about two years ago. There's many things that can be fixed that don't actually take as much effort as you'd think. In many cases, existing x86 Arch Linux PKGBUILDs you'll find will work or don't take many changes to work. Wouldn't you think it's a good idea to go ahead and start making a repository of PKGBUILDs and compiled packages already for ALARM for people to contribute to? It would be like an AUR of sorts in a way.

Also, at least Clang is up to date for ARM64 and ARMv7h on ALARM: https://archlinuxarm.org/packages/aarch64/clang

Last edited by ARM32Enthusiast (2023-12-14 07:32:32)

Popolon · 2023-12-22 23:14:07

You could maybe take some inspiration of the current Arch Linux RISC-V project, they maintain a git repository that contains only the RISC-V diff needed for some specific packages that need the addition of patchs or modifications in PKGBUILD, and it progress really fast this way. I use both x86_64, armv7h, aarch64 (ARMv8) and riscv64 and it is a very good news in my point of view to have finally a willing to melt ALARM in main Arch .

Last edited by Popolon (2023-12-22 23:18:00)

Neitsab · 2024-02-24 09:20:41

solskogen wrote:

There's been little to no response on my mail to arch-general mailing list, will try the developer one today.

For those willing to contribute, here is the thread on arch-general: Bring ARM into the fold.

If many people chime in, it will give more strength to the request (which is a fairly big ask from Arch's team POV, with far-reaching consequences for the project's identity, infrastructure, support cost...).

I am working on a rationale to back up the request. So far it centers around the following points:

embrace the gradual shift to more ARM-powered devices: cloud servers (Graviton, Ampere), Qualcomm laptops, Chromebooks... x86_64 preeminence is slowly eroding. Now would be a good time to start working towards a more architecturally-diverse computing future.
maintain Arch's quality standard: ALARM uses Arch branding "under permission of the Arch Linux Project Lead" according to its homepage, so that anyone would be excused if they believed it is an officially endorsed project, if only a side one. But in recent times, users have reported that it's been providing a subpar experience (one completely at odds with upstream Arch Linux) with core packages being outdated for months and communication from the project almost non-existent. Folding it under Arch would take stock of the existing (and understandable) belief that it is an Arch subproject (despite it being completely separate), and mitigate the harm done to Arch branding by improving quality consistency and ensuring that it remains so.
do a service to the ALARM community, which unlike other downstreams are actual Arch users at heart (they just want to use Arch on their ARM devices), which is hindered in its development by the unresponsiveness of the project's leadership. On the forums several users have already stepped up to offer their help, but due to the project's organization (no TUs, the only responsive "developer" – the one and only Graysky – being very clear about his limited responsabilities/power as a maintainer), the community's development has hampered.

Is there something else important that you would like to see included?

Besides the rationale, a successful plea would consider what the request entails for the main project: what are the changes needed in the infra? Is it possible to onboard ALARM community members and pair them with core contributors to organize and oversee all those changes? Etc. etc. It is a far reaching change that we are proposing.

Maybe graysky and tpowa would be willing to chime in and say what they think of the idea, or even provide guidance on how to present this request to other Arch developers?

Edited to add: although the main developer is consistently active on ALARM GitHub, I think the plea for folding into Arch remains valid, potentially with him in the group of coordinators if he so wishes. Although reducing the bus factor and improving the project structure could be done standalone, I still think that reason number 1 (preparing Arch for a more ARMed future) is actually the most important here, and in turn it would also improve point 2 & 3.

Last edited by Neitsab (2024-02-24 10:28:38)

bschnei · 2024-03-06 00:03:03

Neitsab wrote:

ALARM uses Arch branding

IMHO, this is the real issue and worthy of Arch Linux's attention.

The ALARM community has recently expressed their frustration, but outdated packages and poor communication seem to be a systemic issue for the ALARM project--not just a recent phenomenon.

I can't offer an educated opinion on whether it makes sense for the existing ALARM project to be "folded in", but I do share the observation that the ALARM project seems to be struggling with the Arch Linux principle of Modernity when it comes to "supported" device kernels and the toolchain (as already noted). This is even more confusing given the apparent willingness of the community to contribute.

For me, the association of the Arch Linux name with the ALARM project in its current state undermines the principles the Arch Linux project claims to represent.

The project's package repository does indeed have a lot of commit activity, but much of it seems to be some sort of automation. Whatever the case (manual or automated), application packages generally seem to receive extremely rapid updates. But a distribution is not just the applications.

I own an ESPRESSObin Ultra (Marvell Armada 3720 Soc) which is variant of the ESPRESSObin which is "supported" by ALARM. This is a network appliance I use as an edge router so keeping the kernel reasonably up-to-date is a priority. The official ALARM kernel for the device hasn't been updated past v5.10.

To be fair, the inconsistency of the boot process across ARM devices poses major headaches to any packages that attempt to alter the boot process (i.e. kernel packages). The number of device-specific kernel packages in the ALARM repos speaks for itself.

There is also no obvious strong incentive for SoC manufacturers to contribute/support open source communities so kernels for specific devices will also get frozen in time due to the lack of support when a kernel upgrade "breaks" a device due to the device's broken firmware.

I've been running and packaging an up-to-date kernel myself which installs the kernel and determines if systemd-boot is being used to manage the ESP. If so, it calls it to install the kernel to the ESP. Systemd-boot being part of base means no GRUB, no pacman hooks, and no hacky mkinitcpio scripts/presets. It is simple, pragmatic, and modern--it's..Arch.

But because EFI stub booting is broken in the stock firmware, if I submitted a PR to update the existing kernel package for this device at ALARM, devices that upgrade would fail to boot. I am very willing to support users that needed help, and I would really prefer to support Arch users, but nearly everything about the current state of the ALARM project suggests my time would be better spent helping users at other distributions.

asoliverez-col · 2024-03-29 11:32:25

Are there any concrete steps that should happen to have ARM accepted into main Archlinux? I've seen a lot of diagnostics on the current situation with ARM and the possible benefits, but there is no mention to actual actions to get this going

solskogen · 2024-03-29 12:25:45

This is the only light in the tunnel: https://gitlab.archlinux.org/archlinux/ … equests/32

Trilby · 2024-03-29 13:28:52

asoliverez-col wrote:

Are there any concrete steps that should happen to have ARM accepted into main Archlinux?

There can't be concrete steps to achieving a goal if the goal itself isn't even defined in concrete terms. What do you mean by being "accepted into main Archlinux"? That's a meaningless phrase.

As in my first comment here, this sounds like you want the existing arch linux developers to take over all the work that the archlinuxARM developers are allegedly failing to do well. But how could this happen? Distro devs are volunteers. I'm quite sure they are all aware of ArchARM, and if they wanted to volunteer to help out with ARM they'd be doing so already, right?

So, what, we tell these volunteers that they're now "required" to start doing a bunch of work they have no interest in? Take a moment to think about what that would do.

And if pawning off all the work that is (again allegedly) not being done well by the existing ArchARM team onto the existing Arch Linux team is not what you mean by being "accepted", then please define what it is you'd actually want.

solskogen · 2024-03-29 15:42:10

One of the biggest problems with ALARM is that there isn't any ArchARM team.
Most PKGBUILDs doesn't require any changes, but a few do, and there is at least some people (me included) who are willing to help where ever we can.

ugjka · 2024-03-29 16:35:16

Perhaps it will be considered when more and more ARM laptops/desktops appear on the market that can be actually be used as daily drivers for the work people actually do. Right now i don't see the point for these little critter devices that hang dangling by the USB charger wire with some USB stick with sole purpose of hosting some mystery Samba share on the LAN

Last edited by ugjka (2024-03-29 16:43:32)

Trilby · 2024-03-29 16:40:42

solskogen wrote:

One of the biggest problems with ALARM is that there isn't any ArchARM team.
Most PKGBUILDs doesn't require any changes, but a few do, and there is at least some people (me included) who are willing to help where ever we can.

Okay, then what's stopping you from stepping in and doing so?

Either your efforts will be sufficient to get ARM in good working order in which case merging wouldn't be needed. Or alternatively, your efforts would not be sufficient because such an undertaking isn't realistic for one or two people, so in the end it'd be the exact scenario I described of wanting to put some of the work on existing arch devs.

Please don't read this the wrong way. I applaud your work and would offer nothing but encouragement. I just do not see any logic at all behind a proposal to "merge" or to "accept" ARM - I don't know what that would even mean. Either there are enough volunteers to maintain it or there aren't. The semantics of whether it is "accepted into the fold" really have no bearing on that.

Last edited by Trilby (2024-03-29 16:43:01)

graysky · 2024-03-29 17:39:16

solskogen wrote:

One of the biggest problems with ALARM is that there isn't any ArchARM team.

There is a team. The project founder and lead developer doesn't have as much free time as he would like. ArchARM is still updated/maintained.

skunark · 2024-03-30 04:02:44

Thanks Graysky for the response, but I feel like the only way forward is for the alarm leadership to ask for help vs the deafening silence that appears in the alarm forums. Each time a question is brought up there, the thread just gets locked. The number of packages missing from archlinuxarm vs archlinux is interesting to review and should be a concern for folding alarm into arch. What I consider basic developer packages are missing from alarm but maybe that isn't the focus of alarm. As I agree or maybe better way to state it is I feel like arm is going to be a player in the cloud as it's just cheaper than x86 and perhaps even risc-v when it matures more it should be on arch's radar.. It's clear alarm is behind on the packages it maintains, it's missing packages and perhaps as it was poorly pointed out the targets are mostly the equivalent of RPI and USB sticks. Not something I would expect Arch Linux to even focus on at this point to be honest.

On the flip side I find it interesting the number of distros based on arch for x86 and the more popular distos are also supporting aarch64. It is to the point that I even question if arch also has its own issues as their popularity slowly falls. I prefer arch and the rolling release way, but neither arch or alarm are leaders for their own distros if you look at the distro popularity which I assume translates to the install base. Maybe I'm reading too much into the popularity contests....

I personally would prefer all "archtypes" under one roof with a common build system as I assume this would be the most efficient for the volunteer effort, but maybe it's significantly more complex than I can understand and shouldn't have added to this thread..

Last edited by skunark (2024-03-30 04:14:04)

samcday · 2024-03-30 09:32:42

I noticed that very recently (as in, some time in the last week or two) the Issues tab for all archlinuxarm repos have been disabled. What on earth is going on with ALARM lately?

Arch Linux

#1 2023-12-08 09:21:14

Bring ARM into the fold?

#2 2023-12-08 09:33:43

Re: Bring ARM into the fold?

#3 2023-12-08 13:56:19

Re: Bring ARM into the fold?

#4 2023-12-08 14:15:13

Re: Bring ARM into the fold?

#5 2023-12-08 14:37:23

Re: Bring ARM into the fold?

#6 2023-12-08 15:05:56

Re: Bring ARM into the fold?

#7 2023-12-08 16:54:50

Re: Bring ARM into the fold?

#8 2023-12-11 13:54:27

Re: Bring ARM into the fold?

#9 2023-12-14 05:06:19

Re: Bring ARM into the fold?

#10 2023-12-14 07:06:07

Re: Bring ARM into the fold?

#11 2023-12-14 07:11:57

Re: Bring ARM into the fold?

#12 2023-12-14 07:20:12

Re: Bring ARM into the fold?

#13 2023-12-14 07:25:03

Re: Bring ARM into the fold?

#14 2023-12-22 23:14:07

Re: Bring ARM into the fold?

#15 2024-02-24 09:20:41

Re: Bring ARM into the fold?

#16 2024-03-06 00:03:03

Re: Bring ARM into the fold?

#17 2024-03-29 11:32:25

Re: Bring ARM into the fold?

#18 2024-03-29 12:25:45

Re: Bring ARM into the fold?

#19 2024-03-29 13:28:52

Re: Bring ARM into the fold?

#20 2024-03-29 15:42:10

Re: Bring ARM into the fold?

#21 2024-03-29 16:35:16

Re: Bring ARM into the fold?

#22 2024-03-29 16:40:42

Re: Bring ARM into the fold?

#23 2024-03-29 17:39:16

Re: Bring ARM into the fold?

#24 2024-03-30 04:02:44

Re: Bring ARM into the fold?

#25 2024-03-30 09:32:42

Re: Bring ARM into the fold?

Board footer