Python Classroom Lab help needed: proj-data is suddenly 569M
by Miro Hrončok
Hello,
when debugging an unexpected significant file size grow of the Python Classroom
Lab [1], I've realized the following package changes since Fedora 33:
proj
-proj-datumgrid
+proj-data-at
+proj-data-au
+proj-data-be
+proj-data-br
+proj-data-ca
+proj-data-ch
+proj-data-de
+proj-data-dk
+proj-data-es
+proj-data-eur
+proj-data-fi
+proj-data-fo
+proj-data-fr
+proj-data-is
+proj-data-jp
+proj-data-nc
+proj-data-nl
+proj-data-nz
+proj-data-pt
+proj-data-se
+proj-data-sk
+proj-data-uk
+proj-data-us
And /usr/share/proj is huge:
[fedora-34]$ du -h /usr/share/proj
569M /usr/share/proj
[fedora-33]$ du -h /usr/share/proj
14M /usr/share/proj
When I attempt to remove proj, I get:
===============================================================================
Package Arch Version Repository Size
===============================================================================
Removing:
proj x86_64 7.2.1-1.fc34 @anaconda 13 M
Removing dependent packages:
python3-gdal x86_64 3.2.1-3.fc34 @anaconda 4.1 M
Removing unused dependencies:
SuperLU x86_64 5.2.1-14.fc33 @anaconda 467 k
armadillo x86_64 10.1.2-1.fc34 @anaconda 99 k
arpack x86_64 3.7.0-8.fc33 @anaconda 625 k
cfitsio x86_64 3.470-3.fc33 @anaconda 1.7 M
freexl x86_64 1.0.6-1.fc33 @anaconda 70 k
gdal-libs x86_64 3.2.1-3.fc34 @anaconda 26 M
geos x86_64 3.9.0-1.fc34 @anaconda 2.2 M
hdf-libs x86_64 4.2.15-3.fc33 @anaconda 682 k
libdap x86_64 3.20.6-2.fc33 @anaconda 2.1 M
libgeotiff x86_64 1.6.0-3.fc34 @anaconda 344 k
libgta x86_64 1.0.9-5.fc33 @anaconda 75 k
libkml x86_64 1.3.0-29.fc33 @anaconda 1.2 M
libpq x86_64 13.1-1.fc34 @anaconda 715 k
librttopo x86_64 1.1.0-1.fc34 @anaconda 518 k
libspatialite x86_64 5.0.0-3.fc34 @anaconda 16 M
mariadb-connector-c x86_64 3.1.11-1.fc34 @anaconda 539 k
mariadb-connector-c-config noarch 3.1.11-1.fc34 @anaconda 497
minizip x86_64 2.10.2-1.fc34 @anaconda 354 k
netcdf x86_64 4.7.3-5.fc34 @anaconda 1.9 M
ogdi x86_64 4.1.0-4.fc33 @anaconda 871 k
proj-data-at noarch 7.2.1-1.fc34 @anaconda 2.1 M
proj-data-au noarch 7.2.1-1.fc34 @anaconda 118 M
proj-data-be noarch 7.2.1-1.fc34 @anaconda 749 k
proj-data-br noarch 7.2.1-1.fc34 @anaconda 1.0 M
proj-data-ca noarch 7.2.1-1.fc34 @anaconda 94 M
proj-data-ch noarch 7.2.1-1.fc34 @anaconda 1.6 M
proj-data-de noarch 7.2.1-1.fc34 @anaconda 74 M
proj-data-dk noarch 7.2.1-1.fc34 @anaconda 9.9 M
proj-data-es noarch 7.2.1-1.fc34 @anaconda 1.0 M
proj-data-eur noarch 7.2.1-1.fc34 @anaconda 1.0 M
proj-data-fi noarch 7.2.1-1.fc34 @anaconda 288 k
proj-data-fo noarch 7.2.1-1.fc34 @anaconda 1.5 k
proj-data-fr noarch 7.2.1-1.fc34 @anaconda 1.2 M
proj-data-is noarch 7.2.1-1.fc34 @anaconda 5.5 M
proj-data-jp noarch 7.2.1-1.fc34 @anaconda 420 k
proj-data-nc noarch 7.2.1-1.fc34 @anaconda 1.1 M
proj-data-nl noarch 7.2.1-1.fc34 @anaconda 1.1 M
proj-data-nz noarch 7.2.1-1.fc34 @anaconda 14 M
proj-data-pt noarch 7.2.1-1.fc34 @anaconda 431 k
proj-data-se noarch 7.2.1-1.fc34 @anaconda 2.2 M
proj-data-sk noarch 7.2.1-1.fc34 @anaconda 1.2 M
proj-data-uk noarch 7.2.1-1.fc34 @anaconda 4.8 M
proj-data-us noarch 7.2.1-1.fc34 @anaconda 224 M
unixODBC x86_64 2.3.9-1.fc34 @anaconda 1.4 M
uriparser x86_64 0.9.4-2.fc33 @anaconda 160 k
xerces-c x86_64 3.2.3-2.fc33 @anaconda 3.5 M
Transaction Summary
===============================================================================
Remove 48 Packages
Freed space: 637 M
When I only remove the data, I get:
===============================================================================
Package Architecture Version Repository Size
===============================================================================
Removing:
proj-data-at noarch 7.2.1-1.fc34 @anaconda 2.1 M
proj-data-au noarch 7.2.1-1.fc34 @anaconda 118 M
proj-data-be noarch 7.2.1-1.fc34 @anaconda 749 k
proj-data-br noarch 7.2.1-1.fc34 @anaconda 1.0 M
proj-data-ca noarch 7.2.1-1.fc34 @anaconda 94 M
proj-data-ch noarch 7.2.1-1.fc34 @anaconda 1.6 M
proj-data-de noarch 7.2.1-1.fc34 @anaconda 74 M
proj-data-dk noarch 7.2.1-1.fc34 @anaconda 9.9 M
proj-data-es noarch 7.2.1-1.fc34 @anaconda 1.0 M
proj-data-eur noarch 7.2.1-1.fc34 @anaconda 1.0 M
proj-data-fi noarch 7.2.1-1.fc34 @anaconda 288 k
proj-data-fo noarch 7.2.1-1.fc34 @anaconda 1.5 k
proj-data-fr noarch 7.2.1-1.fc34 @anaconda 1.2 M
proj-data-is noarch 7.2.1-1.fc34 @anaconda 5.5 M
proj-data-jp noarch 7.2.1-1.fc34 @anaconda 420 k
proj-data-nc noarch 7.2.1-1.fc34 @anaconda 1.1 M
proj-data-nl noarch 7.2.1-1.fc34 @anaconda 1.1 M
proj-data-nz noarch 7.2.1-1.fc34 @anaconda 14 M
proj-data-pt noarch 7.2.1-1.fc34 @anaconda 431 k
proj-data-se noarch 7.2.1-1.fc34 @anaconda 2.2 M
proj-data-sk noarch 7.2.1-1.fc34 @anaconda 1.2 M
proj-data-uk noarch 7.2.1-1.fc34 @anaconda 4.8 M
proj-data-us noarch 7.2.1-1.fc34 @anaconda 224 M
Transaction Summary
===============================================================================
Remove 23 Packages
Freed space: 559 M
The dependency chain that brings in proj is:
python3-scikit-image (from @python-science) requires python3-networkx which
recommends python3-gdal which requires proj.
My questions are:
1) What happens if I keep proj but remove the data? Or should I remove gdal
entirely instead?
2) Why so sudden growth?
Thanks for help.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1902354
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 hour, 11 minutes
pytest 6.2.x update incoming
by Miro Hrončok
Hello Pythonistas.
I'd like to update pytest to 6.2 in rawhide after the mass rebuild. The impact
on not-already-broken packages is surprisingly small.
pybind11: fixed upstream in git
python-alembic: uses removed feature, old version is packaged
python-docopt: uses removed feature, stalled upstream issue exists
python-fiat: broken by python-pytest-cases
python-hypothesis: pytest regression fixed in git, hypothesis adapted upstream
python-jaraco-classes: missing BR
python-pytest-cases: uses removed feature, old version is packaged
python-pytest-ordering: investigating, possible pytest regression
python-pytest-toolbox: missing BR
python-setuptools_scm: fixed upstream
python-watchgod: missing BR
python-werkzeug: fails on new warnings (treated as errors)
See the details in https://src.fedoraproject.org/rpms/pytest/pull-request/19
Let me know if I shall wait or if you want my help with fixing some of the
affected packages. If nobody speaks up, I plan to fix hypothesis, setuptools_scm
and upgrade pytest in a ~1 week.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 day, 12 hours
Self-introduction Yordan
by Yordan
Hello group
My name is Yordan Rodriguez, I am an Electronic Engineer in my last
semester of the University from Colombia. By the way, sorry for my English.
Actually I have a lot of free time because of the pandemic then I was
researching about fedora and I got into a SIGs/Python article. I have
basic Python in linux and I would like to improve my knowledge of Python
by being a part of a big project like this.
The area that I fine interesting is the *Packaging and maintaining
Python applications*. I will be researching about it while I wait your
some tasks to do.
Thanks for your time
5 days, 12 hours
Re: [EPEL-devel] Re: EPEL7 python3/python36 standardization
by Carl George
I'm not sure I understand your question. This proposal is about
python36 packages, not the existing python34 packages or hypothetical
python38 packages. In any case, packages shouldn't be requiring
python* directly. They automatically get a requirement on
`python(abi) = X.Y` that serves this purpose.
On Thu, Jan 21, 2021 at 4:57 AM Andrew C Aitchison
<andrew(a)aitchison.me.uk> wrote:
>
>
> On Thu, 21 Jan 2021, Carl George wrote:
>
> > RHEL7 ships Python 3.6 packages using the python3 prefix. Currently
> > EPEL7 contains Python 3.6 packages using both the python3 and python36
> > prefixes. Thanks to the foresight and preparation work of the Red Hat
> > Python Maintenance team, these work interchangeably when using the
> > %python_provide macro. However the situation is still confusing for
> > packagers and users. We never formalized guidelines on which prefix
> > to use. I would like to change that. I propose that we standardize
> > on the python3 prefix to match RHEL7 packages and document in EPEL
> > guidelines that maintainers SHOULD use the python3 prefix.
>
> Do we need to be explicit about how we spell any value of these keys
> - e.g. should it be
> Requires: python >= 38
> or
> Requires: python >= 3.8
> ?
>
> --
> Andrew C. Aitchison Kendal, UK
> andrew(a)aitchison.me.uk
> _______________________________________________
> epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave(a)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/epel-devel@lists.fedoraproj...
--
Carl George
6 days, 19 hours
EPEL7 python3/python36 standardization
by Carl George
Howdy folks,
RHEL7 ships Python 3.6 packages using the python3 prefix. Currently
EPEL7 contains Python 3.6 packages using both the python3 and python36
prefixes. Thanks to the foresight and preparation work of the Red Hat
Python Maintenance team, these work interchangeably when using the
%python_provide macro. However the situation is still confusing for
packagers and users. We never formalized guidelines on which prefix
to use. I would like to change that. I propose that we standardize
on the python3 prefix to match RHEL7 packages and document in EPEL
guidelines that maintainers SHOULD use the python3 prefix.
Transitioning packages is straightforward. Packages using a
python%{python3_pkgversion}-<name> subpackage can simply rename it to
python3-<name>. If the top level package is already python3-<name>,
then the subpackage can be converted into the top level package. In
both cases, `%python_provide python3-<name>` handles the necessary
provides and obsoletes. This work doesn't need to happen all at once,
and maintainers can opt in as they have time. We already have a mix
of prefixes, this is just about nudging towards python3 as the correct
prefix.
Please share your feedback, and I'll present this proposal and the
feedback to the EPEL Steering Committee.
--
Carl George
6 days, 19 hours
%{python3} no defined in epel-7-aarch64?
by José Abílio Matos
I have used copr to build the first alpha release of lyx-2.4:
https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/build/1858028/
For EPEL7 it build for x86_64 and it fails for aarch64, due to %{python3} not
being defined.
The spec file has BR: python3-devel.
In the install stage I have this:
%py_byte_compile %{python3} %{buildroot}%{_datadir}/%{name}/lyx2lyx
This fails in epel-7-aarch64:
https://download.copr.fedorainfracloud.org/results/jamatos/lyx-devel/epel...
"
+ python_binary='%{python3}'
+ buildroot_path=/builddir/build/BUILDROOT/lyx-devel-2.4.0-0.2.alpha1.el7.aarch64/usr/share/lyx-devel/lyx2lyx
~/build/BUILDROOT/lyx-devel-2.4.0-0.2.alpha1.el7.aarch64 ~/build/BUILD/lyx-2.4.0-alpha1
+ bytecode_compilation_path=./usr/share/lyx-devel/lyx2lyx
+ failure=0
+ pushd /builddir/build/BUILDROOT/lyx-devel-2.4.0-0.2.alpha1.el7.aarch64
+ xargs -0 '%{python3}' -O -m py_compile
+ find ./usr/share/lyx-devel/lyx2lyx -type f -a -name '*.py' -print0
xargs: %{python3}: No such file or directory
+ failure=1
+ xargs -0 '%{python3}' -m py_compile
+ find ./usr/share/lyx-devel/lyx2lyx -type f -a -name '*.py' -print0
xargs: %{python3}: No such file or directory
+ failure=1
~/build/BUILD/lyx-2.4.0-alpha1
+ popd
+ test 1 -eq 0
"
while in the corresponding x86_64 the first line correctly sets:
+ python_binary=/usr/bin/python3
Is this known?
Regards,
--
José Abílio
1 week, 2 days
Re: [EPEL-devel] Re: %{python3} no defined in epel-7-aarch64?
by José Abílio Matos
On Sunday, January 17, 2021 8:01:33 PM WET Jakub Kadlčík wrote:
> Hello everyone,
> as Florian pointed out, the aarch64 architecture support for EPEL 7 was
> discontinued, so I just disabled the epel-7-aarch64 chroot in Copr as
> well.
Thank you Jakub. :-)
Only when Florian sent the message I remembered that aarch64 was discontinued.
With all things going it is easy for these details to escape and it is nice to
have an automatic help in these cases.
--
José Abílio
1 week, 2 days
pyproject-rpm-macros breaking change: %pyproject_save_files now lists
all files explicitly
by Miro Hrončok
Hello,
There is an upcoming update to pyproject-rpm-macros-0-34.fc34, fc33 and fc32.
It contains a backwards incompatible change wrt behavior of %pyproject_save_files:
Previously, when a Python module was a directory, it was listed recursively:
%{python3_sitelib}/foobar/
Now, each file is listed explicitly:
%dir %{python3_sitelib}/foobar
%dir %{python3_sitelib}/foobar/__pycached__
%{python3_sitelib}/foobar/__init__.py
...
This was done to be able to properly list language files and to detect packaging
mistakes.
The list of files is generated from RECORD file:
https://www.python.org/dev/peps/pep-0627/
If you need to manipulate the installed files (rename, move or delete them), try
to do it before building the wheel (e.g. in %prep). If you need to do it after
installing the wheel, using %pyproject_save_files might no longer be possible.
The only affected package in Fedora is:
https://src.fedoraproject.org/rpms/python-matrix-nio/pull-request/1
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 weeks
Need sphinx-tabs
by Richard Shaw
With upcoming OpenColorIO 2.x the documentation generation system has been
completely overhauled and now has a number of new requirements, including
sphinx-tabs.
I have packaged it although I have been unable to get %check to work. I'm
not sure if it's a PBKAC, missing additional testing deps, or they're
actually failing.
It looks to be a very low maintenance package so my idea was to get the
review request done and get it built in Rawhide and then hand it over to
the sig as I need another package to maintain like I need another hole in
my head.
Thoughts?
Thanks,
Richard
2 weeks, 3 days
