On my old Intel desktop system, running KDE PLasma 6.1.5 in Wayland, a problem that started in the previous stable update, 2024-10-01, is still present in this update:
The mouse pointer appears as two columns of dots and dashes, the columns are 3cm appart and 3cm high on my screen, if the dots and dashes were merged they would probably form the expected pointer. My temporary solution is to use X11 instead of Wayland.
in the end, I ended up adding the line to /etc/fstab:
/home/deemon/autogit/localrepo /localrepo none bind,ro
(didn’t even need to change the ownership of files to alpm as suggested as the files had already read access for anyone)
If its anything like this other related thread you might want to check on if you accidentally replaced core packages with AUR variants.
Thanks, that helped! Although after restart the service was inactive (dead) and the widget wasn’t showing again, but restartnig the service helped. I’ll try waiting a little longer after restarting again, hopefully it’ll boot up on its own.
Would potentially suggest a bigger warning in pamac when a package transitions from the main repos to the AUR, as its practically silent atm, and this can clearly cause pretty big issues.
I would agree plus some more, but I dont use pamac.
If you do I would suggest disabling the AUR and/or making sure to use and update it separately from your repo packages.
I agree. Maybe a separate warning for the update option.
Me personally, i have enabled flatpak and aur, but not the updates. That way i use pamac gui as a search browser, but i only install repo packs through it (and it doesn’t upgrade to aur!), flatpak goes through flatpak, aur through yay.
I think it’s a bug with libinput-gestures on Wayland: using three fingers will trigger this weird bug and “stuck” the whole system like the Alt key is pressed and kept pressed. Tested and no issue on X11.
Removing libinput-gestures solved the issue.
my XFCE and KDE updates worked without any problems … just a few custom icons can no longer be assigned, I don’t see any other issue a.t.m.
My core business browser - Brave - repeatedly crashed after the last update, whenever I tried to move a bookmark from one folder to another. The same thing happened on Brave Beta & Chrome. I rolled back using Timeshift & everything was fine. I updated Brave on it’s own this morning - it’s working perfectly. I have no idea what is causing this issue. I have run Manjaro on this machine for 6 years, with almost zero problems, which is incredible. I have not found a solution as yet & will avoid updates until I do. More power to Manjaro & the community…
I’m not certain that’s a particularly wise choice.
Perhaps it would be more useful to see if you can reproduce the issue, to rule out that it might have been a fluke occurrence.
Of course, that’s entirely up to you. Cheers.
BTW, that’s a great avatar you have there…
A real Disco Cat. 
A post was merged into an existing topic: Window decoration broke after update
@ruziel ^^ you may want to read troubleshoots …
Hi @philm - I’m not sure if I’m understanding the Trouble Shooting section but I checked my system & I already have adwaita-icon-theme-legacy-46.2-3 installed. Thanks for your message, R
EDIT - I actually misread my system & only actually had 46.2-1. I have upgraded & rebooted - everything is 100% now.
Much appreciated!! 
I collectively applied the 2024-10-01 and 2024-10-10 updates on my desktop PC and noticed two potential issues during the install/update…
#1
[2024-10-15T08:40:42-0500] [ALPM] warning: /boot/grub/grub.cfg saved as /boot/grub/grub.cfg.pacsave
[2024-10-15T08:40:42-0500] [ALPM] upgraded grub (2.12-4 -> 2.12-7)
… the mentioned pacsave does not exist! Is this cause for concern? Should I manually extract the conf from the package file to compare?
Related query… I installed pacman-contrib and tried out pacdiff… seems it will only remove the pacnew if both sides of meld are identical (meaning updating/saving both sides)… which I thought was odd. Is this to be expected?
This raises a second question… if the pacsave file did exist, would pacdiff have caught it and brought it up for review?
#2
[2024-10-15T08:40:37-0500] [ALPM] warning: directory permissions differ on /etc/bluetooth/, filesystem: 755 package: 555
[2024-10-15T08:40:37-0500] [ALPM] upgraded bluez (5.77-1 -> 5.78-1)
Is the filesystem directory permissions correct, or the package?
No — ignore it.
The filesystem permissions are correct, and the package’s requested permissions are wrong.
This situation has existed for well over a year already, at the very least. The developer of the package doesn’t appear to understand UNIX permissions, which is ironic, given where they are employed.
Rationale: The directory and its contents are owned root:root. The root account (and any process running with UID 0) always has write access to everything that’s on a writable filesystem — things are implemented that way at the kernel level. It is therefore completely meaningless to remove the write permission for root on root-owned files or directories.
All went smooth,
I did have to rebuild the key rings, though, but…I call that a bonus… 
This WIKI-post did help. After that, it was smooth sailing.
And 
I learned how to rebuild the key store! 
Melissa
Just for the sake of completeness, it seems that is actually a change in systemd which is the root cause of this…
When it was reported as a bug:
Arch package maintainer said it was because of upstream he did this commit:
A change that seems to have its origins from this discussion:
And indeed, now with a
cat /usr/lib/systemd/system/bluetooth.service
One can see
ConfigurationDirectory=bluetooth
ConfigurationDirectoryMode=0555
But not everybody seems convinced, see maxnikulin comment
Or the comment of the Gentoo package maintainer, even if he did make the change
Seems to me like yet another attempt from systemd to reinvent the wheel and drift away from the UNIX philosophy and KISS principle…
I get those same Plasma Workspace errors.