Re: ITP: pystac -- Python library for working with the SpatioTemporal Asset Catalog (STAC) specific
+1 Angelos On Sat, Jul 1, 2023 at 8:09 PM Antonio Valentino < antonio.valent...@tiscali.it> wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-Cc: debian-de...@lists.debian.org, : > debian-pyt...@lists.debian.org > Owner: Antonio Valentino > > * Package name: pystac >Version : 1.8.1 >Upstream Author : Rob Emanuele , Jon Duckworth > > * URL : https://github.com/stac-utils/pystac > * License : Apache-2.0 >Programming Lang: Python >Description : Python library for working with the SpatioTemporal > Asset Catalog (STAC) > > Binary package names: python3-pystac > > PySTAC is a library for working with the SpatioTemporal Asset Catalog > (STAC) specification (https://stacspec.org) in Python 3. > . > Some nice features of PySTAC are: > . >* Reading and writing STAC version 1.0. Future versions will read > older versions of STAC, but always write the latest supported > version. > See STAC Spec Version Support for details. >* In-memory manipulations of STAC catalogs. >* Extend the I/O of STAC metadata to provide support for other > platforms (e.g. cloud providers). >* Easy, efficient crawling of STAC catalogs. STAC objects are only > read in when needed. >* Easily write “absolute published”, “relative published” and > “self-contained” catalogs as described in the best practices > documentation. > > -- > Antonio Valentino > > -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos
Re: GDAL 3.1.0
Thank you Bas for the update! On 5/15/20 8:44 AM, Sebastiaan Couwenberg wrote: On 5/13/20 12:04 PM, Sebastiaan Couwenberg wrote: GDAL 3.1.0 has been released, it broke the C++ ABI which required a SONAME bump which in turn triggers a transition. Most rdeps built successfully, fiona is the only real issue. fiona (1.8.13-1) FTBFS due to test failures, reported in #960369. This was already fixed upstream, a patch with those changes has been included. It cannot be uploaded yet, because fontconfig causes the build dependencies to be uninstallable at the moment. Kind Regards, Bas -- Angelos Tzotsos, PhD President Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: GDAL 3.0.2
Thank you for the update and your work Bas! On 1/8/20 7:15 AM, Sebastiaan Couwenberg wrote: On 11/10/19 8:26 PM, Sebastiaan Couwenberg wrote: The transition to GDAL 3 was blocked by the removal of the Python 2 support as discussed in the transition bugreport (#939989). This took quite a bit of time to resolve due to an uncooperative maintainer, but there are no rdeps of python-gdal in unstable any more. In the meantime the GDAL 3 support in fiona was fixed upstream. vtk7 was also updated to use the embedded copy of PROJ.4 to fix the FTBFS with PROJ 6. OSSIM upstream even ported it to use the GEOS C API to fix the build failure with GEOS 3.8.0. Unfortunately OTB still FTBFS due to recent changes in ITK4. It's still not in testing, so not a big issue. Hopefully we'll be able to start the transition soon, but I fear that the python3.8 transition is going to cause more delays (as it will cause many autopkgtest failure until everything is rebuilt for python3.8 as well). networkx continued to delay the transition due to its update breaking autopkgtests for some of its rdeps, but we just got the go-ahead. This means we'll build the next QGIS release (3.4.15) with PROJ6 & GDAL3 which it does not support well, fortunately next month (on February 27th) we'll switch to the 3.10 LTR which does have support for PROJ6 & GDAL3. There are still some projects that lack support for PROJ6/GDAL3 like mapserver and qmapshack, these may be broken in the next Ubuntu LTS (focal) if they transition to GDAL 3 before the import freeze on February 27th. We'll have more time in Debian to get these packages fixed before the next stable release. For Ubuntu endusers it may be better to stick to PROJ6/GDAL2 for focal due to not all leaf packages supporting GDAL3 yet, for use cases like Travis-CI it's probably more desirable to have PROJ6/GDAL3 in the next LTS. I'll leave it to Gianfranco to decide what to do for focal. Kind Regards, Bas -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: zoo-project 1.7.0
Thank you Bas and Gerald, The package now builds fine. I will push the changes to git. Cheers, Angelos On 7/23/19 9:35 PM, Sebastiaan Couwenberg wrote: On 7/23/19 8:29 PM, Angelos Tzotsos wrote: https://launchpadlibrarian.net/434356921/buildlog_ubuntu-bionic-amd64.zoo-project_1.7.0+ds-1~bionic5_BUILDING.txt.gz You need to update the symbols file: patch -p0 < /path/to/build.log Symbols were removed so dh_makeshlibs exits with non-zero status. Also why rely on LP to build the package, use a local cowbuilder chroot with the PPA as other mirror to get results faster. Kind Regards, Bas -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: zoo-project 1.7.0
Looks like build stage is now ok.
Getting this error in later stage though:
https://launchpadlibrarian.net/434356921/buildlog_ubuntu-bionic-amd64.zoo-project_1.7.0+ds-1~bionic5_BUILDING.txt.gz
On 7/23/19 7:54 PM, Sebastiaan Couwenberg wrote:
On 7/23/19 6:39 PM, Angelos Tzotsos wrote:
For amd64 we now get a zoo-service error:
https://launchpadlibrarian.net/434343096/buildlog_ubuntu-bionic-amd64.zoo-project_1.7.0+ds-1~bionic1_BUILDING.txt.gz
./voronoi.c:203:68: error: ‘Face_iterator {aka class
CGAL::Triangulation_2 >,
CGAL::Triangulation_ds_face_base_2 > >::Finite_faces_iterator}’
has no member named ‘info’
fprintf(stderr," *** %s %d %d %d\n",__FILE__,__LINE__,nf,fit.info());
^~~~
Looks like it want a different version of CGAL.
while for i386, the multiarch patch did not work:
gcc cgictest.o -o cgictest.cgi -L./ -lcgic
/usr/lib/i686-linux-gnu/libfcgi.a
gcc: error: /usr/lib/i686-linux-gnu/libfcgi.a: No such file or directory
It fails because the patch doesn't use the mulitarch path:
/usr/lib/i386-linux-gnu/libfcgi.a
- LIBS= -L./ -lcgic /usr/lib/libfcgi.a
+ LIBS= -L./ -lcgic /usr/lib/${CPU}-linux-gnu/libfcgi.a
Use ${DEB_HOST_MULTIARCH} instead.
If you cannot use the environment variable, retrieve it with:
dpkg-architecture -qDEB_HOST_MULTIARCH
Kind Regards,
Bas
--
Angelos Tzotsos, PhD
Charter Member
Open Source Geospatial Foundation
http://users.ntua.gr/tzotsos
Re: zoo-project 1.7.0
Hi, The issue with cmake was solved by adding otb-qgis,qtbase5-dev,libqt5opengl5-dev,libfcgi-dev to build dependencies. On 7/23/19 8:53 PM, Gérald Fenoy wrote: Angelos, is it possible that orb is also located in /usr/lib/x86_64-gnu-linux/otb/applications/ rather than in /usr/lib/otb/applications/? How did you solve the issue with cmake? (I am curious cause I was not able to build otb2zcfg on my appVeryor script). Best regards, Gerald Fenoy gerald.fe...@geolabs.fr GEOLABS Siège social : Futur Building I 1280, avenue des Platanes 34970 Lattes Tél. fixe : +33 (0) 4 67 43 09 95 Tél. portable : +33 (0) 6 70 08 25 39 Le 23 juil. 2019 à 19:51, Angelos Tzotsos a écrit : Thanks Gerald, this worked. Next error: dh_auto_build --sourcedirectory=thirds/otb2zcfg \ --builddirectory=thirds/otb2zcfg/build cd thirds/otb2zcfg/build && make -j4 -O make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build' /usr/bin/cmake -H/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg -B/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build --check-build-system CMakeFiles/Makefile.cmake 0 make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build' make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build' /usr/bin/cmake -E cmake_progress_start /<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build/CMakeFiles /<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build/CMakeFiles/progress.marks make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build' make -f CMakeFiles/Makefile2 all make -f CMakeFiles/otb2zcfg.dir/build.make CMakeFiles/otb2zcfg.dir/depend make[4]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build' cd /<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /<>/zoo-project-1.7.0+ds/thirds/otb2zcfg /<>/zoo-project-1.7.0+ds/thirds/otb2zcfg /<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build /<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build /<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build/CMakeFiles/otb2zcfg.dir/DependInfo.cmake --color= Scanning dependencies of target otb2zcfg make[4]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build' make -f CMakeFiles/otb2zcfg.dir/build.make CMakeFiles/otb2zcfg.dir/build make[4]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build' [ 50%] Building CXX object CMakeFiles/otb2zcfg.dir/otb2zcfg.cxx.o /usr/bin/c++ -I/usr/include/OTB-6.6 -isystem /usr/include/ITK-4.12 -I/usr/include/gdal -I/usr/include/geotiff -I/usr/include/x86_64-linux-gnu -I/usr/include/libsvm -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL -I/usr/include/qwt -msse2 -mfpmath=sse -g -O2 -fdebug-prefix-map=/<>/zoo-project-1.7.0+ds=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2-std=c++14 -o CMakeFiles/otb2zcfg.dir/otb2zcfg.cxx.o -c /<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/otb2zcfg.cxx make[4]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build' make[4]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build' [100%] Linking CXX executable otb2zcfg /usr/bin/cmake -E cmake_link_script CMakeFiles/otb2zcfg.dir/link.txt --verbose=1 /usr/bin/c++ -msse2 -mfpmath=sse -g -O2 -fdebug-prefix-map=/<>/zoo-project-1.7.0+ds=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,--no-undefined -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -rdynamic CMakeFiles/otb2zcfg.dir/otb2zcfg.cxx.o -o otb2zcfg /usr/lib/x86_64-linux-gnu/libOTBApplicationEngine-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBImageIO-6.6.so.1 -lz /usr/lib/x86_64-linux-gnu/libOTBIORAD-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBIOONERA-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBIOLUM-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBIOMSTAR-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBIOBSQ-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBIOTileMap-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBCurlAdapters-6.6.so.1 -lcurl /usr/lib/x86_64-linux-gnu/libOTBExtendedFilename-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBVectorDataIO-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBIOGDAL-6.6.so.1 -ltinyxml /usr/lib/x86_64-linux-gnu/libOTBIOKML-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBProjection-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBVectorDataBase-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBImageManipulation-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBStreaming-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBGdalAdapters-6.6.so.1 -lkmlbase -lkmldom -lkmlengine /usr/lib/x86_64-linux-gnu/libOTBTransform-6.6.so.1 /usr/lib/x86_64-linux-gnu/libOTBImageBa
Re: zoo-project 1.7.0
ec-4.12.so.1 /usr/lib/libITKSpatialObjects-4.12.so.1
/usr/lib/libITKMesh-4.12.so.1 /usr/lib/libITKTransform-4.12.so.1
/usr/lib/libITKPath-4.12.so.1 /usr/lib/libITKCommon-4.12.so.1 /usr/lib/libitksys-4.12.so.1
/usr/lib/libITKVNLInstantiation-4.12.so.1 /usr/lib/libitkvnl_algo-4.12.so.1
/usr/lib/libitkvnl-4.12.so.1 /usr/lib/libitkv3p_netlib-4.12.so.1
/usr/lib/libitknetlib-4.12.so.1 /usr/lib/libitkvcl-4.12.so.1 -lm -lpthread -lm -ldl
/usr/lib/x86_64-linux-gnu/libotbossimplugins-6.6.so.1 -lgdal -lossim -lOpenThreads -lgeotiff
make[4]: Leaving directory
'/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build'
make[3]: Entering directory
'/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build'
[100%] Built target otb2zcfg
make[3]: Leaving directory
'/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build'
make[2]: Entering directory
'/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build'
/usr/bin/cmake -E cmake_progress_start
/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build/CMakeFiles 0
make[2]: Leaving directory
'/<>/zoo-project-1.7.0+ds/thirds/otb2zcfg/build'
( \
mkdir thirds/otb2zcfg/build/zcfgs; \
cd thirds/otb2zcfg/build/zcfgs; \
ITK_AUTOLOAD_PATH=/usr/lib/otb/applications/ ../otb2zcfg || echo "Ignoring
otb2zcfg failure"; \
for i in BandMath Despeckle KMeansClassification; do \
sed -i "s:mimeType = image/png:mimeType = image/png\nuseMapserver =
true\nmsClassify = true:g" $i.zcfg; \
done; \
for i in Smoothing; do \
sed -i "s:mimeType = image/png:mimeType = image/png\nuseMapserver =
true:" $i.zcfg; \
done \
)
INFO: Module search path: /usr/lib/otb/applications/
ERROR: no module found.
sed: can't read BandMath.zcfg: No such file or directory
sed: can't read Despeckle.zcfg: No such file or directory
sed: can't read KMeansClassification.zcfg: No such file or directory
sed: can't read Smoothing.zcfg: No such file or directory
debian/rules:74: recipe for target 'override_dh_auto_build' failed
On 7/23/19 8:34 PM, Gérald Fenoy wrote:
Dear Angelos,
can you please try commenting this line?
I hope this helps.
Best regards,
Gerald Fenoy
gerald.fe...@geolabs.fr
Le 23 juil. 2019 à 19:30, Angelos Tzotsos a écrit :
Hi Gerald,
This is the blocking error right now:
./voronoi.c:161:77: warning: too many arguments for format [-Wformat-extra-args]
./voronoi.c:203:68: error: ‘Face_iterator {aka class CGAL::Triangulation_2 >, CGAL::Triangulation_ds_face_base_2 >
>::Finite_faces_iterator}’ has no member named ‘info’
fprintf(stderr," *** %s %d %d %d\n",__FILE__,__LINE__,nf,fit.info());
^~~~
Best,
Angelos
On 7/23/19 8:17 PM, Gérald Fenoy wrote:
Dear Angelos,
I guess that on your setup, the libfcgi.a is located in
/usr/lib/x86_64-gnu-linux or something similar.
Your may run a sed command on the Makefile to set the correct location before
running make.
I hope this helps.
Gerald Fenoy
gerald.fe...@geolabs.fr
Le 23 juil. 2019 à 17:18, Angelos Tzotsos
a écrit :
Configuration step is done this time, but there is a new failure:
https://launchpad.net/~gcpp-kalxas/+archive/ubuntu/osgeolive/+build/1739/+files/buildlog_ubuntu-bionic-amd64.zoo-project_1.7.0+ds-1~bionic4_BUILDING.txt.gz
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so
-- Could NOT find Qt5LinguistTools (missing: Qt5LinguistTools_DIR)
-- Configuring done
-- Generating done
dh_auto_build --sourcedirectory=thirds/cgic206 \
--builddirectory=thirds/cgic206
cd thirds/cgic206 && make -j4 -O
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
gcc -I/usr/local/include -g -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -c -o
capture.o capture.c
make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
gcc -I/usr/local/include -g -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -c -o
cgictest.o cgictest.c
cgictest.c: In function ‘cgiMain’:
cgictest.c:25:2: warning: implicit declaration of function ‘dup2’
[-Wimplicit-function-declaration]
dup2(cgiOut,stdout);
^~~~
make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
gcc -I/usr/local/include -g -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -c -o
cgic.o cgic.c
cgic.c: In function ‘cgiCookieString’:
cgic.c:1749:11: warning: comparison between pointer and zero character constant
[-Wpointer-compare]
if ((p == '\0') && (n == '\0')) {
^~
cgic.c:1749:9: note: did you mean to dereference the pointer?
if ((p == '\0') && (n == '\0')) {
^
cgic.c:1749:26: warning: comparison between pointer and zero character constant
[-Wpointer-compare]
if ((p == '\0') && (n == '\0')) {
^~
cgic.c:1749:24: note: did you mean to derefer
Re: zoo-project 1.7.0
Thanks, the multiarch path worked fine.
On 7/23/19 7:54 PM, Sebastiaan Couwenberg wrote:
On 7/23/19 6:39 PM, Angelos Tzotsos wrote:
For amd64 we now get a zoo-service error:
https://launchpadlibrarian.net/434343096/buildlog_ubuntu-bionic-amd64.zoo-project_1.7.0+ds-1~bionic1_BUILDING.txt.gz
./voronoi.c:203:68: error: ‘Face_iterator {aka class
CGAL::Triangulation_2 >,
CGAL::Triangulation_ds_face_base_2 > >::Finite_faces_iterator}’
has no member named ‘info’
fprintf(stderr," *** %s %d %d %d\n",__FILE__,__LINE__,nf,fit.info());
^~~~
Looks like it want a different version of CGAL.
while for i386, the multiarch patch did not work:
gcc cgictest.o -o cgictest.cgi -L./ -lcgic
/usr/lib/i686-linux-gnu/libfcgi.a
gcc: error: /usr/lib/i686-linux-gnu/libfcgi.a: No such file or directory
It fails because the patch doesn't use the mulitarch path:
/usr/lib/i386-linux-gnu/libfcgi.a
- LIBS= -L./ -lcgic /usr/lib/libfcgi.a
+ LIBS= -L./ -lcgic /usr/lib/${CPU}-linux-gnu/libfcgi.a
Use ${DEB_HOST_MULTIARCH} instead.
If you cannot use the environment variable, retrieve it with:
dpkg-architecture -qDEB_HOST_MULTIARCH
Kind Regards,
Bas
--
Angelos Tzotsos, PhD
Charter Member
Open Source Geospatial Foundation
http://users.ntua.gr/tzotsos
Re: zoo-project 1.7.0
Hi Gerald,
This is the blocking error right now:
./voronoi.c:161:77: warning: too many arguments for format [-Wformat-extra-args]
./voronoi.c:203:68: error: ‘Face_iterator {aka class CGAL::Triangulation_2 >, CGAL::Triangulation_ds_face_base_2 >
>::Finite_faces_iterator}’ has no member named ‘info’
fprintf(stderr," *** %s %d %d %d\n",__FILE__,__LINE__,nf,fit.info());
^~~~
Best,
Angelos
On 7/23/19 8:17 PM, Gérald Fenoy wrote:
Dear Angelos,
I guess that on your setup, the libfcgi.a is located in
/usr/lib/x86_64-gnu-linux or something similar.
Your may run a sed command on the Makefile to set the correct location before
running make.
I hope this helps.
Gerald Fenoy
gerald.fe...@geolabs.fr
Le 23 juil. 2019 à 17:18, Angelos Tzotsos a écrit :
Configuration step is done this time, but there is a new failure:
https://launchpad.net/~gcpp-kalxas/+archive/ubuntu/osgeolive/+build/1739/+files/buildlog_ubuntu-bionic-amd64.zoo-project_1.7.0+ds-1~bionic4_BUILDING.txt.gz
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so
-- Could NOT find Qt5LinguistTools (missing: Qt5LinguistTools_DIR)
-- Configuring done
-- Generating done
dh_auto_build --sourcedirectory=thirds/cgic206 \
--builddirectory=thirds/cgic206
cd thirds/cgic206 && make -j4 -O
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
gcc -I/usr/local/include -g -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -c -o
capture.o capture.c
make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
gcc -I/usr/local/include -g -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -c -o
cgictest.o cgictest.c
cgictest.c: In function ‘cgiMain’:
cgictest.c:25:2: warning: implicit declaration of function ‘dup2’
[-Wimplicit-function-declaration]
dup2(cgiOut,stdout);
^~~~
make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
gcc -I/usr/local/include -g -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -c -o
cgic.o cgic.c
cgic.c: In function ‘cgiCookieString’:
cgic.c:1749:11: warning: comparison between pointer and zero character constant
[-Wpointer-compare]
if ((p == '\0') && (n == '\0')) {
^~
cgic.c:1749:9: note: did you mean to dereference the pointer?
if ((p == '\0') && (n == '\0')) {
^
cgic.c:1749:26: warning: comparison between pointer and zero character constant
[-Wpointer-compare]
if ((p == '\0') && (n == '\0')) {
^~
cgic.c:1749:24: note: did you mean to dereference the pointer?
if ((p == '\0') && (n == '\0')) {
^
make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
rm -f libcgic.a
ar rc libcgic.a cgic.o
ranlib libcgic.a
make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
gcc cgictest.o -o cgictest.cgi -L./ -lcgic /usr/lib/libfcgi.a
gcc: error: /usr/lib/libfcgi.a: No such file or directory
Makefile:30: recipe for target 'cgictest.cgi' failed
On 7/23/19 4:00 PM, Bas Couwenberg wrote:
On 2019-07-23 14:57, Angelos Tzotsos wrote:
Added otb-qgis to the build depends and now this comes up:
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so
CMake Error at
/usr/lib/x86_64-linux-gnu/cmake/OTB-6.6/Modules/OTBQt.cmake:26
(find_package):
Could not find a package configuration file provided by "Qt5Core" with any
of the following names:
Qt5CoreConfig.cmake
qt5core-config.cmake
apt-file is your friend:
$ apt-file search Qt5CoreConfig.cmake
qtbase5-dev: /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake
qtbase5-gles-dev: /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake
Kind Regards,
Bas
--
Angelos Tzotsos, PhD
Charter Member
Open Source Geospatial Foundation
http://users.ntua.gr/tzotsos
--
Angelos Tzotsos, PhD
Charter Member
Open Source Geospatial Foundation
http://users.ntua.gr/tzotsos
Re: zoo-project 1.7.0
For amd64 we now get a zoo-service error:
https://launchpadlibrarian.net/434343096/buildlog_ubuntu-bionic-amd64.zoo-project_1.7.0+ds-1~bionic1_BUILDING.txt.gz
while for i386, the multiarch patch did not work:
gcc cgictest.o -o cgictest.cgi -L./ -lcgic /usr/lib/i686-linux-gnu/libfcgi.a
gcc: error: /usr/lib/i686-linux-gnu/libfcgi.a: No such file or directory
Here is the patch for the makefile:
--- zoo-project-1.7.0+ds.orig/thirds/cgic206/Makefile
+++ zoo-project-1.7.0+ds/thirds/cgic206/Makefile
@@ -4,7 +4,7 @@ ifeq ($(OS),Darwin)
MACOS_CFLAGS=-arch x86_64
LIBS= -L./ -lcgic /usr/local/lib/libfcgi.dylib
else
- LIBS= -L./ -lcgic /usr/lib/libfcgi.a
+ LIBS= -L./ -lcgic /usr/lib/${CPU}-linux-gnu/libfcgi.a
endif
CFLAGS=-I/usr/local/include -g -Wall ${MACOS_CFLAGS}
CC=gcc
Any ideas how to improve this?
On 7/23/19 7:19 PM, Angelos Tzotsos wrote:
Ah, I just saw that there used to be a patch for that, will restore it.
On 7/23/19 6:32 PM, Sebastiaan Couwenberg wrote:
On 7/23/19 5:18 PM, Angelos Tzotsos wrote:
gcc cgictest.o -o cgictest.cgi -L./ -lcgic /usr/lib/libfcgi.a
gcc: error: /usr/lib/libfcgi.a: No such file or directory
So it wants the fcgi static library, apt-file is your friend again:
$ apt-file search libfcgi.a
libfcgi-dev: /usr/lib/x86_64-linux-gnu/libfcgi.a
If the non-multiarch path is hardcoded, that needs to be patched.
Kind Regards,
Bas
--
Angelos Tzotsos, PhD
Charter Member
Open Source Geospatial Foundation
http://users.ntua.gr/tzotsos
Re: zoo-project 1.7.0
Ah, I just saw that there used to be a patch for that, will restore it. On 7/23/19 6:32 PM, Sebastiaan Couwenberg wrote: On 7/23/19 5:18 PM, Angelos Tzotsos wrote: gcc cgictest.o -o cgictest.cgi -L./ -lcgic /usr/lib/libfcgi.a gcc: error: /usr/lib/libfcgi.a: No such file or directory So it wants the fcgi static library, apt-file is your friend again: $ apt-file search libfcgi.a libfcgi-dev: /usr/lib/x86_64-linux-gnu/libfcgi.a If the non-multiarch path is hardcoded, that needs to be patched. Kind Regards, Bas -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: zoo-project 1.7.0
Configuration step is done this time, but there is a new failure:
https://launchpad.net/~gcpp-kalxas/+archive/ubuntu/osgeolive/+build/1739/+files/buildlog_ubuntu-bionic-amd64.zoo-project_1.7.0+ds-1~bionic4_BUILDING.txt.gz
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so
-- Could NOT find Qt5LinguistTools (missing: Qt5LinguistTools_DIR)
-- Configuring done
-- Generating done
dh_auto_build --sourcedirectory=thirds/cgic206 \
--builddirectory=thirds/cgic206
cd thirds/cgic206 && make -j4 -O
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
gcc -I/usr/local/include -g -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -c -o
capture.o capture.c
make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
gcc -I/usr/local/include -g -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -c -o
cgictest.o cgictest.c
cgictest.c: In function ‘cgiMain’:
cgictest.c:25:2: warning: implicit declaration of function ‘dup2’
[-Wimplicit-function-declaration]
dup2(cgiOut,stdout);
^~~~
make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
gcc -I/usr/local/include -g -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -c -o
cgic.o cgic.c
cgic.c: In function ‘cgiCookieString’:
cgic.c:1749:11: warning: comparison between pointer and zero character constant
[-Wpointer-compare]
if ((p == '\0') && (n == '\0')) {
^~
cgic.c:1749:9: note: did you mean to dereference the pointer?
if ((p == '\0') && (n == '\0')) {
^
cgic.c:1749:26: warning: comparison between pointer and zero character constant
[-Wpointer-compare]
if ((p == '\0') && (n == '\0')) {
^~
cgic.c:1749:24: note: did you mean to dereference the pointer?
if ((p == '\0') && (n == '\0')) {
^
make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
rm -f libcgic.a
ar rc libcgic.a cgic.o
ranlib libcgic.a
make[2]: Leaving directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
make[2]: Entering directory '/<>/zoo-project-1.7.0+ds/thirds/cgic206'
gcc cgictest.o -o cgictest.cgi -L./ -lcgic /usr/lib/libfcgi.a
gcc: error: /usr/lib/libfcgi.a: No such file or directory
Makefile:30: recipe for target 'cgictest.cgi' failed
On 7/23/19 4:00 PM, Bas Couwenberg wrote:
On 2019-07-23 14:57, Angelos Tzotsos wrote:
Added otb-qgis to the build depends and now this comes up:
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so
CMake Error at
/usr/lib/x86_64-linux-gnu/cmake/OTB-6.6/Modules/OTBQt.cmake:26
(find_package):
Could not find a package configuration file provided by "Qt5Core"
with any
of the following names:
Qt5CoreConfig.cmake
qt5core-config.cmake
apt-file is your friend:
$ apt-file search Qt5CoreConfig.cmake
qtbase5-dev: /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake
qtbase5-gles-dev:
/usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake
Kind Regards,
Bas
--
Angelos Tzotsos, PhD
Charter Member
Open Source Geospatial Foundation
http://users.ntua.gr/tzotsos
Re: zoo-project 1.7.0
Added otb-qgis to the build depends and now this comes up: -- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so CMake Error at /usr/lib/x86_64-linux-gnu/cmake/OTB-6.6/Modules/OTBQt.cmake:26 (find_package): Could not find a package configuration file provided by "Qt5Core" with any of the following names: Qt5CoreConfig.cmake qt5core-config.cmake Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set "Qt5Core_DIR" to a directory containing one of the above files. If "Qt5Core" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/OTB-6.6/OTBModuleAPI.cmake:67 (include) /usr/lib/x86_64-linux-gnu/cmake/OTB-6.6/OTBModuleAPI.cmake:44 (otb_module_load) /usr/lib/x86_64-linux-gnu/cmake/OTB-6.6/OTBModuleAPI.cmake:88 (_otb_module_config_recurse) /usr/lib/x86_64-linux-gnu/cmake/OTB-6.6/OTBConfig.cmake:106 (otb_module_config) CMakeLists.txt:5 (FIND_PACKAGE) -- Configuring incomplete, errors occurred! On 7/23/19 3:42 PM, Bas Couwenberg wrote: On 2019-07-23 13:58, Angelos Tzotsos wrote: Thanks, now this comes up: CMake Error at /usr/lib/x86_64-linux-gnu/cmake/OTB-6.6/OTBTargets.cmake:1114 (message): The imported target "otbQgisDescriptor" references the file "/usr/bin/otbQgisDescriptor" but this file does not exist. Possible reasons include: Make sure the otb-qgis package is installed (by adding it to the Build-Depends) which provides this binary. Kind Regards, Bas -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: zoo-project 1.7.0
Thanks, now this comes up: CMake Error at /usr/lib/x86_64-linux-gnu/cmake/OTB-6.6/OTBTargets.cmake:1114 (message): The imported target "otbQgisDescriptor" references the file "/usr/bin/otbQgisDescriptor" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/x86_64-linux-gnu/cmake/OTB-6.6/OTBTargets.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/OTB-6.6/OTBConfig.cmake:82 (include) CMakeLists.txt:5 (FIND_PACKAGE) On 7/23/19 2:15 PM, Bas Couwenberg wrote: On 2019-07-23 13:10, Angelos Tzotsos wrote: This is what I got from a test build on Launchpad: https://launchpad.net/~gcpp-kalxas/+archive/ubuntu/osgeolive/+sourcepub/10360913/+listing-archive-extra That would be: configure: error: checking for GetAvailableApplications... failed The configure log for that shows: /usr/bin/ld: /tmp/ccnIzndw.o: relocation R_X86_64_32 against `.rodata._ZNK3itk10Statistics37MersenneTwisterRandomVariateGenerator14GetNameOfClassEv.str1.8' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status You can try to enable PIE for bionic by removing it in debian/rules: # Disable PIE on Ubuntu where it's still problematic VENDOR_DERIVES_FROM_UBUNTU ?= $(shell dpkg-vendor --derives-from Ubuntu && echo yes) DISTRIBUTION_RELEASE := $(shell lsb_release -cs) ifeq ($(VENDOR_DERIVES_FROM_UBUNTU),yes) ifneq (,$(filter $(DISTRIBUTION_RELEASE),xenial bionic)) export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie endif endif Kind Regards, Bas -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: zoo-project 1.7.0
Thank you Bas, This is what I got from a test build on Launchpad: https://launchpad.net/~gcpp-kalxas/+archive/ubuntu/osgeolive/+sourcepub/10360913/+listing-archive-extra Regards, Angelos On 7/22/19 8:39 PM, Sebastiaan Couwenberg wrote: How far did you come with the patches? I just pushed a change to disable all patches that don't apply, and drop the ones that have been applied upstream. That's should allow the build to start at least, to see which ones need to be updated because the issue has not been fixed upstream. Kind Regards, Bas -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
zoo-project 1.7.0
Moving discussion to the mailing list. I am trying to build the recent zoo release. Best, Angelos On 7/19/19 11:20 PM, Sebastiaan Couwenberg wrote: On 7/19/19 9:59 PM, Angelos Tzotsos wrote: Hi, This is the log from the uscan command. Why does it break the version number? Because it also finds the watch file for cgic: thirds/cgic206/debian/watch $ uscan --watchfile thirds/cgic206/debian/watch --report uscan: Newest version of zoo-project on remote site is 2.07, local version is 1.6.0+ds uscan:=> Newer package available from http://www.boutell.com/cgic/cgic207.tar.gz You can restrict uscan to only use debian/watch file --watchfile too. It's probably a good idea to repack the tarball and exclude the cgic watch file by adding it to Files-Excluded in debian/copyright, you can also exclude its entire debian directory. Yay for embedded copies. Kind Regards, Bas -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
pygeoapi 0.6.0
Hi all, I am wondering if there is interest in adding pygeoapi in Debian. pygeoapi is a Python server implementation of the emerging OGC WFS 3.0 (now being renamed as OGC API - Features) standard. Source available here: https://github.com/geopython/pygeoapi I have already made an upstream debian folder and pushed to UbuntuGIS. The plan is to create a pygeoapi-wsgi package similar to pycsw-wsgi. Cheers, Angelos -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: pyproj 2.2.0
+1 to not update pyproj for a while. Best, Angelos On 6/2/19 9:30 AM, Sebastiaan Couwenberg wrote: pyproj 2.2.0 has been released and is a bit problematic. It requires the aenum module for Python < 3.6 which is not packaged. Packaging it is an option, but its test suite fails with Python 2.7 & 3.7. It has Python 3 specific tests that setup.py removes when called with `setup.py install` and running with Python 2.7, this would need to be translated to a pybuild override. It also needs to be patched to work correctly with how pybuild runs the tests with Python 3. We could remove the Python 2 support from pyproj in theory, but python-pyproj still has many reverse dependencies that would need to drop Python 2 support too, otherwise the package won't be able to migrate to testing creating a blocker for the PROJ 6 transition. For UbuntuGIS it also creates problems, because xenial has Python 3.5 which also requires aenum for pyproj 2.2.0. I don't really want to package the aenum module, as it's not very relevant for Debian unstable where we have Python 3.7 and Python 2.7 will be EOL at the end of the year. Perhaps it's best to not update pyproj for a while until we have completed the PROJ 6 transition, and removed Python 2 support from the reverse dependencies. Thoughts? Kind Regards, Bas -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: PROJ 6.0.0
TODO sumo(1.1.0+dfsg1-1)TODO thuban (1.2.2-14) TODO vtk6(6.3.0+dfsg2-2)TODO vtk7(7.1.1+dfsg1-12) TODO xastir (2.1.0-3) TODO freecad (0.18~pre1+dfsg1-4)TODO gammaray(2.9.0-2.1)TODO grass (7.6.0-1) TODO ifrit (4.1.2-6) TODO lammps (0~20181211.gitad1b1897d+dfsg1-1) TODO node-mapnik (3.7.2+dfsg-5) TODO python-mapnik (1:0.0~20180723-588fc9062-2) TODO r-cran-lwgeom (0.1-5+dfsg-1) TODO therion (5.4.3ds1-4) TODO qgis(2.18.28+dfsg-2) TODO Kind Regards, Bas -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: GDAL 2.2.4
Thanks Bas, Indeed Even said that we will not neet a transition this time. Best, Angelos On Fri, Mar 23, 2018 at 4:37 PM, Sebastiaan Couwenberg <sebas...@xs4all.nl> wrote: > GDAL 2.2.4 has been released, and unlike previous releases the virtual > ABI dependency was not bumped, and so no transition is required this time. > > The diff looked sane enough, and no symbols changes occurred, so I was > willing to try not requiring a transition for this GDAL release. I had > initially planned to try that starting with GDAL 2.3.0 to have a nice > round ABI dependency, but alas. > > Kind Regards, > > Bas > > -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos
Re: pycsw 2.2.0
Only one reason: that is the official release :) On Thu, Mar 22, 2018 at 11:10 AM, Johan Van de Wauw < johan.vandew...@gmail.com> wrote: > Angelos, > > We currently use the tarball at download.osgeo.org as the source for the > package. I noticed there is a different tarball on github. This seems to > suit us better as this does not contain prebuilt documentation. Is there a > good reason to keep the version from download.osgeo.org? > > Kind Regards, > Johan > > On Wed, Mar 21, 2018 at 2:38 PM, Angelos Tzotsos <gcpp.kal...@gmail.com> > wrote: > >> +1 >> I am in Bonn and I can find time to do that too. >> >> Best, >> Angelos >> >> On Tue, Mar 20, 2018 at 8:14 PM, Johan Van de Wauw < >> johan.vandew...@gmail.com> wrote: >> >>> Bas, >>> >>> I will have a look on Thursday (OSGeo codesprint). >>> >>> Kind Regards, >>> Johan >>> >>> On Tue, Mar 20, 2018 at 6:44 PM, Sebastiaan Couwenberg < >>> sebas...@xs4all.nl> wrote: >>> >>>> Hi Johan & Angelos, >>>> >>>> Seeing that pycsw 2.2.2 has been released, does either of you have time >>>> to update the package? >>>> >>>> Kind Regards, >>>> >>>> Bas >>>> >>>> -- >>>> GPG Key ID: 4096R/6750F10AE88D4AF1 >>>> Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 >>>> >>> >>> >> >> >> -- >> Angelos Tzotsos, PhD >> OSGeo Charter Member >> http://users.ntua.gr/tzotsos >> > > -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos
Re: pycsw 2.2.0
+1 I am in Bonn and I can find time to do that too. Best, Angelos On Tue, Mar 20, 2018 at 8:14 PM, Johan Van de Wauw < johan.vandew...@gmail.com> wrote: > Bas, > > I will have a look on Thursday (OSGeo codesprint). > > Kind Regards, > Johan > > On Tue, Mar 20, 2018 at 6:44 PM, Sebastiaan Couwenberg <sebas...@xs4all.nl > > wrote: > >> Hi Johan & Angelos, >> >> Seeing that pycsw 2.2.2 has been released, does either of you have time >> to update the package? >> >> Kind Regards, >> >> Bas >> >> -- >> GPG Key ID: 4096R/6750F10AE88D4AF1 >> Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 >> > > -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos
Re: Membership of the debian-gis-team on Salsa (Was: salsa.debian.org (git.debian.org replacement) going into beta)
u want to take part in salsa administration please get in touch with us. We want to have at least two more administrators for the Gitlab instance. Thanks for your attention Alex on behalf of the salsa team [1] https://salsa.debian.org/salsa/support [2] https://wiki.debian.org/Salsa/Doc [3] https://docs.gitlab.com/ee/README.html -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: GDAL 2.2.3
Thanks for the update Bas! On 11/24/2017 12:06 AM, Sebastiaan Couwenberg wrote: GDAL 2.2.3 has been released, but we cannot start preparing the transition until GRASS 7.4.0 has been released and moved from experimental to unstable. The most recent gdal upload still hasn't migrated to testing (after one month) due to the mariadb-10.1 mess, but that should finally be fixed starting today. So gdal, grass, and the many other reverse dependencies of mariadb-10.1 should finally migrate to testing in about two days. We need this fix in testing before we can think about the gdal transition. Hopefully the GRASS 7.4.0 final release is soon, so that we can make room in experimental for libgdal-grass (2.3.0) where it will reside until we get the go-ahead for the transition. Kind Regards, Bas -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: OSSIM 2.2.0
Thank you Bas for the detailed information. Best, Angelos On Thu, Aug 24, 2017 at 8:17 PM, Sebastiaan Couwenberg <sebas...@xs4all.nl> wrote: > OSSIM has finally published a new release, but unfortunately in its > currently form it's unsuitable for inclusion in Debian. > > The most problematic issue the embedded copy of libjsoncpp without an > option to build with the system provided library. [0] > > The library and the apps cannot be built in the same process any more, > requiring the library to be available before the apps can be built > (required at configure). [1] I've disabled building of the apps for now, > meaning that ossim-core will no longer be provided. > > Finally the changes between 1.8.20-3 and 2.2.0 imply that the license > was changed from MIT to LGPL, but this is not properly reflected in the > source. [2] > > Until these issues are resolved the ossim package cannot be updated to 2.x. > > The new ossim release is required for GEOS 3.6, so when osm2pgsql 4.x is > available and OSSIM 2.x still suffers from these issues I'm likely to > remove OSSIM from Debian and OTB along with it. For the sake of the > latter I'd rather not have to take this route, but I don't have a lot of > faith left in the OSSIM project. > > If you care about OSSIM and/or OTB in Debian, please help resolve these > issues in OSSIM. > > [0] https://github.com/ossimlabs/ossim/issues/115 > [1] https://github.com/ossimlabs/ossim/issues/114 > [2] https://github.com/ossimlabs/ossim/issues/113 > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > > -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos
Re: pycsw 2.0.3
Done. On 06/03/2017 06:35 PM, Angelos Tzotsos wrote: On 06/03/2017 11:28 AM, Sebastiaan Couwenberg wrote: Hi Johan & Angelos, Seeing that pycsw 2.0.3 has been released, will either of you update the package? Kind Regards, Bas Hi Bas, I will try to update the following days. Best, Angelos -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: pycsw 2.0.3
On 06/03/2017 11:28 AM, Sebastiaan Couwenberg wrote: Hi Johan & Angelos, Seeing that pycsw 2.0.3 has been released, will either of you update the package? Kind Regards, Bas Hi Bas, I will try to update the following days. Best, Angelos -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos
Re: pycsw 2.0.2
On 10/18/2016 08:12 PM, Sebastiaan Couwenberg wrote: Hi Johan & Angelos, Seeing that pycsw 2.0.2 has been released, will either of you update the package or shall I? Kind Regards, Bas Hi Bas, pycsw 2.0.2 has been updated. Best, Angelos -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos
Re: pycsw 2.0.1
On 09/17/2016 07:54 PM, Sebastiaan Couwenberg wrote: Hi Angelos, On 09/13/2016 11:17 AM, Sebastiaan Couwenberg wrote: On 09/12/2016 02:45 PM, Sebastiaan Couwenberg wrote: On 09/12/2016 10:42 AM, Angelos Tzotsos wrote: On 09/12/2016 11:08 AM, Sebastiaan Couwenberg wrote: On 09/09/2016 10:34 AM, Angelos Tzotsos wrote: On 09/09/2016 11:32 AM, Sebastiaan Couwenberg wrote: Hi Johan & Angelos, Seeing that pycsw 2.0.1 has been released, will either of you update the package before the end of the weekend or shall I? The changes are trivial, so I'd rather not wait to update the package to the latest upstream release. I will update the package this weekend. Seeing that pycsw hasn't been updated yet, shall I update the package after all? Busy weekend, will update it now. Thanks for your work on pycsw. I've push a few changes to document the patch removal and to refresh the remaining patches. Quite a few tests fail, that may warrant investigation. If you're happy with the package, please set the distribution in the changelog to unstable, and I will sponsor the upload. Or Johan can do it if he has time (please let me know if you'll upload it). The test failures seem to be caused by not having network in the cowbuilder chroots to conform with the Debian Policy which disallows targets in debian/rules from relying on network access. We should find a more gentle way to skip tests that rely on network access for the Debian package other than renaming the XML files to have them skipped. Maybe limit the suites to those that don't rely on external services? Do you have any suggestions? I've finalized the package and uploaded it to unstable. Let's look at improving the tests for the offline case when you have more time. Kind Regards, Bas Thank you Bas for finalizing the package. The online tests are valuable to test harvesting functionality. Since having online tests is against the Debian Policy, I think renaming them in order to be skipped is ok for now. Best regards, Angelos -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos
Re: pycsw 2.0.1
On 09/09/2016 11:32 AM, Sebastiaan Couwenberg wrote: Hi Johan & Angelos, Seeing that pycsw 2.0.1 has been released, will either of you update the package before the end of the weekend or shall I? The changes are trivial, so I'd rather not wait to update the package to the latest upstream release. Kind Regards, Bas Hi Bas, I will update the package this weekend. Best regards, Angelos -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos
Re: pycsw 2.0.0 - proposed package restructuring
Hi Bas, Thanks for promoting the release :) yes, I agree with the plan, sounds good. Best, Angelos On 07/12/2016 12:12 AM, Sebastiaan Couwenberg wrote: pycsw 2.0.0 is out, and the packaging has been updated and uploaded to experimental to replace RC1. With 2.0.0 being a major new release, now is good time to do some restructuring of the package that is more disruptive. I propose to remodel it to resemble the pywps packaging more. Have a pycsw binary package that contains the pycsw-admin executable and manpage, and have it depend on the python-pycsw package for the Python module, and on pycsw-wsgi for the the web services. The -doc package will likewise be renamed to drop the python- prefix. This restructuring makes the pywps the main package instead of python-pywps which will become a simple module package without an executable, and `apt-get install pycsw` should get you a working pycsw setup via the dependencies. In support of the move to Python 3 [0], pycsw should also be built for Python 3 to at least provide the module via python3-pycsw, and ideally to use Python 3 for the main pycsw & pycsw-wsgi packages too. In the Python Policy, the move to Python 3 only contains "should" requirements, so we don't have to switch pycsw to Python 3 yet, although that's strongly encouraged via the Policy. An overview of the proposed restructuring is below, showing what's installed by the packages and their dependencies. Johan & Angelos, what do you think of this proposal? - Package: pycsw Install: etc/pycsw/* usr/bin/pycsw-admin usr/share/man/man1/pycsw-admin.1.gz Depends: pycsw-wsgi, python-pycsw Suggests: pycsw-doc - Package: pycsw-doc Install: usr/share/doc/pycsw-doc/* - Package: pycsw-wsgi Install: etc/apache2/sites-available/pycsw.conf usr/share/pycsw/csw.py usr/share/pycsw/wsgi.py usr/share/pycsw/tests/* Depends: python-pycsw - Package: python-pycsw Install: usr/lib/python2* - Package: python3-pycsw Install: usr/lib/python3* [0] https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html Kind Regards, Bas -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos
Re: packaging pycsw
On 10/31/2015 10:41 PM, Sebastiaan Couwenberg wrote: On 27-06-15 14:47, Angelos Tzotsos wrote: On 06/27/2015 03:41 PM, Sebastiaan Couwenberg wrote: While looking into the new PyCSW point release, I noticed that it changed the OWSlib requirement to <0.9.0. Since we have OWSlib 0.9.0 in unstable, this could mean that we're unable to update the pycsw package. Is this a correct assessment? We found out that under specific circumstances, OWSLib 0.9.0 breaks some of our unit tests. We are still investigating this, and we will fix in a future release. Some time has passed, and now PyCSW 1.10.3 is out but still requires OWSLib < 0.9.0, so I guess that issue still hasn't been resolved or can we finally update the pycsw package again? Kind Regards, Bas Hi Bas, I have just updated the pycsw package in OSGeoLive ppa. I would like to take this opportunity to finally learn the process to maintain the package in Debian... I will clone the Debian git repository and read the documentation. Questions might follow ;) Best regards, Angelos -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos
Re: Johan is DM
Congratulations Johan! On Tue, Aug 18, 2015 at 6:43 PM, Ross Gammon r...@the-gammons.net wrote: On 08/18/2015 02:29 PM, Johan Van de Wauw wrote: Hi all, My key was added to the keyring last month, so I'm a debian maintainer now. The flag has not been set on any package yet, but if you are a DD feel free to add any of the packages for which I'm an uploader [1]. Python-cligj is ready for upload (and one of the few packages that can build on sid now), so that might be a good first candidate. Kind Regards, Johan [1] https://qa.debian.org/developer.php?login=johan.vandewauw%40gmail.com Yay! Congratulations. -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos
Re: packaging pycsw
Hi Bas, We found out that under specific circumstances, OWSLib 0.9.0 breaks some of our unit tests. We are still investigating this, and we will fix in a future release. Best, Angelos On 06/27/2015 03:41 PM, Sebastiaan Couwenberg wrote: While looking into the new PyCSW point release, I noticed that it changed the OWSlib requirement to 0.9.0. Since we have OWSlib 0.9.0 in unstable, this could mean that we're unable to update the pycsw package. Is this a correct assessment? Kind Regards, Bas -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To UNSUBSCRIBE, email to debian-gis-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558e9b7a.5010...@gmail.com
Re: Sponsoring of Debian GIS packages (revisited)
On 02/03/2015 09:39 PM, Sebastiaan Couwenberg wrote: Hi all, To follow up on an earlier thread about sponsoring of Debian GIS packages, I can share some good news today. A few hours ago I got an email from Peter Palfrader informing me that he upgraded my existing account. While nm.d.o hasn't marked my process as Completed yet, that seems a minor technicality. This means the team has gained another sponsor to relieve some of burden on Andreas. :-) If you need a sponsor for packages included in the Debian GIS Blend please include pkg-grass-de...@lists.alioth.debian.org in the CC of your RFS as documented in the policy [1], it should hit my radar if you do. I'll need a little time to formalize my sponsorship guidelines, but it won't be anything shocking, and along the lines of those used by other DDs. This message is mostly meant to inform your that another DD is available in the team for sponsoring. Kind Regards, Bas [1] http://pkg-grass.alioth.debian.org/policy/packaging.html#sponsorship Congratulations Bas! Great news :) -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To UNSUBSCRIBE, email to debian-gis-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54d20cad.8010...@gmail.com
Re: Packaging GRASS 7
Hi Bas, On 01/11/2015 01:18 AM, Sebastiaan Couwenberg wrote: The OSGeo Live team already includes the grass70 packages, but the issue tracking it [2] doesn't have any information about breakage yet. I agree with your proposed strategy. I consider the upcoming OSGeoLive 8.5 release as a very good opportunity to get feedback for GRASS 6.4 to 7.0 switch. The ticket has been updated to reflect current status. Since grass70 packaging was done in a way to not conflict with grass64, the upgrade process was easy, only the qgis-grass plugin was removed from the Live. Best, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To UNSUBSCRIBE, email to debian-gis-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b27725.7040...@gmail.com
Re: pycsw - precompiled docs
Hi Johan, Thanks for the review, +1 Angelos On 10/08/2014 07:23 PM, Johan Van de Wauw wrote: Angelos, I just thought about this a bit more. We must remove the docs now because it contains some google analytics code which is not free software. If in a next release the docs are build without google analytics I think we can do without repackaging. Johan On Wed, Oct 8, 2014 at 1:04 PM, Johan Van de Wauw johan.vandew...@gmail.com wrote: On Wed, Oct 8, 2014 at 12:43 PM, Angelos Tzotsos gcpp.kal...@gmail.com wrote: Hi Johan, Thanks for your effort, it is really appreciated. The docs inside the package are there as a reference to the users. If this conflicts with Debian policy or something then I am ok removing them. For the enduser the difference is small since they can have the documentation as built in debian. I'm in favor of keeping it inside the source package also, but I'm not sure about the policy. I'll ask on debian mentors as well. Regarding cgi, this was added as a fast way to have pycsw working for OSGeoLive. I have WSGI package also in my todo list and actually I would prefer this solution since it is safer and faster. Ok, I'll switch to WSGI then. It is actually not more work than cgi. Just setting WSGIScriptAlias in the conffile and adding the right dependency (libapache2-mod-wsgi). The only advantage of cgi over wsgi that I see is that people could use other webservers than apache, but then again, they would have to configure it themselves. Johan -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To UNSUBSCRIBE, email to debian-gis-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5435917f.8080...@gmail.com
Re: [Live-demo] Let's bring the OSGeo live packages to debian!
Hi Johan, On Wed, Sep 10, 2014 at 10:48 PM, Johan Van de Wauw johan.vandew...@gmail.com wrote: Hello everyone, One of the goals for OSGeo live 8 was having more programs packaged as deb files. Although we are still far from installing everything from deb at least some programs were packaged, and this actually helped the build process a lot. With OSGeo live version 8 released, perhaps now is a good time to make sure those packages get into debian as well. +1. I already plan to upload all the packages I did initially to UbuntuGIS. The steps that you need to do are well documented in the packaging pages of the debian GIS policy [1]. I'd suggest that everyone who currently has a package or wants to build a package at least does the first step: filing an ITP bug. This is just a way to make sure that nobody else starts doing the same thing without contacting you. Debian freeze is approaching (5th of november), so better no procrastination, or your package will not be in the next release :-) Thanks for the heads up. So for those of you sitting at a boring talk at foss4g or cannot sleep after having had many great talks: start bringing packages to debian :-) :) Johan [1] http://pkg-grass.alioth.debian.org/policy/packaging.html ___ Live-demo mailing list live-d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/live-demo http://live.osgeo.org http://wiki.osgeo.org/wiki/Live_GIS_Disc -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos
