Re: %pyproject_save_files for packages without Python modules
Hi,
On 10/30/24 12:47, Miro Hrončok via python-devel wrote:
I want to change
that, but I want to consult the API ideas:
1. Allow %pyproject_save_files without arguments
%pyproject_install
%pyproject_save_files
Simple, easy. Calling %pyproject_save_files without arguments will work
and it will only save the .dist-info for %{pyproject_files}. (This will
allow to use the pyproject RPM declarative BuildSystem without
BuildOption(install) as well.)
Are there any downsides? Even if packages forget to add arguments to
%pyproject_save_files, this will work:
%install
%pyproject_install
%pyproject_save_files
%files -n python3-foo -f %{pyproject_files}
%{python3_sitelib}/foo/
My only worry now is that the "default" behavior of
%pyproject_save_files exists only to accommodate a very niche need.
I'm not the biggest fan of this option. Exactly for the reason you
described: it looks clear and tempting and I suspect this could become a
boilerplate which we'd see in various specfiles in time. If we don't
mind such outcome, then I guess it's alright to make this way.
3. Another +argument
%pyproject_install
%pyproject_save_files +nomodules
We already have +auto, so this would be another +thing. I don't like
this much, but more than 2.
+nomodules is verbose which is a plus. OTOH the other + option is
explicitly forbidden in Fedora, so adding this would mean folks need to
remember that there are some valid and some invalid arguments. Because
of that overhead I'd vote against this approach.
4. Another short option
===
%pyproject_install
%pyproject_save_files -M
(The character choice is arbitrary.) We already have -l/-L. This would
be another such option.
I'm in favour of this one. We already have a bunch of, admiteddly,
somewhat cryptic one letter flags, e.g. in %pyproject_buildrequires, so
this is something I'm accustomed to. The meaning of a capital letter is
widely known. It clearly indicates the packager's intention to create
exactly a package without modules and is visible at first glance for any
reader of such spec (as opposed to option 1 which, for an untrained eye,
may be easy to overlook).
--
Karolina Surma (she/her/hers)
Software Engineer
Python Maintenance Team, Red Hat
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Fedora 43 Python 3.14 rebuild in a side tag starts today
Hello, We are starting the Python 3.14 mass rebuild in the side tag for Fedora 41 with Python 3.14.0b2. Please, follow the original instructions when planning to build your Python packages. We'll let you know when we'll plan to merge the side tag. And... keep your fingers crossed :) Karolina On 5/28/25 14:28, Karolina Surma wrote: Hello, To deliver Python 3.14 with Fedora Linux 43, we will run a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.14 Python 3.14.0b2 has been released on Monday, May 26th, 2025 and shipped in all Fedoras. We hope to start the mass rebuild beginning next week. TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.14. Details: If you see a "Rebuilt for Python 3.14" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f43-python $ koji wait-repo f43-python --build --request It takes time to build all the essential packages, so don't expect all your dependencies to be available right away. Any attempts to build your packages in the side tag before we do will likely fail due to missing dependencies. When in trouble, ask here or on Fedora's Matrix - Fedora Python room (https://matrix.to/#/#python:fedoraproject.org) Ping me (ksurma) or Miro (mhroncok) if you need to talk to us. Builds will appear here: https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f43- python&inherited=0 Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks! Karolina -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 43 Python 3.14 mass rebuild status
Hello, The Python 3.14 rebuild is in progress. We plan to merge the side tag soon. So far, we've successfully built 3682 out of 4259 source packages, with 577 remaining to be built. See the list of packages sorted by maintainers at the end of this mail. If your package fails because there is a non-dependency problem, you might have already received a bugzilla from us in the past. If the build failure is related to changes in Python 3.14, it should contain some hints about the problem. If you haven't received a bugzilla from us yet, feel free to open a new one and block the PYTHON3.14 tracking bug. You can verify your package builds with Python 3.14 via a scratch build: $ koji build --scratch f43-python or $ fedpkg build --scratch --target f43-python If successful, you can submit a build to the side tag from the rawhide branch in dist-git repository via: $ fedpkg build --target f43-python Please, don't build Python packages in regular rawhide now. After the side tag is merged, we'll let you know when it's safe to build in regular rawhide again. The remaining failures can be fixed afterwards. Karolina Maintainers by package: APLpysergiopr DisplayCAL jistone ngompa Mayavi orion ansible-lint pnemade ara dmsimard asv qulogic audiotubethunderbirdtr avogadro2-libs sagitter awscli2 davdunc nforro azure-clijcline bandit mikelo2 misc binwalk ajax swt2c blender design-sw ignatenkobrain luya music slaanesh bodhi-server abompard humaton lenkaseg borgbackup fschwarz bout++ davidsch buildbot besser82 ignatenkobrain limb ngompa radez buildstream atim jjardon calibre chkr kevin zbyszek cantera fuller sic capstone rebus ret2libc certbot nb cfn-lint music chirpjskarvad cjdnssdgathman conda-build orion copr-backend frostyx msuchy praiskup cozy suve criu adrian rstoyanov cura churchyard diceware kushal did lzachar psss diffoscope zbyszek distro-info suraia dlib principis thunderbirdtr dolfin zbyszek duplicitylimb dxf2gcodedwrobel electrum js emacs-jedi melmorabity eric yselkowitz fastapi-cli music pwouters rominf fawltydeps gui1ty fedrqgotmax23 fontmake music gingasergiopr git-filter-repo asn salimma glances aekoroglu jonathanspw gnofract4d yselkowitz go-vendor-tools gotmax23 go2rpm alexsaezm eclipseo gotmax23 mikelo2 google-api-python-client limb mbaldessari mikelo2 gr-air-modes jskarvad gr-funcube jskarvad gr-hpsdr jskarvad gr-iqbal jskarvad gr-osmosdr cottsay jskarvad gr-rds jskarvad sharkcz grpc defolos neil httpie churchyard mikelo2 ikiwiki thm input-remapper alexpl kittyatim jonathanspw solopasha zawertun kiwi-boxed-pluginngompa kmymoney rdieter vascom kurchu ngompa kvircnucleo libarcus churchyard libpeas amigadave kalev libunity rdieter lilv nphilipp tartina linode-cli cicku mikelo2 nb liquidctlsuve lutris bunnyapocalypse farchord mailman3 ngompa salimma mailman3-fedmsg-plugin abompard matrix-synapse dcallagh v02460 mirrormanager2 abompard mkdocs-material dcavalca monkeytype dcavalca salimma mopidy girst mopidy-mpd girst mrchem jussilehtola mu churchyard kushal muse oget myst-nb jjames nanopb topazus nordugrid-arcellert novelwriter fed500 nvme-stastbzatek ocrmypdf qulogic odcs cqi hlin lsedlar qwan onnx aalvarez dherrera openapi-python-client dogukancagatay opencv hhorak jkucera jridky kwizart openms sagitter openvino aekoroglu packit lachmanfrantisek lbarczio mfocko mmassari nforro nikromen ttomecek paraview orion sagitter patool eclipseo pcp agerstmayr fberat jkurik lchilton nathans samfeifer wcohen pcs cfeist idevat mlisik mpospisi omular tojeline petscsagitter picard alexlan cicku gbcox poezio orphan protobuf adrian jonathanspw mizdebsk orion salimma psi4 jussilehtola pychess bruno dcavalca pychromecast pbrobin
Re: Fedora 43 Python 3.14 mass rebuild status [DONE]
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 Rawhide with Python 3.14 safely. Shortly we'll start opening bugzillas for the remaining packages. ## What now? The usual advice If you are aware of the problem and working towards fixing it, set your bugzilla to ASSIGNED to avoid further automated reminders. If blocked by dependencies, do not close the bugzillas as NOTABUG or DUPLICATE just because it is "not a problem in your package". The automation will file new ones anyway. Use the Blocks and Depends on fields in bugzilla instead please. ## My package fails to build because it has test failures in %check Please, try to resolve the failures. If you are confident that the package works fine, but the tests are wrong, skip some failing tests, ideally with a link to an upstream issue. Do not disable (e.g. comment out) all tests just to unblock the rebuild of your package, it usually only hides the problem. ## My package fails to build because it has broken build dependencies Please try to track the missing build dependencies in Bugzilla. If possible, help the maintainers of your dependencies to get them rebuilt. When in need of escalation, ask us for provenpackager help (ideally with pull requests to be merged). Once possible, rebuild your package. When you do, the bugzilla will eventually get automatically closed, but you can do that manually as well. ## My package was rebuilt with Python 3.14 but it has broken runtime dependencies Please try to track the missing runtime dependencies in Bugzilla. If possible, help the maintainers of your dependencies to get them rebuilt. When in need of escalation, ask us for provenpackager help (ideally with pull requests to be merged). When the dependencies are rebuilt, your package will install successfully once again and the bugzilla will eventually get automatically closed, but you can do that manually as well. ## My package failed to build but installs just fine Some packages that only require libpython3.13.so.1.0 will successfully pull in the python3.13 package as a dependency and hence they don't have installation issues. They need to be rebuilt with Python 3.14 anyway, we don't want Fedora users to pull in two Python versions unless they need them for development purposes. ## How to run things locally? You can use mock. Make sure to: 1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all 2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 --enablerepo=local ... ## Where to get help Reply to this thread or find us (ksurma, mhroncok) on Matrix (#python:fedoraproject.org). Karolina -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
