Bring ARM into the fold?

BluePyTheDeer_ · 2024-08-05 17:08:53

I know, but MAIN Arch.

solskogen · 2024-08-06 06:09:52

I don't think you'll notice any difference if it becomes a Arch Linux port.

soloturn · 2024-09-07 16:01:03

ugjka wrote:

Allan wrote:
We have had an RFC approved that outlines the process for getting a new architecture to be official, but there has been no-one step up and start the process for any new architecture. It is as if no-one is really that interested in doing the work needed.
Perhaps when the new SnapdraggonX laptops start popping up in dev's laps someone will step up!

@allan am i allowed to start such an rfc? who could help me with it? am using a snapdragon x now and then - and it has *cough* windows at the moment. for aur packages i am responsible i at least put arch=('x86_64' 'aarch64') in, like for the new rust based cosmic desktop: https://aur.archlinux.org/cgit/aur.git/ … c-comp-git . but for the official package this gets dropped again: https://gitlab.archlinux.org/archlinux/ … type=heads

Lone_Wolf · 2024-09-08 10:48:56

The RFC has been accepted and describes the process needed to get a port into archlinux .

I suggest you start with reading it thoroughly to get an idea of the work needed, https://rfc.archlinux.page/0032-arch-linux-ports/ .

bschnei · 2025-01-20 19:16:38

In case those still following this thread missed a related discussion on the aur-general mailing list: https://lists.archlinux.org/archives/li … IKL6HLHPZ/

Bert Peters wrote:

Packages in the AUR should be useful on Arch Linux, which is currently an x86_64-only distribution. Software that doesn't work on that architecture, therefore shouldn't be in the AUR, as it is not for Arch Linux, even if it may be useful for Arch Linux derivatives.

Valentin Hăloiu wrote:

In that case I think it would be helpful to call this out explicitly in the AUR submission guidelines...As for my "aarch64" packages, I guess I'll just need to find (or create) a different repository for them.

RFC 32 wrote:

The past has shown, that if expertise and domain knowledge can not be kept with Arch Linux, alternative projects such as Arch Linux ARM are created. If these projects are not merged back into the default distribution at some point and are undermaintained, they go defunct over time.

If the argument goes:

- Arch Linux derivatives use what the Arch Linux project creates, maintains, and distributes freely.
- Their communities do not contribute to the Arch Linux project.

Then it does indeed follow that there should be clear boundaries about what is and is not supported and maintained by Arch Linux. In other words, I can support Bert's decision on the boundaries for the AUR. However, the discussion on aur-general as well as comments here make a pretty compelling case that the current boundaries are not clear.

In my previous posts here, I have specifically called out the confusion created by allowing a project that is technically not "Arch Linux" to use the name "Arch Linux ARM" (and related branding).

To be clear, I have not, and am not, suggesting that the Arch Linux ARM project have to stop using Arch Linux branding. Nor have I suggested that the project must be integrated into Arch Linux. I don't know enough about the problems to start proposing solutions. I'm just pointing out (again) that the situation contributes to a lack of clarity around how anyone that would be interested in contributing to an Arch Linux Ports for ARM should proceed.

As I noted in my last post, the Ports RFC says to create another RFC. The RFC readme says anyone can file one, but

At least one Arch Linux Staff member has to support the RFC and must be willing to work on it in a joint effort with the contributor.

In this thread, I count at least three occasions people have expressed interest in being a part of the solution--not just whining and expecting handouts. I can't speak for others, but nobody from the Arch Linux Staff has reached out to me. Should I email staff randomly? Post on a mailing list instead?

Again, my point is that it is not clear how anyone interested in helping should really proceed. Just repeating over and over again that anyone interested should "read the RFC" is going in circles. We've read the RFC--what is the *next* step? Where is the *Arch Linux Staff* member that is going to step up and has the authority to figure out what to do with Arch Linux ARM?

Last edited by bschnei (2025-01-20 19:18:45)

Lone_Wolf · 2025-01-21 10:19:38

It seems I didn't put the correct link to the final version of the RFC ,
it is at https://gitlab.archlinux.org/archlinux/ … -ports.rst

I don't know who the devs are that maintain the existing arch linux arm distro but they don't seem interested in becoming an official arch linux Port .

If that's correct , a new port needs to be started .

In Specfiication > Maintainers of the RFC there's a very important line :

In case external volunteers are interested in starting a port, they need to be onboarded as package maintainers to the Arch Linux team first.

You appear to be an 'external volunteer' so you have to become a package maintainer .

See https://wiki.archlinux.org/title/Packag … Maintainer? .

bschnei · 2025-01-21 19:00:21

Thanks Lone_Wolf! It sounds like Arch needs more staff/package maintainers then as the first step. I maintain a few packages on the AUR, but also several outside because they are device-specific ARM kernels. My preference is to contribute the work I've done back to this community rather than other distributions. If there are maintainers interested in sponsoring me, please reach out.

Don Coyote · 2025-01-25 19:27:58

Lone_Wolf wrote:

I don't know who the devs are that maintain the existing arch linux arm distro but they don't seem interested in becoming an official arch linux Port .

And yet they are interested in using the official logo and name?

Lone_Wolf · 2025-01-26 11:19:45

Archlinux arm was started around 2009 . In the first years many people were involved with both archlinux & archlinux arm.
The permission to use the archlinux name & logo was given then.

Over time the distance between the 2 increased. A few years ago archlinux staff looked into ways to improve archlinux including adapting its infrastructure to allow multiple architectures.

In may 2024 the RFC dealing with integrating ports was accepted, sofar no port devs have come forward to start the process (as far as I know).

drzee99 · 2025-03-07 22:17:21

Coming back to this after a while ....

I have been reading up on the RFC etc. - I understand the intention of the RFC.

If an official port of Arch Linux has to be added to the project, then they want that who ever is proposing and managing that port become an integrated member of the Arch Linux project to contribute and help maintain the general Arch Linux build process and surrounding tools (in particular the devtools package). That is a fair ask IMHO.

The RFC also outlines a number of key requirements a Port must follow to ensure integration with the existing Arch Linux project and (hopefully) reduce the workload for package maintainers to support multiple ports.

Thee RFC does not propose or suggest how to automate an orchestrate the build process. That is left to the port maintainers and to be discussed in a separate RFC. It is though suggested that: "The introduction of automated build infrastructure is out of scope for this RFC. However, creating ports serves as learning experience for identifying common issues that need addressing in automated builds and as a stepping stone towards a centralized build infrastructure. As such port maintainers should work towards a common infrastructure and not rely on single-purpose build infrastructure."

Anyway the formal process to start bringing ARM into the fold would be:

(1) - TWO persons need to be accepted as Arch Linux Package maintainers (or two current Arch Linux Package maintainers need to be identified who want to work on this). To become a package maintainer is not "easy" if your interest is to only work on ARM ... basically you first have to "put the work in on x86_64" - see https://wiki.archlinux.org/title/Package_Maintainers

(2) - these two maintainers then need to formulate an RFC, that makes the suggestion to include an ARM port. If accepted the initial work will be to update the official tooling to support the new port: "Once an introduction RFC is accepted, the work on a port may start. Initial work includes additions of port specific integration (e.g. custom pacman.conf, makepkg.conf, etc.) to the official build tooling.". Assume that during this phase work on the build automation/orchestration also starts. By having access to "Port maintainers may gain access to dedicated build infrastructure and are strongly encouraged to help maintain and improve it." its possible to see how its done for x86_64 and then either adapt that or using the RFC process again to help shape a more "universal" build infrastructure/process that allows for the multiple ports.

(3) - When building is working for the port then care needs to be taken to ensure certain things. There is mention in the RFC about how to deal with packages that need specific architecture patches to compile on the Port and how to deal with package releases where its not possible to upgrade to the next version on a given Port (e.g. because some upstream issue or dependency issue). These need to be factored into the automation/orchestration. During this stage the port is still considered "unofficial" and there are some requirements to how the ports needs to handle PKGBUILD files that maintainers push to the repos.

(4) - If a port consistently hits 90% of package parity with the Arch Linux on x86_64 it can be made into an official supported port through an RFC process. The riscv64 and aarch64 projects almost qualify here - however I believe they end up short when it comes to some of the requirements stipulated in the RFC, which is why they can not become an official port in their current form.

I would be happy to engage in such a project if the requirements for (1) could be relaxed. I'm not a package maintainer (nor do I have any idea what packages that would be, that I could do, that are not already done), but I'm very much interested in automation/orchestration of the build process.

Any one else up for this? If so how do we get started?

FYI - Its may be possible to "skip" (1) and - outside of the scope of Arch Linux - start with (2) (but without doing the RFC), then when confident that (2) and (3) work go back to (1) ... IMHO this is a bit hard though. I have found no documentation on how the current automation/orchestration for Arch Linux builds work, there are some "hints" here and there, but nothing that so far has given me the mental model on how that works.

One thing that I really are unsure about, is what happens if we have package A that gets upgraded to version N+1, and packages B and C depend on A (version N).

Do we then have to re-build B and C when A (N+1) has been build?
And do we wait to push A (N+1) to the repo until both B and C have been re-build?
Is there an easy way to traverse the dependency tree to find these?
And what if B and C fail to build with A (N+1) because they themselves have to be upgraded first? What do we do then?
Do we need to approach this different if its just a "normal" dependency vs. a BUILD dependency?

It would be good to have an in-depth dialogue with some of the current owners of the build automation/orchestration for Arch Linux to understand and bottom out these things - they are independent of the actually underlying tooling. Who would be a good contact?

Last edited by drzee99 (2025-03-07 22:20:31)

bschnei · Today 19:26:38

drzee99 wrote:

I'm not a package maintainer...but I'm very much interested in automation/orchestration of the build process.

I'm in a similar situation. That is, I'm not a Package Maintainer, but I do maintain few AUR packages and some aarch64 kernel packages for my own device.

So I reached out a bit ago to David Runge (the author of the Arch Linux Ports RFC), and he mentioned there are two newer projects meant to address package build automation:

https://gitlab.archlinux.org/archlinux/buildbtw/
https://gitlab.archlinux.org/archlinux/signstar/

I also got the impression that there is a desire to focus on improving *current* package automation before trying to support other architectures, and I can completely understand that prioritization.

drzee99 wrote:

I have found no documentation on how the current automation/orchestration for Arch Linux builds work. One thing that I really are unsure about, is what happens if we have package A that gets upgraded to version N+1, and packages B and C depend on A (version N).

I think that's because in cases with complicated dependencies (like the toolchain) it is probably quite manual (as far as I can tell). For simpler application packages, I've seen cases where gitlab runners automate the building of packages using the docker image. That seems like a pretty cool/modern approach.

drzee99 wrote:

It would be good to have an in-depth dialogue with some of the current owners...

There's a lot to figure out by trying to fix an existing shortcoming you identify with the Arch Linux ARM project. For example, the official generic images used to bootstrap a new system haven't been updated since March 2023: https://ca.us.mirror.archlinuxarm.org/os/. OK, great, what does it take to build and maintain installation images *independently of Arch Linux ARM*? If you keep following the thread, you eventually wind up at the toolchain packages, which, again, appears to be maintained at least somewhat manually both at Arch Linux as well as Arch Linux ARM.

I have actually been able to build most of the core repo: https://archrepo.bens.haus/core-testing/os/aarch64/ with some very primitive scripts (https://github.com/bschnei/arch_a64), but am stuck right now spending a lot of time dealing with the toolchain. The PKGBUILD for glibc in the repo at Arch Linux ARM does not seem to build for me (in a clean chroot) as it currently stands. It's not clear to me if cross-compilation is used to make Arch Linux ARM packages, but I'm trying to do everything natively given that there are ARM cloud servers these days, but most ARM systems are not very powerful. glibc takes a few hours to compile so the trial and error to figure out what the issues are can be very time consuming. But presumably this is what Arch Linux ARM grappled with (and grapples with still when there are updates).

Arch Linux

#51 2024-08-05 17:08:53

Re: Bring ARM into the fold?

#52 2024-08-06 06:09:52

Re: Bring ARM into the fold?

#53 2024-09-07 16:01:03

Re: Bring ARM into the fold?

#54 2024-09-08 10:48:56

Re: Bring ARM into the fold?

#55 2025-01-20 19:16:38

Re: Bring ARM into the fold?

#56 2025-01-21 10:19:38

Re: Bring ARM into the fold?

#57 2025-01-21 19:00:21

Re: Bring ARM into the fold?

#58 2025-01-25 19:27:58

Re: Bring ARM into the fold?

#59 2025-01-26 11:19:45

Re: Bring ARM into the fold?

#60 2025-03-07 22:17:21

Re: Bring ARM into the fold?

#61 Today 19:26:38

Re: Bring ARM into the fold?

Board footer