[Testing Update] 2019-03-14 - Kernels, Plasma, Deepin, Pamac, Python, Ruby

There is the tool pacdiff for that.
IMHO everybody should run pacdiff after an update that produces pacnew/pacsave files.

Pacman Pamac should probably have the option to run pacdiff after every update and if there is something to do, present the differences with a nice Diffprog like Meld...
I don't think it will ever be possible to automatize this "work" for rolling releases, so make it at least as simple to use as possible.


Sorry, do not recall reading the forum rule stating that one needed to seek permission of a poster before either replying to or commenting on their post. Must have been in that dreaded fine print.


Well where's the fun in that?


Thank you. This is exactly it. Good thing it's known.

Finally fixed with gnome-control-center 3.30.3+4+g26287234b-1
Just update your system. :slight_smile:


Real fix will be available with Gnome 3.32.x-y :smiley:

1 Like


next time ... if you like a more magic method for diffing these files.
Try to combine sudoedit with a fancy visual merge tool ... meld for example.
Such an elementary functionality is unfortunately missing in pamac.


Fish solution
function pacnew --description 'Merge new *.pacnew configuration files with their originals'

	echo "Locating .pacnew and .pacsave files ..."

	set cfgfiles (find /etc -regextype posix-extended -regex ".+\.pac(new|save)" 2> /dev/null)

	# Check if any .pacnew or .pacsave configurations are found
	if test -z "$cfgfiles"
		echo "No configurations to update"
		return 0

	for config in $cfgfiles
		echo "Found: $config"
		set -lx SUDO_EDITOR "meld $config"
		# Let user securely edit original configuration
		sudoedit (string replace -r ".pac(new|save)" "" $config)
		# Remove file?
		while true
		  read -P 'Delete file ? (Y/n): ' value
		  switch $value
				case y Y
					sudo rm "$config"; and echo "Deleted: $config"
				case n N
					# do nothing
				case '*'
					echo 'Answer (Y)es or (n)o.'
Bash solution
# Merge new *.pacnew configuration files with their originals

echo "Locating .pacnew and .pacsave files ... this may take a while"

cfgfiles=$(find /etc -regextype posix-extended -regex ".+\.pac(new|save)" 2> /dev/null)

# Check if any .pacnew or .pacsave configurations are found
if [[ -z "${cfgfiles}" ]]; then
  echo "No configurations to update"

for config in ${cfgfiles}; do
	echo "Found: $config"
	export SUDO_EDITOR="meld $config"
  # Let user securely edit original configuration
  sudoedit ${config%\.*}
  # Remove file?
  while true; do
    read -p "Delete file ? (Y/n): " Yn
    case ${Yn} in
      [Yy]* ) sudo rm "$config" && \
              echo "Deleted: \""${config}"\"."
              break                         ;;
      [Nn]* ) break                         ;;
      *     ) echo "Answer (Y)es or (n)o." ;;

It already exists.

DIFFPROG=meld pacdiff

Thanks for the hint! I will try it next time :slightly_smiling_face:

1 Like

Don't forget sudo, so you actually can edit the files and delete the .pacnew:
sudo -H DIFFPROG=meld pacdiff


Okay, if I wanted an Opera lookalike, I would use Opera. Is it fun yet?

@philm: Compiz needes a rebuild against the new protobuf version (stumbled upon this issue on my Arch machine but should be the same in Manjaro testing).

When Microsoft convince Google to put all the privacy invading changes in Chome, will you still use it?

Yeah it's fun :wink:

Switched to Pamac-gtk (I run Xfce).
Could not turn it off, I had to kill the process in the process manager. When it was started it didn't respond to the "close" button nor the right-click "close" option. The only thing that worked was to kill the process.

Used a Manjaro in VBox. Modified some options (like AUR being activated).

Enabled testing and upgraded using pamac in GUI. Config was not restored :frowning:

Tried on my main PC which is powered by Manjaro linux with testing enabled and my configuration was kept when upgrading to pamac 7.3.5 in CLI... Ouch !

Issue opened: https://gitlab.manjaro.org/applications/pamac/issues/576

It worked fine on my side, updated with Pamac GUI. I got my old configuration file back.

Do you have both pamac.conf and pamac-new-DATE.conf?

Is it possible to give us your pacman.log? The thing is that the code meant to restore the old config file is in pamac-gtk, but /etc/pamac.conf is actually owned by pamac-common. It works great when pamac-gtk is installed after pamac-common, but if it is updated the other way around (is it even possible?), it will fail.

@philm Is there a reason why the code used to restore the conf file is in pamac-gtk instead of pamac-common?

You're lucky. By the way, I made a copy of an up to date stable manjaro with pamac-7.3.4 before splitting happen.

Here is the error related to pamac-gtk installation:

Installing pamac-gtk (7.3.5-1)...
Configuring pamac-gtk...
error: 1 argument(s) specified

Usage: vercmp <ver1> <ver2>
/tmp/alpm_MPxfek/.INSTALL: ligne 12 : [:  : nombre entier attendu
comme expression

Rough translation:

Installing pamac-gtk (7.3.5-1)...
Configuring pamac-gtk...
error: 1 argument(s) specified

Usage: vercmp <ver1> <ver2>
/tmp/alpm_MPxfek/.INSTALL: line 12 : [:  : expected integer as expression

I will add pacman.log part related to my test on bug report asap.

I see, I only made the upgrade in Testing. (And without going back and forth between Stable and Testing.)

I'll check that out with VMs that are not updated yet to see if I get something similar.

Grabbed my /var/log/pacman.log and cut the part related to testing migration.

I read this:

[2019-03-15 22:07] [PAMAC] synchronizing package lists
[2019-03-15 22:08] [ALPM] transaction started
[2019-03-15 22:08] [ALPM] warning: /etc/pamac.conf saved as /etc/pamac.conf.pacsave
[2019-03-15 22:08] [ALPM] removed pamac (7.3.4-2)

Looks like install code is not handling correctly /etc/pamac.conf.pacsave. Why?

A little later, first pamac-common, then pamac-cli and pamac-gtk are installed:

[2019-03-15 22:09] [ALPM] installed pamac-common (7.3.5-1)
[2019-03-15 22:09] [ALPM-SCRIPTLET] ==> An authentication agent is required
[2019-03-15 22:09] [ALPM-SCRIPTLET]     Cinnamon, Deepin, GNOME, GNOME Flashback, KDE, LXDE, LXQt, MATE and Xfce
[2019-03-15 22:09] [ALPM-SCRIPTLET]     have an authentication agent already.
[2019-03-15 22:09] [ALPM-SCRIPTLET]     See https://wiki.archlinux.org/index.php/Polkit#Authentication_agents
[2019-03-15 22:09] [ALPM-SCRIPTLET]     for other desktop environments.
[2019-03-15 22:09] [ALPM] installed pamac-cli (7.3.5-1)
[2019-03-15 22:09] [ALPM] installed pamac-gtk (7.3.5-1)
[2019-03-15 22:09] [ALPM-SCRIPTLET] error: 1 argument(s) specified
[2019-03-15 22:09] [ALPM-SCRIPTLET] 
[2019-03-15 22:09] [ALPM-SCRIPTLET] Usage: vercmp <ver1> <ver2>
[2019-03-15 22:09] [ALPM-SCRIPTLET] /tmp/alpm_MPxfek/.INSTALL: ligne 12 : [:  : nombre entier attendu comme expression

Annoying to see pamac-7.3.5 still not keeping /etc/pamac.conf :frowning:

Ok, I understand why it fails on @fredb74 side. It is because in post_install(), vercmp use the second argument ($2) instead of the first one ($1).

if [ "$(vercmp $2 7.3.5-1)" -lt 0 ]; then

As said in the manual for PKGBUILD, only one argument is passed to the function when executed, the version of the package that is installed.


Run right after files are extracted. One argument is passed: new package full version string.

Therefore, when the package is installed (which is the case when pamac package is replaced by pamac-gtk), the function doesn't receive the version of the package, but receive nothing instead. Thus, vercmp fails because $2 is nothing, the test fails because vercmp fails, the if fails, and the conf file is not replaced because the if failed.


@philm The post_install() need some changes so it works for folks on Stable (and those who have not updated yet on other branches). Of course, the version number used in vercmp will need to be changed too, so it works with the rebuild. :slight_smile:

The code is fine for post_upgrade() though.


Looks like I found a bad bug once again.

I'm not a bash wizard. Thanks for the explanation!

So, if I understand well - I hope - the right function could be:

if [ "$(vercmp $1 7.3.5-1)" -lt 0 ]; then

Well, if it is the case, it is a really simple fix!

Forum kindly sponsored by