Bug 1741567 - Request to package gdal for EPEL 8
Summary: Request to package gdal for EPEL 8
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: gdal
Version: epel8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Devrim Gündüz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1763546
Blocks: 1788804 1771975
TreeView+ depends on / blocked
 
Reported: 2019-08-15 12:33 UTC by adam winberg
Modified: 2020-06-04 00:49 UTC (History)
17 users (show)

Fixed In Version: gdal-3.0.4-5.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-04 00:49:10 UTC
Type: Bug


Attachments (Terms of Use)
GDAL 3.0.4 SPEC file modified for Centos 8 (42.69 KB, text/plain)
2020-05-09 13:56 UTC, markusN
no flags Details

Description adam winberg 2019-08-15 12:33:53 UTC
Could you please build gdal for EPEL8?

Comment 1 Norman Gaywood 2019-08-29 23:18:07 UTC
Also a version > 1 for EL7 would be great.
It seems to be stuck at 1.11.4 since 2017

Comment 2 Orion Poplawski 2019-10-20 23:51:11 UTC
DEBUG util.py:593:  No matching package to install: 'libkml-devel'

Comment 3 Daniele Branchini 2019-10-31 14:08:25 UTC
Hi,
I don't want to be pushing, I'm asking just to understand the issue and find out if I can help in any way and/or reference a bug on the correct package: what's the current status on gdal rebuild?

I tried to rebuild it on local machine with source packages from fedora repos, this is what I found out about missing build dependencies in epel 8 repos:

1.  gdal needs libkml
2a. libkml needs uriparser (the only thing I managed to rebuild for CentOS8)
2b. libkml also needs junit
3. junit needs maven-local (that should be provided as a subpackage of javapackages-tools, and rebuilding it from epel8 srpm actually builds the package, I'm probably missing something here)
4. maven-local needs xmvn (as an installation requirement)
5. xmvn needs gradle
6. gradle seems to need a ton of apparently unavailable maven plugins to build

are those the biggest culprit of the issue?

Thank you for any help you can offer.

Comment 4 Orion Poplawski 2019-11-03 01:16:05 UTC
The dependent packages and bugs are linked to this report.  We are just needing libkml -> uriparser I believe.  junit is in the javapackages-tools module in the CodeReader Linux Builder repo in RHEL8 (PowerTools in CentOS 8).

I've requested the uriparser branches to get that train moving...

Devrim - are you interested in maintaining gdal in epel8 once we get the dependencies in place?

Comment 5 Devrim Gündüz 2019-11-03 12:38:57 UTC
Hi Orion,

I can try. Let's wait for 3.0.2 to be released first (it is very very close). Then, I'll try.

Regards, Devrim

Comment 6 Daniele Branchini 2019-11-04 11:06:44 UTC
(In reply to Orion Poplawski from comment #4)
> The dependent packages and bugs are linked to this report.  We are just
> needing libkml -> uriparser I believe.  junit is in the javapackages-tools
> module in the CodeReader Linux Builder repo in RHEL8 (PowerTools in CentOS
> 8).
> 

Thank you for all the informations, I did an unsuccessful `dnf search junit` with PowerTools repo enabled but I didn't know I had to enable the module to actually find it.

Comment 7 Devrim Gündüz 2019-11-04 22:24:20 UTC
Pushed spec and patches to the repo. Waiting for the dependencies.

Comment 8 Orion Poplawski 2019-11-05 15:43:44 UTC
Just submitted https://bodhi.fedoraproject.org/overrides/libkml-1.3.0-24.el8

Comment 9 Orion Poplawski 2019-11-14 04:07:06 UTC
Looks like frmts/iso8211/GNUmakefile does not properly support builds with libtool - so OBJ_EXT gets set to .lo, but it's not building with libtool.

Comment 10 Daniele Branchini 2019-12-10 10:18:20 UTC
Hi, I don't know if it can be of any help but I built gdal packages on a CentOs 8 (x86_64) straight from Fedora 32 srpm (2.3.2-14), I just had to comment out the "patch11" (it's needed for poppler 0.73 while CentOs 8 has 0.66).

(but I ignore what release of gdal was chosen for CentOs8 nor if there are complications on other achitectures)

Comment 11 Paolo Patruno 2019-12-20 14:01:36 UTC
Any news?
Using the Fedora 32 srpm (2.3.2-14) is the right way?

Comment 12 Daniele Branchini 2020-01-07 14:32:26 UTC
(In reply to Paolo Patruno from comment #11)
> Any news?
> Using the Fedora 32 srpm (2.3.2-14) is the right way?

If I understand correctly (it took me a bit), looking here:
https://apps.fedoraproject.org/packages/gdal/builds/
it seems that the chosen version for epel 8 will be 3.0.2 but it's currently failing (I guess with the error described in comment #9)

Comment 13 adam winberg 2020-01-24 11:03:33 UTC
That failed build is from 2 months ago, any news?

Comment 14 Orion Poplawski 2020-01-31 02:07:50 UTC
Devrim - Looks like you gave up on 3.X in Fedora?  What's the status there?  I see 3.0.4 is out now - don't know if that addresses any issues.

Comment 15 Daniele Branchini 2020-03-09 11:41:43 UTC
I hope I'm not breaking any policy here, but if anyone is interested we repackaged out of necessity gdal 2.3.2 (and ncl) for CentOS8 from fedora srpm on a public copr repo:

https://copr.fedorainfracloud.org/coprs/simc/stable/

please note: there are no java plugins (I had some troubles managing the `javapackages-tools` module on copr so I removed `--with-java` from configure)

This of course is a temporary unofficial workaround and there could be conflicts with the future official package if they gave up with the 3.x version. We tried to stick to the guidelines for the versioning (https://fedoraproject.org/wiki/PackagingDrafts/TildeVersioning) so the full name is: gdal-2.3.2-14aSIMC.el8 (SIMC being the name of our organization).


Again, if this message is inappropriate I apologize.

Comment 16 markusN 2020-05-04 14:19:04 UTC
Any chance to make use of Daniele Branchini efforts on COPR also here?

Comment 17 markusN 2020-05-09 13:56:12 UTC
Created attachment 1686787 [details]
GDAL 3.0.4 SPEC file modified for Centos 8

Comment 18 markusN 2020-05-09 13:58:55 UTC
Attached the official GDAL SPEC file with following changes:

- disabled JAVA and LaTeX support for EPEL8, due to (yet) missing dependencies

It compiles on Centos 8 and is highly desired to be officially distributed (no idea if anyone can address the missing dependencies).

Comment 19 markusN 2020-05-09 21:10:53 UTC
Here the COPR EPEL8 built of GDAL 3.0.4:
https://copr.fedorainfracloud.org/coprs/neteler/GDAL/builds/

Comment 20 markusN 2020-05-16 21:18:21 UTC
(In reply to markusN from comment #18)
> Attached the official GDAL SPEC file with following changes:
> 
> - disabled JAVA and LaTeX support for EPEL8, due to (yet) missing
> dependencies
> 
> It compiles on Centos 8 and is highly desired to be officially distributed
> (no idea if anyone can address the missing dependencies).

Submitted as https://src.fedoraproject.org/rpms/gdal/pull-request/13

Comment 21 Fedora Update System 2020-05-19 11:19:58 UTC
FEDORA-EPEL-2020-53ddeb81a7 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-53ddeb81a7

Comment 22 Fedora Update System 2020-05-20 05:13:52 UTC
FEDORA-EPEL-2020-53ddeb81a7 has been pushed to the Fedora EPEL 8 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-53ddeb81a7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 23 markusN 2020-05-31 18:35:57 UTC
FYI:
I tried to compile GDAL 3.1.0 but struggle with the docs due to BZ#1808766.

For now I have added conditions to skip the GDAL docs but hesitate to submit that to EPEL8.

The current lack of python-breathe for EPEL8 is an issue for both GDAL and PDAL.

Comment 24 Fedora Update System 2020-06-04 00:49:10 UTC
FEDORA-EPEL-2020-53ddeb81a7 has been pushed to the Fedora EPEL 8 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.