Ah I see, now it works
1 Like
I think the versioning of the Linux kernels is incorrect in the announcement.
3 Likes
Whoops! Fixed it. Thanks for pointing that out.
2 Likes
Youâre welcome! Glad I could help. 
Normally we only fast track security updates, however with the timing of the stable update and the quick 126.0.1 bug fix release, I will this time. Coming along shortlyâŚ
6 Likes
Tell him to evade chinaâs attack boats 
You mean ink (AUR) is not working with wayland?
My Eddie OpenVPN client is working flawless.
error: failed to prepare transaction (could not satisfy dependencies)
:: installing icu (75.1-1) breaks dependency âlibicuuc.so=74-64â required by qt5-webkit
:: installing icu (75.1-1) breaks dependency âlibicui18n.so=74-64â required by qt5-webkit
1 Like
Under this newer updateâŚall well except intrerestinglyâŚ
For System monitor 6.0.5 which sizes my 1 TB M2 SSD at 1.8 TB. Shows used space correctly but total M2 capacity is reported wrong FWTW.
qt5-webkit is an AUR package. Remove it and then do your update.
3 Likes
I use the AUR and ran into the same issue. What I did to solve it is simply uninstalling all gcc12 packages. For me that was gcc12 and gcc12-libs. I restarted and then ran the update and it worked with no problems.
sudo pacman -R gcc12 gcc12-libs
1 Like
Just prior to the plasma 6 updates (two updates prior to this one) gamescope 3.14.2-1 was able to correctly launch games using the -F fsr option within a Plasma 5.27 wayland sessionâŚ
gamescope -r 60 -o 30 -h 720 -H 1440 -F fsr %command%
Once plasma 6 was released, gamescope 3.14.3-1 was also introduced and steam games with gamescope in their launch options would load a blank/empty window where i could see the desktop through it. I reverted to using X11 as gamescope 3.14.3-1 seemed to work happily there.
After the plasma 6.04 release/update, I got more curious and did some additional troubleshooting under wayland. If I took the -F fsr option out, the game would launch but the steam overlay would not work. The workaround to correct both problems was to revert back to the previous version of gamescope 3.14.2-1 from the cache⌠and games were happily using gamescope (with overlay) once again under wayland.
sudo pacman -U file:///var/cache/pacman/pkg/gamescope-3.14.2-1-x86_64.pkg.tar.zst
I did a bit searching and found both my issues listed as separate issues atâŚ
- Games open in an invisible window since 3.14.3 when using FSR ¡ Issue #1237 ¡ ValveSoftware/gamescope ¡ GitHub
- Gamescope breaks Steam Overlay ¡ Issue #835 ¡ ValveSoftware/gamescope ¡ GitHub
The first link/issue seems to have âfix codeâ, but itâs not released yet (if I;m reading it right). The second link/issue does not yet have a fix listed, and hasnât had any new info hit the thread in a couple weeks.
With todayâs update (including gamescope 3.14.16-1), I was hoping something not listed in the links above might have helped to address the issue⌠as I still wasnât 100% convinced that plasma 6 was innocent, nor that gamescope held all the blame. Of course this was not the case as the same issues were present with gamescope 3.14.16-1 under plasma 6.05 wayland⌠but all was happy once again after downgrading gamescopeâŚ
sudo pacman -U file:///var/cache/pacman/pkg/gamescope-3.14.2-1-x86_64.pkg.tar.zst
Is any other âgamerâ using gamescope also experiencing these issues under wayland? Iâm curious if I have found the proper upstream issue(s), or if plasma 6 itself hasnât introduced itâs own wrinkles under wayland that are waiting for fixes.
For now, in case it helps anyone else, keep using gamescope 3.14.2-1 and block it from updating in your /etc/pacman.conf âŚ
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
IgnorePkg = gamescope
You are asking about a calendar plug in that was in Aur. Manjaro states over and over: AUR is not supported. So this is not an issue to report here.
However, in the AUR discussion page on Arch, they are trying to migrate to a fork that is working on supporting Plasma 6. So it is not dead I donât think.
If it is really useful to you, there is no reason why you couldnât do the migration yourself or hire a developer to update the forkâŚ
I am getting this error:
error: could not read db âextraâ (Damaged tar archive)
This command:
sudo pacman -Syyuw
solves the issue 
Hooks have changed in /etc/mkinitcpio.conf.pacnew, what should I do here?
/etc/mkinitcpio.conf:
HOOKS=(base udev autodetect modconf kms block keyboard keymap consolefont encrypt openswap resume filesystems)
/etc/mkinitcpio.conf.pacnew
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems fsck)
If that wasnât a typographical error on your part, I would suggest you have deeper issues.
On one of my installs, I got an error message at the very end of the install with the helpful message: âerror: program failed.â Fortunately, my journal gave more specifics and suggested a solution: âsystemctl enable tlp.serviceâ. The tlp service was in fact not enabled, so I did. Nothing seemed amiss even before this, so it was just to settle my curiosity.
Is the version of the mesa package on GitLab lower than the version of this update?
Can the dilemma be clarified a little?
@soundofthunder
After the system rebooted, the usual procedure ended up successful.
sudo pacman -Syu
You were right, it wasnât enough for my gear.
The obvious thing to do would be to hold off doing the upgrade until the announcement appears. Itâs not as if youâre forced to do it immediately as Iâm told Windows users are.
Donât forget, the developers are volunteers and have lives (and jobs?) to get on with as well.
5 Likes
Well, it resulted with further investigations (thanks to the folks of that thread) that it was (as it usually is) a user (myself) error. I had a dangling (but not marked orphaned, probably some âsuggestedâ dependency) qgnomeplatform-qt6 from AUR that was the final culprit. Removing it fixed everything.