Rust bindings for Python (pyo3 versions <0.19, cpython) broken with
Python 3.12
by Fabio Valentini
Hello Pythonistas and Rustaceans,
TL;DR: Only PyO3 v0.19.2 (and later) will ever properly support Python
3.12. Port your Python projects to v0.19 **NOW**.
Older versions of PyO3 (especially pyo3 v0.15, v0.16, v0.17, and
v0.18) are *not* compatible with Python 3.12 due to some ABI changes
in unicode strings and behavioural changes wrt/ "immortal" objects.
This also affects all current versions of the "cpython" Rust bindings,
with no timeline for Python 3.12 support.
As far as I can tell, extensions that use pyo3 < v0.19 or the
"cpython" bindings can (and likely will) not work as expected on
Python 3.12 if they use the affected APIs (either by producing garbage
data in strings that are passed over the FFI boundary, or by
crashing).
There are applications in Fedora that still rely on *ancient* versions
of PyO3, potentially affected by this:
- cpython: mercurial
- pyo3 v0.15: fapolicy-analyzer, python-bcrypt, python-cryptography
- pyo3 v0.16: python-y-py
- pyo3 v0.17: unused compat packages, will be retired
- pyo3 v0.18: matrix-synapse
I *stongly* recommend to move all of these packages to pyo3 v0.19 in
Rawhide as soon as possible. I will try to submit pull requests with
the required changes for affected packages (except mercurial, since
there's no version of the "cpython" crate that supports Python 3.12 in
sight).
There's already a few packages that depend on pyo3 v0.19, which I will
rebuild in rawhide for pyo3 v0.19.2, which has much better support for
Python 3.12 than v0.19.0 and v0.19.1 (breezy, python-rpds-py, orjson)
unless there are any objections.
As soon as no packages depend on the compat packages for old versions
of pyo3 any longer, I will retire them from Rawhide (and F39,
depending on the timing), since they will never work with Python 3.12
and nothing should use them.
I've added <package>-maintainers(a)fedoraproject.org for all these
packages to the CC of this message.
Fabio
Rust SIG / PyO3 maintainer in Fedora
2 weeks, 2 days
16 packages still need a Python 3.12 rebuild, final freeze in 6 days
by Miro Hrončok
Hello packagers,
here is the list of packages that still need a Python 3.12 rebuild for Fedora 39+.
Packages on this list have broken dependencies and hence the users of Fedora
Linux 39+ cannot install them at all.
Moreover, users of Fedora Linux 37 or 38 with the listed packages installed are
unable to upgrade to Fedora Linux 39+.
We need to either rebuild those packages in Fedora Linux 39+ or retire+obsolete
them to clear the upgrade path. Package retirement is not a "punishment" for
not fixing the package, it is merely a way to allow our users to upgrade.
When a retired package is fixed after Fedora Linux 39 final release, it can be
added back to the distribution.
The Fedora 39 Final Freeze starts on 2023-10-03 14:00 UTC -- that leaves only 6
days to push updates via Bodhi, meaning they will not be autopushed in time.
Please, if you are planning to fix the packages, set low karma limits and ask
another packager to test it and add karma.
Request freeze exceptions when needed:
https://qa.fedoraproject.org/blockerbugs/propose_bug
I plan to propose "mass" retirement of the remaining packages without a
requested freeze exception and a clear path forward a couple days after the
freeze starts, so we have time to ship an updated fedora-obsolete-packages.
Packages broken in Rawhide by maintainer:
atkac fail2ban
cottsay python-bloom
dcavalca python-mathics3 python-mathicsscript
echevemaster python-protego
hobbes1069 fail2ban freecad python-pyside2
jcaratzas python-logutils
jkastner freecad
luya openshadinglanguage
matyas condor
music openshadinglanguage
orion fail2ban
qulogic python-geomet
rebus dionaea python-smbpasswd
rmattes python-bloom
salimma python-rust-update-set
sdyroff python-ansi
slaanesh openshadinglanguage
tmz fail2ban
ttheisen condor
valtri condor
zbyszek python-igor
Details:
condor
======
https://bugzilla.redhat.com/2172684
Bugzilla ASSIGNED half a year ago, no update since.
Maintainer NEEDINFOed today.
Seems to a problem with Boost since Fedora 38.
dionaea
=======
https://bugzilla.redhat.com/2219972
Bugzilla ASSIGNED 2 months ago, no update since.
Maintainer NEEDINFOed last week.
fail2ban
========
https://bugzilla.redhat.com/2219991
https://github.com/fail2ban/fail2ban/issues/3487
Bugzilla ASSIGNED 2 months ago, no update since.
Maintainers NEEDINFOed last week.
freecad
=======
Bugzilla ASSIGNED 2 months ago, no update since.
Maintainer NEEDINFOed last week.
Blocked on pyside2.
openshadinglanguage
===================
https://bugzilla.redhat.com/2220055
Seems to be actively progressing, blocked on this clang15 PR:
https://src.fedoraproject.org/rpms/clang15/pull-request/1
python-ansi
===========
https://bugzilla.redhat.com/2220110
Bugzilla ASSIGNED 2 months ago, no update since.
Maintainers NEEDINFOed last week.
The fix of FTBFS is trivial (BR python3-setuptools, as described in
https://bugzilla.redhat.com/2155030 in December 2022).
However, package has no %check, so I am reluctant to fix it myself, not knowing
if it even works.
python-bloom
============
https://bugzilla.redhat.com/2220133
Maintainer said to retire it last week.
python-geomet
=============
https://bugzilla.redhat.com/2220250
https://github.com/geomet/geomet/issues/92
Bugzilla ASSIGNED 2 months ago, no update since.
Maintainer NEEDINFOed last week.
python-igor
===========
https://bugzilla.redhat.com/2220275
Bugzilla ASSIGNED a month ago, no update since.
Maintainer NEEDINFOed last week.
python-logutils
===============
https://bugzilla.redhat.com/2220313
https://src.fedoraproject.org/rpms/python-logutils/pull-request/2
PR opened a month ago, no progress since.
New maintainer NEEDINFOed this week.
python-mathics3
===============
https://bugzilla.redhat.com/2220323
https://src.fedoraproject.org/rpms/python-mathics3/pull-request/2 (still fails)
Bugzilla ASSIGNED a month ago, no update since.
Maintainer NEEDINFOed last week.
python-mathicsscript
====================
https://bugzilla.redhat.com/2220324
Depends on mathics3
Bugzilla ASSIGNED a month ago, no update since.
Maintainer NEEDINFOed last week.
python-protego
==============
https://bugzilla.redhat.com/2240746
Built in Fedora 39 only (the f39 branch is ahead of rawhide).
I'd normally just go ahead and merge the branches myself,
but the "fix" was to remove all the tests and add redundant manual Requires,
so I am reluctant to do that.
python-pyside2
==============
https://bugzilla.redhat.com/2155447
https://bugzilla.redhat.com/2220452
https://bugreports.qt.io/browse/PYSIDE-2388 (WONTFIX)
Upstream no longer cares about this pyside2 version.
Bugzilla ASSIGNED 2 months ago, no update since.
Maintainer NEEDINFOed last week.
python-rust-update-set
======================
https://bugzilla.redhat.com/2220488
Bugzilla ASSIGNED 2 months ago, no update since.
Maintainer NEEDINFOed last week.
python-smbpasswd
================
https://bugzilla.redhat.com/2154979
Bugzilla ASSIGNED 8 months ago, no update since.
Maintainer NEEDINFOed last week.
---
Packages fixed in Rawhide with Fedora 39 updates in need of karma:
python-box https://bodhi.fedoraproject.org/updates/FEDORA-2023-595f85c4f3
python-click-spinner https://bodhi.fedoraproject.org/updates/FEDORA-2023-39dcc5afea
python-elpy https://bodhi.fedoraproject.org/updates/FEDORA-2023-a999e30051
python-nipy https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed0adf8107
python-pvc https://bodhi.fedoraproject.org/updates/FEDORA-2023-05814fcc72
python-pydocstyle https://bodhi.fedoraproject.org/updates/FEDORA-2023-3703495e43
python-sklearn-genetic-opt
https://bodhi.fedoraproject.org/updates/FEDORA-2023-d8d9f6376a
python-streamlink https://bodhi.fedoraproject.org/updates/FEDORA-2023-0eeb1b6b0e
python-uinput https://bodhi.fedoraproject.org/updates/FEDORA-2023-9ba7c6ba53
python-uvicorn https://bodhi.fedoraproject.org/updates/FEDORA-2023-ae19f823c9
python-uvloop https://bodhi.fedoraproject.org/updates/FEDORA-2023-ae19f823c9
python-ZEO https://bodhi.fedoraproject.org/updates/FEDORA-2023-24d588cf46
python-ZODB3 https://bodhi.fedoraproject.org/updates/FEDORA-2023-24d588cf46
Thanks for your help.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 month, 4 weeks
%pyproject_save_files license handlers
by Maxwell G
Hi Pythonistas,
%pyproject_save_files automatically handles marking license files
with %license when a build backend installs them into a package's
dist-info directory and the License-File header is specified in the
METADATA file. Currently, only setuptools and hatchling meet this
criteria. Notably, poetry and flit do not support this. They will
install license texts into the dist-info directory, but they do not add
the License-File metadata. The License-File tag is not standardized, and
discussion on PEP 639 which defines this standard has stalled. I believe
relying on this feature is a problem, as if a project changes build
systems or some other config and a packager doesn't realize, suddenly
the license file won't be marked with %license or even worse, not
installed at all. Since the pyproject macros read the build backend from
pyproject.toml without packagers having to manually specify anything
(which is generally great!), this situation seems likely to occur.
Until these issues are resolved, I propose banning this in Fedora and
requiring packagers to manually mark files with %license or at least
adding a large warning to the Packaging Guidelines. It can be similar to
the `'*' +auto` flags which are used by pyp2spec for automatic PyPI
builds in Copr but not allowed in Fedora proper.
What do y'all think? Am I missing something?
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
2 months
Need help with build failure
by Mattia Verga
python-calcephpy builds were FTB since between the F39 mass rebuild (which completed fine) and the Cython 3.x change (which started to fail).
While I was waiting for upstream to fix the package for compatibility with Cython 3.x I tried to rebuild it forcing cython < 3.0, but I got an odd build failure to which I didn't pay great attention, I simply thought about some glitch trying to force the cython version to the compat package.
Now that upstream released a new version compatible with Cython 3.x I tried to update the package, but I still get the odd build failure. It seems that during the configure script the package complains about being cross-built... the latest build attempt completed fine on i686 and ppc64le, while failed on other architectures.
Does anyone have any idea about this?
Thanks
Mattia
[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=32685
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=105822496
2 months, 1 week
Questions about %pyproject_buildrequires
by Scott Talbert
Hi all,
First, is it possible to use this macro if the pyproject.toml isn't in the
root directory of the package? There doesn't seem to be an option to
specify a path, so I tried cd'ing into a path and running it, but it
seemed to run into an odd error like it was trying to include my directory
as a package.
Second, can %pyproject_buildrequires (and the other %pyproject_ macros) be
used multiple times in a package? I have a package that has multiple
pyproject.toml files in it (but that's mostly a legacy thing, so I could
probably separate them into multiple RPMs).
Thanks,
Scott
2 months, 2 weeks
