shiboken2 depends on a sepecific major+minor version of python.

/usr/lib/x86_64-linux-gnu/cmake/Shiboken2-5.15.2/shiboken_helpers.cmake
checks for this.

As a result, attempting to build any package cmake package using
shiboken2 currently fails:

Hi Yuri,

Yuri D'Elia <wavexx@thregr.org> writes:
[snip]

Thank you for reporting this bug :-)

[snip]

Agreed.

These are not the only available options.  Are you aware of binNMUs?
https://wiki.debian.org/binNMU

Regards,
Nicholas

I'm using it for development, and not being able to work if the minor
version changes is a bigger problem than it sounds: I cannot rebuild
third-party software which is using shiboken/pyside unless I completely
rebuild pyside in parallel.

I remember I already had this issue with the 3.9 transition.

IMHO if shiboken2 is tied to the minor version, it should depend on the
minor version as well so that the whole pyside/shiboken2 so that
transitions and downstream dependencies will also be handled as part of
the transitions?

For example, the current situation is probably breaking packages which
are currently build with shiboken.

This makes shiboken2 completely useless if you have more than a one
minor version of python installed (for example during transition
periods). shiboken2 will work only for _one_ minor version.

I actually don't use shiboken2 _directly_ myself, but is there any real
drawback to build with FORCE_LIMITED_API ?

Hi Yuri and Kurt,

Kurt, would you please read the following discussion, and comment if
it's possible to generate a tighter Python dependency at build time?

Yuri D'Elia <wavexx@thregr.org> writes:

I understand, and agree that the issue is real, and that a rebuild is
required.  A binNMU is the most expedient solution ;-)  Please read
"What are binNMUs?" at the link provided above...

Yes, this is totally normal during transitions, and this is why
transitions are needed.  You can also see proof of past binNMUs here:

https://snapshot.debian.org/binary/libshiboken2-py3-5.15/

Those "+b" versions are binNMUs.

Kurt, this is the point I'm wondering about, because it would be better
if the transition tracker would alert us of outstanding issues rather
than waiting for someone to report breakage.  If this isn't feasible,
could you document that fact in the source package?

This might be by design.  Kurt, do you know?  There's also the question
of if pyside2/shiboken2 is even py3.10-ready (I haven't tested yet).

As a general principle, I worry that this would either reduce
functionality and/or debugging, or introduce regression potential, so
this is not a change I'm willing to make as a team member and not
as one of the primary maintainers/uploaders of pyside2.  I can however
test py3.10 compatibility and request a binNMU.

Best,
Nicholas

Yes, but I wouldn't call this "expedient", since ...

... we're waiting for somebody to report the unavoidable breakage, since
shiboken2 enforces this through a minor version check (we're not hoping
it will work - it will just refuse to work).

That would be a "grave" bug report from that perspective, not too
dissimilar to any ABI breakage rendering downstream users _and_ packages
unusable until fixed.

Answering this for an hypothetical 3.11 transition, the answer would
similarly be "likely doesn't matter - it's worth attempting a build and
hope for the best, because the current version is broken".

I understand this. And the documentation around this define is lacking
as well. Looking at the sources, it does seem to reduce the number of
exported methods, so it is fair to say we might have users that expect
the full API to be available and would break if used...

Disclaimer: I didn't check to see if upstream 5.15.3 fixed this issue.

Yuri D'Elia <wavexx@thregr.org> writes:

Expedient means fast.  [1. Optionally check what happens locally]
2. Schedule a binNMU.

Unfortunately it won't work in this case.  The pyside2 build currently
in unstable correctly iterated over supported Python versions, and both
libshiboken2-py3-5.15 and libshiboken2-dev contain both Python 3.9 and
3.10 variants...but that's not good enough, because
shiboken_helpers.cmake doesn't appear to support multiple Python
versions, and isn't choosing the right (ie: Debian's python3-default)
version.

Yuri, I see what you mean now, it seems the fastest way to resolve this
would be to statically declare a dependency on python3.10-dev everywhere
in the package, but by doing this the Debian pyside2 package would lose
early detection of FTBFS and failing unit tests with future Python
versions, which means upstream might not receive early enough
notification, which means pyside2 would risk being cut from the next
Debian release if a Python transition happens right before the freeze.
The backported py3.10 support patches already in the pyside2 package are
evidence that the existing approach has value.

[snip]

And with the above context, your pragmatic point makes sense in a
"perfect is the enemy of the good" sense :-)

Unfortunately your proposed resolution won't solve what now appears to
be the root of the problem: shiboken_helpers.cmake doesn't appear to
support multiple installed Python versions, and will necessarily break
with every Python transition.  It seems to me that that cmake file
should be generated during pyside2's build to enable runtime detection
of the support for all Python versions that were compiled into the
pyside2 libraries.  Alternatively, as a less desirable option, that
cmake file could be modified in override_dh_auto_install (or somewhere
more appropriate) to exclusively support the current python3-default
version.  In both cases, I'm assuming that the compiled py39 and py310
libs are functional.

Thank you for your help investigating this option!

Unfortunately I'm out of time for the near future, but if you'd like I
can upload an untested 5.15.3 package to experimental for you to test.
To be honest, I won't have time to make the cmake fix for what isn't
even one of my packages.  Sorry.

Sincerely,
Nicholas

I can definitely help testing this.

Maybe this is something that upstream would be willing to investigate?

(yeah, I know that all the rage now is to have pyenvs within dockers so
you have 20 copies of everything .. so I'm not holding my breath ;))

Ping! ;)

We believe that the bug you reported is fixed in the latest version of
pyside2, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1008849@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christian Marillat <marillat@debian.org> (supplier of updated pyside2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 12 Jun 2022 18:30:03 +0200
Source: pyside2
Architecture: source
Version: 5.15.2-2.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
Changed-By: Christian Marillat <marillat@debian.org>
Closes: 1008849
Changes:
 pyside2 (5.15.2-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Should always Build-Depends on python3-dev but not on python3-all-dev.
     This package is unable to manage two python versions at the same time.
     (Closes: #1008849)
Checksums-Sha1:
 0790db02041ac30315ba07a0b0502a6b11da89ef 7778 pyside2_5.15.2-2.1.dsc
 1bd17cef222f289e29a42e26588f633636c585e8 19064 pyside2_5.15.2-2.1.debian.tar.xz
 55bd1b2c625c6527a879da60d8b35e3c79dd82f3 14106 pyside2_5.15.2-2.1_source.buildinfo
Checksums-Sha256:
 c9afd7ebc7f76144ad4b851c8379e05ed8a6942d9eac6b7783e99babbc21a912 7778 pyside2_5.15.2-2.1.dsc
 d064207a4ed81eef8c0a7bce808a9d88936dd93da564e595e3d3e3b57b53edd4 19064 pyside2_5.15.2-2.1.debian.tar.xz
 a5e3bd6431b186fc09e8a40adda5e5c13bc09323a5138c6e6fb378bbec54d282 14106 pyside2_5.15.2-2.1_source.buildinfo
Files:
 7e0c4c03e702ba84524ac9eb9fe62e1a 7778 python optional pyside2_5.15.2-2.1.dsc
 c7d8d92489d0de82baea79a6366baada 19064 python optional pyside2_5.15.2-2.1.debian.tar.xz
 ad5d1d1b9e47aacabaf12cfe5e52b7f2 14106 python optional pyside2_5.15.2-2.1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEpAH/mTaPofmBUt51XICMK2VVgRcFAmKmFUUACgkQXICMK2VV
gRdDfhAA8jR0q0WtGvAnateMNog6LNMWaFnCaVhHXbQ0m4okyEzH1B4DvnTXx2Xg
lALakk0zOleyk2fy7EgxXn8VIW7Xu8xr2YCd5ZMM6elWupLkUnIahlpf2GQUwQwY
Ob6gwQEkjgVbgAKPHs2MBhteV4lsd7dnFkchEVHF5cYhoWWuqH64sOWVyiQ4hR5p
4zM/HgwbPCQ22nG2+peSrBRX3zUbqwUHcXMXKUi060z8G02Rb/JAcS6F43cXDfo+
U5cM0ukdmra2Ud3yHd1AWsuZUca+xDKji0yrw1sW4w8guUpYbzekuiEeXslR27bV
85W60Mx+ZJ4IBT46H1k2oOfBWVSbOtcqiXOS9b87wzs+nlgo6np5aYQmlXcn2CDx
17iy2pYY7TwMrj8ErQHasJfr28ks8OP3BoHH2oiFR/P2Ush7T5cmTXWp3yaOvgUX
3XKFeK26dbDMD19QbOdlQwNd2UNu4+sTKLNuVCTyd5NuMfL45DqQryNwvMjkdzhS
P4bhfe/52BFiRH3a90trf79zTAyzCN/wubncFXrQAGh8gxXhlzjunEE5ohTcsfgQ
HR4uirviQ0h2mUKKJXDQvGEAyC7IVUHZRW3bFRhOnjM1zrmowv+kxlt/mTVX3gMW
YOUboBo43+f10wmlJZSc6W8MBDNy38TSJnuvIFZ+RImjl7Gmno4=
=u1VI
-----END PGP SIGNATURE-----