Status of ARM Stable Updates: No Major Update Since March 2024?

Hello, please don’t take this the wrong way. I appreciate your time and work on Linux Manjaro, and I understand that some things simply take longer sometimes.

As far as I can see, the last major ARM Stable update was in March 2024, which means it’s been more than 7 months. Looking back at previous updates, this seems like quite a long time, especially for a rolling OS.

I find bug fixes and security updates very important, but maybe I am missing something?

2 Likes

See: Manjaro's Weg in die Zukunft - media.ccc.de

It takes some time due the lagge of ALARM activity, that may change soon.

2 Likes

Hi,

I’m not a power user but I switched to unstable branch with success, so far the OS is stable.

Look the last unstable update, the feedback are looking good.

1 Like

Hello, thanks for the information and the link to “Manjaro’s Weg in die Zukunft”. I hadn’t seen the video before.

As I understand it, there are both positive and negative aspects:

  • Positive: A new branch structure will be introduced, and the old boxit system will be replaced by bxt. This change should allow the branches to be updated faster and automatically.
  • Negative: Unfortunately, this also means that the previously independent ALARM project will no longer be actively maintained.

I really hope the situation around ALARM changes before the transition. Kernel-LTS and Node.js-LTS updates are especially important to me.

I use Manjaro ARM headless in production for Pi-hole and the SmartHome system ioBroker, so I prefer the stable branch. Even though the unstable branch is currently running well, there’s no guarantee it will always be like that. I’d rather avoid having issues after an update. Of course, I do regular backups, but ioBroker should run without interruptions, and having to restore because of an update issue would be quite annoying.

1 Like

Hi @jolic, thx for asking what the situation with stable updates on ARM are. It is a little complex. You can check the packages mailing list to see how many syncs, pushes or commits were done to the binary packages repositories and by whom.

x86_64 architecture is more active as more people are using it. Even when you use ARM parts of Manjaro, most likely you will also have some x86_64 machines you might run at your home with Manjaro too.

When we look back to i686 architecture, Manjaro also had to maintain that architecture too. So a sync from Arch would also pull those packages to Manjaro. However, that architecture was dropped at some point. Regardless of that, package maintainers had to compile our overlay packages for both architectures back then.

When we talk ARM then the upstream distribution is currently Archlinux ARM or short ALARM. They do push packages to their repos and update their stuff. However, there might be a misunderstanding on how we get the packages from Arch or ALARM.

Well, it is still a manual process via our tool boxit. You might see daily updates on unstable branch for x86_64 simply cos our developers and package maintainers call boxit sync when ever they see a need to do so. On ARM side this happens not so often or for some months not at all.

There will be some updates to arm-unstable branch, but those might be just kernels or few packages.

The overall concept however is simple but get kinda complex on ARM, more than it is on x86_64. So what is the magic behind stable updates?

  • first, a developer or release manager is syncing from ALARM via boxit sync
  • then we normally discuss and check possible todo-lists from Arch and if ALARM adopted those.
  • then our overlay packages might need rebuilds or updates to possible library changes made by the upstream distribution
  • when that is all done the actual fun begins. ARM is not like x86_64 where we can assume on an AMD system Plasma, XFCE, GNOME and other desktop environments might work similar as on an Intel system. Sure there will be different graphic cards like AMD, Intel and Nvidia in the mix, but there mostly the drivers work. On ARM however we have different SBCs and some more commercial like devices like Pinephones, Pine64 laptops and some other MiniPC like devices from other vendors. All those have different firmwares and boot files plus also different kernels and drivers sometimes. So a Rasberry Pi4 might work but for some odd reason a Pi5 not. Or some SBC with Rockchip SoC act differently. Then you might need to discuss within the team or testers, who have that device on how to debug it or simply ship it knowing we will break some installations. Mostly developers even test packages first locally before they get added to our repositories. On x86_64 we normally ship and test after. ARM is more fragile in that regard.
  • lets assume those tasks all succeeded somehow, then we do the snap to arm-testing
  • hopefully some community testers will then pick up those updates and give it a swing. Based on their feedback we will fix remaining issues and push the set to arm-stable
  • then the device images get created and tested again on all devices we currently support. when that is done the release announcement is written and published on our forums
  • then another sync from ALARM to arm-unstable happens and the cycle repeats

So the whole process we somehow managed to do in 2 months. However, since the ARM team changed and not all supported devices are at our end for testing, less updates were made to arm-stable branch. Device images are currently only auto-generated but not tested at all.

So how to change that? Well, first we have to reduce all supported images and only focus on the few we might have devices on our end. Then we might need more people who might want to join the ARM team on our end and pick up what old members left of. When new tools like bxt get introduced at some point our workflow needs to be adopted or changed.

When I started Manjaro with friends 13 years ago, we just wanted a simpler Arch and don’t case Arch when they updated their repos, hence we cloned them to our end and had all the time we needed to update our packages. The team was small and we were agile.

Now the project has grown and has even more architectures than it had before. So we might also need to grow our team to give better support to those who use this distribution.

I tried as interim release manager for some time, but my time is very limited these days.

4 Likes

I don’t know how stable it might be but here I tossed over 10.146 packages to testing branch: [ARM Testing Update] 2024-10-26 - package updates from the last 5 months

3 Likes

Hello @philm, thank you very much for your time and detailed response. I can understand well that you need more time and manpower for the ARM architecture, which is currently less utilized.

I’m not exactly a developer myself—when I code, it’s usually small tools or functions that I’ve taught myself, which I also enjoy sharing on forums or GitHub. So nothing like a real programmer who’s learned everything from scratch.

I’ve been using Manjaro x86_64 (KDE) for several years, and I particularly like the stable, rolling OS. That’s why about a year ago, when I had to replace my Debian stable system on the Pi4 for ioBroker again, I decided to try Manjaro ARM—and I was impressed by how smoothly it worked. Personally, an ARM stable update every 3-6 months would be totally fine for me, though I know that might not be true for everyone.

So, I wonder if there’s a way I could support you. I still have a Pi4 in my drawer and could install the latest ARM testing update on it in the coming days. Then, I’d be happy to test how it works with my configuration, especially with pi-hole and ioBroker, and report back to you. I hope this small approach could be helpful to you.

One more question: Since the ARM team has been reduced and therefore fewer stable updates are released, I’m curious about the long-term plan—whether ARM will continue to be supported on the Pi4 and Pi5 architecture or if I might be better off returning to Debian stable.

Thanks,
jolic

PS: In the past, I’ve financially supported some projects that I found to be valuable. If ARM continues to be maintained, I’d be happy to support you as well with an annual one-time donation.

2 Likes

This is pretty much all I do now. I had to scale back my work since my heart attack. I build the 6 new latest pi kernels a week along with the boot related packages and eeprom and push them to unstable. I will continue as long as I am able to do it.

@philm is fixing to snap testing to stable in the next few days. That will put all of the branches with the same toolchain. So you would be able to install the latest kernel and other pi related packages if needed from unstable branch and still use the stable branch for the other packages. You could do that anyway regardless of toolchain version if you do not have any DKMS/3rdparty modules to build.

1 Like

Hello @Darksky, that sounds truly impressive, and it’s great to see you still so engaged despite the health setbacks!

It’s fantastic to hear that @philm will soon be syncing the testing snapshot to stable, allowing all branches to use the same toolchain. This will definitely make it easier to install the latest kernel and Pi packages from unstable while keeping the rest of the system on the stable branch. This flexibility will surely benefit many users, especially those who don’t rely on DKMS or third-party modules.

Wishing you all the best, and I hope you can continue contributing to the community for a long time to come!

jolic

1 Like

The pi packages I keep up to date each week in unstable are:

linux-rpi4 linux-rpi4-headers
linux-rpi5 linux-rpi5-headers
linux-rpi4-mainline linux-rpi4-mainline-headers
linux-rpi5-mainline linux-rpi5-mainline-headers
linux-rpi4-rc linux-rpi4-rc-headers
linux-rpi5-rc linux-rpi5-rc-headers
raspberrypi-bootloader
rpi4-eeprom
rpi5-eeprom
raspberrypi-utils

I try to make a post as each package get’s upgraded in the Raspberry Pi Kernels thread.

2 Likes