Status of ALARM project

I was off for quite a long time and I didn’t check every topics but I thought it could be a good thing if I inform you about the status of ALARM project.
Manjaro ARM packages rely upon some of theirs and some are even directly from their repo.
I hope this will revitalize the project because unfortunately some packages are quite old (glibc for instance).

1 Like

I have been watching that thread and others for a while now and I am still in the dark what is going on. There is very little response from the “Powers to be”. A few of our packages are now broken waiting for them to upgrade some packages. I have my fingers crossed hoping things start flowing again.

1 Like

Personally my priority is currently more on x86_64 of the project and not on ARM. A toolchain on ALARM can take longer than on x86_64 cos the ALARM team is not so keen in how the toolchain works in general, so Arch developers from x86_64 have to guide them mostly. Also it is general known that some parts of ALARM take longer to be updated.

Currently there was a ICU update and I asked for other packagers of the ARM side of things to check if some is still broken. I’ve the feeling that packagers only maintain their own packages they may have interest in but don’t help or adopt other packages, which are more basic nature.

So yes the ARM team as to reorganize and find a way to also maintain other packages as needed. Package updates per architecture can be followed here: The manjaro-packages Archives

1 Like

I think that’s the main issue even if we can see some commit that are not applyed… :frowning:

I don’t know if they will be able to softly manage the toolchain but it is a very BIG thing for our package lineage.

BTW, thanks for all your work !!

1 Like

The main issue I see with the current ARM toolchain is that is appears to miscompile one of the applications shipped on the Plasma Mobile images:

Hi,

Firefox status on arch arm
https://archlinuxarm.org/packages/aarch64/firefox

Firefox status on Manjaro arm
https://packages.manjaro.org/?query=firefox&arm=on

They have not built firefox 117 yet, It will show up here when it is done.

http://fl.us.mirror.archlinuxarm.org/aarch64/extra/

1 Like

should we move to another distro or just wait?

I believe they are doing their best they can. I’m not going anywhere.

1 Like

ALARM start update :smile:

1 Like

I saw that today. Hopefully our mirrors will sync soon. :heart_eyes:

I need to rebuild kodi-rpi-git.

2 Likes

Saw Chromium 117, Firefox & newer Mesa on archlinuxarm.org.

I suppose kodi-rpi-git might work on Amlogic S922X.

1 Like

No clue. It is based on using v4lm2m for h264/h265 but it will only do HW decoding while running in a TTY (Ctrl-Alt-F2 running “kodi-standalone”). It will run in a DE but no HW decoding on the RPi. The same with kodi-rpi.

You can always try it out and see what it does. Right now the 2 kodi-rpi packages that work are in the testing and unstable branches.

The kodi-rpi-git packages needs a rebuild when our mirrors sync with upstream because of some previous new lib issues that was fixed with a workaround.

2 Likes

Hi @Darksky @Rip2,

Are you able to enable “v4l2” on Chromium-117 and how?

update gcc/glibc etc, how hard is?

updating the toolchain is not an easy task. even Arch x64 are struggling with that.

Not be hard. It’s just like making the whole os again lol.
When base pkgs like gcc/glibc it’s updated then all the pkgs that depend on it needs to be updated.

Then the devs come to know which pkgs are have problem compiling on new gcc/glibc.

1 Like

Not really. There is a high amount of backwards compatibility. A mass rebuild is usually done to ensure everything still builds, but for most packages, a rebuild is not necessary. Unless some change to the platform ABI is done in the toolchain packages (which as far as I know is not supposed to be the case in upstream GCC at least for C and C++, the last C++ ABI change was a long time ago and the C ABI is managed even more conservatively, so it could only be caused by changed distribution settings, which is a case of “Don’t Do That Then”).

A toolchain update normally requires much fewer packages to be rebuilt than, say, an ICU update.

By the way, what is the status of our version of glibc with regard to the latest critical bug? Critical Glibc Bug Puts Linux Distributions at Risk - Infosecurity Magazine
Generally speaking, I note that the life cycle of the main components of a distribution (kernel/GCC/glibc/python to name but a few) have all adopted a shorter life cycle.

Since the toolchain of ALARM is not being updated soon that glibc issue will be longer given with that architecture.