libspatialindex 2.0.0
libspatialindex has released a bunch of betas for the 2.0.0. And the SONAME bump requires a transition. We might get away with requesting binNMUs for the two rdeps as both spatialindex and python-rtree have very few rdeps. Only python-rtee required a patch to not FTBFS with the new version. Transition: spatialindex libspatialindex6 (1.9.3-3+b1) -> libspatialindex7 (2.0.0~b4-1~exp1) libspatialindex-c6 (1.9.3-3+b1) -> libspatialindex-c7 (2.0.0~b4-1~exp1) The status of the most recent rebuilds is as follows. minetest (5.8.0+dfsg+~1.9.0mt13-1) OK python-rtree (1.2.0-2) OK qgis (3.34.7+dfsg-1) OK Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: ITP: cdsetool -- Tools & CLI for interacting with CDSE product APIs
On 5/26/24 8:12 PM, Antonio Valentino wrote: Could you please proceed with the review and upload? Where is the license for tests/query/mock/sentinel_1/describe.xml recorded? The file itself contains All Rights Reserved in its attribution which disallows modification amongst others unless the applicable license grants it. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: ITP: cdsetool -- Tools & CLI for interacting with CDSE product APIs
On 5/26/24 7:51 PM, Antonio Valentino wrote: could you please create a repository for the package in subject? https://salsa.debian.org/debian-gis-team/cdsetool
Re: e-foto - Photogrametric workstation
Looks like useful software, but not a very healthy project with no activity for a year. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Packaging issue for ogdi
On 4/28/24 11:11 AM, Even Rouault wrote: Thanks for addressing this This is fixed in ogdi-dfsg (4.1.1+ds-4) which I just uploaded to unstable. An SRU [0] is required to fix this in Ubuntu noble, can you drive that? Because the package is in the universe component it is effectively unmaintained in Ubuntu. Hum I've skimmed through this document, but that looks rather intimidating for the un-initiated like me... For example "4. Procedure" : 1) "Check that the bug is fixed in the current development release, and that its bug task is "Fix Released".". current-development release = Debian or Ubuntu ? Ubuntu. But there is no development release yet for the "O" codename to follow noble. What does "bug task" refer to here ? Is it a new bug report that should be created in launchpad as mentioned in 2. Or should there bug 2 different bug reports: one for the fix, and for the SRU ? I'm confused... Your initial post to this list should be filed in Launchpad as a bug: https://bugs.launchpad.net/ubuntu/+source/ogdi-dfsg That bugreport can then be marked as fixed in ogdi-dfsg (4.1.1+ds-4) for the development release once "obese" (or whatever their next release codename will be) has synced the package from Debian unstable. A separate bugreport for the SRU will be required with the proposed debdiff for the packaging changes. You can get that by cherry-picking the fix from Debian on top of the current version in noble, e.g. dget -u https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/ogdi-dfsg/4.1.1+ds-3build1/ogdi-dfsg_4.1.1+ds-3build1.dsc cd ogdi-dfsg-4.1.1+ds/ wget https://salsa.debian.org/debian-gis-team/ogdi-dfsg/-/commit/bd47d6548f066cb5237d82735a2ce4b58caf595d.patch -O /tmp/multiarch.patch patch -p1 < /tmp/multiarch.patch rm debian/changelog.* dch -D noble -i "Fix Multi-Arch MODULES_PATH. (LP: #)" pdebuild --pbuilder cowbuilder -- --basepath /var/cache/pbuilder/base-noble.cow debdiff > /tmp/ogdi-dfsg.debdiff 4) " attach a debdiff to the bug". I suppose that would be the patch of https://salsa.debian.org/debian-gis-team/ogdi-dfsg/-/commit/bd47d6548f066cb5237d82735a2ce4b58caf595d ? "The upload must have the correct /release/ in the changelog header": is that the "ogdi-dfsg (4.1.1+ds-4)" of your patch, or should that be modified to be I assume 4.1.1+ds-3build2 seeing it is 4.1.1+ds-3build1 currently in https://packages.ubuntu.com/source/noble/ogdi-dfsg | I'm not sure what the version scheme for Ubuntu is. In Debian we use `dch --stable` to append +deb12u1 to the version, but Ubuntu doesn't use that. If you want to get this issue fixed in Ubuntu, you should at least file the bugreport in Launchpad, you can then delegate the rest of the work to Ubuntu people. But as mentioned before, because the package is in universe and thereby effectively unmaintained, Ubuntu people are unlikely to act on the bugreport to get the issue fixed in the noble release. Perhaps Angelos Tzotsos could help with the Ubuntu packaging, he has experience with that thanks to his work on OSGeo-Live and UbuntuGIS. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Packaging issue for ogdi
On 4/28/24 6:34 AM, Sebastiaan Couwenberg wrote: This is fixed in ogdi-dfsg (4.1.1+ds-4) which I just uploaded to unstable. I've also added an autopkgtest to verify that ogdi_info works: https://salsa.debian.org/debian-gis-team/ogdi-dfsg/-/jobs/5652707 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Packaging issue for ogdi
On 4/27/24 9:27 PM, Even Rouault wrote:
ln -s /usr/lib/x86_64-linux-gnu/ogdi/4.1/libvrf.so
/usr/lib/x86_64-linux-gnu
A very ugly hack.
==> There is an inversion in the path components between lib and
${DEB_HOST_MULTIARCH}. It should be
-DMODULES_PATH="\"/usr/lib/${DEB_HOST_MULTIARCH}/ogdi/4.1/\""
Good catch. I did not when applying the Yuriy's patch in
https://salsa.debian.org/debian-gis-team/ogdi-dfsg/-/commit/bcf29eb28b0a25b2f6204f253fa0efc040d4a5f4
This is fixed in ogdi-dfsg (4.1.1+ds-4) which I just uploaded to
unstable. An SRU [0] is required to fix this in Ubuntu noble, can you
drive that? Because the package is in the universe component it is
effectively unmaintained in Ubuntu.
[0] https://wiki.ubuntu.com/StableReleaseUpdates
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
GDAL 3.9.0
The first beta for GDAL 3.9.0 has been released. The SONAME bump requires a transition, for which most rdeps built successfully as summarized below. Only rasterio actually failed due to changes in GDAL, ncl was unrelated, and python-django and facet-analyser have old RC issues. ncl (6.6.2.dfsg.1-6) FTBFS due to missing executables caued by link failures. (#1069845) python-django (3:4.2.11-1) FTBFS due to unrelated test failures. (#1042637) rasterio (1.3.10-1) FTBFS due to test failures. (#1069868) facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) FTBFS due to uninstallable build dependencies. (#1040334) Bugreports can be found using the gdal-3.9 usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gis@lists.debian.org=gdal-3.9 Transition: gdal libgdal34t64 (3.8.5+dfsg-1) -> libgdal35 (3.9.0~beta1+dfsg-1~exp1) The status of the most recent rebuilds is as follows. cloudcompare(2.11.3-7.1) OK fiona (1.9.6-1) OK gmt (6.5.0+dfsg-3)OK grass (8.3.2-1) OK libcitygml (2.5.2-1) OK libgeo-gdal-ffi-perl(0.11-2) OK libosmium (2.20.0-1)OK mapcache(1.14.0-4)OK mapnik (3.1.0+ds-7) OK mapproxy(2.0.2+dfsg-1)OK mapserver (8.0.1-4) OK merkaartor (0.19.0+ds-5) OK mysql-workbench (8.0.32+dfsg-2) OK ncl (6.6.2.dfsg.1-6) FTBFS (#1069845) octave-mapping (1.4.2-3) OK openorienteering-mapper (0.9.5-3.1) OK openscenegraph (3.6.5+dfsg1-8) OK paraview(5.11.2+dfsg-6) OK pgsql-ogr-fdw (1.1.4-3) OK pktools (2.6.7.6+ds-6)OK postgis (3.4.2+dfsg-1)OK python-django (3:4.2.11-1) FTBFS (#1042637) qmapshack (1.17.1-1)OK r-cran-sf (1.0-15+dfsg-1) OK r-cran-terra(1.7-65-1)OK rasterio(1.3.10-1)FTBFS (#1069868) saga(9.4.0+dfsg-1)OK vtk9(9.1.0+really9.1.0+dfsg2-7.1) OK facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) FTBFS (#1040334) libgdal-grass (1:1.0.2-7) OK opencv (4.6.0+dfsg-13.1) OK osmcoastline(2.4.0-2) OK qgis(3.34.6+dfsg-1) OK sumo(1.18.0+dfsg-3) OK Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Mapnik 4.0.0
The first release candidate for Mapnik 4.0.0 has been released. It's almost like upstream can sense when I consider the lack of new upstream releases reason enough to remove mapnik and its rdeps from Debian, so they throw us a bone to delay the inevitable. CMake is now also supported alongside SCons which makes the packaging much simpler. The switch to CMake does break most rdeps because they rely on mapnik-config which is only built when using SCons. Patching those to use pkg-config instead was easy enough. Only libapache2-mod-tile already had support for Mapnik 4.x, everything else required patches as summarized below. The new major version was also a good time to stop diverging from upstream and include the full version in the SONAME instead of only major and minor. This does require going through NEW for every new upstream release like QGIS, and rebuilds of the rdeps. That's not great, but inherent to the unstable ABI. The switch to CMake also uses the Multi-Arch path for the libraries by default, which is nice. Mapnik 4.0.0 has two new dependencies: mapbox-geometry & mapbox-polylabel. The former was used by node-mapnik via mapnik-vector-tile in the past, and was removed from the archive along with node-mapnik. The mapbox-geometry package was reintroduced for Mapnik 4.0.0, and mapbox-polylabel was packaged as well. Only the C++ header-only library is required for Mapnik so no binary package is provided for the Javascript library. Bugreports with patches can be found using the mapnik-4.0 usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gis@lists.debian.org=mapnik-4.0 Supporting both Mapnik 3.x & Mapnik 4.0 was too much of a PITA, so the patches all require Mapnik 4.0. Applying them will need to wait at least until mapnik 4.0.0 has passed NEW. python-mapnik (1:0.0~20200224-7da019cf9-5) FTBFS due to mapnik-config removal in favor of pkg-config. tirex (0.7.1-1) FTBFS due to mapnik-config removal in favor of pkg-config. viking (1.10-2) FTBFS due to mapnik/map.hpp include check failure (doesn't use C++14). Transition: mapnik libmapnik3.1t64 (3.1.0+ds-7+b2) -> libmapnik4.0.0 (4.0.0~rc1+ds-1~exp1) The status of the most recent rebuilds is as follows. libapache2-mod-tile (0.7.1-1)OK python-mapnik (1:0.0~20200224-7da019cf9-5) FTBFS (#1069130) tirex (0.7.1-1)FTBFS (#1069109) viking (1.10-2) FTBFS (#1069105) Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
HDF 4.3.0
HDF 4.3.0 has been released which no longer installs several private headers and stops exporting private symbols, see: https://github.com/HDFGroup/hdf4/blob/hdf4.3.0/doc/HDF-4.2-to-4.3-migration.md The new release does not bump the SONAME, despite these potentially breaking changes. The find out whether we can move HDF 4.3.0 without breaking too many rdeps, I did a round of rebuilds which revealed that 7 of 14 rdeps FTBFS although only 3 due to these changes in HDF 4.3.0. -Werror=implicit-function-declaration is the most common FTBFS cause. I've requested the removal of librsl because it's RC buggy since 2018 with no activity of its maintainer since 2014. Let's not waste time on this package in the future. Our only affected package is python-hdf4, which already has a patch in git. Two other packages have patches in the BTS, see: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gis@lists.debian.org=hdf-4.3 Since there were no major blockers, I'll move the package to unstable soon. I'll wait for the experimental build on riscv64 and and give debci a chance to run its jobs for the rdeps with the package from experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: GDAL and GeoParquet in Debian
On 3/29/24 10:00 AM, Richard Duivenvoorde wrote: [0] https://gdal.org/drivers/vector/parquet.html " Build dependencies Parquet component of the Apache Arrow C++ library " That's not in Debian yet: https://bugs.debian.org/970021 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: librttopo lacks the PROJ dependency
On 3/25/24 12:26 AM, Even Rouault wrote: Hum, actually digging further, the root issue is that librttopo's configure.ac has no provision to build against PROJ. OK, so this is an upstream issue actually. Just filed at https://git.osgeo.org/gitea/rttopo/librttopo/issues/44 This is quite common. geojson support is likewise missing: https://git.osgeo.org/gitea/rttopo/librttopo/issues/21#issuecomment-8877 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Application to join Debian GIS Team
On 1/26/24 14:21, Amanda McCann wrote: I'd like to join the Debian GIS team, to help with packaging of OpenStreetMap related software in Debian/Ubuntu. My day job at Geofabrik involves maintaining much of this software in production use (e.g. mod_tile, tile servers etc.). Our approach has worked well, but can be a little non-portable. I would like to contribute back to Debian/FLOSS by ensuring the relevant geo/OSM software easily installed & recent in Debian/Ubuntu. Specifically, I want to improve tirex, mod_tile and other web tile rendering packages. Additional hands to help maintain the tirex & libapache-mod-tile packages is certainly welcome. It looks like Felix doesn't have enough time for these packages these days. I'm not a Debian Developer. I've been using Ubuntu (and lately) Debian for ~20 years. However, I am new to proper Debian packaging, and I have a lot to learn. I am always open to tips & help. I have been using bash scripts for a long time. I know my way around that. My debian salsa account is amandasaurus: https://salsa.debian.org/amandasaurus I've added you to the team. Be aware that Salsa is undergoing maintenance and is a bit flaky today. Is there anything more you need from me? Please familiarize yourself with the team conventions as documented in the team policy, and ensure you're subscribed to both mailinglists: https://debian-gis-team.pages.debian.net/ Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Your Salsa membership request for tirex
Please join the team as documented in our team policy: https://debian-gis-team.pages.debian.net/policy/index.html#membership Also note the git packaging workflow: https://debian-gis-team.pages.debian.net/policy/packaging.html#git-packaging Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Fwd: Bug#1058954: Acknowledgement (libjpeg-dev: New upstream version libjpegturbo 3.0.1 available)
On 1/16/24 17:10, Even Rouault wrote: Do you know what holds the below request to update libjpeg to libjpeguturbo 3.0.1 ? (presumably lack of maintainer time?). That would help unvendoring libjpeg from GDAL. Lack of time is a likely cause, I can only speculate. The package is not team maintained, Ondřej Surý is listed as Maintainer but hasn't uploaded the package since 2017. Mike Gabriel has done most of the uploads since. See: https://tracker.debian.org/pkg/libjpeg-turbo His GPG key was used to upload packages this month, so he doesn't seem to be MIA or otherwise inactive. See: https://contributors.debian.org/contributor/sunweaver/ Try contacting Mike directly. Doing the work to update the package in your fork of the repo and testing the reverse dependencies is also an option if you're willing to invest this heavily in the package. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Shapelib 1.6.0
The first release candidate for Shapelib 1.6.0 has been released. A transition is required due to the SONAME bump. All rdeps built successfully as summarized below. Transition: shapelib libshp2 (1.5.0-3+b1) -> libshp4 (1.6.0~rc1-1~exp1) The status of the most recent rebuilds is as follows. cyrus-imapd (3.8.1-1) OK glgrib (1.0-3) OK gpsbabel (1.9.0+ds-2)OK gpsmanshp(1.2.3-6) OK grads(3:2.2.1-5) OK libgeo-shapelib-perl (0.22-6)OK libterralib (4.3.0+dfsg.2-12.1) OK marble (4:22.12.3-2) OK plplot (5.15.0+dfsg2-6)OK therion (6.1.8-2) OK tilemaker(2.4.0-1) OK gnudatalanguage (1.0.3-1) OK scamp(2.10.0-2) OK xastir (2.2.0-1) OK Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Osmosis 0.49.1
osmosis (0.49.1-1~exp1) has a patch which adds support for Maven. The plexus based launcher from prior releases has been reintroduced as I didn't find a good alternative to the Gradle application plugin. We'll get to keep osmosis in Debian a little longer. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Osmosis 0.49.1
The latest Osmosis upstream release uses gradle 8.1.1 which causes the package build to fail because gradle in Debian is stuck at 4.4.1 due to extreme difficulty updating it. It has been suggested to use an alternative build system like Maven for the Debian package builds [0], this may be an option to keep the osmosis package in Debian. I have very little experience with authoring pom.xml files, so this won't be easy or done quickly. I don't really like the idea of maintaining a separate build system without upstream support, so perhaps we should consider Osmosis unmaintainable in Debian and removing the package. On the other hand, Osmosis is in maintenance mode, and its infrequent release don't create a heavy maintenance burden. Updating the Maven build system every once in a while might be very doable. Help from more experienced Java developers to get osmosis to build with Maven is greatly appreciated. [0] https://lists.debian.org/debian-java/2022/08/msg00010.html Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: GDAL 3.8.0
On 11/8/23 20:02, Sebastiaan Couwenberg wrote: Most of the build failures have the same cause: This is fixed in gdal (3.8.0~rc1+dfsg-1~exp2), which leaves just four FTBFS issues of which three are caused by GDAL: Transition: gdal libgdal33 (3.7.3+dfsg-1) -> libgdal34 (3.8.0~rc1+dfsg-1~exp2) The status of the most recent rebuilds is as follows. cloudcompare(2.11.3-7.1) OK fiona (1.9.5-1) OK gmt (6.4.0+dfsg-2)OK grass (8.3.1-1) OK libcitygml (2.5.1-1) OK libgeo-gdal-ffi-perl(0.1-2) FTBFS (#1055581) libosmium (2.20.0-1)OK mapcache(1.14.0-2)OK mapnik (3.1.0+ds-4) OK mapproxy(1.16.0+dfsg-1) OK mapserver (8.0.1-2) OK merkaartor (0.19.0+ds-4) OK mysql-workbench (8.0.32+dfsg-1) FTBFS (#1051433) ncl (6.6.2.dfsg.1-2) OK octave-mapping (1.4.2-3) OK openorienteering-mapper (0.9.5-3.1) OK openscenegraph (3.6.5+dfsg1-8) OK paraview(5.11.0+dfsg-2) OK pgsql-ogr-fdw (1.1.4-3) OK pktools (2.6.7.6+ds-4)OK postgis (3.4.0+dfsg-3)OK python-django (3:4.2.6-1) OK qmapshack (1.17.0-1)OK r-cran-rgdal(1.6-7+dfsg-1)OK r-cran-sf (1.0-14+dfsg-1) OK r-cran-terra(1.7-55-1)OK rasterio(1.3.9-1) FTBFS (#1055594) saga(9.2.0+dfsg-1)OK vtk9(9.1.0+really9.1.0+dfsg2-7) OK facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) BD-UNINST libgdal-grass (1:1.0.2-6) OK opencv (4.6.0+dfsg-13) OK osmcoastline(2.4.0-2) OK qgis(3.28.12+dfsg-1) OK sumo(1.18.0+dfsg-3) OK Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
GDAL 3.8.0
The first release candidate for GDAL 3.8.0 has been released. Most of the build failures have the same cause: In file included from /usr/include/gdal/ogr_geometry.h:36, from /build/osmcoastline-2.4.0/src/coastline_polygons.hpp:25, from /build/osmcoastline-2.4.0/src/coastline_ring_collection.cpp:22: /usr/include/gdal/cpl_json.h:97:36: error: expected ')' before 'nVal' 97 | explicit CPLJSONObject(uint64_t nVal); | ~^ |) /usr/include/gdal/cpl_json.h:119:41: error: 'uint64_t' has not been declared 119 | void Add(const std::string , uint64_t nValue); | ^~~~ /usr/include/gdal/cpl_json.h:119:10: error: 'void CPLJSONObject::Add(const std::string&, int)' cannot be overloaded with 'void CPLJSONObject::Add(const std::string&, int)' 119 | void Add(const std::string , uint64_t nValue); | ^~~ /usr/include/gdal/cpl_json.h:117:10: note: previous declaration 'void CPLJSONObject::Add(const std::string&, int)' 117 | void Add(const std::string , int nValue); | ^~~ /usr/include/gdal/cpl_json.h:131:41: error: 'uint64_t' has not been declared 131 | void Set(const std::string , uint64_t nValue); | ^~~~ /usr/include/gdal/cpl_json.h:131:10: error: 'void CPLJSONObject::Set(const std::string&, int)' cannot be overloaded with 'void CPLJSONObject::Set(const std::string&, int)' 131 | void Set(const std::string , uint64_t nValue); | ^~~ /usr/include/gdal/cpl_json.h:129:10: note: previous declaration 'void CPLJSONObject::Set(const std::string&, int)' 129 | void Set(const std::string , int nValue); | ^~~ /usr/include/gdal/cpl_json.h:245:14: error: 'uint64_t' has not been declared 245 | void Add(uint64_t nValue); | ^~~~ /usr/include/gdal/cpl_json.h:245:10: error: 'void CPLJSONArray::Add(int)' cannot be overloaded with 'void CPLJSONArray::Add(int)' 245 | void Add(uint64_t nValue); | ^~~ /usr/include/gdal/cpl_json.h:243:10: note: previous declaration 'void CPLJSONArray::Add(int)' 243 | void Add(int nValue); | ^~~ Fixing this will resolves most blockers. libgeo-gdal-ffi-perl (0.1-2) FTBFS due to test failures. (#1055581) mysql-workbench (8.0.32+dfsg-1) FTBFS due to unrelated issues. (#1051433) pktools (2.6.7.6+ds-4) FTBFS due to type errors. (#1055587) r-cran-rgdal (1.6-7+dfsg-1) FTBFS due to type errors. (#1055589) r-cran-sf (1.0-14+dfsg-1) FTBFS due to type errors. (#1055590) rasterio (1.3.9-1) FTBFS due to test failures. (#1055594) facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) cannot be built due to #1040334. libgdal-grass (1:1.0.2-6) FTBFS due to type errors. (#1055602) osmcoastline (2.4.0-2) FTBFS due to type errors. (#1055604) Bugreports: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gis@lists.debian.org=gdal-3.8 Transition: gdal libgdal33 (3.7.3+dfsg-1) -> libgdal34 (3.8.0~rc1+dfsg-1~exp1) The status of the most recent rebuilds is as follows. cloudcompare(2.11.3-7.1) OK fiona (1.9.5-1) OK gmt (6.4.0+dfsg-2)OK grass (8.3.1-1) OK libcitygml (2.5.1-1) OK libgeo-gdal-ffi-perl(0.1-2) FTBFS (#1055581) libosmium (2.20.0-1)OK mapcache(1.14.0-2)OK mapnik (3.1.0+ds-4) OK mapproxy(1.16.0+dfsg-1) OK mapserver (8.0.1-2) OK merkaartor (0.19.0+ds-4) OK mysql-workbench (8.0.32+dfsg-1) FTBFS (#1051433) ncl (6.6.2.dfsg.1-2) OK octave-mapping (1.4.2-3) OK openorienteering-mapper (0.9.5-3.1) OK openscenegraph (3.6.5+dfsg1-8) OK paraview(5.11.0+dfsg-2) OK pgsql-ogr-fdw (1.1.4-3) OK pktools (2.6.7.6+ds-4)FTBFS (#1055587) postgis (3.4.0+dfsg-3)OK python-django (3:4.2.6-1) OK qmapshack (1.17.0-1)OK r-cran-rgdal(1.6-7+dfsg-1)FTBFS (#1055589) r-cran-sf (1.0-14+dfsg-1) FTBFS (#1055590)
Re: Packaging lerc
On 11/1/21 18:52, Sebastiaan Couwenberg wrote: On 11/1/21 18:27, Antonio Valentino wrote: Why is the list of architectures restricted in debian/control? LERC does not support bigendian architectures Might be better to use Architecture: any and just have the build fail on those architectures, any new LE architectures won't need changes to the architecture list. I've recently learned about the architecture-properties package which provides architecture-is-<32|64>-bit and architecture-is--endian. Using this makes the package BD-Uninstallable on architectures which don't match the requirement. osmium-tool uses Spaten which only supports little endian, so I've added architecture-is-little-endian to its build dependencies to make this explicit. This seems like a good option for lerc too, no time will be wasted building the package on big endian architectures where it will just fail. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Collaborate GIS team
On 8/30/23 05:28, Sebastiaan Couwenberg wrote: On 8/29/23 21:53, Nilson Silva wrote: But the package is also a dependency of "Geopandas" ! https://salsa.debian.org/debian-gis-team/python-geopandas/-/blob/master/requirements-dev.txt#17 As mentioned before: " This seems to be an upstream issue, the plotting deps are only included in requirements-dev.txt not as optional dependencies in pyproject.toml. " https://lists.debian.org/debian-gis/2023/08/msg7.html Reported upstream: https://github.com/geopandas/geopandas/issues/2990 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Collaborate GIS team
On 8/29/23 21:53, Nilson Silva wrote: Hello Sebastian! Hope this message finds you well! Returning to the subject about https://salsa.debian.org/science-team/mapclassify Nilesh, who sponsored, placed the package in the care of the Science team. But the package is also a dependency of "Geopandas" ! https://salsa.debian.org/debian-gis-team/python-geopandas/-/blob/master/requirements-dev.txt#17 As mentioned before: " This seems to be an upstream issue, the plotting deps are only included in requirements-dev.txt not as optional dependencies in pyproject.toml. " https://lists.debian.org/debian-gis/2023/08/msg7.html mapclassify is only required when the plotting scheme is set. I didn't upload the update because I'm not part of the GIS team. If you want me to prepare it for someone from the team to go up later, just say so. But it would have to have access to the team namespace. Can you accept me on the team? It's not clear what you want to do. python3-mapclassify will need to be in the archive before it can be added as a (build) dependency of python-geopandas. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Collaborate GIS team
On 8/17/23 15:23, Nilson Silva wrote: I recently packaged this module: https://salsa.debian.org/science-team/mapclassify But according to DD, this module fits within the GIS team. Please maintain the package in the Science team alongside libpysal which has the same upstream. https://lists.debian.org/debian-gis/2023/08/msg7.html Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Request to join salsa
On 8/14/23 04:48, Nilesh Patra wrote: On 08/14/2023 12:10 AM IST Sebastiaan Couwenberg wrote: What is the geopandas bug? I should've been clearer. explore() is unusable without dependency on matplotlib, mapclassify and folium. This needs to be added or at least recommended. See https://salsa.debian.org/debian-gis-team/python-geopandas/-/blob/master/geopandas/explore.py#L296 This was making tests choke in another package. This seems to be an upstream issue, the plotting deps are only included in requirements-dev.txt not as optional dependencies in pyproject.toml. And why move mapclassify from the science team? It is not yet uploaded even to NEW, and the description says: | mapclassify implements a family of classification schemes for choropleth maps. Its focus is on the determination of | the number of classes, and the assignment of observations to those classes. It is intended for use with upstream mapping | and geovisualization packages (see geopandas and geoplot) that handle the rendering of the maps. This seems a much better fit for GIS. Or the Python team. But since its upstream is PySAL, the Science Team seems like a better fit for mapclassify. Did you read the team policy? https://debian-gis-team.pages.debian.net/policy/ I did. Interestingly, some people who helped draft it are the ones with whom I work on a daily basis in med and other blends teams. Have I justified enough to get added now? In general yes, but I'd rather not have mapclassify in the GIS team. Please keep that in the science team alongside libpysal. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Request to join salsa
On 8/13/23 19:56, Nilesh Patra wrote: I am Nilesh, and I'm a debian developer. I'm interested in working on some gis packages. For the starters, geopandas (wherein I found a bug). I'd also like to push mapclassify (currently in science team) to gis. What is the geopandas bug? And why move mapclassify from the science team? We are an understaffed team, so your help is welcome, unless you don't stick around to maintain the mapclassify package. Could someone kindly add me in? Did you read the team policy? https://debian-gis-team.pages.debian.net/policy/ PS: Please add me in with maintainer access, as I frequently enable salsa CI. Please clarify your intentions in the teams first. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: SpatiaLite 5.1.0
On 7/25/23 08:34, Sebastiaan Couwenberg wrote: The first release candidate for SpatiaLite 5.1.0 has been released, it requires FreeXL 2.0.0 from experimental, so hopefully that sees a final release soon. The final release of spatialite & spatialite-tools have been published. Another round of rebuilds with this version did reveal any regressions. Transition: spatialite libspatialite7 (5.0.1-3) -> libspatialite8 (5.1.0-1~exp1) The status of the most recent rebuilds is as follows. gdal (3.7.1+dfsg-1) OK librasterlite2 (1.1.0~beta1-3) OK spatialite-tools (5.0.1-2) OK merkaartor (0.19.0+ds-4) OK osmcoastline (2.4.0-2) OK qgis (3.28.9+dfsg-1) OK spatialite-gui (2.1.0~beta1-2) OK Transition bugreport: #1043045 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: OTB 8.1.0
On 8/16/22 07:45, Sebastiaan Couwenberg wrote: insighttoolkit5 won't be supported until OTB 9, so we won't be able to update the package for the time being. ITK5 support got moved to OTB 10. The otb package has therefor been removed from Debian unstable, it was the last rdep of insighttoolkit4. Once ITK5 support is available the package can be reintroduced by someone committed to maintaining the package in Debian. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
SpatiaLite 5.1.0
The first release candidate for SpatiaLite 5.1.0 has been released, it requires FreeXL 2.0.0 from experimental, so hopefully that sees a final release soon. A transition is required due to the SONAME bump. A round of rebuilds did not result in any FTBFS issues. Transition: spatialite libspatialite7 (5.0.1-3) -> libspatialite8 (5.1.0~rc0-1~exp1) The status of the most recent rebuilds is as follows. gdal (3.7.1+dfsg-1) OK librasterlite2 (1.1.0~beta1-3) OK spatialite-tools (5.0.1-2) OK merkaartor (0.19.0+ds-3) OK osmcoastline (2.4.0-2) OK qgis (3.28.9+dfsg-1) OK spatialite-gui (2.1.0~beta1-2) OK Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Proposal for the inclusion of new packages
On 7/2/23 19:26, Antonio Valentino wrote: Just for the completeness, at the moment eodag misses 5 non-optional dependencies: * orjson: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002996 * usgs: https://github.com/kapadia/usgs Note that usgs is dead upstream: https://github.com/kapadia/usgs/pull/38 * jsonpath-ng: https://github.com/h2non/jsonpath-ng * pystac: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040045 * ecmwf-api-client: https://github.com/ecmwf/ecmwf-api-client Two of them (including pystac) already have ITPs. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Proposal for the inclusion of new packages
On 7/1/23 13:18, Antonio Valentino wrote: Dear Sebastiaan, Il 01/07/23 13:05, Sebastiaan Couwenberg ha scritto: On 7/1/23 13:02, Antonio Valentino wrote: Il 01/07/23 11:00, Sebastiaan Couwenberg ha scritto: On 7/1/23 10:20, Antonio Valentino wrote: Finally the following two packages are new optional dependencies od satpy: * pint-xarray: https://github.com/xarray-contrib/pint-xarray https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039101 * xarray-datatree: https://github.com/xarray-contrib/datatree https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039097 For that ones the packages are mostly ready and I have already opened ITPs. If it is ok for you to sponsor the first upload I can immediately create the git repository in salsa. Repos created: https://salsa.debian.org/debian-gis-team/pint-xarray https://salsa.debian.org/debian-gis-team/xarray-datatree Thanks. I think that now I have implemented all the changes you requested. Yes, if you want me to upload pint-xarray too, please set the changelog accordingly. The distribution is already set to unstable, if that is what you mean. Do I miss something? No, I just didn't see a commit to set the distribution like xarray-datatree. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Proposal for the inclusion of new packages
On 7/1/23 13:02, Antonio Valentino wrote: Il 01/07/23 11:00, Sebastiaan Couwenberg ha scritto: On 7/1/23 10:20, Antonio Valentino wrote: Finally the following two packages are new optional dependencies od satpy: * pint-xarray: https://github.com/xarray-contrib/pint-xarray https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039101 * xarray-datatree: https://github.com/xarray-contrib/datatree https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039097 For that ones the packages are mostly ready and I have already opened ITPs. If it is ok for you to sponsor the first upload I can immediately create the git repository in salsa. Repos created: https://salsa.debian.org/debian-gis-team/pint-xarray https://salsa.debian.org/debian-gis-team/xarray-datatree Thanks. I think that now I have implemented all the changes you requested. Yes, if you want me to upload pint-xarray too, please set the changelog accordingly. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Proposal for the inclusion of new packages
On 7/1/23 10:20, Antonio Valentino wrote: I think that it would be very important to have in Debian at least pystack, pystack-client and stacktools. The other ones are maybe less relevant. Maybe we could select a subset and discuss about priorities. For all the above packages I have not even started the packaging work. I would like to hear your opinion before doing it. Of course, it could take some time to have all of them packaged. Remote sensing is your area of expertise, so I defer to your opinion. You're also the one doing the work on those packages. Finally the following two packages are new optional dependencies od satpy: * pint-xarray: https://github.com/xarray-contrib/pint-xarray https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039101 * xarray-datatree: https://github.com/xarray-contrib/datatree https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039097 For that ones the packages are mostly ready and I have already opened ITPs. If it is ok for you to sponsor the first upload I can immediately create the git repository in salsa. Repos created: https://salsa.debian.org/debian-gis-team/pint-xarray https://salsa.debian.org/debian-gis-team/xarray-datatree Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: GDAL 3.7.0
On 6/16/23 11:12, Alastair McKinstry wrote: Sorry I'm confused; NCL failed but you also have it building in the list below. ncl initially FTBFS due to hdf4, see: https://github.com/HDFGroup/hdf4/pull/366 I then patched hdf4 to fix this, that's why it builds successfully now. I just rebuilt NCL (6.6.2.dfsg.1-1) with gdal 3.7.0 (and gcc/gfortran 13) locally on sid, it built for me. How did you make the build fail? By not having this patch applied to hdf4 (4.2.16-1): https://salsa.debian.org/debian-gis-team/hdf4/-/blob/master/debian/patches/include.patch Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
GDAL 3.7.0
With the release of bookworm it's time to prepare the transition for GDAL 3.7.0. The rdeps have been rebuilt which revealed one issue caused by changes in GDAL 3.7.0, and a few other packages which FTBFS due to unrelated issues. mysql-workbench (8.0.32+dfsg-1) FTBFS due to ca-certificates-java (#1030129). Once that is fixed it will likely FTBFS due to #998833. ncl (6.6.2.dfsg.1-1) FTBFS due to hdf4 (4.2.16-1): /usr/include/hdf/dfi.h:128:2: error: #endif without #if 128 | #endif /* H4_DFI_H */ | ^ This is fixed in hdf4 (4.2.16-2), but NCL still FTBFS: /usr/include/hdf/dfi.h:53:33: error: two or more data types in declaration specifiers 53 | #define float32 float | ^ /usr/include/hdf/hdfi.h:121:16: note: in expansion of macro 'float32' 121 | typedef float float32; |^~~ /usr/include/hdf/hdfi.h:121:1: warning: useless type name in empty declaration 121 | typedef float float32; | ^~~ hdf4 (4.2.16-3) contains a different fix for dfi.h that resolves this issue. python-django (3:3.2.19-1) FTBFS due to an unrelated issue (#1037920). vtk6 (6.3.0+dfsg2-8.1) FTBFS due to an unrelated issue (#984398). opencv (4.6.0+dfsg-12) FTBFS due to ca-certificates-java (#1030129). Removing the Java packages lets the package build successfully with GDAL 3.7.0. osmcoastline (2.4.0-1) FTBFS due to changes in GDAL 3.7.0 (#1037976), osmcoastline (2.4.0-2) contains a patch to fix this issue. The bugreports can be found via the gdal-3.7 usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gis@lists.debian.org=gdal-3.7 Transition: gdal libgdal32 (3.6.4+dfsg-1) -> libgdal33 (3.7.0+dfsg-1~exp1) The status of the most recent rebuilds is as follows. cloudcompare(2.11.3-7.1) OK fiona (1.9.4-1) OK gmt (6.4.0+dfsg-2)OK grass (8.2.1-1) OK libcitygml (2.5.1-1) OK libosmium (2.19.0-1)OK mapcache(1.14.0-1)OK mapnik (3.1.0+ds-3) OK mapproxy(1.16.0+dfsg-1) OK mapserver (8.0.1-1) OK merkaartor (0.19.0+ds-3) OK mysql-workbench (8.0.32+dfsg-1) FTBFS (#998833) ncl (6.6.2.dfsg.1-1) OK octave-mapping (1.4.2-3) OK openorienteering-mapper (0.9.5-3) OK openscenegraph (3.6.5+dfsg1-8) OK paraview(5.11.0+dfsg-1) OK pgsql-ogr-fdw (1.1.3-1) OK pktools (2.6.7.6+ds-4)OK postgis (3.3.3+dfsg-2)OK python-django (3:3.2.19-1) FTBFS (#1037920) qmapshack (1.16.1-2)OK r-cran-rgdal(1.6-4+dfsg-1)OK r-cran-sf (1.0-9+dfsg-1)OK r-cran-terra(1.7-3-1) OK rasterio(1.3.7-1) OK saga(9.0.2+dfsg-1)OK vtk6(6.3.0+dfsg2-8.1) FTBFS (#984398) vtk7(7.1.1+dfsg2-10.2)OK vtk9(9.1.0+really9.1.0+dfsg2-5) OK facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) OK libgdal-grass (1:1.0.2-4) OK opencv (4.6.0+dfsg-12) FTBFS (#1030129) osmcoastline(2.4.0-2) OK qgis(3.28.7+dfsg-1) OK sumo(1.15.0+dfsg-1) OK otb (8.1.1+dfsg-1)OK Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
tilemaker 2.4.0
tilemaker 2.4.0 has been released, do you have time to update the package? Wit the release of bookworm packages can be uploaded to unstable again instead of experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Debhelper compat level 13
With the bookworm release and EOL of bionic it's time to revisit the default debhelper compat level for our packages. Due to the lintian change complaining out compat level 9 we adopted 10 when it was only available for xenial via backports. Ubuntu focal has debhelper 12 in its release repo, and 13 in backports. Since backports are now required for Ubuntu, there is no strong blocker for switching to compat level 13. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Shapely 2.0
On 12/6/22 17:12, Sebastiaan Couwenberg wrote: With Shapely 2.0 nearing release, now was a good time to test the impact of the new major version. Not all rdeps are compatible with Shapely 2.0 as expected. A few FTBFS, and two don't due to test failures being ignored. The biggest blocker is Cartopy whose failure also affects other packages. While it seems that Shapely 2.0 will be released before the freeze in February, it is unlikely that the rdeps will be patched by then. Bugreports: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gis@lists.debian.org=shapely-2.0 Shapely 2.0 has been released. The test failure in pyresample was fixed in the the mean time, and Cartopy 0.21.1 also fixed compatibility with Shapely 2.0 which affected pyresample and geopandas. mapproxy our last unfixed package, unfortunately upstream development is not very active so it will likely take a while to get fixed. osmnx has a patch which is already applied upstream. python-dicompylercore doesn't have a fix yet, but upstream is aware of the issue. If there are fixes for the remaining issues in January, we can move Shapely 2.0 to unstable before the freeze. Otherwise it will stay in experimental until the bookworm release. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Shapely 2.0
With Shapely 2.0 nearing release, now was a good time to test the impact of the new major version. Not all rdeps are compatible with Shapely 2.0 as expected. A few FTBFS, and two don't due to test failures being ignored. The biggest blocker is Cartopy whose failure also affects other packages. While it seems that Shapely 2.0 will be released before the freeze in February, it is unlikely that the rdeps will be patched by then. Bugreports: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gis@lists.debian.org=shapely-2.0 Transition: python-shapely The status of the most recent rebuilds is as follows. aplpy (2.1.0-1)OK cura (4.13.0-1) OK doris (5.0.3~beta+dfsg-16) OK epigrass (3.0.3+dfsg-2) OK geoalchemy2 (0.12.1-1) OK mrcal (2.2-3) OK overpass (0.7-2) OK psycopg3 (3.1.3-0.1) OK pyosmium (3.5.0-1)OK python-dicompylercore (0.5.5-4)FTBFS (#1025605) python-pyproj (3.4.0-2)OK rasterio (1.3.4-1)OK mapproxy (1.15.1-2) OK (#1025610) pycsw (2.6.1+dfsg-2) OK python-cartopy(0.21.0+dfsg-4) FTBFS (#1025611) xarray-sentinel (0.9.5+ds-1) OK pyresample(1.26.0-4) FTBFS (#1025612) python-geopandas (0.12.1-2) OK (#1025613) osmnx (1.2.2+ds-2) FTBFS (#1025588) Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Memory Leak in renderd package
On 12/5/22 14:15, Chris wrote: i just set up two OSM rendering machines based on Debian 11.5 and used the packaged version of ,renderd'. This version however has an ugly memory leak, it consumes as much ram as it can with no limits and there are several reports of it, like: https://github.com/openstreetmap/mod_tile/issues/181 I compiled the latest GIT version of mod_tile, which includes renderd, and this version runs much better than the packaged one, so i would suggest considering an update of the packaged version. Felix, do you have time to work on this (upstream)? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Finalizing blends tasks for bookworm
The blends tasks have been cleaned up in preparation for the bookworm freeze. The remotesensing task has quite a few packages that aren't in Debian which I'm tempted to remove as well. Antonio, can you clarify the status of these packages? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
GDAL 3.6.0
The first release candidate for GDAL 3.6.0 has been released. A transition will be required for the SONAME bump. The rdeps have been rebuilt which revealed two issues caused by changes in GDAL 3.6.0, and five packages which FTBFS due to unrelated issues. New revisions of libgdal-grass and rasterio have been uploaded to unstable today with patches to fix their GDAL 3.6.0 related build failures. gazebo (11.10.1+dfsg-2) FTBFS due to unrelated issues (#1004795). mysql-workbench (8.0.26+dfsg-1) FTBFS due to unrelated issues (#998833). rasterio (1.3.3-1) FTBFS due to test failures (#1023480). A patch has been added to use xfail for the tests that fail with GDAL 3.6.0 in rasterio (1.3.3-2). vtk6 (6.3.0+dfsg2-8.1) FTBFS due to unrelated issues (#984398). libgdal-grass (1:1.0.1-1) FTBFS due to compile errors (#1023506). Even was very quick to provide PR to fix this issue, the changes have been added as a patch in libgdal-grass (1:1.0.1-2). Markus released gdal-grass 1.0.2 a little later with the GDAL 3.6.0 changes. sumo (1.12.0+dfsg1-1) FTBFS due to unrelated issues (#1023520). otb (8.0.1+dfsg-1) FTBFS due to unrelated issues (#1012950). The bugreports can be found via the gdal-3.6 usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gis@lists.debian.org=gdal-3.6 Transition: gdal libgdal31 (3.5.3+dfsg-1) -> libgdal32 (3.6.0~rc1+dfsg-1~exp1) The status of the most recent rebuilds is as follows. cloudcompare(2.11.3-7) OK fiona (1.8.22-1) OK gazebo (11.10.1+dfsg-2)FTBFS (#1004795) gmt (6.4.0+dfsg-1) OK grass (8.2.0-2) OK libcitygml (2.4.3-1) OK libosmium (2.18.0-1) OK mapcache(1.12.1-1) OK mapnik (3.1.0+ds-2)OK mapproxy(1.15.1-1) OK mapserver (8.0.0-2) OK merkaartor (0.19.0+ds-3) OK mysql-workbench (8.0.26+dfsg-1) FTBFS (#998833) ncl (6.6.2-12) OK octave-mapping (1.4.2-2) OK openorienteering-mapper (0.9.5-3) OK openscenegraph (3.6.5+dfsg1-8) OK paraview(5.11.0~rc1+dfsg-1) OK pgsql-ogr-fdw (1.1.3-1) OK pktools (2.6.7.6+ds-3) OK postgis (3.3.1+dfsg-2) OK python-django (3:3.2.16-1)OK qmapshack (1.16.1-1) OK r-cran-rgdal(1.5-32+dfsg-1) OK r-cran-sf (1.0-8+dfsg-1) OK r-cran-terra(1.6-17-1) OK rasterio(1.3.3-1) FTBFS (#1023480) saga(8.4.0+dfsg-1) OK vtk6(6.3.0+dfsg2-8.1) FTBFS (#984398) vtk7(7.1.1+dfsg2-10.2) OK vtk9(9.1.0+really9.1.0+dfsg2-4) OK libgdal-grass (1:1.0.1-1) FTBFS (#1023506) opencv (4.6.0+dfsg-7) OK osmcoastline(2.3.1-1) OK qgis(3.22.12+dfsg-1)OK sumo(1.12.0+dfsg1-1)FTBFS (#1023520) otb (8.0.1+dfsg-1) FTBFS (#1012950) Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Join the Debian GIS Team
On 10/25/22 16:00, Jochen Sprickerhof wrote: * Sebastiaan Couwenberg [2022-10-25 15:36]: On 10/25/22 15:25, Jochen Sprickerhof wrote: I'm a Debian Developer and would like to join the GIS Team to help with packing pure-maps. I have uploaded s2geometry from [1] to NEW earlier today and agreed with Sebastian Spaeth that it should be in the GIS Team. Would be great if someone with enough permissions could move it (or give me enough permissions to do so). Not very considerate to upload a package before joining the team that's set as Maintainer. It is not set as a maintainer yet. It is in git: https://salsa.debian.org/Mobian-team/packages/puremaps/s2geometry-deb/-/blob/debian/latest/debian/control#L4 Why not keep s2geometry in the mobian-team? We will move it to the DebianOnMobile team. My advice is to keep the puremaps related packages in the same team, no need to deal with multiple team policies and practices. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Join the Debian GIS Team
On 10/25/22 15:25, Jochen Sprickerhof wrote: I'm a Debian Developer and would like to join the GIS Team to help with packing pure-maps. I have uploaded s2geometry from [1] to NEW earlier today and agreed with Sebastian Spaeth that it should be in the GIS Team. Would be great if someone with enough permissions could move it (or give me enough permissions to do so). Not very considerate to upload a package before joining the team that's set as Maintainer. Why not keep s2geometry in the mobian-team? It has no dependencies on any GIS packages. I've read the Debian GIS Policy [2] and I agree with it. I've opened a membership request on Salsa as well. The packaging for s2geometry does not follow the packaging style of GIS packages. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
SAGA 8.4.0
On 10/12/22 15:42, Johan Van de Wauw wrote: SAGA 8.4.0 was released today, and I plan on updating to that. Thanks for working on the saga packaging. When do you plan to finish it? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
ruby-netcdf needs work for Ruby 3.1
Hi Youhei, ruby-netcdf is RC-buggy now that the transition to ruby3.1 has started. https://bugs.debian.org/1015328 Can you fix this? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: SAGA 8.3.0
On 7/30/22 07:13, Sebastiaan Couwenberg wrote: On 7/18/22 14:19, Johan Van de Wauw wrote: I will do the update. Thanks for working on the saga package, I saw the updated upstream branch but now further changes. Did you run into problems Ping. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: postinstallaton of qgis-providers fails with status 139
On 9/8/22 15:58, Martin Landa wrote: Could be related to [1]. Any idea what could be wrong? Libraries in the dependency tree are linked to different PROJ versions: https://bugs.debian.org/954242 https://bugs.debian.org/961281 https://bugs.debian.org/1008126 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
OTB 8.1.0
The first release candidate for OTB 8.1.0 has been released, but we can't build the package because insighttoolkit4 is broken causing the build dependencies to be uninstallable: libc6-dev : Breaks: libinsighttoolkit4-dev (<= 4.13.3withdata-dfsg2-3+b1) but 4.13.3withdata-dfsg2-3+b1 is to be installed insighttoolkit5 won't be supported until OTB 9, so we won't be able to update the package for the time being. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: sarsen
sarsen can be built now, which revealed an issue: dh_missing: warning: usr/lib/python3.10/dist-packages/.pytest_cache/.gitignore exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/python3.10/dist-packages/.pytest_cache/CACHEDIR.TAG exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/python3.10/dist-packages/.pytest_cache/README.md exists in debian/tmp but is not installed to anywhere (related file: "README.md") dh_missing: warning: usr/lib/python3.10/dist-packages/.pytest_cache/v/cache/nodeids exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/python3.10/dist-packages/.pytest_cache/v/cache/stepwise exists in debian/tmp but is not installed to anywhere The .pytest_cache directory will need to be removed explicitly in debian/rules or added to debian/not-installed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: xarray-sentinel
On 8/10/22 08:05, Antonio Valentino wrote:
Il 09/08/22 19:06, Sebastiaan Couwenberg ha scritto:
Packaging looks good, but it FTBFS:
make[1]: Entering directory '/home/bas/git/pkg-grass/xarray-sentinel'
dh_auto_clean
I: pybuild base:232: python3.9 setup.py clean
python3.9: can't open file
'/home/bas/git/pkg-grass/xarray-sentinel/setup.py': [Errno 2] No such
file or directory
E: pybuild pybuild:353: clean: plugin distutils failed with: exit
code=2: python3.9 setup.py clean
dh_auto_clean: error: pybuild --clean --test-pytest -i python{version}
-p 3.9 returned exit code 13
make[1]: *** [debian/rules:14: override_dh_auto_clean] Error 25
make[1]: Leaving directory '/home/bas/git/pkg-grass/xarray-sentinel'
make: *** [debian/rules:11: clean] Error 2
gbp:error: 'git-pbuilder' failed: it exited with 2
Sorry but I'm not able to reproduce this issue.
I see that you are using python3.9.
In what environment are you trying to build?
bullseye with sid cowbuilder chroot
Could you please provide more details to reproduce?
The clean target is executed outside the chroot first before the build
is started in the chroot.
Looks like it requires dh-python from backports.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
sarsen
* debian/copyright: Copyright format is: , * debian/rules: Adding a comment would help explain why this is set: export GITHUB_ACTIONS=true Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
flox
Packaging looks good, upload sponsored. Only nitpick: * Copyright format is: , You always omit the comma. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
xarray-sentinel
Packaging looks good, but it FTBFS:
make[1]: Entering directory '/home/bas/git/pkg-grass/xarray-sentinel'
dh_auto_clean
I: pybuild base:232: python3.9 setup.py clean
python3.9: can't open file
'/home/bas/git/pkg-grass/xarray-sentinel/setup.py': [Errno 2] No such
file or directory
E: pybuild pybuild:353: clean: plugin distutils failed with: exit
code=2: python3.9 setup.py clean
dh_auto_clean: error: pybuild --clean --test-pytest -i python{version}
-p 3.9 returned exit code 13
make[1]: *** [debian/rules:14: override_dh_auto_clean] Error 25
make[1]: Leaving directory '/home/bas/git/pkg-grass/xarray-sentinel'
make: *** [debian/rules:11: clean] Error 2
gbp:error: 'git-pbuilder' failed: it exited with 2
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: tilemaker 2.2.0
On 8/9/22 17:59, Felix Delattre wrote: On 8/3/22 13:10, Felix Delattre wrote: On 8/3/22 13:07, Sebastiaan Couwenberg wrote: Could you provide a patch for their cmake and makefile buildsystems? Sure, will do both. In the meantime set distribution back to UNRELEASED. Set up the environment locally to test mipsel and armel archs. Provided a patch to upstream and tested successfully the packaging locally. Set the distribution to unstable or experimental of you want to see it built there first. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Sarsen packaging
On 8/9/22 08:18, Antonio Valentino wrote:
Il 09/08/22 05:25, Sebastiaan Couwenberg ha scritto:
On 8/8/22 22:54, Antonio Valentino wrote:
I was able to create the three repositories but I got an error like
the following:
$ ./salsa-create-repository.pl -v -t -p sarsen
Getting projects for namespace: 2052 (page: 1)
Getting projects for namespace: 2052 (page: 2)
Getting projects for namespace: 2052 (page: 3)
Creating project: sarsen
Error: Request failed!
(https://salsa.debian.org/api/v4/projects/72235/integrations)
HTTP Status: 403 Forbidden
{"message":"403 Forbidden"}
Did you pull the latest changes?
The scripts were updated to fix the integration API calls:
https://salsa.debian.org/debian-gis-team/scripts/-/commit/c7ec2167ac324c147de03895cf275a52cfcdfb56
yes, I confirm that I used the latest revision on the git repo
Since you get a 403 instead of 404 it might be a permission issue:
This API requires an access token with the Maintainer or Owner role.
https://salsa.debian.org/help/api/integrations.md
OK, in the Debian GIS group on salsa I'm a "Developer"
This explains the issue
Access level check added to the scripts:
https://salsa.debian.org/debian-gis-team/scripts/-/commit/076a4eba3ea06788a69d3b5fa50d343efafb61f0
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Sarsen packaging
On 8/8/22 22:54, Antonio Valentino wrote:
Il 08/08/22 18:46, Sebastiaan Couwenberg ha scritto:
On 8/8/22 18:33, Antonio Valentino wrote:
Would you like to review the packages and sponsor the initial upload?
Once it's on Salsa.
If it is OK for you I will create the repositories on salsa and push
the source code.
Sure, go ahead.
Please use the sarsen, flox, and xarray-sential for the source package
names and git repos.
I was able to create the three repositories but I got an error like the
following:
$ ./salsa-create-repository.pl -v -t -p sarsen
Getting projects for namespace: 2052 (page: 1)
Getting projects for namespace: 2052 (page: 2)
Getting projects for namespace: 2052 (page: 3)
Creating project: sarsen
Error: Request failed!
(https://salsa.debian.org/api/v4/projects/72235/integrations)
HTTP Status: 403 Forbidden
{"message":"403 Forbidden"}
Did you pull the latest changes?
The scripts were updated to fix the integration API calls:
https://salsa.debian.org/debian-gis-team/scripts/-/commit/c7ec2167ac324c147de03895cf275a52cfcdfb56
Since you get a 403 instead of 404 it might be a permission issue:
This API requires an access token with the Maintainer or Owner role.
https://salsa.debian.org/help/api/integrations.md
Apparently it does not create problems and I was able to push the code
regularly.
Email & IRC notifications were not been configured due to the above, I
did that now:
$ ../scripts/salsa-configure-repositories.pl -vp sarsen
Getting projects for namespace: 2052 (page: 1)
Getting projects for namespace: 2052 (page: 2)
Getting projects for namespace: 2052 (page: 3)
Project: sarsen (72235)
Issues already disabled.
Merge method is already fast-forward.
Merge request link when pushing from the command line is already
disabled.
Current CI config path is already 'debian/.gitlab-ci.yml'.
Activating Emails on push for: sarsen (72235)
Activated Emails on push service for project: sarsen (72235)
Irker service already deactivated for project: sarsen (72235)
Adding KGB webhook for: sarsen (72235)
Added KGB webhook for project: sarsen (72235)
Configuring protected branches for: sarsen (72235)
Configured protected branches for project: sarsen (72235)
$ ../scripts/salsa-configure-repositories.pl -vp flox
Getting projects for namespace: 2052 (page: 1)
Getting projects for namespace: 2052 (page: 2)
Getting projects for namespace: 2052 (page: 3)
Project: flox (72233)
Issues already disabled.
Merge method is already fast-forward.
Merge request link when pushing from the command line is already disabled.
Current CI config path is already 'debian/.gitlab-ci.yml'.
Activating Emails on push for: flox (72233)
Activated Emails on push service for project: flox (72233)
Irker service already deactivated for project: flox (72233)
Adding KGB webhook for: flox (72233)
Added KGB webhook for project: flox (72233)
Configuring protected branches for: flox (72233)
Configured protected branches for project: flox (72233)
$ ../scripts/salsa-configure-repositories.pl -vp xarray-sentinel
Getting projects for namespace: 2052 (page: 1)
Getting projects for namespace: 2052 (page: 2)
Getting projects for namespace: 2052 (page: 3)
Project: xarray-sentinel (72234)
Issues already disabled.
Merge method is already fast-forward.
Merge request link when pushing from the command line is already disabled.
Current CI config path is already 'debian/.gitlab-ci.yml'.
Activating Emails on push for: xarray-sentinel (72234)
Activated Emails on push service for project: xarray-sentinel (72234)
Irker service already deactivated for project: xarray-sentinel (72234)
Adding KGB webhook for: xarray-sentinel (72234)
Added KGB webhook for project: xarray-sentinel (72234)
Configuring protected branches for: xarray-sentinel (72234)
Configured protected branches for project: xarray-sentinel (72234)
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Sarsen packaging
On 8/8/22 18:33, Antonio Valentino wrote: Would you like to review the packages and sponsor the initial upload? Once it's on Salsa. If it is OK for you I will create the repositories on salsa and push the source code. Sure, go ahead. Please use the sarsen, flox, and xarray-sential for the source package names and git repos. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: tilemaker 2.2.0
On 8/3/22 13:20, Sebastiaan Couwenberg wrote: 2.2.0 FTFBS on some architectures: https://buildd.debian.org/status/package.php?p=tilemaker -latomic is required on some architecture, something like the following may suffice: diff --git a/debian/rules b/debian/rules index 6246cf3..de32874 100755 --- a/debian/rules +++ b/debian/rules @@ -10,7 +10,11 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all include /usr/share/dpkg/pkg-info.mk TM_VERSION := $(shell echo $(DEB_VERSION_UPSTREAM) | sed -e 's/\+.*//') -export DEB_CXXFLAGS_MAINT_APPEND=-DTM_VERSION=$(TM_VERSION) +ifneq (,$(filter $(DEB_BUILD_ARCH),armel mipsel powerpc)) + export DEB_CXXFLAGS_MAINT_APPEND=-DTM_VERSION=$(TM_VERSION) -latomic +else + export DEB_CXXFLAGS_MAINT_APPEND=-DTM_VERSION=$(TM_VERSION) +endif %: dh $@ --buildsystem=cmake I see you pushed a commit with the above, have you tested it on one or more of the architectures in question (e.g. using qemu or a guest account on the porterboxes)? Ideally upstream would fix their buildsystem to add -latomic when needed, llvm and chromium do this in their CMake builds for example. Could you provide a patch for their cmake and makefile buildsystems? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: tilemaker 2.2.0
2.2.0 FTFBS on some architectures: https://buildd.debian.org/status/package.php?p=tilemaker -latomic is required on some architecture, something like the following may suffice: diff --git a/debian/rules b/debian/rules index 6246cf3..de32874 100755 --- a/debian/rules +++ b/debian/rules @@ -10,7 +10,11 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all include /usr/share/dpkg/pkg-info.mk TM_VERSION := $(shell echo $(DEB_VERSION_UPSTREAM) | sed -e 's/\+.*//') -export DEB_CXXFLAGS_MAINT_APPEND=-DTM_VERSION=$(TM_VERSION) +ifneq (,$(filter $(DEB_BUILD_ARCH),armel mipsel powerpc)) + export DEB_CXXFLAGS_MAINT_APPEND=-DTM_VERSION=$(TM_VERSION) -latomic +else + export DEB_CXXFLAGS_MAINT_APPEND=-DTM_VERSION=$(TM_VERSION) +endif %: dh $@ --buildsystem=cmake Or you need to get the package removed from armel & mipsel via an RM bugreport on ftp.debian.org using reportbug. tilemaker has no reverse dependencies, so there are no blockers for partial removal. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: SAGA 8.3.0
On 7/18/22 14:19, Johan Van de Wauw wrote: I will do the update. Thanks for working on the saga package, I saw the updated upstream branch but now further changes. Did you run into problems? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: tilemaker 2.2.0
On 7/23/22 13:29, Felix Delattre wrote: On 7/22/22 12:47, Sebastiaan Couwenberg wrote: Any progress on updating the tilemaker package to 2.2.0? Not so far, but planning to do in the upcoming weeks. Or is there any reason why this has to happen urgently? It's been a while since the last upload, the 2.1.0 release from February never got packaged, so it's high time to update the package now. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Postgis debian packaging
On 7/22/22 15:38, Marc Millas wrote: error: cannot find function gserialized_gist_sortsupport_2d in file postgresql-12-postgis-3.so google for that function name.. find it in postgis sources what can be the pb ? The function was added in PostGIS 3.2.0: https://salsa.debian.org/debian-gis-team/postgis/-/blame/master/postgis/gserialized_gist_2d.c#L88 https://git.osgeo.org/gitea/postgis/postgis/commit/b6fccefdb6a3bd672e8e9fe0179e8ff9c080f084 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: tilemaker 2.2.0
On 7/15/22 15:45, Felix Delattre wrote: Yes I do use deb...@xama.nu and I am happy to look into the updates. Any progress on updating the tilemaker package to 2.2.0? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Postgis debian packaging
On 7/20/22 16:57, Marc Millas wrote: I am porting a postgres 12 postgis 3.0.x instance from a windows machine to a debian 11 machine. as the app running on that db is quite long to test, the target MUST be postgres 12 and postgis 3.0.x I know that debian 11 comes with a postgres 13 and postgis distro, but it's not the versions I need. no pb to install the postgres 12.11 from postgresql.org When installing a different postgresql version included in the Debian release, you need to install postgis from the apt.postgresql.org repo too: https://wiki.postgresql.org/wiki/Apt When you need a different version of postgis than provided in Debian or apt.postgresql.org, you'll need to build it yourself. but, when looking at the debian postgis page, I didnt find "nothing" ie. I don't find what could be the name of the packet, and obviously not the packet itself. The postgis binary package Recommends postgresql-postgis which is provided by postgresql-13-postgis-3. For postgresql-12 you'll need to install its postgis extension: postgresql-12-postgis-3 I am even unable to guess if such a packet do exist. `apt-cache search postgis` is your friend. Clearly, I do find a postgres-12-postgis-3 packet, but that one installs a postgis 3.2.1 which is not my need. Then you'll need to build the version of postgis that you need with the version postgresql that you use. Marc MILLAS Senior Architect +33607850334 www.mokadb.com You should work with credativ, they provide PostgreSQL consulting and employ two of the maintainers of apt.postgresql.org. https://www.credativ.de/en/contact/ Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
mercantile 1.2.1
mercantile 1.2.1 has been released, do you have time to update the package? Are you still alive? Haven't seen activity from you in a while. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
tilemaker 2.2.0
tilemaker 2.2.0 has been released, do you have time to update the package? There is also an outstanding MR for tirex: https://salsa.debian.org/debian-gis-team/tirex/-/merge_requests/1 Are you still alive? Previous pings have not generated a response. Do you no longer use deb...@xama.nu? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
openstreetmap-carto 5.5.1
openstreetmap-carto 5.5.1 has been released, do 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
SAGA 8.3.0
SAGA 8.3.0 has been released, do 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
Re: State of ECW support in Debian gdal?
On 7/6/22 14:06, Sebastiaan Couwenberg wrote: You'll need to maintain a fork of the package which sets GDAL_USE_ECW in d/rules and adds the relevant packages to the Build-Depends in d/control. Or find a way to build the ECW driver as a plugin like gdal-grass, that's the cleanest solution. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: State of ECW support in Debian gdal?
On 7/6/22 13:25, Sven Geggus wrote: gdal in Debian used to contain a patch for adding ecw support via a proprietary library using a plugin. Unfortunately this seems to have gone. Yes. With the switch to CMake the packaging was updated significantly, all the custom targets were removed along with their related patches because that used Autotools. We only used the gdal-grass target, which is now obsolete because it moved to a separate repo. Unfortunately this plugin approach does not seem to be included in the package anymore. Is this correct? You'll need to maintain a fork of the package which sets GDAL_USE_ECW in d/rules and adds the relevant packages to the Build-Depends in d/control. Do I really need to recompile the whole library now? Yes. Just like when you need OCI support in qgis. We won't be maintaining any support for proprietary drivers. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Debian GIS
On 7/4/22 13:14, Mgr. Vladimir Zbozinek wrote: Hit http://security.debian.org jessie/updates InRelease jessie is EOL: https://wiki.debian.org/DebianReleases#Production_Releases Debian Pure Blends are great because all packages are in Debian itself, you can just install Debian bullseye (current stable): https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/ And then install the packages from the GIS pure blend, e.g.: apt install gis-workstation Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: [RFS] MintPy packaging
On 6/30/22 08:48, Antonio Valentino wrote:
Il 26/06/22 21:45, Sebastiaan Couwenberg ha scritto:
On 5/15/22 09:31, Antonio Valentino wrote:
The package for mintpy still needs some work, but, for a proper
testing, I would like to have all dependencies are in the archive.
The dependencies are now in the archive and on the mirrors enabling
package builds without custom repos for those.
With the recent update of lintian, the overrides need to be updated
and new issues need to be reviewed.
I haven't had time for an extensive review yet, but I did notice the
long list of dependencies for the binary package which shouldn't be
required as ${python3:Depends} and dh_python3 should take care of
those using setup.py install_requires. Am I missing something that
explains the hardcoded list of dependencies?
There is still a related issue:
I: dh_python3 pydist:292: Cannot find package that provides
dask_jobqueue. Please add package that provides it to Build-Depends or
add "dask_jobqueue python3-dask-jobqueue" line to
debian/py3dist-overrides or add proper dependency to Depends by hand
and ignore this info.
mintpy/objects/cluster.py imports for non-local clusters, so it's not
strictly required and can be ignored.
According to /usr/share/doc/dh-python/README.PyDist the dependency can
be ignored by only specifying the dist field and nothing else.
Also, hardcoded dependencies should be specified first, then the ones
set via substitution variables like ${python3:Depends} and ${misc:Depends}.
The link overload in the extended description is also not great.
GFDL license is considered non-free when it contains invariant
sections, does this apply to MintPy?
https://wiki.debian.org/DFSGLicenses#GNU_Free_Documentation_License_.28GFDL.29
As far as I can understand it is not the case for mintpy.
The wiki-2.0.cpt file, the only one with GFDL license, includes the a
license notice clearly stating
...
# any later version published by the Free Software Foundation; with no
# Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
...
By the way I have also checked that the "wiki-2.0.cpt" is never used
directly in the code and it can be easily removed.
If you think that it is safer to remove it, please let me know.
Thanks for the clarification.
Otherwise I think that the rest of the comments raised in your review
have been addressed, so please fee free to go on with a final review and
upload.
Suggests is sufficient for -doc package, installing the library
shouldn't pull in the documentation by default that should be installed
by the user explicitly.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: [RFS] MintPy packaging
On 6/26/22 21:45, Sebastiaan Couwenberg wrote:
On 5/15/22 09:31, Antonio Valentino wrote:
The package for mintpy still needs some work, but, for a proper
testing, I would like to have all dependencies are in the archive.
The dependencies are now in the archive and on the mirrors enabling
package builds without custom repos for those.
With the recent update of lintian, the overrides need to be updated and
new issues need to be reviewed.
I haven't had time for an extensive review yet, but I did notice the
long list of dependencies for the binary package which shouldn't be
required as ${python3:Depends} and dh_python3 should take care of those
using setup.py install_requires. Am I missing something that explains
the hardcoded list of dependencies?
The link overload in the extended description is also not great.
GFDL license is considered non-free when it contains invariant sections,
does this apply to MintPy?
https://wiki.debian.org/DFSGLicenses#GNU_Free_Documentation_License_.28GFDL.29
debian/control
You may want to consider a separate -doc package.
debian/rules
python{version} should be replaced with {interpreter}.
https://manpages.debian.org/bullseye/dh-python/pybuild.1.en.html#variables_that_can_be_used_in_ARGUMENTS_and_COMMAND
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: [RFS] MintPy packaging
On 5/15/22 09:31, Antonio Valentino wrote:
The package for mintpy still needs some work, but, for a proper testing,
I would like to have all dependencies are in the archive.
The dependencies are now in the archive and on the mirrors enabling
package builds without custom repos for those.
With the recent update of lintian, the overrides need to be updated and
new issues need to be reviewed.
I haven't had time for an extensive review yet, but I did notice the
long list of dependencies for the binary package which shouldn't be
required as ${python3:Depends} and dh_python3 should take care of those
using setup.py install_requires. Am I missing something that explains
the hardcoded list of dependencies?
The link overload in the extended description is also not great.
GFDL license is considered non-free when it contains invariant sections,
does this apply to MintPy?
https://wiki.debian.org/DFSGLicenses#GNU_Free_Documentation_License_.28GFDL.29
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: [RFS] MintPy packaging
On 6/25/22 09:26, Antonio Valentino wrote: Regarding pykml, I have updated the license file and removed form the package a file (only used for testing) for which the licensing was not clear to me. Did you have time to review it? Is there anything that still needs to be fixed? Yes, as mentioned before: https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2022-June/094961.html From the linked message: " pykml (0.2.0+dfsg-1) only excludes kml22gx.xsd, that is unlikely to be sufficient for the FTP masters. ogckml22.xsd uses the OGC Document Notice which was considered non-free because it limits modification. This is why tinyows is in non-free. Exclude src/pykml/schemas/* instead to not have to deal with any XSD licensing. " https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2022-June/094907.html Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
SAGA 8.2.2
SAGA 8.2.2 has been released, do 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
Re: Updating Saga (again)
On 5/30/22 16:02, Johan Van de Wauw wrote: FYI, I found the issue, working on a fix. Thanks for the patch in saga (8.2.1+dfsg-2). Do you consider it ready for upload? If so, please update the changelog accordingly, and I'll sponsor the upload. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: pykml packaging
On 5/19/22 07:59, Antonio Valentino wrote: Il 18/05/22 08:15, Sebastiaan Couwenberg ha scritto: debian/control pykml is a better name for the binary package See for example: https://salsa.debian.org/debian-gis-team/python-stetl/-/blob/master/debian/control#L56 `apt install pykml` gets you the executables and library which is more intuitive than `apt install pykml-bin`. this is now fixed. Thanks. debian/rules Why did you remove PYBUILD_NAME? Because there are multiple binary packages. If I set it then I get the following error: running install_scripts Installing csv2kml script to /home/antonio/debian/git/build-area/pykml-0.2.0/debian/python3-pykml/usr/bin Installing kml2pykml script to /home/antonio/debian/git/build-area/pykml-0.2.0/debian/python3-pykml/usr/bin Installing validate_kml script to /home/antonio/debian/git/build-area/pykml-0.2.0/debian/python3-pykml/usr/bin dh_install -O--buildsystem=pybuild dh_install: warning: Cannot find (any matches for) "usr/lib" (tried in ., debian/tmp) dh_install: warning: python3-pykml missing files: usr/lib dh_install: warning: Cannot find (any matches for) "usr/bin" (tried in ., debian/tmp) dh_install: warning: pykml missing files: usr/bin dh_install: error: missing files, aborting make: *** [debian/rules:7: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 debuild: fatal error at line 1182: dpkg-buildpackage -us -uc -ui -i -I failed gbp:error: 'debuild -i -I -us -uc' failed: it exited with 29 Is there a better way to do it? No it's fine, as per the pybuild manpage: " • if more than one binary package is build: add debian/python-foo.install files, or export PYBUILD_NAME=modulename (modulename will be used to guess binary package prefixes), or export PYBUILD_DESTDIR env. variables in debian/rules " It's just unusual to see pybuild packages without PYBUILD_NAME in d/rules. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: pykml packaging
debian/control pykml is a better name for the binary package See for example: https://salsa.debian.org/debian-gis-team/python-stetl/-/blob/master/debian/control#L56 `apt install pykml` gets you the executables and library which is more intuitive than `apt install pykml-bin`. debian/rules Why did you remove PYBUILD_NAME? Kind Regards, Bas On 5/18/22 07:55, Antonio Valentino wrote: Dear Bas, all the requested changes should be now implemented. Please feel free to go on with your review. kind regards antonio Il 16/05/22 08:43, Antonio Valentino ha scritto: Dear Bas, Il 15/05/22 18:46, Sebastiaan Couwenberg ha scritto: On 5/15/22 11:07, Antonio Valentino wrote: Please feel free to review them. debian/copyright GitHub repo is better than PyPI for Source. debian/patches/* Forward patches upstream and mark them accordingly. Don't use a mailinglist for From/Author. debian/python3-pykml.lintian-overrides Move executables to pykml binary package. debian/watch Using GitHub tags is generally better than the PyPI service. PyPI is only for cases where there are not tagged releases elsewhere. But the GitHub repo lacks tags for the releases on PyPI. And the project hasn't seen any changes in 10 years. Doesn't look like a good project to have in Debian. You'll have to carry a lot of patches that upstream won't act on. OK, I think that I have addressed most of the points. Only the split out of executable scripts into a dedicated package is missing. I will implement it later today or tomorrow. kind regards -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
pykml packaging
On 5/15/22 11:07, Antonio Valentino wrote: Please feel free to review them. debian/copyright GitHub repo is better than PyPI for Source. debian/patches/* Forward patches upstream and mark them accordingly. Don't use a mailinglist for From/Author. debian/python3-pykml.lintian-overrides Move executables to pykml binary package. debian/watch Using GitHub tags is generally better than the PyPI service. PyPI is only for cases where there are not tagged releases elsewhere. But the GitHub repo lacks tags for the releases on PyPI. And the project hasn't seen any changes in 10 years. Doesn't look like a good project to have in Debian. You'll have to carry a lot of patches that upstream won't act on. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
pysolid packaging
On 5/15/22 11:07, Antonio Valentino wrote: Please feel free to review them. debian/copyright Source URL is empty. debian/rules Use py3versions, python2 is EOL. Sort rules targets in order of execution Use only a single dh_auto_test override. debian/watch Uses repacksuffix but Files-Excluded is not used. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
pyaps3 packaging
On 5/15/22 11:07, Antonio Valentino wrote: Please feel free to review them. debian/copyright Please use standalone license paragraphs. debian/patches/0001-Fix-indentation.patch Please forward upstream and mark the patch accordingly. debian/upstream/metadata Consider adding Cite-As. debian/watch Using GitHub tags is generally better than the PyPI service. PyPI is only for cases where there are not tagged releases elsewhere. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: [RFS] MintPy packaging
On 5/15/22 09:31, Antonio Valentino wrote: If you agree I would like to maintain the packages under debian-gis. That's obviously fine. If there are no objections I would kindly ask you to create the git repositories in salsa and then review and sponsor the upload. Fix the fixed scripts you should have been able to create them yourself. https://salsa.debian.org/debian-gis-team/mintpy https://salsa.debian.org/debian-gis-team/pyaps3 https://salsa.debian.org/debian-gis-team/pysolid https://salsa.debian.org/debian-gis-team/pykml The package for mintpy still needs some work, but, for a proper testing, I would like to have all dependencies are in the archive. You may want to consider using reprepro to host your own packages, I use it for my own packages and have a separate distribution and associated cowbuilder chroot for rebuilds which is used to make rebuilt packages available in my LAN when preparing transitions. With your own repo you're not blocking waiting for the dependencies to pass NEW. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: GDAL 3.5.0
On 5/9/22 15:16, Sebastiaan Couwenberg wrote: Rebuild tests are still TODO which may reveal some issues caused by the changes for 3.5.0. Rebuild tests are done, and only qgis FTFBS due to changes in gdal. This is already fixed in git, but we need sip6 to be fixed to before qgis can be built successfully. mysql-workbench (8.0.26+dfsg-1) FTBFS due to gcc-11 (#998833). saga (7.3.0+dfsg-7) FTBFS due to python3.10 (#1009417). vtk6 (6.3.0+dfsg2-8.1) FTBFS due to gcc-11 (#984398). qgis (3.22.5+dfsg-1) FTBFS due to sip6 (#1009939) and not supporting Multi-Arch paths for gdal. Transition: gdal libgdal30 (3.4.3+dfsg-1) -> libgdal31 (3.5.0~rc2+dfsg-1~exp1) The status of the most recent rebuilds is as follows. cloudcompare(2.11.3-5) OK fiona (1.8.21-1) OK gazebo (11.10.1+dfsg-2)OK gmt (6.3.0+dfsg-2) OK grass (8.0.1-1) OK libcitygml (2.4.2-1) OK libosmium (2.18.0-1) OK mapcache(1.12.1-1) OK mapnik (3.1.0+ds-2)OK mapproxy(1.14.0-1) OK mapserver (7.6.4-2) OK merkaartor (0.19.0+ds-2) OK mysql-workbench (8.0.26+dfsg-1) FTBFS (#998833) ncl (6.6.2-11) OK octave-mapping (1.4.2-1) OK openorienteering-mapper (0.9.5-3) OK openscenegraph (3.6.5+dfsg1-7) OK paraview(5.10.1-1) OK pgsql-ogr-fdw (1.1.1-3) OK pktools (2.6.7.6+ds-3) OK postgis (3.2.1+dfsg-1) OK python-django (2:3.2.13-1)OK qmapshack (1.16.1-1) OK r-cran-rgdal(1.5-29+dfsg-1) OK r-cran-sf (1.0-7+dfsg-1) OK r-cran-terra(1.5-21-2) OK rasterio(1.2.10-1) OK saga(7.3.0+dfsg-7) FTBFS (#1009417) vtk6(6.3.0+dfsg2-8.1) FTBFS (#984398) vtk7(7.1.1+dfsg2-10.1) OK vtk9(9.1.0+really9.1.0+dfsg2-3) OK libgdal-grass (3.4.3-1 / 1:1.0.0-1~exp1) FTBFS / OK opencv (4.5.4+dfsg-9) OK osmcoastline(2.3.1-1) OK qgis(3.22.5+dfsg-1) FTBFS (#1009939) sumo(1.12.0+dfsg1-1)OK otb (8.0.1+dfsg-1) OK Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Updating Saga (again)
On 5/10/22 11:52, Johan Van de Wauw wrote: I've pushed some more changes to the packaging of SAGA, I think it is in relatively good shape now. The changelog needs to be updated to include more of the changes and most importantly close #1009417. The copyright file also needs to be updated, for input see: licensecheck --deb-machine -r * Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
GDAL 3.5.0
The first two release candidates for GDAL 3.5.0 have been released. The packaging got a significant overhaul to use CMake and remove its many non-standard ways of doing things. The symbols file is no managed with pkgkde-symbolshelper like our other C++ packages with symbols files. No more waiting for snapshot.debian.org to get the new libgdal packages before you can update the symbols with gdal-symbols.pl, you now only have to wait for the build to complete. The switch to CMake causes the removal of the static library, as only Autotools builds both by default. The packaging overhaul causes the use of Multi-Arch path for the library files, the grass package needed an update for this as it symlinks the library. The 3.5.0 removes many deprecated drivers [0] (DOD which we removed already, and CharLS which was removed in RC1), and the Perl bindings. A bit annoying is the new drivers.ini file in the gdalplugins directory, this is a subdirectory under /usr/lib/$(DEB_HOST_MULTIARCH) which would suggest including the file in libgdal31 but that would make the package no longer co-installable with libgdal32+ and complicate upgrades. Since the Multi-Arch path is specific to the architecture, the file cannot be included in gdal-data which is contains many other data files for libgdal, hence the gdal-plugins package was introduced as a dependency of libgdal31 to install this file. The libgdal-grass package is also no longer generated from the gdal source tree, it's now maintained in a separate upstream git repo where the version was reset to 1.0.0 (for testing) [1]. If that stays we'll need to use an epoch for the Debian package. My local working copy was manipulated to use 3.5.0~rc1 for the time being. Like gdal, the gdal-grass packaging also overhauled but since it still uses Autotools just not as extensive. The packaging was updated to support DESTDIR and debug symbols, and use the Multi-Arch path for the gdalplugins. The VERSION check was also removed, this was a divergence from upstream which is not required, we only need to ensure to rebuild the package when the GDAL major or minor version changes. This will make transitions easier as we won't have to upload a new revision of libgdal-grass every time. Rebuild tests are still TODO which may reveal some issues caused by the changes for 3.5.0. [0] https://lists.osgeo.org/pipermail/gdal-dev/2021-March/053590.html [1] https://github.com/OSGeo/gdal-grass/discussions/2 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Adding tiledb to gdal and pdal ? (And help with tiledb-py ?)
On 1/20/22 20:14, Sebastiaan Couwenberg wrote: On 1/20/22 15:59, Dirk Eddelbuettel wrote: The tiledb package is now in testing [1] which means gdal and pdal could configure with it. I tested this over the holiday break with earlier (informal) packages from launchpad -- I still have the repos and could file bug reports with patches if that helped but I think it really is just libtiledb-dev in debian/control for Build-Depends --with-tiledb=yes in debian/rules for configure I have not yet had time to look at tiledb-py. In case someone here in GIS space wants to give me a hand I would all for it :) I am mostly an R/C++ programmer and only package a few things in Python for Debian. While it's good that the tiledb is in a better state now, I think it's a bit early to enable the support now. GDAL 3.5 and PDAL 2.4 might a good time to add tiledb support. Adding TileDB support for gdal (3.5.0~rc1+dfsg-1) causes the test target to fail. GDAL 3.5.0 contains changes to support TileDB 2.7 which suggests this is a regression caused by TileDB 2.8. TileDB support won't be added in 3.5. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: GeographicLib 2.0
On 4/29/22 07:52, Antonio Valentino wrote: thanks for the review All should be fixed now Thanks for your work. I've pushed a few more changes before uploading the package. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: GeographicLib 2.0
On 4/28/22 08:10, Antonio Valentino wrote:
I have almost completed the packaging of geographiclib-python 2.0.
I've review the changes in the Salsa repo.
The debian/2.0-1_exp1 tag was pushed prematurely, I've deleted it from
the repo, you'll need to do the same in your working copy.
debian/control:
The source package currently matches the upstream repository name, it's
probably better to use the same name as the packaging git repo:
python-geographiclib. That also conforms more to the Python Policy.
${python3:Recommends} and ${python3:Suggests} are not defined and should
be removed .
debian/copyright:
The title and copyright statement should be removed from the Expat
standalone license paragraph. It should start with "Permission is hereby
granted...".
Using the GitHub repo for the Source is better than the link to the
documentation.
debian/rules:
Please add an empty line before the %: rule.
debian/watch:
Doesn't handle common issues. See python-stetl for example.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: GeographicLib 2.0
On 4/28/22 08:35, Sebastiaan Couwenberg wrote: On 4/28/22 08:10, Antonio Valentino wrote: Now I need a repository in salsa. I think that I can create it myself through the GitLab Web UI. Never create repositories via the web interface, we use scripts to configuration (new) repositories correctly (CI configuration path, Emails on Push integration, KGB webhook, protected branches). I was just wondering if there is some specific initialization step I'm not aware of. In case could you please point me to the relevant documentation? https://debian-gis-team.pages.debian.net/policy/packaging.html#git-repository-on-salsa Unfortunately the emails-on-push REST API endpoint is still broken causing salsa-create-repository.pl to fail. I've updated the scripts to make them work with the new REST API behavior. The REST API may still fail for some users due their limited role: " This API requires an access token with the Maintainer or Owner role. " https://salsa.debian.org/help/api/integrations.md Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: GeographicLib 2.0
On 4/28/22 08:10, Antonio Valentino wrote: I have almost completed the packaging of geographiclib-python 2.0. Sorry, I'm quite busy in this period and I will still need few days to finalize. There is no hurry, upstream has published some 2.0 releases for some of the implementations but not C++ yet. https://sourceforge.net/projects/geographiclib/files/ Now I need a repository in salsa. I think that I can create it myself through the GitLab Web UI. Never create repositories via the web interface, we use scripts to configuration (new) repositories correctly (CI configuration path, Emails on Push integration, KGB webhook, protected branches). I was just wondering if there is some specific initialization step I'm not aware of. In case could you please point me to the relevant documentation? https://debian-gis-team.pages.debian.net/policy/packaging.html#git-repository-on-salsa Unfortunately the emails-on-push REST API endpoint is still broken causing salsa-create-repository.pl to fail. I've created the repository for you: https://salsa.debian.org/debian-gis-team/python-geographiclib Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Switching SAGA to cmake
On 4/19/22 09:23, Johan Van de Wauw wrote: On Mon, Apr 18, 2022 at 8:35 PM Sebastiaan Couwenberg wrote: Regarding those issues I'm mostly wanting your feedback about your inconsistent email address use, and the libvigraimpex support. For email, my preferred email for open source work is jo...@gisky.be That's not reflected in d/control at the moment: johan.vandew...@gmail.com avce00 python-affine python-cligj python-descartes python-geojson python-geopandas python-snuggs jo...@vandewauw.be fiona geolinks python-click-plugins rasterio saga jo...@gisky.be hdf4 owslib pycsw I you use the same email address everywhere you can set DEBEMAIL accordingly and have it used by dch. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Switching SAGA to cmake
On 4/14/22 13:32, Sebastiaan Couwenberg wrote: On 4/14/22 11:21, Sebastiaan Couwenberg wrote: On 4/14/22 10:36, Johan Van de Wauw wrote: As SAGA is switching to cmake[1], I'm now adjusting the debian package build to use cmake as well. For now I managed to build a working package, but I've disabled two tools [2]. If I enable them, I get these errors: -- :CMake Error at src/tools/io/io_shapes_dxf/CMakeLists.txt:10 (target_include_directories): Cannot specify include directories for target "io_shapes_dxf" which is not built by this project. CMake Error at src/tools/io/io_shapes_dxf/CMakeLists.txt:11 (target_link_libraries): Cannot specify link libraries for target "io_shapes_dxf" which is not built by this project. -- if anyone has an idea why this happens, feel free to help fixing the issue. " The named must have been created by a command such as add_executable() or add_library() and must not be an ALIAS target. " https://cmake.org/cmake/help/latest/command/target_include_directories.html saga-gis/src/tools/CMakePluginTemplate.cmake call add_library and should likely be included after the project() call instead of at the end of the file. Please act on the issues raised on the pkg-grass-devel lists: https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2022-April/094097.html https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2022-April/094087.html https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2022-April/094086.html I've pushed changes to fix several issues, please address the remaining ones. You really need to push the upstream branch as it needs to be updated with another repacked upstream release from which the CC BY-NC-SA documentation is also removed. I have already deleted the 8.2.0+dfsg tag, you should delete that in your local copy too. Did you see the related lintian issue? missing-field-in-dep5-copyright License [debian/copyright:252] Do you have time to finish work on the package? The CMake issues are fixed, but the patches still need to be forwarded upstream. The copyright file needs an update too, see: licensecheck --deb-machine -r * | less While fixing the CMake issues I also addressed many of the issues I raised on the pkg-grass-devel lists, but not all of them. Regarding those issues I'm mostly wanting your feedback about your inconsistent email address use, and the libvigraimpex support. libvigraimpex is blocked from migrating to testing by python3-defaults, removing its support from saga would help its testing migration. But it needs to close the RC bug with the changelog entry for the removed Python support to be eligible for testing migration. Does SAGA upstream have plans to move to setuptools or similar instead of distutils? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Switching SAGA to cmake
On 4/14/22 11:21, Sebastiaan Couwenberg wrote: On 4/14/22 10:36, Johan Van de Wauw wrote: As SAGA is switching to cmake[1], I'm now adjusting the debian package build to use cmake as well. For now I managed to build a working package, but I've disabled two tools [2]. If I enable them, I get these errors: -- :CMake Error at src/tools/io/io_shapes_dxf/CMakeLists.txt:10 (target_include_directories): Cannot specify include directories for target "io_shapes_dxf" which is not built by this project. CMake Error at src/tools/io/io_shapes_dxf/CMakeLists.txt:11 (target_link_libraries): Cannot specify link libraries for target "io_shapes_dxf" which is not built by this project. -- if anyone has an idea why this happens, feel free to help fixing the issue. " The named must have been created by a command such as add_executable() or add_library() and must not be an ALIAS target. " https://cmake.org/cmake/help/latest/command/target_include_directories.html saga-gis/src/tools/CMakePluginTemplate.cmake call add_library and should likely be included after the project() call instead of at the end of the file. Please act on the issues raised on the pkg-grass-devel lists: https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2022-April/094097.html https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2022-April/094087.html https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2022-April/094086.html I've pushed changes to fix several issues, please address the remaining ones. You really need to push the upstream branch as it needs to be updated with another repacked upstream release from which the CC BY-NC-SA documentation is also removed. I have already deleted the 8.2.0+dfsg tag, you should delete that in your local copy too. Did you see the related lintian issue? missing-field-in-dep5-copyright License [debian/copyright:252] Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Switching SAGA to cmake
On 4/14/22 10:36, Johan Van de Wauw wrote: As SAGA is switching to cmake[1], I'm now adjusting the debian package build to use cmake as well. For now I managed to build a working package, but I've disabled two tools [2]. If I enable them, I get these errors: -- :CMake Error at src/tools/io/io_shapes_dxf/CMakeLists.txt:10 (target_include_directories): Cannot specify include directories for target "io_shapes_dxf" which is not built by this project. CMake Error at src/tools/io/io_shapes_dxf/CMakeLists.txt:11 (target_link_libraries): Cannot specify link libraries for target "io_shapes_dxf" which is not built by this project. -- if anyone has an idea why this happens, feel free to help fixing the issue. " The named must have been created by a command such as add_executable() or add_library() and must not be an ALIAS target. " https://cmake.org/cmake/help/latest/command/target_include_directories.html saga-gis/src/tools/CMakePluginTemplate.cmake call add_library and should likely be included after the project() call instead of at the end of the file. Please act on the issues raised on the pkg-grass-devel lists: https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2022-April/094097.html https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2022-April/094087.html https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2022-April/094086.html Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: ruby-netcdf & ruby-hdfeos5 need work for Ruby 3.0
On 3/26/22 16:59, Youhei SASAKI wrote: I just skipped a test to build successfully. We (upstream) will try to fix/update Ruby3 issue this week. Thanks for your work on ruby-netcdf. I see that LICENSE.txt changed to BSD-2-Clause but this is not reflected in debian/copyright. Do you also intend to relicense the debian/* files? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: GeographicLib 2.0
On 3/29/22 16:14, Sebastiaan Couwenberg wrote: GeographicLib 2.0 has been released, which removes the language bindings from the source tree, it also renamed the library from libGeographic to libGeographicLib. Yesterday upstream removed the 2.0 release from the download location on SF which suggests that it was a premature release. The package has already been updated and is in experimental, it will likely need to be updated to 2.0+ds once the 2.0 release is made again to include the changes since the package was first updated to 2.0. The python3-geographlib and node-geographiclib binary packages are no longer built. Popcon shows pretty much no usage of node-geographiclib so its removal is not big deal. python3-geographiclib does have some (but not many) users, likely via python3-geopy which will be broken once GeographLib 2.0 is in unstable. #1008603 has been filed for geopy. There are distrib directories for C and Octave, but none for Python or Node.js at https://sourceforge.net/projects/geographiclib/files/. I have not idea what the future of Python bindings will be, I only know that I won't be packaging it. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: GeographicLib 2.0
On 3/30/22 08:24, Antonio Valentino wrote: Il 29/03/22 16:14, Sebastiaan Couwenberg ha scritto: GeographicLib 2.0 has been released, which removes the language bindings from the source tree, it also renamed the library from libGeographic to libGeographicLib. The python3-geographlib and node-geographiclib binary packages are no longer built. Popcon shows pretty much no usage of node-geographiclib so its removal is not big deal. python3-geographiclib does have some (but not many) users, likely via python3-geopy which will be broken once GeographLib 2.0 is in unstable. #1008603 has been filed for geopy. There are distrib directories for C and Octave, but none for Python or Node.js at https://sourceforge.net/projects/geographiclib/files/. I have not idea what the future of Python bindings will be, I only know that I won't be packaging it. If necessary I could possibly take in charge the packaging and maintenance of python bindings, but, as you say, the source package is not available at the moment and I was not even able to find a NEWS file or a changelog for v2.0. Probably it is better to wait a little bit and see what happens upstream. The Fortran bindings appeared on SourceForge, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008603#25 Keep an eye on the download location: https://sourceforge.net/projects/geographiclib/files/ And repo for the Python bindings: https://github.com/geographiclib/geographiclib-python Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
GeographicLib 2.0
GeographicLib 2.0 has been released, which removes the language bindings from the source tree, it also renamed the library from libGeographic to libGeographicLib. The python3-geographlib and node-geographiclib binary packages are no longer built. Popcon shows pretty much no usage of node-geographiclib so its removal is not big deal. python3-geographiclib does have some (but not many) users, likely via python3-geopy which will be broken once GeographLib 2.0 is in unstable. #1008603 has been filed for geopy. There are distrib directories for C and Octave, but none for Python or Node.js at https://sourceforge.net/projects/geographiclib/files/. I have not idea what the future of Python bindings will be, I only know that I won't be packaging it. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
