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

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

2 Likes

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.

post_install

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.

Oops.

@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.

4 Likes

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

Eh.
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

Forum kindly sponsored by