Comment by frankjr | Hacker News Reader

Comment by frankjr | Hacker News Reader

Parent Full thread

The newest status update I could find is this [0] but that's over a year old too. Honestly I would rather if they worked on providing ARM64 packages. I know about and use Arch Linux ARM but that's a completely different project with different people and even fewer resources, which often manifests in broken packages (right now generating initramfs fails without manual intervention [1]). I remember for a long time Arch Linux didn't have any build servers and packagers mostly used their own machines to build packages. Not sure what's the current state of things but if that's still the case, then it's quite understandable that not everybody has an ARM64 machine to build on.

[0] https://lists.archlinux.org/hyperkitty/list/arch-dev-public@...

[1] https://archlinuxarm.org/forum/viewtopic.php?f=15&t=16672

It's all part of the same problem domain; How do we rearchitecture the release process of Arch so we can support multiple architectures.

The amount of people that understand this problem domain, have the time+energy to work on it and is actually able to see it too completion is.. well. Not many.

I tried to hack on buildbot, as I wrote in that email, but I have been questioning the maintainability of trying to fit what we need on top of buildbot. In constrast to writing something from scratch.

I wonder if something like that should be built on top of GitLab now that you have migrated to it. GitLab CI supports multiple runners for a single job, so the workflow might be that you merge a merge request which modifies PKGBUILD/.SRCINFO, the CI picks it up and based on labels/tags dispatches it to different runners running possibly on a completely different architecture for building. The runners then send the artifacts back and the job publishes them. The nice thing about this is that most of the parts are already there handled by GitLab itself, you just have to draw the rest of the owl.

This doesn't help at all as you need to coordinate so-name rebuilds across multiple architectures. This implies you need to some way to orchestrate a staging repository and have building do rebuilds towards this repo interactively until all issues are solved.

Retrofitting this ontop of gitlab sounds painfull. I don't even know if we would like to be that tied to a singular forge.

Reply on news.ycombinator.com