Arch Linux

samcday

Member

Registered: 2023-07-13

Posts: 7

Re: Bring ARM into the fold?

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

You might be interested in this then: https://gitlab.archlinux.org/archlinux/ … equests/32

EDIT: I searched for "RFC" and didn't see any results, but I realize now solskogen linked it earlier and FluxBB contracted the link. Oops!

Last edited by samcday (2024-03-30 10:21:24)

samcday

Member

Registered: 2023-07-13

Posts: 7

Re: Bring ARM into the fold?

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

It's worth noting that there's a *massive* number of aarch64 devices that could in fact be running Arch Linux today: mobile phones and tablets. The postmarketOS project has been humming along for the last few years and nowadays has made a *lot* of progress in getting mainline kernel running on a lot of devices. Look at this list: https://wiki.postmarketos.org/wiki/Devices

In particular, the msm8916 devices from the 2015 era have great mainline support. I'm working on porting ALARM to these devices: https://github.com/samcday/archlinux-msm8916/.... There is also Kupfer doing the same with a broader scope: https://kupfer.gitlab.io/

I have a Samsung Galaxy A5 sitting next to me right now that is running ALARM with kernel 6.8.2. It's running Phosh with full 3D acceleration (Mesa Freedreno) support. The modem works. It has full wifi + bluetooth support. This is *not* some shrimpy USB stick samba share device or a Raspbi running Pi-hole

Last edited by samcday (2024-03-30 10:26:59)

bschnei

Member

Registered: 2024-03-05

Posts: 15

Re: Bring ARM into the fold?

ArchARM is still updated/maintained.

This is not true for parts of the project. I specifically pointed out the very old kernel for an officially supported device. So either the device is not actually supported and the website is not updated/maintained, or it is but the kernel is not updated/maintained. The state of the Arch Linux ARM Forum also speaks volumes. Sure, application packages and a few kernels are indeed well maintained, but it doesn't help the discussion to imply everything is just fine/nothing to see here when that is demonstrably not the case.

A distribution is clearly much more than application packages. David Runge did a great job in the RFC of explaining the problem:

Anyone creating a new Arch Linux port today is required to make an effort to setup infrastructure similar to archweb, dbscripts, part of devtools, source hosting for PKGBUILDs, etc.

So the "why don't you just fork it?" category of arguments are misguided and not constructive. Sure, the PKGBUILDs are open source and can be forked, but what good does that accomplish for the community without documentation, forum/discussion, build servers, package mirrors, etc? I.e. resources that seem to be under the exclusive control of the project lead (please correct me if I'm wrong).

The project founder and lead developer doesn't have as much free time as he would like.

I mean, you are just describing...people But it's not reasonable to expect empathy when you don't communicate. Can you clarify why the lead cannot or will not respond to his situation by engaging with the community he built? In other words, why drive potential solutions to the problem away? There appears to be at least a few capable people willing to help, but it doesn't seem like help is actually wanted. Again, please correct any misunderstandings here because it answers this question:

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

I brought the old kernel noted above up-to-date, but what should I do with it now? Submit a PR that, if merged, will mean devices that upgrade won't boot unless they also bring their bootloader up-to-date and reconfigure u-boot? Where should the announcement go that a package will introduce a change that breaks your system so much so that you need to flash new firmware? Or I could submit a PR for yet another device-specific kernel and give users options to migrate? Where would documentation for that go? On the Arch Linux ARM Wiki that hasn't seen a commit in two years? I don't know, but I do know I'm not going to build an entirely new website, wiki, forum, build infrastructure, etc. just so I can share the work I've done to bring one kernel up to date on one device with the community.

So while I agree with your perspective, I don't get the sense that most of the people here are asking for handouts or to dump work on others, etc. Or at least, I'm not. I think the proposed Arch Linux Ports more or less addresses the primary challenge the Arch Linux ARM community is facing: one person in control of the infrastructure who can't/won't communicate while critical parts of the project decay. I think the requirement for EFI boot support in particular is very important as it should largely eliminate device-specific kernel and u-boot configuration packages. But it could also mean that a lot of devices currently supported by Arch Linux ARM wouldn't be supported by Arch Linux Ports. At least, in the case of Marvell Armada 37xx SoC devices, they wouldn't be supported without the work I've done on the bootloader.

solskogen

Member

From: Norway

Registered: 2005-03-06

Posts: 121

Re: Bring ARM into the fold?

So while I agree with your perspective, I don't get the sense that most of the people here are asking for handouts or to dump work on others, etc. Or at least, I'm not. I think the proposed Arch Linux Ports more or less addresses the primary challenge the Arch Linux ARM community is facing: one person in control of the infrastructure who can't/won't communicate while critical parts of the project decay. I think the requirement for EFI boot support in particular is very important as it should largely eliminate device-specific kernel and u-boot configuration packages. But it could also mean that a lot of devices currently supported by Arch Linux ARM wouldn't be supported by Arch Linux Ports. At least, in the case of Marvell Armada 37xx SoC devices, they wouldn't be supported without the work I've done on the bootloader.

It will also throw the most used ARM board (the Raspberry Pi) under the bus.

bschnei

Member

Registered: 2024-03-05

Posts: 15

Re: Bring ARM into the fold?

It will also throw the most used ARM board (the Raspberry Pi) under the bus.

Sorry, I mispoke. In the RFC, David used the word UEFI as a "baseline" but left open the potential to support non-UEFI devices provided they are documented. I started a thread there and samcday has jumped in too. If you have something to contribute to the discussion, I'd share it there. I don't get the sense that the intention is to shut non-UEFI devices out entirely, but there are legitimate questions about how to support them that don't have straightforward answers. To Trilby's point, simply "moving/folding in" something that isn't working right elsewhere won't solve all of the challenges and could exacerbate some of them.

I have a Pi Zero W that I ran Arch ARM on for a while. One day I tried to update it only to find out that 32-bit ARM was no longer supported. So it runs Raspberry Pi OS. Disappointing? Sure, but not a death sentence for the device. I'm not very familiar with the Pi family of devices in general, but if you can get a relatively modern version of U-Boot running on it. Then you've got enough of the UEFI standard to make supporting the device at scale very easy for any distribution.

Now, whether or not users should be expected to flash their bootloader in order to be able to use your distribution is debatable. But at least when it comes to ARM as an architecture, the communities seem to be populated with users more comfortable with those kinds of operations (e.g. lots of headless devices). Which, IMHO, also makes it a good candidate architecture in terms of cultural fit for Arch Linux.

solskogen

Member

From: Norway

Registered: 2005-03-06

Posts: 121

Re: Bring ARM into the fold?

Oh, that's great. I really like the way Arch Linux ARM (and the Raspberry Pi OS) boots On the Pi's, since it doesn't require u-boot. U-boot is just another layer that can (and have) break that makes the device unbootable :-)

samcday

Member

Registered: 2023-07-13

Posts: 7

Re: Bring ARM into the fold?

So the "why don't you just fork it?" category of arguments are misguided and not constructive.

Thanks for taking the time to write a well-reasoned retort on this topic. I agree with everything you said. It drives me nuts when people say that because I find it quite adversarial and argumentative in a way that helps exactly nobody.

I also agree with your analysis on the situation with ALARM maintainer (is it okay if we just say "Kevin"? Not to call this person out in some weird way, but they *are* the lead maintainer for ALARM...). I feel so conflicted on the whole matter because, on the one hand, I'm extraordinarily grateful to this person's efforts. For all its limitations/warts, I've managed to go a long way with ALARM. It's not "true" Arch upstream in many weird ways (like how about mkosi is version 22 in upstream, but version 14 from May 2023 in ALARM... argh!), but it's the best Arch we currently got in the ARM world, and for me it beats the alternatives in many cases.

But on the other hand, I'm so frustrated by how far ALARM goes, and then just suddenly .. stops. If there was even just a *little* bit more effort to open up a community (how about a Matrix/IRC room?) it could be so much more!

I keep thinking about the fact that Asahi Linux started out on ALARM. I can't help but wonder if they'd still be based on it today rather than Fedora, if ALARM was closer to Arch upstream. After all, Valve made it *to market* on top of Arch...

asoliverez-col

Member

Registered: 2024-03-28

Posts: 2

Re: Bring ARM into the fold?

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.

Having ARM (or other architectures) in the same infra helps reduce the duplication of work. Most of the issues will be common to all archs, and then specific issues can be looked at by the specialty arch maintainers. It's not that special, other distros do it well, with x86 usually being the best maintained and other archs having varying levels of support.

Maybe the way to start is open a poll? Would there be interest from current maintainers? Do we need to find 14000 ARM package maintainers before even discussing whether ARM is feasible to do within the same infrastructure as Archlinux?

Some people have expressed interest in contributing here instead of in ALARM, maybe there's enough power to start a mini project? Would it be acceptable to only have the Core repository ported to ARM, and work through extra over time and as interest grows on it?

I think there are many possible ways forward. I'd like to continue the discussion without any assumptions that I'm demanding anything from current maintainers or trying to throw work over the fence without concern for people's time or desires.

marcan

Member

Registered: 2024-04-11

Posts: 3

Re: Bring ARM into the fold?

I keep thinking about the fact that Asahi Linux started out on ALARM. I can't help but wonder if they'd still be based on it today rather than Fedora, if ALARM was closer to Arch upstream. After all, Valve made it *to market* on top of Arch...

There are two separate factors here. First, Fedora is the current flagship *because* Fedora maintainers signed up to work directly with us and upstream our work. The Arch ARM release was a purely downstream project.

The second question is why the Arch ARM port was essentially dropped as unmaintained. The answer is twofold: First, Kevin was somewhat responsive when the project started (before the first release) and we even floated the idea of giving me or other Asahi folks commit access to help with maintainership. However, later when we tried to actually upstream our changes we were met with passive-aggressiveness. Our PRs were ignored due to minor issues, instead of pointing out what those issues were. There was never any follow-up engagement to make Apple Macs a first-class platform for Arch ARM, but quite the opposite.

Second, Arch ARM itself is not maintained to a suitable quality standard. Packages/builds randomly break or have missing dependencies. I've seen QtWebEngine builds that were outright broken (missing files), breaking KDE. Another one was when a Firefox update had build issues with WebRTC, and Arch ARM's response was just to... disable WebRTC. That's just not acceptable for a distro that wants to take itself seriously (users: "why did video conferencing stop working on Asahi?"). Never mind the years-out-of-date toolchain/glibc (this blocks Widevine support), broken qemu that couldn't even be installed (no VMs!), etc. I could go on. Arch ARM may be good enough for hobbyist use on a Raspberry Pi, but it's not up to par for being a desktop/server distro that people actually rely on not to break randomly and with no real timelines for being fixed.

Our quality standard for Asahi Linux today to become one of the default installer options is a distro that has first-class ARM64 support, which upstreams our major packages officially (no pure downstream forks), and where the team responsible can work with upstream to get ARM or Apple-specific bugs fixed within a reasonable timeframe (i.e. it's not acceptable for a major package update that breaks on the platform to remain unfixed for weeks, and yes this does happen on smaller platforms like this one since developers often don't test on them).

I understand that Kevin does not have as much time as he wants to work on the project, and I do not fault him for the slipping quality as a result. However, it is his responsibility to work with the community to find people to help, and he hasn't been doing a good job on that front.

Last edited by marcan (2024-04-11 21:43:57)

samcday

Member

Registered: 2023-07-13

Posts: 7

Re: Bring ARM into the fold?

Thanks for the highly valuable insight marcan!

Considering the proposition that is being put forth upstream in RFC0032, and noting the fact that the merry band of Asaheroes were literally pitching the idea of participating in the package/distro maintenance activities, I really do think that in an alternate reality where RFC0032 was accepted and already in place back in early 2021, we could all be bragging that "I run Arch btw and so do all my Mac hipster friends"

(by the way, we were discussing the ALARM topic in #archlinux:archlinux.org yesterday and someone linked to your post on the Fediverse from last year)

Anyways, this might be a good time to let folks know that I've been bootstrapping the armch64 project over the last few days. Let's give an ARM64 port another try, and do things a little differently so that it shapes up (hopefully!) to be a healthier, more stable, and more complete port.

Right now it's still bootstrapping and not ready to take for a spin yet (unless you really like bleedingly sharp edges). But  hopefully we'll have something ready for wider consumption in the next few days.

The plan is to kinda pick up where ALARM has seemingly left off. The org README I linked touches on the main points, but let me restate them here too.

* Develop entirely in the open.
* Stay as close to upstream as possible: use all their tooling, infra, development practices, and of course PKGBUILDs. Participate in upstream decision-making. Contribute changes back upstream.
* Ensure we can accept any and all contributions: from downstream distros like DanctNIX/the-next-Asahi to single-line drive-by contributions from individuals.
* Actively recruit and encourage potential contributors/maintainers.
* Exist for exactly as long as we need to, until we can onboard to the upstream Arch Ports initiative, when it is ready.

That's why the "armch64" name is so stupid: you should only be annoyed by the silly moniker for a while, until you're transitioned to good old upstream Arch.

If you're interested in getting involved, please do so! Discuss here, ping me on Matrix (@sam:samcday.com), or email me (me@samcday.com). There's a few hundred million ARM64 devices that have been yeeted into the marketplace over the last decade or so, let's get Arch running on more of them.

(and hey, I'm sure marcan will be pleased to know that as part of the initial bootstrapping we're starting with the toolchain! Here's a GCC13 package fresh out of the oven )

Last edited by samcday (2024-04-15 16:01:04)

marcan

Member

Registered: 2024-04-11

Posts: 3

Re: Bring ARM into the fold?

Thank you for doing this. We still regularly get folks asking about an Arch port

For the Asahi packages (somewhat outdated, but see PRs for some contribution attempts I haven't had a chance to look at) feel free to fork/inherit the PKGBUILDs if you're interested. Ideally everything except perhaps kernel/mesa/uboot packages should be upstreamed (depending on policies/etc). See also the Fedora side for a bunch of stuff that's not there yet. From my POV I'd love it for some folks to effectively take over the Asahi port, and since this would presumably be a new thing without a direct upgrade path from ALARM, that also means there's no need to worry about handing off package signing keys/infra stuff and whatnot. In other words, this turns the Arch effort into something like the Fedora and Ubuntu efforts where the major packages/infra are upstream (or, in this case, "armch64" considered as upstream at least).

Once the whole thing is stable enough and with active maintainership I'd be happy to reinstate the Arch images in the asahilinux.org installer. We now have the ability to fetch images from third party hosts, so you get to figure out the infra yourself; the build scripts I used for Arch ARM are here for reference and in my case it was all built/synced to the mirrors manually, but I'm sure it can be done better and/or integrated into the upstream image builds (since I was basing off of Arch ARM rootfs tarballs anyway) .

Last edited by marcan (2024-04-15 03:19:28)

samcday

Member

Registered: 2023-07-13

Posts: 7

Re: Bring ARM into the fold?

Actually, as the project progressed further and I started interacting more with upstream, I think I've discovered why ALARM is the way it is - it's much more in line with upstream than folks may fully appreciate Sadly many of the folks I encountered upstream are quite unfriendly, and often times just outright rude

I think that whoever ends up trying to pick up the work of porting Arch to non-x86 architectures is going to need to ensure they have the right mix of skills. It won't just be technical challenges, you'll need to have a thick skin (much thicker than mine evidently is, at least!) and be ready for lots of pointlessly unpleasant + passive-aggressive interactions.

As for me, all I want is a solid ARM64 distro that is ideally consistent with my daily driver. So I guess it's time to kick the tires on Fedora again, I hear it's pretty good for at least some ARM64 machines

Last edited by samcday (2024-04-15 16:12:42)

marcan

Member

Registered: 2024-04-11

Posts: 3

Re: Bring ARM into the fold?

Well, that's unfortunate... I've had better interactions with upstream Arch folks than with ALARM, but I guess that's not everyone

Fedora *is* pretty nice though, definitely recommended for ARM64 if you're not particular about other aspects of the distro choice. I was a Gentoo+Arch person before the Fedora folks signing up to the Asahi project made me jump ship, but now that I'm here I'm really liking the infra, community, tooling, and general vibe of the distro. It's a lot closer to rolling-release than I expected (the stable versions, not even rawhide) and the release cadence is fast enough that I don't mind waiting a few months for those major package updates that do get held back to the next release. Fedora also seems to have a lot more overlap between its package maintainers and upstream (no doubt in part because becoming a package maintainer is pretty easy) which helps with things. I suspect all my future x86 installs will also be Fedora unless I have a really good reason to pick something else, going forward.

Last edited by marcan (2024-04-15 21:01:59)

samcday

Member

Registered: 2023-07-13

Posts: 7

Re: Bring ARM into the fold?

That's good to hear. I've played with Silverblue a handful of times, and my homelab nodes have been happily running CoreOS for a while now.

Yesterday I made a concerted effort to do the switch, so now my daily driver is on Silverblue properly. I still find rpm-ostree to be one of those "it sounds better on paper" things, but I've been following it for a few years now and I've definitely observed it steadily improving so, I'm optimistic.

I actually started working on some Fedora packaging a month ago, before I decided to jump into trying to package aarch64 on Arch. COPR is very nice indeed.

Alas the first thing I started with for packaging in Fedora was the device-specific kernel I needed for the devices I'm working on porting. And uh ... gosh. Compare the couple of hundred lines of kernel PKGBUILD to ARK .... yikes! But to be fair I *did* manage to get something cooking on COPR (I used the Asahi git history and changes to ARK as reference!)

I also noticed that, since I don't have a powerful AArch64 machine right now and was doing mkosi builds and such from qemu-user-static, DNF + RPM scriptlets are *significantly* slower under qemu than Pacman + PKGBUILD install scripts are.

So of course there's always tradeoffs on these things. Though it's good hear you specifically note that you're liking the "general vibe". That's quite important to me personally, once all the boring technical stuff has been weighed and considered!

I'll see you around in the Fedora communities sometime, perhaps Probably also going to pick up a used M1 for aarch64 development porpoises so - thanks in advance for all the amazing work you and the homies have done so far in Asahi.

Last edited by samcday (2024-04-16 10:04:41)