From gdt at lexort.com Sun Nov 2 07:44:47 2025 From: gdt at lexort.com (Greg Troxel) Date: Sun, 02 Nov 2025 10:44:47 -0500 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? Message-ID: I saw 3.40.12 and updated pkgsrc, and the .12 being pretty high made me guess that there was a new LTR and I should look at it. I went to read https://qgis.org/resources/roadmap/ and after staring at it for a long time, my take is: - 3.44 is *going to be* LTR, but will not be blessed as such until 3.44.8 in February - What is unusual is that LTR will be 3.44.8, not 3.46.4, because there was no 3.46 in 2025-10, but we're still holding off until February, because some blend of + LTR promotion is always February + LTR promotion of a future-LTR happens only when the next branch .0 comes out. - 4.2 will become LTR in 2026-10, which is out of cycle, and probably we'll then see 4.8 in 2027-10 with LTRs happening on October instead of February. (That's an observation not a complaint.) If I'm confused a clue would be appreciated, and if 99.9% of the list was already super clear sorry for the noise. Separately, given that pkgsrc is on the fence between "latest release is fine" and "LTR is more stable and better", I should be planning to switch from 3.40.x to 3.44.x, and any time between now and just after the LTR-blessing of 3.44 on 2026-02-20 is a reasonable time to do that. (I am building 3.44.4 from source and it's halfway through.) My impression is that 3.44 is entirely stable and that for normal users (not trying to coordinate with other packaging systems in big organizations, and not having the LTS "running old code on purpose is good" outlook), there is no real reason to stay on 3.40. It is clear that I should try to package 4.0, or even 3.99, but as a separate/experimental package, to surface and resolve qt6 issues. From clhermansen at gmail.com Sun Nov 2 08:10:12 2025 From: clhermansen at gmail.com (chris hermansen) Date: Sun, 2 Nov 2025 08:10:12 -0800 Subject: [QGIS-Developer] QGIS on Ubuntu 25.10 Message-ID: I would like to offer a big thank you for finding QGIS available on Ubuntu 25.10 this past week after belatedly upgrading. Really appreciated! Chris Hermansen ? clhermansen "at" gmail "dot" com C'est ma fa?on de parler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Mon Nov 3 05:17:21 2025 From: gdt at lexort.com (Greg Troxel) Date: Mon, 03 Nov 2025 08:17:21 -0500 Subject: [QGIS-Developer] precompiled headers, turning off Message-ID: Building 3.44 on NetBSD (using ccache in our compiler wrappers and disabled in qgis) I'm getting errors about precompiled headers: [110/5655] Building CXX object src/core/CMakeFiles/qgis_core.dir/symbology/qgssymbollayerreference.cpp.o cc1plus: warning: /tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx.gch: had text segment at different address >From searching, it seems that gcc pch is buggy in the presence of ASLR, and that this causes ccache not to cache. Indeed, I get repeated misses. So I tried CMAKE_CONFIGURE_ARGS+= -DUSE_PRECOMPILED_HEADERS:BOOL=FALSE which not surprisingly adds the rhs to the cmake invocation, but no change. Grepping the diff from 3.40 to 3.44 (I am ignoring 3.42 on purpose), I see $ git diff ..release-3_44 |egrep PRECOM + set(USE_PRECOMPILED_HEADERS OFF) + set(USE_PRECOMPILED_HEADERS ON) +if (USE_PRECOMPILED_HEADERS) +if (USE_PRECOMPILED_HEADERS) +if (USE_PRECOMPILED_HEADERS) +if(USE_PRECOMPILED_HEADERS) +if (USE_PRECOMPILED_HEADERS) +if (USE_PRECOMPILED_HEADERS) and I don't see an option declaration or a way for the cmake invoker to say don't do that. I'm about to patch to always OFF and will see how that goes. I wonder if people think this is a bug, and if it's turning up on other systems with ASLR, or if it's only the combination of older gcc (I'm using 10) and ASLR. (As an aside, this wasn't listed in NEWS, and I'm finding it to be a significant user-visible change, as I consider compiling from source to be a user activity for a Free Software project. I realize it was intended to be invisible, but I view pch as hairy and not normal, having started C with K&R first edition.) From julien.cabieces at oslandia.com Mon Nov 3 08:45:08 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Mon, 03 Nov 2025 17:45:08 +0100 Subject: [QGIS-Developer] Dirtying project within model classes or not Message-ID: <87a513oyjv.fsf@julienlaptop.home> Hi all, I recently faced a strong disagreement about a design question that I would like to discuss so we could take a decision on what it's best to do. The discussion starts here [0] According to Nyall: "dirtying is a gui/app level operation, which should only occur as a direct result of user operations (as opposed to say a script/plugin/process calling a particular piece of API)" I strongly disagree, I think setDirty() calls should be made within model classes, not in widgets. A plugin script that would modify a model object expects the project to be dirty. If not, modifications made by the script could simply be lost when closing the project without even prompting user about unsaved modifications. In several (most?) occasions (here for instances [1], [2]) it's done in the model part, but there are actually some where it was not the case. I was considering those as issues, but it seems that we have different view on the matter. So, I'd like to know if we should: - always dirty the project within model classes - never dirty the project within model classes - it depends... Regards, Julien [0] https://github.com/qgis/QGIS/pull/63498#discussion_r2425462712 [1] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L490 [2] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L975 -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From gdt at lexort.com Mon Nov 3 14:54:15 2025 From: gdt at lexort.com (Greg Troxel) Date: Mon, 03 Nov 2025 17:54:15 -0500 Subject: [QGIS-Developer] precompiled headers buggy, how to disable, compilation error In-Reply-To: (Greg Troxel via's message of "Mon, 03 Nov 2025 08:17:21 -0500") References: Message-ID: This is a known problem with gcc, sort of addressed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934 After failing to disable pch with cmake, I edited the CMakeFiles where target_precompiled_header existed and just removed it. Building again, I don't get the warning, and things are mostly ok. One file failed to build, and after fixing it (see below), I was able to get the build to complete. My question is: Is there a way to add something to the cmake line to disable precompiled headers? (It really seems like there should be.) Greg * src/core/pal/priorityqueue.cpp I got a complaint that was likely missing. I am guessing that somehow precompiled headers include it somehow when building in that mode -- although that seems buggy. I added a patch and it built. But obviously it's building for ~everybody else. I wonder if others, if you remove the "target_precompiled_headers" line, can build this file. The patch: --- src/core/pal/priorityqueue.cpp.orig 2025-11-03 18:44:19.775172737 +0000 +++ src/core/pal/priorityqueue.cpp @@ -28,6 +28,7 @@ */ #include +#include #include "internalexception.h" #include "priorityqueue.h" The error output (without the patch): FAILED: [code=1] src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o /tmp/work/geography/qgis/work/.cwrapper/bin/c++ -DCMAKE_SOURCE_DIR=\"/tmp/work/geography/qgis/work/qgis-3.44.4\" -DPROTOBUF_USE_DLLS -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x050800 -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_SERIALPORT_LIB -DQT_SQL_LIB -DQT_SVG_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DSIP_VERSION=0x060c00 -DTEST_DATA_DIR=\"/tmp/work/geography/qgis/work/qgis-3.44.4/tests/testdata\" -DWITH_COPC -DWITH_EPT -D_HAVE_PTHREAD_ -Dqgis_core_EXPORTS -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build/src/core/qgis_core_autogen/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/poly2tri -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/ept -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/copc -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/vpc -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build/src/core -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/meshOptimizer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/3d -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/actions -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/annotations -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/auth -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/browser -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/callouts -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/classification -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/diagram -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/dxf -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/editform -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/effects -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/elevation -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/expression -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/externalstorage -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/fieldformatter -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/geometry -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/geocoding -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/gps -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/labeling -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/labeling/rules -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/layertree -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/layout -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/locator -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/maprenderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/mesh -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/metadata -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/network -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/numericformats -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/painting -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pdf -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/plot -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pointcloud -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pointcloud/expression -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/processing -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/processing/models -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/proj -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/project -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/arcgis -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/memory -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/gdal -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/ogr -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/meshmemory -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/sensorthings -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/raster -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/renderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/scalebar -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/settings -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/sensor -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/stac -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/symbology -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/textrenderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/tiledscene -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/validity -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/vector -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/vectortile -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/web -I/tmp/work/geography/qgis/work/qgis-3.44.4/external -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/delaunator-cpp -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/kdbush/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/nmea -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/rtree/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/tinygltf -isystem /usr/pkg/qt5/include/Qca-qt5/QtCrypto -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtCore -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/./mkspecs/netbsd-g++ -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtGui -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtXml -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtWidgets -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSvg -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtNetwork -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSql -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtConcurrent -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtPositioning -isystem /tmp/work/geography/qgis/work/.buildlink/include/geos -isystem /usr/pkg/qt5/include -isystem /usr/pkg/qt5/include/QtDBus -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtPrintSupport -isystem /usr/pkg/include -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSerialPort -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.13 -Dz_off_t=long -I/usr/pkg/include/libxml2 -I/usr/pkg/include/minizip -I/usr/pkg/qt5/include -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/harfbuzz -I/usr/pkg/include/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include/libdrm -I/usr/pkg/include/gstreamer-1.0 -I/usr/pkg/qwt-6.3.0/include -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move -Wno-misleading-indentation -Wno-deprecated-copy -std=gnu++17 -fPIC -fvisibility=hidden -fPIC -MD -MT src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o -MF src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o.d -o src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o -c /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp In file included from /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:33: /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:96:12: error: 'unique_ptr' in namespace 'std' does not name a template type 96 | std::unique_ptr heap; | ^~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:37:1: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? 36 | #include +++ |+#include 37 | /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:97:12: error: 'unique_ptr' in namespace 'std' does not name a template type 97 | std::unique_ptr p; | ^~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:97:7: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? 97 | std::unique_ptr p; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:98:12: error: 'unique_ptr' in namespace 'std' does not name a template type 98 | std::unique_ptr pos; | ^~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:98:7: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? 98 | std::unique_ptr pos; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In constructor 'pal::PriorityQueue::PriorityQueue(int, int, bool)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:3: error: 'heap' was not declared in this scope; did you mean 'upheap'? 53 | heap = std::make_unique( maxsize ); | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:15: error: 'make_unique' is not a member of 'std' 53 | heap = std::make_unique( maxsize ); | ^~~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:34:1: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? 33 | #include "priorityqueue.h" +++ |+#include 34 | /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:27: error: expected primary-expression before 'int' 53 | heap = std::make_unique( maxsize ); | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:3: error: 'p' was not declared in this scope 54 | p = std::make_unique( maxsize ); | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:12: error: 'make_unique' is not a member of 'std' 54 | p = std::make_unique( maxsize ); | ^~~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:12: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:24: error: expected primary-expression before 'double' 54 | p = std::make_unique( maxsize ); | ^~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:3: error: 'pos' was not declared in this scope 55 | pos = std::make_unique( maxId + 1 ); | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:14: error: 'make_unique' is not a member of 'std' 55 | pos = std::make_unique( maxId + 1 ); | ^~~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:14: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:26: error: expected primary-expression before 'int' 55 | pos = std::make_unique( maxId + 1 ); | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getBest()': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:84:28: error: 'heap' was not declared in this scope; did you mean 'upheap'? 84 | const int return_value = heap[0]; | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:88:3: error: 'pos' was not declared in this scope 88 | pos[heap[0]] = -1; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:95:5: error: 'p' was not declared in this scope 95 | p[0] = p[size]; | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'bool pal::PriorityQueue::isIn(int) const': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:105:26: error: 'pos' was not declared in this scope 105 | return key <= maxId && pos[key] >= 0; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getId(int) const': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:110:25: error: 'pos' was not declared in this scope 110 | return key <= maxId ? pos[key] : -1; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::insert(int, double)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:118:3: error: 'heap' was not declared in this scope; did you mean 'upheap'? 118 | heap[size] = key; | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:119:3: error: 'pos' was not declared in this scope 119 | pos[key] = size; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:120:9: error: 'class pal::PriorityQueue' has no member named 'p' 120 | this->p[size] = p; | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::remove(int)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:135:17: error: 'pos' was not declared in this scope 135 | const int i = pos[key]; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:140:9: error: 'heap' was not declared in this scope; did you mean 'upheap'? 140 | pos[heap[size]] = i; | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:144:5: error: 'p' was not declared in this scope 144 | p[i] = p[size]; | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::upheap(int)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:177:7: error: 'pos' was not declared in this scope 177 | i = pos[key]; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:183:21: error: 'p' was not declared in this scope 183 | if ( greater( p[PARENT( i )], p[i] ) ) | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:187:13: error: 'heap' was not declared in this scope; did you mean 'upheap'? 187 | pos[heap[i]] = i2; | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::downheap(int)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:220:30: error: 'p' was not declared in this scope 220 | min_child = greater( p[RIGHT( id )], p[LEFT( id )] ) ? LEFT( id ) : RIGHT( id ); | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:228:19: error: 'p' was not declared in this scope 228 | if ( greater( p[id], p[min_child] ) ) | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:230:7: error: 'pos' was not declared in this scope 230 | pos[heap[id]] = min_child; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:230:11: error: 'heap' was not declared in this scope; did you mean 'upheap'? 230 | pos[heap[id]] = min_child; | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::setPriority(int, double)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:255:17: error: 'pos' was not declared in this scope 255 | const int i = pos[key]; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:263:3: error: 'p' was not declared in this scope 263 | p[i] = new_p; | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::decreaseKey(int)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:276:17: error: 'pos' was not declared in this scope 276 | const int i = pos[key]; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:281:3: error: 'p' was not declared in this scope 281 | p[i]--; | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::print()': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:72: error: 'heap' was not declared in this scope; did you mean 'upheap'? 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:81: error: 'pos' was not declared in this scope 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:95: error: 'p' was not declared in this scope 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getSizeByPos() const': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:310:10: error: 'pos' was not declared in this scope 310 | if ( pos[i] >= 0 ) | ^~~ From even.rouault at spatialys.com Mon Nov 3 15:37:49 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 4 Nov 2025 00:37:49 +0100 Subject: [QGIS-Developer] precompiled headers buggy, how to disable, compilation error In-Reply-To: References: Message-ID: <8ada5d6d-eb34-4d5e-8973-02b450b8d724@spatialys.com> adressed per https://github.com/qgis/QGIS/pull/63794 Le 03/11/2025 ? 23:54, Greg Troxel via QGIS-Developer a ?crit?: > This is a known problem with gcc, sort of addressed: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934 > > After failing to disable pch with cmake, I edited the CMakeFiles where > target_precompiled_header existed and just removed it. Building again, > I don't get the warning, and things are mostly ok. One file failed to > build, and after fixing it (see below), I was able to get the build to > complete. > > My question is: > > Is there a way to add something to the cmake line to disable > precompiled headers? (It really seems like there should be.) > > > Greg > > > * src/core/pal/priorityqueue.cpp > > I got a complaint that was likely missing. I am guessing that > somehow precompiled headers include it somehow when building in that > mode -- although that seems buggy. > > I added a patch and it built. But obviously it's building for > ~everybody else. I wonder if others, if you remove the > "target_precompiled_headers" line, can build this file. > > > The patch: > > --- src/core/pal/priorityqueue.cpp.orig 2025-11-03 18:44:19.775172737 +0000 > +++ src/core/pal/priorityqueue.cpp > @@ -28,6 +28,7 @@ > */ > > #include > +#include > > #include "internalexception.h" > #include "priorityqueue.h" > > > The error output (without the patch): > > FAILED: [code=1] src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o > /tmp/work/geography/qgis/work/.cwrapper/bin/c++ -DCMAKE_SOURCE_DIR=\"/tmp/work/geography/qgis/work/qgis-3.44.4\" -DPROTOBUF_USE_DLLS -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x050800 -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_SERIALPORT_LIB -DQT_SQL_LIB -DQT_SVG_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DSIP_VERSION=0x060c00 -DTEST_DATA_DIR=\"/tmp/work/geography/qgis/work/qgis-3.44.4/tests/testdata\" -DWITH_COPC -DWITH_EPT -D_HAVE_PTHREAD_ -Dqgis_core_EXPORTS -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build/src/core/qgis_core_autogen/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/poly2tri -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/ept -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/copc -I/tmp/work/geography/qgis/work/qg > is-3.44.4/src/core/providers/vpc -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build/src/core -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/meshOptimizer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/3d -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/actions -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/annotations -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/auth -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/browser -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/callouts -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/classification -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/diagram -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/dxf -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/editform -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/effects -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/elevation -I/tmp/work/geography/qgis/work/qgis- > 3.44.4/src/core/expression -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/externalstorage -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/fieldformatter -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/geometry -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/geocoding -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/gps -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/labeling -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/labeling/rules -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/layertree -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/layout -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/locator -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/maprenderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/mesh -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/metadata -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/network -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/numericformats -I/tmp/work/geography/q > gis/work/qgis-3.44.4/src/core/painting -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pdf -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/plot -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pointcloud -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pointcloud/expression -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/processing -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/processing/models -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/proj -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/project -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/arcgis -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/memory -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/gdal -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/ogr -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pr > oviders/meshmemory -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/sensorthings -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/raster -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/renderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/scalebar -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/settings -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/sensor -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/stac -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/symbology -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/textrenderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/tiledscene -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/validity -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/vector -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/vectortile -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/web -I/tmp/work/geography/qgis/work/qgis-3.44.4/external -I/tmp/work/geography/qgis/work/qgis-3.44.4/exter > nal/delaunator-cpp -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/kdbush/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/nmea -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/rtree/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/tinygltf -isystem /usr/pkg/qt5/include/Qca-qt5/QtCrypto -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtCore -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/./mkspecs/netbsd-g++ -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtGui -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtXml -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtWidgets -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSvg -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtNetwork -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSql -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtConcurrent -isystem /tmp/work/geography/qgis/work/.b > uildlink/qt5/include/QtPositioning -isystem /tmp/work/geography/qgis/work/.buildlink/include/geos -isystem /usr/pkg/qt5/include -isystem /usr/pkg/qt5/include/QtDBus -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtPrintSupport -isystem /usr/pkg/include -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSerialPort -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.13 -Dz_off_t=long -I/usr/pkg/include/libxml2 -I/usr/pkg/include/minizip -I/usr/pkg/qt5/include -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/harfbuzz -I/usr/pkg/include/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include/libdrm -I/usr/pkg/include/gstreamer-1.0 -I/usr/pkg/qwt-6.3.0/include -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move -Wno-misleading-indentation -Wno-deprecated-copy -std=gnu++17 -fPIC -fvisibility=hidden -fPIC -MD -MT src/core/CMakeFiles/qgis_ > core.dir/pal/priorityqueue.cpp.o -MF src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o.d -o src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o -c /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp > In file included from /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:33: > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:96:12: error: 'unique_ptr' in namespace 'std' does not name a template type > 96 | std::unique_ptr heap; > | ^~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:37:1: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? > 36 | #include > +++ |+#include > 37 | > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:97:12: error: 'unique_ptr' in namespace 'std' does not name a template type > 97 | std::unique_ptr p; > | ^~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:97:7: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? > 97 | std::unique_ptr p; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:98:12: error: 'unique_ptr' in namespace 'std' does not name a template type > 98 | std::unique_ptr pos; > | ^~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:98:7: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? > 98 | std::unique_ptr pos; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In constructor 'pal::PriorityQueue::PriorityQueue(int, int, bool)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:3: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 53 | heap = std::make_unique( maxsize ); > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:15: error: 'make_unique' is not a member of 'std' > 53 | heap = std::make_unique( maxsize ); > | ^~~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:34:1: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? > 33 | #include "priorityqueue.h" > +++ |+#include > 34 | > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:27: error: expected primary-expression before 'int' > 53 | heap = std::make_unique( maxsize ); > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:3: error: 'p' was not declared in this scope > 54 | p = std::make_unique( maxsize ); > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:12: error: 'make_unique' is not a member of 'std' > 54 | p = std::make_unique( maxsize ); > | ^~~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:12: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:24: error: expected primary-expression before 'double' > 54 | p = std::make_unique( maxsize ); > | ^~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:3: error: 'pos' was not declared in this scope > 55 | pos = std::make_unique( maxId + 1 ); > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:14: error: 'make_unique' is not a member of 'std' > 55 | pos = std::make_unique( maxId + 1 ); > | ^~~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:14: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:26: error: expected primary-expression before 'int' > 55 | pos = std::make_unique( maxId + 1 ); > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getBest()': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:84:28: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 84 | const int return_value = heap[0]; > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:88:3: error: 'pos' was not declared in this scope > 88 | pos[heap[0]] = -1; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:95:5: error: 'p' was not declared in this scope > 95 | p[0] = p[size]; > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'bool pal::PriorityQueue::isIn(int) const': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:105:26: error: 'pos' was not declared in this scope > 105 | return key <= maxId && pos[key] >= 0; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getId(int) const': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:110:25: error: 'pos' was not declared in this scope > 110 | return key <= maxId ? pos[key] : -1; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::insert(int, double)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:118:3: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 118 | heap[size] = key; > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:119:3: error: 'pos' was not declared in this scope > 119 | pos[key] = size; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:120:9: error: 'class pal::PriorityQueue' has no member named 'p' > 120 | this->p[size] = p; > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::remove(int)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:135:17: error: 'pos' was not declared in this scope > 135 | const int i = pos[key]; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:140:9: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 140 | pos[heap[size]] = i; > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:144:5: error: 'p' was not declared in this scope > 144 | p[i] = p[size]; > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::upheap(int)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:177:7: error: 'pos' was not declared in this scope > 177 | i = pos[key]; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:183:21: error: 'p' was not declared in this scope > 183 | if ( greater( p[PARENT( i )], p[i] ) ) > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:187:13: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 187 | pos[heap[i]] = i2; > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::downheap(int)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:220:30: error: 'p' was not declared in this scope > 220 | min_child = greater( p[RIGHT( id )], p[LEFT( id )] ) ? LEFT( id ) : RIGHT( id ); > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:228:19: error: 'p' was not declared in this scope > 228 | if ( greater( p[id], p[min_child] ) ) > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:230:7: error: 'pos' was not declared in this scope > 230 | pos[heap[id]] = min_child; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:230:11: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 230 | pos[heap[id]] = min_child; > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::setPriority(int, double)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:255:17: error: 'pos' was not declared in this scope > 255 | const int i = pos[key]; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:263:3: error: 'p' was not declared in this scope > 263 | p[i] = new_p; > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::decreaseKey(int)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:276:17: error: 'pos' was not declared in this scope > 276 | const int i = pos[key]; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:281:3: error: 'p' was not declared in this scope > 281 | p[i]--; > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::print()': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:72: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:81: error: 'pos' was not declared in this scope > 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:95: error: 'p' was not declared in this scope > 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getSizeByPos() const': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:310:10: error: 'pos' was not declared in this scope > 310 | if ( pos[i] >= 0 ) > | ^~~ > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- http://www.spatialys.com My software is free, but my time generally not. From gdt at lexort.com Mon Nov 3 16:19:04 2025 From: gdt at lexort.com (Greg Troxel) Date: Mon, 03 Nov 2025 19:19:04 -0500 Subject: [QGIS-Developer] precompiled headers buggy, how to disable, compilation error In-Reply-To: <8ada5d6d-eb34-4d5e-8973-02b450b8d724@spatialys.com> (Even Rouault's message of "Tue, 4 Nov 2025 00:37:49 +0100") References: <8ada5d6d-eb34-4d5e-8973-02b450b8d724@spatialys.com> Message-ID: Even Rouault writes: > adressed per https://github.com/qgis/QGIS/pull/63794 Thanks -- that was fast! Addressed in more detail on github, but that works great for me and the resulting 3.44.4 package (built with gdal 3.12.0rc1 even) works fine. From nyall.dawson at gmail.com Mon Nov 3 17:34:19 2025 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Tue, 4 Nov 2025 11:34:19 +1000 Subject: [QGIS-Developer] Dirtying project within model classes or not In-Reply-To: <87a513oyjv.fsf@julienlaptop.home> References: <87a513oyjv.fsf@julienlaptop.home> Message-ID: On Tue, 4 Nov 2025 at 02:45, Julien Cabieces via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > > So, I'd like to know if we should: > - always dirty the project within model classes > - never dirty the project within model classes > - it depends... Thanks for raising this discussion Julien, I agree that a project-wide policy/guideline would be better than the ad-hoc approach we currently have. While I believe that conceptually dirtying a project IS an app level operation, my strongest counter-argument against dirtying from core classes is that not every class in core which "changes" a project HAS a way of notifying that project that it's been dirtied. For instance -- a layer's appearance can be changed via something like: layer->renderer()->symbol().setColor(...) There's NO way for symbols or renderers to notify the project (or even the layer) of these changes. A QgsSymbol doesn't (and shouldn't) keep a reference to its owner QgsFeatureRenderer, and the renderer doesn't keep a reference to its owner QgsVectorLayer. Neither QgsSymbol or QgsFeatureRenderer are QObjects (and they definitely should NOT be!!), so we can't eg emit signals from the symbol to notify of changes. The only way a change to one of these objects has to dirty a project would be a nasty QgsProject::instance()->setDirty() call, and (for good reason!) introduction of new occurrences of QgsProject::instance() is explicitly prohibited in core code. This leaves us in the situation where SOME calls to api methods in core classes dirties the project, but others have no possible way to do that. And this API inconsistency leads to a mess -- a caller would have no predictable way of knowing if any particular API call which effectively modifies a project will dirty the project or not, so they'll just need to manually dirty the project anyway to be certain. Or in short: if we dirty from core classes, we'll *always* have a need to *also* have dirty calls from gui/app. The alternative is to decide that dirtying belongs only at the app/gui level, and this makes things nice and predictable -- if a GUI / user operation changes the project, that gui/app code is responsible for dirtying the project. No ambiguity involved ? Nyall > > Regards, > Julien > > [0] https://github.com/qgis/QGIS/pull/63498#discussion_r2425462712 > [1] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L490 > [2] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L975 > > -- > > Julien Cabieces > Senior Developer at Oslandia > julien.cabieces at oslandia.com > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at qgis.org Mon Nov 3 23:56:46 2025 From: andreas at qgis.org (Andreas Neumann) Date: Tue, 4 Nov 2025 08:56:46 +0100 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? In-Reply-To: References: Message-ID: Hi Greg, With the switch from QGIS 3.x to 4.x we are kind of breaking the rules around our otherwise strict schedules. This means that we skipped one release altogether and this also means that 3.44.x will be the last 3.x version and we decided it makes sense that the last 3.x version will eventually become LTR. I hope this makes sense. QGIS 4.x (currently 3.99.x) is still in early stages, but already usable. Plugins will have to update to work in QGIS 4.x. So I would wait a couple of 4.x releases to use it in production. Greetings, Andreas Andreas On Sun, 2 Nov 2025 at 16:44, Greg Troxel via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > I saw 3.40.12 and updated pkgsrc, and the .12 being pretty high made me > guess that there was a new LTR and I should look at it. I went to read > > https://qgis.org/resources/roadmap/ > > and after staring at it for a long time, my take is: > > - 3.44 is *going to be* LTR, but will not be blessed as such until > 3.44.8 in February > > - What is unusual is that LTR will be 3.44.8, not 3.46.4, because > there was no 3.46 in 2025-10, but we're still holding off until > February, because some blend of > + LTR promotion is always February > + LTR promotion of a future-LTR happens only when the next branch > .0 comes out. > > - 4.2 will become LTR in 2026-10, which is out of cycle, and probably > we'll then see 4.8 in 2027-10 with LTRs happening on October > instead of February. (That's an observation not a complaint.) > > If I'm confused a clue would be appreciated, and if 99.9% of the list > was already super clear sorry for the noise. > > Separately, given that pkgsrc is on the fence between "latest release is > fine" and "LTR is more stable and better", I should be planning to > switch from 3.40.x to 3.44.x, and any time between now and just after > the LTR-blessing of 3.44 on 2026-02-20 is a reasonable time to do that. > (I am building 3.44.4 from source and it's halfway through.) > > My impression is that 3.44 is entirely stable and that for normal users > (not trying to coordinate with other packaging systems in big > organizations, and not having the LTS "running old code on purpose is > good" outlook), there is no real reason to stay on 3.40. > > It is clear that I should try to package 4.0, or even 3.99, but as a > separate/experimental package, to surface and resolve qt6 issues. > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- -- Andreas Neumann QGIS.ORG board member (treasurer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at qgis.org Mon Nov 3 23:57:23 2025 From: andreas at qgis.org (Andreas Neumann) Date: Tue, 4 Nov 2025 08:57:23 +0100 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? In-Reply-To: References: Message-ID: See also https://blog.qgis.org/2025/10/07/update-on-qgis-4-0-release-schedule-and-ltr-plans/ where this was communicated. Andreas On Sun, 2 Nov 2025 at 16:44, Greg Troxel via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > I saw 3.40.12 and updated pkgsrc, and the .12 being pretty high made me > guess that there was a new LTR and I should look at it. I went to read > > https://qgis.org/resources/roadmap/ > > and after staring at it for a long time, my take is: > > - 3.44 is *going to be* LTR, but will not be blessed as such until > 3.44.8 in February > > - What is unusual is that LTR will be 3.44.8, not 3.46.4, because > there was no 3.46 in 2025-10, but we're still holding off until > February, because some blend of > + LTR promotion is always February > + LTR promotion of a future-LTR happens only when the next branch > .0 comes out. > > - 4.2 will become LTR in 2026-10, which is out of cycle, and probably > we'll then see 4.8 in 2027-10 with LTRs happening on October > instead of February. (That's an observation not a complaint.) > > If I'm confused a clue would be appreciated, and if 99.9% of the list > was already super clear sorry for the noise. > > Separately, given that pkgsrc is on the fence between "latest release is > fine" and "LTR is more stable and better", I should be planning to > switch from 3.40.x to 3.44.x, and any time between now and just after > the LTR-blessing of 3.44 on 2026-02-20 is a reasonable time to do that. > (I am building 3.44.4 from source and it's halfway through.) > > My impression is that 3.44 is entirely stable and that for normal users > (not trying to coordinate with other packaging systems in big > organizations, and not having the LTS "running old code on purpose is > good" outlook), there is no real reason to stay on 3.40. > > It is clear that I should try to package 4.0, or even 3.99, but as a > separate/experimental package, to surface and resolve qt6 issues. > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- -- Andreas Neumann QGIS.ORG board member (treasurer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.cabieces at oslandia.com Tue Nov 4 00:22:02 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Tue, 04 Nov 2025 09:22:02 +0100 Subject: [QGIS-Developer] Dirtying project within model classes or not In-Reply-To: (Nyall Dawson's message of "Tue, 4 Nov 2025 11:34:19 +1000") References: <87a513oyjv.fsf@julienlaptop.home> Message-ID: <87y0omnr6d.fsf@julienlaptop.home> > On Tue, 4 Nov 2025 at 02:45, Julien Cabieces via QGIS-Developer wrote: >> > >> So, I'd like to know if we should: >> - always dirty the project within model classes >> - never dirty the project within model classes >> - it depends... > > Thanks for raising this discussion Julien, I agree that a project-wide policy/guideline would be better than the ad-hoc approach we currently > have. While I believe that conceptually dirtying a project IS an app level operation, my strongest counter-argument against dirtying from core > classes is that not every class in core which "changes" a project HAS a way of notifying that project that it's been dirtied. > > For instance -- a layer's appearance can be changed via something like: > > layer->renderer()->symbol().setColor(...) > > There's NO way for symbols or renderers to notify the project (or even the layer) of these changes. A QgsSymbol doesn't (and shouldn't) keep a > reference to its owner QgsFeatureRenderer, and the renderer doesn't keep a reference to its owner QgsVectorLayer. Neither QgsSymbol or > QgsFeatureRenderer are QObjects (and they definitely should NOT be!!), so we can't eg emit signals from the symbol to notify of changes. The > only way a change to one of these objects has to dirty a project would be a nasty QgsProject::instance()->setDirty() call, and (for good reason!) > introduction of new occurrences of QgsProject::instance() is explicitly prohibited in core code. > Why not plain old callbacks instead of signals (I don't like that much signals, It's hard to debug, I think we use them too much). QgsSymbol could have some methods like this void addModifiedCallback( std::function callback ) { mCallbacks.append( callback ); } void dirty() { for( auto callback : mCallbacks ) callback(); } void setSize( double size ) { ... dirty(); } And QgsFeatureRenderer would report it to QgsVectorLayer, which would then report it to QgsProject > This leaves us in the situation where SOME calls to api methods in core classes dirties the project, but others have no possible way to do that. > And this API inconsistency leads to a mess -- a caller would have no predictable way of knowing if any particular API call which effectively > modifies a project will dirty the project or not, so they'll just need to manually dirty the project anyway to be certain. Or in short: if we dirty from > core classes, we'll *always* have a need to *also* have dirty calls from gui/app. > > The alternative is to decide that dirtying belongs only at the app/gui level, and this makes things nice and predictable -- if a GUI / user operation > changes the project, that gui/app code is responsible for dirtying the project. No ambiguity involved ? > Plugin developer could forget to dirty. And according to murphy law, if they could, they would! Doing it in core will prevent us from this > Nyall > >> >> Regards, >> Julien >> >> [0] https://github.com/qgis/QGIS/pull/63498#discussion_r2425462712 >> [1] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L490 >> [2] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L975 >> >> -- >> >> Julien Cabieces >> Senior Developer at Oslandia >> julien.cabieces at oslandia.com >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From dvdkon at konarici.cz Tue Nov 4 00:44:49 2025 From: dvdkon at konarici.cz (=?UTF-8?B?RGF2aWQgS2/FiGHFmcOtaw==?=) Date: Tue, 4 Nov 2025 09:44:49 +0100 Subject: [QGIS-Developer] Dirtying project within model classes or not In-Reply-To: <87y0omnr6d.fsf@julienlaptop.home> References: <87a513oyjv.fsf@julienlaptop.home> <87y0omnr6d.fsf@julienlaptop.home> Message-ID: <21d859f9-eee1-4772-a8b3-b06df4af64ba@konarici.cz> Hi all, On 11/4/25 09:22, Julien Cabieces via QGIS-Developer wrote: > Why not plain old callbacks instead of signals (I don't like that much > signals, It's hard to debug, I think we use them too much). QgsSymbol could have some > methods like this > > void addModifiedCallback( std::function callback ) > { > mCallbacks.append( callback ); > } > > void dirty() > { > for( auto callback : mCallbacks ) > callback(); > } > > void setSize( double size ) > { > ... > dirty(); > } > > And QgsFeatureRenderer would report it to QgsVectorLayer, which would > then report it to QgsProject I don't have an opinion on dirtying (due to lack of experience with it), but I do have an opinion on signals and callbacks: I agree that QGIS sometimes overuses signals, but I think callbacks are only a reasonable replacement where there will be exactly one callback, and only when that callback isn't stored in an object. Apart from the code duplication introduced by manually handling lists of callback functions (and slowly reimplementing signals ourselves), signals, when attached to objects, will automatically respond to the destruction of one of the endpoints. This means that properly-connected signals will never cause use-after-free issues, and that is reason enough to use them, in my opinion. David Ko?a??k From gdt at lexort.com Tue Nov 4 05:59:06 2025 From: gdt at lexort.com (Greg Troxel) Date: Tue, 04 Nov 2025 08:59:06 -0500 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? In-Reply-To: (Andreas Neumann's message of "Tue, 4 Nov 2025 08:56:46 +0100") References: Message-ID: Andreas Neumann writes: > With the switch from QGIS 3.x to 4.x we are kind of breaking the rules > around our otherwise strict schedules. This means that we skipped one > release altogether and this also means that 3.44.x will be the last 3.x > version and we decided it makes sense that the last 3.x version will > eventually become LTR. I hope this makes sense. Yes, that makes sense and I understood the general plan. What I was not clear about was whether, today, 3.44 *was* the LTR or just *is going to be*. But from reading the roadmap, I convinced myself that today, 3.40 is LTR, and in late February, 3.44 will become LTR. Confusingly, 3.44 proclaims itself LTR in the splash screen, and it sort of is, kind of like crown prince. > QGIS 4.x (currently 3.99.x) is still in early stages, but already usable. > Plugins will have to update to work in QGIS 4.x. So I would wait a couple > of 4.x releases to use it in production. I guess that's really separate from the blessing of 4.2 as LTR. Then, once can presume that 4.2 is stable, but that doesn't mean plugins are ok. I guess every person/org has to assess what plugins they care about, test them, and if issues either fix them, pay someone else to fix, wait, or decide they don't care quite so much. From andreaerdna at libero.it Tue Nov 4 09:29:39 2025 From: andreaerdna at libero.it (Andrea Giudiceandrea) Date: Tue, 4 Nov 2025 18:29:39 +0100 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? Message-ID: <6df71adb-e337-45d9-9aec-7a30b89abfc9@libero.it> Il 04/11/2025 14:59, Greg Troxel via QGIS-Developer ha scritto: > Confusingly, 3.44 > proclaims itself LTR in the splash screen, and it sort of is, kind of > like crown prince. Already reported [1] and fixed [2]. Regards. Andrea [1] https://github.com/qgis/QGIS/issues/63692 [2] https://github.com/qgis/QGIS/pull/63710 From jef at norbit.de Tue Nov 4 09:51:11 2025 From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer) Date: Tue, 4 Nov 2025 18:51:11 +0100 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? In-Reply-To: References: Message-ID: <20251104175111.2ieagxyfxlnxghhd@norbit.de> Hi Greg, On Tue, 04. Nov 2025 at 08:59:06 -0500, Greg Troxel via QGIS-Developer wrote: > Yes, that makes sense and I understood the general plan. What I was not > clear about was whether, today, 3.44 *was* the LTR or just *is going to > be*. But from reading the roadmap, I convinced myself that today, 3.40 > is LTR, and in late February, 3.44 will become LTR. Confusingly, 3.44 > proclaims itself LTR in the splash screen, and it sort of is, kind of > like crown prince. Well, in my view the ltr is a branch that is longer maintained as others. So an ltr starts when it's branched off. We just build packages for the latest and long-term release and as that wouldn't make much sense while both are the same, we continue to build the previous ltr, while the new ltr is also the latest release. That way we still have two lines to build and the new ltr has some more time to replace the previous. That happens when the next version is released and takes its place as lastest release. That should also be the point were the splash is changed - which is usually with .4. That would have been - but should have happend with .8 on this branch. The splash change was meanwhile reverted. But I didn't bother to retag or do another point release just for this IMHO minor issue - the branch is a LTR branch. J?rgen -- J?rgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstra?e 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden https://www.norbit.de QGIS release manager (PSC) Germany IRC: jef on Libera|OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nyall.dawson at gmail.com Tue Nov 4 11:11:35 2025 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Wed, 5 Nov 2025 05:11:35 +1000 Subject: [QGIS-Developer] Dirtying project within model classes or not In-Reply-To: <21d859f9-eee1-4772-a8b3-b06df4af64ba@konarici.cz> References: <87a513oyjv.fsf@julienlaptop.home> <87y0omnr6d.fsf@julienlaptop.home> <21d859f9-eee1-4772-a8b3-b06df4af64ba@konarici.cz> Message-ID: On Tue, 4 Nov 2025, 6:45?pm David Ko?a??k via QGIS-Developer, < qgis-developer at lists.osgeo.org> wrote: > > I don't have an opinion on dirtying (due to lack of experience with it), > but I do have an opinion on signals and callbacks: > > I agree that QGIS sometimes overuses signals, but I think callbacks are > only a reasonable replacement where there will be exactly one callback, > and only when that callback isn't stored in an object. > > Apart from the code duplication introduced by manually handling lists of > callback functions (and slowly reimplementing signals ourselves), > signals, when attached to objects, will automatically respond to the > destruction of one of the endpoints. This means that properly-connected > signals will never cause use-after-free issues, and that is reason > enough to use them, in my opinion. > +1. Effectively reimplementing qobject ourselves is not a good idea at all. Nyall > David Ko?a??k > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.cabieces at oslandia.com Wed Nov 5 05:33:41 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Wed, 05 Nov 2025 14:33:41 +0100 Subject: [QGIS-Developer] Dirtying project within model classes or not In-Reply-To: <21d859f9-eee1-4772-a8b3-b06df4af64ba@konarici.cz> ("David =?utf-8?B?S2/FiGHFmcOtaw==?= via QGIS-Developer"'s message of "Tue, 4 Nov 2025 09:44:49 +0100") References: <87a513oyjv.fsf@julienlaptop.home> <87y0omnr6d.fsf@julienlaptop.home> <21d859f9-eee1-4772-a8b3-b06df4af64ba@konarici.cz> Message-ID: <87346sr4cq.fsf@julienlaptop.home> Hi David, Thank you for taking the time to answer this. > Hi all, > > On 11/4/25 09:22, Julien Cabieces via QGIS-Developer wrote: >> Why not plain old callbacks instead of signals (I don't like that much >> signals, It's hard to debug, I think we use them too much). QgsSymbol could have some >> methods like this >> void addModifiedCallback( std::function callback ) >> { >> mCallbacks.append( callback ); >> } >> void dirty() >> { >> for( auto callback : mCallbacks ) >> callback(); >> } >> void setSize( double size ) >> { >> ... >> dirty(); >> } >> And QgsFeatureRenderer would report it to QgsVectorLayer, which >> would >> then report it to QgsProject > > I don't have an opinion on dirtying (due to lack of experience with > it), but I do have an opinion on signals and callbacks: > > I agree that QGIS sometimes overuses signals, but I think callbacks > are only a reasonable replacement where there will be exactly one > callback, and only when that callback isn't stored in an object. > Why could we not have several callbacks ? And I'm not sure to really understand what you mean when you say "that callback isn't stored in an object". > Apart from the code duplication introduced by manually handling lists > of callback functions (and slowly reimplementing signals ourselves), > signals, when attached to objects, will automatically respond to the > destruction of one of the endpoints. This means that > properly-connected signals will never cause use-after-free issues, and > that is reason enough to use them, in my opinion. > signals/slots are way much than just simple callbacks as I described it in my previous email. They can use event loop and deal with inter thread communication for instance. So my proposal is IMHO far from reimplementing signals ourselves. Regarding use-after-free, indeed, the callee need to remove itself from the callback list on destruction, like all the ressources it manages. And code duplication could be avoided by putting the callback logic in some class to extend Regards, Julien > David Ko?a??k > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From julien.cabieces at oslandia.com Wed Nov 5 22:33:44 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Thu, 06 Nov 2025 07:33:44 +0100 Subject: [QGIS-Developer] clang-tidy warning for narrowing to float In-Reply-To: ("David =?utf-8?B?S2/FiGHFmcOtaw==?= via QGIS-Developer"'s message of "Tue, 28 Oct 2025 09:55:20 +0100") References: <87y0ovqwfn.fsf@julienlaptop.home> Message-ID: <87v7jnoek7.fsf@julienlaptop.home> Hi, > Hi, > thanks for your input. We can, however, disable only some aspects of > the warning, and the only ones I'd like to disable are warnings on > floating point conversions. > > The PR you linked fixed a bug with an unwanted integer-to-integer > conversion. I'm convinced something like this couldn't happen with > float conversions, but feel free to send me counterexamples. > I don't have any. And we may never face such an issue like the one I pointed in int-to-float conversion. But there is data loss, so I'd rather be (too) cautious. But you're probable right and it's maybe overkill indeed. Regards, Julien > David Ko?a??k > > On 10/28/25 09:09, Julien Cabieces via QGIS-Developer wrote: >> Hi, >> I totally get your point, and I already faced such a situation where >> I >> have to introduce (too) many static_cast<>. On the other side, I already >> faced a situation where the use of this warning would have prevented a >> real issue [0]. >> So, I'm not really in favor of your proposal because it would >> disable >> the warning for the whole codebase, on some situation where it could be relevant. Could we not instead: >> - introduce float getters/setters to have the conversion at only one place >> - just have some converted variable "const float fvar = >> static_cast( var )". I don't think it makes the code so difficult >> to read. >> Regards, >> Julien >> [0] https://github.com/qgis/QGIS/pull/50016 >> >>> Hi all, >>> I'd like to propose a change to QGIS's clang-tidy settings. Currently, >>> we have bugprone-narrowing-conversions [0] turned on by wildcard, >>> which by default warns on converting between integer types, between >>> floating point types, and from integers to floating points, if the >>> full range of the source type won't fit into the destination type >>> without loss of precision. >>> >>> I fully agree that conversions between different integer types should >>> be conscious decisions, since they can lead to security issues [1]. I >>> find the floating point warnings to have dubious usefulness, though. >>> >>> In QGIS' 3D code, we often need to use integer values (e.g. screen >>> size) in floating point calculations, with practically no chance that >>> the integer value won't be representable as a float, and zero risk >>> even if it is - creating a security issue would require a very >>> creative abuse of floats. Fixing the warning leads to a visual spam of >>> static_cast()s everywhere, obscuring any actual bugs. >>> >>> Converting doubles to floats can actually cause issues, but it's also >>> inevitable in many places, seeing as Qt3D uses floats, but we need to >>> use doubles ourselves for precision reasons. Given this, I also think >>> the warning isn't very useful here. >>> >>> I propose turning off WarnOnIntegerToFloatingPointNarrowingConversion >>> and possibly WarnOnFloatingPointNarrowingConversion, based on your >>> feedback. >>> >>> David Ko?a??k >>> >>> [1]: >>> https://clang.llvm.org/extra/clang-tidy/checks/bugprone/narrowing-conversions.html >>> [0]: e.g. char *copy_string(char *str, uint64_t str_size) { >>> uint32_t size_plus_null = str_size + 1; >>> char *copy = malloc(size_plus_null); >>> memcpy(copy, str, str_size); >>> copy[str_size] = '\0'; >>> return copy; >>> } >>> _______________________________________________ >>> QGIS-Developer mailing list >>> QGIS-Developer at lists.osgeo.org >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From rdmailings at duif.net Thu Nov 6 00:07:53 2025 From: rdmailings at duif.net (Richard Duivenvoorde) Date: Thu, 6 Nov 2025 09:07:53 +0100 Subject: [QGIS-Developer] 3.44 keeps asking for CRS Transformation every time??? Message-ID: Hi, At a client they have installed QGIS 3.44 on Windows. There is a project with some layers. Every time they open that project the "Select Transformation for ..." keeps popping up. And it keeps popping up every time you open the project, even if you check the 'Make default' checkbox and save the project again and again. I now have it here on my Debian laptop too, it's not very clear which kind of layers are affected, but at least the WFS layers are. I have attached a QGIS project with only one WFS layer. Can others reproduce this in QGIS 3.44 (and master...)? I'll create a ticket as anybody can reproduce this... Regards, Richard Duivenvoorde -------------- next part -------------- A non-text attachment was scrubbed... Name: testwfs.qgs Type: application/x-qgis Size: 56832 bytes Desc: not available URL: From pjduplooy.gis at gmail.com Thu Nov 6 00:26:00 2025 From: pjduplooy.gis at gmail.com (Gandalf the Gray) Date: Thu, 6 Nov 2025 10:26:00 +0200 Subject: [QGIS-Developer] 3.44 keeps asking for CRS Transformation every time??? In-Reply-To: References: Message-ID: Richard. Happens on my Windows Machine too.(3.44). Pieter On Thu, Nov 6, 2025 at 10:14?AM Richard Duivenvoorde via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hi, > > At a client they have installed QGIS 3.44 on Windows. There is a project > with some layers. Every time they open that project the "Select > Transformation for ..." keeps popping up. > And it keeps popping up every time you open the project, even if you check > the 'Make default' checkbox and save the project again and again. > > I now have it here on my Debian laptop too, it's not very clear which kind > of layers are affected, but at least the WFS layers are. > > I have attached a QGIS project with only one WFS layer. > Can others reproduce this in QGIS 3.44 (and master...)? > I'll create a ticket as anybody can reproduce this... > > Regards, > > Richard Duivenvoorde > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochenschwarze70 at posteo.de Thu Nov 6 01:59:29 2025 From: jochenschwarze70 at posteo.de (Jochen Schwarze) Date: Thu, 06 Nov 2025 09:59:29 +0000 Subject: [QGIS-Developer] 3.44 keeps asking for CRS Transformation every time??? In-Reply-To: References: Message-ID: Hi, we had a comparable issue with a prior LTR, it was related to an outdated proj.db, cp. Regards, Jochen Schwarze Am 6. November 2025 09:07:53 MEZ schrieb Richard Duivenvoorde via QGIS-Developer : >Hi, > >At a client they have installed QGIS 3.44 on Windows. There is a project with some layers. Every time they open that project the "Select Transformation for ..." keeps popping up. >And it keeps popping up every time you open the project, even if you check the 'Make default' checkbox and save the project again and again. > >I now have it here on my Debian laptop too, it's not very clear which kind of layers are affected, but at least the WFS layers are. > >I have attached a QGIS project with only one WFS layer. >Can others reproduce this in QGIS 3.44 (and master...)? >I'll create a ticket as anybody can reproduce this... > >Regards, > >Richard Duivenvoorde -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmailings at duif.net Thu Nov 6 02:24:34 2025 From: rdmailings at duif.net (Richard Duivenvoorde) Date: Thu, 6 Nov 2025 11:24:34 +0100 Subject: [QGIS-Developer] 3.44 keeps asking for CRS Transformation every time??? In-Reply-To: References: Message-ID: Hi Jochen, I've seen this on too many places now. Last week I created a Virtual Windows11 machine, installed 3.40.12 on it, and this project still keeps asking for transformation... BUT now I see that after the CRS Transformation questions, the project crs (right corner) shows No CRS.... I really do not know how I ended up here. But I've seen this a couple of times now around me too. So apparently a project can at a certain moment end up as a 'No CRS' project, and THEN this popup popping starts ? If I now set the project crs again, the popups disappear. But then I think the question is how people (it's not only my project files) end up here? And should QGIS not put a crs on a project after choosing a CRS Transformation for the layer? Or warn the user? Or just do not ask for the transformation if there is NO project crs? Regards, Richard Duivenvoorde On 11/6/25 10:59, Jochen Schwarze wrote: > Hi, we had a comparable issue with a prior LTR, it was related to an outdated proj.db, cp. > > > > Regards, Jochen Schwarze > > > Am 6. November 2025 09:07:53 MEZ schrieb Richard Duivenvoorde via QGIS-Developer : > > Hi, > > At a client they have installed QGIS 3.44 on Windows. There is a project with some layers. Every time they open that project the "Select Transformation for ..." keeps popping up. > And it keeps popping up every time you open the project, even if you check the 'Make default' checkbox and save the project again and again. > > I now have it here on my Debian laptop too, it's not very clear which kind of layers are affected, but at least the WFS layers are. > > I have attached a QGIS project with only one WFS layer. > Can others reproduce this in QGIS 3.44 (and master...)? > I'll create a ticket as anybody can reproduce this... > > Regards, > > Richard Duivenvoorde > From tom at sparkgeo.com Thu Nov 6 17:45:12 2025 From: tom at sparkgeo.com (Tom Christian) Date: Thu, 6 Nov 2025 17:45:12 -0800 Subject: [QGIS-Developer] Development environment setup Message-ID: <8132C8FA-A075-4B36-8C98-1ADD8E360C03@sparkgeo.com> Hi All, I am interested in learning more about how QGIS developers configure their development environments, and I would like to get some feedback on an alternate approach. I recently contributed my first changes to QGIS and I found the development environment quite challenging. While the QGIS Developers Guide contains lots of information I found most of it to be high-level, e.g. how to work with Git, and there was limited information on gathering required dependencies and setting build configurations. Given the number of dependencies, the risk of conflicts with existing packages, and my strong preference to avoid VMs, I thought a containerised build environment was ideal. My work requires frequently switching between projects and environments. I generally cannot let any one project's dependencies pollute the system outside of a Conda environment, a container, or a VM. I found the CI Docker configuration and thought I could use this to build and test QGIS. These Dockerfiles should guarantee all required dependencies AND this is the environment that passes or fails CI checks on my changes. Building QGIS using the CI Docker configuration was OK, but CI is not setup for running the build product in a container - meaning changes cannot quickly be manually / visually tested in this way. The project would have to be compiled (with the benefit of mounted ccache) and installed every time the container was started before the application could run. The long Docker commands are not currently scripted outside of GitHub Actions Workflows, and build configurations are provided via matrices, so replicating these processes locally is non-trivial. I created this repo to better automate container-based development and testing of QGIS. It contains build / run / test scripts, .env configurations, and Docker Compose overrides to work with the QGIS CI Docker configuration with as few changes as possible. It currently requires a single small commit in the active QGIS branch to support this approach, which I removed before creating PRs for the main QGIS repo. With this approach, building and running a containerised QGIS development build is (in theory) as simple as scripts/run.sh. Tests can be executed with scripts/test.sh. I have some questions: 1) are you installing QGIS build dependencies on "bare metal", or perhaps using a VM? 2) is there a simpler approach than this for containerised builds, runs, and tests? 2a) if not, is there any interest in pursuing this or a similar approach to simplify containerised development environments? Ultimately I suspect the QGIS project would benefit from lower barriers to entry and the ability to better isolate build dependencies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Sat Nov 8 15:33:37 2025 From: gdt at lexort.com (Greg Troxel) Date: Sat, 08 Nov 2025 18:33:37 -0500 Subject: [QGIS-Developer] Development environment setup In-Reply-To: <8132C8FA-A075-4B36-8C98-1ADD8E360C03@sparkgeo.com> (Tom Christian via's message of "Thu, 6 Nov 2025 17:45:12 -0800") References: <8132C8FA-A075-4B36-8C98-1ADD8E360C03@sparkgeo.com> Message-ID: Tom Christian via QGIS-Developer writes: > I am interested in learning more about how QGIS developers configure > their development environments, and I would like to get some feedback > on an alternate approach. > > I recently contributed my first changes to QGIS and I found the > development environment quite challenging. While the QGIS Developers > Guide > contains lots of information I found most of it to be high-level, > e.g. how to work with Git, and there was limited information on > gathering required dependencies and setting build configurations. I believe that INSTALL.md should be extended, and reorganized to speak in general terms before specializing to a particular OS. > Given the number of dependencies, the risk of conflicts with existing > packages, and my strong preference to avoid VMs, I thought a > containerised build environment was ideal. My work requires frequently > switching between projects and environments. I generally cannot let > any one project's dependencies pollute the system outside of a Conda > environment, a container, or a VM. I find the choices that give rise to this approach to be problematic. Containers are a useful device for someone to choose, but if people feel they have to use a container, that's a clue that the situation is troubled. I suspect you are running into packages which require an exact dependency, rather than the proper approach of having a minimal version, trying hard to not to raise that without cause, and adapating to any released version >= the minimum. Some upstreams, influenced by language-specific packaging tools, take the approach that their package is the most important thing in the world and therefore it's ok to insist on exact versions. So far, it seems that qgis does very well on not being unreasonable about dependencies (as long as gcc 12 turns out to be ok; see below). I'm building qgis git master on NetBSD, with dependencies provided by pkgsrc. So far things are almost entirely ok except for what I believe is erroneous code in two tests. I also build qgis 3.40 and now 3.44 releases under pkgsrc. I have generally not had dependency issues. > I found the CI Docker configuration > and thought I could > use this to build and test QGIS. These Dockerfiles should guarantee > all required dependencies AND this is the environment that passes or > fails CI checks on my changes. Building QGIS using the CI Docker > configuration was OK, but CI is not setup for running the build > product in a container - meaning changes cannot quickly be manually / > visually tested in this way. The project would have to be compiled > (with the benefit of mounted ccache) and installed every time the > container was started before the application could run. The long > Docker commands are not currently scripted outside of GitHub Actions > Workflows, and build configurations are provided via matrices, so > replicating these processes locally is non-trivial. Agreed it would be nicer if everything useful like this were hoisted to first-class scripts that could then be used by CI, moving as much out of CI as possible. However, I think it's important for it to be reasonable to build without containers. > I created this repo > to better > automate container-based development and testing of QGIS. It contains > build / run / test scripts, .env configurations, and Docker Compose > overrides to work with the QGIS CI Docker configuration with as few > changes as possible. It currently requires a single small commit > > in the active QGIS branch to support this approach, which I removed > before creating PRs for the main QGIS repo. Thanks; will have a look. > 1) are you installing QGIS build dependencies on "bare metal", or perhaps using a VM? I am installing them within a system which already exists and is also used for other purposes. That system happens to be on bare metal. > 2) is there a simpler approach than this for containerised builds, runs, and tests? > 2a) if not, is there any interest in pursuing this or a similar approach to simplify containerised development environments? > > Ultimately I suspect the QGIS project would benefit from lower barriers to entry and the ability to better isolate build dependencies. Perhaps, but I see the biggest issue as bringing clarity to the situation. As things are I found out missing dependencies from cmake failures -- but at least that is very straightforward. To be fair, the things I found might be in INSTALL.md. As an example, INSTALL.md does not say you need a C++ compiler, and it does not say that C++20 is needed. Beyond that, it doesn't address which parts of C++20 is neeeed; requiring 100% confornmance is obviously unreasonable and means, of gcc versions, only gcc 16 is acceptable. I have received some help in the matrix chat about this, but so far there's no clarity on if gcc12 is good enough (it implements most of c++20, and my take is that only odd parts aren't working in 12). From apasotti at gmail.com Mon Nov 10 00:46:23 2025 From: apasotti at gmail.com (Alessandro Pasotti) Date: Mon, 10 Nov 2025 09:46:23 +0100 Subject: [QGIS-Developer] Development environment setup In-Reply-To: <8132C8FA-A075-4B36-8C98-1ADD8E360C03@sparkgeo.com> References: <8132C8FA-A075-4B36-8C98-1ADD8E360C03@sparkgeo.com> Message-ID: Hi Tom, here is my setup for building with QT6 (QT5 also works): Ubuntu 25.10 all dependencies installed from the system except for GDAL (which I build by myself to have full control and because I am also co-maintainer of GDAL and I occasionally do some development work on that library). If you are in doubt about how/what to install, you can get inspired by https://github.com/qgis/QGIS/blob/master/.docker/qgis3-ubuntu-qt6-build-deps.dockerfile (or use the docker directly if you decide to go that way). The environment is configured by setting environment variables in QT-Creator and by setting the environment variables in a bash wrapper script when I run the python tests from VS-Codium (I use QT-Creator for C++ but I prefer VS-Codium for python). A docker also works just fine, I've used that in the past. IMHO a VM is probably overkill (I've also used that mainly to reduce the entry barriers for newcomers: see now abandoned https://github.com/elpaso/qgis-dev-vagrant). Hope this helps. On Fri, Nov 7, 2025 at 2:45?AM Tom Christian via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hi All, > > I am interested in learning more about how QGIS developers configure their > development environments, and I would like to get some feedback on an > alternate approach. > > I recently contributed my first changes to QGIS and I found the > development environment quite challenging. While the QGIS Developers Guide > contains > lots of information I found most of it to be high-level, e.g. how to work > with Git, and there was limited information on gathering required > dependencies and setting build configurations. > > Given the number of dependencies, the risk of conflicts with existing > packages, and my strong preference to avoid VMs, I thought a containerised > build environment was ideal. My work requires frequently switching between > projects and environments. I generally cannot let any one project's > dependencies pollute the system outside of a Conda environment, a > container, or a VM. > > I found the CI Docker configuration > and thought I could > use this to build and test QGIS. These Dockerfiles should guarantee all > required dependencies AND this is the environment that passes or fails CI > checks on my changes. Building QGIS using the CI Docker configuration was > OK, but CI is not setup for running the build product in a container - > meaning changes cannot quickly be manually / visually tested in this way. > The project would have to be compiled (with the benefit of mounted ccache) > and installed every time the container was started before the application > could run. The long Docker commands are not currently scripted outside of > GitHub Actions Workflows, and build configurations are provided via > matrices, so replicating these processes locally is non-trivial. > > I created this repo > to better > automate container-based development and testing of QGIS. It contains build > / run / test scripts, .env configurations, and Docker Compose overrides to > work with the QGIS CI Docker configuration with as few changes as possible. > It currently requires a single small commit > in > the active QGIS branch to support this approach, which I removed before > creating PRs for the main QGIS repo. > > With this approach, building and running a containerised QGIS development > build is (in theory) as simple as scripts/run.sh. Tests can be executed > with scripts/test.sh. > > > I have some questions: > > 1) are you installing QGIS build dependencies on "bare metal", or perhaps > using a VM? > 2) is there a simpler approach than this for containerised builds, runs, > and tests? > 2a) if not, is there any interest in pursuing this or a similar approach > to simplify containerised development environments? > > > Ultimately I suspect the QGIS project would benefit from lower barriers to > entry and the ability to better isolate build dependencies. > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From smwltwesa6 at gmail.com Tue Nov 11 00:16:14 2025 From: smwltwesa6 at gmail.com (Samweli Twesa Mwakisambwe) Date: Tue, 11 Nov 2025 10:16:14 +0200 Subject: [QGIS-Developer] Development environment setup In-Reply-To: <8132C8FA-A075-4B36-8C98-1ADD8E360C03@sparkgeo.com> References: <8132C8FA-A075-4B36-8C98-1ADD8E360C03@sparkgeo.com> Message-ID: Hi Tom, Here is a suggested alternative approach that I have documented recently https://samweli.github.io/QGIS-Development-Using-Docker It may address some of the challenges you have mentioned and there is a potential to align both efforts or incorporate improvements from your implementation. Best, Samweli On Fri, Nov 7, 2025 at 3:45?AM Tom Christian via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hi All, > > I am interested in learning more about how QGIS developers configure their > development environments, and I would like to get some feedback on an > alternate approach. > > I recently contributed my first changes to QGIS and I found the > development environment quite challenging. While the QGIS Developers Guide > contains > lots of information I found most of it to be high-level, e.g. how to work > with Git, and there was limited information on gathering required > dependencies and setting build configurations. > > Given the number of dependencies, the risk of conflicts with existing > packages, and my strong preference to avoid VMs, I thought a containerised > build environment was ideal. My work requires frequently switching between > projects and environments. I generally cannot let any one project's > dependencies pollute the system outside of a Conda environment, a > container, or a VM. > > I found the CI Docker configuration > and thought I could > use this to build and test QGIS. These Dockerfiles should guarantee all > required dependencies AND this is the environment that passes or fails CI > checks on my changes. Building QGIS using the CI Docker configuration was > OK, but CI is not setup for running the build product in a container - > meaning changes cannot quickly be manually / visually tested in this way. > The project would have to be compiled (with the benefit of mounted ccache) > and installed every time the container was started before the application > could run. The long Docker commands are not currently scripted outside of > GitHub Actions Workflows, and build configurations are provided via > matrices, so replicating these processes locally is non-trivial. > > I created this repo > to better > automate container-based development and testing of QGIS. It contains build > / run / test scripts, .env configurations, and Docker Compose overrides to > work with the QGIS CI Docker configuration with as few changes as possible. > It currently requires a single small commit > in > the active QGIS branch to support this approach, which I removed before > creating PRs for the main QGIS repo. > > With this approach, building and running a containerised QGIS development > build is (in theory) as simple as scripts/run.sh. Tests can be executed > with scripts/test.sh. > > > I have some questions: > > 1) are you installing QGIS build dependencies on "bare metal", or perhaps > using a VM? > 2) is there a simpler approach than this for containerised builds, runs, > and tests? > 2a) if not, is there any interest in pursuing this or a similar approach > to simplify containerised development environments? > > > Ultimately I suspect the QGIS project would benefit from lower barriers to > entry and the ability to better isolate build dependencies. > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- All the Best, Samweli -------------- next part -------------- An HTML attachment was scrubbed... URL: From joona.p.laine at gmail.com Tue Nov 11 00:47:45 2025 From: joona.p.laine at gmail.com (Joona Laine) Date: Tue, 11 Nov 2025 10:47:45 +0200 Subject: [QGIS-Developer] Development environment setup In-Reply-To: References: <8132C8FA-A075-4B36-8C98-1ADD8E360C03@sparkgeo.com> Message-ID: Hi all, Great that we are talking about the difficulties of building QGIS. I just wanted to also share my way of building QGIS using Distrobox ( https://github.com/89luca89/distrobox). I have tried local and few containerization methods and VCPKG but I find Distrobox to be easily the fastest and the most stable way. Here are the steps in a nutshell: 1. Download Distrobox in any linux distro 2. Check the suitable build deps image for your needs in https://hub.docker.com/u/qgis . I used *qqgis3-build-deps-ubuntu-qt6:latest* which contains every dependency needed for building QGIS with QT6 support 3. In terminal run: distrobox create --image docker.io/qgis/qqgis3-build-deps-ubuntu-qt6:latest --additional-packages "qtcreator" qgis-dev 4. Allow using graphical interface within distrobox by running: xhost + 5. Connect to box: distrobox enter qgis-dev 6. Start qtcreator (or CLion which is my IDE of choice) in the terminal and start building QGIS normally 7. You might want to set -DWITH_INTERNAL_SPATIALINDEX=ON and -DWITH_PDAL=OFF since build dep images do not contain the deps for those. 8. QGIS can be started and debugged normally and has access to all your local data just like in the normal local environment and even local (or container) databases can be accessed easily via your computer's ip address (ip addr show) All the tasks prior to building take about 10 minutes and the development experience is superior to any other method I have tried so far. I can see that .devcontainer folder is in .gitignore so there is at least some developers that are using Devcontainers with QGIS as well, but it would be great if that way could also be officially supported. Cheers, Joona ti 11.11.2025 klo 10.16 Samweli Twesa Mwakisambwe via QGIS-Developer ( qgis-developer at lists.osgeo.org) kirjoitti: > Hi Tom, > > Here is a suggested alternative approach that I have documented recently > https://samweli.github.io/QGIS-Development-Using-Docker > > It may address some of the challenges you have mentioned and there is a > potential to align both efforts or incorporate improvements from your > implementation. > > > Best, > Samweli > > On Fri, Nov 7, 2025 at 3:45?AM Tom Christian via QGIS-Developer < > qgis-developer at lists.osgeo.org> wrote: > >> Hi All, >> >> I am interested in learning more about how QGIS developers configure >> their development environments, and I would like to get some feedback on an >> alternate approach. >> >> I recently contributed my first changes to QGIS and I found the >> development environment quite challenging. While the QGIS Developers >> Guide contains >> lots of information I found most of it to be high-level, e.g. how to work >> with Git, and there was limited information on gathering required >> dependencies and setting build configurations. >> >> Given the number of dependencies, the risk of conflicts with existing >> packages, and my strong preference to avoid VMs, I thought a containerised >> build environment was ideal. My work requires frequently switching between >> projects and environments. I generally cannot let any one project's >> dependencies pollute the system outside of a Conda environment, a >> container, or a VM. >> >> I found the CI Docker configuration >> and thought I could >> use this to build and test QGIS. These Dockerfiles should guarantee all >> required dependencies AND this is the environment that passes or fails CI >> checks on my changes. Building QGIS using the CI Docker configuration >> was OK, but CI is not setup for running the build product in a container - >> meaning changes cannot quickly be manually / visually tested in this way. >> The project would have to be compiled (with the benefit of mounted ccache) >> and installed every time the container was started before the application >> could run. The long Docker commands are not currently scripted outside of >> GitHub Actions Workflows, and build configurations are provided via >> matrices, so replicating these processes locally is non-trivial. >> >> I created this repo >> to better >> automate container-based development and testing of QGIS. It contains build >> / run / test scripts, .env configurations, and Docker Compose overrides to >> work with the QGIS CI Docker configuration with as few changes as possible. >> It currently requires a single small commit >> in >> the active QGIS branch to support this approach, which I removed before >> creating PRs for the main QGIS repo. >> >> With this approach, building and running a containerised QGIS development >> build is (in theory) as simple as scripts/run.sh. Tests can be executed >> with scripts/test.sh. >> >> >> I have some questions: >> >> 1) are you installing QGIS build dependencies on "bare metal", or perhaps >> using a VM? >> 2) is there a simpler approach than this for containerised builds, runs, >> and tests? >> 2a) if not, is there any interest in pursuing this or a similar >> approach to simplify containerised development environments? >> >> >> Ultimately I suspect the QGIS project would benefit from lower barriers >> to entry and the ability to better isolate build dependencies. >> >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > > -- > > > All the Best, > > Samweli > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smaspons at bgeo.es Tue Nov 11 00:37:25 2025 From: smaspons at bgeo.es (Sergi Maspons - BGEO) Date: Tue, 11 Nov 2025 09:37:25 +0100 Subject: [QGIS-Developer] Python plugin Processing tests using QGIS Docker Message-ID: <86e4fe52-df23-47bc-be0c-45450f266457@bgeo.es> Hi all, I'm trying to build some CI tests on GitHub (with pytest) using the official qgis/qgis Docker image. Everything works fine except for the parts of my plugin that use Processing algorithms. I'd like to run full workflow tests, but the processing plugin doesn't seem to be available in the container. When I try to load it with qgis.utils.loadPlugin('processing') I get this error: Python error(2): Traceback (most recent call last): ? File "/usr/share/qgis/python/qgis/utils.py", line 447, in loadPlugin ? ? __import__(packageName) ? File "/usr/share/qgis/python/qgis/utils.py", line 1100, in _import ? ? mod = _builtin_import(name, globals, locals, fromlist, level) ? ? ? ? ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ModuleNotFoundError: No module named 'processing' Couldn't load plugin 'processing'(1): Couldn't load plugin 'processing' I can't find much documentation on how to build CI tests for a QGIS plugin, so I've been trying to make it work, but I don't know if I'm doing it rightly... I've tried installing extra packages (qgis-plugin-grass, grass, saga) in the Dockerfile, but it didn't help. Here's my *Dockerfile*: ARG QGIS_TEST_VERSION=latest FROM? qgis/qgis:${QGIS_TEST_VERSION} RUN apt-get update \ ? ? && apt-get install -y python3-pip qgis-plugin-grass grass saga \ ? ? && rm -rf /var/lib/apt/lists/* COPY ./test/requirements.txt /tmp/ RUN pip3 install --upgrade pip || true RUN pip3 install -r /tmp/requirements.txt || pip3 install -r /tmp/requirements.txt --break-system-packages ENV LANG=C.UTF-8 WORKDIR / This is my *run-docker-tests.sh*: #!/usr/bin/env bash set -e pushd /usr/src/ibergis_qgis_plugin xvfb-run pytest popd And the relevant part of *GitHub Actions (test.yml)*: ? # Run unit tests ? tests-qgis: ? ? runs-on: ubuntu-24.04 ? ? strategy: ? ? ? fail-fast: false ? ? ? matrix: ? ? ? ? qgis_version: [latest, ltr, stable] ? ? env: ? ? ? QGIS_TEST_VERSION: ${{ matrix.qgis_version }} ? ? steps: ? ? ? - name: Checkout ? ? ? ? uses: actions/checkout at v4 ? ? ? ? with: ? ? ? ? ? submodules: recursive ? ? ? - name: Test ? ? ? ? run: | ? ? ? ? ? chmod +x .docker/run-docker-tests.sh ? ? ? ? ? docker compose -f .docker/docker-compose.yml run qgis /usr/src/ibergis_qgis_plugin/.docker/run-docker-tests.sh I haven't found much documentation on running QGIS plugin tests in CI environments, so I might be missing something obvious. If anyone has experience running tests that use Processing algorithms inside Docker, I'd really appreciate some guidance. Thanks in advance! -- *Sergi Maspons "Maspi"* -------------- next part -------------- An HTML attachment was scrubbed... URL: From joona.p.laine at gmail.com Tue Nov 11 02:05:59 2025 From: joona.p.laine at gmail.com (Joona Laine) Date: Tue, 11 Nov 2025 12:05:59 +0200 Subject: [QGIS-Developer] Python plugin Processing tests using QGIS Docker In-Reply-To: <86e4fe52-df23-47bc-be0c-45450f266457@bgeo.es> References: <86e4fe52-df23-47bc-be0c-45450f266457@bgeo.es> Message-ID: Hi, Are you using pytest-qgis already in your tests? If you are, just use the fixture qgis_processing in your tests and testing processing algorithms should work just fine. Check here for more details on how to easily test algorithms: https://github.com/GispoCoding/pytest-qgis/issues/27 Cheers, Joona ti 11.11.2025 klo 11.09 Sergi Maspons - BGEO via QGIS-Developer ( qgis-developer at lists.osgeo.org) kirjoitti: > Hi all, > > I'm trying to build some CI tests on GitHub (with pytest) using the > official qgis/qgis Docker image. Everything works fine except for the parts > of my plugin that use Processing algorithms. I'd like to run full workflow > tests, but the processing plugin doesn't seem to be available in the > container. > > When I try to load it with qgis.utils.loadPlugin('processing') I get this > error: > > Python error(2): Traceback (most recent call last): File "/usr/share/qgis/python/qgis/utils.py", line 447, in loadPlugin __import__(packageName) File "/usr/share/qgis/python/qgis/utils.py", line 1100, in _import mod = _builtin_import(name, globals, locals, fromlist, level) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ModuleNotFoundError: No module named 'processing' > Couldn't load plugin 'processing'(1): Couldn't load plugin 'processing' > > I can't find much documentation on how to build CI tests for a QGIS > plugin, so I've been trying to make it work, but I don't know if I'm doing > it rightly... > > I've tried installing extra packages (qgis-plugin-grass, grass, saga) in > the Dockerfile, but it didn't help. > > Here's my *Dockerfile*: > > ARG QGIS_TEST_VERSION=latest > FROM qgis/qgis:${QGIS_TEST_VERSION} > > RUN apt-get update \ > && apt-get install -y python3-pip qgis-plugin-grass grass saga \ > && rm -rf /var/lib/apt/lists/* > > COPY ./test/requirements.txt /tmp/ > RUN pip3 install --upgrade pip || true > RUN pip3 install -r /tmp/requirements.txt || pip3 install -r /tmp/requirements.txt --break-system-packages > ENV LANG=C.UTF-8 > WORKDIR / > > This is my *run-docker-tests.sh*: > > #!/usr/bin/env bash > set -e > pushd /usr/src/ibergis_qgis_plugin > xvfb-run pytest > popd > > And the relevant part of *GitHub Actions (test.yml)*: > > # Run unit tests > tests-qgis: > runs-on: ubuntu-24.04 > strategy: > fail-fast: false > matrix: > qgis_version: [latest, ltr, stable] > env: > QGIS_TEST_VERSION: ${{ matrix.qgis_version }} > steps: > - name: Checkout > uses: actions/checkout at v4 > with: > submodules: recursive > > - name: Test > run: | > chmod +x .docker/run-docker-tests.sh > docker compose -f .docker/docker-compose.yml run qgis /usr/src/ibergis_qgis_plugin/.docker/run-docker-tests.sh > > I haven't found much documentation on running QGIS plugin tests in CI > environments, so I might be missing something obvious. > If anyone has experience running tests that use Processing algorithms > inside Docker, I'd really appreciate some guidance. > > Thanks in advance! > -- > *Sergi Maspons "Maspi"* > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nirvn.asia at gmail.com Tue Nov 11 04:56:01 2025 From: nirvn.asia at gmail.com (Mathieu Pellerin) Date: Tue, 11 Nov 2025 19:56:01 +0700 Subject: [QGIS-Developer] QEP 347: Welcome page revamp Message-ID: Greetings, This is to inform that a new QEP ( https://github.com/qgis/QGIS-Enhancement-Proposals/pull/351) has been opened earlier today formalizing the discussion around the revamping of the welcome page into a proper QEP. Much has already been said about this on the related issue ( https://github.com/qgis/QGIS-Enhancement-Proposals/issues/327). If people have more comments, please feel invited to drop them into the QEP pull request during this discussion period. Best, Mathieu Pellerin -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at opengis.ch Tue Nov 11 04:58:03 2025 From: david at opengis.ch (David Signer) Date: Tue, 11 Nov 2025 13:58:03 +0100 Subject: [QGIS-Developer] QEP 402: Opaque Layergroups in QGIS-Server In-Reply-To: References: Message-ID: Hi everyone I?m happy to announce the revamped version of this QEP, which now includes additional technical details and clarifies previously unclear points. I look forward to your feedback. https://github.com/qgis/QGIS-Enhancement-Proposals/pull/352 Thanks and regards Dave On Thu, Aug 28, 2025 at 12:08?PM jeker oliver via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > High all > > We would like to extend QGIS with the capability to serve opaque > layergroups through OGC WMS. Opaque layergroups hide all their children, > grandchildren, ... in the layertree. > > Our motivation is to hide implementation details from the user. One usage > example for an opaque layergroup is a detailed road_polygon dataset and an > overview road_line dataset. The point and polygon layer of these two > datasets are contained in the opaque layergroup "roads". > > Please see the following Pull-Request for details: QEP 402: Opaque > Layergroups in QGIS-Server by ojeker ? Pull Request #348 ? > qgis/QGIS-Enhancement-Proposals > > > Thanks > Oliver > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carrillo.german at gmail.com Tue Nov 11 06:18:51 2025 From: carrillo.german at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Carrillo?=) Date: Tue, 11 Nov 2025 09:18:51 -0500 Subject: [QGIS-Developer] Python plugin Processing tests using QGIS Docker In-Reply-To: References: <86e4fe52-df23-47bc-be0c-45450f266457@bgeo.es> Message-ID: Hi Sergi, I think I faced the same issue earlier this year. Have a look at our test.yaml file [1], we needed to pass PYTHONPATH to the docker run command. Hope that helps. Regards, Germ?n ----------- [1] https://github.com/opengisch/pzp/blob/f951fa3fa4ae3662d01d733ea6a32a4d41acedc6/.github/workflows/test.yml#L33 El mar, 11 nov 2025 a las 5:06, Joona Laine via QGIS-Developer (< qgis-developer at lists.osgeo.org>) escribi?: > Hi, > > Are you using pytest-qgis already in your tests? If you are, just use the > fixture qgis_processing in your tests and testing processing algorithms > should work just fine. Check here for more details on how to easily test > algorithms: https://github.com/GispoCoding/pytest-qgis/issues/27 > > Cheers, > Joona > > ti 11.11.2025 klo 11.09 Sergi Maspons - BGEO via QGIS-Developer ( > qgis-developer at lists.osgeo.org) kirjoitti: > >> Hi all, >> >> I'm trying to build some CI tests on GitHub (with pytest) using the >> official qgis/qgis Docker image. Everything works fine except for the parts >> of my plugin that use Processing algorithms. I'd like to run full workflow >> tests, but the processing plugin doesn't seem to be available in the >> container. >> >> When I try to load it with qgis.utils.loadPlugin('processing') I get this >> error: >> >> Python error(2): Traceback (most recent call last): File "/usr/share/qgis/python/qgis/utils.py", line 447, in loadPlugin __import__(packageName) File "/usr/share/qgis/python/qgis/utils.py", line 1100, in _import mod = _builtin_import(name, globals, locals, fromlist, level) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ModuleNotFoundError: No module named 'processing' >> Couldn't load plugin 'processing'(1): Couldn't load plugin 'processing' >> >> I can't find much documentation on how to build CI tests for a QGIS >> plugin, so I've been trying to make it work, but I don't know if I'm doing >> it rightly... >> >> I've tried installing extra packages (qgis-plugin-grass, grass, saga) in >> the Dockerfile, but it didn't help. >> >> Here's my *Dockerfile*: >> >> ARG QGIS_TEST_VERSION=latest >> FROM qgis/qgis:${QGIS_TEST_VERSION} >> >> RUN apt-get update \ >> && apt-get install -y python3-pip qgis-plugin-grass grass saga \ >> && rm -rf /var/lib/apt/lists/* >> >> COPY ./test/requirements.txt /tmp/ >> RUN pip3 install --upgrade pip || true >> RUN pip3 install -r /tmp/requirements.txt || pip3 install -r /tmp/requirements.txt --break-system-packages >> ENV LANG=C.UTF-8 >> WORKDIR / >> >> This is my *run-docker-tests.sh*: >> >> #!/usr/bin/env bash >> set -e >> pushd /usr/src/ibergis_qgis_plugin >> xvfb-run pytest >> popd >> >> And the relevant part of *GitHub Actions (test.yml)*: >> >> # Run unit tests >> tests-qgis: >> runs-on: ubuntu-24.04 >> strategy: >> fail-fast: false >> matrix: >> qgis_version: [latest, ltr, stable] >> env: >> QGIS_TEST_VERSION: ${{ matrix.qgis_version }} >> steps: >> - name: Checkout >> uses: actions/checkout at v4 >> with: >> submodules: recursive >> >> - name: Test >> run: | >> chmod +x .docker/run-docker-tests.sh >> docker compose -f .docker/docker-compose.yml run qgis /usr/src/ibergis_qgis_plugin/.docker/run-docker-tests.sh >> >> I haven't found much documentation on running QGIS plugin tests in CI >> environments, so I might be missing something obvious. >> If anyone has experience running tests that use Processing algorithms >> inside Docker, I'd really appreciate some guidance. >> >> Thanks in advance! >> -- >> *Sergi Maspons "Maspi"* >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmailings at duif.net Wed Nov 12 07:45:45 2025 From: rdmailings at duif.net (Richard Duivenvoorde) Date: Wed, 12 Nov 2025 16:45:45 +0100 Subject: [QGIS-Developer] building QGIS without external/pdal-wrench Message-ID: Hi, I'm trying to package/install PDAL (for Debian), but after installing pdal libs I fail to install QGIS because (I think) changes in the interface or types or so??? Is there a way/flag to not use the extern/pdal_wrench dir? [677/4567] Linking CXX executable output/lib/qgis/pdal_wrench FAILED: [code=1] output/lib/qgis/pdal_wrench : && /usr/bin/c++ -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move -Wno-misleading-indentation -Wno-deprecated-copy -g -Wl,--no-undefined src/providers/pdal/CMakeFiles/pdal_wrench.dir/pdal_wrench_autogen/mocs_compilation.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/main.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/alg.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/boundary.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/clip.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/density.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/info.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/merge.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/thin.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/to_raster.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/to_raster_tin.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/to_vector.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/translate.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/utils.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/vpc.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/tile.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/BufferCache.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/Cell.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/FileProcessor.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/Las.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/TileGrid.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/ThreadPool.cpp.o src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/Writer.cpp.o -o output/lib/qgis/pdal_wrench -L/home/richard/git/qgis/build/src/core -L/home/richard/git/qgis/build/src/gui -Wl,-rpath,/home/richard/git/qgis/build/src/core:/home/richard/git/qgis/build/src/gui: /usr/lib/libpdalcpp.so.19.2.0 /usr/lib/x86_64-linux-gnu/libgdal.so.37.3.11.4 && : /usr/bin/ld: src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/clip.cpp.o: in function `loadPolygons(std::__cxx11::basic_string, std::allocator > const&, pdal::Options&, pdal::BOX2D&)': /home/richard/git/qgis/external/pdal_wrench/clip.cpp:101:(.text+0x72d): undefined reference to `pdal::Polygon::Polygon(OGRGeometryHS*)' collect2: error: ld returned 1 exit status Then I tried to 'fix' that by cleaning up the extern/pdal_wrench dir and commenting out the lines in src/providers/pdal/CMakeLists.txt which point to that dir... But then I get: [638/4545] Linking CXX executable output/lib/qgis/pdal_wrench FAILED: [code=1] output/lib/qgis/pdal_wrench : && /usr/bin/c++ -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move -Wno-misleading-indentation -Wno-deprecated-copy -g -Wl,--no-undefined src/providers/pdal/CMakeFiles/pdal_wrench.dir/pdal_wrench_autogen/mocs_compilation.cpp.o -o output/lib/qgis/pdal_wrench -L/home/richard/git/qgis/build/src/core -L/home/richard/git/qgis/build/src/gui -Wl,-rpath,/home/richard/git/qgis/build/src/core:/home/richard/git/qgis/build/src/gui: /usr/lib/libpdalcpp.so.19.2.0 /usr/lib/x86_64-linux-gnu/libgdal.so.37.3.11.4 && : /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/15/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x17): undefined reference to `main' collect2: error: ld returned 1 exit status Any pointers appreciated... Regards, Richard Duivenvoorde From tom at sparkgeo.com Wed Nov 12 09:20:15 2025 From: tom at sparkgeo.com (Tom Christian) Date: Wed, 12 Nov 2025 09:20:15 -0800 Subject: [QGIS-Developer] Development environment setup Message-ID: <3768BA83-CDEC-4A40-94AF-50474CA2AA4E@sparkgeo.com> Hi Greg, thanks for your input. Regarding this: > I find the choices that give rise to this approach to be problematic. > Containers are a useful device for someone to choose, but if people feel > they have to use a container, that's a clue that the situation is > troubled. > I suspect you are running into packages which require an exact > dependency, rather than the proper approach of having a minimal version, > trying hard to not to raise that without cause, and adapating to any > released version >= the minimum. Some upstreams, influenced by > language-specific packaging tools, take the approach that their package > is the most important thing in the world and therefore it's ok to insist > on exact versions. > So far, it seems that qgis does very well on not being unreasonable > about dependencies (as long as gcc 12 turns out to be ok; see below). If the QGIS repo is good at managing its dependencies in a way that limits its impact on the rest of my system - that's great. The problem is that any other repo could manage its dependencies differently. Over the past year I've probably worked across 50 different repos, many of which I do not maintain and cannot manage their dependencies. If I don't attempt to isolate each project within Conda, containers, or a VM then I am at risk of surprise breakages from what should be unrelated repos. In any repos that I do maintain I provide a containerised option whenever possible to ease the lives of other contributors. > However, I think it's important for it to be reasonable to build without > containers. I agree - I'm not suggesting QGIS should _only_ build and run in a container, but I think the option of building and running in a container could be better supported and I'm happy to contribute to that effort if others also want it. Tom From gdt at lexort.com Wed Nov 12 09:45:41 2025 From: gdt at lexort.com (Greg Troxel) Date: Wed, 12 Nov 2025 12:45:41 -0500 Subject: [QGIS-Developer] Development environment setup In-Reply-To: <3768BA83-CDEC-4A40-94AF-50474CA2AA4E@sparkgeo.com> (Tom Christian's message of "Wed, 12 Nov 2025 09:20:15 -0800") References: <3768BA83-CDEC-4A40-94AF-50474CA2AA4E@sparkgeo.com> Message-ID: Tom Christian writes: > Hi Greg, thanks for your input. Regarding this: > >> I find the choices that give rise to this approach to be problematic. >> Containers are a useful device for someone to choose, but if people feel >> they have to use a container, that's a clue that the situation is >> troubled. > >> I suspect you are running into packages which require an exact >> dependency, rather than the proper approach of having a minimal version, >> trying hard to not to raise that without cause, and adapating to any >> released version >= the minimum. Some upstreams, influenced by >> language-specific packaging tools, take the approach that their package >> is the most important thing in the world and therefore it's ok to insist >> on exact versions. > >> So far, it seems that qgis does very well on not being unreasonable >> about dependencies (as long as gcc 12 turns out to be ok; see below). > > If the QGIS repo is good at managing its dependencies in a way that > limits its impact on the rest of my system - that's great. The problem > is that any other repo could manage its dependencies differently. Over > the past year I've probably worked across 50 different repos, many of > which I do not maintain and cannot manage their dependencies. If I > don't attempt to isolate each project within Conda, containers, or a > VM then I am at risk of surprise breakages from what should be > unrelated repos. In any repos that I do maintain I provide a > containerised option whenever possible to ease the lives of other > contributors. I do understand that there's a lot of bad practice out there and that it needs mitigation at times. >> However, I think it's important for it to be reasonable to build without >> containers. > > I agree - I'm not suggesting QGIS should _only_ build and run in a > container, but I think the option of building and running in a > container could be better supported and I'm happy to contribute to > that effort if others also want it. That's fine with me. I have just been seeing more and more projects that say to install, run docker blah blah with absolutely zero information about how to deal with it. I've even submitted bug reports (*not* qgis) about the build-from-source instructions being lacking and been asked "why are you as an end user even trying to build this?" which by traditional Free Software standards is shocking. In my view it's a slippery slope towards "container is the approeach" leading to "we don't have to be reasonable about dependencies bcause we have a container", and hence all pro-container posts need commenting on about the dangers of losing general buidlability (not really kidding, a bit hyperbolic). From gdt at lexort.com Wed Nov 12 09:48:12 2025 From: gdt at lexort.com (Greg Troxel) Date: Wed, 12 Nov 2025 12:48:12 -0500 Subject: [QGIS-Developer] Development environment setup In-Reply-To: <3768BA83-CDEC-4A40-94AF-50474CA2AA4E@sparkgeo.com> (Tom Christian's message of "Wed, 12 Nov 2025 09:20:15 -0800") References: <3768BA83-CDEC-4A40-94AF-50474CA2AA4E@sparkgeo.com> Message-ID: I should also say that a well-documented repository to create containers that aare useful is a help to building manually, as commented code is more precise than what is in README, so despite my biases, I think it's a good thing in general. In that way a container config repo is somewhat similar to packaging systems. I maintain the qgis entry in pkgsrc, which lists the dependency packages, has some patches, a bunch of CMAKE_CONFIGURE_ARGS, etc. From jean.felder at oslandia.com Wed Nov 12 09:54:34 2025 From: jean.felder at oslandia.com (Jean Felder) Date: Wed, 12 Nov 2025 18:54:34 +0100 Subject: [QGIS-Developer] building QGIS without external/pdal-wrench In-Reply-To: References: Message-ID: Hi Regards, I don't know what happens in your case but your first error looks like an?incompatibility between your pdal_wrench and GDAL versions when compiling QGIS. You should be able to compile QGIS without PDAL support to changing the CMake WITH_PDAL variable: -DWITH_PDAL=OFF Regards, Jean Le 12/11/2025 ? 16:45, Richard Duivenvoorde via QGIS-Developer a ?crit?: > Hi, > > I'm trying to package/install PDAL (for Debian), but after installing > pdal libs I fail to install QGIS because (I think) changes in the > interface or types or so??? > > Is there a way/flag to not use the extern/pdal_wrench dir? > > [677/4567] Linking CXX executable output/lib/qgis/pdal_wrench > FAILED: [code=1] output/lib/qgis/pdal_wrench > : && /usr/bin/c++ -Wall -Wextra -Wno-long-long -Wformat-security > -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move > -Wno-misleading-indentation -Wno-deprecated-copy -g -Wl,--no-undefined > src/providers/pdal/CMakeFiles/pdal_wrench.dir/pdal_wrench_autogen/mocs_compilation.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/main.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/alg.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/boundary.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/clip.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/density.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/info.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/merge.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/thin.cpp.o > src/provid > ers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/to_raster.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/to_raster_tin.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/to_vector.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/translate.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/utils.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/vpc.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/tile.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/BufferCache.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/Cell.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/FileProcessor.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/t > > ile/Las.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/TileGrid.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/ThreadPool.cpp.o > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/tile/Writer.cpp.o > -o output/lib/qgis/pdal_wrench -L/home/richard/git/qgis/build/src/core > -L/home/richard/git/qgis/build/src/gui > -Wl,-rpath,/home/richard/git/qgis/build/src/core:/home/richard/git/qgis/build/src/gui: > /usr/lib/libpdalcpp.so.19.2.0 > /usr/lib/x86_64-linux-gnu/libgdal.so.37.3.11.4 && : > /usr/bin/ld: > src/providers/pdal/CMakeFiles/pdal_wrench.dir/__/__/__/external/pdal_wrench/clip.cpp.o: > in function `loadPolygons(std::__cxx11::basic_string std::char_traits, std::allocator > const&, pdal::Options&, > pdal::BOX2D&)': > /home/richard/git/qgis/external/pdal_wrench/clip.cpp:101:(.text+0x72d): > undefined reference to `pdal::Polygon::Polygon(OGRGeometryHS*)' > collect2: error: ld returned 1 exit status > > Then I tried to 'fix' that by cleaning up the extern/pdal_wrench dir > and commenting out the lines in src/providers/pdal/CMakeLists.txt > which point to that dir... > > But then I get: > > [638/4545] Linking CXX executable output/lib/qgis/pdal_wrench > FAILED: [code=1] output/lib/qgis/pdal_wrench > : && /usr/bin/c++ -Wall -Wextra -Wno-long-long -Wformat-security > -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move > -Wno-misleading-indentation -Wno-deprecated-copy -g -Wl,--no-undefined > src/providers/pdal/CMakeFiles/pdal_wrench.dir/pdal_wrench_autogen/mocs_compilation.cpp.o > -o output/lib/qgis/pdal_wrench -L/home/richard/git/qgis/build/src/core > -L/home/richard/git/qgis/build/src/gui > -Wl,-rpath,/home/richard/git/qgis/build/src/core:/home/richard/git/qgis/build/src/gui: > /usr/lib/libpdalcpp.so.19.2.0 > /usr/lib/x86_64-linux-gnu/libgdal.so.37.3.11.4 && : > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/15/../../../x86_64-linux-gnu/Scrt1.o: in > function `_start': > (.text+0x17): undefined reference to `main' > collect2: error: ld returned 1 exit status > > Any pointers appreciated... > > Regards, > > Richard Duivenvoorde > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Jean Felder D?veloppeur SIG Oslandia -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x12722DC64D3F429E.asc Type: application/pgp-keys Size: 2444 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From smaspons at bgeo.es Thu Nov 13 04:40:43 2025 From: smaspons at bgeo.es (Sergi Maspons - BGEO) Date: Thu, 13 Nov 2025 13:40:43 +0100 Subject: [QGIS-Developer] Python plugin Processing tests using QGIS Docker In-Reply-To: References: <86e4fe52-df23-47bc-be0c-45450f266457@bgeo.es> Message-ID: <630e89e1-08b9-4b49-a740-2d687c4df1f1@bgeo.es> Hi Joona, hi Germ?n, Thank you so much for the answers. I think I didn't code my tests as they should be and that's why I'm having so much trouble. I've tried to workaround it but I haven't had any luck. I'll try to re-write them using pytest-qgis, with fixtures and everything (right now I don't use any, and can't seem to use them with how I have set up the tests). Thanks again for the responses, hopefully I get it working. Kind regards, *Sergi Maspons "Maspi"* El 11/11/2025 a las 15:18, Germ?n Carrillo escribi?: > Hi Sergi, > > I think I faced the same issue earlier this year. > > Have a look at our test.yaml file [1], we needed to pass PYTHONPATH to > the docker run command. > > Hope that?helps. > > Regards, > > Germ?n > ----------- > [1] > https://github.com/opengisch/pzp/blob/f951fa3fa4ae3662d01d733ea6a32a4d41acedc6/.github/workflows/test.yml#L33 > > > El mar, 11 nov 2025 a las 5:06, Joona Laine via QGIS-Developer > () escribi?: > > Hi, > > Are you using pytest-qgis already in your tests? If you are, just > use the fixture qgis_processing in your tests and testing > processing algorithms should work just fine. Check here for more > details on how to easily test algorithms: > https://github.com/GispoCoding/pytest-qgis/issues/27 > > Cheers, > Joona > > ti 11.11.2025 klo 11.09 Sergi Maspons - BGEO via QGIS-Developer > (qgis-developer at lists.osgeo.org) kirjoitti: > > Hi all, > > I'm trying to build some CI tests on GitHub (with pytest) > using the official qgis/qgis Docker image. Everything works > fine except for the parts of my plugin that use Processing > algorithms. I'd like to run full workflow tests, but the > processing plugin doesn't seem to be available in the container. > > When I try to load it with qgis.utils.loadPlugin('processing') > I get this error: > > Python error(2): Traceback (most recent call last): > ? File "/usr/share/qgis/python/qgis/utils.py", line 447, in > loadPlugin > ? ? __import__(packageName) > ? File "/usr/share/qgis/python/qgis/utils.py", line 1100, in > _import > ? ? mod = _builtin_import(name, globals, locals, fromlist, level) > ? ? ? ? ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ModuleNotFoundError: No module named 'processing' > > Couldn't load plugin 'processing'(1): Couldn't load plugin > 'processing' > > I can't find much documentation on how to build CI tests for a > QGIS plugin, so I've been trying to make it work, but I don't > know if I'm doing it rightly... > > I've tried installing extra packages (qgis-plugin-grass, > grass, saga) in the Dockerfile, but it didn't help. > > Here's my *Dockerfile*: > > ARG QGIS_TEST_VERSION=latest FROM? > qgis/qgis:${QGIS_TEST_VERSION} RUN apt-get update \ ? ? && > apt-get install -y python3-pip qgis-plugin-grass grass saga \ > ? ? && rm -rf /var/lib/apt/lists/* COPY > ./test/requirements.txt /tmp/ RUN pip3 install --upgrade pip > || true RUN pip3 install -r /tmp/requirements.txt || pip3 > install -r /tmp/requirements.txt --break-system-packages ENV > LANG=C.UTF-8 WORKDIR / > > This is my *run-docker-tests.sh*: > > #!/usr/bin/env bash set -e pushd /usr/src/ibergis_qgis_plugin > xvfb-run pytest popd > > And the relevant part of *GitHub Actions (test.yml)*: > > ? # Run unit tests ? tests-qgis: ? ? runs-on: ubuntu-24.04 ? ? > strategy: ? ? ? fail-fast: false ? ? ? matrix: ? ? ? ? > qgis_version: [latest, ltr, stable] ? ? env: ? ? ? > QGIS_TEST_VERSION: ${{ matrix.qgis_version }} ? ? steps: ? ? ? > - name: Checkout ? ? ? ? uses: actions/checkout at v4 ? ? ? ? > with: ? ? ? ? ? submodules: recursive ? ? ? - name: Test ? ? ? > ? run: | ? ? ? ? ? chmod +x .docker/run-docker-tests.sh ? ? ? > ? ? docker compose -f .docker/docker-compose.yml run qgis > /usr/src/ibergis_qgis_plugin/.docker/run-docker-tests.sh > > I haven't found much documentation on running QGIS plugin > tests in CI environments, so I might be missing something obvious. > If anyone has experience running tests that use Processing > algorithms inside Docker, I'd really appreciate some guidance. > > Thanks in advance! > > -- > *Sergi Maspons "Maspi"* > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: > https://lists.osgeo.org/mailman/listinfo/qgis-developer > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lova at kartoza.com Fri Nov 14 06:00:00 2025 From: lova at kartoza.com (Lova Andriarimalala) Date: Fri, 14 Nov 2025 17:00:00 +0300 Subject: [QGIS-Developer] QGIS Full Stack Developer Report from October 20 to November 14, 2025 Message-ID: Hello everyone, Please find below some highlights regarding the development and maintenance of the QGIS Websites for the last four weeks, from October 20 to November 14, 2025. *QGIS.org:* - Improve the user groups page [New PR] and make a template repository for the user groups website ( https://github.com/Xpirix/QGIS-User-Group-Website) - Improve UI/UX of the download page [New PR] - Add supporting contributors [Deployed] - Separate contributors tabs to different pages and add permalinks [Deployed] - Updated Kartoza contributors' data with new entries [Deployed] - Add submission button for Supporting Contributors application [Deployed] - Add organisation instructions [Deployed] - Sort contributing organisations by total commits instead of name [Deployed] - Harvest Screenshots from the Hub [Deployed] *QGIS Plugins:* - Filter XML plugins for QGIS 4.x [New PR, discussions in progress] - Improve QGIS 4 plugins listing and add support for supportsQt6 metadata [Deployed] *QGIS Infrastructure:* - Implementing self-hosted runners - Adding a helpers script for the infrastructure management - Staging testing Have a nice weekend! Lova Andriarimalala *QGIS Full Stack Developer * *T *: +27(0) 87 809 2702 *E *: lova at kartoza.com *W* : kartoza.com *This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you * *have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying* *of the contents is prohibited.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From senhor.neto at gmail.com Fri Nov 14 11:24:44 2025 From: senhor.neto at gmail.com (Alexandre Neto) Date: Fri, 14 Nov 2025 19:24:44 +0000 Subject: [QGIS-Developer] Issues with represent_value used inside native:atlaslayouttopdf processing algorithm Message-ID: Hi, I have an atlas layout that uses represent_value() in several parts like labels and tables of attributes to retrieve the pretty strings in fields formatted with relation_references and value_relation widgets. Exporting the layout in atlas works fine. And using the native:atlaslayouttopdf processing algorithm directly from processing also exports correctly, with the correct labels. My next step was to create an action on the coverage layer layer that runs the processing algorithm for a specific feature. The button works fine and the PDF is created, but in the labels and tables, I get the keys printed and not the represent_value() outputs. This is the code I am using in the action (with inspiration from Ujaval Gandhi work): from qgis.core import QgsExpression, QgsExpressionContext, QgsExpressionContextUtils, QgsProject, QgsApplication, Qgis from qgis.PyQt.QtCore import QUrl from qgis.PyQt.QtGui import QDesktopServices from qgis.utils import iface from os import path import processing import re uuid = '[% "uuid" %]' filename = '[%concat(format_date( "data_visita",'yyyyMMdd'),'-' || represent_value("talhao_id"),'-' || represent_value("tecnico_id"),'-' || represent_value("actividade"), '.pdf')%]' filename = re.sub(r'[\\/*?:"<>|]', '_', filename) filename = filename.strip() # Create expression context to access variables context = QgsExpressionContext() context.appendScope(QgsExpressionContextUtils.globalScope()) context.appendScope(QgsExpressionContextUtils.projectScope(QgsProject.instance())) # Evaluate the expression with proper context expression = QgsExpression("@working_project_path") expression.prepare(context) output_dir = expression.evaluate(context) output_path = path.join(output_dir, 'relatorios', filename) print(output_path) processing_context = QgsProcessingContext() processing_context.setProject(QgsProject.instance()) processing_context.setExpressionContext(context) feedback = QgsProcessingFeedback() parameters = { 'COVERAGE_LAYER': 'postgres://service=\'gis\' sslmode=disable key=\'uuid\' estimatedmetadata=true checkPrimaryKeyUnicity=\'1\' table="base"."visita_monitorizacao"', 'DISABLE_TILED': False, 'DPI': None, 'FILTER_EXPRESSION': '"uuid" = \'[% "uuid" %]\'', 'FORCE_RASTER': False, 'FORCE_VECTOR': False, 'GEOREFERENCE': True, 'IMAGE_COMPRESSION': 0, # Lossy (JPEG) 'INCLUDE_METADATA': True, 'LAYERS': None, 'LAYOUT': 'Atlas visitas', 'OUTPUT': output_path, 'SIMPLIFY': True, 'SORTBY_EXPRESSION': '', 'SORTBY_REVERSE': False, 'TEXT_FORMAT': 0, # Always Export Text as Paths (Recommended) } processing.run( 'native:atlaslayouttopdf', parameters, context=processing_context, feedback=feedback ) # Show message in QGIS toolbar with link file_url = QUrl.fromLocalFile(output_path) message = f'Relat?rio exportado com sucesso para {file_url.toString()}' item = iface.messageBar().pushMessage( "Exporta??o:", message, level=Qgis.Info, duration=0 # Stays until user closes it ) I thought the problem could be the algorithm running without a proper context, and that is why I added processing_context lines, but it actually made no difference. The workaround is replacing the represent_values("field_with_key") by attributes(get_feature('layer', 'id', "field_with_key")["value_field"] in the layout for all labels and tables, but now I would really learn what I am doing wrong :-) Thanks, Alex Neto -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.jakimow at geo.hu-berlin.de Sun Nov 16 11:23:42 2025 From: benjamin.jakimow at geo.hu-berlin.de (Benjamin Jakimow) Date: Sun, 16 Nov 2025 20:23:42 +0100 Subject: [QGIS-Developer] Python plugin Processing tests using QGIS Docker In-Reply-To: References: <86e4fe52-df23-47bc-be0c-45450f266457@bgeo.es> Message-ID: <40fb3142-db39-4d76-aade-077701e3fc62@geo.hu-berlin.de> Hi Sergi, as Germ?n wrote, you need to ensure that the PYTHONPATH contains the local QGIS plugin directory: PYTHONPATH=/usr/share/qgis/python/plugins In addition the test suite may need to initialized the processing framework with: from processing.core.Processing import Processing Processing.initialize() Greetings, Benjamin On 11/11/2025 15:18, Germ?n Carrillo via QGIS-Developer wrote: > Hi Sergi, > > I think I faced the same issue earlier this year. > > Have a look at our test.yaml file [1], we needed to pass PYTHONPATH to > the docker run command. > > Hope that?helps. > > Regards, > > Germ?n > ----------- > [1] https://github.com/opengisch/pzp/blob/ > f951fa3fa4ae3662d01d733ea6a32a4d41acedc6/.github/workflows/test.yml#L33 > f951fa3fa4ae3662d01d733ea6a32a4d41acedc6/.github/workflows/test.yml#L33> > > > El mar, 11 nov 2025 a las 5:06, Joona Laine via QGIS-Developer ( developer at lists.osgeo.org >) > escribi?: > > Hi, > > Are you using pytest-qgis already in your tests? If you are, just > use the fixture qgis_processing in your tests and testing processing > algorithms should work just fine. Check here for more details on how > to easily test algorithms: https://github.com/GispoCoding/pytest- > qgis/issues/27 > > Cheers, > Joona > > ti 11.11.2025 klo 11.09 Sergi Maspons - BGEO via QGIS-Developer > (qgis-developer at lists.osgeo.org developer at lists.osgeo.org>) kirjoitti: > > __ > > Hi all, > > I'm trying to build some CI tests on GitHub (with pytest) using > the official qgis/qgis Docker image. Everything works fine > except for the parts of my plugin that use Processing > algorithms. I'd like to run full workflow tests, but the > processing plugin doesn't seem to be available in the container. > > When I try to load it with qgis.utils.loadPlugin('processing') I > get this error: > > Python error(2): Traceback (most recent call last): > ? File "/usr/share/qgis/python/qgis/utils.py", line 447, in > loadPlugin > ? ? __import__(packageName) > ? File "/usr/share/qgis/python/qgis/utils.py", line 1100, in > _import > ? ? mod = _builtin_import(name, globals, locals, fromlist, level) > ? ? ? ? ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ModuleNotFoundError: No module named 'processing' > > Couldn't load plugin 'processing'(1): Couldn't load plugin > 'processing' > > I can't find much documentation on how to build CI tests for a > QGIS plugin, so I've been trying to make it work, but I don't > know if I'm doing it rightly... > > I've tried installing extra packages (qgis-plugin-grass, grass, > saga) in the Dockerfile, but it didn't help. > > Here's my *Dockerfile*: > > ARG QGIS_TEST_VERSION=latest FROM? qgis/qgis: > ${QGIS_TEST_VERSION} RUN apt-get update \ ? ? && apt-get install > -y python3-pip qgis-plugin-grass grass saga \ ? ? && rm -rf / > var/lib/apt/lists/* COPY ./test/requirements.txt /tmp/ RUN pip3 > install --upgrade pip || true RUN pip3 install -r /tmp/ > requirements.txt || pip3 install -r /tmp/requirements.txt -- > break-system-packages ENV LANG=C.UTF-8 WORKDIR / > > This is my *run-docker-tests.sh*: > > #!/usr/bin/env bash set -e pushd /usr/src/ibergis_qgis_plugin > xvfb-run pytest popd > > And the relevant part of *GitHub Actions (test.yml)*: > > ? # Run unit tests ? tests-qgis: ? ? runs-on: ubuntu-24.04 > strategy: ? ? ? fail-fast: false ? ? ? matrix: > qgis_version: [latest, ltr, stable] ? ? env: > QGIS_TEST_VERSION: ${{ matrix.qgis_version }} ? ? steps: ? ? ? - > name: Checkout ? ? ? ? uses: actions/checkout at v4 ? ? ? ? with: > ? ? ? ? submodules: recursive ? ? ? - name: Test ? ? ? ? run: | > ? ? ? ? ? chmod +x .docker/run-docker-tests.sh ? ? ? ? ? docker > compose -f .docker/docker-compose.yml run qgis /usr/src/ > ibergis_qgis_plugin/.docker/run-docker-tests.sh > > I haven't found much documentation on running QGIS plugin tests > in CI environments, so I might be missing something obvious. > If anyone has experience running tests that use Processing > algorithms inside Docker, I'd really appreciate some guidance. > > Thanks in advance! > > -- > *Sergi Maspons "Maspi"* > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org Developer at lists.osgeo.org> > List info: https://lists.osgeo.org/mailman/listinfo/qgis- > developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis- > developer > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > > > > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Benjamin Jakimow Earth Observation Lab | Geography Department | Humboldt-Universit?t zu Berlin e-mail: benjamin.jakimow at geo.hu-berlin.de phone: +49 (0) 30 2093 45846 mobile: +49 (0) 157 5656 8477 fax: +49 (0) 30 2093 6848 mail: Unter den Linden 6 | 10099 Berlin | Germany matrix: @jakimowb:hu-berlin.de web: https://hu-berlin.de/eo-lab -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4347 bytes Desc: S/MIME Cryptographic Signature URL: From julien.cabieces at oslandia.com Mon Nov 17 04:54:13 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Mon, 17 Nov 2025 13:54:13 +0100 Subject: [QGIS-Developer] New QEP: Customized Toolbars and Menus In-Reply-To: <87bjmgw27b.fsf@julienlaptop.home> (Julien Cabieces's message of "Thu, 09 Oct 2025 16:59:36 +0200") References: <87bjmgw27b.fsf@julienlaptop.home> Message-ID: <878qg4rf9m.fsf@julienlaptop.home> Hi list, After weeks of discussions, the QEP is now open for voting. Please cast your vote, See https://github.com/qgis/QGIS-Enhancement-Proposals/pull/343 Kind regards, Julien > Hi list, > > I have considerably updated the custom toolbars QEP and you have want to > take a look at it. > > As part of this QEP, I propose to remove the "Widgets" customization > part because it's probably never user, completely out of sync and very > fragile. Please let me know if you think otherwise. > > Regards, > Julien > >> Hi list! >> >> We propose to add a way to create custom toolbars and custom menus to QGIS. >> >> It will allow users to have their favorite tool buttons / menu items >> grouped together in their own toolbars and menus. >> >> See https://github.com/qgis/QGIS-Enhancement-Proposals/pull/343 >> >> Best regards -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From Ethan.Snyder at rve.com Tue Nov 18 12:16:49 2025 From: Ethan.Snyder at rve.com (Ethan Snyder) Date: Tue, 18 Nov 2025 20:16:49 +0000 Subject: [QGIS-Developer] QGIS Open Day - Nov. 28 - QGIS Processing Nodes Project Update Presentation Message-ID: Hello all, I will be giving an extended version of my FOSS4G NA 2025 presentation over the status of my QGIS Processing Nodes (QPN) project for this coming QGIS Open Day. Info here: https://github.com/qgis/QGIS/wiki/QOD-November-2025 The main reason why I'm announcing this to the dev mailing list is that this project is related to QEP 346 as it intends to overhaul the QGIS Graphical Modeler completely, and I would really appreciate your feedback. It will be going over the project goals and ideas, the current progress of the project, and the extremely rough timeline for the project. Before someone freaks out, (this will also be mentioned in the presentation, along with additional details), the project is currently in a proof-of-concept phase, and will obviously go for a QEP when ready (which won't be for a while). Let me know if you have any comments, questions, concerns, moans, groans, or gripes. ?Thanks, Ethan Snyder Senior GIS/GPS Technician & Software Engineer Remington & Vernick Engineers 2059 Springdale Road Cherry Hill, NJ 08003 (856)-795-9595 ext. 1069 ethan.snyder at rve.com Offices throughout NJ - PA - MD - DE - NC rve.com DISCLAIMER: This message and any documents attached may contain confidential information and are intended only for the individual(s) named. If you are not the intended recipient, or the employee or agent authorized to receive it on behalf of the intended recipient, you should not disseminate, distribute, or copy this e-mail and any attached documents. If you have received this e-mail in error, please immediately notify the sender at Remington & Vernick Engineers by replying to this e-mail and delete the original e-mail and any reply e-mail messages from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Thank you. DISCLAIMER: This message and any documents attached may contain confidential information and are intended only for the individual(s) named. If you are not the intended recipient, or the employee or agent authorized to received for the intended recipient, you should not disseminate, distribute or copy this e-mail and any attached documents. If you have received this e-mail in error, please immediately notify the sender at Remington & Vernick Engineers by replying to this e-mail and delete the original e-mail and any reply e-mail messages from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Thank you. From delazj at gmail.com Fri Nov 21 01:17:58 2025 From: delazj at gmail.com (DelazJ) Date: Fri, 21 Nov 2025 10:17:58 +0100 Subject: [QGIS-Developer] Remove "Polygons must follow boundaries of layer ..." check in Geometry checker plugin? In-Reply-To: References: Message-ID: Hi devs, I didn't get any reply so I wonder if it is because nobody knows, nobody cares, or something else... Other than the concern of "adding/keeping a broken tool" in QGIS, we have a PR in the docs we don't really know how to finalize, so a feedback would be appreciated. Thanks. Regards, Harrissou (for the docs team) Le mar. 28 oct. 2025 ? 10:38, DelazJ a ?crit : > Hi Devs, > In the "Geometry checker" core plugin, there is that option > called "Polygons must follow boundaries of layer ...", of which a > Processing alg "Polygons exceeding boundaries" was recently created. > While testing the algorithm in order to properly document it, we came > across weird results (also output by the geometry checker) that we are > unable to explain/understand their coherence. > > Issues and discussion are availabel at > https://github.com/qgis/QGIS/issues/63454 and > https://github.com/qgis/QGIS-Documentation/pull/10314#issuecomment-3425649278 > > 1/ Does anyone *KNOW* how this option is really supposed to check? and > understand the logic behind the output? > 2/ If there is agreement that this tool does not adress any real use case, > is it something we want to keep in QGIS (in this state)? > > Looking forward to your replies. > Regards, > Harrissou > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nirvn.asia at gmail.com Sat Nov 22 22:57:57 2025 From: nirvn.asia at gmail.com (Mathieu Pellerin) Date: Sun, 23 Nov 2025 13:57:57 +0700 Subject: [QGIS-Developer] QEP 344: Copy, move and rotate annotations Message-ID: Greetings, As plenty of discussion has happened around QEP 344 ( This proposal has passed the two weeks discussion period and is ready for its judgement -- please go ahead and cast your vote! :)), it's time to finalize this with votes. A few people have already +1'ed, more casting is most welcome :) Mathieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.grosjean at wanadoo.fr Mon Nov 24 01:02:21 2025 From: marc.grosjean at wanadoo.fr (Marc GROSJEAN) Date: Mon, 24 Nov 2025 10:02:21 +0100 (CET) Subject: [QGIS-Developer] Validation plugin Message-ID: <78032312.371415.1763974941175.JavaMail.open-xchange@opme11oxm15aub.op.aub.pom.fr.intraorange> An HTML attachment was scrubbed... URL: From rdmailings at duif.net Mon Nov 24 04:37:44 2025 From: rdmailings at duif.net (Richard Duivenvoorde) Date: Mon, 24 Nov 2025 13:37:44 +0100 Subject: [QGIS-Developer] Validation plugin In-Reply-To: <78032312.371415.1763974941175.JavaMail.open-xchange@opme11oxm15aub.op.aub.pom.fr.intraorange> References: <78032312.371415.1763974941175.JavaMail.open-xchange@opme11oxm15aub.op.aub.pom.fr.intraorange> Message-ID: <2f36704b-0a6f-48e4-90cc-c35def2489d8@duif.net> Yep, it can take some days, volunteers will check plugins when they find/have time. What is the name and the maintainer of your plugin? (I cannot find "forest management" nor "grosjean") Regards, Richard Duivenvoorde On 11/24/25 10:02, Marc GROSJEAN via QGIS-Developer wrote: > Hello, > > Due to a mistake, I deleted my "forest management" plugin (all versions). I then upload again the latest QGIS 3 compatible version and the latest QGIS 4 Qt6 version. However, unlike usual, after 5 days it is still not validated. I have downloaded it 7 times for verification. I just wanted to know if this is normal? > > Thank you for your help. > > > Marc GROSJEAN > > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer From david at opengis.ch Mon Nov 24 07:47:00 2025 From: david at opengis.ch (David Signer) Date: Mon, 24 Nov 2025 16:47:00 +0100 Subject: [QGIS-Developer] QEP 403: Client-side field comments Message-ID: Hello everyone, I would like to announce a new QEP that I have just proposed. It concerns client-side field comments overriding server-side comments and being fully handled within the QGIS project. https://github.com/qgis/QGIS-Enhancement-Proposals/pull/353 Feedback is appreciated. Thanks and cheers Dave --- David Signer Senior Developer & INTERLIS Architect Team QGIS & Industry Solutions david at opengis.ch opengis.ch -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyall.dawson at gmail.com Mon Nov 24 17:47:14 2025 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Tue, 25 Nov 2025 11:47:14 +1000 Subject: [QGIS-Developer] QEP 404: Placement modes for curved label placement Message-ID: Hi lists, I've just submitted QEP 405, detailing new options for placing curved labels in QGIS. This QEP introduces additional placement "modes" for use with curved labels, allowing for much more fine-grained control over how text is positioned for curved labels. See the QEP PR at https://github.com/qgis/QGIS-Enhancement-Proposals/pull/354 for further details and discussion. Kind regards, Nyall -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyall.dawson at gmail.com Mon Nov 24 17:48:22 2025 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Tue, 25 Nov 2025 11:48:22 +1000 Subject: [QGIS-Developer] QEP 405: Multipart geometry labeling enhancements Message-ID: Hi lists, I've just submitted QEP 405: "Multipart geometry labeling enhancements". This QEP proposes a new option for labeling multi-part geometries in order to give users more cartographic control over the exact appearance and placement of their labels. The user interface will be reworked to accommodate this new option. See the QEP PR at https://github.com/qgis/QGIS-Enhancement-Proposals/pull/355 for further details and discussion. Kind regards, Nyall -------------- next part -------------- An HTML attachment was scrubbed... URL: From lova at kartoza.com Fri Nov 28 06:00:00 2025 From: lova at kartoza.com (Lova Andriarimalala) Date: Fri, 28 Nov 2025 17:00:00 +0300 Subject: [QGIS-Developer] QGIS Full Stack Developer Report from October 20 to November 14, 2025 Message-ID: Hello everyone, Please find below some highlights regarding the development and maintenance of the QGIS Websites for the last two weeks, from November 17 to November 28, 2025. *QGIS.org:* - Downloads listing page [New PR] - Improve contributors homepage [New PR] - Add workflow to test Nix packaging on pull requests [New PR] - Add new supporting contributors and enhanced image processing/email template [New PR] - Update installation instructions for QGIS to include Qt6 package option [New PR] - Review early contributors' commits count [Deployed] - Add cachix build workflow [Deployed] - Update playwright version and tests [Deployed] - Add application guidelines for Supporting Contributors recognition [Deployed] - Update nixpkgs input to follow QGIS versioning [Deployed] *QGIS Hub:* - Add upload size limit in each resource type [New PR] - Contributors API: Add remote head configuration and update fetch command [Deployed] *QGIS Planet:* - Add nix build workflow with cachix [Deployed] - Update nixpkgs input to follow QGIS-specific version [Deployed] *QGIS Infrastructure:* - Clone QGIS Downloads to an S3 Bucket - Init download redirections task - Some tweaks for the new infrastructure Have a nice weekend! Best regards, Lova Andriarimalala *QGIS Full Stack Developer * *T *: +27(0) 87 809 2702 *E *: lova at kartoza.com *W* : kartoza.com *This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you * *have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying* *of the contents is prohibited.* -------------- next part -------------- An HTML attachment was scrubbed... URL: