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
1 week, 4 days
Co-maintainers for my ham packages
by Matt Domsch
Due to an impending move to NYC and related downsizing of my house into a
2-bedroom apartment, I'm selling all my ham radio gear. Therefore I won't
be able to test any of the Fedora packages I maintain with actual
hardware. Would anyone be interested in maintaining or co-maintaining
these?
- direwolf - Sound Card-based AX.25 TNC
- CubicSDR - Cross-Platform Software-Defined Radio Panadapter
- liquid-dsp - Digital Signal Processing Library for Software-Defined Radios
- sdrpp - SDRPlusPlus bloat-free SDR receiver software
- SoapySDR - A Vendor Neutral and Platform Independent SDR Support Library
- soapy-rtlsdr - SoapySDR module for RTL-SDR hardware
Thanks,
Matt N5MLD
2 weeks, 3 days
DNF5: Checking signatures of packages installed out of a repository?
by Petr Pisar
Hello,
DNF5 got a complaint
<https://github.com/rpm-software-management/dnf5/issues/991> that "dnf update
https://..." skips verifying package signatures:
$ sudo dnf update https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.... https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2....
[...]
Warning: skipped PGP checks for 2 package(s).
A DNF5 developer confirmed that old DNF4 does not verify signatures too.
The verification happens only for packages comming from a repository. Why DNF5
looks bad is because it actually prints the warning and thus keeps the user
better informed.
The nonchecking behavior probably exists to make installing local packages
easy. If DNF5 would insist on checking the signatures, Fedora users would have
to pass --no-gpgchecks option to their "dnf5" commands to override the new
default, or start signing their packages. As always security is not easy.
Because this an old behavior and some users probably depend on it, enabling
the verification for all cases looks like an abrupt change.
I would would like to hear your opinion: Should DNF5 start verifying all
packages? Should DNF5 keep ignoring signatures for out-of-repository packages?
Or should rather narrow the verification skip to packages from a local file
system? Any other options?
-- Petr
2 weeks, 5 days
Automate your Fedora package maintenance using Packit
by Laura Barcziova
If you're a Fedora package maintainer, we've got an exciting automation
solution for you!
At the beginning of the year, we announced a new feature called
pull_from_upstream that eases the process of bringing upstream releases
into Fedora. This feature can be easily configured directly in the dist-git
repository without access to the upstream (as opposed to our previously
introduced automation). It is most suitable for simple packages with
straightforward update processes (e.g. without patches, or need to build in
side tags).
Our automation works on top of the Upstream Release Monitoring [1], and
here's how to set it up:
1.
Enable Upstream Release Monitoring for your Fedora package: set the
mapping of the project in Anitya and in the left column in
https://src.fedoraproject.org/rpms/$YourPackage, change *Monitoring
status* to *Monitoring*.
2.
Add the Packit configuration with the *pull_from_upstream* job to your
dist-git repository (see example
https://packit.dev/docs/configuration/downstream/pull_from_upstream#example
).
Once set up, here's how it works:
-
Upstream Release Monitoring creates a Bugzilla bug when new upstream
versions are detected.
-
As a reaction to that, Packit:
-
automatically uploads the upstream archive to the lookaside cache,
-
creates dist-git pull request(s) at https://src.fedoraproject.org/
<https://src.fedoraproject.org/rpms/$YourPackage> with all the
necessary changes, like updates to the specfile and sources.
If you are interested in this, read the previously published full post with
the details of the setup here: https://packit.dev/posts/pull-from-upstream.
Since the publication of this post, many users have adopted this feature
and provided valuable feedback, allowing us to enhance the UX. We're now
excited to assist you in automating the process as well!
In addition to creating pull requests in dist-git, Packit can also automate
Koji builds and Bodhi updates:
-
https://packit.dev/docs/configuration/downstream/koji_build
-
https://packit.dev/docs/configuration/downstream/bodhi_update
For complete automation documentation, don't miss our comprehensive Fedora
release guide at: https://packit.dev/docs/fedora-releases-guide. It
contains all the essential information and setup tips.
For any questions, feel free to contact us: https://packit.dev/#contact.
Best regards,
Packit team!
[1]
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release...
3 weeks, 4 days
Making -Wmissing-include-dirs an error?
by Neal Gompa
Hey all,
Recently, one of the folks working on packaging stuff in Fedora KDE
nearly missed an issue caused by GCC emitting a warning about missing
include dirs:
> cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or directory [-Wmissing-include-dirs]
> cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or directory [-Wmissing-include-dirs]
I did manage to figure out this meant we needed an additional build
dependency (qt6-qtbase-private-devel, FYI), but it made me think if
there's a reason this shouldn't be an error.
If it's an error, then at least we can evaluate these things and
ensure we have the right build inputs...
What do y'all think?
--
真実はいつも一つ！/ Always, there's only one truth!
3 weeks, 6 days
Request for comment- tuned replacing power-profiles-daemon plan
by Kate Hsuan
Hi Folks,
We would like to replace power-profiles-daemon with tuned. There are
many power-related software that offer similar functions. Advanced
users may install several power management tools, for example, tuned
and power-profiles-daemon (ppd), and get confused about which tools
manage the system and cause unexpected behaviors for the system. By
integrating power-profiles-daemon with tuned, the user can get extra
features to finetune the system, and the basic feature provided by ppd
can be used according to the user's demand. It also can reduce the
efforts of the maintainer.
The impact of this plan would be gnome-control-center (power panel),
KDE, sysprof, and tuned (or some projects depending on ppd). We should
move the ppd API and features to tuned to provide the same features of
it. From the API aspect, we also can design a new API for the basic
feature, ppd provided but the software dependent on ppd should be
modified to use the new API. Although, for the long-term plan, a set
of new API is a good option. For the short-term plan, moving the
original one to tuned is good for those applications depending on ppd.
Moreover, the detailed change proposal can be found here.
https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon
If you have any suggestions, please let us know.
Thank you. :)
--
BR,
Kate
1 month
openmpi 5.0.0 update coming - drops i686 and C++ API
by Orion Poplawski
I'm going to start building openmpi 5.0.0 and its requirements (pmix
4.2.7, prrte 3.0.2) and dependencies in a side-tag starting tomorrow.
Notable changes are:
* Dropping support for 32-bit
* Dropping support for C++ API
* Change in the environment variable to allow oversubscription (running
with more processes than available cores)
I will be making changes to dependent packages to address these changes.
I've been rebuilding deps in COPR
(https://copr.fedorainfracloud.org/coprs/orion/pmix-4.2/builds/) and
most rebuild fine. One exception is MUSIC which depends on the C++ API.
There is a longstanding upstream issue to address this. Hopefully
this will finally get dealt with.
There are no soname bumps, but pmix has proved problematic in the past
but its deps will be rebuilt.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
1 month
