Yes. You need to remove the now defunct [community] repo from your pacman.conf
(and you should also manage pacnews on your system as they populate … not just this one)
No.
Also overwrite /etc/pam.d/sddm in when running pacdiff -s (on KDE Plasma) ?
....
renamed '/etc/pacman.conf.pacnew' -> '/etc/pacman.conf'
==> pacnew file found for /etc/pam.d/sddm
:: (V)iew, (M)erge, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/m/s/r/o/q]
you can revert to pamac-gtk3
1 Like
my reply was at @BTO
if you @1efaf7d71a8637c6800a have not made any customisations to that file, then yes. That’s why the View option is there…to see what the change is. Otherwise keep your old file but edit it and remove the Community section from it.
1 Like
Thank you. the black-screen-after-login-with-sddm known issue above was lurking when I asked. Logged in fine after pac-re-newing the file, also after reboot. 
managed to solve this by
# pacman -R linux62-zfs zfs-utils
run the updates
# pacman -Syyu
installed the new kernel
# mhwd-kernel -i linux64
and lastly reinstalling zfs
# pacman -S linux64-zfs zfs-utils
at some point between reboots you need to take the old kernel out as well…
Be happy
Pamac logs out after every update. This is kind of annoying. Checked the /alpm/hooks/ scripts but could not find any that would do this.
Has anyone a clue what to look or search for ?
Running the xfce4 desktop flavor.
The log is in /var/log/pacman.log
In general, getting a database update error, I did the following, found the pamac.conf and pamac.conf.pacnew files, opened the first one in the editor, copied everything that was in the second. Saved, reloaded, the error disappeared. Flatpak and the old repository were registered in the first file, which is why there was an error (in my opinion), now everything is fine. Perhaps it will be useful!
I’m in a mess again. I had a few issues with Plex, ended up restoring a snapshot and trying to re-run updates.
So now I’m facing a few issues.
-
Running Pamac, it starts preparing. Then it pauses:
Waiting for another package manager to quit...and this isn’t pacman (database lock). When I select Cancel, it seems to continue - but fails to synch AUR and gives up. -
Keys are properly messed up.
`sudo pacman -Syu’ brings a list for the upgrade.
error: could not rename /var/cache/pacman/pkg/linux63-headers-6.3.12-1-x86_64.pkg.tar.zst.part to /var/cache/pacman/pkg/linux63-headers-6.3.12-1-x86_64.pkg.tar.zst (No such file or directory)
error: could not rename /var/cache/pacman/pkg/linux61-headers-6.1.38-1-x86_64.pkg.tar.zst.part to /var/cache/pacman/pkg/linux61-headers-6.1.38-1-x86_64.pkg.tar.zst (No such file or directory)
error: could not rename /var/cache/pacman/pkg/oxygen-icons-1:5.107.0-1-any.pkg.tar.zst.part to /var/cache/pacman/pkg/oxygen-icons-1:5.107.0-1-any.pkg.tar.zst (No such file or directory)
error: could not rename /var/cache/pacman/pkg/telegram-desktop-4.8.4-2-x86_64.pkg.tar.zst.part to /var/cache/pacman/pkg/telegram-desktop-4.8.4-2-x86_64.pkg.tar.zst (No such file or directory)
warning: failed to retrieve some files
error: failed to commit transaction (unexpected error)
Errors occurred, no packages were upgraded.
pamac upgrade --force-refresh --enable-downgrade --aur --devel Preparing...
Waiting for another package manager to quit...
- Next went with
sudo pacman -Sy gnupg archlinux-keyring manjaro-keyring gnugpg: signature... ...is unknown trust
errors leading to failure.sudo pacman -Sy gnupg archlinux-keyring manjaro-keyring… could not be locally signed.
There has not been an issue in stable branch with a .pacnew file for a long time now, and nobody seems to have considered that there are many more users seeing a .pacnew for the first time
It also seems to be no consideration that previous warnings were given a lot more prominence: in first post of update announcement with a warning icon
Testing update[2022-12-01]
There is only one .pacnew file so using pacdiff to check all .pacnew is not necessary
but users should check and merge any .pacnew file to keep system up-to-date
Or for the sudo afeard
Other users have since advised that kcompare and diffuse can be used to compare files
and some users choose to ignore all of that and just overwrite the .conf file with .pacnew file.
Those users may have issues in future with other .pacnew files that may need to be managed differently
Thank you, I had the same issue with another package.
And try updating the repository first, and than aur. (Pacman -Syu)
The smaller issue I mentioned above:
( In Nemo, when I search files, these CAN ONLY be viewed in List view, not Icon view, not Compact. All switching options are grayed out. )
May be fixed already in Nemo 5.8.4, from their changelog:
nemo (5.8.4) victoria; urgency=medium
[ Michael Webster ]
* search: Fix search directory view selection.
Hope also file view. Push this upgrade if tested?
After the update with pacman -Syu I notice problems on running applications or maybe to be more specific the applications run but it seems like there is an issue to create their screen/window.
For instance, Steam runs, I can see the icon in the taskbar (KDE Plasma), and I can run installed games, although they run a bit junky. I can shutdown Steam application through the taskbar’s context menu.
Once every 100 executions, steam browser may come up normally and use it normally.
This behavior of not creating/placing windows/screens I notice it from other applications too. Initially from gwenview but after rebooting it seems to be working fine ever since.
smaplyer/mpv also did not play videos but after the reboot it plays fine now.
I tried the fixes for Steam but did not help.
Update: steam --reset seems to fix the issue for now.
Feel free to test it then. nemo 5.8.4 is in the Manjaro testing and unstable branches.
1 Like
Archkeyring wont refresh.
$ journalctl -p 3 -xb
systemd[1]: Failed to start Refresh existing keys of archlinux-keyring.
░░ Subject: A start job for unit archlinux-keyring-wkd-sync.service has failed
░░ Defined-By: systemd
░░ Support: https://forum.manjaro.org/c/support
░░
░░ A start job for unit archlinux-keyring-wkd-sync.service has finished with a failure.
░░
░░ The job identifier is 3067 and the job result is failed.
$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● archlinux-keyring-wkd-sync.service loaded failed failed Refresh existing keys of archlinux-keyring
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed.
I recommend for using timeshift and create a snapshot befor you changing files.
Even if your system works after a restart at the moment, when you doing something wrong with editing, the next update could maybe fail.
And…?..
systemctl status archlinux-keyring-wkd-sync.service
$ systemctl status archlinux-keyring-wkd-sync.service
× archlinux-keyring-wkd-sync.service - Refresh existing keys of archlinux-keyring
Loaded: loaded (/usr/lib/systemd/system/archlinux-keyring-wkd-sync.service; static)
Active: failed (Result: exit-code) since Sun 2023-07-16 23:19:18 CEST; 8h ago
Duration: 12.591s
TriggeredBy: ● archlinux-keyring-wkd-sync.timer
Process: 17614 ExecStart=/usr/bin/archlinux-keyring-wkd-sync (code=exited, status=1/FAILURE)
Main PID: 17614 (code=exited, status=1/FAILURE)
CPU: 1.318s
Jul 16 23:19:18 koboldx-z170 systemd[1]: archlinux-keyring-wkd-sync.service: Scheduled restart job, restart counter is at 3.
Jul 16 23:19:18 koboldx-z170 systemd[1]: Stopped Refresh existing keys of archlinux-keyring.
Jul 16 23:19:18 koboldx-z170 systemd[1]: archlinux-keyring-wkd-sync.service: Consumed 1.318s CPU time.
Jul 16 23:19:18 koboldx-z170 systemd[1]: archlinux-keyring-wkd-sync.service: Start request repeated too quickly.
Jul 16 23:19:18 koboldx-z170 systemd[1]: archlinux-keyring-wkd-sync.service: Failed with result 'exit-code'.
Jul 16 23:19:18 koboldx-z170 systemd[1]: Failed to start Refresh existing keys of archlinux-keyring.