On 12. 10. 24 0:32, Adam Williamson wrote:
On Fri, 2024-10-11 at 21:29 +0200, Michal Ambroz wrote:
Hello Miro,
Thank you very much for the tool - I am adding it to toolbox.
I actually love the new pyproject macros, but in the past there were some
discrepancies between
Fedora and EPEL where no
Hello Pythonistas,
The old %py3_build and %py3_install macros (201x-era) as documented in [1] use
a deprecated feature of setuptools.
It is highly recommended to use the current %pyproject macros instead as
documented in [2] and [3] sooner than it becomes necessary.
To help you convert your
On 05. 11. 24 0:36, Gerald B. Cox via python-devel wrote:
Posted originally here:
https://discussion.fedoraproject.org/t/how-to-pass-arbritary-options-in-spec-file-for-python-build/135434/
I’m currently refactoring the picard spec file to conform to the new python
build guidelines (used pyproje
On 05. 11. 24 19:40, Gerald B. Cox via python-devel wrote:
so upstream created the option to disable
the update dialog via the --disable-autoupdate option
What is this option for? Where are you supposed to use it?
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
Hello Pythonistas.
I came across a couple packages that only install .dist-info in
%python3_sitelib/arch, or an additional .pth file.
E.g. it's a Python-packaged command line tool that installs /usr/bin/foo +
.dist-info only (e.g. badchars, ddiskit, fuzza, isrcsubmit, ksc, pwncat,
python-vev
On 04. 11. 24 21:25, Blaise Pabon via python-packagers-sig wrote:
I think I would like to join python packagers... unless the group is only
concerned with packaging the cpython language for Fedora.
Hello Blaise,
first of all, python-packagers-...@lists.fedoraproject.org is not for
communicati
On 27. 09. 24 18:46, Miro Hrončok wrote:
On 24. 09. 24 13:55, Maxwell G wrote:
Later, I'd like to experiment with https://github.com/packit/specfile to
write a minimal automatic convertor from the old macros to the new. It won't
be perfect and likely won't be able to ditch any manually listed
On 24. 09. 24 13:55, Maxwell G wrote:
Later, I'd like to experiment with https://github.com/packit/specfile to
write a minimal automatic convertor from the old macros to the new. It won't
be perfect and likely won't be able to ditch any manually listed
BuildRequires at first, but at least it mi
On 27. 09. 24 23:43, Miro Hrončok wrote:
And there are some outright bugs:
-%{python3_sitelib}/ATpy-*.egg-info
+%{python3_sitelib}/ATpy.dist-info
Here the replacement ate the -* part thinking it is -py3.13.
Not sure how to properly differentiate between:
%{python3_sitelib}/ATpy-*.egg-info
%{p
On 06. 11. 24 2:29, Gerald B. Cox via python-devel wrote:
Hi Miro, Thanks for taking the time to respond. I'm probably not doing a very
good job explaining this. Perhaps it would help you
understand better if you went directly to the ticket where the option was
created:
https://tickets.metabr
Hey Pythonistas,
%pyproject_buildrequires has gained 2 new flags: -p and -g
-p reads runtime dependencies (and extras given via -x or read from tox
configuration) directly from the pyproject.toml [project] table. This is useful
for backends that do not implement the optional
prepare_metadata_
On 26. 11. 24 14:52, Peter Oliver via python-devel wrote:
TL;DR: Should Rust bindings for Tree-sitter parsers be packaged independently
(using the usual Python packaging process), or should they be a subpackage of
the main Tree-sitter parser package (effectively giving us Python bindings for
fr
On 15. 11. 24 0:18, Miro Hrončok wrote:
The new 1.16 version of pyproject-rpm-macros is available in all Fedoras and is
on its way to c10s and c9s.
This is now available in c10s and c9s, hence also in EPEL 10.0 and EPEL 9 Next
Koji buildroots.
tox 4.23 is currently available in Rawhide + upd
Hey Pythonistas,
now when we have %pyproject_buildrequires -p, I paln to deprecate -w.
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/502
The flag was provisional and no Fedora package needs it any more.
The -w and -p flags are both useful for build backends that don't i
On 06. 12. 24 14:40, Anirban Mitra via python-devel wrote:
Fontmake is a python tool required to generate variable fonts from designspace
and ufo sources. I have created a variable font which I want to package for
fedora. But I couldn't find fontmake in fedora packages. So do I need to
package
On 07. 12. 24 18:51, Sérgio Basto wrote:
Hi,
I just notice that we have in Fedora 3 python packages for Multipart
Handler [1] I'm maintainer of python-MultipartPostHandler2 and I think
the package can be orphan and retired later , because now we have one
replacement . The other two I don't know
Hello,
I propose we retire python-nose from Fedora 43+ immediately after branching.
The package has been deprecated for 5 years:
https://fedoraproject.org/wiki/Changes/DeprecateNose
It does not build with Python 3.14:
https://bugzilla.redhat.com/2323163
We carry downstream-only patches s
Hello Pythonistas.
When we updated tox from version 3 to 4, it no longer fails when here is no
suitable tox configuration found. This was a deliberate upstream choice.
Unfortunately, it means that packages that use %pyproject_buildrequires with -t
or -e now silently succeed if there is no tox
On 05. 02. 25 10:47, Miro Hrončok wrote:
Hello Pythonistas.
When we updated tox from version 3 to 4, it no longer fails when here is no
suitable tox configuration found. This was a deliberate upstream choice.
Unfortunately, it means that packages that use %pyproject_buildrequires with -t
or
On 02. 02. 25 12:50, Sandro via python-devel wrote:
On 31-01-2025 18:17, Miro Hrončok via python-devel wrote:
When dealing with python-nose removals I noticed the python-pytest7 package
sues nose in tests. Those tests could be easily skipped, but I wonder if it
isn't time to get rid of py
Hello Pythonistas.
When dealing with python-nose removals I noticed the python-pytest7 package
sues nose in tests. Those tests could be easily skipped, but I wonder if it
isn't time to get rid of pytest7 (and pluggy1.3).
The tracking bugzilla https://bugzilla.redhat.com/2256331 now only depe
On 06. 12. 24 1:46, Miro Hrončok wrote:
On 05. 12. 24 23:24, Fabio Valentini via python-devel wrote:
On Thu, Nov 21, 2024 at 11:13 PM Miro Hrončok via python-devel
wrote:
Hey Pythonistas,
- Python 3.8 reached upstream End of Life 2024-10-07.
- RHEL 8 Python 3.8 Stream has been retired since
On 19. 12. 24 16:30, Orion Poplawski via python-devel wrote:
I'm trying to update pywt to 1.6 or 1.8 here:
https://src.fedoraproject.org/rpms/python-pywt/pull-request/6
I'm running into an issue where it seems that I must install the built wheel
locally so that I can then build the docs, but I
Hey Pythonistas,
- Python 3.8 reached upstream End of Life 2024-10-07.
- RHEL 8 Python 3.8 Stream has been retired since May 2023.
- Debian buster had Python 3.7, bullseye has 3.9.
- Ubuntu 20.04 LTS (Focal Fossa) has Python 3.8.
- Standard support ends April 2025.
Fedora 42 release date is A
Hello Pythonistas.
tl;dr I wonder if we should get rid of the last downstream-only patch in
Fedora's Python,
the one responsible for /usr/local/lib(64)/python... installation location.
The removal would bring us closer to upstream, but perhaps cause a regression
for our users.
I propose to ad
On 05. 12. 24 23:24, Fabio Valentini via python-devel wrote:
On Thu, Nov 21, 2024 at 11:13 PM Miro Hrončok via python-devel
wrote:
Hey Pythonistas,
- Python 3.8 reached upstream End of Life 2024-10-07.
- RHEL 8 Python 3.8 Stream has been retired since May 2023.
- Debian buster had Python 3.7
On 06. 12. 24 18:31, Neal Gompa via python-devel wrote:
On Fri, Dec 6, 2024 at 12:04 PM Fabio Valentini via python-devel
wrote:
On Tue, Dec 3, 2024 at 7:03 PM Miro Hrončok via python-devel
wrote:
Hello Pythonistas.
tl;dr I wonder if we should get rid of the last downstream-only patch in
On 06. 12. 24 18:56, Neal Gompa wrote:
On Fri, Dec 6, 2024 at 12:48 PM Miro Hrončok via python-devel
wrote:
On 06. 12. 24 18:31, Neal Gompa via python-devel wrote:
On Fri, Dec 6, 2024 at 12:04 PM Fabio Valentini via python-devel
wrote:
On Tue, Dec 3, 2024 at 7:03 PM Miro Hrončok via
On 11. 01. 25 23:02, Nico Kadel-Garcia wrote:
The dependency chains still using python-nose are pretty popular, and
include awscli and Samba. This may not be as easy as it seems at
first glance.
Could you please point out that dependency trees? I see neither package as
affected by nose retire
On 06. 01. 25 12:45, Miro Hrončok wrote:
Hello,
I propose we retire python-nose from Fedora 43+ immediately after branching.
The package has been deprecated for 5 years:
https://fedoraproject.org/wiki/Changes/DeprecateNose
It does not build with Python 3.14:
https://bugzilla.redhat.com
On 16. 01. 25 13:29, Miro Hrončok wrote:
On 06. 01. 25 12:45, Miro Hrončok wrote:
Hello,
I propose we retire python-nose from Fedora 43+ immediately after branching.
The package has been deprecated for 5 years:
https://fedoraproject.org/wiki/Changes/DeprecateNose
It does not build with Py
Hello packagers.
As a followup to this email sent a month ago to the python-devel list, I now
plan to make the incorrect (and unsafe) usage of %pyproject_buildrequires -t/-e
and %tox without a suitable tox configuration fail the build.
This is a breaking change, but I believe it's the only wa
Hi.
The rebuild is stuck. We have ~600 packages left to rebuild (from ~4250).
At this point, we'd like to merge, but we are investigating some OpenQA
failures that might (or might not) be related.
In the meantime, please continue following the instructions: Do not build
Python packages in ra
On 11. 06. 25 16:49, Łukasz Wojniłowicz wrote:
On 25-06-11 09:47, Karolina Surma wrote:
Hello,
On 6/10/25 11:35, Karolina Surma wrote:
The Python 3.14 rebuild is in progress. We plan to merge the side tag soon.
The side tag has been merged. Now you can build Python packages in
regular Rawhi
Hi Pythonistas.
I have just realized, that the %py_byte_compile macro, when invoked like this:
%py_byte_compile %{python3} %{buildroot}%{_datadir}/nemo*
Will happily compile files like
/usr/share/nemo-compare/__pycache__/nemo-compare-preferences.cpython-313.pyc
/usr/share/nemo-pastebin/
On 12. 06. 25 17:02, Łukasz Wojniłowicz wrote:
Thanks. I wrote that, because bugzilla mentioned python-click. I didn't know
that bugzilla wasn't working properly. It's confusing.
So the bugzilla says "nothing provides python3.13dist(click) needed by
python3-aw-core-0.5.17-3.fc42.noarch" which
Hello Python packagers,
as many are currently migrating from the old Python RPM macros to the new due
to https://fedoraproject.org/wiki/Changes/DeprecateSetuppyMacros I'd like to
reiterate:
%generate_buildrequires
%pyproject_buildrequires [options...]
This is MANDATORY when you use %pypr
On 09. 07. 25 4:31, Scott Talbert via python-devel wrote:
Is there any way to use the pyproject macros when setup.py isn't in the root
directory?
I maintain a couple of packages where this is the case - one where there are
actually two PyPI packages built from the same source package, and anot
On 10. 07. 25 2:45, Scott Talbert wrote:
The one thing - %pyproject_save_files can't work in the case of building
multiple wheels in the same package, right?
Correct. As ow now, it has no API to say "save files from package X", so when
multiple wheels are installed in %pyproject_install, we
39 matches
Mail list logo
