Hello Pythonistas,
pyproject-rpm-macros 1.19.0 was just built and it provides a small enhancement.
Consider this code:
%generate_buildrequires
pushd nemo-audio-tab >&2
%pyproject_buildrequires
popd >&2
pushd nemo-pastebin >&2
%pyproject_buildrequires
popd >&2
It can now be replaced with:
%generate_buildrequires
%pyproject_buildrequires -d nemo-audio-tab
%pyproject_buildrequires -d nemo-pastebin
Same for %pyproject_wheel.
See the documentation in README, section *Building wheels from custom
directories*
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/READ…
Beware: As this is a new option for the macros, if your spec file uses it, you
cannot parse it with an old version of the macros installed. This includes
running commands like fedpkg prep, fedpkg srpm etc.
Updates are available in Bodhi for all Fedora releases and I plan to update the
package in c9s and c10s during the current RHEL development cycle.
Happy packaging.
--
Miro Hrončok
--
Phone: +420777974800
Hello folks,
I'd like to get feedback on a new macro for pyproject-rpm-macros that
allows packagers to override upstream dependency constraints that are
incompatible with the versions available in Fedora.
*The problem*
More and more packages move to pyproject macros that make use of upstream
metadata. Upstream Python projects frequently pin or constrain dependency
versions (e.g. numpy<2.0, attrs==25.3). When Fedora ships a different
version, packagers currently resort to sed/patch in %prep to modify
pyproject.toml, requirements.txt, setup.cfg etc. This is quite fragile and
honestly a pain point every time as it breaks on upstream reformatting,
varies across build systems and pollutes the spec. And I'm not the biggest
fan of deciphering regexes.
*The solution*
A new %pyproject_patch_dependency macro, declared in %prep, that provides a
uniform way to modify dependency constraints regardless of the build
backend. It affects both BuildRequires (via %pyproject_buildrequires) and
runtime Requires (via patching the installed .dist-info/METADATA during
%pyproject_install).
*Usage*
%prep
%autosetup -p1
%pyproject_patch_dependency cython:drop_upper
%pyproject_patch_dependency numpy:set_upper:3.0
%pyproject_patch_dependency legacy-dep:ignore
One override per macro call. The syntax is:
%pyproject_patch_dependency PACKAGE:ACTION[:VALUE][:br_only]
The reasoning for only one override per macro call is that each override
should be verified and possibly commented on why it's needed, instead of
blindly removing dependencies. Also having one per line will keep the spec
readable. More than one argument in the macro call will make it error out.
*Available actions*
- drop_upper: remove upper-bound constraints (<, <=, ==, ~=)
- drop_lower: remove lower-bound constraints (>, >=, ==, ~=)
- drop_constraints: remove all version constraints
- set_upper: replace the upper bound with < VALUE
- set_lower: replace the lower bound with >= VALUE
- ignore: remove the dependency entirely
Note: == and ~= act as both upper and lower bounds, so either drop_upper or
drop_lower will remove them. Exclusions (!=) are always preserved.
*Multi-wheel packages (br_only)*
For spec files that build multiple Python subpackages from one source, a
sibling package may need to be ignored in BuildRequires (as it's not yet
installed during build) but kept as a runtime dependency. The br_only
suffix handles this:
%pyproject_patch_dependency sibling-package:ignore:br_only
This ignores the dependency during %generate_buildrequires but leaves the
installed METADATA untouched, so the runtime Requires is preserved.
Related bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2386906
PR: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/567
Alternative approach with a -D flag (most likely will not move this
forward):
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/564
Feedback on the API, action names, or overall approach is welcome.
--
Regards,
Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
Dear all,
After a long process, I am happy to report that we're close to finally
being able to retire python-mock (which has long been deprecated in
favor of unittest.mock)
https://fedoraproject.org/wiki/Changes/RemovePythonMockUsagehttps://bugzilla.redhat.com/show_bug.cgi?id=2258085
❯ fedrq whatrequires python3-mock --src | grep -v -f done.txt
ansible-collection-dellemc-openmanage-10.0.1-3.fc44.src
beets-2.6.1-1.fc44.src
compose-utils-0.1.50-15.fc44.src
gtimelog-0.12.0-9.fc44.src
PRs are open for these
-
https://src.fedoraproject.org/rpms/ansible-collection-dellemc-openmanage/pu…
- https://src.fedoraproject.org/rpms/beets/pull-request/1-https://src.fedoraproject.org/rpms/compose-utils/pull-request/3
- https://src.fedoraproject.org/rpms/gtimelog/pull-request/3
We're likely not going to retire python-mock in F44 itself, despite the
change currently being targeted at it (it was originally filed for F40,
and has been deferred several times as shepherding these changes take
longer than expected).
We will, though, retire the package from Rawhide, so that if it
resurfaces (e.g. a package enabling tests, which pulls in mock) it will
get detected as a FTBFS.
These packages are currently FTBFS for unrelated reasons and we will
just have to not touch them -- rather than committing a change removing
python-mock usage that we can't easily test.
python-hupper
pychess
pytest also has tests that compare the behavior of unittest.mock vs
PyPI mock; that package has not been touched yet until other mock usage
has been removed.
There are several suggestions for how this change could have gone
better I'm taking onboard for next time -- more communication with
involved maintainers, and doing more of the upstreaming -- I apologize
for any inconvenience caused.
Best regards, I
--
_o) Michel Lind
_( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
README: https://fedoraproject.org/wiki/User:Salimma#README
Hi,
As there is not package from Fedora, if one wnats to use vosk von Fedora in python, we have to install it this way:
pip3 install vosk portaudio
But that is something a package for Fedora is not allowed to do to fix it's dependencies.
Would you consider to build and maintain that package?
Things will be way easier as expcetd, because someoneelse had build libvosk.so for you and packaged it already,
so all you have to add is the python part. I tested the libvosk.so from vosk-api-devel.x86_64 via symlinking it:
vosk]# ls -la
insgesamt 25412
drwxr-xr-x. 4 root root 4096 6. Feb 09:25 .
drwxr-xr-x. 8 root root 4096 19. Apr 2025 ..
-rw-r--r--. 1 root root 9892 19. Apr 2025 __init__.py
lrwxrwxrwx. 1 root root 21 6. Feb 09:25 libvosk.so -> /usr/lib64/libvosk.so
-rwxr-xr-x. 1 root root 25986496 19. Apr 2025 libvosk.so_orig
drwxr-xr-x. 2 root root 4096 19. Apr 2025 __pycache__
drwxr-xr-x. 3 root root 4096 19. Apr 2025 transcriber
-rw-r--r--. 1 root root 3984 19. Apr 2025 vosk_cffi.py
and it works as expected. I have no idea what is required for a portaudio package or if the already packaged python3-pyaudio.x86_64 binding will be enough. Python is not my world tbh, but this is:
https://fedoramagazine.org/your-personal-voice-assistant-on-fedora-linux/
and that is what we get if you supply those to packages to Fedora.
Trust me here, what is written in that old article is still true, but way more features have been added since.
The PVA is able to administer a whole cluster of devices in a household and so open, that you can bind anything to it. even an llm can build working plugins for it( just tested ;) ) Due to 20+ supported languages we could make a lot of people happier.
Some core features:
- ollama LLM support for chat and analysing images
- chatgpt support ( same features )
- cluster support for audio/video out and input
- Netflix support
- CardDAV support
- Thunderbird support
- QMMP support
- any video player with MPRS2 ( celluloid prefered )
- fully open sourced
- easy extendible
- phonecall support via "twinkle" , in- and outgoing.
Please let me know what you think.
pylibssh started to fail to build from source recently:
https://koschei.fedoraproject.org/package/python-ansible-pylibssh
Processing files: python-ansible-pylibssh-debugsource-1.2.2-7.fc44.x86_64
RPM build errors:
error: Empty %files file
/builddir/build/BUILD/python-ansible-pylibssh-1.2.2-build/ansible-pylibssh-1.2.2/debugsourcefiles.list
Empty %files file
/builddir/build/BUILD/python-ansible-pylibssh-1.2.2-build/ansible-pylibssh-1.2.2/debugsourcefiles.list
Any idea what might be causing that?
--
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/
Hi folks ,
My nickname is saibug, I am Fedora Infra contributor and I plan to help python-sig .
Is there any good area for getting started please ???
Regards
Saibug
Hello Fedora packagers.
Unfortunately, we need to rebuild all Fedora 43 (and 44) packages with Python
3.14 .pyc files. To obtain a list, use:
$ repoquery --repo=rawhide --refresh -f *.cpython-314.pyc --source
(3931 unique packages)
This is needed because Python 3.14 just bumped the pyc "magic number" (version)
due to a severe bugfix [1].
Packages with old .pyc files will have slower import times and might report AVC
denials in restricted contexts. However, they remain functional, there is no
need to panic.
The plan, as of now, is:
1. Either wait for Python 3.14.0rc2 release or backport the change.
2. Wait for the Fedora 43 branching to finish.
3. Bump and build all 3931 packages in rawhide (except kernel).
4. FF-merge into f43 and build all packages that match the criteria:
a) the rawhide and f43 branches were not different before 3.
b) they have no update stuck in bodhi/gating.
5. Open bugzillas for the remaining packages (failed or skipped rebuild).
The rebuild can be done in any order (i.e. all at once) and does not need to
happen in a side tag.
I will follow up when things start moving. Let me know if I should alter the
plan somehow.
[1] https://github.com/python/cpython/pull/137427
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok