pyliblo fails to build with Python 3.13.0a1. src/liblo.c: In function ‘__pyx_pf_5liblo_12ServerThread___init__’: src/liblo.c:13502:3: error: implicit declaration of function ‘PyEval_InitThreads’; did you mean ‘PyEval_SaveThread’? [-Werror=implicit-function-declaration] 13502 | PyEval_InitThreads(); | ^~~~~~~~~~~~~~~~~~ | PyEval_SaveThread According to https://docs.python.org/3.13/whatsnew/3.13.html: Remove PyEval_InitThreads() and PyEval_ThreadsInitialized() functions, deprecated in Python 3.9. Since Python 3.7, Py_Initialize() always creates the GIL: calling PyEval_InitThreads() did nothing and PyEval_ThreadsInitialized() always returned non-zero. (Contributed by Victor Stinner in https://github.com/python/cpython/issues/105182.) https://docs.python.org/3.13/whatsnew/3.13.html For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.13/fedora-rawhide-x86_64/06593988-pyliblo/ For all our attempts to build pyliblo with Python 3.13, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.13/package/pyliblo/ 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.13: https://copr.fedorainfracloud.org/coprs/g/python/python3.13/ Let us know here if you have any questions. Python 3.13 is planned to be included in Fedora 41. To make that update smoother, we're building Fedora packages with all pre-releases of Python 3.13. 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.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
*** Bug 2291593 has been marked as a duplicate of this bug. ***
I just managed to build it with 'Wno-error=incompatible-pointer-types' flag . $ python --version Python 3.13.0b2 Wrote: /builddir/build/RPMS/python3-pyliblo-0.10.0-31.fc41.x86_64.rpm Wrote: /builddir/build/RPMS/python3-pyliblo-debuginfo-0.10.0-31.fc41.x86_64.rpm Wrote: /builddir/build/RPMS/pyliblo-debugsource-0.10.0-31.fc41.x86_64.rpm Finish: rpmbuild pyliblo-0.10.0-31.fc41.src.rpm Finish: build phase for pyliblo-0.10.0-31.fc41.src.rpm INFO: Done(pyliblo-0.10.0-31.fc41.src.rpm) Config(default) 0 minutes 26 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result Finish: run
+ /usr/bin/python3 setup.py build '--executable=/usr/bin/python3 -sP' running build running build_ext /usr/lib64/python3.13/site-packages/Cython/Compiler/Main.py:381: FutureWarning: Cython directive 'language_level' not set, using '3str' for now (Py3). This has changed from earlier releases! File: /builddir/build/BUILD/pyliblo-0.10.0-build/pyliblo-0.10.0/src/liblo.pxd tree = Parsing.p_module(s, pxd, full_module_name) performance hint: src/liblo.pyx:286:5: Exception check on '_err_handler' will always require the GIL to be acquired. Possible solutions: 1. Declare '_err_handler' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. 2. Use an 'int' return type on '_err_handler' to allow an error code to be returned. Compiling src/liblo.pyx because it changed. [1/1] Cythonizing src/liblo.pyx building 'liblo' extension creating build creating build/temp.linux-aarch64-cpython-313 creating build/temp.linux-aarch64-cpython-313/src gcc -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -fexceptions -fexceptions -fexceptions -O3 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC -I/usr/include/python3.13 -c src/liblo.c -o build/temp.linux-aarch64-cpython-313/src/liblo.o -fno-strict-aliasing -Werror-implicit-function-declaration -Wfatal-errors src/liblo.c: In function ‘__pyx_f_5liblo__msg_callback’: src/liblo.c:7808:94: error: passing argument 1 of ‘lo_blob_dataptr’ from incompatible pointer type [-Wincompatible-pointer-types] 7808 | __pyx_t_7 = __Pyx_PyBytes_FromCString(((unsigned char *)lo_blob_dataptr((__pyx_v_argv[__pyx_v_i])))); if (unlikely(!__pyx_t_7)) __PYX_ERR(0, 234, __pyx_L1_error) | ~~~~~~~~~~~~~^~~~~~~~~~~~ | | | lo_arg * src/liblo.c:1313:78: note: in definition of macro ‘__Pyx_PyBytes_FromCString’ 1313 | #define __Pyx_PyBytes_FromCString(s) __Pyx_PyBytes_FromString((const char*)s) | ^ compilation terminated due to -Wfatal-errors. error: command '/usr/bin/gcc' failed with exit code 1
The following patch makes it work without -Wno-error=incompatible-pointer-types: diff --git a/src/liblo.pyx b/src/liblo.pyx index 25066c1..85ab713 100644 --- a/src/liblo.pyx +++ b/src/liblo.pyx @@ -232,12 +232,12 @@ cdef int _msg_callback(const_char *path, const_char *types, lo_arg **argv, elif t == 't': v = _timetag_to_double(argv[i].t) elif t == 'b': if PY_VERSION_HEX >= 0x03000000: - v = bytes(<unsigned char*>lo_blob_dataptr(argv[i])) + v = bytes(<unsigned char*>lo_blob_dataptr(<lo_blob>argv[i])) else: # convert binary data to python list v = [] - ptr = <unsigned char*>lo_blob_dataptr(argv[i]) - size = lo_blob_datasize(argv[i]) + ptr = <unsigned char*>lo_blob_dataptr(<lo_blob>argv[i]) + size = lo_blob_datasize(<lo_blob>argv[i]) for j from 0 <= j < size: v.append(ptr[j]) else: I'd submit it upstream, but the project seems pretty much dead.
I'll see if we can get whatever uses liblo off the Jam_KDE image, then.
Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/ This package fails to install and maintainers are advised to take one of the following actions: - Fix this bug and close this bugzilla once the update makes it to the repository. (The same script that posted this comment will eventually close this bugzilla when the fixed package reaches the repository, so you don't have to worry about it.) or - Move this bug to ASSIGNED if you plan on fixing this, but simply haven't done so yet. or - Orphan the package if you no longer plan to maintain it. If you do not take one of these actions, the process at https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs will continue. This package may be orphaned in 7+ weeks. This is the first reminder (step 3) from the policy. Don't hesitate to ask for help on https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ if you are unsure how to fix this bug.
So, the things that use pyliblo are Carla - https://src.fedoraproject.org/rpms/Carla - and raysession - https://src.fedoraproject.org/rpms/raysession . Both seem like useful tools with active upstreams, so it seems a shame to use them. I *think* it's possible to build Carla without liblo support. I don't know how important the features lost would be. CCing Martin Gansser, who's been taking care of it, in case he has any input. Sorry to CC three emails, I cannot tell which one is the current one.
Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/ This package fails to install and maintainers are advised to take one of the following actions: - Fix this bug and close this bugzilla once the update makes it to the repository. (The same script that posted this comment will eventually close this bugzilla when the fixed package reaches the repository, so you don't have to worry about it.) or - Move this bug to ASSIGNED if you plan on fixing this, but simply haven't done so yet. or - Orphan the package if you no longer plan to maintain it. If you do not take one of these actions, the process at https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs will continue. This package may be orphaned in 4+ weeks. This is the second reminder (step 4) from the policy. Don't hesitate to ask for help on https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ if you are unsure how to fix this bug.
This package has been orphaned. You can pick it up at https://src.fedoraproject.org/rpms/pyliblo by clicking button "Take". If nobody picks it up, it will be retired and removed from a distribution.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Automation has figured out the package is retired in rawhide. If you like it to be unretired, please open a ticket at https://pagure.io/releng/new_issue?template=package_unretirement
There does seem to be a somewhat-more-maintained fork at https://github.com/gesellkammer/pyliblo3 which we could adopt. That fork already responded to and fixed a Fedora-related bug - https://github.com/gesellkammer/pyliblo3/issues/5 . It hasn't cut a release since 2021, but there seem to be regular commits. Perhaps we could contribute this there, package that (either as a continuation of pyliblo, or under the new name) and flip the deps to use it? It would be a shame to lose Carla, which seems like a major audio tool, and is useless without pyliblo (I checked, it's needed for the GUI to work at all).