Explore the Holo Core aarch64 preview, with early binaries, sources, and containers for an Arch Linux-based Arm port backed by reproducible CI tooling.
The existing stuff needs to be adapted, not reinvented. In my time as packaging some software for my own use under openSUSE I barely seen software that needed adaptions in the package spec file for other CPU architectures. Emulators were the most common exceptions I encountered and even that changed a lot since then thanks to upstreams porting those to Android and Apple M processors. Collabora lists as main challenges the ability to access the upstream source codes for reproducibility, not “repositories, recipes, and support paths”.
Man, if it was that simple, ALARM wouldn’t exist and arch would have (at least) allowed aarch64 packages in the AUR years ago. There are other factors in play than what I listed above, but it’s still weird to not even mention the existing community efforts.
Reproducible builds are one step closer than what ALARM was already providing. It’s cool, but it’s still just one step up, and a rewrite. I don’t understand why Collabora went in this direction aside from having more billable hours.
Man, if it was that simple, ALARM wouldn’t exist and arch would have (at least) allowed aarch64 packages in the AUR years ago.
Arch’s policy is to offer only x64 binaries. They don’t offer ARM packages because they don’t want to. ALARM exists because Arch does not want the contributions.
While it’s not zero work, your claim of reinventing the wheel overstates what compiling software that’s already compatible with ARM requires.
I’m reading what Collabora wrote and nowhere is that blog post did they state that compiling stuff for ARM and the packaging are the hard parts. They explicitly called out the reproducibility parts, not the rest.
If your small community project with dead forums and broken logs (see below) can do it, a team of full time Linux engineers can do it in a relatively small amount of time, probably with logs.
Package repositories, recipes, and support paths
The existing stuff needs to be adapted, not reinvented. In my time as packaging some software for my own use under openSUSE I barely seen software that needed adaptions in the package spec file for other CPU architectures. Emulators were the most common exceptions I encountered and even that changed a lot since then thanks to upstreams porting those to Android and Apple M processors. Collabora lists as main challenges the ability to access the upstream source codes for reproducibility, not “repositories, recipes, and support paths”.
Man, if it was that simple, ALARM wouldn’t exist and arch would have (at least) allowed aarch64 packages in the AUR years ago. There are other factors in play than what I listed above, but it’s still weird to not even mention the existing community efforts.
Reproducible builds are one step closer than what ALARM was already providing. It’s cool, but it’s still just one step up, and a rewrite. I don’t understand why Collabora went in this direction aside from having more billable hours.
Arch’s policy is to offer only x64 binaries. They don’t offer ARM packages because they don’t want to. ALARM exists because Arch does not want the contributions.
While it’s not zero work, your claim of reinventing the wheel overstates what compiling software that’s already compatible with ARM requires.
I’m reading what Collabora wrote and nowhere is that blog post did they state that compiling stuff for ARM and the packaging are the hard parts. They explicitly called out the reproducibility parts, not the rest.
If your small community project with dead forums and broken logs (see below) can do it, a team of full time Linux engineers can do it in a relatively small amount of time, probably with logs.