Re: are pyproject rpm macros supposed to pick up the license automatically?
On 29. 05. 24 9:48, Karolina Surma wrote: Hi Felix, The missing bit is whether the build backend of pypdf exposes the metadata that pyproject-rpm-macros use to detect the license file. pypdf uses flit-core as its build backend which doesn't implement `License-File` field (it's a part of PEP 639, still in draft and implemented only in a subset of build backends, like setuptools and hatch). Hopefully in the future it'll become a standard. For now, you've got to declare the license file via the %license macro manually. See "Generating the %files section" of https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/README.md for more details. Most importantly, this paragraph: """ %pyproject_save_files can automatically mark license files with %license macro and language (*.mo) files with %lang macro and appropriate language code. Only license files declared via PEP 639 License-File field are detected. PEP 639 is still a draft and can be changed in the future. It is possible to use the -l flag to declare that a missing license should terminate the build or -L (the default) to explicitly disable this check. Packagers are encouraged to use the -l flag when the %license file is not manually listed in %files to avoid accidentally losing the file in a future version. When the %license file is manually listed in %files, packagers can use the -L flag to ensure future compatibility in case the -l behavior eventually becomes a default. """ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: Creating venv with latest python3.10 requires expat >= 2.6.0
On 18. 04. 24 1:00, Miro Hrončok wrote: On 18. 04. 24 0:37, Miro Hrončok wrote: On 17. 04. 24 23:10, Markus Falb wrote: I wonder if there is a way to reflect that in the spec file something like: ...snip Requires: expat >= 2.6.0 snap... Yes, we need to do that. I'm on it. https://src.fedoraproject.org/rpms/python3.13/pull-request/54 -- other Pythons will follow after CI + review. Here is the Fedora 38 python3.10 update: https://bodhi.fedoraproject.org/updates/FEDORA-2024-7736b7ce48 Other updates are available as well: https://bodhi.fedoraproject.org/updates/?packages=python3.8,python3.9,python3.10,python3.11,python3.12,python3.13 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: Creating venv with latest python3.10 requires expat >= 2.6.0
On 18. 04. 24 0:37, Miro Hrončok wrote: On 17. 04. 24 23:10, Markus Falb wrote: I wonder if there is a way to reflect that in the spec file something like: ...snip Requires: expat >= 2.6.0 snap... Yes, we need to do that. I'm on it. https://src.fedoraproject.org/rpms/python3.13/pull-request/54 -- other Pythons will follow after CI + review. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: Creating venv with latest python3.10 requires expat >= 2.6.0
On 17. 04. 24 23:10, Markus Falb wrote: Hi, I noticed that creating virtualenvs did not work anymore with the latest python 3.10 package on Fedora 38 Hello Markus, Thanks for the report, this is indeed happening. [root@fe60c84b08f3 /]# python3.10 -m venv venv Error: Command '['/venv/bin/python3.10', '-m', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1. snap... And the error is (when I run the failed command): ImportError: /usr/lib64/python3.10/lib-dynload/pyexpat.cpython-310-x86_64-linux-gnu.so: undefined symbol: XML_SetReparseDeferralEnabled Unfortunately this also happens with all python3.8 ... python3.13. 3.11 and 3.12 were still in updates testing, so I have blocked the autopush for now: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d615822702 https://bodhi.fedoraproject.org/updates/FEDORA-2024-98a723cb68 I am afraid this also impacts newer Fedoras once shipped with older expat. https://www.python.org/downloads/release/python-31014/ tells us ... bundled libexpat was updated to 2.6.0 to address CVE-2023-52425... And we unbundle it, yet we depend on the new symbol :( using the fedora container for CI runs without doing global dnf update to save resources I had to update expat from expat-2.5.0-2.fc38.x86_64 to expat-2.6.0-1.fc38.x86_64 Fortunately, fedora:39 from registry.fedoraproject.org already has expat-2.6.2-1.fc39. I wonder if there is a way to reflect that in the spec file something like: ...snip Requires: expat >= 2.6.0 snap... Yes, we need to do that. I'm on it. --- I wonder how to prevent this in the future. There is https://github.com/rpm-software-management/rpm/pull/2372 but that will take a while. Perhaps we need to always Require expat >= version of expat used when building. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: Handling --enable-experimental-jit in Python 3.13
On 17. 04. 24 14:27, Victor Stinner wrote: On Wed, Apr 10, 2024 at 8:23 PM Miro Hrončok wrote: Python 3.13 has an experimental JIT compiler: https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler Enabling it is a configure (hence build-time) option. How do we handle this in Fedora? - We can keep it disabled, as it is experimental. I concur with that. - We can enable it, but be ready to revert if it causes problems. - We can add yet another build variant, but we already have 4 of those (regular, debug, freethreading, freethreading-debug), so I'd rather not make it 6 (or 8, if we include freethreading+jit combinations). I don't know yet if it would be co-installable. I don't think it's worth it. Moreover, it doesn't build on Fedora 39 with clang-17, since Python 3.13 currently requires exactly clang-16. We have multiple clangs/llvms: https://src.fedoraproject.org/rpms/llvm16 https://src.fedoraproject.org/rpms/clang16 Victor, do you think it would be possible to build in the JIT support but have a runtime opt-out/opt-in switch? That way, we can build it, but disable it by default, unless our users want to experiment with it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: RFC: Django latest vs LTS maintenance plan
On 11. 04. 24 22:41, Michel Lind wrote: The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: pytohn3dist(django)`? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: Idea: pynose as drop-in replacement for nose
On 11. 04. 24 15:05, Sandro wrote: On 11-04-2024 13:54, Miro Hrončok wrote: On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. That makes sense. Review is up [1]. If enough packagers adapt, I may not need to go through the changes process. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. Since predicting the future is difficult, I'll start on writing up a proposal while the package is being introduced, anyway. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514 I see "# Package doesn't provide any tests" in the %check section. That certainly feels a bit dodgy. This successor of a test framework decided to ditch all of the tests it used to have? That is certainly a red flag. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: Idea: pynose as drop-in replacement for nose
On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Handling --enable-experimental-jit in Python 3.13
Hello Pythonistas, Python 3.13 has an experimental JIT compiler: https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler Enabling it is a configure (hence build-time) option. How do we handle this in Fedora? - We can keep it disabled, as it is experimental. - We can enable it, but be ready to revert if it causes problems. - We can add yet another build variant, but we already have 4 of those (regular, debug, freethreading, freethreading-debug), so I'd rather not make it 6 (or 8, if we include freethreading+jit combinations). I don't know yet if it would be co-installable. Opinions? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: Idea: pynose as drop-in replacement for nose
On 10. 04. 24 17:30, Sandro wrote: On 10-04-2024 12:04, Miro Hrončok wrote: On 09. 04. 24 19:30, Sandro wrote: Therefore, I'm thinking of introducing pynose as a drop in replacement of deprecated nose. Pynose uses the same namespace as nose, but provides python3dist(pynose). Thus adding Provides: for nose would make it a drop-in replacement for packages currently depending on nose. FTR We MUST NOT add RPM Provides for python3dist(nose) unless we package nose dist-info metadata. Thanks for pointing that out. I was indeed experimenting with it. Is there some documentation or example for packaging extra dist-info metadata? Not really, because it is a hack that should not be done if it can be avoided. You can see a working example in python-lark https://src.fedoraproject.org/rpms/python-lark/c/c7a9aa2e7b0b1d9d621ac60f73c854fdcc154ab2 I also played around pith setuptools' `provide` only to learn later on that pip ignores it entirely (as well as `obsoletes`, which is deprecated). So, the pyproject-rpm-macros are probably not honoring that either. For example %pyproject_buildrequires queries Python for installed packages (hence it reads the packaged dist-info/egg-info metadata) and it will see nose is not installed. It will then query dnf to install python3dist(nose). dnf will install pynose. %pyproject_buildrequires will see nose is not installed. It will query dnf to install python3dist(nose) again. dnf will install nothing. The %pyproject_buildrequires phase will end prematurely when dnf installs nothing. Agreed. If we do add python3dist(nose) it needs to work not cause more issues. Most packages I've looked at recently have a BR for python3-nose. That's covered by adding "%py_provides python3-nose". But dependency resolution in %pyproject_buildrequires uses python3dist. If the package configuration has a dependency on nose declared, I would like that to be satisfiable, both in RPM and pip, by installing python3-pynose. If that is too much hassle or simply (currently) not possible, a fallback to not providing nose at all, is also possible. In that case more packages might need to be patched and we need to educate people te replace dependencies on nose with pynose. My preference at the moment is for the former. If we are to retire python-nose at the same time, I'd do: - have python3-pynose %py_provides (and Obsolete) python3-nose - don't mess with dist metadata at all That way: - packages that use upstream requirements will need to be updated (preferably upstream first => good) - packages that manually BuildRequire python3-nose will likely keep working If the pynose package has a "nose" importable module, providing python3-nose even follows https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_provides_for_importable_modules -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: Idea: pynose as drop-in replacement for nose
On 09. 04. 24 19:30, Sandro wrote: Therefore, I'm thinking of introducing pynose as a drop in replacement of deprecated nose. Pynose uses the same namespace as nose, but provides python3dist(pynose). Thus adding Provides: for nose would make it a drop-in replacement for packages currently depending on nose. FTR We MUST NOT add RPM Provides for python3dist(nose) unless we package nose dist-info metadata. For example %pyproject_buildrequires queries Python for installed packages (hence it reads the packaged dist-info/egg-info metadata) and it will see nose is not installed. It will then query dnf to install python3dist(nose). dnf will install pynose. %pyproject_buildrequires will see nose is not installed. It will query dnf to install python3dist(nose) again. dnf will install nothing. The %pyproject_buildrequires phase will end prematurely when dnf installs nothing. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: %pyproject_buildrequires -r/-x: Attempt to read runtime dependencies from pyproject.toml?
On 27. 03. 24 23:15, Maxwell G wrote: One way to mitigate would be to make the proposed behavior opt-in only, with the possibility to either build wheel with -w option (already existing) or e.g. -p (now-proposed: reading from pyproject.toml) in case backend doesn't have prepare_metadata_for_build_wheel. Yeah, I think -p (for *p*yproject) is good flag name choice. Or even for [*p*roject] table. It is double good. I guess I will throw something out there, but I am not convinced it is a great idea: what about making the `-p` flag fail if `prepare_metadata_for_build_wheel` is available? In my opinion, this should only be a last resort for backends that do not implement the hook. I am not particularly keen on this. This means that once the backend starts supporting it, all the spec files using -p need to drop it. And if the backend only supports it in rawhide, the spec files need to diverge and/or %if-guard the flag. If the backend followed PEP 621 before adding the hook and now it added the hook, it is unlikely the PEP 621 support was dropped. OTHO if the backed was changed (e.g. meson -> poetry), this *could* happen. So I am not entirely opposed for this guard. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Orphaned python-mccabe (dependency of pylint)
Hello.
I have orphaned python-mccabe.
It does not build with updated hypothesis, because the update broke
hypothesmith and I don't have time to look into it:
https://bugzilla.redhat.com/2261579
mccabe is a dependency of pylint.
Packages other than linters should not BuildRequire pylint in Fedora (but they
do).
The recursive dependency tree is very large. Here are some basics:
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mccabe
pylint-0:3.0.3-3.fc40.src
python-f5-icontrol-rest-0:1.3.15-11.fc39.src
python-flake8-0:6.0.0-2.fc39.src
python-lsp-server-0:1.9.0-3.fc40.src
python-twitter-0:3.5-18.fc39.src
python3-flake8-0:6.0.0-2.fc39.noarch
python3-lsp-server+all-0:1.9.0-3.fc40.noarch
python3-pylint-0:3.0.3-3.fc40.noarch
$ repoquery -q --repo=rawhide{,-source} --whatrequires pylint --whatrequires
python3-pylint
crypto-policies-0:20231204-1.git1e3a2e4.fc40.src
distro-info-0:0.18-18.fc39.src
dogtag-pki-tests-0:11.4.3-2.fc39.1.noarch
foomuuri-0:0.21-1.fc40.src
nordugrid-arc-0:6.18.0-2.fc40.src
nvme-stas-0:2.3.1-1.fc40.src
postfix-mta-sts-resolver+dev-0:1.4.0-2.fc40.noarch
pylint-0:3.0.3-3.fc40.noarch
python-geoplot-0:0.5.1-7.fc40.src
python-guessit-0:3.8.0-1.fc40.src
python-hwdata-0:2.3.8-4.fc39.src
python-platformio-0:6.1.13-1.fc40.src
python-pocketlint-0:0.25-1.fc40.src
python-pylint-venv-0:3.0.2-1.fc40.src
python-rebulk-0:3.3.0-1.fc40.src
python3-pocketlint-0:0.25-1.fc40.noarch
python3-spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.noarch
thonny-0:4.1.4-1.fc40.noarch
thonny-0:4.1.4-1.fc40.src
vcs-diff-lint-0:4-3.fc39.noarch
vim-syntastic-python-0:3.10.0-21.fc39.noarch
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mccabe
--recursive
crypto-policies-0:20231204-1.git1e3a2e4.fc40.src
diskimage-builder-0:3.31.0-2.fc40.noarch
distro-info-0:0.18-18.fc39.src
dogtag-pki-tests-0:11.4.3-2.fc39.1.noarch
foomuuri-0:0.21-1.fc40.src
glances-0:3.4.0-3.fc39.src
mu-0:1.2.0-10.fc40.noarch
mu-0:1.2.0-10.fc40.src
nordugrid-arc-0:6.18.0-2.fc40.src
nvme-stas-0:2.3.1-1.fc40.src
ocaml-atd-0:2.15.0-3.fc40.src
piper-0:0.7-5.fc39.src
postfix-mta-sts-resolver+dev-0:1.4.0-2.fc40.noarch
pyee-0:9.0.4-6.fc39.src
pylint-0:3.0.3-3.fc40.noarch
pylint-0:3.0.3-3.fc40.src
python-binary-memcached-0:0.31.2-2.fc39.src
python-croniter-0:1.4.1-1.fc40.src
python-debianbts-0:2.8.2-13.fc39.src
python-django-formtools-0:2.2-10.fc39.src
python-esbonio-0:0.16.4-3.fc40.src
python-f5-icontrol-rest-0:1.3.15-11.fc39.src
python-factory-boy-0:3.3.0-1.fc40.src
python-flake8-0:6.0.0-2.fc39.src
python-flake8-builtins-0:2.1.0-4.fc39.src
python-flake8-comprehensions-0:3.10.1-6.fc39.src
python-flake8-import-order-0:0.18.2-3.fc39.src
python-flake8-polyfill-0:1.0.2-19.fc39.src
python-flake8-quotes-0:3.3.2-4.fc39.src
python-flask-mailman-0:1.0.0-1.fc40.src
python-geoplot-0:0.5.1-7.fc40.src
python-gerritlib-0:0.6.0-24.fc39.src
python-guessit-0:3.8.0-1.fc40.src
python-hacking-0:6.0.1-1.fc40.src
python-hwdata-0:2.3.8-4.fc39.src
python-ipmi-0:0.5.4-3.fc39.src
python-lsp-server-0:1.9.0-3.fc40.src
python-nashpy-0:0.0.40-1.fc39.src
python-nikola-0:8.2.4-4.fc39.src
python-oslo-context-0:5.2.0-1.fc40.src
python-oslo-service-0:3.1.1-8.fc40.src
python-pep8-naming-0:0.13.3-3.fc39.src
python-platformio-0:6.1.13-1.fc40.src
python-pocketlint-0:0.25-1.fc40.src
python-pylint-venv-0:3.0.2-1.fc40.src
python-pymochad-0:0.2.0-10.fc39.src
python-pytest-flake8-path-0:1.5.0-1.fc39.src
python-rebulk-0:3.3.0-1.fc40.src
python-sqlalchemy-utils-0:0.41.1-2.fc39.src
python-twitter-0:3.5-18.fc39.src
python3-esbonio+dev-0:0.16.4-3.fc40.noarch
python3-flake8-0:6.0.0-2.fc39.noarch
python3-flake8-builtins-0:2.1.0-4.fc39.noarch
python3-flake8-comprehensions-0:3.10.1-6.fc39.noarch
python3-flake8-docstrings-0:1.6.0-6.fc39.noarch
python3-flake8-import-order-0:0.18.2-3.fc39.noarch
python3-flake8-polyfill-0:1.0.2-19.fc39.noarch
python3-flake8-quotes-0:3.3.2-4.fc39.noarch
python3-hacking-0:6.0.1-1.fc40.noarch
python3-lsp-server+all-0:1.9.0-3.fc40.noarch
python3-oslo-concurrency-tests-0:5.2.0-1.fc40.noarch
python3-oslo-service-tests-0:3.1.1-8.fc40.noarch
python3-oslo-utils-tests-0:6.2.1-1.fc40.noarch
python3-pep8-naming-0:0.13.3-3.fc39.noarch
python3-pocketlint-0:0.25-1.fc40.noarch
python3-pylint-0:3.0.3-3.fc40.noarch
python3-pytest-flake8-path-0:1.5.0-1.fc39.noarch
python3-spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.noarch
python3-tackerclient-tests-unit-0:1.14.0-1.fc40.noarch
quodlibet-0:4.6.0-1.fc40.src
repo-0:2.35-1.fc39.src
spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.src
thonny-0:4.1.4-1.fc40.noarch
thonny-0:4.1.4-1.fc40.src
vcs-diff-lint-0:4-3.fc39.noarch
vim-syntastic-python-0:3.10.0-21.fc39.noarch
xr-hardware-0:1.1.0-1.fc40.src
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
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
Re: Orphaning python-flit
On 26. 01. 24 4:33, Nico Kadel-Garcia wrote: What is the*fascination* with splitting and renaming packages this way? No idea generally, but in the world of Python packaging, the two cases I know (poetry, flit) were motivated by folks not wanting to pull in full-blown package and environment management apps when they only want to pip install something that uses it. The split made a lot of sense. core - PEP517 backend https://peps.python.org/pep-0517/ the rest - an app that let's you "manage" your project Scenario: - The developer uses the full app to create and develop the project. - The user uses -core to build and install it. (Obviously a developer is free to just use -core as well, if they like it. Many upstream projects use flit-core only.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Orphaning python-flit
Hello.
Now when python-flit-core has been split out of python-flit, I do no longer
have a use-case for python-flit and hence I have orphaned it.
$ repoquery -q --repo=rawhide{,-source} --whatrequires flit
python-perky-0:0.8.2-3.fc39.src
python-pydyf-0:0.8.0-1.fc40.src
python-pyrpm-0:0.14.1-3.fc39.src
python-signature-dispatch-0:1.0.1-4.fc39.src
python-vecrec-0:0.3.1-11.fc40.src
weasyprint-0:60.2-1.fc40.src
The packages would probably build fine with flit-core (happy to help with that
if you are interested).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
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
Re: Broken %pyproject_buildrequires parser
On 29. 12. 23 20:41, Mattia Verga wrote: I think I would just do something like this in %prep: sed -r -i 's/^file:/# &/' tests/requirements.in Thanks, that did it. Is this something broken in upstream code, or is it our parser that needs to be adjusted? Our thing wants to generate dependencies on packages via their names. It cannot properly generate dependencies for file:, https:, git, etc. packages. What should the parser do? We could generate a dependency on python3dist(rpds-py), but it woulds be wrong, this package does not BuildRequire self, it just wants to be installed. It isn't broken in upstream, it's just a tad weird. What upstream does here is using the tests/requirements.in file for a slightly different purpose than we do. Their purpose: describe everything we want installed in the test environment. Our purpose: list the dependencies for tests. Similar or not, the self-dependency is the difference. And unlike other types of BuildRequires we can generate, generating them from a file is non-standardized, so we cannot go to upstream and say "your text file is wrong", because it's just that -- a text file. I couldn't find the relevant pip documentation about 'file:.#egg=' format. file: -> this will be a local path on the filesystem . -> the actual path #egg=rpds-py -> this package is called rpds-py (a hint to pip to know this information before actually going to the path and building a package) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: python packaging assistance sought for xgboost
On 12. 12. 23 7:56, Nathan Scott wrote: Thanks Miro - that size pointer was helpful. Indeed, the only thing in the wheel are 3 metadata files. Things seem to be OK up to this point in the upstream hatchling build: https://github.com/dmlc/xgboost/blob/43897b829680d241491abe1ecd46b2ba9d338967/python-package/packager/pep517.py#L86 ... that temporary directory is populated with all the python files in what looks like a good format, but the generated wheel is essentially empty. Is there any way to see what's happening inside that hatchling.build.build_wheel call I wonder? I don't know. Try adding: [tool.hatch.build.targets.wheel] packages = ["xgboost"] to pyproject.toml. Does it help? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
pyproject-rpm-macros 1.11.0: %pyproject_save_files gains the -l flag (and more)
Hello Pythonistas,
pyproject-rpm-macros 1.11.0 is available in Rawhide + updates-testing for older
releases.
https://bodhi.fedoraproject.org/updates/?packages=pyproject-rpm-macros
I plan to sync it to c9s eventually early next year.
It contains one new feature and several smaller bugfixes:
The new -l/-L flag to %pyproject_save_files
===
As said by Maxwell G on this list [1]:
%pyproject_save_files automatically handles marking license files
with %license when a build backend installs them into a package's
dist-info directory and the License-File header is specified in the
METADATA file. Currently, only setuptools and hatchling meet this
criteria. Notably, poetry and flit do not support this. They will
install license texts into the dist-info directory, but they do not add
the License-File metadata. The License-File tag is not standardized, and
discussion on PEP 639 which defines this standard has stalled. I believe
relying on this feature is a problem, as if a project changes build
systems or some other config and a packager doesn't realize, suddenly
the license file won't be marked with %license or even worse, not
installed at all. Since the pyproject macros read the build backend from
pyproject.toml without packagers having to manually specify anything
(which is generally great!), this situation seems likely to occur.
You can now use `%pyproject_save_files -l` to assert at least one license file
was detected and marked as %license. This is good in case you want a protection
from an accidental silent drop of the %license file in a next release.
Note that the -l flag only asserts *at least one license file was detected*.
It can still mean one of multiple files are silently dropped during a package
upgrade, but that's unlikely to happen for unrelated reasons (such as a change
of a build backend upstream).
For the time being, this assertion is opt-in only. Use `%pyproject_save_files
-L` if you list the %license file manually and you would like to explicitly
opt-out from this check in case it ever becomes the default (no such plan
exists for the time being).
(Note that this still needs to be documented in the Python packaging
guidelines.)
Prevent incorrect usage of %pyproject_buildrequires -R with -x/-e/-t
Using `%pyproject_buildrequires -R` with -x, -t, or -e previously silently
discarded the -R option. Combining either of the flags with -R is actually not
possible and will now error properly.
https://bugzilla.redhat.com/2244282
Show a better error message when %pyproject_install finds no wheel
==
When there is no wheel to install (e.g. when you forget to run
%pyproject_wheel), the underlying pip error message was leaking:
ERROR: You must give at least one requirement to install (maybe you meant "pip
install /builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir"?)
It has been explicitly changed to:
ERROR: %pyproject_install found no wheel in %{_pyproject_wheeldir}
/builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir
https://bugzilla.redhat.com/2242452
Fix %pyproject_buildrequires -w when build backend is installed and pip isn't
=
Packages using `%pyproject_buildrequires -w` would fail to build if the build
backend was already (manually) installed before pip.
This was happening e.g. when testing a local version of the RPM with the build
backend and running something like:
$ mock init
$ mock install ../my-rpms/pytohn3-hatchling-1.2.3-1.fc50.noarch.rpm
$ fedpkg mockbuild -N
But it was also possible to achieve with manual BuildRequires:
BuildRequires: pytohn3-hatchling
...
%generate_buildrequires
%pyproject_buildrequires -w
The %pyproject_buildrequires macro generated a BuildRequires on pip, but it
attempted to build a wheel using pip before the generated pip dependency was
installed. This has now been fixed and the macro will "restart" in case pip is
not yet available to build the wheel.
https://bugzilla.redhat.com/2169855
---
Happy packaging.
Special thanks to Maxwell G, Karolina Surma, and Benjamin Beasley for help with
this release.
[1]
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/YDIHALW766GRSYU3GL635QER2MQABML6/
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
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@lis
Re: Next Wednesday: Opening up the Python Maint Fedora Bugs Triage
On 06. 12. 23 13:28, Miro Hrončok wrote: Hello Pythonistas. Every other Wednesday at 14:00 Europe/Prague the Red Hat Python Maint team has a meeting at https://meet.google.com/xuj-jswy-hat The next meeting is in a week. We go trough the open Fedora Bugzillas, PRs etc. assigned to our members. https://fedoraproject.org/wiki/User:Python-maint We've been doing this for a while and recently we decided to open this meeting for other Python SIG members and interested parties. I've added the meeting to Fedora calendar: https://calendar.fedoraproject.org/SIGs/2023/12/11/#m10669 You are welcome to join us next week. I'll send a reminder. This is happening today at `date -d '2023-12-13 14:00 CET'`. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Heads up: dnf5 cannot handle BuildRequires with Python extras
Hello Pythonistas. In case you upgraded to mock-core-configs-39.3 and see failures like this in rawhide mockbuilds with %pyproject_buildrequires: No match for argument: python3dist(setuptools-scm[toml]) >= 5 No match for argument: python3dist(raven[flask]) No match for argument: python3dist(ini2toml[lite]) >= 0.9 Note that the issue is known and reported: https://github.com/rpm-software-management/dnf5/issues/1084 https://github.com/rpm-software-management/mock/issues/1267 This should block the deployment of https://fedoraproject.org/wiki/Changes/BuildWithDNF5 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: python packaging assistance sought for xgboost
On 10. 12. 23 23:05, Nathan Scott wrote: Thanks for the assistance Miro. I've uploaded a local build log here: https://nathans.fedorapeople.org/xgboost/build.log AFAICS the python parts of the %install step seemed to have worked, but based on Sandro's pointer I can see many files are missing. Building wheels for collected packages: xgboost Building wheel for xgboost (pyproject.toml): started Running command Building wheel for xgboost (pyproject.toml) Building wheel for xgboost (pyproject.toml): finished with status 'done' Created wheel for xgboost: filename=xgboost-2.0.2-py3-none-linux_aarch64.whl size=1413 sha256=e77e7765ce58907708363f8e60bf96ba11abd5f66bb78c1804f59bccdd4df36d There's not much information here, but size 1413 indicates the built wheel does not really have any Python modules in it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: python packaging assistance sought for xgboost
On 08. 12. 23 7:22, Nathan Scott wrote:
Hi all,
I've recently been packaging xgboost for Fedora. It's a C++ project using
cmake, with a python module on the side (all in one source tarball):
https://nathans.fedorapeople.org/xgboost/
The dependent dmlc-core package is here:
https://nathans.fedorapeople.org/dmlc-core/
Everything is prepared and working from the C++ and shared library
perspectives, but I'm struggling with getting the python module to install
using latest Fedora python spec guidelines. Can anyone point out where I've
gone wrong? (looks like its during the final python step in the spec %install)
https://nathans.fedorapeople.org/xgboost/xgboost.spec+python shows my additions to add
the python sub-package and this is the error I now see (this is from the
"%pyproject_save_files xgboost" line right at the end of %install):
Traceback (most recent call last):
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 775, in
main(cli_args)
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 730, in main
file_section, module_names = pyproject_save_files_and_modules(
^
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 720, in
pyproject_save_files_and_modules
generate_file_list(paths_dict, globs, include_auto)
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 534, in
generate_file_list
raise ValueError(f"Globs did not match any module: {missed_text}")
ValueError: Globs did not match any module: xgboost
error: Bad exit status from /var/tmp/rpm-tmp.y91d9b (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.y91d9b (%install)
Hello. As was already said, the error is that:
%pyproject_save_files xgboost
Finds no such Python modules.
If you could provide a full build log, it might indicate what Python modules
(if any) are actually installed.
Examining the wheels from https://pypi.org/project/xgboost/#files
xgboost-2.0.2-py3-none-manylinux2014_x86_64.whl
This one actually contains an xgboost Python module. That might indicate the
build step in %pyproject_wheel is somewhat broken. Without full logs, I cannot
say more.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
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
Next Wednesday: Opening up the Python Maint Fedora Bugs Triage
Hello Pythonistas. Every other Wednesday at 14:00 Europe/Prague the Red Hat Python Maint team has a meeting at https://meet.google.com/xuj-jswy-hat The next meeting is in a week. We go trough the open Fedora Bugzillas, PRs etc. assigned to our members. https://fedoraproject.org/wiki/User:Python-maint We've been doing this for a while and recently we decided to open this meeting for other Python SIG members and interested parties. I've added the meeting to Fedora calendar: https://calendar.fedoraproject.org/SIGs/2023/12/11/#m10669 You are welcome to join us next week. I'll send a reminder. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: I propose sphinx no longer Requires sphinxcontrib-{applehelp,devhelp,jsmath,htmlhelp,serializinghtml,qthelp}
On 08. 11. 23 13:02, Miro Hrončok wrote: On 08. 11. 23 12:57, Neal Gompa wrote: Packages that need those would need to BuildRequire them specifically, as proposed in: -https://src.fedoraproject.org/rpms/xca/pull-request/1 -https://src.fedoraproject.org/rpms/python-django-haystack/pull-request/1 -https://src.fedoraproject.org/rpms/pykka/pull-request/3 -https://src.fedoraproject.org/rpms/extra-cmake-modules/pull-request/2 The change has been offered upstream, but I suppose it will take a while before it is actually landed there. Let me know if you think this needs more discussion before shipping it. (The change is only intended for Fedora 40+ and ELN.) Do we know what the impact of this is going to be beyond those four? All Fedora packages that BuildRequire python3-sphinx (even transitively) were tested. Those that successfully built before this change are known not to be impacted, except for the listed 4 and https://src.fedoraproject.org/rpms/python-fastavro/pull-request/12 (which is special, because the removal only uncovered a bug in tests). This was tested in https://copr.fedorainfracloud.org/coprs/churchyard/sphinxcontrib-optional/builds/ and https://copr.fedorainfracloud.org/coprs/churchyard/sphinxcontrib-mandaotry/builds/ A handful of packages timed out after 5 hours in Copr, happy to fix them later if they they are impacted. Same for the packages that FTBFS now for unrelated reasons. Another impacted package: https://src.fedoraproject.org/rpms/buildstream/pull-request/4 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ 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
Re: I propose sphinx no longer Requires sphinxcontrib-{applehelp,devhelp,jsmath,htmlhelp,serializinghtml,qthelp}
On 08. 11. 23 12:57, Neal Gompa wrote: Packages that need those would need to BuildRequire them specifically, as proposed in: -https://src.fedoraproject.org/rpms/xca/pull-request/1 -https://src.fedoraproject.org/rpms/python-django-haystack/pull-request/1 -https://src.fedoraproject.org/rpms/pykka/pull-request/3 -https://src.fedoraproject.org/rpms/extra-cmake-modules/pull-request/2 The change has been offered upstream, but I suppose it will take a while before it is actually landed there. Let me know if you think this needs more discussion before shipping it. (The change is only intended for Fedora 40+ and ELN.) Do we know what the impact of this is going to be beyond those four? All Fedora packages that BuildRequire python3-sphinx (even transitively) were tested. Those that successfully built before this change are known not to be impacted, except for the listed 4 and https://src.fedoraproject.org/rpms/python-fastavro/pull-request/12 (which is special, because the removal only uncovered a bug in tests). This was tested in https://copr.fedorainfracloud.org/coprs/churchyard/sphinxcontrib-optional/builds/ and https://copr.fedorainfracloud.org/coprs/churchyard/sphinxcontrib-mandaotry/builds/ A handful of packages timed out after 5 hours in Copr, happy to fix them later if they they are impacted. Same for the packages that FTBFS now for unrelated reasons. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
I propose sphinx no longer Requires sphinxcontrib-{applehelp,devhelp,jsmath,htmlhelp,serializinghtml,qthelp}
Hello Pythonistas. In https://src.fedoraproject.org/rpms/python-sphinx/pull-request/59 I propose a change that would make the runtime requirements of: - python3-sphinxcontrib-applehelp - python3-sphinxcontrib-devhelp - python3-sphinxcontrib-jsmath - python3-sphinxcontrib-htmlhelp - python3-sphinxcontrib-serializinghtml - python3-sphinxcontrib-qthelp ...optional (Recommends) in python3-sphinx. Packages that need those would need to BuildRequire them specifically, as proposed in: - https://src.fedoraproject.org/rpms/xca/pull-request/1 - https://src.fedoraproject.org/rpms/python-django-haystack/pull-request/1 - https://src.fedoraproject.org/rpms/pykka/pull-request/3 - https://src.fedoraproject.org/rpms/extra-cmake-modules/pull-request/2 The change has been offered upstream, but I suppose it will take a while before it is actually landed there. Let me know if you think this needs more discussion before shipping it. (The change is only intended for Fedora 40+ and ELN.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: 16 packages still need a Python 3.12 rebuild, final freeze in 6 days
On 02. 10. 23 15:03, Sandro wrote: On 27-09-2023 11:56, Miro Hrončok wrote: here is the list of packages that still need a Python 3.12 rebuild for Fedora 39+. Not mentioned on the list, but still pending, is the update for spyder. It's not mentioned because it does not need a Python 3.12 rebuild. While still related, this is a bit different situation. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: %pyproject_save_files license handlers
On 19. 08. 23 23:57, Maxwell G wrote: On Sat Aug 19, 2023 at 22:13 +0200, Miro Hrončok wrote: On 19. 08. 23 19:44, Maxwell G wrote: Hi Pythonistas, %pyproject_save_files automatically handles marking license files with %license when a build backend installs them into a package's dist-info directory and the License-File header is specified in the METADATA file. Currently, only setuptools and hatchling meet this criteria. Notably, poetry and flit do not support this. They will install license texts into the dist-info directory, but they do not add the License-File metadata. The License-File tag is not standardized, and discussion on PEP 639 which defines this standard has stalled. I believe relying on this feature is a problem, as if a project changes build systems or some other config and a packager doesn't realize, suddenly the license file won't be marked with %license or even worse, not installed at all. Since the pyproject macros read the build backend from pyproject.toml without packagers having to manually specify anything (which is generally great!), this situation seems likely to occur. Until these issues are resolved, I propose banning this in Fedora and requiring packagers to manually mark files with %license or at least adding a large warning to the Packaging Guidelines. It can be similar to the `'*' +auto` flags which are used by pyp2spec for automatic PyPI builds in Copr but not allowed in Fedora proper. What do y'all think? Am I missing something? Hey. Alternatively to banning this: what if we make %pyproject_save_files fail without a license? Obviously, that would be a breaking change, so it could be opt-in first. %pyproject_save_files -l ... When used like this, no License-File header would result in an error. We could introduce a reverse flag -L (don't fail without a license), and have a discussion about changing the default later. The guidelines could than say something like: If there is a license file you MUST do one of the following when using %pyproject_save_files: 1) use -l and don't list it in %files explicitly 2) use -L and list it in %files explicitly That way, we ensure the license is packaged (and marked as %license) while not reducing automation. I like -l flag idea, but I don't think we can make it fail by default for the foreseeable future, given the status of PEP 639 and build system adoption. We could use a heuristic (such as a hardcoded list of globs) to match license files in dist-info directories if License-File doesn't exist, but I'm not sure that's the best idea. I'm hesitant about adding a noop -L flag until we actually have a plan/criteria on when to start enforcing -l, but I don't feel strongly. I've drafted the implementation: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/422 The -l flag asserts at least 1 License-File is present. The -L flag disables the assert (i.e. it does nothing). I was considering the idea that the -L flag would assert no License-File was found, but I don't think that will be that useful. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: 16 packages still need a Python 3.12 rebuild, final freeze in 6 days
On 27. 09. 23 15:58, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Sep 27, 2023 at 11:56:01AM +0200, Miro Hrončok wrote: Hello packagers, here is the list of packages that still need a Python 3.12 rebuild for Fedora 39+. zbyszekpython-igor I retired it now in f39 and rawhide. The first attempt failed halfway because I didn't have a valid token. I repeated the 'fedpkg retire …' command, but I'm not sure if the state got updated correctly. Thanks. The failed token failure is not real. It only fails to disable monitoring. What matters is the dead.package file dist git. See https://pagure.io/fedpkg/issue/505 (opened 6 months ago). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
16 packages still need a Python 3.12 rebuild, final freeze in 6 days
979 Bugzilla ASSIGNED 8 months ago, no update since. Maintainer NEEDINFOed last week. --- Packages fixed in Rawhide with Fedora 39 updates in need of karma: python-box https://bodhi.fedoraproject.org/updates/FEDORA-2023-595f85c4f3 python-click-spinner https://bodhi.fedoraproject.org/updates/FEDORA-2023-39dcc5afea python-elpy https://bodhi.fedoraproject.org/updates/FEDORA-2023-a999e30051 python-nipy https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed0adf8107 python-pvc https://bodhi.fedoraproject.org/updates/FEDORA-2023-05814fcc72 python-pydocstyle https://bodhi.fedoraproject.org/updates/FEDORA-2023-3703495e43 python-sklearn-genetic-opt https://bodhi.fedoraproject.org/updates/FEDORA-2023-d8d9f6376a python-streamlink https://bodhi.fedoraproject.org/updates/FEDORA-2023-0eeb1b6b0e python-uinput https://bodhi.fedoraproject.org/updates/FEDORA-2023-9ba7c6ba53 python-uvicorn https://bodhi.fedoraproject.org/updates/FEDORA-2023-ae19f823c9 python-uvloop https://bodhi.fedoraproject.org/updates/FEDORA-2023-ae19f823c9 python-ZEO https://bodhi.fedoraproject.org/updates/FEDORA-2023-24d588cf46 python-ZODB3 https://bodhi.fedoraproject.org/updates/FEDORA-2023-24d588cf46 Thanks for your help. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Questions about %pyproject_buildrequires
On 13. 09. 23 5:03, Scott Talbert wrote: Hi all, Hi Scott. First, is it possible to use this macro if the pyproject.toml isn't in the root directory of the package? There doesn't seem to be an option to specify a path, so I tried cd'ing into a path and running it, but it seemed to run into an odd error like it was trying to include my directory as a package. You can do this, but you MUST NOT put anything to the standard output. E.g. if you do this: %generate_buildrequires cd subdir %pyproject_buildrequires It'll work properly. However, if you do: %generate_buildrequires cd subdir %pyproject_buildrequires cd - It will generate a dependency on something like /builddir/build/BUILD/pkg-1.2.3 because that is what `cd -` prints to standard output. Same with pushd and popd. The solution is to use >&2 when runnign such commands in %generate_buildrequires. For example: %generate_buildrequires pushd pkg1 >&2 %pyproject_buildrequires popd >&2 pushd pkg2 >&2 %pyproject_buildrequires popd >&2 Second, can %pyproject_buildrequires (and the other %pyproject_ macros) be used multiple times in a package? I have a package that has multiple pyproject.toml files in it (but that's mostly a legacy thing, so I could probably separate them into multiple RPMs). Yes, but %pyproject_insatll SHOULD only be used once (it will install everything, running it multiple times is redundant) and %pyproject_save_files will not work at all. %build pushd pkg1 %pyproject_wheel popd pushd pkg2 %pyproject_wheel popd %install # this will install both wheels: %pyproject_install # we cannot use %%pyproject_save_files here # because mixing files from multiple wheels is not supported -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Looking for a new (possibly better) python-argcomplete maintainer
On 23. 08. 23 13:00, Sandro wrote: On 21-08-2023 13:13, Miro Hrončok wrote: I don't want to maintain it, but pytest uses it for tests, so I don't want to be retired. Is there somebody else who would take better care of it than I do? Miro, you are way too young to "be retired". 臘 I'd be willing to take over maintainership of the package. As always, co-maintainers are welcome. Thanks. I made @gui1ty the main admin a the man bugzilla point of contact for Fedora. On 23. 08. 23 13:39, Christiano Anderson wrote: > If you need a co-maintainer, feel free to invite me. Thanks. Added @canderson9 as a co-admin. On 23. 08. 23 20:47, Maxwell G wrote: > I maintain two of my packages on that list (fedrq and ansible-core), > so I'm happy to co-maintain. Thanks. Added @gotmax23 as a co-admin. Please let me know if I did not figure out your FAS names correctly, neither of you included them in your email, so I had to improvise. There is an open [DO NOT MERGE] PR: https://src.fedoraproject.org/rpms/python-argcomplete/pull-request/19 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: %pyproject_save_files license handlers
On 23. 08. 23 13:17, Sandro wrote:> This might be out of scope, but would it also be possible to have it fail or issue a warning if %pyproject_save_files -l marks a license, but the packager also uses an explicit %license in %files. That would prevent duplication. Unfortunately, the macro have no way of knowing what is included in %files manually, co I am afraid this is not possible to implement. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: %pyproject_save_files license handlers
On 19. 08. 23 19:44, Maxwell G wrote: Hi Pythonistas, %pyproject_save_files automatically handles marking license files with %license when a build backend installs them into a package's dist-info directory and the License-File header is specified in the METADATA file. Currently, only setuptools and hatchling meet this criteria. Notably, poetry and flit do not support this. They will install license texts into the dist-info directory, but they do not add the License-File metadata. The License-File tag is not standardized, and discussion on PEP 639 which defines this standard has stalled. I believe relying on this feature is a problem, as if a project changes build systems or some other config and a packager doesn't realize, suddenly the license file won't be marked with %license or even worse, not installed at all. Since the pyproject macros read the build backend from pyproject.toml without packagers having to manually specify anything (which is generally great!), this situation seems likely to occur. Until these issues are resolved, I propose banning this in Fedora and requiring packagers to manually mark files with %license or at least adding a large warning to the Packaging Guidelines. It can be similar to the `'*' +auto` flags which are used by pyp2spec for automatic PyPI builds in Copr but not allowed in Fedora proper. What do y'all think? Am I missing something? Hey. Alternatively to banning this: what if we make %pyproject_save_files fail without a license? Obviously, that would be a breaking change, so it could be opt-in first. %pyproject_save_files -l ... When used like this, no License-File header would result in an error. We could introduce a reverse flag -L (don't fail without a license), and have a discussion about changing the default later. The guidelines could than say something like: If there is a license file you MUST do one of the following when using %pyproject_save_files: 1) use -l and don't list it in %files explicitly 2) use -L and list it in %files explicitly That way, we ensure the license is packaged (and marked as %license) while not reducing automation. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Intent to orphan several python packages
On 14. 08. 23 0:17, Mukundan Ragavan wrote: On 8/13/23 16:28, Mukundan Ragavan wrote: I am going to orphan the following packages unless someone wants to pick them up. I do not have time to maintain them anymore since the dependencies have become more and more complex with each release.Several of these packages do not have dependencies packaged in Fedora. python-nbconvert python-nbclient Those are required by notebook and somebody from python-maint will take them if they are orphaned. You can assign them to me (churchyard). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Cython 3 plans
On 20. 07. 23 12:16, Miro Hrončok wrote: scipy cstratak mmuzila nforro orion psimovec tomspur ttomecek Fixed via https://src.fedoraproject.org/rpms/scipy/pull-request/29 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Cython 3 plans
On 20. 07. 23 12:16, Miro Hrončok wrote: On 17. 07. 23 21:09, Miro Hrončok wrote: Hello Pythonistas, apparently, Cython 3.0.0 final was released today. I plan to make it build somehow in https://src.fedoraproject.org/rpms/Cython/pull-request/41 and once it does, I'll update the package in Rawhide, introducing a python(3)-cython0.29 conflicting compact package for those who cannot upgrade yet (like python-lxml). Note that Cython 0.29 was only built without tests during the Python 3.12 bootstrap and I am unsure we will ever be able to enable them again (at least not all of them). We'll get rid of emacs-cython-mode during the transition -- it can be packaged separately by someone else if desired. This is ready to be shipped in: https://src.fedoraproject.org/rpms/Cython/pull-request/41 https://src.fedoraproject.org/rpms/python-cython0.29/pull-request/1 Some packages succeeded in https://copr.fedorainfracloud.org/coprs/g/python/cython0.29/ but failed in https://copr.fedorainfracloud.org/coprs/g/python/cython3/ Unless the failure was transient, they will need to pin the build dependency on python3dist(cython) < 3~~. Maintainers by package: ... numpy cstratak limb orion rdieter tomspur ttomecek https://src.fedoraproject.org/rpms/numpy/pull-request/35 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Retiring python-pytest-flake8
On 27. 07. 23 18:26, Michel Alexandre Salim wrote:
⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide
--enablerepo=fedora-source --whatrequires python-pytest-flake8
Always use the actual binary package name for queries like this, as only the
actual package name will show all dependencies that happen to require a
differetn virtual provide:
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-pytest-flake8
cvise-0:2.4.0-3.fc36.src
python-cssutils-0:2.6.0-2.fc38.src
python-nashpy-0:0.0.37-1.fc39.src
python-pyunicorn-0:0.6.1-12.fc38.src
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: Cython 3 plans
On 20. 07. 23 12:16, Miro Hrončok wrote: On 17. 07. 23 21:09, Miro Hrončok wrote: Hello Pythonistas, apparently, Cython 3.0.0 final was released today. I plan to make it build somehow in https://src.fedoraproject.org/rpms/Cython/pull-request/41 and once it does, I'll update the package in Rawhide, introducing a python(3)-cython0.29 conflicting compact package for those who cannot upgrade yet (like python-lxml). Note that Cython 0.29 was only built without tests during the Python 3.12 bootstrap and I am unsure we will ever be able to enable them again (at least not all of them). We'll get rid of emacs-cython-mode during the transition -- it can be packaged separately by someone else if desired. This is ready to be shipped in: https://src.fedoraproject.org/rpms/Cython/pull-request/41 https://src.fedoraproject.org/rpms/python-cython0.29/pull-request/1 Some packages succeeded in https://copr.fedorainfracloud.org/coprs/g/python/cython0.29/ but failed in https://copr.fedorainfracloud.org/coprs/g/python/cython3/ Unless the failure was transient, they will need to pin the build dependency on python3dist(cython) < 3~~. Maintainers by package: ... PyYAML jeckersb https://src.fedoraproject.org/rpms/PyYAML/pull-request/9 ... python-lxml cstratak fale lbalhar mizdebsk https://src.fedoraproject.org/rpms/python-lxml/pull-request/29 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Cython 3 plans
On 20. 07. 23 12:16, Miro Hrončok wrote: python-rapidfuzz thrnciar troycurtisjr See https://src.fedoraproject.org/rpms/python-rapidfuzz/pull-request/2 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Cython 3 plans
On 17. 07. 23 21:09, Miro Hrončok wrote: Hello Pythonistas, apparently, Cython 3.0.0 final was released today. I plan to make it build somehow in https://src.fedoraproject.org/rpms/Cython/pull-request/41 and once it does, I'll update the package in Rawhide, introducing a python(3)-cython0.29 conflicting compact package for those who cannot upgrade yet (like python-lxml). Note that Cython 0.29 was only built without tests during the Python 3.12 bootstrap and I am unsure we will ever be able to enable them again (at least not all of them). We'll get rid of emacs-cython-mode during the transition -- it can be packaged separately by someone else if desired. This is ready to be shipped in: https://src.fedoraproject.org/rpms/Cython/pull-request/41 https://src.fedoraproject.org/rpms/python-cython0.29/pull-request/1 Some packages succeeded in https://copr.fedorainfracloud.org/coprs/g/python/cython0.29/ but failed in https://copr.fedorainfracloud.org/coprs/g/python/cython3/ Unless the failure was transient, they will need to pin the build dependency on python3dist(cython) < 3~~. Maintainers by package: MUSICankursinha PyYAML jeckersb cantera fuller sic h5py orion stevetraylen terjeros libarrow kkeithle libfreenect jkastner kathenas kwizart rmattes libgpuarray orphan mlpack fed500 rcurtin mpi4py limb tomspur numpycstratak limb orion rdieter tomspur ttomecek petscsagitter pygame jskarvad limb sergiomb pyliblo fab python-blosc2zbyszek python-calcephpy mattia python-cftimeorion python-comprefformusic python-cyipopt music python-cysignals pcpa python-cytoolz orion python-djvulibre aekoroglu python-editdistance-s limb python-ezdxf music python-fastavro ankursinha python-gbinder aleasto python-giacpysagitter python-gssapisimo python-healpylupinix python-hidapijonny python-imagecodecs orion python-indexed_gzip ankursinha python-jnius raphgro python-kmod grover mlombard python-llfusedfateyev maci python-lxml cstratak fale lbalhar mizdebsk python-oracledb stevetraylen python-orderedsetvtrefny python-pari-jupyter jjames python-peeweecarlwgeorge cstratak vkrizan python-pplpy jjames python-pyclipper athoscr python-pyedflib iztokf python-pysam davidsch python-pyspike ankursinha python-rapidfuzz thrnciar troycurtisjr python-rtmidifab python-smartcols kalev python-statsmodels sergiopr python-tablesjonathanspw zbyszek python-uamqp mhayden rdma-coredledford honli jwilson kheib michich rust-cbindgendecathorpe scipycstratak mmuzila nforro orion psimovec tomspur ttomecek setools alexl caolanm dwalsh mbarnes pcmoore plautrba rhughes rstrode vmojzis urh jskarvad vapoursynth slaanesh Packages by maintainer: aekoroglu python-djvulibre aleastopython-gbinder alexl setools ankursinha MUSIC python-fastavro python-indexed_gzip python-pyspike athoscrpython-pyclipper caolanmsetools carlwgeorge python-peewee cstratak numpy python-lxml python-peewee scipy davidsch python-pysam decathorpe rust-cbindgen dfateyev python-llfuse dledford rdma-core dwalsh setools fabpyliblo python-rtmidi fale python-lxml fed500 mlpack fuller cantera grover python-kmod honli rdma-core iztokf python-pyedflib jeckersb PyYAML jjames python-pari-jupyter python-pplpy jkastner libfreenect jonathanspw python-tables jonny python-hidapi jskarvad pygame urh jwilsonrdma-core kalev python-smartcols kathenas libfreenect kheib rdma-core kkeithle libarrow kwizartlibfreenect lbalharpython-lxml limb mpi4py numpy pygame python-editdistance-s lupinixpython-healpy maci python-llfuse mattia python-calcephpy mbarnessetools mhaydenpython-uamqp michichrdma-core mizdebsk python-lxml mlombard python-kmod mmuzilascipy music python-compreffor python-cyipopt python-ezdxf nforro scipy orion h5py numpy python-cftime python-cytoolz python-imagecodecs scipy orphan libgpuarray pcmooresetools pcpa python-cysignals plautrba setools psimovec scipy raphgropython-jnius rcurtinmlpack rdieternumpy rhughessetools rmatteslibfreenect rstrodesetools sagitter petsc python-giacpy sergiomb pygame sergiopr python-statsmodels siccantera simo python-gssapi slaanesh vapoursynth stevetraylen h5py python-oracledb terjeros h5py thrnciar python-rapidfuzz tomspurmpi4py numpy scipy troycurtisjr python-rapidfuzz ttomecek numpy scipy vkrizanpython-peewee vmojzissetools vtrefnypython-orderedset zbys
Cython 3 plans
Hello Pythonistas, apparently, Cython 3.0.0 final was released today. I plan to make it build somehow in https://src.fedoraproject.org/rpms/Cython/pull-request/41 and once it does, I'll update the package in Rawhide, introducing a python(3)-cython0.29 conflicting compact package for those who cannot upgrade yet (like python-lxml). Note that Cython 0.29 was only built without tests during the Python 3.12 bootstrap and I am unsure we will ever be able to enable them again (at least not all of them). We'll get rid of emacs-cython-mode during the transition -- it can be packaged separately by someone else if desired. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Py3.12: vit -> urwid -> undefined symbol: PyUnicode_AS_UNICODE
On 06. 07. 23 11:21, Ankur Sinha wrote:
Hi folks,
While looking into the vit FTI bug[1], I ran into this error in the
test:
==
ERROR: vit (unittest.loader._FailedTest.vit)
--
ImportError: Failed to import test module: vit
Traceback (most recent call last):
File "/usr/lib64/python3.12/unittest/loader.py", line 415, in _find_test_path
package = self._get_module_from_name(name)
File "/usr/lib64/python3.12/unittest/loader.py", line 325, in
_get_module_from_name
__import__(name)
File "/builddir/build/BUILD/vit-2.3.0/vit/__init__.py", line 2, in
from .application import Application
File "/builddir/build/BUILD/vit-2.3.0/vit/application.py", line 19, in
from vit.formatter_base import FormatterBase
File "/builddir/build/BUILD/vit-2.3.0/vit/formatter_base.py", line 8, in
from vit import util
File "/builddir/build/BUILD/vit-2.3.0/vit/util.py", line 7, in
from urwid.str_util import calc_width
ImportError:
/usr/lib64/python3.12/site-packages/urwid/str_util.cpython-312-x86_64-linux-gnu.so:
undefined symbol: PyUnicode_AS_UNICODE
A web search brought me here:
https://github.com/cython/cython/issues/5149
How would we fix this? Is this something that needs fixing in urwid?
I still see PyUnicode_AS_UNICODE used there:
https://github.com/search?q=repo%3Aurwid%2Furwid%20PyUnicode_AS_UNICODE=code
(and no issues filed about it yet).
This is https://peps.python.org/pep-0623/#python-3-12
I don't know what is the proper replacement. Either way, this needs to be fixed
in python-urwid. It has tests ignored out, so the problem was masked away. It
could at least use an import check.
It has this in the build.log:
gcc ... -fPIC -I/usr/include/python3.12 -c source/str_util.c -o
build/temp.linux-x86_64-cpython-312/source/str_util.o
source/str_util.c: In function ‘Py_IsWideChar’:
source/str_util.c:484:16: warning: implicit declaration of function
‘PyUnicode_AS_UNICODE’; did you mean ‘PyUnicode_AsUCS4’?
[-Wimplicit-function-declaration]
484 | ustr = PyUnicode_AS_UNICODE(text);
|^~~~
|PyUnicode_AsUCS4
source/str_util.c:484:14: warning: assignment to ‘Py_UNICODE *’ {aka ‘int *’}
from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
484 | ustr = PyUnicode_AS_UNICODE(text);
| ^
source/str_util.c: In function ‘Py_CalcWidth’:
source/str_util.c:663:14: warning: assignment to ‘Py_UNICODE *’ {aka ‘int *’}
from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
663 | ustr = PyUnicode_AS_UNICODE(text);
| ^
source/str_util.c: In function ‘Py_CalcTextPos’:
source/str_util.c:749:14: warning: assignment to ‘Py_UNICODE *’ {aka ‘int *’}
from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
749 | ustr = PyUnicode_AS_UNICODE(text);
| ^
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)
On 05. 07. 23 7:54, Miro Hrončok wrote: On 04. 07. 23 16:51, Tomáš Hrnčiar wrote: Hello. As you might already know, we have recently conducted a Python 3.12mass rebuild in aside tag. We plan to ask releng to merge it today, despite several builds not succeeding. This has not happened yet, see https://pagure.io/releng/issue/11451 for progress update. The side tag has been merged. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)
On 04. 07. 23 16:51, Tomáš Hrnčiar wrote: Hello. As you might already know, we have recently conducted a Python 3.12mass rebuild in aside tag. We plan to ask releng to merge it today, despite several builds not succeeding. This has not happened yet, see https://pagure.io/releng/issue/11451 for progress update. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)
On 04. 07. 23 20:11, Steven A. Falco wrote: On 7/4/23 10:51 AM, Tomáš Hrnčiar wrote: ## 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 ... That doesn't appear correct. At least I still get 3.11 when I try. I assume I need to refer to the side tag instead. This will only work once the side tag is actually merged. I have requested the merge from releng but I cannot do it myself. Also there is a typo - there needs to be a space between fedora-rawhide-x86_64 and --scrub=all :-) Indeed. Thanks for spotting this and sorry about that. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 27. 06. 23 21:37, Maxwell G wrote: If your package is failing with ModuleNotFoundError: No module named 'imp', this is happening because Python 3.12 removed the long deprecated imp module. As a stopgap measure, you can BuildRequire python3-zombie-imp package, which allows you to import the imp module even on Python 3.12. We strongly recommend talking to upstream and encouraging them to migrate to importlib instead. The package has `Provides: deprecated()` so that cannot be done without violating policy. The idea is that packages that already use (deprecated) imp can migrate to this as a stop gap measure. But no new packages should depend on this. We could *not deprecate* it instead and submit a change proposal to deprecate it later, but that seems rather useless. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 18. 06. 23 15:17, Barry Scott wrote: On 17 Jun 2023, at 10:50, Miro Hrončok wrote: Please avoid further rawhide builds of them until the side tag is merged. I have been fixing pycxx and pysvn for python 3.12. I have released new pycxx and pysvn upstream that fix the 3.12 issues. But I did not see your message about not building in rawhide, sorry. python-pycxx was buildt in rawhide. I have not built pysvn in rawhide. For both packages I have pushed updates to sources and spec file that are needed for 3.12 support. For pycxx need to have conditional access to _Py_PackageContext and replace use of distutils. For pysvn fix a SEGV when the process exits. I'v attempted to rebuild python-pycxx: Traceback (most recent call last): File "/builddir/build/BUILD/pycxx-7.1.8/setup.py", line 3, in from distutils.command.install import install ModuleNotFoundError: No module named 'distutils' The distutils module eas removed from the Python standard library. You should be able to fix this by BuildRequiring python3-setuptools. Cannot build pysvn yet, as it is blocked by the above. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 13. 06. 23 14:02, Tomas Hrnciar wrote: Hello, in order to deliver Python 3.12, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.12 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f39-python $ koji wait-repo f39-python --build Note that it will take a while before all the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Please, don't attempt to build your package in the side tag before we do. When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us. Builds: https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0 <https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0> Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks. Let us know if you have any questions. Hey folks, apologies if you have missed our announcement, but I'd like to ask you not to build packages in rawhide if they have received a "Rebuilt for Python 3.12" commit. For details, see the announcement quoted above. The following packages have been rebuilt in rawhide after we have rebuilt them in the f39-python side tag and so I bumped them again and built them again in f39-python: legendary python-boto3 tracer Please avoid further rawhide builds of them until the side tag is merged. Thanks and sorry for the trouble. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 13. 06. 23 14:02, Tomas Hrnciar wrote: Hello, in order to deliver Python 3.12, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.12 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f39-python $ koji wait-repo f39-python --build Note that it will take a while before all the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Please, don't attempt to build your package in the side tag before we do. When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us. Builds: https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0 <https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0> Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks. Let us know if you have any questions. Hey folks, apologies if you have missed our announcement, but I'd like to ask you not to build packages in rawhide if they have received a "Rebuilt for Python 3.12" commit. For details, see the announcement quoted above. The following packages have been rebuilt in rawhide after we have rebuilt them in the f39-python side tag and I will now bump them again and build them again in f39-python: python-google-api-core python-radexreader Please avoid further rawhide builds of them until the side tag is merged. Thanks and sorry for the trouble. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 16. 06. 23 12:07, Nikita Popov wrote: We have a conflicting python-lit build sitting in another side tag -- we'll discard that one and rebuild once your side tag is merged. If it's already built and ready to be shipped, do it. Our side tag will last for ~1 week at least. Happy to bump python-lit once again to make your side tag work unblocked. Just let us know. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 16. 06. 23 9:57, Bastien Nocera wrote: On Fri, 16 Jun 2023 at 09:48, Miro Hrončok <mailto:mhron...@redhat.com>> wrote: On 16. 06. 23 9:41, Bastien Nocera wrote: > Scolding people that haven't seen your original message for limitations in the > build system isn't nice. Apologies for not being nice enough. However, we need to notify the folks who do that and ask them to stop, because as you say, the system is not perfect. If you have specific suggestions, please speak up. Yes, tell folks that they might have missed an email instead of sending a scolding " Please, don't do that." Thanks for the suggestion. I honestly had no idea that "please, don't do that" could be considered unfriendly, but I hope that's language/cultural barrier (rather than me being a sociopath). I've adjusted my wording in the followup emails. > I fixed my missing the devel-announce email by subscribing to the list (though > this should probably be implemented somewhere in the accounts system) but I'm > afraid I cannot do anything about the build system not allowing for specific > blocking of builds in circumstances such as yours. I kindly ask you not to submit rawhide builds of packages that have been already built in our side tag, until the side tag is merged. If you cannot do that, I kindly ask you not to build any packages until the side tag is merged. Unfortunately, asking people is the only thing I am able to do. I'm talking about limitations in the build system that don't allow you to automatically do what you're trying to get *people* to do instead. People are fallible, and filing an RFE for the build system would go some way to shifting the burden to a computer. This has actually been discussed on this list several times already, but Fabio was kind enough to file that RFE today: https://pagure.io/koji/issue/3847 That said, most of Fedora's RFEs to Koji that would make things easier for packagers seem to linger, presumably due to capacity reasons. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 16. 06. 23 9:41, Miro Hrončok wrote: The following packages were built in rawhide after they were built in out Python 3.12 side tag (f39-python): ... python-cerberus I believe this also wasn't built after 3.12 rebuild, but the rawhide version is 0-1.3.4-1.fc38, which is > 0-1.3.2-3.fc39. The dist-git history goes: 1.3.1 -> 1.3.2 -> 1.3.4 -> 1.3.3 -> 1.3.2 https://src.fedoraproject.org/rpms/python-cerberus/commits/rawhide Not sure how to fix this properly without stepping on the maintainers' toes. I've opened https://src.fedoraproject.org/rpms/python-cerberus/pull-request/2 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 13. 06. 23 14:02, Tomas Hrnciar wrote: Hello, in order to deliver Python 3.12, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.12 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f39-python $ koji wait-repo f39-python --build Note that it will take a while before all the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Please, don't attempt to build your package in the side tag before we do. When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us. Builds: https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0 <https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0> Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks. Let us know if you have any questions. Hey folks, apologies if you have missed our announcement, but I'd like to ask you not to build packages in rawhide if they have received a "Rebuilt for Python 3.12" commit. For details, see the announcement quoted above. The following packages have been rebuilt in rawhide after we have rebuilt them in the f39-python side tag and I will now bump them again and build them again in f39-python: clang lldb Please avoid further rawhide builds of them until the side tag is merged. Thanks and sorry for the trouble. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 16. 06. 23 9:41, Bastien Nocera wrote: Scolding people that haven't seen your original message for limitations in the build system isn't nice. Apologies for not being nice enough. However, we need to notify the folks who do that and ask them to stop, because as you say, the system is not perfect. If you have specific suggestions, please speak up. I fixed my missing the devel-announce email by subscribing to the list (though this should probably be implemented somewhere in the accounts system) but I'm afraid I cannot do anything about the build system not allowing for specific blocking of builds in circumstances such as yours. I kindly ask you not to submit rawhide builds of packages that have been already built in our side tag, until the side tag is merged. If you cannot do that, I kindly ask you not to build any packages until the side tag is merged. Unfortunately, asking people is the only thing I am able to do. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 16. 06. 23 8:49, Miro Hrončok wrote: On 13. 06. 23 14:02, Tomas Hrnciar wrote: Hello, in order to deliver Python 3.12, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.12 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f39-python $ koji wait-repo f39-python --build Note that it will take a while before all the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Please, don't attempt to build your package in the side tag before we do. When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us. Builds: https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0 <https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0> Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks. Let us know if you have any questions. The following packages were built in rawhide after they were built in out Python 3.12 side tag (f39-python): ... python-cerberus I believe this also wasn't built after 3.12 rebuild, but the rawhide version is 0-1.3.4-1.fc38, which is > 0-1.3.2-3.fc39. The dist-git history goes: 1.3.1 -> 1.3.2 -> 1.3.4 -> 1.3.3 -> 1.3.2 https://src.fedoraproject.org/rpms/python-cerberus/commits/rawhide Not sure how to fix this properly without stepping on the maintainers' toes. Please, don't do that. I will now rebuild them in the side tag again. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 16. 06. 23 8:49, Miro Hrončok wrote: On 13. 06. 23 14:02, Tomas Hrnciar wrote: Hello, in order to deliver Python 3.12, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.12 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f39-python $ koji wait-repo f39-python --build Note that it will take a while before all the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Please, don't attempt to build your package in the side tag before we do. When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us. Builds: https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0 <https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0> Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks. Let us know if you have any questions. The following packages were built in rawhide after they were built in out Python 3.12 side tag (f39-python): ... python-hpack This one wasn't actually rebuilt after that, but for some reason, f39-build has higher version from an older build: python-hpack 0-4.0.0-7.fc37 > 0-4.0.0-4.fc39 The package was converted to rpmautospec and back and does not sort correctly. I'll bump the release to 8. Please, don't do that. I will now rebuild them in the side tag again. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 13. 06. 23 14:02, Tomas Hrnciar wrote: Hello, in order to deliver Python 3.12, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.12 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f39-python $ koji wait-repo f39-python --build Note that it will take a while before all the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Please, don't attempt to build your package in the side tag before we do. When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us. Builds: https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0 <https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0> Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks. Let us know if you have any questions. The following packages were built in rawhide after they were built in out Python 3.12 side tag (f39-python): codespell devscripts iscsi-initiator-utils libxc miniupnpc petsc python-apypie python-bitarray python-boto3 python-cerberus python-cloudflare python-hpack python-pyudev Please, don't do that. I will now rebuild them in the side tag again. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 13. 06. 23 14:02, Tomas Hrnciar wrote: Hello, in order to deliver Python 3.12, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.12 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f39-python $ koji wait-repo f39-python --build Note that it will take a while before all the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Please, don't attempt to build your package in the side tag before we do. When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us. Builds: https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0 <https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0> Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks. Let us know if you have any questions. FTR it has started. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: nest: python package still setup.py; also needs to be built for MPI
On 12. 06. 23 16:04, Ankur Sinha wrote: However, I can't figure out how I would replicate the build using the `pyproject` macros. I guess `pyproject_wheel` usage is straightforward (?), but how do I get `pyproject_install` to install in the $MPI_SITEARCH locations, and then how do I get `pyproject_save_files` to store the files in three different lists that I can use in the different `%files` sections? This is currently not possible. Unfortunately, support for this would require somebody else than me to drive it. (If you just need to install the same files in multiple locations, you can cp -a them around after %pyproject_install.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Question regarding setuptools automatic discovery (pyproject.toml)
On 04. 06. 23 1:54, Sandro wrote: Hi, Hey. I ran into a build failure for a Python package that dropped setup.py in the latest update and uses pyproject.toml for metadata and setuptools. The build failed due to 'error: Installed (but unpackaged) file(s) found' [1]. However, all the erroneously installed modules should be excluded by default, if I understand the setuptools automatic discovery documentation [2] correctly. They are listed in 'FlatLayoutPackageFinder.DEFAULT_EXCLUDE'. In this case 'docs', 'scripts' and 'test'. Since this is still beta when using pyproject.toml, I was wondering if someone else has come across this misbehavior. Or, maybe, it's something I failed to spot in pyproject.toml, that's causing it. I can make it work by adding a 'include = ["palettable"]' in the tool.setuptools.packages.find table [3]. But I'd like a second opinion before submitting a PR upstream. First of all, upstream wheel downloaded from https://pypi.org/project/palettable/3.3.3/#files includes build, docs and test as well. I think the elicit exclude configured at https://github.com/jiffyclub/palettable/blob/v3.3.3/pyproject.toml#L35 migth override the DEFAULT_EXCLUDE value. I don't know how tool.setuptools.packages.find.exclude behaves, but I have seen this behavior with pytest, where the default was to exclude a bunch of directories including ".*", but projects that set their own excludes (without ".*") suddenly started to collect tests from our .pyproject-* folders. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: python macros inconsistency between Fedora and EPEL9
On 03. 06. 23 13:29, Mattia Verga wrote: In the test section of libindi package I use this to run tests: %ctest --test-dir %_vpath_builddir/test This translates in Fedora as: + /usr/bin/ctest --test-dir redhat-linux-build --output-on-failure --force-new-ctest-process -j6 --test-dir redhat-linux-build/test Internal ctest changing into directory: /builddir/build/BUILD/indi-2.0.2/redhat-linux-build/test While on EPEL (at least, in COPR): + /usr/bin/ctest --output-on-failure --force-new-ctest-process -j2 --test-dir redhat-linux-build/test Internal ctest changing into directory: /builddir/build/BUILD/indi-2.0.2/redhat-linux-build/redhat-linux-build/test Failed to change working directory to "/builddir/build/BUILD/indi-2.0.2/redhat-linux-build/redhat-linux-build/test" : No such file or directory I'm not sure against what package I should report this. Python-rpm-macros seems a Fedora package only, I don't see any epel9 build there. It's not in epel because it is in RHEL. And, most important, I don't know if I'm doing something wrong or if is indeed something to report. Can anyone clarify me these two things? I have no idea. What makes you suspect this problem is related to *Python* macros at all? %ctest is defined in /usr/lib/rpm/macros.d/macros.cmake which is shipped by cmake-rpm-macros, a subpackage of cmake. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
pyproject-rpm-macros 1.9.0: Support for passing config_settings to the build backend
Hello Pythonistas,
Let me announce the release of pyproject-rpm-macros 1.9.0.
The new version is available in Rawhide+ELN Koji and updates are penfing for
older Fedora releases. A sync to c9s is in progress but will require a review,
so it might take longer.
The new version has the following changes compared to 1.8.0:
Allow passing config_settings to the build backend
==
Contributed by Maxwell G (@gotmax23), thank you!
From the README:
---
The %pyproject_buildrequires and %pyproject_wheel macros accept a -C flag to
pass configuration settings [1] to the build backend. Options take the form of
-C KEY, -C KEY=VALUE, or -C--option-with-dashes. Pass -C multiple times to
specify multiple options. This option is equivalent to pip's --config-settings
flag. These are passed on to PEP 517 hooks' config_settings argument as a
Python dictionary.
The %pyproject_buildrequires macro passes these options to the
get_requires_for_build_wheel and prepare_metadata_for_build_wheel hooks.
Passing -C to %pyproject_buildrequires is incompatible with -N which does not
call these hooks at all.
The %pyproject_wheel macro passes these options to the build_wheel hook.
Consult the project's upstream documentation and/or the corresponding build
backend's documentation for more information. Note that some projects don't use
config settings at all and other projects may only accept config settings for
one of the two steps.
Note that the current implementation of the macros uses pip to build wheels. On
some systems (notably on RHEL 9 with Python 3.9), pip is too old to understand
--config-settings. Using the -C option for %pyproject_wheel (or
%pyproject_buildrequires -w) is not supported there and will result to an error
like:
Usage:
/usr/bin/python3 -m pip wheel [options] ...
...
no such option: --config-settings
[1] https://peps.python.org/pep-0517/#config-settings
---
Previously, packagers needed to patch for this:
https://src.fedoraproject.org/rpms/python-scikit-misc/c/3dda47b4b7
On Python older than 3.11, use tomli instead of deprecated toml
===
All currently supported Fedora releases have Python 3.11, so this has not a big
effect except for EL 9. However, all packages had generated this BuildRequires:
(python3dist(toml) if python3-devel < 3.11)
This will now be:
(python3dist(tomli) if python3-devel < 3.11)
Such build requirements in Fedora manifests themselves in the results of dnf
repoquery --wahtrequires python3-toml(i).
Fix literal % handling in %{pyproject_files} on RPM 4.19
If your package has files with literal % signs in the filenames, it was briefly
broken on Fedora Rawhide, because RPM 4.19 now requires 2 % signs to escape
them in the filelist (it was 8 in RPM 4.16 and 4.17). This has now been fixed.
Unfortunately, to support both RPM 4.19 and older ones, there is a conditional
in %pyproject_save_files which checks the Fedora version. If you run old RPM on
Fedora 39 or new RPM on older Fedoras and ahve literal % signs in filenames, it
will break. I have requested an %rpmversion macro from RPM and it was added
upstream. Once propagated to Fedora, the conditional will be replaced.
Happy packaging!
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: Guidance for a python package update
On 30. 05. 23 15:13, Troy Curtis Jr wrote: Please, attempt to change the dependents. Since the requires generally come from the package metadata itself, does this mean changing upstream for each dependency? Or just patch for our Fedora packages? Presumably they could be patched and then built together with the updated name, I presume this is where side tags come in to play? (It'll be a new experience for me!) I'd send a PR upstream and use that as a patch for Fedora. Using side tags to ship this is a good idea, yes. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Guidance for a python package update
Hi Troy.
On 29. 05. 23 18:01, Troy Curtis Jr wrote:
I'm currently working on the update for python-Levenshtein [1] and I have a
question about the best way to proceed.
In the intervening time since the last release we have packaged, a new
maintainer has taken over maintenance, and built the updates around a stack of
other packages (rapidfuzz-cpp, python-rapidfuzz, scikit-build, etc). Now that
all these dependencies are available I can look to actually do the update. As
part of the updates, the current maintainer has deprecated the original pypi
name of "python-Levenshtein" in favor of the more typical name without the
"python-" prefix. He is continuing to maintain the "python-Levenshtein" pypi
package for compatibility, but now it is just an empty package which defines
"Levenshtein" as a dependency [2]. This means the upstream for the Fedora
python-Levenshtein package must point to the new Levenshtein package in order
to get the actual package contents. However, this means the metadata for the
package indicates the name "Levenshtein" which translate to a provide for
"python3.11dist(levenshtein)", but that is different than the currently
provided "python3.11dist(python-levenshtein)", which current dependencies
require. One option would be to simply manually add a
"python3.11dist(python-levenshtein)" provide, but it seems this seems
specifically prohibited in the Python packaging guidelines [3].
And there is a reason. If the package "claimed" to be
python3dist(python-levenshtein), yet the Python metadata would say it's
levenshtein, all automation that generates requirements for
python3dist(python-levenshtein) would happily accept it, but fail on Python
level. For example, the %pyproject_buildrequires macro, when it encounters an
unmet dependency on levenshtein on the Python level, prints out
python3dist(levenshtein) and restarts for dnf to take over. dnf then installs
the package but the macro still does not see the package on Python level, so it
prints it out again and restarts...
I think there are 2 options:
- Manually provide the legacy name outside of the python package meta-data
Please don't.
- Rebuild all users of the provide to use the new name
It's not that many:
$ repoquery -q --repo=rawhide{,-source} --whatrequires
'python3.11dist(python-levenshtein)' --whatrequires
'python3dist(python-levenshtein)'
paperwork-0:2.1.2-2.fc38.src
python-paperwork-backend-0:2.1.2-2.fc38.src
python3-paperwork-0:2.1.2-2.fc38.noarch
python3-paperwork-backend-0:2.1.2-2.fc38.noarch
The main downside to the second approach is that nothing would provide the
python-Levenshtein name, which is still present and usable via pypi and
perfectly compatible with the current library implementation.
But do we need it in Fedora?
If you really need this, you could insert a second dist-info metadata to the
package, so it would ship:
%{python_sitearch}/...actual content here...
%{python_sitearch}/Levenshtein-0.21.0.dist-info/
%{python_sitelib}/python_Levenshtein-0.21.0.dist-info/
That way, it provides both names on Python and RPM level both.
But I consider that an overkill.
So what is the appropriate course of action here?
Please, attempt to change the dependents.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: [EPEL-devel] Re: python3.11-rpm to EPEL 9
On 16. 05. 23 15:44, Maxwell G wrote:
On Tue May 16, 2023 at 11:04 +0200, Miro Hrončok wrote:
On 15. 05. 23 16:49, Maxwell G wrote:
On Mon May 15, 2023 at 12:14 +0200, Miro Hrončok wrote:
Hello,
I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next.
See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4.
Cool!
I decided to reuse the python3-rpm component (currently epel7 only). Let me
know if I should not.
Are we able to build for multiple Python versions out of the same
specfile?
It's possible, but it's not nice.
In principle, this works:
%build
%define py3x_build() %{global python3_pkgversion %1}%py3_build
%py3x_build 39
%py3x_build 3.11
%install
%define py3x_install() %{global python3_pkgversion %1}%py3_install
%py3x_install 39
%py3x_install 3.11
But with a project like RPM, we might need to run configure multiple times as
well and create separate working directories. Will need to check.
Yeah, that could work,
but I'd change %{global python3_pkgversion %1} to
%{define python3_pkgversion %1} in the py3x_* macro definitions so you
only change the definition of %python3_pkgversion within those macros'
scopes.
Unless there's some other way to work around this, I'd use a
python3.11-rpm or python3.11-rpm-epel component like we've been doing
for the other alt python stacks in RHEL 8.
I consider the "not nice" way easier, as it will only require to keep one
package synced with c8s rpm, and not many. Will try to hack it up and show how
it looks like.
I tend to agree. Syncing packages with RHEL and CentOS Stream is
difficult and tedious so better to limit the amount of times you have to
do it. Carl's new EPEL 10 proposal will hopefully with this.
OK, here's an EPEL 8 demo with multiple Python versions:
https://src.fedoraproject.org/rpms/python3-rpm/pull-request/5
(I am not sure if Python 3.11 is available in the EPEL 8 buildroot already, but
if it is not, we can probably just wait a bit instead of building this in EPEL
8 Next first.)
Unfortunately the trick with %{global python3_pkgversion %1} inside a %define
seemed to work on Fedora 37, but RHEL 8 did not like it (especially with
multiline macros) an I was unable to make it work. Instead, I kept %global'ing
%python3_pkgversion back and forth.
It is not as bad as expected actually, this version of RPM still supports
building and installing the Python bindings via distutils, so I only needed to
run configure once.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
pyproject-rpm-macros 1.8.0: self-referential extras, %{pyproject_build_lib} deprecated
Hello Pythonistas,
I've built pyproject-rpm-macros-1.8.0-1.fc39 in Rawhide and updates are
available for older Fedoras. Later on I plan to sync this to c9s as well.
https://bodhi.fedoraproject.org/updates/pyproject-rpm-macros
The release brings a bugfix/enhancement (depending on how you look at it) and a
deprecation.
## %pyproject_buildrequires now supports self-referential extras requirements
That is, if you package e.g. attrs and use:
%pyproject_buildrequires -x tests
It correctly handles the requirement on attrs[tests-no-zope] as defined here:
https://github.com/python-attrs/attrs/blob/23.1.0/pyproject.toml#L45
When a self-referential dependency on extras is found, the required extra is
added to the list of desired extras, and all the previously discarded "alien"
requirements are reevaluated using the new extras list.
Example use: https://src.fedoraproject.org/rpms/python-fiona/pull-request/2
## The provisional %{pyproject_build_lib} macro was deprecated
There is no scheduled removal, but it may break entirely in the future.
See
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/HMLOPAU3RZLXD4BOJHTIPKI3I4U6U7OE/
for motivation.
Packagers are encouraged to use
$PWD/build/lib.%{python3_platform}-cpython-%{python3_version_nodots} instead if
they need to (works on all current Fedoras but not on RHEL 9's Python 3.9).
The following Fedora Rawhide packages use it:
asv
buku
ocrmypdf
pytest
python-Automat
python-constantly
python-cppy
python-cypari2
python-cysignals
python-elasticsearch
python-graphviz
python-hyperframe
python-hyperlink
python-h2
python-libdiscid
python-mistune
python-mplcursors
python-nb2plots
python-networkx
python-nipy
python-numcodecs
python-opentracing
python-pbr
python-persistent
python-pikepdf
python-pplpy
python-primecountpy
python-priority
python-pybtex
python-pyedflib
python-pytest-regressions
python-service-identity
python-simplejson
python-stestr
python-transforms3d
python-twisted
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: [EPEL-devel] python3.11-rpm to EPEL 9
On 15. 05. 23 16:49, Maxwell G wrote:
On Mon May 15, 2023 at 12:14 +0200, Miro Hrončok wrote:
Hello,
I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next.
See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4.
Cool!
I decided to reuse the python3-rpm component (currently epel7 only). Let me
know if I should not.
Are we able to build for multiple Python versions out of the same
specfile?
It's possible, but it's not nice.
In principle, this works:
%build
%define py3x_build() %{global python3_pkgversion %1}%py3_build
%py3x_build 39
%py3x_build 3.11
%install
%define py3x_install() %{global python3_pkgversion %1}%py3_install
%py3x_install 39
%py3x_install 3.11
But with a project like RPM, we might need to run configure multiple times as
well and create separate working directories. Will need to check.
That PR has:
```
+ # We'll build python3.11-rpm only for now
+ # Once a new Python version is added,
+ # the spec will need to change to support multiple Pythons anyway
+ %global python3_pkgversion 3.11
```
but I thought we got rid of the %py3_other_* stuff that allowed building
for multiple Python versions out of the same specfile.
We did.
Unless there's some other way to work around this, I'd use a
python3.11-rpm or python3.11-rpm-epel component like we've been doing
for the other alt python stacks in RHEL 8.
I consider the "not nice" way easier, as it will only require to keep one
package synced with c8s rpm, and not many. Will try to hack it up and show how
it looks like.
If there is a significant demand, I can try add this (and python39-rpm) to EPEL
8 as well.
As I said on IRC, I'd like that for fedrq.
Ack.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
python3.11-rpm to EPEL 9
Hello, I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next. See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4. I decided to reuse the python3-rpm component (currently epel7 only). Let me know if I should not. If there is a significant demand, I can try add this (and python39-rpm) to EPEL 8 as well. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
How to drop 32bit support from the scientific Python stack
Hello folks, Couple months ago, we discussed with @psimovec if it's possible to ExcludeArch i686 from scipy. This Python discussion brought the topic back: https://discuss.python.org/t/dropping-32-bit-packages/5476/9 I've tried to see how many packages would be affected and the short answer is: all of them, unless we break the dependency chains somewhere. There are many deep transitive build dependency chains on scipy, but the perhaps most interesting one is: (everything) <- rpm <- rust-rpm-sequoia <- rust-packaging <- pytest <- python-hypothesis <- python-pandas <- scipy Another interesting fact is that the majority of the dependency chains I found traverses through a path of noarch Python packages (such as pytest). If scipy drops i686 we would need to conditionalize the test-related BuildRequires of such noarch packages -- unfortunately that would mean that based on randomness (noarch packages are built on random archotcture), not all tests would always run and we could potentially ship packages that are broken / untested properly. And if we don't conditionalize the dependencies, the packages would randomly fail to build. An alternative is to make all the related packages archful with noarch python3-xxx subpackages -- which would be quite tedious and wasteful resource-wise. The best way forward for this use case (and many others that will show up sooner or later) would be to stop building noarch packages on i686. That way, only archful packages that (Build)Require scipy would need to be changed. Would that be possible? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Numpy version pinned despite numpy>=1.22.3
On 30. 04. 23 17:00, Ben Beasley wrote: sed -r -i 's/(numpy)==/\1>=/' pyproject.toml Just in case you don't already know this. If the listed dependency is numpy==1.23.2, the sed above works fine. But if the the dependency was numpy==1.23.*, the sed would generate an invalid requirement (* cannot be used with >=). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Let's deprecate the %{pyproject_build_lib} macro... ?
On 08. 03. 23 12:09, Miro Hrončok wrote:
Hello.
The %{pyproject_build_lib} macro is a *provisional* macro from
pyproject-rpm-macros.
It was added to solve the problem of out-of-tree pip builds. From the
pyproject-rpm-macros README:
"""
Sometimes, it is desired to be able to import the just-built extension modules
in the %build section, e.g. to build the documentation with Sphinx.
%build
%pyproject_wheel
... build the docs here ...
With pure Python packages, it might be possible to set PYTHONPATH=${PWD} or
PYTHONPATH=${PWD}/src. However, it is a bit more complicated with extension
modules.
The location of just-built modules might differ depending on Python version,
architecture, pip version, etc. Hence, the macro %{pyproject_build_lib} exists
to be used like this:
%build
%pyproject_wheel
PYTHONPATH=%{pyproject_build_lib} ... build the docs here ...
"""
When this macro was introduced, the built extension module lived in a folder
like
/builddir/build/BUILD/%{name}-%{version}/.pyproject-builddir/pip-req-build-/build/lib.linux-x86_64-3.10, hence it made sense to include in the pyproject-rpm-macros and call it %pyproject_something.
Today, on Rawhide, pip default to in-tree-builds and the value for extension
modules will most likely be:
$PWD/build/lib.%{python3_platform}-cpython-%{python3_version_nodots}
And for pure Python:
$PWD/build/lib
And it turns out, the value is setuptools-specific, see
https://bugzilla.redhat.com/show_bug.cgi?id=2176393
Other build backends might store the built extension modules elsewhere or
simply pack the pure Python files into wheel directly from the source tree.
In Rawhide, 41 packages use PYTHONPATH="%{pyproject_build_lib}" and 2 packages
have a comment with %%{pyproject_build_lib} in them.
Considering the macro
- is not build-backend-agnostic, and
- is not so much needed as it once was
I propose we deprecate it with no further fixes going in, but no scheduled
removal.
The 41 packages can be fixed once Fedora 36 goes EOL by expanding the macro to
the values above, or if desired, we could macronize this in pythohn3-setuptools
as %{setuptools_build_lib}.
One problem is that the macro is unfortunately still needed on EL 9.
Thoughts?
WIP pull request:
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/375
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: RPM 4.19: Dynamic subpackages with Python extras
On 30. 03. 23 23:55, Miro Hrončok wrote:
Hello Python packagers.
RPM 4.19 introduces this feature:
https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html
I decided to write this email to gather my thoughts. I believe that with this,
we can turn manual Python extras subpackages like this:
%package -n python3-...
Summary: %{summary}
%description -n python3-... %_description
%pyproject_extras_subpkg -n python3-xxx extra1 extra2
(See https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Extras
for what that means.)
Into something like this:
%package -n python3-...
Summary: %{summary}
%description -n python3-... %_description
...
%install
%pyproject_install
...
%pyproject_generate_extras_subpkgs -n python3-xxx
The %pyproject_generate_extras_subpkgs macro would parse the installed
.dist-info directory to find out what extras are available and generate
subpackages for all of them.
One challenge: When an extra is removed upstream, the packager might not notice
that it needs to be provided/obsoleted/etc.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
RPM 4.19: Dynamic subpackages with Python extras
Hello Python packagers.
RPM 4.19 introduces this feature:
https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html
I decided to write this email to gather my thoughts. I believe that with this,
we can turn manual Python extras subpackages like this:
%package -n python3-...
Summary:%{summary}
%description -n python3-... %_description
%pyproject_extras_subpkg -n python3-xxx extra1 extra2
(See https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Extras
for what that means.)
Into something like this:
%package -n python3-...
Summary:%{summary}
%description -n python3-... %_description
...
%install
%pyproject_install
...
%pyproject_generate_extras_subpkgs -n python3-xxx
The %pyproject_generate_extras_subpkgs macro would parse the installed
.dist-info directory to find out what extras are available and generate
subpackages for all of them.
(Obviously, the macro name is open up for discussion.)
An API would be required to exclude extras:
- that are not useful for other packages
(for example build/development requirements, commonly named dev, doc or test)
- that have requirements that are not packaged in Fedora
For example (mimicking the API of %pyproject_check_import):
%pyproject_generate_extras_subpkgs -n python3-xxx -e test -e 'nonfree*'
However, extras are also currently manually passed to %pyproject_buildrequires:
%generate_buildrequires
%pyproject_buildrequires -x extra1 -x extra2 -x test
It should already be possible to implement automatic extras discovery in
%pyproject_buildrequires with older RPM versions and allow it to be used this way:
%generate_buildrequires
%pyproject_buildrequires -X 'nonfree*'
RPM macros can only accept short flags, so can
either be -x '*' (if we start treating -x values as globs, which is backwards
compatible and probably generally useful), or a single-letter switch such as -a
(but honestly we are running out of meaningful letters).
(When -X is used, can probably be implied. However,
an explicit form needs to exist for packages that don't need to exclude any
extras at all.)
Eventually, I'd like to make the default, once RPM
4.19 is omnipresent.
Combined, this would mean that the packager needs to:
1. specify extras that are not supposed to be used as BRs
2. specify extras that are not supposed to be packaged
In the ideal word (2) is a superset of (1).
Should %pyproject_generate_extras_subpkgs somehow inherit the -Xes from
%pyproject_buildrequires?
When a package has extra1, extra2, nonfree1, nonfree2 and test extras, one
could do:
%generate_buildrequires
%pyproject_buildrequires -X 'nonfree*'
...
%pyproject_install
...
%pyproject_generate_extras_subpkgs -X test
That would mean:
- extra1 is BRed and packaged
- extra2 is BRed and packaged
- test is BRed but not packaged
- nonfree1 is neither
- nonfree2 is neither
Alternatively the information could be supplied by %globals:
%global _python_ignored_extras nonfree*
%global _python_unpackaged_extras test
However, I somehow dislike this approach.
I'd appreciate your thoughts on the matter.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Let's deprecate the %{pyproject_build_lib} macro... ?
Hello.
The %{pyproject_build_lib} macro is a *provisional* macro from
pyproject-rpm-macros.
It was added to solve the problem of out-of-tree pip builds. From the
pyproject-rpm-macros README:
"""
Sometimes, it is desired to be able to import the just-built extension modules
in the %build section, e.g. to build the documentation with Sphinx.
%build
%pyproject_wheel
... build the docs here ...
With pure Python packages, it might be possible to set PYTHONPATH=${PWD} or
PYTHONPATH=${PWD}/src. However, it is a bit more complicated with extension
modules.
The location of just-built modules might differ depending on Python version,
architecture, pip version, etc. Hence, the macro %{pyproject_build_lib} exists
to be used like this:
%build
%pyproject_wheel
PYTHONPATH=%{pyproject_build_lib} ... build the docs here ...
"""
When this macro was introduced, the built extension module lived in a folder
like
/builddir/build/BUILD/%{name}-%{version}/.pyproject-builddir/pip-req-build-/build/lib.linux-x86_64-3.10,
hence it made sense to include in the pyproject-rpm-macros and call it
%pyproject_something.
Today, on Rawhide, pip default to in-tree-builds and the value for extension
modules will most likely be:
$PWD/build/lib.%{python3_platform}-cpython-%{python3_version_nodots}
And for pure Python:
$PWD/build/lib
And it turns out, the value is setuptools-specific, see
https://bugzilla.redhat.com/show_bug.cgi?id=2176393
Other build backends might store the built extension modules elsewhere or
simply pack the pure Python files into wheel directly from the source tree.
In Rawhide, 41 packages use PYTHONPATH="%{pyproject_build_lib}" and 2 packages
have a comment with %%{pyproject_build_lib} in them.
Considering the macro
- is not build-backend-agnostic, and
- is not so much needed as it once was
I propose we deprecate it with no further fixes going in, but no scheduled
removal.
The 41 packages can be fixed once Fedora 36 goes EOL by expanding the macro to
the values above, or if desired, we could macronize this in pythohn3-setuptools
as %{setuptools_build_lib}.
One problem is that the macro is unfortunately still needed on EL 9.
Thoughts?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: JupyterLab finally in Fedora and the future of Jupyter Notebook
On 05. 03. 23 18:17, Lumír Balhar wrote: Should we include JupyterLab in Fedora 39 Python Classroom Lab? Adding it there soon might help us with testing but users of Classroom lab might want better stability. What do you think? Should be add it there now or wait at least for the stable release? I'd say users who want such stability don't generally use Rawhide. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: JupyterLab finally in Fedora and the future of Jupyter Notebook
On 05. 03. 23 12:32, Lumír Balhar wrote: Hi. There were some attempts to package JupyterLab (the first one in 2018) but none of them were successful. But now, after packaging 20 new Python and Rust packages, JupyterLab finally landed into rawhide. The main motivation for this effort is the ongoing plan to base the next version of Jupyter Notebook (version 7) on top of the components of JupyterLab. Take a look at JEP 79 is you want to know more about this - https://jupyter.org/enhancement-proposals/79-notebook-v7/notebook-v7.html So, how the future of Jupyter Notebook looks like in Fedora? In Fedora 37, there is still the old standalone Jupyter Notebook version 6.4 and nothing will change about it. Fedora 38 contains a slightly newer version of Jupyter Notebook (6.5 - the last release in 6). Everything looks the same as before but behind the curtains, the standard components Notebook is based on moved to a new package named nbclassic. This is gonna be important for Fedora 39. Fedora 39 now contains JupyterLab 4.0.0 alpha 34 which allows me to update Jupyter Notebook to 7.0.0 alpha 14. So, there will be three options in rawhide you can choose from when working with ipynb files: * JupyterLab - new development environment with text editor, consoles, files browser and more. * Jupyter Notebook - document-centric UI you already know but looking a little bit different because it'll based on components from Jupyter lab. * Jupyter nbclassic - The good old Jupyter Notebook as you know it for years. This package should be supported upstream for 2 years after the stable version of Notebook v7 is released. Both JupyterLab and Notebook are currently alpha but the plan of upstream developers is to release stable releases before JupyterCon in May so we should have plenty of time to update the packages in rawhide before the beta freeze in August. If you want to use the new notebook v7 before I update it in rawhide, use this COPR: https://copr.fedorainfracloud.org/coprs/lbalhar/notebook/ Any help testing the prereleases is appreciated. Thank you, Lumír, for doing this! Should we include JupyterLab in Fedora 39 Python Classroom Lab? If so, we need to add it here: https://pagure.io/fedora-comps/blob/main/f/comps-f39.xml.in Search for: python3-notebook -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Packaging python3-*-devel subpackages
Hello Pythonistats and packaging folks.
Tomáš (CCed) approached me today with an interesting question.
A Python package he is packaging into RPM (python3-rapidfuzz) installs some
development files (.h and .pxd).
Tomáš queried upstream about those files to figure out if they should be
installed or if they are only needed to build the package itself. Upstream
responded:
> rapidfuzz.h and __init__.pxd provide a capi for rapidfuzz, which allows users
> to write their own similarity metrics in C/C++/Cython, which can be called by
> rapidfuzz in a more performant way through this C-API.
> For this reason the header file should be part of the installation as well.
OK, we want to ship them. Our packaging guidelines however say:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
> Specifically, -devel packages must be used to contain files which are
> intended solely for development or needed only at build-time. This is done to
> minimize the install footprint for users. There are some types of files which
> almost always belong in a -devel package:
> - Header files...
So from our guidelines perspective, the files would go to
python3-rapidfuzz-devel. The way we packaged Python in 201x, this would be the
end of it.
However, in this decade with automatic Python BuildRequires, we could easily
end up in this situation:
1. a Python package lists rapidfuzz as a build requirement
2. %pyproject_buildrequires generates a dependency on python3dist(rapidfuzz)
3. only python3-rapidfuzz is pulled
4. %build wants to use rapidfuzz.h
5. packager needs to manually BuildRequire python3-rapidfuzz-devel
To avoid (5), my suggestion was to add the following requirement to
python3-rapidfuzz:
Requires: (python3-rapidfuzz-devel%{?_isa} =
%{?epoch:%{epoch}:}%{version}-%{release} if python3-devel)
That way, application packages that pull in pytohn3-rapidfuzz as a runtime
dependency won't get it (we are minimizing the install footprint for users),
but users who build stuff (including RPM packages) will get it (we make
automatically generated dependencies work as intended).
(Of course, users who have python3-devel installed for reasons other than
rapidfuxx will still get the files, but the assumption here is that users who
install -devel packages intent to /generally/ build stuff.)
Is that a good suggestion? And if so, should it be a general recommendation for
such cases?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Fwd: [pypy-dev] Dropping py3.8, working on py3.10
Considering this, I intent to retire pypy3.8 from Fedora 38+ before the beta freeze. Forwarded Message Subject: [pypy-dev] Dropping py3.8, working on py3.10 Date: Tue, 10 Jan 2023 12:01:58 +0200 From: Matti Picus To: pypy-...@python.org We have begun work on py3.10. I changed the buildbot configuration to build default (py2.7), py3.9, py3.10 instead of default (py2.7), py3.8, py3.9. Builds for py3.8 (or any branch) can be kicked off manually. Unless there is significant push-back, or some latent urgent bug appears on py3.8, I do not plan on making another py3.8 release. Help is always welcome, the py3.10 work is at a stage of "death by 1000 paper cuts" where there are many small details that need to be changed. One thing people could do is to peruse the lib-python failures (testing py3.10 on the upstream stdlib tests) for obvious [2] problems. You can see the log file by looking at the latest builds [0] -> clicking on the pypy-c-jit-linux-x86-64 link -> shell_16 lib-python test failed -> stdio. There are some hints for parsing that output on the wiki [1]. Matti [0] https://buildbot.pypy.org/summary?branch=py3.10 [1] https://foss.heptapod.net/pypy/pypy/-/wikis/Analysing-lib-python-errors [2] what may be obvious to you may be gibberish to someone else, which is why we need everyone's expertise ___ 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
News in pyproject-rpm-macros 1.5.x and 1.6.x
Hello Pythonistas.
We have released a new version of pyproject-rpm-macros 1.6.2.
The last announcement on this list was for 1.4.0, so let me summarize what's
new since then:
The 1.5.x versions are not very significant. 1.5.0+ now uses the
%py3_test_envvars macro (available on Fedora 38+) in %tox. This is mostly an
internal change, but it has subtle differences for packages using %tox. The
noticeable difference is that CFLAGS/LDFLAGS are now set to
${RPM_OPT_FLAGS}/${RPM_LD_FLAGS}, so if the tests run gcc etc. in them they use
the RPM build flags.
1.5.1 adjusted tests for tox 4+, which is also available in Fedora 38+.
--
Version 1.6.0 introduced a new pyproject-srpm-macros subpackage (installed in
the default buildroot) with a minimal implementation of the
%pyproject_buildrequires macro.
Packages using %pyproject_buildrequires now technically don't need to manually
BuildRequire neither pyproject-rpm-macros nor python3-devel.
With that change, the python3-devel package in ELN/RHEL10+ no longer requires
pyproject-rpm-macros. ELN packages that use pyproject-rpm-macros and don't use
%pyproject_buildrequires might need to be adjusted. As always, I note that
using pyproject-rpm-macros without %pyproject_buildrequires works fine but has
no backwards compatibility guarantees -- packagers who prefer to list all
BuildRequires manually might need to adjust the list even on "minor"
pyproject-rpm-macros updates.
This change was mostly motivated by the need to avoid pulling
pyproject-rpm-macros into the AppStream RHEL10+ repository and is not impacting
Fedora builds in any negative way. The python3-devel package in Fedora still
requires pyproject-rpm-macros.
--
Version 1.6.1 fixed a subtle bug in %pyproject_buildrequires. When the build
backend (mostly a setup.py scrip) was shelling out to subprocesses its stdout
was falsely part of the generated BuildRequires. This is now fixed.
See http://bugzilla.redhat.com/2166888 for details.
--
Version 1.6.2 now considers more paths as language files.
Previously, only files like .../locale/xx/LC_MESSAGES/*.mo were marked as
%lang(xx). Currently the /locale/ part no longer needs to be there.
We decided to treat this as a bugfix.
See https://bugzilla.redhat.com/2166295 for details.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: Cython build failing on longintrepr.h not found
On 27. 09. 22 19:41, Miro Hrončok wrote: On 27. 09. 22 17:55, Sandro wrote: On 27-09-2022 08:17, Lumír Balhar wrote: Make sure that the build does not use the pyx file from upstream. It seems to me that the file generated by Cython is in the source tarball (skmisc/loess/src/_loess.pyx) and I did not find any mention of use of Cython in the build log. The file is probably generated by an older version of Cython and that is causing you the problem. Thank you, Lumír, for pointing me in the right direction. The offending pregenerated C file was indeed in the source tarball along with a precompiled library for good measure. I was looking at the source on GitHub, which does not have skmisc/loess/src/_loess.c. I'm sure that's what you meant. It's generated from skmisc/loess/src/_loess.pyx I have switched to the GitHub source tarball, which seems to be aimed at developers, who like to build everything from scratch, and comes without pregenerated files nor binaries. However, I haven't been able to build the package, yet. It looks like the tools/cythonize.py script, which is called from setup.py, generates output, that throws off %pyproject_buildrequires: No matching package to install: 'Processing' No matching package to install: 'changed' Is there a standard way of handling noisy scripts? Or am I just out of luck using pyproject macros? Or, my bet, am I missing something? https://copr.fedorainfracloud.org/coprs/gui1ty/neuro-sig/build/4875750/ Looking at the code, this happens because: 1) their setup.py uses subprocess https://github.com/has2k1/scikit-misc/blob/v0.1.4/setup.py#L92 2) the script executed via subprocess prints to stdout: https://github.com/has2k1/scikit-misc/blob/v0.1.4/tools/cythonize.py#L177 3) %pyproject_buildrequires uses contextlib.redirect_stdout: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/a3e31c/f/pyproject_buildrequires.py#_52 4) contextlib.redirect_stdout does not support stdout of subprocesses https://docs.python.org/3/library/contextlib.html#contextlib.redirect_stdout We might need a more robust way of redirecting all of stdout... And this now finally has a fix ready: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/353 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Pre-review of a new python package: uswid
On 31. 01. 23 13:12, Richard Hughes wrote: Hey all, I'm building python-uswid as a rpm as it's going to be needed by the fwupd-efi package at build time in the near future. I'm also the upstream maintainer, so I'm not against changing upstream and then tagging a new release if there's something that needs to be fixed to build a Fedora package. I'm no python expert, so advice very welcome. I've uploaded a srpm here and I'd appreciate some early 40,000ft checks before I submit a Fedora package review: https://people.freedesktop.org/~hughsient/temp/python-uswid-0.4.1-1.fc37.src.rpm -- the upstream is https://github.com/hughsie/python-uswid/ for the curious. Another thing, if you decide not to use the current Packaging guidelines with automatically generated BuildRequires. The https://github.com/hughsie/python-uswid/blob/main/setup.py file has: from setuptools import setup And hence the spec file must have: BuildRequires: python3-setuptools For %py3_build and %py3_install to work. Have you tried to build the package? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Pre-review of a new python package: uswid
On 31. 01. 23 13:12, Richard Hughes wrote:
Hey all,
I'm building python-uswid as a rpm as it's going to be needed by the fwupd-efi
package at build time in the near future. I'm also the upstream maintainer, so
I'm not against changing upstream and then tagging a new release if there's
something that needs to be fixed to build a Fedora package. I'm no python
expert, so advice very welcome.
I've uploaded a srpm here and I'd appreciate some early 40,000ft checks before
I submit a Fedora package review:
https://people.freedesktop.org/~hughsient/temp/python-uswid-0.4.1-1.fc37.src.rpm
-- the upstream is https://github.com/hughsie/python-uswid/ for the curious.
Thanks!
Hey Richard.
I agree with what Neal said, plus:
You might want to follow the current Python packaging guidelines, i.e. use this
template:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_empty_spec_file
The main added benefit for this package:
Runtime requires aromatically generated as BuildRequires, so when tests run,
they are installed and it works. Currently you don't BR
python3-{cbor2,lxml,pefile} and hence the tests might fail. I'd be surprised if
the tests pass without the runtime deps (it might indicate the tests are not
"good enough").
The added benefit is that if the package would miss runtime dependencies, it
won't build and you will realize the problem sooner.
Considering you are also the upstream, it allows you to specify test
dependencies upstream (e.g. as an [test] extra, I can help with that) and not
copy-paste the information into the spec file (I understand that if the only
tests dependency is pytest, this does not sound like a big deal, but generally,
it gets the packaging part easier).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: Heads up: tox 4 in Rawhide buildroot
On 11. 01. 23 15:59, Miro Hrončok wrote: > Successfully waited 0:00 for python-tox-4.2.6-1.fc38 to appear in the f38-build repo. If you hit unexpected issues with %tox, let us know here or in Bugzilla. First gotcha: tox 4 no longer fails without configuration: $ tox --print-deps-to - ROOT: No tox.ini or setup.cfg or pyproject.toml found, assuming empty tox.ini at .../patiencediff-0.2.12 tox py: OK (0.01 seconds) congratulations :) (0.04 seconds) $ echo $? 0 So packages that us: %generate_buildrequires %pyproject_buildrequires -t Without any tox configuration at all will now simply BuildRequire tox and tox-current-env for no good reason, instead of failing :/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
-Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python
Hello folks,
this recent Fedora change:
https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
Made me think:
Which compiler flags we need to store in Python and which can we omit?
In order to make Python extension modules binary compatible with Python, Python
saves the compiler flags at compile-time and reuses them when building
extension modules.
Historically, we had troubles with this approach because some of the flags are
unusable without redhat-rpm-config, annobin etc.
As a result, there are now 2 compiler flags macros available for RPM:
%{build_cflags} and %{extension_cflags} (same for ldflags etc.).
While Python itself is built with %{build_cflags}, it saves %{extension_cflags}
in sysconfig.
The flags differ like this:
$ diff -u <(rpm --eval '%build_cflags' | tr ' ' '\n') <(rpm --eval
'%extension_cflags' | tr ' ' '\n') | grep ^-
--flto=auto
--ffat-lto-objects
--specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
--specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
$ diff -u <(rpm --eval '%build_ldflags' | tr ' ' '\n') <(rpm --eval
'%extension_ldflags' | tr ' ' '\n') | grep ^-
--specs=/usr/lib/rpm/redhat/redhat-hardened-ld
--specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
(There are also some other differences wrt
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects but
those are apparently harder to get from outside of a real build.)
The current set of flags from Python can be obtained by:
>>> sysconfig.get_config_var('CFLAGS')
'-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security -U_FORTIFY_SOURCE
-Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2
-fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security
-U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_GNU_SOURCE -fPIC -fwrapv -O2 -fexceptions -g -grecord-gcc-switches -pipe
-Wall -Werror=format-security -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE
-Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong
-m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -D_GNU_SOURCE -fPIC -fwrapv'
>>> sysconfig.get_config_var('LDFLAGS')
'-Wl,-z,relro -Wl,--as-needed -Wl,-z,now-Wl,--build-id=sha1 -g
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now-Wl,--build-id=sha1 -g'
I wonder if other flags should be removed as well.
Isn't Python built e.g. with -Werror=format-security or -Wsign-compare binary
compatible with extension modules built without it?
What about FORTIFY_SOURCE and others?
Is there a compiler flags expert here who could help me determine what flags
could (or even should) be removed from %{extension_*flags}?
Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Heads up: tox 4 in Rawhide buildroot
> Successfully waited 0:00 for python-tox-4.2.6-1.fc38 to appear in the f38-build repo. If you hit unexpected issues with %tox, let us know here or in Bugzilla. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Building Python 3.12 with no-omit-frame-pointer
On 23. 11. 22 9:12, Petr Viktorin wrote:
On 22. 11. 22 18:30, Miro Hrončok wrote:
On 21. 11. 22 11:01, Petr Viktorin wrote:
And since the Python slowdown comes from a single weird function, I think
that Fedora should ignore the Python benchmarks when evaluating the distro
default -- and if Fedora switches to no-omit-frame-pointer, Python 3.11
should be an exception (to be re-evaluated for 3.12).
Do I interpret correctly?
If (and only if) Fedora switches to -fno-omit-frame-pointer, python3.11 (and
possibly older Pythons) will explicitly use -fomit-frame-pointer instead (aka
opt-out).
Yes. If the change allows software to opt out (e.g. if it's slowed down too
much), then, based on the benchmarks, Python 3.11 should do that.
python3.11 has opted out.
I've also prepared pull requests for python3.{6..10} to do the same.
I don't intent to touch Python 2.7 unless I have to.
No idea how this affects PyPys, so keeping them untouched as well.
python3.12 will do the same for now.
Or not, if that would help testing. I don't think the speed of the preview
Python matters that much.
python3.12 has not opted out.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: Exposing Shell environment variables from %pytest via %python3_test_envvars?
On 26. 10. 22 14:48, Miro Hrončok wrote:
Hello Pythonistas,
while working on a change that requires adding a new Shell environment variable
to both %pytest and %tox, I figured out we might benefit from defining such
variables at one place.
Maxwell suggested that this place should be exposed to packagers, so they could
use it with other test runners.
In https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/149 we
propose to use it like this:
%check
%{python3_test_envvars} %{python3} -m unittest
Or:
%check
%{python3_test_envvars} stestr run
The macro would currently be defined as:
CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}" \
PATH="%{buildroot}%{_bindir}:$PATH" \
PYTHONPATH="${PYTHONPATH:-%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib}}"
\
PYTHONDONTWRITEBYTECODE=1 \
%{?__pytest_addopts:PYTEST_ADDOPTS="${PYTEST_ADDOPTS:-} %{__pytest_addopts}"}
PYTEST_XDIST_AUTO_NUM_WORKERS=%{_smp_build_ncpus}
Some of the variables are pytest-specific, but some are useful with other test
runners as well.
I am writing this email to raise awareness and get some feedback, if needed.
As always, the most important question is the bikeshed color^W^W macro name.
This has landed in rawhide as %py3_test_envvars. Will let it there for a while
before backporting it or documenting it in the guidelines.
See [1] and [2] for the name reasoning.
[1]
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/149#comment-124048
[2]
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/149#comment-124067
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: python-lockfile deprecation
On 13. 12. 22 6:06, Carl George wrote: Howdy Python SIG and python-lockfile maintainers, I recently noticed that pylockfile (packaged as python-lockfile in Fedora and EPEL) is no longer maintained upstream (since 2017). https://github.com/openstack-archive/pylockfile I see 10 packages that still (build)require this, so retirement is probably premature, but is anyone opposed to me marking the package as deprecated so that new packages can't (build)require it? I'd support such change proposal. I wanted to get rid of it long ago but poetry requires CacheControl[filecache] and that requires this one. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Headers file in python package
On 04. 12. 22 9:51, Mattia Verga wrote: I'm reviewing the un-retirement ticket of python-nss [1] and rpmlint is complaining about header files under the python module directory. The specfile is using the %pyproject_save_files macro to get the file list. I'm unsure if this is a false positive or I must ask the submitter to filter out those files in a -devel package... What do you think? What is the purpose of the header files? Does the package function without them? In that case, I think they shall be completely eliminated, not moved to a devel subpackage. To eliminate them, I would suggest modifying setup.py not to install them at all, however looking at it I have no idea how would I do that. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2133080 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Building Python 3.12 with no-omit-frame-pointer
On 21. 11. 22 11:01, Petr Viktorin wrote: And since the Python slowdown comes from a single weird function, I think that Fedora should ignore the Python benchmarks when evaluating the distro default -- and if Fedora switches to no-omit-frame-pointer, Python 3.11 should be an exception (to be re-evaluated for 3.12). Do I interpret correctly? If (and only if) Fedora switches to -fno-omit-frame-pointer, python3.11 (and possibly older Pythons) will explicitly use -fomit-frame-pointer instead (aka opt-out). python3.12 will do the same for now. Once the massive changes to _PyEval_EvalFrameDefault land in Python 3.12, we will re-evaluate whether to use -fomit-frame-pointer or -fno-omit-frame-pointer (regardless of the Fedora global flags). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Heads up: NumPy 1.23.4 coming to rawhide
Hello Pythonistas, I am building numpy-1.23.4-1.fc38 in rawhide. I will also update python-hypothesis to 6.56.3 to fix some failures with the new NumPy version. This breaks some packages, I've reported the problems couple weeks ago: https://bugzilla.redhat.com/buglist.cgi?bug_id=2137287,2137289,2137290,2137291,2137292,2137293,2137443,2137441 Maintainers by package: astrometry lupinix python-Bottleneckbesser82 python-astropy-healpix lupinix python-nipy ankursinha ignatenkobrain python-numexpr tnorth zbyszek python-pint lzachar mrunge Packages by maintainer: ankursinha python-nipy besser82 python-Bottleneck ignatenkobrain python-nipy lupinixastrometry python-astropy-healpix lzacharpython-pint mrunge python-pint tnorth python-numexpr zbyszekpython-numexpr -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: ImportError: attempted relative import with no known parent package
On 26. 10. 22 19:40, Sandro wrote: Hi, I'm getting the ImportError from subject specifically when building python-plotnine for f36 (Python 3.10.7). Yes, importing from .conftest in tests should not be possible. The same package builds fine for f37 and rawhide (Python 3.11.0). Maybe pytest somehow made this work? It¨s not just Python 3.11 but also pytest 7. The module the test is trying to import from is present in tests/, so I'm a bit stupefied as to why this fails. I also tried with putting an empty __init__.py in tests/. But this fails with an OSError in conftest.py. Do you happen to have the exact OSError with a traceback? Maybe it's not related. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: pathfix.py will be removed from Python 3.12
On 27. 10. 22 11:51, Miro Hrončok wrote: micropython churchyard https://src.fedoraproject.org/rpms/micropython/pull-request/14 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: pathfix.py will be removed from Python 3.12
policycoreutils vpolasek openscap waltersGConf2 wcohen systemtap whot libevdev libinput wsato openscap yselkowitz workrave zbyszeklibsbml python-igor zvetliknodejs -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: pathfix.py will be removed from Python 3.12
On 26. 10. 22 18:41, Maxwell G wrote: On Wed Oct 26, 2022 at 12:41 +0200, Lumír Balhar wrote: Since Python 2.0 (1994), Python provided a useful tool pathfix.py that we use in Python RPM macros for fixing shebangs of Python modules and some RPM packages use it as well directly in their specfiles for similar purposes. The script will no longer be part of CPython source code and python3-devel RPM package. Because we think it's useful, we have decided to create a new upstream project for it (https://github.com/fedora-python/pathfix) on Github and include it in the python3-rpm-macros package. The change means the script will move from /usr/bin/pathfix.py to /usr/lib/rpm/redhat/pathfix.py. Why does it need to be moved to python-rpm-macros and a private location? Can it be put in a separate package and kept in its existing location in /usr/bin? Just installing the script straight into /usr/bin (i.e. don't make it a proper Python distribution) and running the current unittest-based tests shouldn't pose too much of a bootstrap problem. We don't want to maintain this script for our users forever, we just want to maintain the macro. But if there is a huge pushback, we can introduce a compatibility shim in the original location that emits deprecation warnings. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Exposing Shell environment variables from %pytest via %python3_test_envvars?
Hello Pythonistas,
while working on a change that requires adding a new Shell environment variable
to both %pytest and %tox, I figured out we might benefit from defining such
variables at one place.
Maxwell suggested that this place should be exposed to packagers, so they could
use it with other test runners.
In https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/149 we
propose to use it like this:
%check
%{python3_test_envvars} %{python3} -m unittest
Or:
%check
%{python3_test_envvars} stestr run
The macro would currently be defined as:
CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}" \
PATH="%{buildroot}%{_bindir}:$PATH" \
PYTHONPATH="${PYTHONPATH:-%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib}}"
\
PYTHONDONTWRITEBYTECODE=1 \
%{?__pytest_addopts:PYTEST_ADDOPTS="${PYTEST_ADDOPTS:-} %{__pytest_addopts}"}
PYTEST_XDIST_AUTO_NUM_WORKERS=%{_smp_build_ncpus}
Some of the variables are pytest-specific, but some are useful with other test
runners as well.
I am writing this email to raise awareness and get some feedback, if needed.
As always, the most important question is the bikeshed color^W^W macro name.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: distutils use in hivex libdnet libnbd (and more) [was: Re: Help needed triaging build failures without distutils]
On 24. 10. 22 12:46, Richard W.M. Jones wrote: I'm not sure what could have happened here. The RPM would have failed to build if the Python bindings had been ./configure-d out. The link shows libguestfs as "not build yet / Disabled": https://copr.fedorainfracloud.org/coprs/g/python/python-without-distutils/packages/?page=13 (I forgot to respond to this part of your email, so doing that now.) That is caused by the fact that I build packages in a custom "directory" which is a copr thing that allows me to build thousands of packages in copr without them "seeing" each other, but it has some UX downsides, such as not being visible as built on this page. but then there's a build which succeeded: https://copr.fedorainfracloud.org/coprs/g/python/python-without-distutils/build/4906970/ and it has Python bindings. (The logs of the build don't seem to be available.) Yeah, I only renewed failed builds for the logs, I had no idea people will want to examine succeeded packages. Looking at the latest succeeded root.log from Koji instead https://koji.fedoraproject.org/koji/buildinfo?buildID=2074440 https://kojipkgs.fedoraproject.org//packages/libguestfs/1.49.5/2.fc38/data/logs/x86_64/root.log I see python3-setuptools was installed, which is the likely reason the build succeeded without distutils (as said in my announcement, setuptools provide a distutils module, which is 99%-compatible replacement for the removed standard library module). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: [Libguestfs] distutils use in hivex libdnet libnbd (and more) [was: Re: Help needed triaging build failures without distutils]
On 24. 10. 22 15:14, Richard W.M. Jones wrote:
Original code:
$ python3 -c 'import distutils.sysconfig;
print(distutils.sysconfig.get_python_lib(1,0));'
/usr/lib64/python3.11/site-packages
Potential replacement:
$ python3 -c 'import sysconfig; print(sysconfig.get_path("platlib"));'
/usr/local/lib64/python3.11/site-packages
That is a correct replacement. It will return the same value in rpmbuild
environment.
Maybe the original code was wrong, but I guess we don't want to
install site packages in /usr/local when running under RPM at least.
$ python3 -c 'import sysconfig; print(sysconfig.get_path("platlib"));'
/usr/local/lib64/python3.11/site-packages
$ RPM_BUILD_ROOT=/ python3 -c 'import sysconfig;
print(sysconfig.get_path("platlib"));'
/usr/lib64/python3.11/site-packages
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: Replacing pytest -n auto with pytest -n %{_smp_build_ncpus}
On 12. 07. 22 11:50, Miro Hrončok wrote:
On 12. 07. 22 11:25, Petr Viktorin wrote:
Or pytest-xdist could be taught to check an environment variable for
`auto`, making this seamless for packagers?
This could work, except that sometimes pytest-xdist is installed and we
don't want to run tests in parallel because they are not prepared for that.
But I guess an opt-out would still exist, e.g. setting %{_smp_build_ncpus}
to 1 in the %check section.
I will have a look if there is an environment variable we could use. We can
probably adjust PYTEST_ADDOPTS if we detect pytest-xdist is available.
I meant teaching pytest-xdist to look at an envvar, which would just be
ignored if xdist isn't around.
Actually I just went ahead and proposed it upstream:
https://github.com/pytest-dev/pytest-xdist/issues/792
Oh, now I get it. Perfect!
A followup:
Petr's change was merged to pytest-xdsit:
https://github.com/pytest-dev/pytest-xdist/pull/829
I've drafted a change for %pytest:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/149
Change for %tox will follow.
Packages that call pytest directly (i.e. not by the macros) won't benefit from
this change.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
