Bug#1060675: python3-pyside2.qtgui: Fails to install with libqt5gui5-gles

2024-01-12 Thread Fuzzey, Martin 
Package: python3-pyside2.qtgui
Version: 5.15.8-2+b1
Severity: normal
X-Debbugs-Cc: martin.fuzzey@flowbird.group

Dear Maintainer,

When libqt5gui5-gles is installed (required on arm64 platforms without
desktop OpenGL)
package installation fails with

python3-pyside2.qtgui : Depends: libqt5gui5 (>= 5.15) but it is
not installable

The problem is that python3-pyside2.qt has in its dependencies
libqt5gui5 (>= 5.15), libqt5gui5 (>= 5.15.1) | libqt5gui5-gles (>= 5.15.1)

IE an unconditional dependency on libqt5gui5 and an alternative on
libqt5gui5 or libqt5gui5-gles

I tried (as a hack) to modify the binary package(by unpacking and
repacking it) to
remove the unconditional dependency on libqt5gui5. That makes it installable
but it is still trying to use desktop opengl symbols:

>>> from PySide2 import QtGui
Traceback (most recent call last):
  File "", line 1, in 
ImportError: 
/usr/lib/python3/dist-packages/PySide2/QtGui.cpython-311-aarch64-linux-gnu.so:
undefined symbol: _ZTI18QOpenGLTimeMonitor, version Qt_5


I've looked at the package source and it seems it is supposed to handle this
by the patch debian/patches/Fix-GLES-builds.patch.
But that removes expected symbols based on QT.gui.enabled_features

The features are supplied by the qtbase5-dev package which is
different on armhf and arm64
On armhf opengles2 is enabled whereas on arm64 it is disabled.

Since python3-pyside2.qtgui Build-Depends on qtbase5-dev the patch
doesn't really
work in the Debian context on arm64 - the package will build but the
dependencies
calculated by shlibdeps will be wrong for gles.

I tried to fix the problem by rebuilding changing the Build-Depends on
qtbase5-dev
and qtbase5-private-dev to qtbase5-gles-dev and qtbase5-private-gles-dev.
But that results in a build dep conflict because some of the other dependencies
(like  libqt5charts5-dev) depend on qtbase5-dev (which conflicts with
qtbase5-gles-dev)

  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: amd64
  status: broken
  reasons:
   -
conflict:
 pkg1:
  package: qtbase5-dev
  version: 5.15.8+dfsg-11
  architecture: amd64
  unsat-conflict: qtbase5-gles-dev:amd64
 pkg2:
  package: qtbase5-gles-dev
  version: 5.15.8+dfsg-3
  architecture: amd64
 depchain1:
  -
   depchain:
-
 package: sbuild-build-depends-main-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: libqt5charts5-dev:amd64 (>= 5.15)
-
 package: libqt5charts5-dev
 version: 5.15.8-2
 architecture: amd64
 depends: qtbase5-dev:amd64
 depchain2:
  -
   depchain:
-
 package: sbuild-build-depends-main-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: qtbase5-gles-dev:amd64 (>= 5.15)


Regards,

Martin


-- System Information:
Debian Release: 12.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.6-pknbsp-svn7643-std-00019-g34ac856c6990 (SMP w/4
CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pyside2.qtgui depends on:
ii  libc6   2.36-9+deb12u3
ii  libgcc-s1   12.2.0-14
ii  libpyside2-py3-5.15 5.15.8-2+b1
ii  libqt5core5a5.15.8+dfsg-11
ii  libqt5gui5-gles 5.15.8+dfsg-3
ii  libshiboken2-py3-5.15   5.15.8-2+b1
ii  libstdc++6  12.2.0-14
ii  python3 3.11.2-1+b1
ii  python3-pyside2.qtcore  5.15.8-2+b1

python3-pyside2.qtgui recommends no packages.

python3-pyside2.qtgui suggests no packages.

-- no debconf information

Bug#1057374: python3-networkmanager: KeyError due to unhandled NM_DEVICE_TYPE_LOOPBACK

2023-12-04 Thread Fuzzey, Martin 
Package: python3-networkmanager
Version: 2.2-2

In Debian Bookworm with these two package versions

ii  network-manager  1.42.4-1 armhf
network management
ii  python3-networkmanager 2.2-2  all  Python 3
interface to the NetworkManager D-Bus interface


An exception occurs when calling GetDevices() on a network manager
object via the python bindings

File "", line 8, in GetDevices
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 584,
in to_python
val = fixups.base_to_python(val)
  ^^
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 647,
in base_to_python
return [fixups.base_to_python(x) for x in val]
   ^^^
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 647,
in 
return [fixups.base_to_python(x) for x in val]

  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 660,
in base_to_python
return globals()[classname](val)
   ^
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 353, in __new__
klass = device_class(obj.Get('org.freedesktop.NetworkManager.Device',
'DeviceType', dbus_interface='org.freedesktop.DBus.Properties'))

^^
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 373,
in device_class
return {
   ^
KeyError: dbus.UInt32(32, variant_level=1)

This is for the same reason as the, now closed #984983 except that it
is for a new device type (32 = NM_DEVICE_TYPE_LOOPBACK) whereas that
one was for types 30 and 31.

It seems rather fragile manually ensuring that the network manager
bindings and its python bindings are in sync.
Maybe the direct dictionary lookup with[] should be replaced with a
.get() using a sensible default?

Regards,

Martin Fuzzey
-- 

Martin Fuzzey | Software Architect
Besançon | FR
Mobile: (+33) 6 77 15 85 82
martin.fuzzey@flowbird.group | www.flowbird.group