The whole thing about pacnews is that pacman recognized that the file it wanted to update was changed from the packaged version. The user could have made a configuration change or it could have been done on behalf of the user, but it’s a good bet the user doesn’t want to lose their configuration changes.
Several threads on the arch bbs regarding this update and the pacnew.
Bottom line, only change that line.
Only when necessary.
Nope. If it was present, and got removed, it wasn’t by me.
As for my issue #1, that didn’t involve file “/bin/fakeroot”, but rather, package “rebuild-detector”, so it does not appear to be connected to issue #3.
I was never the topic. The topic is philm’s request, “Please post your solution”. I simply complied.
I’ve been using Manjaro Linux, with multiple AURs, for several years, but I’ve never ran into “could not build AUR because binary file ‘fakeroot’ could not be found” errors before. (Indeed, I’ve had few problems of any kind with AURs; I’ve had far more issues with snaps and flatpaks.)
So either file “/bin/fakeroot” wasn’t needed before, or it was needed but was present (at that time), so the problem didn’t occur. But this update, for whatever reason, the file “/bin/fakeroot” was needed-but-not-present at the time Pamac attempted to update AUR files, so those updates failed until after I installed “fakeroot”.
Btw, running Ctrl-F on the Arch AUR page shows that the string “fakeroot” is not present on that page, so reading it would not have helped with my issue #3. Pamac, on the other hand, was very clear as to what needed to be done to solve issues #1 and #3, so those were easy fixes. Issue #2 was a bit thornier. (There’s also an issue #4 which I’m about to add, but that’s a whole other story.)
For years I’ve added a single line at the bottom of /etc/bash.bashrc. All local, system-wide changes go into bash.bashrc.local. I usually get a bash.bashrc.pacnew and just re-add the line. Check for a .pacsave.
[ -f /etc/bash.bashrc.local ] && source /etc/bash.bashrc.local
Your solution isn’t a solution at all…
…and it wouldn’t be a problem if you actually READ what prerequisites for using AUR are – as is expected from every user of AUR.
/bin is a symlink to /usr/bin so both lines will work. And keep the other lines untouched.
ls -l /bin ✔
lrwxrwxrwx 1 root root 7 ene 19 18:16 /bin -> usr/bin
Going through yet another update thread, I want to post a short note on my experience. I have been using Manjaro as my only OS for the last four years, and I am still on my first install since then. It was a new experience as I was switching from the Debian/Ubuntu world. I had to adjust my update habits to a whole new process. Doing a lot of reading, I came across two things that were extremely helpful:
System Maintenance
Update Manjaro the smart way
They are in my bookmarks, and I reread them every now and then.
Additionally, create, verify, and test your backups (obvious, I know, we all do them, right?).
Last but not least, keep learning your system. The Manjaro is a rolling distribution. It has perks, but with great power comes some responsibilities. 
Thanks Manjaro Team, and many happy updates to all of us.
fakeroot is part of base-devel which is mandatory when using custom build scripts.
The knowledge is mandatory - pamac may have had a basic check earlier - I think the present situation is that you need to know that base-devel is required possibly to raise more awareness to the casual user.
The text at the Third Party tab in Pamac Preferences states
AUR is a community maintained repository so it presents potential risks and problems.
All AUR users should be familiar with the build process
One of the topics within the familiarity, is to know the base-devel must be synced and the system is fully synced.
I have encountered an issue with this update.
I am using urxvt with i3, and additionally fcitx5 with mozc for japanese input.
Hitting the trigger button (alt + `) will not change the typed symbols in the console.
It works as expected (before the update) in other applications though, just the console is not working.
Fonts are installed and tested working, the console can display Japanese just fine.
Has anyone any idea where this could come from?
I am out of luck, and i am sourcing ~/.profile through a line in ~/.bashrc
This issue is fixed again.
Since the .profile file is no longer sourced, i added a line (source ~/.profile) to .bashrc.
This is wrong!
I found here that you should do things you did previously in .profile now in .bash_profile.
i moved the entire file contents over there, and now it works (of course disable the .bashrc line where i call .profile.
This really can’t be emphasised enough. I’ve seen the consequences of backups failing silently in my days as a data centre operator. The time those failed backups were needed and weren’t there cost the business something like £5m.
About the issue with the blue lines (errors/warnings) on boot, it was plymouth related. Obviously, removing plymouth and kms hooks was not enough, i also had to add the kernel parameters to disable it as per the guide above.
If you had updated with pacman instead of through the pamac GUI, then you would have seen the question to replace the package appear right at the top of the update process. 
An issue I had is using sd-boot+ukify+kernel-install+sbctl is that the sbctl hook in /etc/initcpio/post/ is broken. I had to fully comment it out. kernel-install has its own sbctl hook to sign a uki.
==> pacnew file found for /etc/passwd
:: (V)iew, (M)erge, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/m/s/r/o/q]^C
$ cat /etc/passwd.pacnew
root:x:0:0::/root:/usr/bin/bash
good job. 
That does seem odd. I’ve had a few AUR packages on this system for years … since I started using it (2017-ish?) and fakeroot was used from the outset AFAIK. I never explicitly installed it.
I did wonder at the time what “Entering fakeroot environment …” meant.
i gave up on this. i tried to start a discussion about the permanent existence of fakeroot years ago. fakeroot is a primary security issue and other distros use it also while updating-processes but they delete it after finishing.
i won’t comment this further not to get another strike
i haven’t updated yet but disabled Plymouth following these instructions:
upon restart i get the following screen before accessing the desktop(not my screenshot):
and i also disabled the Splash screen in KDE(not sure if related)
Edit:
it might be because i removed the “quiet” parameter,but that is what was instructed in the wiki:
can i put it back?
Edit2
it seems that alone it might not be enough:
https://wiki.archlinux.org/title/Silent_boot
i won’t bother with it.
You never explicitly installed it because previously fakeroot was automatically installed as a dependency of pacman. So it was impossible not to have it. It is now a dependency of both pacman-contrib and base-devel (which is a requirement for building AUR packages on Manjaro.). There should be no need to ever explicitly install fakeroot unless you’ve done something wrong.
No unforeseen problems, thanks to the info in this thread. Thanks!
Well you have just un-hidden it, why do you want to hide it. This is just the system booting and is actually very nice for diagnostic, if something goes red or stops for a couple of seconds you will know there is something wrong and investigate further after booting.
The purpose of the splash and plymouth is exactly to hide the log behind some animation so that ex windows users do not freak out 
