Hello community, here we have another set of package updates. Since I’m still recovering from my move back to Europe from Asia, I might be less responsive on the forum. So lets test these packages thoroughly so we can do another stable branch snap.
Current Promotions
Find out all about our current Gaming Laptop the Hero with Manjaro pre-installed from Spain!
Protect your personal data, keep yourself safe with Surfshark VPN: See current promotion
Manjaro, like many other open-source projects, relies on the generosity of its community through donations and corporate sponsorships to support its growth and development. These donations are essential in covering the various expenses incurred in the operations of the project such as server costs, software development tools, infrastructure expenses, training, flying people to events or conferences and the salaries of key developers. With the help of these donations, Manjaro is able to secure the necessary financial stability that allows the project to continuously improve and remain active. If you love Manjaro, consider to donate!
As you might have seen some of our team were able to attend FOSDEM 2023 and the conference proved to be incredibly productive for us. See our blog post for more.
Finding information easier about Manjaro always has been a topic that needed to be solved. With our new search we have put all Manjaro data accessible in one place and divided by sections so it makes it easier to digest: News – Manjaro
You will need to rebuild any AUR Python packages that install files to site-packages or link to libpython3.12.so.
Print a list of of packages that have files in /usr/lib/python3.12/ :
pacman -Qoq /usr/lib/python3.12/
Rebuild them all at once:*
pamac build $(pacman -Qoq /usr/lib/python3.12)
Use rebuild-detector to see if anything else needs to be rebuilt:
checkrebuild
* It’s recommended to clean your build cache first with pamac clean --build-files
Info about AUR packages
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.
System may hang during splash screen when Nvidia 570 drivers are used
A lot of users with older Nvidia cards report system hanging on Plymouth splash screen after installing Nvidia 570 drivers. In the past we had issues with plymouth in general combined with Nvidia drivers. Therefore we didn’t update plymouth in our stable and testing branch.
As a workaround splash could be removed from /etc/default/grub file followed by a update-grub cmd to remove plymouth from starting. Another alternative is to test the newer plymouth and give feedback if that solves the issue:
Similar to Arch we removed our [community] repos from our mirrors and servers. You may want to check your pacnew files or manually remove [community] and [kde-unstable] when used in your /etc/pacman.conf file.
2025-02-16
Update only regular repository packages first, no AUR
Follow the best practice of first updating only regular repository packages, followed separately by AUR packages.
Update regular repository packages first with
pamac update --no-aur or
sudo pacman -Syu
Then, if needed, update AUR packages.
Failure to follow this practice may result in the installation of packages that you may not need, and may cause problems. For further details, see:
update went well - now using kernel 614 and Gnome48
Within Gnome there are a couple of shell extentions that - as of today - are flagged as “outdated” (what is a kind of normal and has nothing to do with manjaro)
So the one who is depending on all the extentions might want to wait with the gnome48 update - or use “Disable version validation” for the shell extensions - the ones I have installed are working even without explicitly being enabled for 48.
And do not install/enable other extentions as long as you enable `“disable version validation”. … as this migth lead to completly unsupported extentions being installed.
if the extension works using “Disable version validation”,
then (I did) edit the file metadata.json and add version 48…
Without validation there is the danger of installing
“really NOT compatible extensions”
thanks for your reply… this is what a forum is about … talking and learning and helping. Much appreciated!!
My understanding (but I may be completly wrong):
Changing manually in the .json the approved version to … e.g. 48 means, we - as the user of the system, but not the developer, states, that the extention is approved for 48. Hm … ok, this just makes the installed extension work, but it is not validating anything…
From my understanding … “disable version validation” has the same effect: just ignoring whether there is a version number in the extension or not.
Agreed - for very old extensions - this is a difference. But for the currently installed ones, the outcome is the same.
As long as someone is not installing new extentions (very old ones) there is no difference.
Will update my post with "and do not enable other extentions as long as you enable `“disable validation”.
Hovering over native Wayland windows sends the cursor into fits of flickering. Before the update, it ran quite smoothly regardless of application.
XWayland windows and gnome shell components do not seem to cause flickering when hovered over.
EDIT:
Done some further testing. Wayland-native GTK4 applications that, as of now, lack the new blue tint (e.g. Inspector, Rnote, Apostrophe) don’t seem to cause any flickering.
I have been using Brave browser with keepassxc for secrets storage (my shortcut launches Brave with the command line argument --password-store=gnome-libsecret %U ).
This was previously working fine - KeepassXC loaded and asked for a login. This broke with the most recent update. The culprits was
I seem to recall that the org.freedesktop.secrets.service file previously did not even exist (as of a few months ago) and I had to create it. Can anyone shed more light on this?
make sure to actually install grub to your EFI/MBR to apply them: install-grub
Haven’t done this before, so I just wanted to confirm that the command to do this on a typical (UEFI) setup would be: sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Manjaro
As long as you now have “manjaro” defaults and no advanced configurations like FDE (full-disk encryption) or possibly dual-booting into windows (I wouldn’t advocate this anyway but YMMV,) and you also have the packages install-grub and update-grub installed, then new updates to grub should automatically be installed without further commands like yours. With that being said, anytime you’d like to make changes to the grub file (for example, adding or changing linux kernel parameters,) or perhaps regenerating the initramfs images, then you’d follow up (after saving the grub file – if you modified it) with a sudo update-grub.
You can verify the currently-installed version of grub by rebooting and entering its menu by spamming the default “shift” key during the grub countdown past the initial bootup after your post test in the bios/uefi.
With all that being said, it is absolutely ESSENTIAL to pay attention (line-by-line) to pacman or pamac’s output after doing these updates. A subtle error could easily be missed during alpm hooks and that could warrant an immediate, manual intervention while you’re still booted into your system instead of chroot later – which you should also know how to do, have a minimal .iso live installer on a usb drive for this very reason, and be comfortable with basic commands. If you miss any subtle errors – that’s for sure on you.
Very wise advice. I don’t think I have ever left my PC unattended during an update in the entire 20 years that I have been using Linux. I’m very watchful of what is being done during an update.
And, although I do keep a very careful eye on output during updates, as a backup I find the paclog command (part of the pacutils package) to be very useful. It is very easy to use:
To view the full log:
paclog
To search for a term in the output (such as “grub”):
paclog --grep=grub
To view the log for and after a certain date (say, 2025-03-26):
paclog --after=2025-03-26
All available paclog options (paclog --help):
paclog --help
paclog - filter pacman log entries
usage: paclog [options] [filters]
options:
--config=<path> set an alternate configuration file
--root=<path> set an alternate installation root
--sysroot=<path> set an alternate installation system root
--debug enable extra debugging messages
--logfile=<path> set an alternate log file
--[no-]color color output
--pkglist list installed packages (EXPERIMENTAL)
--help display this help information
--version display version information
filters:
--action=<action> show <action> entries
--after=<date> show entries after <date>
--before=<date> show entries before <date>
--caller=<name> show entries from program <name>
--commandline show command line entries
--grep=<regex> show entries matching <regex>
--package=<pkg> show entries affecting <pkg>
--warnings show notes/warnings/errors
After a search came across this similar issue on Mint’s forums, I believe it may have something to do with /etc/grub.d/00_header As I consider myself a technically savvy noob, I’m not brave enough to attempt editing it without being sure about what the command will do (especially since it’s from another distro and old).
After reverted patch released, sudo update-grub forced grub to honor the value I’d set (not running this left it at 30 seconds).
You will need to rebuild any AUR Python packages that install files to site-packages or link to 
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.
2025-03-26
