From j1 at jimenezshaw.com Mon Feb 2 09:39:34 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Mon, 2 Feb 2026 18:39:34 +0100 Subject: [gdal-dev] FLIR thermal with embedded image In-Reply-To: <51cb221a-fcd5-4cec-b616-fa03a55bd014@spatialys.com> References: <51cb221a-fcd5-4cec-b616-fa03a55bd014@spatialys.com> Message-ID: Hi Even I was not able to achieve that, sorry. So finally I made the PR with an original image. If anybody has one image that works I can still replace mine. Thanks On Sat, 31 Jan 2026 at 03:20, Even Rouault wrote: > Javier, > > What about the hard core GDAL contributor way of starting with a small > JPEG image and then adding the needed bytes with your favorite hexadecimal > editor :-) ? > > Otherwise, still a bit of use of your hexadecimal editor, but just to find > out a couple offfset/lenghts, you may try the trick of starting from an > existing file, keeping the begin in a part, the end in the other part, and > omitting most of the embedded image using a /vsisparse/ .XML file and > replacing it with a at zero. Like > https://github.com/OSGeo/gdal/blob/master/autotest/gdrivers/data/grib/rotated_pole.grb2.xml > and then you use "/vsisparse/your.xml" as a valid JPEG dataset name. > > Or variation of the above, perhaps a bit less convoluted, start with your > initial image, set to the zero byte unneeded ranges, and zip it. > > Even > Le 30/01/2026 ? 10:43, Javier Jimenez Shaw via gdal-dev a ?crit : > > Hi > > TL;DR: I need a "small" FLIR image file for a unit test in GDAL. Do you > have one? > > I am working on GDAL's thermal jpeg code, to read an embedded RGB image > that some FLIR cameras are including inside the JPEG, in addition to the > thermal information/image. > > I want to add a unit test with a real image, but unfortunately I only have > "big" images, around 4 or 5 MB. > > It would be great if anybody has a smaller image that can be included in > the GDAL tests code (with the copyright/license permissions that it has). > The model "FLIR T640" I think produces images of about 1.5 MB only. But it > can be other models as well. > > To check if it has the Embedded Image, just run this: > > exiftool -EmbeddedImage filename.jpg > > If you see any output, please contact me. > > Thank you! > > _______________________________________________ > gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- http://www.spatialys.com > My software is free, but my time generally not. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Mon Feb 2 10:02:53 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 2 Feb 2026 19:02:53 +0100 Subject: [gdal-dev] FLIR thermal with embedded image In-Reply-To: References: <51cb221a-fcd5-4cec-b616-fa03a55bd014@spatialys.com> Message-ID: Javier, I've just added a commit in your pull request to replace your image with a smaller one. I've started from autotest/gdrivers/data/jpeg/flir/FLIR.jpg and then hacked record 2 of type 32 (FLIR_REC_CAMERA_INFO) with data at offset 0xC7E + 1352 by replacing it by type 14 (FLIR_REC_EMBEDDEDIMAGE), and then I copied & pasted the content of a 2x1 JPEG image at offset 0xC7E + 1352 + 32. This resulting image is of course non sensical, but enough for our purposes. Even Le 02/02/2026 ? 18:39, Javier Jimenez Shaw a ?crit?: > Hi Even > > I was not able to achieve that, sorry. So finally I made the PR with > an original image. > If anybody has one image that works I can still replace mine. > > Thanks > > On Sat, 31 Jan 2026 at 03:20, Even Rouault > wrote: > > Javier, > > What about the hard core GDAL contributor way of starting with a > small JPEG image and then adding the needed bytes with your > favorite hexadecimal editor :-) ? > > Otherwise, still a bit of use of your hexadecimal editor, but just > to find out a couple offfset/lenghts, you may try the trick of > starting from an existing file, keeping the begin in a part, the > end in the other part, and omitting most of the embedded image > using a /vsisparse/ .XML file and replacing it with a > at zero. Like > https://github.com/OSGeo/gdal/blob/master/autotest/gdrivers/data/grib/rotated_pole.grb2.xml > ?and then you use "/vsisparse/your.xml" as a valid JPEG dataset name. > > Or variation of the above, perhaps a bit less convoluted, start > with your initial image, set to the zero byte unneeded ranges, and > zip it. > > Even > > Le 30/01/2026 ? 10:43, Javier Jimenez Shaw via gdal-dev a ?crit?: >> Hi >> >> TL;DR: I need a "small" FLIR image file for a unit test in GDAL. >> Do you have one? >> >> I am working on GDAL's thermal jpeg code, to read an embedded RGB >> image that some FLIR cameras are including inside the JPEG, in >> addition to the thermal information/image. >> >> I want to add a unit test with a real image, but unfortunately I >> only have "big" images, around 4 or 5 MB. >> >> It would be great if anybody has a smaller image that can be >> included in the GDAL tests code (with the copyright/license >> permissions that it has). >> The model "FLIR T640" I think produces images of about 1.5 MB >> only. But it can be other models as well. >> >> To check if it has the Embedded Image, just run this: >> >> exiftool -EmbeddedImage filename.jpg >> >> If you see any output, please contact me. >> >> Thank you! >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > http://www.spatialys.com > My software is free, but my time generally not. > -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Tue Feb 3 06:56:28 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 3 Feb 2026 15:56:28 +0100 Subject: [gdal-dev] GDAL 3.12.2 release candidate Message-ID: <1d496425-d266-4d9a-9445-999174b5301c@spatialys.com> Hi, I have prepared a GDAL/OGR 3.12.2 bugfix release candidate. Pick up an archive among the following ones (by ascending size): ? https://download.osgeo.org/gdal/3.12.2/gdal-3.12.2rc1.tar.xz ? https://download.osgeo.org/gdal/3.12.2/gdal-3.12.2rc1.tar.gz ? https://download.osgeo.org/gdal/3.12.2/gdal3122rc1.zip A snapshot of the gdalautotest suite is also available: https://download.osgeo.org/gdal/3.12.2/gdalautotest-3.12.2rc1.zip The NEWS file is here: ? https://github.com/OSGeo/gdal/blob/v3.12.2RC1/NEWS.md I'll call for a vote in a couple days if no serious issues are reported before. Best regards, Even -- http://www.spatialys.com My software is free, but my time generally not. From gdt at lexort.com Wed Feb 4 04:01:19 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 04 Feb 2026 07:01:19 -0500 Subject: [gdal-dev] GDAL 3.12.2 release candidate In-Reply-To: <1d496425-d266-4d9a-9445-999174b5301c@spatialys.com> (Even Rouault via gdal-dev's message of "Tue, 3 Feb 2026 15:56:28 +0100") References: <1d496425-d266-4d9a-9445-999174b5301c@spatialys.com> Message-ID: Even Rouault via gdal-dev writes: > ? https://download.osgeo.org/gdal/3.12.2/gdal-3.12.2rc1.tar.xz Builds warning free on NetBSD 10 amd64 and aarch64 (gcc10). With it installed, qgis works on amd64. So looks fine from here. From gdal at aitchison.me.uk Thu Feb 5 01:40:18 2026 From: gdal at aitchison.me.uk (Andrew C Aitchison) Date: Thu, 5 Feb 2026 09:40:18 +0000 (GMT) Subject: [gdal-dev] QGIS - was Re: GDAL 3.12.2 release candidate Message-ID: On Wed, 4 Feb 2026, Greg Troxel via gdal-dev wrote: > Builds warning free on NetBSD 10 amd64 and aarch64 (gcc10). > With it installed, qgis works on amd64. Is that a custom-built qgis, or can the system qgis use the new gdal libraries ? Although I build the latest gdal frequently on Linux I am still using the system libgdal with the system qgis, which is a waste of an opportunity to test, but I haven't attempted to keep rebuilding qgis against each new gdal. Am I missing something ? -- Andrew C. Aitchison Kendal, UK andrew at aitchison.me.uk From even.rouault at spatialys.com Thu Feb 5 04:18:47 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 5 Feb 2026 13:18:47 +0100 Subject: [gdal-dev] Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 Message-ID: Hi, Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. From jukka.rahkonen at maanmittauslaitos.fi Thu Feb 5 04:42:57 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Thu, 5 Feb 2026 12:42:57 +0000 Subject: [gdal-dev] Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 In-Reply-To: References: Message-ID: +1 -Jukka Rahkonen- ________________________________________ L?hett?j?: gdal-dev k?ytt?j?n Even Rouault via gdal-dev puolesta L?hetetty: Torstai 5. helmikuuta 2026 14.18 Vastaanottaja: gdal-dev at lists.osgeo.org Aihe: [gdal-dev] Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 Hi, Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 starting with my +1 Even -- http://www.spatialys.com/ My software is free, but my time generally not. _______________________________________________ gdal-dev mailing list gdal-dev at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev From szekerest at gmail.com Thu Feb 5 04:46:25 2026 From: szekerest at gmail.com (Tamas Szekeres) Date: Thu, 5 Feb 2026 13:46:25 +0100 Subject: [gdal-dev] Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 In-Reply-To: References: Message-ID: +1 Tamas Even Rouault via gdal-dev ezt ?rta (id?pont: 2026. febr. 5., Cs, 13:18): > Hi, > > Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 > > starting with my +1 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Thu Feb 5 04:46:22 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Thu, 5 Feb 2026 13:46:22 +0100 Subject: [gdal-dev] Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 In-Reply-To: References: Message-ID: +1 Javier On Thu, 5 Feb 2026 at 13:43, Rahkonen Jukka via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > +1 > > -Jukka Rahkonen- > > ________________________________________ > L?hett?j?: gdal-dev k?ytt?j?n Even > Rouault via gdal-dev puolesta > L?hetetty: Torstai 5. helmikuuta 2026 14.18 > Vastaanottaja: gdal-dev at lists.osgeo.org > Aihe: [gdal-dev] Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 > > > Hi, > > Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 > > starting with my +1 > > Even > > -- > http://www.spatialys.com/ > My software is free, but my time generally not. > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Thu Feb 5 04:56:49 2026 From: gdt at lexort.com (Greg Troxel) Date: Thu, 05 Feb 2026 07:56:49 -0500 Subject: [gdal-dev] QGIS - was Re: GDAL 3.12.2 release candidate In-Reply-To: (Andrew C. Aitchison via gdal-dev's message of "Thu, 5 Feb 2026 09:40:18 +0000 (GMT)") References: Message-ID: Andrew C Aitchison via gdal-dev writes: > On Wed, 4 Feb 2026, Greg Troxel via gdal-dev wrote: > >> Builds warning free on NetBSD 10 amd64 and aarch64 (gcc10). >> With it installed, qgis works on amd64. > > Is that a custom-built qgis, or can the system qgis use > the new gdal libraries ? NetBSD's base system includes only things that are traditionally part of UNIX, or would be today (cat, cc, and so on). So there is no such thing as "system qgis". pkgsrc is used to build the vast amount of software beyond the base, and that includes qgis, gdal, etc. I have qgis as /usr/pkg/bin/qgis, and that links to a bunch of libraries, the non-base-UNIXy of which are in /usr/pkg/lib. # Full output 223 lines - much snipped. $ ldd /usr/pkg/bin/qgis /usr/pkg/bin/qgis: -lexecinfo.0 => /usr/lib/libexecinfo.so.0 -lelf.2 => /usr/lib/libelf.so.2 -lc.12 => /usr/lib/libc.so.12 -lgcc_s.1 => /usr/lib/libgcc_s.so.1 -lqgis_app.3.44.7 => /usr/pkg/lib/libqgis_app.so.3.44.7 -lqwt.6.3 => /usr/pkg/qwt-6.3.0/lib/libqwt.so.6.3 -lQt5PrintSupport.5 => /usr/pkg/qt5/lib/libQt5PrintSupport.so.5 -lQt5Widgets.5 => /usr/pkg/qt5/lib/libQt5Widgets.so.5 -lQt5Gui.5 => /usr/pkg/qt5/lib/libQt5Gui.so.5 -lQt5Core.5 => /usr/pkg/qt5/lib/libQt5Core.so.5 -lz.1 => /usr/lib/libz.so.1 -ldouble-conversion.3 => /usr/pkg/lib/libdouble-conversion.so.3 -lstdc++.9 => /usr/lib/libstdc++.so.9 -lm.0 => /usr/lib/libm.so.0 -licui18n.78 => /usr/pkg/lib/libicui18n.so.78 -licuuc.78 => /usr/pkg/lib/libicuuc.so.78 ... -lgdal.38 => /usr/pkg/lib/libgdal.so.38 -larchive.5 => /usr/lib/libarchive.so.5 -llzma.2 => /usr/lib/liblzma.so.2 -lxml2.16 => /usr/pkg/lib/libxml2.so.16 -lqhull_r.8.0 => /usr/pkg/lib/libqhull_r.so.8.0 -lxerces-c-3.3 => /usr/pkg/lib/libxerces-c-3.3.so -ljpeg.8 => /usr/pkg/lib/libjpeg.so.8 -ltiff.6 => /usr/pkg/lib/libtiff.so.6 ... -lpython3.13.1.0 => /usr/pkg/lib/libpython3.13.so.1.0 -lutil.7 => /usr/lib/libutil.so.7 When viewed from the perspective of GNU/Linux distributions which have (from the traditonal UNIX perspective) merged base/packages in /usr, /usr/pkg/bin/qgis is "system" qgis in that it was installed by the packaging system rather than built by the user. I am the package maintainer for qgis and gdal (and others), so what I do is update the packaging entry for gdal from 3.12.1 (which is what the rest of the world sees) to 3.12.2rc1 and rebuild the package and then update the system with that package. So on my computer I have: $ ls -l /usr/pkg/lib/libgdal.so* lrwxr-xr-x 1 root wheel 13 Feb 3 13:37 /usr/pkg/lib/libgdal.so -> libgdal.so.38 lrwxr-xr-x 1 root wheel 20 Feb 3 13:37 /usr/pkg/lib/libgdal.so.38 -> libgdal.so.38.3.12.2 -rwxr-xr-x 1 root wheel 29683336 Feb 3 13:37 /usr/pkg/lib/libgdal.so.38.3.12.2 qgis thus uses that when it starts because it was linked against libgdal.so.38 and that resolves. Because there was no API/ABI change in a micro, I don't need to rebuild it. If I do need to rebuild qgis, because of API/ABI changes, I'd "make replace" in /usr/pkgsrc/geography/qgis afterwards. (Really, I'd use a tool that finds packages with dependencies changed out from under them and runs make replace in all of them, in tsorted order.) > Although I build the latest gdal frequently on Linux I am still using > the system libgdal with the system qgis, which is a waste of an > opportunity to test, but I haven't attempted to keep rebuilding qgis > against each new gdal. Am I missing something ? I have never really been clear on GNU/Linux packaging (and don't know which flavor you are using, Debian, Fedora, Suse, or one of the boutique systems). The pkgsrc attitude is source first, so the standard approach is for someone to "make package" (which downloads the sources, recurses into dependencies, unpacks, builds, installs in a destdir, and tars that up) and then "make package-install" or "make replace". (Binary packages are available for popular OS/version/cpu combinations as a time-saving measure for people that want to use that. With a vax, you usually have to build your own :-) ) I have the impression that most/all? GNU/Linux packaging systems are also like this, and you can get the control files, and then modify them to point to the new gdal release, build a package, and then update your system with it. For micro releases, I suspect you can just do this and then run qgis, checking with ldd to see what it links with. For non-micro, you would then want to get the control files for qgis and then build/replace a package. An alternative would be to set up another prefix, say /usr/osgeo, and then build gdal and install with --with-prefix=/usr/osgoe, and then qgis, passing in CPPFLAGS=-I/usr/osgeo, LDFLAGS="-L/usr/osgeo/lib -R/usr/osgeo/lib" and similar for pkg-config so the .pc files there will be found in preference to those in /usr. This is not easy as sometimes packages assume they are on linux and only work in /usr. pkgsrc, in addition to having control files to say how to build the package, has an accumulation of patches to remediate non-portability. We (especially I) try to push these upstream. I definitely encourage you to use the packaging system to build gdal and replace it, and rebuild other things as needed. This ought to be straightforward and maybe it is. It just seems to be culture that nobody does it. If you work out how to do this it would be great to explain to others. If it's just me that's confused and it's a well-trodden well-documented path a link would be great. From gdt at lexort.com Thu Feb 5 07:44:44 2026 From: gdt at lexort.com (Greg Troxel) Date: Thu, 05 Feb 2026 10:44:44 -0500 Subject: [gdal-dev] QGIS - was Re: GDAL 3.12.2 release candidate In-Reply-To: <8baff3f8-9174-3171-dbdf-55a91306fef1@aitchison.me.uk> (Andrew C. Aitchison's message of "Thu, 5 Feb 2026 15:31:04 +0000 (GMT)") References: <8baff3f8-9174-3171-dbdf-55a91306fef1@aitchison.me.uk> Message-ID: Andrew C Aitchison writes: > On Thu, 5 Feb 2026, Greg Troxel via gdal-dev wrote: > >> Andrew C Aitchison via gdal-dev writes: > > There are newer package types like snap and flatpak which are supposed > to be flavour-agnostic (snap seems to be Debian and Ubuntu-only) > and allow *users* to install them without being root (typically using > a container to isolate the machine from the application). FWIW pkgsrc can be run as a user as long as you bootstrap it to a prefix you can write. I used to use $HOME/pkg on a Debian system where I didn't have root. >> For micro releases, I suspect you can just do this and then run qgis, >> checking with ldd to see what it links with. >> >> For non-micro, you would then want to get the control files for qgis and >> then build/replace a package. > > Current Ubuntu (Questing, 25-10) comes with gdal 3.10.3 and qgis 3.40.5. That seems surprisingly out of date at first glance, but I guess that's only from April of 2025. > I like to keep several versions around so that I can check for > regressions and other changed behaviour. > For example if I find a problem whilst testing the GDAL 3.12.2 release > candidate, it is useful to be clear whether the problem was present > in say 3.11.x, 3.12.0 or 3.12.1. > > As you say qgis can be made to use a different/newer micro release, > but I was hoping you had found a way around needing to rebuild qgis for > each mini-release of gdal. I don't think there is a way. I use ccache, and I find that it doesn't really take all that long. I think you're heading down a path where you want the cross product of qgis and gdal versions, and that just is n*m. Personally, and with pkgsrc hat on, I don't pay attention to releases older than what pkgsrc has, and I try to keep pkgsrc updated to the most recent release that feels responible to update to. GDAL has been very stable with no significant issues introduced in minor releases, so while I do verify that my qgis project opens and shows data, I don't worry much. Sounds like you are testing what you need to. I find the "one is installed in the system at any given time" approach to help sanity, and if I wanted to check old gdal I'd just checkout the gdal pkgsrc bits for the old version, make replace, and then rebuild depending packages. But so far I have been able to avoid caring about older versions. From gdal at aitchison.me.uk Thu Feb 5 07:46:09 2026 From: gdal at aitchison.me.uk (Andrew C Aitchison) Date: Thu, 5 Feb 2026 15:46:09 +0000 (GMT) Subject: [gdal-dev] QGIS - was Re: GDAL 3.12.2 release candidate In-Reply-To: References: Message-ID: <11938349-47ef-1074-d815-dea362b4f89a@aitchison.me.uk> On Thu, 5 Feb 2026, Greg Troxel via gdal-dev wrote: > Andrew C Aitchison via gdal-dev writes: > >> On Wed, 4 Feb 2026, Greg Troxel via gdal-dev wrote: >> >>> Builds warning free on NetBSD 10 amd64 and aarch64 (gcc10). >>> With it installed, qgis works on amd64. >> >> Is that a custom-built qgis, or can the system qgis use >> the new gdal libraries ? > > NetBSD's base system includes only things that are traditionally part of > UNIX, or would be today (cat, cc, and so on). So there is no such thing > as "system qgis". pkgsrc is used to build the vast amount of software > beyond the base, and that includes qgis, gdal, etc. I have qgis as > /usr/pkg/bin/qgis, and that links to a bunch of libraries, the > non-base-UNIXy of which are in /usr/pkg/lib. > > # Full output 223 lines - much snipped. > $ ldd /usr/pkg/bin/qgis > /usr/pkg/bin/qgis: > -lexecinfo.0 => /usr/lib/libexecinfo.so.0 > -lelf.2 => /usr/lib/libelf.so.2 > -lc.12 => /usr/lib/libc.so.12 > -lgcc_s.1 => /usr/lib/libgcc_s.so.1 > -lqgis_app.3.44.7 => /usr/pkg/lib/libqgis_app.so.3.44.7 > -lqwt.6.3 => /usr/pkg/qwt-6.3.0/lib/libqwt.so.6.3 > -lQt5PrintSupport.5 => /usr/pkg/qt5/lib/libQt5PrintSupport.so.5 > -lQt5Widgets.5 => /usr/pkg/qt5/lib/libQt5Widgets.so.5 > -lQt5Gui.5 => /usr/pkg/qt5/lib/libQt5Gui.so.5 > -lQt5Core.5 => /usr/pkg/qt5/lib/libQt5Core.so.5 > -lz.1 => /usr/lib/libz.so.1 > -ldouble-conversion.3 => /usr/pkg/lib/libdouble-conversion.so.3 > -lstdc++.9 => /usr/lib/libstdc++.so.9 > -lm.0 => /usr/lib/libm.so.0 > -licui18n.78 => /usr/pkg/lib/libicui18n.so.78 > -licuuc.78 => /usr/pkg/lib/libicuuc.so.78 > ... > -lgdal.38 => /usr/pkg/lib/libgdal.so.38 > -larchive.5 => /usr/lib/libarchive.so.5 > -llzma.2 => /usr/lib/liblzma.so.2 > -lxml2.16 => /usr/pkg/lib/libxml2.so.16 > -lqhull_r.8.0 => /usr/pkg/lib/libqhull_r.so.8.0 > -lxerces-c-3.3 => /usr/pkg/lib/libxerces-c-3.3.so > -ljpeg.8 => /usr/pkg/lib/libjpeg.so.8 > -ltiff.6 => /usr/pkg/lib/libtiff.so.6 > ... > -lpython3.13.1.0 => /usr/pkg/lib/libpython3.13.so.1.0 > -lutil.7 => /usr/lib/libutil.so.7 > > When viewed from the perspective of GNU/Linux distributions which have > (from the traditonal UNIX perspective) merged base/packages in /usr, > /usr/pkg/bin/qgis is "system" qgis in that it was installed by the > packaging system rather than built by the user. > > I am the package maintainer for qgis and gdal (and others), so what I do > is update the packaging entry for gdal from 3.12.1 (which is what the > rest of the world sees) to 3.12.2rc1 and rebuild the package and then > update the system with that package. So on my computer I have: > > $ ls -l /usr/pkg/lib/libgdal.so* > lrwxr-xr-x 1 root wheel 13 Feb 3 13:37 /usr/pkg/lib/libgdal.so -> libgdal.so.38 > lrwxr-xr-x 1 root wheel 20 Feb 3 13:37 /usr/pkg/lib/libgdal.so.38 -> libgdal.so.38.3.12.2 > -rwxr-xr-x 1 root wheel 29683336 Feb 3 13:37 /usr/pkg/lib/libgdal.so.38.3.12.2 > > qgis thus uses that when it starts because it was linked against > libgdal.so.38 and that resolves. Because there was no API/ABI change in > a micro, I don't need to rebuild it. If I do need to rebuild qgis, > because of API/ABI changes, I'd "make replace" in > /usr/pkgsrc/geography/qgis afterwards. (Really, I'd use a tool that > finds packages with dependencies changed out from under them and runs > make replace in all of them, in tsorted order.) > >> Although I build the latest gdal frequently on Linux I am still using >> the system libgdal with the system qgis, which is a waste of an >> opportunity to test, but I haven't attempted to keep rebuilding qgis >> against each new gdal. Am I missing something ? > > I have never really been clear on GNU/Linux packaging (and don't know > which flavor you are using, Debian, Fedora, Suse, or one of the boutique > systems). The pkgsrc attitude is source first, so the standard approach > is for someone to "make package" (which downloads the sources, recurses > into dependencies, unpacks, builds, installs in a destdir, and tars that > up) and then "make package-install" or "make replace". (Binary packages > are available for popular OS/version/cpu combinations as a time-saving > measure for people that want to use that. With a vax, you usually have > to build your own :-) ) > > I have the impression that most/all? GNU/Linux packaging systems are > also like this, and you can get the control files, and then modify them > to point to the new gdal release, build a package, and then update your > system with it. That is correct for Red Hat and Ubuntu from personal experience; and I assume also for other .rpm or .deb based systems. There are newer package types like snap and flatpak which are supposed to be flavour-agnostic (snap seems to be Debian and Ubuntu-only) and allow *users* to install them without being root (typically using a container to isolate the machine from the application). > For micro releases, I suspect you can just do this and then run qgis, > checking with ldd to see what it links with. > > For non-micro, you would then want to get the control files for qgis and > then build/replace a package. Current Ubuntu (Questing, 25-10) comes with gdal 3.10.3 and qgis 3.40.5. I like to keep several versions around so that I can check for regressions and other changed behaviour. For example if I find a problem whilst testing the GDAL 3.12.2 release candidate, it is useful to be clear whether the problem was present in say 3.11.x, 3.12.0 or 3.12.1. As you say qgis can be made to use a different/newer micro release, but I was hoping you had found a way around needing to rebuild qgis for each mini-release of gdal. [ This is also a killer for publishing out-of-tree gdal drivers and building drivers from source is beyond a substantial class of potential QGIS users :-( ] > An alternative would be to set up another prefix, say /usr/osgeo, and > then build gdal and install with --with-prefix=/usr/osgoe, and then > qgis, passing in CPPFLAGS=-I/usr/osgeo, LDFLAGS="-L/usr/osgeo/lib > -R/usr/osgeo/lib" and similar for pkg-config so the .pc files there will > be found in preference to those in /usr. This is not easy as sometimes > packages assume they are on linux and only work in /usr. pkgsrc, in > addition to having control files to say how to build the package, has an > accumulation of patches to remediate non-portability. We (especially I) > try to push these upstream. Yes, I'm there for gdal, but I having been poking inside QGIS so haven't wanted/needed to setup mutiple copies of that. > I definitely encourage you to use the packaging system to build gdal and > replace it, and rebuild other things as needed. This ought to be > straightforward and maybe it is. It just seems to be culture that > nobody does it. That is great and what I did as a sysadmin for a department-full of machines, but with my developer hat on, both package systems only allow a single version at a time. 'alternatives' allows two or more well-coordinated packages to be installed at the same time and for the sysadmin to choose which one is the system default, but this is designed for alternate implementations rather that successive versions... 'environment-modules' allows a user (or script) to switch which version is active in the current context. I have worked hard and have a single script which builds my gdal drivers with two compilers for each of (up to) about a dozen micro-versions of gdal. Since the package system is not designed for multiple concurrently installed versions, I haven't bothered to package each version ... > If you work out how to do this it would be great to explain to others. > If it's just me that's confused and it's a well-trodden well-documented > path a link would be great. -- Andrew C. Aitchison Kendal, UK andrew at aitchison.me.uk From howard at hobu.co Thu Feb 5 08:19:32 2026 From: howard at hobu.co (Howard Butler) Date: Thu, 5 Feb 2026 11:19:32 -0500 Subject: [gdal-dev] Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 In-Reply-To: References:

Message-ID: +1 Howard > On Feb 5, 2026, at 7:46?AM, Javier Jimenez Shaw via gdal-dev wrote: > > +1 Javier > > On Thu, 5 Feb 2026 at 13:43, Rahkonen Jukka via gdal-dev > wrote: >> +1 >> >> -Jukka Rahkonen- >> >> ________________________________________ >> L?hett?j?: gdal-dev > k?ytt?j?n Even Rouault via gdal-dev > puolesta >> L?hetetty: Torstai 5. helmikuuta 2026 14.18 >> Vastaanottaja: gdal-dev at lists.osgeo.org

> >> Aihe: [gdal-dev] Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 >> >> >> Hi, >> >> Motion: approve GDAL 3.12.2 RC1 as final 3.12.2 >> >> starting with my +1 >> >> Even >> >> -- >> http://www.spatialys.com/ >> My software is free, but my time generally not. >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: