Bug 1713856

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.