python-pyside2 fails to build with Python 3.10.0a2. /sources/shiboken2/libshiboken/sbkstring.cpp:250:23: error: expression is not assignable Py_REFCNT(ob) = 1; ~~~~~~~~~~~~~ ^ 1 error generated. https://docs.python.org/3.10/whatsnew/changelog.html#id11 bpo-39573: Convert Py_REFCNT() and Py_SIZE() macros to static inline functions. They cannot be used as l-value anymore: use Py_SET_REFCNT() and Py_SET_SIZE() to set an object reference count and size. This change is backward incompatible on purpose, to prepare the C API for an opaque PyObject structure. https://bugs.python.org/issue39573 For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-x86_64/01805997-python-pyside2/ For all our attempts to build python-pyside2 with Python 3.10, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/python-pyside2/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.10: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/ Let us know here if you have any questions. Python 3.10 will be included in Fedora 35. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.10. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
Victor, please take a look.
I'm working on a fix: https://src.fedoraproject.org/rpms/python-pyside2/pull-request/7
I reported the issue to Qt upstream (PySide project): https://bugreports.qt.io/browse/PYSIDE-1436
Upstream is having a very active discussion on the fix so I would rather wait for them than apply the patch which just makes it "build". Hopefully they'll provide a patch (or something that I can make a patch from) and we won't have to wait until the next patch release.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
This is a mass-posted update. Sorry if it is not 100% accurate to this bugzilla. The Python 3.10 rebuild is in progress in a Koji side tag. If you manage to fix the problem, please commit the fix in the rawhide branch, but don't build the package in regular rawhide. You can either build the package in the side tag, with: $ fedpkg build --target=f35-python Or you can the build and we will eventually build it for you. Note that the rebuild is still in progress, so not all (build) dependencies of this package might be available right away. Thanks. See also https://fedoraproject.org/wiki/Changes/Python3.10 If you have general questions about the rebuild, please use this mailing list thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/G47SGOYIQLRDTWGOSLSWERZSSHXDEDH5/
Looks like upstream didn’t come through in time for the mass rebuild. The last update in the discussion was > It is under test, and there are a few critical bugs with debug builds. on 2021-05-13. The proposed patch set is https://codereview.qt-project.org/c/pyside/pyside-setup/+/348390; the notes say: > Unfortunately, there are a couple of bugs remaining which > need further investigation. (Built with debug mode) > Some bugs are infinite loops. > > The test script breaks with unicode errors, which needs > fixing, before continuing on this. What do you think should be done?
The f35-python side tag has been merged to Rawhide. From now on, build as you would normally build.
*** Bug 1960117 has been marked as a duplicate of this bug. ***
*** Bug 1969107 has been marked as a duplicate of this bug. ***
Nope, no fix from upstream as of yet.
Porting pyside2 to Python 3.10 is beyond me, anyone else care to take a stab at it? It doesn't seem like upstream is in any hurry.
Let's see if https://codereview.qt-project.org/c/pyside/pyside-setup/+/348390 is any better than the status quo. I can build it in Copr and see if the dependent packages build.
Built. I've triggered builds for the dependent packages.