If you don’t tweak the configuration files I’d expect this to be the case and it’s nice to have a report suggesting that it indeed seems so.
Thank you for your work! I Followed the hint “[community] repo removed from servers” from the actual update 2025-03-05 and tried:
- Unpacking the ZIP and run it
bash pacnew-checker.sh - Installed it using pamac and run it from application menu
In case 1.) it seems to run for 1…2 seconds, in case 2 I can not see any reaction, no message is shown. What am I doing wrong?
After that, I checked /etc/pacman.conf and found for te keywords [community] and [kde-unstable]:
[community]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist
Your recommendations highly welcome.
change this:
[community]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist
to this:
#[community]
#SigLevel = PackageRequired
#Include = /etc/pacman.d/mirrorlist
or just delete those three lines
then run:
sudo pacman-mirrors -f
to refresh the list of mirrors
No idea what the [kde-unstable] repo is about or why you have it.
Probably comment these lines out as well if you don’t know why it’s there.
But you must have put this there yourself …
1 Like
Thank you @anon33601770 I followed your advices and comment out those lines and refreshed the mirrors; I’ve not yet started today’s UPdate.
What reaction should I get from manjaro-pacnew-checker, that I installed as described here?
I do not know - I don’t know what it checks for.
But this change will remove the community repo, which is causing your issue
because that repo does not exist anymore
After performing an update;
sudo pacman -Syu
manjaro-pacnew-checker should indicate whether any pacnew files exist – it checks for them and prints any that exist at the end of the update – beyond that, you should attend to them using whichever method you choose.
1 Like
In this case - when editing the original file - the corresponding .pacnew will still be there,
and probably still be detected - but can then be ignored
I don’t think you can start manually Manjaro Pacnew Checker (anymore?).
After an update, if the post update hook script finds .pacnew files, it creates a temporary file, and if this temporary file exists, then it auto starts Manjaro Pacnew Checker (because there is a service periodically checking if this temp file exists).
You can, for a test, copy the file, let say /etc/makepkg.conf, to /etc/makepkg.conf.pacnew, then trigger an installation, for example sudo pacman -Syu nano, it will detect .pacnew file, and after a few seconds it will auto start Manjaro Pacnew Checker.
PS: I guess for further issues with Pacman configuration about repositories, a new thread could be created (or all the posts could be moved to new thread). This is kinda off topic.
Thanks for the explanation how to test the functionality of this tool.
For me, everything was working well and I was surprised just how many .pacsave/ .pacnew files accumulated over the last years.
But now it hopefully shouldn’t happen anymore.
I think manjaro-pacnew-checker should be included in the default set of Manjaro’s packages, so that users who aren’t that much into Pacman’s internals, don’t get surprised at some point because their configuration doesn’t work anymore.
4 Likes
The pacnew-checker.path contains:
[Unit]
Description="Monitor the *.pacnew/*.pacsave files creations"
After=default.target
[Path]
PathExists=/tmp/pacnew-check.file
Unit=pacnew-checker.service
[Install]
WantedBy=default.target
Isn’t this a dependency loop?
This only runs after default.target while being required to complete default.target or am I misunderstanding?
[Install]
Like when you install?
Yes like the symlink, that is created when the unit is enabled, that writes the dependency on disk to be used whenever the unit is started?
Well, given that my question got ignored, I’ll answer it myself:
Yes, this most definitely is a dependency loop and running
systemctl --user status pacnew-checker.path
confirmed this for me, as it contains log messages informing about this loop.
Dependency loops get resolved by (randomly?) removing services.
The result is, that your system might act unpredictable.
Which was the case for me since I installed this (as many probably did when the community repos got removed).
As far as I know, removing the WantedBy line would cause the unit to not run, so I removed the After line, which resolved the issue for me.
I do not know if this unit actually requires the default target to be finished. If it does, this could cause issues.
I would very much like the maintainer to give this some thought. Thanks.
On my side I tried to dig into SystemD unit files and services documentation but I have to admit I left the battle early 
@Ste74
/tmp/pacnew-check.file is not created when pacnew-checker.hook is started in tty.
see this thread
Updates through TTY are sometimes recommended for larger updates of the desktop environment.
Please review if coding of manjaro-pacnew-checker could be altered for that scenario.
1 Like
why only use it between update and reboot?
Add a flag “–force” if you want run this tool after reboot
# if [[ ! -e /tmp/pacnew-check.file ]]; then
if [[ ! $@ =~ '--force' && ! -e /tmp/pacnew-check.file ]]; then
exit 1
fi
or before
if [[ ! $@ =~ '--force' ]]; then
touch '/tmp/pacnew-check.file'
fi
1 Like
I think the issue currently in TTY is that it needs an active GUI user to be able to create the temp file that triggers the GUI, because it triggers commands with sudo as the current active user.