Rebuild shiboken2 after system update(24-07-16)

Hi everybody,

when i follow the announcement on last stable system update (2024-07-16), i have to rebuild any AUR Python packages that install files to site-packages oder link to libpython3.11.so.

The first thing I did was try to find out which packages they might be.

Checkrebuild found 5 hits for me:

  • foreign khotkeys
  • foreign mpv-full-build-git
  • foreign pyside2
  • foreign python-manjaro-sdk
  • foreign python-shiboken2

The command :
pacman -Qoq /usr/lib/python3.11/
found three hits for me

  • pyside2
  • python-manjaro-sdk
  • python-shiboken2

I think that the first two packages do not have to be rebuilt because of python, but for another reason, which is why I put them at the end.

I read on a page that you should rebuild shiboken2 before pyside2 and tried to do that with the command :
pamac build shiboken2
Unfortunately I got the following output:
Warning: you seem to have cloned an empty repository.
==> ERROR: PKGBUILD does not exist.
Error: Process could not be prepared successfully: Error cloning build files for shiboken2

Unfortunately, I am not familiar enough with this problem to solve it on my own, so I am asking for help.

Ohoh,

just as I was reading my own post, I saw the mistake.
Instead of

  • pamac build shiboken2
    I should have used
  • pamac build python-shiboken2
    should have been used. Then the problem disappeared and a new one arose, which I think I can solve myself:
Warning: Cannot resolve “clang=17.0.6” (a dependency of “python-shiboken2”)
Error: Operation could not be prepared successfully:
Cannot fulfill dependencies:
- non-existent dependency 'clang=17.0.6' required by python-shiboken2

In this case you can probably click e for edit and then in the line for the clang version
18.1.8-1
because that is the version on my system.
On the official PySide2 page (PySide2 · PyPI) you can read :
PySide2 versions following 5.12 use a C++ parser based on Clang. The Clang library (C-bindings), version 6.0 or higher is required for building.
So it would be possible to use a newer version of clang for building, if I understood correctly. But before I do this I would like to have some opinions about it

That would be accurate.
But,

Is deprecated. If you are using current plasma then this should not be present.
Well - I dont know why else it would be present otherwise.
Unless you know of an explicit, good, reason to keep it then khotkeys should be removed.

And I suppose this is too - it does not exist in the repos or the AUR.


This may mean its a good idea to re-evaluate certain packages.
Are you sure you even need or want them all?


Its really just a convenience thing, as shiboken relies on pyside2 so it would be built formerly anyways.
But it really wouldnt save you time as installing afterwards would use the latest build.
Meaning it does not matter. (unless you force clean build the second time around)

There is discussion about this on the page for the package
https://aur.archlinux.org/packages/python-shiboken2

it’s very old ! probably (I hope) orphans
pyside6 exists since 2020 (before was pyside2, which has been frozen since 2020)

1 Like

Very interesting, what you said about the python3.11-apps, cscs.

Even if I’m a little surprised why I have such outdated packages on the system when I only reinstalled Manjaro in October 2023. On this german page. I could find what you say about KHotKeys.

But I can find Python Manjaro SDK via pamac search python-manjaro-sdk. I get the following output :

python-manjaro-sdk 1:0.1.1-1 [Installed]                                              
    Manjaro SDK, Python library for easy access to any Manjaro tools or Libs.

Since I have not activated the AUR for my Pamac, it must be in the Manjaro repository.

That is a difficult question. I’m always a bit careful and keep things before I delete too much. It also depends on what others have to say about it, I was honestly hoping that there are users like me who have similar issues. I also don’t think it’s all that important because I already have python3.12 on my system. Probably needs to be considered as coexistence, like an old kernel or something. For this reason, I’ll wait a little longer before uninstalling it.

If you can call it that. There’s a comment every few days, it’s not very lively. Unfortunately, they don’t talk about clang 18. Thanks for that anyway, maybe I’ll write there sometime.

I would still say about shiboken2, it’s not so much the order that matters to me. I also think you are right that the dependencies may install themselves if necessary. But much more important to me was the question if I will edit the build files and if no one answers, I will join the other discussion, as I said.

This is interesting on the one hand, but also strange on the other. I wonder how such packages get onto my system?
I mean I only completely reinstalled my Manjaro in October 2023. OK, I kept my home partition, but not my root directory.

This is incorrect. By default, pamac searches both the repository and installed packages. So this is simply telling you that you have python-manjaro-sdk installed, which we already know. You should have tried something like

pamac search --repos python-manjaro-sdk
pamac list --foreign

Why wonder? You could check the output from

pactree -r pyside2

(available via the package pacman-contrib if not already installed) to see the tree of dependencies, or check /var/log/pacman.log and see what else you installed at the same time.

1 Like

I never explicitly installed this but:

$ pamac search pyside6
pyside6-tools  6.7.2-3                                                                                   extra
    Tools for pyside6
pyside6  6.7.2-3 [Installed]                                                                             extra
    Enables the use of Qt6 APIs in Python applications

:man_shrugging:

dependency for “python-manjaro-sdk” family as Jak ?
or from aur, list is short

[2023-10-10T02:22:49+0200] [ALPM] transaction started
[2023-10-10T02:22:49+0200] [ALPM] installed python-shiboken2 (5.15.10-2)
[2023-10-10T02:22:50+0200] [ALPM] installed pyside2 (5.15.10-2)
[2023-10-10T02:22:50+0200] [ALPM] installed falkon (23.08.1-1)
[2023-10-10T02:22:50+0200] [ALPM] transaction completed

Thanks for the hint, you can see it relatively clearly, it probably both belongs to my Falkon browser, which I installed on October 10th.

The only question here is whether I should still rebuild python-shiboken2 and pyside2 as stated in the announcement for the update.
Or should I just leave it at that, because as I said I don’t have the clang version 17.0.6, but the inappropriate version 18.1.8-1. Especially as there have been no problems using the Falkon so far.

The command
pactree -r python-manjaro-sdk
had the following output

python-manjaro-sdk
└─web-installer-url-handler

The only strange thing is that the “web-installer-url-handler” can neither be found in the pacman.log nor in the repository. Perhaps someone else can tell me where this (web-installer-url-handler) comes from.

grep web-installer-url-handler /desktopfs-pkgs.txt

Together with /rootfs-pkgs.txt, these files list the packages that were initially installed on your system. So both web-installer-url-handler and python-manjaro-sdk were placed on your system in the initial installation. However, both have since been removed from the Manjaro repository, and should similarly be removed from your system.

Regularly checking for orphaned or dropped packages is good system maintenance practice.

The only question here is whether any package still relies on pyside2, because falkon no longer does.

I have really neglected this so far and I see it as the cause of my problems.

So I gave the command
sudo pacman -Rns $(pacman -Qtdq)
and got an output that I didn’t quite like.

AbhĂ€ngigkeiten werden geprĂŒft 

:: cmake benötigt optional ninja: for ninja generator
:: falkon benötigt optional pyside6: Python plugins
:: kate benötigt optional clang: C and C++ LSP support
:: qt5-tools benötigt optional clang: for qdoc
:: qt6-tools benötigt optional clang: for qdoc and lupdate

Pakete (66) clang-18.1.8-1  compiler-rt-18.1.8-1  kcolorpicker-qt5-0.3.1-4  kjs-5.115.0-1
            kpeople5-5.116.0-1  kpty5-5.116.0-1  llvm-18.1.8-3  ninja-1.12.1-1
            plasma-framework5-5.116.0-1  pyside6-6.7.2-3  python-manjaro-sdk-1:0.1.1-1
            python-shiboken2-5.15.12-1  python-systemd-235-3  python-tqdm-4.66.4-1  shiboken6-6.7.2-3
            threadweaver5-5.116.0-1  amf-headers-1.4.33-1  bluez-qt5-5.116.0-1  cmocka-1.1.7-2
            db-6.2.32-1  ffnvcodec-headers-12.2.72.0-1  gcab-1.6-2  glibmm-2.68-2.80.0-1  go-2:1.22.5-1
            gperf-3.1-5  gptfdisk-1.0.10-1  grantlee-5.3.1-2  kactivities-stats5-5.116.0-1
            kcalendarcore5-5.116.0-1  kdesu5-5.116.0-1  kdnssd5-5.116.0-1  kdsoap-qt5-2.2.0-1
            kfilemetadata5-5.116.0-2  kgamma-6.0.5-1  khtml-5.115.0-1  kimageannotator-qt5-0.7.1-3
            kirigami-addons5-0.11.0-7  kpeoplevcard-0.1-2  kquickcharts5-5.115.0-1  krunner5-5.115.0-1
            ldns-1.8.3-2  lib32-libunwind-1.8.1-1  lib32-libxdamage-1.1.6-1  libkcddb5-24.05.2-1
            libqaccessibilityclient-qt5-0.6.0-1  libsmbios-2.4.3-7  luajit-2.1.1720049189-1
            meson-1.5.0-1  modemmanager-qt5-5.116.0-1  nasm-2.16.03-1  networkmanager-qt5-5.116.0-1
            opencl-headers-2:2024.05.08-1  oxygen-sounds-6.0.5-1  perl-mozilla-ca-20240313-1
            podofo-0.9-0.9.8-5  pyside2-5.15.12-1  python-docutils-1:0.21.2-1  python-ply-3.11-13
            python-pycurl-7.45.2-4  qgpgme-qt5-1.23.2-1  qqc2-desktop-style5-5.116.1-1
            qt5-doc-5.15.14-1  ttf-opensans-1.101-2  wayland-protocols-1.36-1
            web-installer-url-handler-2.3-1  webrtc-audio-processing-0.3.1-4

GesamtgrĂ¶ĂŸe der entfernten Pakete:  1244,83 MiB

:: Möchten Sie diese Pakete entfernen? [J/n] n

clang is apparently required here and selected for removal at the same time, which seems pointless to me. What do you mean and how could you exclude a package from removal ?

After some research I found the answer to my question myself, you just leave out the -s and it looks better. So

sudo pacman -Rn $(pacman -Qtdq)

solves the problem by itself.
Here you could also leave out the -n, but that didn’t make any difference in my particular case.

I know that removing orphans itself creates orphans, which in turn have to be deleted. Since I haven’t gotten to the point where I’ve deleted them all, I guess it remains to be seen whether all five foreign packages from my first post will be removed if I subsequently run

paru -c

afterwards.

Not really.

You should mark packages you want to keep as ‘explicit’

sudo pacman -D --asexplicit clang

because the -s is taking things recursively not required by anything else.

Once you have marked packages you want to keep as being installed explicitly then they will not be included in the list.

Note:
This would not be required if clang had not been originally installed only as a dependency.

Now, unfortunately, I have run into a problem again I think. As I said, I removed the orphans with the above command. That went well a few times. They minimized from 50 to 9, then to 1, where I always checked if they are needed by anything. Since that was never the case, I even ended up deleting the package called python-systemd
I deleted that too, but then I checked for Orphane again and suddenly found 1762 new ones. Looked at the file again,
(which I create like this)

pacman -Qi $(pacman -Qtdq) > ~/Documents/_Terminal/orphans4.txt 

whether they are needed and they are, partly from several well-known packages, so that I became suspicious with the deletion. Have I acted correctly so far or what do you think ? Should I stop now?
A few examples of the orphans that I am currently receiving via
pacman -Qi $(pacman -Qtdq) are displayed

Name                     : a52dec
Version                  : 0.8.0-2
Beschreibung             : Library for decoding ATSC A/52 (AC-3) audio streams
Architektur              : x86_64
URL                      : https://git.adelielinux.org/community/a52dec/
Lizenzen                 : GPL
Gruppen                  : Nichts
Stellt bereit            : Nichts
HĂ€ngt ab von             : glibc
Optionale AbhÀngigkeiten : Nichts
Benötigt von             : gst-plugins-ugly  mplayer  vlc
Optional fĂŒr             : Nichts
In Konflikt mit          : Nichts
Ersetzt                  : Nichts
InstallationsgrĂ¶ĂŸe       : 136,04 KiB
Packer                   : Balló György <bgyorgy@archlinux.org>
Erstellt am              : Fr 02 Jun 2023 16:06:10 CEST
Installiert am           : Di 19 Sep 2023 10:27:51 CEST
Installationsgrund       : Installiert als AbhÀngigkeit eines anderen Pakets
Installations-Skript     : Nein
Verifiziert durch        : Signatur

Name                     : aalib
Version                  : 1.4rc5-18
Beschreibung             : ASCII art graphic library
Architektur              : x86_64
URL                      : https://aa-project.sourceforge.net/aalib/
Lizenzen                 : LGPL-2.0-or-later
Gruppen                  : Nichts
Stellt bereit            : Nichts
HĂ€ngt ab von             : glibc  gpm  libx11  ncurses  slang
Optionale AbhÀngigkeiten : xorg-fonts-misc: x11 driver
                           xorg-mkfontscale: x11 driver [Installiert]
Benötigt von             : gst-plugins-good  mplayer
Optional fĂŒr             : vlc
In Konflikt mit          : Nichts
Ersetzt                  : Nichts
InstallationsgrĂ¶ĂŸe       : 279,88 KiB
Packer                   : Balló György <bgyorgy@archlinux.org>
Erstellt am              : Di 16 Apr 2024 19:15:35 CEST
Installiert am           : Mo 03 Jun 2024 14:18:11 CEST
Installationsgrund       : Installiert als AbhÀngigkeit eines anderen Pakets
Installations-Skript     : Nein
Verifiziert durch        : Signatur

Name                     : abseil-cpp
Version                  : 20240116.2-2
Beschreibung             : Collection of C++ library code designed to augment the C++ standard library
Architektur              : x86_64
URL                      : https://abseil.io
Lizenzen                 : Apache-2.0
Gruppen                  : Nichts
Stellt bereit            : Nichts
HĂ€ngt ab von             : gcc-libs  glibc  gtest
Optionale AbhÀngigkeiten : Nichts
Benötigt von             : libphonenumber  opencv  protobuf  telegram-desktop  vlc  webrtc-audio-processing-1
Optional fĂŒr             : Nichts
In Konflikt mit          : Nichts
Ersetzt                  : Nichts
InstallationsgrĂ¶ĂŸe       : 6,28 MiB
Packer                   : Christian Heusel <gromit@archlinux.org>
Erstellt am              : Do 23 Mai 2024 02:00:06 CEST
Installiert am           : Mo 03 Jun 2024 14:18:11 CEST
Installationsgrund       : Installiert als AbhÀngigkeit eines anderen Pakets
Installations-Skript     : Nein
Verifiziert durch        : Signatur

Is such a result normal, it doesn’t seem so to me. The last ones found as Orphans are no longer Orphans, are they?
I am confused and fear I have made a mistake, what do you think is going on here?

For all people which do not understand german so well
‘Benötigt von’ means ‘Needed from’, so they are needed. That’s not an Orphan in my eyes, so anybody knows why all theses packages where listed afterwards ?

I’d definitely put that one back. Although it doesn’t depend on other things, as you have seen, other things depend on it. :wink:

I suspected something like this and reinstalled it straight away - no problem.

They’re not, so I’m switching from Pacman to Pamac for good.
If you ask Pamac,

pamac list -o

it finds exactly no more Orphans, Pacman apparently can’t.

After removing the Orphans, the last three dots have disappeared.
I have already rebuilt mpv-full-build-git, after entering
checkrebuild
there is only

foreign khotkeys

left and I removed that because cscs convinced me that it was outdated.

Thanks to all involved that my problems could be solved, especially this statement

which is why I am marking this as a solution, because it made me sit up and take notice. I think it will fundamentally forget my awareness of system maintenance because I finally read up on it.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.