proj + libgdal: update and rebuild dependants #31687
Conversation
|
Hello @Chocimier, do you have any insight into why postgis builds fail the checks in this PR? It's unrelated to the updates of gdal and proj, I see the same thing when just doing a compile locally on master branch. The build against updated gdal/proj (without checks) seems to function correctly locally. Not sure if missing |
|
Disabled failing tests for now, please rebase. |
|
I've changed/reverted the maintainer lines where applicable. I'd been in touch with Nyx70 previously and he gave thumbs up on continuing with his work, but wasn't explicit about maintainership. Re
Is this a matter of removing those flags, and if so, how to do that? Finally there's one more package to be rebuilt against libgdal and proj, grass. The currently packaged version is apparently not working #29209; I built the new grass version 7.8.5 but it still has non-working GUI. So maybe that can be done separately. I've resolved the xlint license issue for osg, but if I push that it'll trigger another build, maybe that's not desirable? |
diff --git a/srcpkgs/libgdal/template b/srcpkgs/libgdal/template
index 2c6f38a328..f71d947b0a 100644
--- a/srcpkgs/libgdal/template
+++ b/srcpkgs/libgdal/template
@@ -2,8 +2,6 @@
pkgname=libgdal
version=3.2.3
revision=1
-# aarch & arm currently failing
-archs="~aarch* ~armv*"
wrksrc="gdal-${version}"
build_style=gnu-configure
configure_args="
@@ -39,20 +37,41 @@ build_options_default="kml"
if [ -z "$CROSS_BUILD" ]; then
makedepends+=" hdf5-devel"
fi
+CFLAGS="-pthread -I${XBPS_CROSS_BASE}/${py3_inc}"
+LDFLAGS="-L${XBPS_CROSS_BASE}/${py3_lib}"
post_build() {
+ if [ "$CROSS_BUILD" ]; then
+ export PYPREFIX="$XBPS_CROSS_BASE"
+ export PYTHONPATH=${XBPS_CROSS_BASE}/${py3_lib}
+ for f in ${XBPS_CROSS_BASE}/${py3_lib}/_sysconfigdata_*; do
+ f=${f##*/}
+ export _PYTHON_SYSCONFIGDATA_NAME=${f%.py}
+ done
+ fi
+ export LDSHARED="${CC} $CFLAGS -shared $LDFLAGS"
+
rm -f swig/python/*_wrap.cpp
make -C swig/python generate
cd swig/python
- make ${makejobs} PYTHON=python3 ${makejobs}
+ python3 setup.py build
}
post_install() {
vinstall gdal.pc 644 usr/lib/pkgconfig
vlicense LICENSE.TXT
- # python modules
+ if [ "$CROSS_BUILD" ]; then
+ export PYPREFIX="$XBPS_CROSS_BASE"
+ export PYTHONPATH=${XBPS_CROSS_BASE}/${py3_lib}
+ for f in ${XBPS_CROSS_BASE}/${py3_lib}/_sysconfigdata_*; do
+ f=${f##*/}
+ export _PYTHON_SYSCONFIGDATA_NAME=${f%.py}
+ done
+ fi
+ export LDSHARED="${CC} $CFLAGS -shared $LDFLAGS"
+
cd swig/python
- make PYTHON=python3 DESTDIR=${DESTDIR}/ install
+ python3 setup.py install --prefix=/usr --root=$DESTDIR
}
libgdal-tools_package() {
@@ -79,9 +98,8 @@ python3-gdal_package() {
depends="${sourcepkg}>=${version}_${revision}"
short_desc+=" - Python3 bindings"
pkg_install() {
- vmove usr/bin/*.py
+ vmove "usr/bin/*.py"
vmove "usr/lib/python*"
- vlicense LICENSE.TXT
vdoc swig/python/README.rst
vmkdir usr/share/python3-gdal
vcopy swig/python/samples usr/share/python3-gdal/examples |
|
Thanks @sgn! Re OpenOrienteering-Mapper, tests passed locally, it looks like the following failure is specific to the test runner. How best to handle that?
|
|
You can add do_check() {
cd build
ctest -E 'sensors_t'
}which disables that specific test |
ar-jan
force-pushed
the
gdal-proj
branch
3 times, most recently
from
881b60d
to
77c29c0
Compare
|
Apparently, the Grass GUI currently packaged is not functional (#29209). The updated version compiles and starts successfully, but in my testing the GUI disappears as soon as the mouse pointer enters its area. I do not see any error message. Any clues how to find the cause? If not perhaps it can be merged anyway since the GUI is already not functional in the current state and otherwise the library versions are a problem. |
ar-jan
changed the title
|
The Grass GUI issue is due to to wxPython4 with Python 3.9 which segfaults. OSGeo/grass#1261 This issue is fixed in wxPython4-4.1.1 which requires wxWidgets 3.1, but I assume it's not desirable to update to the 3.1 branch since it isn't stable like the current 3.0 series. I tried with a backported patch to wxPython4 but still had the same issue. |
Not only that, it doesn't even work for all our applications... Do you have any suggestions? |
|
That first part was probably wrong -- what seems to be the underlying bug is fixed in that version, but I've tried with a backported patch which does work for Fedora, but without success. So either I'm doing something wrong in using the patched wxPython, or maybe something else is wrong (but that would be weird given that it fails in exactly the same way as described there). |
|
What steps did you follow? |
|
I built Then installed wxPython4 and grass from this local build, then ran I supposed it's only a runtime dependency, but to be sure I also built I just switched to a new installation using i3 and I'm now seeing an additional error that I didn't see before: |
ar-jan
force-pushed
the
gdal-proj
branch
3 times, most recently
from
4f920c9
to
13c821f
Compare
|
Edit: I've simplified the PR by only rebuilding the current version of grass, and omitting libspatialite/libkml/librttopo for a separate PR. Grass looks as functional as before. |
ar-jan
force-pushed
the
gdal-proj
branch
5 times, most recently
from
64aa285
to
bf26193
Compare
|
Anyone have any ideas of why the crossbuild fails? @sgn maybe? It was working before. It seems that the swig build is now attempted in the do_build step, while it should be occurring in the custom post_build step. |
|
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it. |
|
I could take a look on cross compilation, but logs expired. Please rebase. |
libgdal-3.4.1 proj-7.2.1
libgdal-3.4.1 proj-7.2.1
Do not use ninja ("unknown target" error)
|
I updated the branch. @Chocimier or @sgn want to take a look at libgdal cross compilation? (The other builds are failing because postgis-postgresql12 install is attempted). |
|
I've updated the libgdal template like so (not pushing to avoid needless 4 hour CI build): Updated libgdal-3.4.3 templateBut it looks like starting with
I think this is because Is that right? How to fix? |
|
libgdal was updated in #40225, can you rebase for the proj update? |
|
(easier to make a new branch) |
General
Have the results of the proposed changes been tested?
I use PostGIS regularly and this works for me.
I generally don't use the other packages which have to be rebuilt against proj and/or gdal, but I did test all of them briefly.
Motivation