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

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!

As far as I know, it should be, except that you need to also change 7.3.5-1 for 7.3.5-2 so it works with the rebuilded package that will be in version 7.3.5-2 and not 7.3.5-1 (well, unless he just overwrite the package in the repos instead of pushing a rebuild?).

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

1 Like

I think @philm will find the best answer to work around this bug and make next stable update flawless.

At least, it would be great for stable users :smiley:

Well, the code in the if works fine. It more a matter of making the if in itself execute properly. :stuck_out_tongue:

1 Like

No, oh no no noooo, it's been fun already for yonks. One learns the most interesting things in the forum. Just recently, for instance, i learned of someone who actually chose to make themselves the product, to subjugate their privacy by willingly installing a bland locked-down-UI gaggle of spyware that collects, commodifies & commercialises their personal data. I know, amazing innit? Still, takes all kinds, doesn't it?




Oh wow, you Manjaroos are brilliant -- ta heaps! :grinning:

The resultant interface looks extremely familiar [given i often use Plasma's kompare for non-root files], My earlier, brief, attempts to also use kompare with kdesu for root-files only gave me grief when i tried it & found it created wrong permissions; whoops. Next suitable update i shall keenly try sudo DIFFPROG=meld pacdiff for relevant root-system `.pac*' files. Ta.

EDIT: haha, i just went to add this good info to my CherryTree notes on managing pacnews, when therein i rediscovered this prior gem i had forgotten:

2/7/18 : Handy technique: Pacsave, pacnew - how to manage those reasonably?

sudo -H DIFFPROG = kompare pacdiff

When prompted in the terminal to edit the files simply select the “ View ” option and it will automatically open the 2 file versions side by side in Kompare for merging.

1 Like

If the data they collect is unusable, or their result never actually comes back to me, I don't care.

For example I always say "Yes" when a homepage asks me about accepting cookies. Because A) I don't see any ads and B) The data they collect is mostly faulty (if any) anyway.

1 Like

Is this a bearded tag-team event? :grinning:

I had a problem with "systemd-swap" using kernel 501 in the last update that was solved with this update. Thanks

Something to hide ? ? ? You know nothing about privacy no matter what browser you use. Use the internet and your life is an open book. Been doing this since I built my first DOS computer, with a green screen, two 5 1/4" drives and 64 bytes of RAM. Back when micro-soft and apple were in their infancy. I could be a hacker, but, I'm a white hat. Call a truce before we both get kicked off the forum.

Sorry frog, but that does not work well.
All actions are readonly, the config file can not be changed and pacsave/pacnew can not be deleted.

oje, this runs meld/kompare with sudo. I don't like the thought of running a x applications with elevated privileges. You're literally running millions of lines of code with elevated privileges :roll_eyes:

I feel safer with sudoedit, therefore I stay with my own fish/bash function.

You can use this line to edit files with gui editor without root privileges:

DIFFPROG=sudoedit SUDO_EDITOR=meld pacdiff

The drawback is that you can't remove/overwrite .pacnew/.pacsave files whith it, only edit.


I got that same error as well after a clean install of pamac-gtk. No previous .pacsave files were left behind because I previously used option -Rns. The app seems to run fine however.

Something else cropped up, I've been experiencing a few more audacious crashes just recently. They're frustrating because I can't reproduce them and the dump isn't really helpful in identifying the problem:

Stack trace for audacious segfault

Stack trace of thread 14187:
#0 0x00007fcce4e88d7f raise (libc.so.6)
#1 0x00007fcce4e73672 abort (libc.so.6)
#2 0x00007fcce4e73548 __assert_fail_base.cold.0 (libc.so.6)
#3 0x00007fcce4e81396 __assert_fail (libc.so.6)
#4 0x00007fccd3f01a71 n/a (libX11.so.6)
#5 0x00007fccd3f01b21 n/a (libX11.so.6)
#6 0x00007fccd3f01e1d _XEventsQueued (libX11.so.6)
#7 0x00007fccd3ef3998 XPending (libX11.so.6)
#8 0x00007fcce0133d27 n/a (libgdk-x11-2.0.so.0)
#9 0x00007fcce522bd42 g_main_context_check (libglib-2.0.so.0)
#10 0x00007fcce522d636 n/a (libglib-2.0.so.0)
#11 0x00007fcce522e6d2 g_main_loop_run (libglib-2.0.so.0)
#12 0x00007fcce04bcdf3 gtk_main (libgtk-x11-2.0.so.0)
#13 0x00007fcce553e62d n/a (libaudcore.so.5)
#14 0x00007fcce5551a87 _Z7aud_runv (libaudcore.so.5)
#15 0x00005644ed82d616 n/a (audacious)
#16 0x00007fcce4e75223 __libc_start_main (libc.so.6)
#17 0x00005644ed82dc1e n/a (audacious)

[...and 4 more additional threads...]

It mostly seems to crash when listening to a track a fairly-high volume (replaygain is enabled) for an extended period, and then doing another gui action like pressing "next" or "stop." I suspected glib2 due to issues related to gnome...but since my first crash logged wasn't until after these updates (3/14) so I can't rule out these packages. Bug places 1 and 2 don't mention anything. Thankfully it's mostly a sporadic issue -- again happening once or twice a day.

still usb keyboard and mouse frezing problems.

Forum kindly sponsored by