Splitting alternative Python packages into subpackages, e.g.
python3.11{,libs,devel,...}
by Tomáš Orsava
Hi Python-devel,
we are considering splitting the alternative Python versions from a
single-package format (e.g. python3.11) to multiple subpackages (e.g.
python3.11{,-libs,-devel,-tkinter,-test,-idle}). We do this already with
the main `python3` package: it requires less disk space to install and
speeds up download times, because you can chose which bits are important
to you. For example, if you decide you don't need python3-tkinter, you
save yourself ~18 dependent packages leading to a total savings of
~20MBs, while skipping python3-test saves you further ~10MBs.
What do you think?
The push came from [BZ#2063227] where the reporters would welcome to
have a smaller python3.11 package for containers and VMs for local
testing, CI purposes and more.
This would be a larger amount of work, so our initial reaction was
hesitant. We'll have to change the already complicated spec file %bcond
logic, and adjust the ecosystem to work with the new subpackages. For
example tox would need to Recommend `python3.11-devel`, as `python3.11`
would bring in only the bare interpreter. And of course a thorough
integration testing would be in order.
However, we already do separate subpackages for alternative stacks in
Enterprise Linux (CentOS /Stream, RHEL, EPEL) and as a general rule we
consider it good to have fewer differences between Fedora and EL. This
helps to test things earlier, and there are fewer surprises in user
experience. So perhaps the effort in doing this would be well spent.
To cut down on the amount of work, we're considering changing only the
`python3.11` package (and any future newer versions) right now. If later
we consider it worth it, we could switch the older alternative
interpreters as well, or we might let them die out as they are.
We're currently in the brainstorming stage, so you're feedback is welcome.
[BZ#2063227] https://bugzilla.redhat.com/show_bug.cgi?id=2063227
All the best,
Tomáš
1 year, 4 months
Re: Retire unused nose plugins?
by Miro Hrončok
On 21. 04. 20 15:58, Matthias Runge wrote:
> On 21/04/2020 12:55, Miro Hrončok wrote:
>> Hello.
>>
>> Given https://fedoraproject.org/wiki/Changes/DeprecateNose would you be
>> OK if I retire python-nose_fixes, python-nose-xcover and
>> python-nose-testconfig in rawhide?
>>
>> Nothing in Fedora depends on them:
>>
>> $ repoquery --repo=rawhide{,-source} --whatrequires python3-nose_fixes
>> $ repoquery --repo=rawhide{,-source} --whatrequires python3-nose-xcover
>> $ repoquery --repo=rawhide{,-source} --whatrequires python3-nose-testconfig
>>
>> Thanks,
> yes, sure!
There seem to be 2 more that can be dropped:
$ repoquery --repo=rawhide{,-source} --whatrequires python3-nose_fixes
$ repoquery --repo=rawhide{,-source} --whatrequires python3-nose-cover3
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 6 months
Dropping 32bit arches from pypy2.7?
by Miro Hrončok
Hello.
pypy 2.7 fails to build with GCC 12 on 32 bit arches.
https://bugzilla.redhat.com/show_bug.cgi?id=2046857
Instead of investigating this and trying to fix this, I wonder if I can just
excludearch %ix86 and %arm32. No other Fedora package really requires pypy,
(asv uses it in %check but it already excludes some arches).
I am not aware of any multilib i686 use cases and we retired arm32 anyway.
I would probably do this in Fedora 37 only, but if we need to rebuild the
package in the future e.g. for a CVE fix or upgrade, excluding the arches on
F36 would also help me.
Any thoughts?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 6 months
Pytest 7 coming to rawhide next week
by Miro Hrončok
Hello Pythonistas,
I intent to upgrade pytest in Rawhide to 7.0.x next week.
There are ~18 packages affected at build time and 2 almost-unused pytest
plugins are affected on runtime.
See https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTEST7
If you wish to test your changes against pytest 7, send a rawhide pull request
to your package and it will show up in
https://copr.fedorainfracloud.org/coprs/churchyard/pytest-7/builds/ --
alternatively, use that Copr repo directly, e.g. in mock or in another Copr.
If you need help getting your package fixed with pytest 7, feel free to ask. If
the problem remains unfixed, your package will fail to build from source
starting next week.
In the worst case scenario, I can help you package python-pytest6, but I do not
wish to maintain that long term.
Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 6 months
[HEADS-UP] - python-setuptools 60.9.x is heading to Rawhide
by Karolina Surma
Hello,
python-setuptools 60.9.x will be shipped to Rawhide on Friday, Mar 11.
During the efforts to integrate the new version to Fedora we have
discovered ~25 affected packages.
Wherever it was straightforward to fix, I sent a Pull Request directly
to the package repository in Fedora's dist-git. For more complex cases,
a Bugzilla ticket was created.
setuptools 60+ brings a significant behavior change: it makes its local
copy of distutils the default. To override the new default, set the
environment variable SETUPTOOLS_USE_DISTUTILS=stdlib.
The setuptools' copy sometimes behaves differently than distutils from
Python's standard library. If overriding, bear in mind that Python's
distutils is deprecated and slated for removal in Python 3.12. We
encourage you to work with the upstreams to fix the encountered
distutils' issues, but ideally migrating away from distutils entirely.
python-setuptools's license string has changed as some new libraries are
vendored by the package.
The new license is: 'MIT and ASL 2.0 and (BSD or ASL 2.0) and Python'
(was: 'MIT and (BSD or ASL 2.0)').
Happy packaging,
Karolina Surma
1 year, 6 months
Is missing python3-docs in EL9 a problem?
by Orion Poplawski
I've been poking at some packages that BR python3-docs, like
python-zope-event. This apparently comes from a sphinx inventory:
# Use local objects.inv for intersphinx
sed -i "s|\('https://docs\.python\.org/':
\)None|\1'%{_docdir}/python3-docs/html/objects.inv'|" docs/conf.py
If I build without python3-docs present I get the following message but
the build succeeds:
Running Sphinx v3.4.3
making output directory... done
loading intersphinx inventory from
/usr/share/doc/python3-docs/html/objects.inv...
WARNING: failed to reach any of the inventories with the following issues:
intersphinx inventory '/usr/share/doc/python3-docs/html/objects.inv' not
fetchable due to <class 'FileNotFoundError'>: [Errno 2] No such file or
directory: '/usr/share/doc/python3-docs/html/objects.inv'
Is this a problem or can we safely ignore it? Is there a better way to
remove the intersphinx dep?
If not, how best to get python3-docs into EL9?
Thanks.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
1 year, 6 months
Making PyPy 3.9 the "main" pypy3 for Fedora 36?
by Miro Hrončok
Hello Pythonistas.
Do you think we should make /usr/bin/pypy3 PyPy 3.9 in Fedora 36? It is rather
late in the release cycle, but considering this is essentially a leaf package I
think this might be a good idea.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 6 months
Orphaned python-aiohttp-cors
by Miro Hrončok
Hello,
I've maintained python-aiohttp-cors because python-black required it, but it no
longer does, so I've just orphaned it.
The package is now only required by gns3-server.
The package builds, installs, builds with Python 3.11 (we have just pushed a fix).
However, it appears dead upstream. Consider dropping the dependency instead of
taking the package.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 6 months