Bug 2021946
| Summary: | rdiff-backup fails to build with Python 3.11: error: lvalue required as left operand of assignment | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tomáš Hrnčiar <thrnciar> |
| Component: | rdiff-backup | Assignee: | Frank Crawford <frank> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | frank, kevin, mhroncok, thrnciar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-01-02 08:40:25 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2016048 | ||
Thanks. I'll push this upstream as I'm sure they will be keen to know of this issue. However, as they are now working on the next generation, I'll probably end up adding a patch similar to your notes here into the Fedora package. Submitted upstream as https://github.com/rdiff-backup/rdiff-backup/issues/633 A new version has been added to rawhide - rdiff-backup-2.0.5-6, with the issue fixed, but I'm not sure how to get it rebuilt in your COPR branch? What do I raise a PR against, and what should it include? Alternatively, will it automatically be tested at some point? Thanks Frank Thanks. Here you can see that 2.0.5-6 has succeeded: https://copr.fedorainfracloud.org/coprs/g/python/python3.11/package/rdiff-backup/ If you had sent a PR in https://src.fedoraproject.org/rpms/rdiff-backup/pull-requests it would have shown up https://copr.fedorainfracloud.org/coprs/g/python/python3.11/builds/?dirname=python3.11:pr:2 (where 2 is the number of the PR in https://src.fedoraproject.org/rpms/rdiff-backup/pull-requests). Since Miro answered your question, I am clearing the needinfo. Thank you, Frank, for taking care of this. |
rdiff-backup fails to build with Python 3.11.0a2. src/_librsyncmodule.c:543:36: error: lvalue required as left operand of assignment 543 | Py_TYPE(&_librsync_SigMakerType) = &PyType_Type; | ^ src/_librsyncmodule.c:544:38: error: lvalue required as left operand of assignment 544 | Py_TYPE(&_librsync_DeltaMakerType) = &PyType_Type; | ^ Since Py_TYPE() is changed to a inline static function, Py_TYPE(obj) = new_type must be replaced with Py_SET_TYPE(obj, new_type): see the Py_SET_TYPE() function (available since Python 3.9). For backward compatibility, this macro can be used: #if PY_VERSION_HEX < 0x030900A4 && !defined(Py_SET_TYPE) static inline void _Py_SET_TYPE(PyObject *ob, PyTypeObject *type) { ob->ob_type = type; } #define Py_SET_TYPE(ob, type) _Py_SET_TYPE((PyObject*)(ob), type) #endif (Contributed by Victor Stinner in bpo-39573.) https://bugs.python.org/issue39573 https://docs.python.org/3.11/whatsnew/3.11.html For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.11/fedora-rawhide-x86_64/02940979-rdiff-backup/ For all our attempts to build rdiff-backup with Python 3.11, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.11/package/rdiff-backup/ 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.11: https://copr.fedorainfracloud.org/coprs/g/python/python3.11/ Let us know here if you have any questions. Python 3.11 is planned to be included in Fedora 37. To make that update smoother, we're building Fedora packages with all pre-releases of Python 3.11. 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.