Description of problem: upstream proj has released new versions 6.0.0 and 6.1.0, and looking at the 6.0.0 release notes a lot has changed since the 5.x series. pyproj upstream is following these changes and can no longer be build using proj 5.x, so currently I cannot update this package anymore. This bug is just to note the current situation, and to help me track when proj gets upgraded to the new version.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
still waiting for news here. If the maintainer could add a note on what the plans are that would be appreciated.
Looks like libgeotiff 1.5 requires proj 6 as well. Devrim, are you still around?
PR - https://src.fedoraproject.org/rpms/proj/pull-request/6
Hi, (In reply to Orion Poplawski from comment #4) > Looks like libgeotiff 1.5 requires proj 6 as well. Devrim, are you still > around? 6.2.0 is is just out. Please let's start with 6.2.0. I am on it.
FEDORA-2019-29c418b1d7 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-29c418b1d7
Hi Orion, (In reply to Orion Poplawski from comment #4) > Looks like libgeotiff 1.5 requires proj 6 as well. Devrim, are you still > around? That said, I pushed 1.5.1 to EPEL 8. I'll leave Fedora to Volker.
proj-6.2.0-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-29c418b1d7
The update actually broke pyproj. Problem: conflicting requests - nothing provides libproj.so.13()(64bit) needed by python3-cartopy-0.17.0-6.fc31.x86_64 Problem: package python3-geopandas-0.5.1-1.fc31.noarch requires python3.7dist(pyproj), but none of the providers can be installed - conflicting requests - nothing provides libproj.so.13()(64bit) needed by python3-pyproj-1.9.6-3.fc31.x86_64 - nothing provides proj-epsg needed by python3-pyproj-1.9.6-3.fc31.x86_64 - nothing provides proj-nad needed by python3-pyproj-1.9.6-3.fc31.x86_64
Hi, Sorry for the breakage. I am working on fixing it. Regards, Devrim
Hi Miro, I also tried to update to 2.3.1, but it failed: https://koji.fedoraproject.org/koji/taskinfo?taskID=37456340 https://kojipkgs.fedoraproject.org//work/tasks/6340/37456340/build.log Can you please take a look? Sorry about that. Regards, Devrim
You need to recythonize the sources. See https://pagure.io/packaging-committee/issue/893
Hi Miro, I am not a Python/Cython guy -- and read the link and sublinks as well :) Still, not quite sure what I need to do. Is that something like for file in `find %{buildroot} -iname "*.py"` do cython $i done or? Sorry again. Devrim
https://src.fedoraproject.org/rpms/pyproj/pull-request/2
Hi Devrim and Miro, first a big thank you for stepping in and doing the pyproj update. The new proj for rawhide seems not yet available in my local mirror, but if I download the proj 6.2.0 generated rpms from koji and manually insert them in mock I can locally rebuild this new version. There may be one small issue left. If I use rpmlint on the generated rpm files it complains about one file in the docs: python3-pyproj.x86_64: E: wrong-script-interpreter /usr/share/doc/python3-pyproj/docs/conf.py /usr/bin/env python If I try to generate docs manually in the unpacked source tree /builddir/build/BUILD/pyproj-2.3.1/docs/ using the provided Makefile, it becomes clear that also the Makefile still points to plain python without version. So my questions: * should generation of docs (html or other) be added to the specfile? I find no statements on this in the packaging guidelines. * if so, should we patch the conf.py and Makefile in the docs dir to point to python3 * if not, should we still patch these files in case users wish to generate the documentation themselves? What do you think?
(In reply to Jos de Kloe from comment #16) > Hi Devrim and Miro, > > first a big thank you for stepping in and doing the pyproj update. > The new proj for rawhide seems not yet available in my local mirror, but if > I download the proj 6.2.0 generated rpms from koji and manually insert them > in mock I can locally rebuild this new version. > > There may be one small issue left. If I use rpmlint on the generated rpm > files it complains about one file in the docs: > > python3-pyproj.x86_64: E: wrong-script-interpreter > /usr/share/doc/python3-pyproj/docs/conf.py /usr/bin/env python That shebang would ideally be removed, yes. > If I try to generate docs manually in the unpacked source tree > /builddir/build/BUILD/pyproj-2.3.1/docs/ using the provided Makefile, it > becomes clear that also the Makefile still points to plain python without > version. > > So my questions: > * should generation of docs (html or other) be added to the specfile? I find > no statements on this in the packaging guidelines. It might. Not should. > * if so, should we patch the conf.py and Makefile in the docs dir to point > to python3 You should remove the shebang (preferably in upstream). For Makefile, I believe it just uses the "sphinx-build" command, doesn't it? > * if not, should we still patch these files in case users wish to generate > the documentation themselves? You should still remove the shebang. Otherwise I wouldn't patch anything.
(In reply to Miro Hrončok from comment #15) > https://src.fedoraproject.org/rpms/pyproj/pull-request/2 Sorry, forgot to thank you. Regards, Devrim
No problem :)
I proposed a patch upstream for the python->python3 issue, which was accepted and merged. Next I'll take a look at the spec file to patch the issue for this current version. Also I will look again at the documentation generation. The provided makefile uses "python -msphinx" to generate the documentation, not sphinx-build.
Fix for plain python usage and documentation generation has been added now to the rawhide version.
The latest version 2.4.1 of pyproj has been build succesfully now for rawhide, so closing this bug.