[Testing Update] 2019-02-10 - KDE Apps, Gambas, Qt5, VirtualBox, LibreOffice, Wine, Firefox



According to the explanation, this situation is caused by user action. They’ve done something on their system that should normally not be done. So the expertise required to create the problem is sufficient to solve the problem I think.

But since this type of file conflict is common during updtes, maybe it is something to be suggested in Manjaro Development.


If the laptop is not turning on, this is a hardware failure.


Yes @jonathon certainly said that… but i have done neither of those things, yet still incurred this problem. Fwiw…


Then this mystery is not yet solved! Does the creation date of the file in question correspond to any installed packages, possibly AUR related? :female_detective:


That is an analytically excellent question. Sadly i was too dimwitted to think of that, before i did these: [Testing Update] 2019-02-10 - KDE Apps, Gambas, Qt5, VirtualBox, LibreOffice, Wine, Firefox
Ie, there is no longer any stiffened corpse on which to perform the post-mortem. Alas!


Even if we happen to know what exactly make this file appears and prove it, it won’t make the problem disappear magically to users in Stable that might be affected by it. The harm is already done on those systems. Knowing that it can happen in Stable to some (fortunately not every) users, since it just needs a file removal to fix it, I’m still strongly in favor to automate it.

Last time Manjaro asked its users to do a manual intervention in order to upgrade their system, it didn’t turn out very well. Ok, it is far less critical than this one since a file conflict prevents the upgrade completely, so it can’t really break the system. But is it still a problem that makes the upgrade not smooth, and we have the tool to make the upgrade smoother.

If nothing is done, there will be people who will ask for help. There will be people who will ask for help even if the solution is clearly documented. Hopefully no one will throw the RTFM post when it’ll be asked for the 20th time. :grinning:

Perhaps a post should be done, yes. Maybe tomorrow (if not already done by then).


is simply a ‘compiled’ version of
and that __init__.py is kind of the starter for all of PyQt5.

__pycache__ directories and .pyc files are made by the Python interpreter when it imports .py files for the first time. So you could delete the whole __pycache__ directory, and Python will create it again if it’s needed.

As a long-time user of Python, I thought everyone knew that
(and maybe Jonathan thought so too…)

Qt5 underpins KDE, but I don’t know if KDE use PyQt5.

PyQt5 is on my system at that location, and I thought I installed it myself, but there’s no __pycache__ dir, as if it hasn’t been ‘imported’ by any Python app.

Hmm … the fact that you get that error while upgrading means … what?
Why does pacman not just overwrite it? – that’s what it does to most files, isn’t it?


Pacman never overwrites files that don’t belong to packages by default. If you want to overwrite a file with one provided by a package, you must explicitly ask pacman to do so with the --overwrite option.


What kind of twisted logic is that? How is your putative deep familiarity with Python in any way causal to other people’s familiarity [or lack thereof] with Python?

I might as well say something like “as a long-term user of hospitals, i thought everyone would know cardio-thoracic keyhole surgery”. Talk about a non sequitur


It creates them from the corresponding .py files
(which are human-readable text source code).

So if some package consists of .pyc files without .py files, don’t delete the .pyc files or __pycache__ dirs. (But such a situation is unlikely in the open-source world.)


Yeh, I know, but it’s just the way my brain subconsciously operated, until it became obvious that that you and korealinux didn’t know. :slight_smile:

kdemeoz, you woke me (partially) out of my hazy stupor, and I reread Jonathan’s post, which explained it all in great detail.

He used the terms pre-compiled/cache files and bytecode,
which mean the same as __pycache__ dirs and .pyc files.

He’s saying that the python-pyqt5 package is trying to install pre-compiled .pyc files, which it didn’t used to do.

I wonder if, contrary to what I think Jonathan meant: that explains why the files are present in the new package that’s trying to install, not why they’re in your system…

Whichever way, it seems likely that deleting all __pycache__ dirs under /usr/lib/python3.7/site-packages/PyQt5/ would safely fix the problem.


My suspicion is that problem child KDE. But then @Linu74 reports i3/xfce (which was this?) and @mbod reports gnome. All other reports come from kde users.

python is presumably on nearly all machines since it is required for pacman-mirrors and ufw - to name 2 that are generally default for manjaro iso’s.

As to the appropriate action: surely (no names mentioned :stuck_out_tongue_winking_eye:) only an entry in the ‘Known issues and solutions’ wikipost is called for. :woman_shrugging:


OK, thanks for confirmation.

I maybe thought that my .xprofile settings maybe causing it because I enabled global menus long before they were official so I had few related entries there. I commented them out, rebooted and still the same so I guess those entries doesn’t matter anymore and were not causing anything bad, so I guess we are left with waiting for a new KDE framework in hope it will be the fix.


Hope is a nice thing… but you could investigate more I guess. Check journal for relevant messages and confirm there is no “actual” cloned Global Menu on the panel.


On my KDE i didn’t have this file conflict. Maybe I haven’t ran python as root?

If I understood the issue (not a python user) the packagers know their code (python), so they assume “noone” ran python as root, so…
Then the users that came to Manjaro, looking for a “noob-friendly” experience should learn what’s the proper definition of this, like @jonathon often explains… (no need to repeat here, it’s already in numerous topics about these terms).

It maybe the difference between

  • “Learning in the classroom” by others’ mistakes/experience (=RTFM)
  • “Learning on the job” by own mistakes/experience (=WTF)


Really, you’re going to stick with this pontification(?), despite minor inconveniences like



I am no expert.
I respect the experts (firstly).
If you doubt the experts (that this is introduced when you run a python as root), ask them instead. I will accept any final outcome of this, as

I only am responsible of my system. I assume this for everyone.

This is not personal :rose:


Hope is based on information I was given, so it’s not completely baseless. As to checking cloned global menu in journals, I wouldn’t know what to look. I can see on my own eyes doubled menu and also asked here if that’s just me or others have the same issue - it was confirmed, so this exists.

I just wait for the new Plasma and KDE framework. If that won’t fix it, then I’ll start investigating and reporting. The general issues with LO menus in Plasma are marked as fixed so instead making a panic, let’s wait a bit. New packages should arrive pretty soon.


I fear that the problem not only affects Plasma, but also desktops with vala-panel-appmenu. See LO here in Xfce.


Made the update in unstable and is the same … even with framework 5.55