[Stable Update] 2019-02-19 - Kernels, KDE, LibreOffice, Systemd, VirtualBox, Deepin, Qt, Firmwares, Wine



This isn’t anything to do with systemd. People have just had the same “libidn2.so.4” update issue with manjaro32 and x32-stable has been on 240 for a few weeks.

The common factor: Pamac.

I suspect it is failing halfway through because it’s upgrading packages in use and removing files it needs, then it falls over.

This is why I only use pacman (and sensible AUR helpers like yay and aurman).


I used pamac in name of science on xfce and no ill happened. Just that python cache thing which I think is unrelated to pamac.


I don’t think it’s consistent, but it does seem to be a common factor - all of the people having issues with [Stable Update i686] 2019-02-18 - systemd, LibreOffice, KDE, firmware were using Pamac to update. I have had zero issues with pacman. However - my data sample is small so I could be wrong.


As long as i read to the post i’m more convince of that pamac is somehow disturbing with the update process.
I can say that people that made it through pacman hadn’t any problem.


Damn, my system must be blessed then. :cross:

The thing is Pamac is a front-end using libalpm, the same library that use Pacman to handle package management.

So I don’t understand why Pamac would be the culprit here, especially when people could just upgrade without problem usually with Pamac before when there’s nothing systemd related.

If there’s someone that can actually prove in detail that Pamac is doing garbage when upgrading packages, I would like to see that, and I’m pretty sure @guinux would like to fix that too.

If Pamac is considered too problematic, prehaps guinux should stop losing his time to develop and maintain it right now then. It’s kinda useless to develop a package manager in-house if we just end up saying “Use pacman, Pamac is garbage.” :confused:


Manjaro Deepin Edition user reporting in. No errors! Everything went smootly updating through TTY. Woo hoo!!! Thanks devs! And thanks @oberon for all the hard work!

System Info for those interested. Cheers!


It’s well-known that writing package managers is hard and there are edge- and corner-cases which don’t appear in normal use.

The larger a piece of software gets, the harder it is to keep clean, the more edge-cases.

Just because Pamac uses libalpm doesn’t necessarily mean it does things in the same way as pacman - for example, the update/dependency checking/etc. logic can be very different, and especially so when Pamac also brings in AUR support.

I suspect Pamac needs some TLC, testing, and polish. Just like systemd did with 240.


I’ve been doing pamac upgrades since last October. Nothing ever happened. I have two systems and both always show the same warnings or issues (like the mentioned python cache file). Why? Because most likely I use the exactly same software (packages) on both.

What would be cool (but impossible to do) is to make two databases. One with a list of installed packages of users who’s update though pamac went well and another dB with lists of installed packages of users who had issues upgrading with pamac. A sample of 10-20 users on each dB would be enough. All we would need to do would be to prune out each dB to find the common packages among each user group and finally crosscheck (diff) between the two dB.

I bet a case of beer we would find a very small set of packages that made the difference between the update going through well or not.


Nop, it needs to be work around and tested.
Is very helpful to new non linux users.

But we all know that one way or the other we all are going to end up using terminal or tty.
And in any case… That’s the beauty of a rolling release…


Update success! :slightly_smiling_face:

All went reasonable smooth while updating my two main machines running stable Manjaro.
Thank you very much for the time and work.


I aknowledge that. But it won’t help if we can assure that it does its job correctly to begin with.

Of course I want to be wrong on that statement, I don’t actually want guinux to drop Pamac.

The thing is that a significant part of the community in Testing and Unstable actually don’t use it at all. It’s hard to gather data and improve the software when the package manager made in-house is not even used by the testers themselves.

That is a huge flaw in Manjaro QA in my opinion. In addition to the lack of people on development branches, people who use Testing and Unstable are generally using tools and ways to upgrade their system that are not used by the average joe in Stable. I cannot blame them to follow good practices of course, but it means that we can get really unexpected results in Stable.

What we can do about it? I don’t know honestly.


It is interesting to read about potential smoking guns here possibly pointing towards Pamac. It makes me wonder… did any of the [Plasma] users here who have posted about “disappointing” update outcomes when doing it graphically, use Octopi / would it be equally [potentially] susceptible as Pamac?


If they’re here, then ipso facto they’re Linux users. :grinning:

Don’t worry, i know exactly what you meant to say. I’m just trying to lighten the mood a bit.


What we the testers should do is to organize like 20 people doing tty/terminal updates and 20 doing pamac updates.

But it’s like i said a long time ago… Not many people want to use testing or unstable, cause at some point it might break…

More testers are needed, indeed… But that’s to how people want to be involve in this community.


I have two Testing VMs. Used to be one, but recently i cloned it. After reading this interesting discussion, i think from now on i shall keep using tty for the bigger updates in one, but revert to Pamac for all updates in the other… then report back if/when the sky falls in.

[Testing Update] 2019-02-22 - Kernels, Systemd, Browsers, Plasma5, Python, Haskell

its great particularity is that it uses dbus (pamac-gui->polkit->dbus->pamac-system->alpm) - so it is very sensitive to systemd :sweat:

As pamac-cli : it’s only a dbus client


That might be a risk factor.

But if it’s really that, damn, I don’t know how it could actually be fixed outside of ditching systemd completely for an alternative way (which won’t happen anytime soon)(btw, I’m neither pro or anti-systemd, don’t start a “systemd is satan himself” thread please) or hoping that systemd figures out a way to handle systemd upgrades with more stability.

I mean, we won’t just run the whole Pamac GUI process as root just not to use Polkit.


And yet it is still planned to ditch pacman as the default package manager and replace it with pamac … pacman is the best package manager in the Linux ecosystem, period.

Madness, folly, and delusional ego.


If that’s the case then pamac cli may also be affected. My x crash last week was on pamac cli and may even affect users in TTY as @Hipster may have seen? Then you’ve got these users who were probably all on pamac gui. But before simply blaming pamac, the question is why ~1/5 users seem to be affected on pamac – system encryption?

I need a somewhat-workable system so I’ll use my own method of logging updates per pacman in x.


So, I have to take more care when there is an update in dbus or systemd? I go to a tty when appears in my pamac-gui a systemd update, now have more one, dbus, in my case, dbus-x11
I see no problem in doing this, btw