I guess you meant last -w?
Yes it is last -w now. Basically it should now be fixed, user can create the spy file even if his username is longer than 8 characters. There should be no issue like before
PS: the changes are not reflected on the GitLab, the Pacman hook script is the old one pacnew-check.sh · main · Packages / extra / manjaro-pacnew-checker · GitLab
//EDIT: and, even if it works, the touch executable path is not starting with a leading /
???
where is the original ? hard to find in 170 messages …
If -w is used why today, add also rule (gitlab and codeberg) ??? polkit rule is only for delete file as root
(bretelle et ceinture ? ok)
The package has been updated, but the GitLab doesn’t reflect the changes in new package made to the hook script, exactly what I wrote, not sure where the confusion is.
The Polkit solution has not been applied, just the proper flag to last was added (hence no need for Polkit in this case). It fixed the issue, in theory. User creates the spy file as the user even if username is longer than 8 characters, and can delete it without issue now the proper flag was added to last command in hook script.
//EDIT ahhhh I see something weird, a Polkit rule actually has been added on Codeberg, but there is no need for that, as the proper flag was added to the last command. The Polkit file is not in the latest package anyway, not sure why it was added on Codeberg.
Guys, Sorry for the confusion. I have cooied the changes made by Patric in gitlab ( codeberg and gitlab work One as mirrors of other and viceversa ). Today as i Say modify the code with Patrick suggestions and release the 0.6.8 because in my local all work fine but when release It via pkgbuild no. For delete the pacnew-check.file Always ask a admin right. Then as a casuality see i forgot to add the -w flags at the last command and so release a new ver of the 0.6.7 code.
I m on smartphone so Sorry for the not use all code tag…
to EDIT
yes was my question
tag is 0.6.8 in both, so my question and change #179 are for next 0.6.8
I suppose for today a speed Fix (polkit rule was not compatible with rapid troubleshooting)
Yes, I found that out the hard way… that’s why the default fallback to uid 1000 was in there. It’s still probably not ideal, but it most likely will work for most users, as the vdhcoapp helper is a desktop-centric app, and most desktop user systems are run as single-user machines with a single account for graphical desktop login, thus uid 1000 by default.
In the case of the OS tooling in general, maybe it’s not safe to assume that the user’s default UID is 1000, as it could be a shared machine in a university computing lab, a pair-programming station, or some other multi-user system. Like I said, it was a hack 
to replace 1000 : pacman used by a “wheel” user, get the first in group (generally one by pc)
awk -F':|,' '/^wheel/{print $4}' /etc/group
?
EDIT : when i view source
Description = Installing JSON configuration file for current user ...
Strange as description for a package. this hook install only in pacman user but other ? At all users to re-install this package ?
an .install file is missing in PKGBUILD to document the manual install for other users or , at you to install for all users ? (in hook, loop in grep -E ‘:1[0-9]{3}:.*home’ /etc/passwd)
I can confirm that the change to last -w fixed the issue.
Hi, I’ve just switched from testing to stable, looks like everything is good.
I don’t know how to use the pacnew-checker, I tried to run it in console, nothing happens.
It’s only functional when upgrading which I’ve missed? (already run pamac update, nothing to do)
If there are no pacnew files it should not do anything when you try and run it.If there are when updating it should pop up and let you know.You can then decide what to do as it is a pretty simple program.
if the output of pacdiff -o is empty, the program will not open as there is nothing to manage.
Hei @Ste74, have you noticed the issue/bug I raised a few months ago?
Indeed my .mo file was not placed in the proper folder in my PR. Recompiling all the languages from the current .po files should fix it though. Or make a PR with both FR and FI .mo files in the proper places. I sent a PR with the previous file. But better to just let Ste74 recompile all the .mo files from the current language .po files.
@Ste74 can you please recompile the language files for French and Finish so it fixes the Finish language and update the French one?
Hello,
I’m here from the Manjaro forums announcement, stable updates section. Within there philm has linked to here, and another page.
I’ve read as much as I can, and perhaps I’ve missed it, but I still have not found any documentation that tells me as a user what to do with .pacnew and .pacsave files if I run this tool, or pacdiff.
Cool that you have made a GUI over the pacdiff CLI tool, but there either needs to be information telling the user how to respond to each issue that comes up with this, or with pacdiff. Otherwise the tool should be doing it for you.
You are the system administrator - it is your job to know.
Educate your self on the expected content of the files at hand
Impossible - files may be changed by user or system - there is no reliable method to deduce what action should be taken.
When you have a .pacnew file, it means one of the configuration files in the system has been modified, and the last update brought new modification of the original config file, so it creates a .pacnew file instead of overwriting the existing config file during update (because if the file is modified, it means the user made some changes to it so probably best to not overwrite it, right?).
It is up to you to know what to do with the config file and the .pacnew file, open them side by side and see the difference, and act after thinking about it.
Some files are NOT TO BE TOUCHED, like the /etc/passwd or the /etc/shadow files. There might be a .pacnew file one day but if you overwrite these files with their .pacnew, you basically break your system (but as a good user, you surely always have a Manjaro USB live system on hands, and surely make system snapshots with TimeShift in order to have the option to roll back the system when you crash the system by mistake, right?). So think about what you are doing when dealing with .pacnew files, what is this file for, a music player? probably you can just overwrite with the .pacnew. Is it for a critical system component? then double check you will not break the system, maybe ask on the forum.
//EDIT: @Ste74 Can you have a look please #11 - Mistake were made - Ste74/manjaro-pacnew-checker - Codeberg.org
//EDIT2: sent a PM to Stefano in case he didn’t see last edit.
Thank you omano, this is exactly the information I was looking for but could not find. Much appreciated! 
I noticed current version is broken, I believe because of this commit. I don’t understand the purpose of it, and it seems it was not tested, as you can not continue to next .pacnew when you have multiple, it indefinitely loops on the same .pacnew when you click “Do nothing”.
I made a revert commit, and I added a popup to warn people about specific critical system files (for now I added two files /etc/passwd and /etc/shadow):
Comments and changes/improvement to it appreciated.
I have uploaded the 0.6.10 version. Thank you… whitout translation for now…
I look for them, but never find any.