I hope this email finds everyone well. We are currently packaging PyTorch for Fedora and we are actively packaging the dependencies. We’re reaching out to see if anyone is interested in joining the project. If you’re interested in more information, our meeting notes are in a GitHub repo and we have the AI/ML SIG discussion page where we’ve hosted all of our post meeting discussions. We have a WikiPage for our package assignment list if you would like to see what needs packaging or just to see the status of the project. Our next meeting is tomorrow, October 11th at 9AM EST and it’s on the FedoCal under the SIG calendar. All lists are found below. If you’re interested in joining, have any questions, or want to get a calendar invite for our reoccurring meeting, please feel free to email me at kabdo(a)redhat.com or Teng at tema(a)redhat.com.
AI/ML SIG Discussion Page: https://discussion.fedoraproject.org/tag/ai-ml-sig
Meeting Notes: https://github.com/kaitlynabdo/pytorch-fedora-meeting-notes
Packaging Assignment List: https://fedoraproject.org/wiki/SIGs/PyTorch/packagingStatus
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
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
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.
Rust SIG / PyO3 maintainer in Fedora
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
- 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
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
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?
I have a GitHub Action (https://github.com/dogtagpki/jss/actions/runs/5810230552/job/15794978022) that fails due to a conflict between dnf and dnf5 when using the rawhide docker image. I have been trying to keep up with the dnf/dnf5 revert story, but I may have missed something about the current state of affairs/expectations around it working without issue. I am not sure to whom I should raise this issue, any suggestions welcome - thanks!
Recently, one of the folks working on packaging stuff in Fedora KDE
nearly missed an issue caused by GCC emitting a warning about missing
> 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!
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.
If you have any suggestions, please let us know.
Thank you. :)
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
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.
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/