Is ArchlinuxARM project still alive? Or just build failures?

[adam900710]

Hi,

I really love ArchlinuxARM, but recently the project is in a more zombie like state.

Important core packages like glibc is already a full version behind (2.35 in repos, 2.36 upstream).
Qemu-system-aarch64 is unable to install after 7.0 update, and is also one full version behind upstream (7.0 in repos, I have to compile my own 7.1, while the github repo for PKGBUILDS already go 7.2)

And ironically the 7.1 qemu build failure looks like a bug in glibc 2.35, which causes the qemu-user-static to fail, thus fail the whole qemu group.

Kernel is also one version behind (5.19.8 vs 6.0.12).

Is there some big problems in the auto build system? Or is the project already in a zombie state?

[graysky]

The project is very much alive with new packages rolling out all the time. Toolchain bumps are not trivial when covering multiple SoCs/targets more time is spent testing/insuring everything works. Not sure why linux-aarch64 hasn't been updated in a while.

[karog]

$this->bbcode_second_pass_quote('graysky', 'N')ot sure why linux-aarch64 hasn't been updated in a while.

[adam900710]

Personally speaking, if older arch is a burden, in a pure Arch style, we should drop them, just like upstream Arch dropping 32bit x86.

Especially I didn't see much sense supporting them, when native compiling is a too slow.

Or at least, just roll out aarch64 first, since those arches are independent to each other, no need to wait for older archs.

Another thing is, if we're really going to be the Archlinux for ARM (at least aarch64), we really need extra cross tool chains.
With the lack of arm toolchain for aarch64, we can not easily compile packages like edk2-virtarm (recently renamed to edk2-aarch64) and ATF (required by rk3399 uboot).
That's exactly why manjaro added their own package for gcc.

I know those extra things can be a huge burden, but with more and more aarch64 boards coming, still spend a lot of time on older archs is really not the correct way to go IMHO.

[piotro]

Just some additional insights about current state of things :-

(just FYI - not complaining; as i still love archlinux)

https://forum.endeavouros.com/t/eos-ins ... 8?u=warpme

[CounterPillow]

I've tried contributing to packages but my PRs have mostly been ignored. It seems like there is a general culture of not wanting outside contributions, while at the same time having bitten off too much to chew for the people who are active to work on this in their free time. This is extremely frustrating for both users and prospective contributors because you do not clearly communicate that outside help is more effort than it's worth to review and that this is essentially just someone's "take it for what it is" personal project. Those frustrated users will then be passive-aggressive towards the distributions few remaining maintainers, which is not fun for them either.

A few things on my list of changes I'd like to see, but don't see happening any time soon, ordered by likeliest to happen first:
$this->bbcode_list('1')

Generic kernel gets updated to something not months out of date

Toolchain gets updated

We get informed when a large rebuild is happening, and how many packages will be affected

arm-none-eabi toolchain gets packaged for u-boot of rk3399 etc. devices

We get a proper bug tracker, even if it's just something like github issues, where things can be closed and referenced in PRs and labelled and what have you

People submitting pull requests get a response

Images for new devices (especially the ones with mainline kernel support)

The natural graysky response to any of the raised issues will be "go use something else if you don't like it", to which my response is: I already am. Getting RK356x support enabled in Debian's kernel was a much easier time than getting ALARM to do this, and Debian is bureaucracy hell. I'd still like to use an Arch Linux userland on ARM64, since Arch Linux's packaging tools are generally speaking pretty okay, in stark contrast to Debian's... things. Which is why it's a shame this project seemingly has driven itself into a corner where only a few people have access to the repos and build infra, don't have enough time to onboard new contributors, and don't have enough time to maintain the current set of packages.

This isn't me trying to be hostile, dismissive of your work, ungrateful or "unproductive", I just genuinely hope there is some realisation that the status quo isn't working well for the distribution, its maintainers or its users, and that some change needs to happen that leads to a lesser workload on the existing contributors.

[lynix]

This will get me some hate but I'd like to add that the 4+ months old kernel (linux-aarch64) is affected by a number of CVEs.

I know this distro is based on the spare time of volunteers and that sometimes life happens and you suddenly have no time to spare, that happens. But putting out a distribution for others to use, IMHO, brings some level of responsibility.

And if it's not the responsibility to keep core components (somewhat) up-to-date then it's at least the responsibility to be transparent and tell people that you currently can't make it and that stuff is going to be unmaintained for a while.

This way they get to decide whether they are fine with that or have the possibility to migrate their machines to a different distribution in case security is crucial for them. If you don't communicate then you take that option from them and accept that their boxes are potentially vulnerable without them noticing.

What I can't get my head around is that the kernel maintainer seems to be too busy to update the package or even look into pull requests where people have done that for him, but at the same time fans out dozens of updates for extra or community packages. But who am I to judge his decisions how to spend his spare time. Maybe there are valid reasons for doing so.

[solskogen]

And by the look of the huge amount of pull requests that have gone unanswered, it looks to me that people are trying to help but to no avail.

[adam900710]

Glad to see finally qemu/libvirt got proper update recently.

Sad to see a lot of people are having the same problem submitting PR but mostly get ignored.

During the time period we're stuck with older kernel/glibc/qemu/libvirt or whatever core component, I tried my luck with Debian Sid.

A lot of things are not done properly in Debian (from their packaging policy to lack of dtbs support), but at least their builds are working and uptodate.

I really appreciate all the work already done by all those awesome guys, and hope ArchlinuxARM to be better and better.
If you guys have some problem related to the workload, please allow us to help, and give us some feedback.

(And I have some ideas to reduce the workload, but would open it in another thread)

Thanks.

[graysky]

Some PRs are likely ignored due to not following the rules for submission.