Could you please build gdal for EPEL8?
Also a version > 1 for EL7 would be great. It seems to be stuck at 1.11.4 since 2017
DEBUG util.py:593: No matching package to install: 'libkml-devel'
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.
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?
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
(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.
Pushed spec and patches to the repo. Waiting for the dependencies.
Just submitted https://bodhi.fedoraproject.org/overrides/libkml-1.3.0-24.el8
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.
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)
Any news? Using the Fedora 32 srpm (2.3.2-14) is the right way?
(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)
That failed build is from 2 months ago, any news?
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.
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.
Any chance to make use of Daniele Branchini efforts on COPR also here?
Created attachment 1686787 [details] GDAL 3.0.4 SPEC file modified for Centos 8
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).
Here the COPR EPEL8 built of GDAL 3.0.4: https://copr.fedorainfracloud.org/coprs/neteler/GDAL/builds/
(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
FEDORA-EPEL-2020-53ddeb81a7 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-53ddeb81a7
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.
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.
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.