[Unstable Update] April 2024 Edition

Welcome to the new monthly unstable branch thread.

Recent News

Noticeable Package changes

Known Issues

Additional Info

Info about AUR packages

:warning: AUR (Arch User Repository) packages are neither supported by Arch nor Manjaro. Posts about them in Announcements topics are off-topic and will be flagged, moved or removed without warning.

For help with AUR packages, please create a new topic in AUR and a helpful volunteer may be able to assist you.

Get our latest daily developer images now from Github: Plasma, GNOME, XFCE. You can get the latest stable releases of Manjaro from CDN77.

Check if your mirror has already synced:


3 posts were split to a new topic: Plasma Application Launcher Empty (Unstable)

:information_source: Increasing the default vm.max_map_count value

2024-04-07 - Robin Candau

The vm.max_map_count parameter will be increased from the default 65530 value to 1048576.

This change should help address performance, crash or start-up issues for a number of memory intensive applications, particularly for (but not limited to) some Windows games played through Wine/Steam Proton. Overall, end users should have a smoother experience out of the box with no expressed concerns about potential downsides in the related proposal on arch-dev-public mailing list.

This vm.max_map_count increase is introduced in the 2024.04.07-1 release of the filesystem package and will be effective right after the upgrade.

Before upgrading, in case you are already setting your own value for that parameter in a sysctl.d configuration file, either remove it (to switch to the new default value) or make sure your configuration file will be read with a higher priority than the /usr/lib/sysctl.d/10-arch.conf 1 file (to supersede the new default value).

1Note the Manjaro overlay file is /usr/lib/sysctl.d/10-manjaro.conf

Should you use 09 or 9 for priority that’s over 10? :thinking:
Never mind, my file is under /etc/sysctl.d/, so only a name change to 10-manjaro.conf is required.

You could use any number higher than 10. 11 or 99.

The higher the number, the later it is loaded, and therefor the more ‘final’ the setting.

If you want to make sure something is applied … you use 99-something.conf.

But in your example … 9 would come after 10. Which is one reason why we would follow the nomenclature to include the prefacing 0 if we had some reason to want 09 (as in less than 10).

Shell example
$ touch 09-something
$ touch 11-something
$ touch 9-something
$ ls
09-something  11-something  9-something

Huh? You should not edit the system file at /usr/lib.
If you mean you want to augment the new options using a config at /etc/systctl.d … then as above use 11+ .
And the extra terms can be anything.
99-custom.conf, for example.


Exactly. I had a file for this purpose under /etc/sysctl.d/. I’ve renamed it the same as the new file under /usr/lib.

(A week later, can’t have consecutive messages)

warning: gamescope-plus: local (3.13.19.plus0.14.g7f112d5-1) is newer than extra (

Looking at the ChimeraOS repo, the versioning seems to be all over the place :thinking:
My local package is from the end of January

Do a downgrade to get the latest version of gamescope-plus.

2 posts were split to a new topic: Warning after pacman upgrade

Yes - I know - I should probably have the team channel running at all times - so I may not be up-to-date with the recent decisions

But why? I thought the patch was in place to ensure that keyring updates was applied first thus avoiding invalid signature messages?

pacman 6.1.0-6 removes the sync-first patch

to avoid pacman complaining on an unknown option edit pacman.conf and comment or remove the lines

# If upgrades are available for these packages they will be asked for first
SyncFirst    = manjaro-system archlinux-keyring manjaro-keyring
1 Like


this is probably in the pipeline, but thought of posting anyway.

3 posts were split to a new topic: Install development ISO with Unstable

After the latest set of unstable updates, after reboot, I got corrupted/empty pacman.conf and pamac.conf and had to restore from their .pacnew files.

[2024-04-22T21:21:15+0300] [ALPM] warning: /etc/pacman.conf installed as /etc/pacman.conf.pacnew

6 posts were split to a new topic: Warning: config file /etc/pacman.conf ‘SyncFirst’ in section ‘options’ not recognised

:information_source: I’ll be starting Python 3.12 rebuilds shortly. I do not recommend updating for few hours.

EDIT: :white_check_mark: Everything should be (mostly) done. Let us know if we missed something.


9 posts were split to a new topic: Are rebuilt python packages being synced/replaced on the go?



I havent done much.
But seems to have gone off fine.
Reboot, login, and browser all work well. :slight_smile:

1 Like

:sos: My previous personal experience:
About a year ago I broke my OS by making it un-bootable by installing partial python packages updates (all that server provides at that time). I did not read the unstable thread first. It took me pure several hours to fix it but during some long period of time.

:exclamation: The problem:
a) Frequent (1-2 times a day) updates (as unstable branch usually provides) are not highly compatible with constant daily reading of the unstable thread prior each update to make.
Having updates 1-2 times a day it is unreal to check unstable thread first each time prior an update just in order to read predictable/awaited breaks of the OS, which could be prevented by improving maintenance of the unstable update method.
b) Moreover, updates by portions could lead to problems a days after it fixed by package maintainers: there are may be a servers which got only half of packages rebuilds and then they could break self-sync for a 1-2 of more days and nevertheless a user see a maintainer’s post that it is alright to update now, user still don’t know are their server(s) are synced fully with all portions of python packages or not.

All two items are problems.

:white_check_mark: Possible solution:
Instead of pushing python-rebuild packages partially into end-user branch (unstable) may be better to create a temp internal branch (for example pre-unstable or any other) and to push any package portion count, any number of days it takes to prepare major part of python packages need to be rebuilt, and only then it is ready - to merge/push bunch of all major packages of that temp branch into the end-user unstable branch.

That solution covers problems (a) and (b). But may be there are more suitable/comfortable solutions for maintainers.

I can’t see an option to start a poll to realize am I alone who lacks the single time push of all major python packages rebuilt into unstable branch or not.
I suggest to
{vote for some intermediate stuff and only if it is ready to push that package bunch into unstable}
{vote against some intermediate stuff}
by using thumb up/thumb down marks on this message.

Thank you for taking part in the discussion of that my (as end-user of unstable branch) problem!

All Arch rebuilds were already done and moved from Arch Testing to Arch Stable today mostly all at once. I then synced all of them (almost 3,000 packages) to Manjaro Unstable.

The Manjaro package rebuilds are pushed to the main server as they are built. Some are pushed sooner than others for other packages that require them to build, etc. Then it’s up to the mirrors to sync. It’s up to the user to make sure they are using up to date mirrors.