From kayazk82 at gmail.com  Sun May  3 14:40:32 2026
From: kayazk82 at gmail.com (ayazk khan)
Date: Mon, 4 May 2026 02:40:32 +0500
Subject: [QGIS-Developer] 
	=?utf-8?q?Request_for_Review_of_Pending_QGIS_Pl?=
	=?utf-8?q?ugin_=28Sector_Plotter_=E2=80=93_ID_5028=29?=
In-Reply-To: <CAJYs86wX8gRo3DGvb3QTrG4NWvBkXgs3uhVME7zk46n0UvSwVw@mail.gmail.com>
References: <CAJYs86wX8gRo3DGvb3QTrG4NWvBkXgs3uhVME7zk46n0UvSwVw@mail.gmail.com>
Message-ID: <CAJYs86w8S4XtQH05Ez9=cD3-dvZdqEoQBpi5jqHPjdbQ05MrMw@mail.gmail.com>

Dear QGIS Plugin Repository Maintainers,

I hope you are doing well.

I would like to kindly request a review of my plugin *?Sector Plotter?* (Plugin
ID: 5028), which I submitted to the QGIS Plugin Repository approximately
one month ago. As of now, the plugin still shows the status ?no public
version yet,? and I understand it may be pending approval.

The plugin is designed to create telecom sectors from CSV inputs using
azimuth, beamwidth, and KPI mapping, and I have ensured that all required
files and metadata are properly included.

I would greatly appreciate it if you could review the submission at your
convenience and let me know if any changes or corrections are required from
my side. I am happy to make any necessary updates promptly.

Thank you very much for your time and for maintaining the QGIS plugin
ecosystem.

Kind regards,

Ayaz Khan

On Mon, May 4, 2026 at 2:02?AM ayazk khan <kayazk82 at gmail.com> wrote:

> Dear QGIS Plugin Repository Maintainers,
>
> I hope you are doing well.
>
> I would like to kindly request a review of my plugin *?Sector Plotter?*
> (Plugin ID: 5028), which I submitted to the QGIS Plugin Repository
> approximately one month ago. As of now, the plugin still shows the status
> ?no public version yet,? and I understand it may be pending approval.
>
> The plugin is designed to create telecom sectors from CSV inputs using
> azimuth, beamwidth, and KPI mapping, and I have ensured that all required
> files and metadata are properly included.
>
> I would greatly appreciate it if you could review the submission at your
> convenience and let me know if any changes or corrections are required from
> my side. I am happy to make any necessary updates promptly.
>
> Thank you very much for your time and for maintaining the QGIS plugin
> ecosystem.
>
> Kind regards,
>
> Ayaz Khan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260504/14399b31/attachment.htm>

From lova at kartoza.com  Sun May  3 22:42:28 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Mon, 4 May 2026 08:42:28 +0300
Subject: [QGIS-Developer] 
	=?utf-8?q?Request_for_Review_of_Pending_QGIS_Pl?=
	=?utf-8?q?ugin_=28Sector_Plotter_=E2=80=93_ID_5028=29?=
In-Reply-To: <CAJYs86w8S4XtQH05Ez9=cD3-dvZdqEoQBpi5jqHPjdbQ05MrMw@mail.gmail.com>
References: <CAJYs86wX8gRo3DGvb3QTrG4NWvBkXgs3uhVME7zk46n0UvSwVw@mail.gmail.com>
 <CAJYs86w8S4XtQH05Ez9=cD3-dvZdqEoQBpi5jqHPjdbQ05MrMw@mail.gmail.com>
Message-ID: <CAMLC-sBF5=LeOy=QpbjVju=VtG9Vov9=cEy983fHVX7RAXPqZg@mail.gmail.com>

Dear Ayaz,

Please see the plugin approval process at
https://plugins.qgis.org/docs/approval. As mentioned there, do not hesitate
to get in touch with Admire if you have any questions regarding the process.

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.*


On Mon, 4 May 2026 at 00:40, ayazk khan via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Dear QGIS Plugin Repository Maintainers,
>
> I hope you are doing well.
>
> I would like to kindly request a review of my plugin *?Sector Plotter?* (Plugin
> ID: 5028), which I submitted to the QGIS Plugin Repository approximately
> one month ago. As of now, the plugin still shows the status ?no public
> version yet,? and I understand it may be pending approval.
>
> The plugin is designed to create telecom sectors from CSV inputs using
> azimuth, beamwidth, and KPI mapping, and I have ensured that all required
> files and metadata are properly included.
>
> I would greatly appreciate it if you could review the submission at your
> convenience and let me know if any changes or corrections are required from
> my side. I am happy to make any necessary updates promptly.
>
> Thank you very much for your time and for maintaining the QGIS plugin
> ecosystem.
>
> Kind regards,
>
> Ayaz Khan
>
> On Mon, May 4, 2026 at 2:02?AM ayazk khan <kayazk82 at gmail.com> wrote:
>
>> Dear QGIS Plugin Repository Maintainers,
>>
>> I hope you are doing well.
>>
>> I would like to kindly request a review of my plugin *?Sector Plotter?*
>> (Plugin ID: 5028), which I submitted to the QGIS Plugin Repository
>> approximately one month ago. As of now, the plugin still shows the status
>> ?no public version yet,? and I understand it may be pending approval.
>>
>> The plugin is designed to create telecom sectors from CSV inputs using
>> azimuth, beamwidth, and KPI mapping, and I have ensured that all required
>> files and metadata are properly included.
>>
>> I would greatly appreciate it if you could review the submission at your
>> convenience and let me know if any changes or corrections are required from
>> my side. I am happy to make any necessary updates promptly.
>>
>> Thank you very much for your time and for maintaining the QGIS plugin
>> ecosystem.
>>
>> Kind regards,
>>
>> Ayaz Khan
>>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260504/2fe0fcfd/attachment-0001.htm>

From valentin.buira at gmail.com  Tue May  5 15:24:14 2026
From: valentin.buira at gmail.com (Valentin Buira)
Date: Wed, 6 May 2026 00:24:14 +0200
Subject: [QGIS-Developer] (no subject)
In-Reply-To: <CAGCrGoPZMOcxTwjtSYeuy6wxNbpRSHJ5KZPrHzW76tJWJM5mig@mail.gmail.com>
References: <CAGCrGoPZMOcxTwjtSYeuy6wxNbpRSHJ5KZPrHzW76tJWJM5mig@mail.gmail.com>
Message-ID: <CANrSSZ=Oe8DQfSUMEr=wA+CWZ9pOoZHd8=wayUiyLhZpEeYr-w@mail.gmail.com>

Hi Sionigdha,

I am sorry your proposal could not make it.

I would like to thank you as well for the time you invested in your
proposal. And reassures you that it's not all lost,  the design you
did is there and could be used as a basis for future work

I would also like to encourage you to pursue in the QGIS ecosystem. I
was not accepted either in GSoC at the time, but here I am. I hope the
community can offer you a way to get involved in QGIS project.

Since you are not binded  to a GSoC proposal anymore, maybe having a
prototype in the shape of a QGIS plugin would be doable ?

Cheers,
Valentin


Le jeu. 30 avr. 2026 ? 20:40, Sionigdha Sadhukhan via QGIS-Developer
<qgis-developer at lists.osgeo.org> a ?crit :
>
> Thank you all for your time.Thanks for guiding through.Specially Nyall ,Even and Valentine!
> _______________________________________________
> 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 nyall.dawson at gmail.com  Wed May  6 20:20:12 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Thu, 7 May 2026 13:20:12 +1000
Subject: [QGIS-Developer] Announcing QEP 425: Document stable API policy
Message-ID: <CAB28AshNiUj0kNuznjUfssv3UcLY-cP8JBLVyoTH7Hj=C89QJw@mail.gmail.com>

Hi lists,

I've taken some time to write up our (currently undocumented) stable API
policies. This has been submitted as
https://github.com/qgis/QGIS-Enhancement-Proposals/pull/382 for discussion.

It is initially intended as a formal description of CURRENT POLICIES ONLY,
which can be later modified and revised (in an atomic manner) if we want to
change any of these policies. As such, please refrain from using this
initial request as a place to discuss changes to current practice. Rather,
let's keep discussion focused on whether this is an accurate and complete
description of our current policies. ?

The end goal here is having a formal policy in place describing all our API
stability rules, which will help ease new developers into contributing
effectively to QGIS and remove some of the unspoken assumptions surrounding
QGIS development.

Regards,
Nyall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260507/ef18f6e9/attachment.htm>

From jacobchaar at live.ca  Thu May  7 08:24:05 2026
From: jacobchaar at live.ca (jacob chaar)
Date: Thu, 7 May 2026 15:24:05 +0000
Subject: [QGIS-Developer] PyQGIS question: get SVG content with resolved
 param() values from QgsSvgMarkerSymbolLayer or QgsSVGFillSymbolLayer
Message-ID: <EB7513FA-5E4F-41A6-B5A1-37A2DCA699F5@live.ca>

Hello QGIS community,

I am working on a QGIS plugin, and I have a question about SVG symbol rendering in PyQGIS.

I am using SVG-based symbol layers (for example, QgsSvgMarkerSymbolLayer / QgsSVGFillSymbolLayer).  
The SVG file contains placeholders such as param(fill), param(fill-opacity), param(outline), etc.

In Python, I can access:
- the SVG path (path()/svgFilePath())
- the symbol layer properties (color, opacity, outline, etc.)

What I need is the final SVG XML content with those param(...) values already resolved, exactly as QGIS uses it at render time.

My questions:
1. Is there a public PyQGIS API that returns the resolved SVG source (not just a rendered image)?
2. If not, is there a recommended approach to reproduce QGIS resolution logic reliably?
3. Are there edge cases I should handle (quoted params, default values, data-defined overrides, expression-based values)?

Any guidance or examples would be very appreciated.

Thank you!

Best regards,  
Jacob Ch.

From andreas at qgis.org  Fri May  8 06:25:26 2026
From: andreas at qgis.org (Andreas Neumann)
Date: Fri, 8 May 2026 15:25:26 +0200
Subject: [QGIS-Developer] Accommodation at QGIS user conference and
 contributor meeting in Laax
Message-ID: <CAB2Z92A+n6OUbNqLoQFqcn2MHNA90H_9Jx8cV=G=ivF_pddLEg@mail.gmail.com>

Dear QGIS contributors,

I reserved a group accommodation (16 single rooms, 3 double rooms, 6
triple, one 4-bed and two 8-bed rooms). The prices range from 40 to 55 ?
per night - these are really affordable prices for Switzerland. It includes
breakfast (bread, butter, jam, cheese, cereals, fruits, tea and coffee).

If you are interested in such a room / bed, please let me know.

More information at
https://docs.google.com/spreadsheets/d/1HMNEXrUyJimRMq31JtcCduSk56alEGu1XqR3RO0-7dM/edit?usp=sharing

About rooms: if you snore, please reserve a single room, otherwise I would
appreciate it if you could also fill the shared rooms.

In order to reserve, please ask me for editing permission of the
spreadsheet and afterwards fill in your contacts.

In case you fill in and then need to cancel the accommodation, please do
not forget to also remove yourself from the spreadsheet.

Best regards,
Andreas

--
Andreas Neumann
QGIS.ORG board member (treasurer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260508/140e7595/attachment.htm>

From gdt at lexort.com  Sun May 10 11:29:50 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sun, 10 May 2026 14:29:50 -0400
Subject: [QGIS-Developer] segfault with 4.0.0 and 4.0.2+18, qt6
Message-ID: <rmiecjjm82p.fsf@s1.lexort.com>

I'm trying to keep an experimental qgis4 pkgsrc pkg with qt6 up to date.
This is disjoint from the operational 3.44.9 (qt5) package.

This is all on NetBSD 10 amd64, mostly with gcc10 unless packages are
coded to need more bleeding-edge c++ languagea variants.

Earlier, I had 4.0.0 built from git
f2317a9ab1b8b0ab95c88d0cb0a2e53530812076 against qt6 6.10.0(?).  That
worked mostly fine, except that access to secret storage failed.

Then, I had updated qt6 to 6.11.0 (because pkgsrc did, which should be
ok), and I updated qgis to 4.0.2+18 (meaning 18 commits beyond the tag).
That starts up, but segfaults on opening a project.

Next I'm going to roll back qt6 and retest.

Is anyone else using qt 6.11.0?
Does anyone have any clues from this backtrace?



(gdb) bt
#0  0x00000000ffffffff in ?? ()
#1  0x000074c6abd66186 in QObjectPrivate::ConnectionData::cleanOrphanedConnectionsImpl(QObject*, QObjectPrivate::ConnectionData::LockPolicy) () from /usr/pkg/qt6/lib/libQt6Core.so.6
#2  0x000074c6ac014cac in ?? () from /usr/pkg/qt6/lib/libQt6Core.so.6
#3  0x000074c6abd6799a in QObject::disconnect(QMetaObject::Connection const&) () from /usr/pkg/qt6/lib/libQt6Core.so.6
#4  0x000074c6acd33844 in ?? () from /usr/pkg/qt6/lib/libQt6Qml.so.6
#5  0x000074c6acc3ed4e in ?? () from /usr/pkg/qt6/lib/libQt6Qml.so.6
#6  0x000074c6acc3f93e in ?? () from /usr/pkg/qt6/lib/libQt6Qml.so.6
#7  0x000074c6acc3fd28 in ?? () from /usr/pkg/qt6/lib/libQt6Qml.so.6
#8  0x000074c6acc3b49d in QV4::GCStateMachine::transition() () from /usr/pkg/qt6/lib/libQt6Qml.so.6
#9  0x000074c6abd69a9b in QObject::event(QEvent*) () from /usr/pkg/qt6/lib/libQt6Core.so.6
#10 0x000074c6b6784c3b in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/pkg/qt6/lib/libQt6Widgets.so.6
#11 0x000074c6ceb18c56 in QgsApplication::notify(QObject*, QEvent*) () from /usr/pkg/lib/libqgis_core.so.4.0.0
#12 0x000074c6abd32d25 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/pkg/qt6/lib/libQt6Core.so.6
#13 0x000074c6abd36fca in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/pkg/qt6/lib/libQt6Core.so.6
#14 0x000074c6abf842e8 in ?? () from /usr/pkg/qt6/lib/libQt6Core.so.6
#15 0x000074c6a4256203 in g_main_dispatch () from /usr/pkg/lib/libglib-2.0.so.0
#16 0x000074c6a42593f9 in g_main_context_iterate_unlocked.constprop () from /usr/pkg/lib/libglib-2.0.so.0
#17 0x000074c6a4259b51 in g_main_context_iteration () from /usr/pkg/lib/libglib-2.0.so.0
#18 0x000074c6abf837ec in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/pkg/qt6/lib/libQt6Core.so.6
#19 0x000074c6abd3d183 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/pkg/qt6/lib/libQt6Core.so.6
#20 0x000074c6abd3b460 in QCoreApplication::exec() () from /usr/pkg/qt6/lib/libQt6Core.so.6
#21 0x00000001b88149d9 in ?? ()
#22 0x00000001b880b0fd in ?? ()
#23 0x00007f7f8a40baf8 in ?? () from /usr/libexec/ld.elf_so
#24 0x0000000000000002 in ?? ()
#25 0x00007f7fff918908 in ?? ()
#26 0x00007f7fff91891a in ?? ()
#27 0x0000000000000000 in ?? ()


From r.nijssen at terglobo.nl  Mon May 11 00:13:23 2026
From: r.nijssen at terglobo.nl (Raymond Nijssen)
Date: Mon, 11 May 2026 09:13:23 +0200
Subject: [QGIS-Developer] Accommodation at QGIS user conference and
 contributor meeting in Laax
In-Reply-To: <CAB2Z92A+n6OUbNqLoQFqcn2MHNA90H_9Jx8cV=G=ivF_pddLEg@mail.gmail.com>
References: <CAB2Z92A+n6OUbNqLoQFqcn2MHNA90H_9Jx8cV=G=ivF_pddLEg@mail.gmail.com>
Message-ID: <760c2483-7c36-43ab-9fc5-7d100073375f@terglobo.nl>

Hi Andreas,

For who are those rooms intended? Since you are mailing this to the 
developers list only I think it's meant for participants to the 
contributing meeting? But it is not clear and in the Dutch user group we 
have some members who are considering going to the UC but are looking 
for cheap accommodations. Can I tell them, and thus all other members, 
about this option?

Adding the link to either the hackfest wiki page or otherwise to the UC 
website would be more clear?

Kind regards,
Raymond



On 5/8/26 15:25, Andreas Neumann via QGIS-Developer wrote:
> Dear QGIS contributors,
> 
> I reserved a group accommodation (16 single rooms, 3 double rooms, 6 
> triple, one 4-bed and two?8-bed rooms). The prices range from 40 to 55 ? 
> per night - these are really affordable prices for Switzerland. It 
> includes breakfast?(bread, butter, jam, cheese, cereals, fruits, tea and 
> coffee).
> 
> If you are interested in such a room / bed, please let me know.
> 
> More information at https://docs.google.com/spreadsheets/ 
> d/1HMNEXrUyJimRMq31JtcCduSk56alEGu1XqR3RO0-7dM/edit?usp=sharing 
> <https://docs.google.com/spreadsheets/ 
> d/1HMNEXrUyJimRMq31JtcCduSk56alEGu1XqR3RO0-7dM/edit?usp=sharing>
> 
> About rooms: if you snore, please reserve a single room, otherwise I 
> would appreciate it if you could also fill the shared rooms.
> 
> In order to reserve, please ask me for editing permission of the 
> spreadsheet and afterwards fill in your contacts.
> 
> In case you fill in and then need to cancel the accommodation, please do 
> not forget to also remove yourself from the spreadsheet.
> 
> Best regards,
> Andreas
> 
> --
> Andreas Neumann
> QGIS.ORG <http://QGIS.ORG> board member (treasurer)
> 
> _______________________________________________
> 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 lova at kartoza.com  Mon May 11 01:15:25 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Mon, 11 May 2026 11:15:25 +0300
Subject: [QGIS-Developer] QGIS Full Stack Developer Report from April 27th
 to May 8th, 2026
Message-ID: <CAMLC-sBiy8igyxis5AM4qCJiw4k5R+NoZo82rAGboDZqy0G__Q@mail.gmail.com>

Hello everyone,

Please find some highlights regarding the development and maintenance of
the QGIS Websites for the last two weeks, from April 27th to May 8th, 2026.

*QGIS.org:*

   - Improve transifex string pushing
   <https://github.com/qgis/QGIS-Website/pull/990> [New PR]
   - Add torrent-based alternative download for Windows and macOS
   <https://github.com/qgis/QGIS-Website/pull/971> [Older PR - Deployed]
   - feat: add script to generate mtime cache from S3 object metadata
   <https://github.com/qgis/QGIS-Website/pull/975> [Deployed]
   - Remove automated statement from changelog front matter
   <https://github.com/qgis/QGIS-Website/pull/977> [Deployed]
   - Add deduplication of files from windows folder in S3 file explorer
   <https://github.com/qgis/QGIS-Website/pull/978> [Deployed]
   - Fix shortcode syntax in overview.md for local groups link
   <https://github.com/qgis/QGIS-Website/pull/979> [Deployed]
   - Enhance translation build process and fix shortcode issues in
   translated files <https://github.com/qgis/QGIS-Website/pull/986>
    [Deployed]

*QGIS Plugins:*

   - Expose security checks rules and allow managing them
   <https://github.com/qgis/QGIS-Plugins-Website/pull/316> [New PR]

*QGIS Feed:*

   - Add expired entries to the home page (web only)
   <https://github.com/qgis/QGIS-Feed-Website/pull/174> [Deployed]
   - Add publication state logic for feed entries and update display in
   templates <https://github.com/qgis/QGIS-Feed-Website/pull/175> [Deployed]

*QGIS Infrastructure:*

   - Deployment session with Tim and Ivan
   - Docs updates according to the deployment session

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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260511/4885a9dc/attachment.htm>

From andreas at qgis.org  Mon May 11 01:18:51 2026
From: andreas at qgis.org (Andreas Neumann)
Date: Mon, 11 May 2026 10:18:51 +0200
Subject: [QGIS-Developer] Accommodation at QGIS user conference and
 contributor meeting in Laax
In-Reply-To: <760c2483-7c36-43ab-9fc5-7d100073375f@terglobo.nl>
References: <CAB2Z92A+n6OUbNqLoQFqcn2MHNA90H_9Jx8cV=G=ivF_pddLEg@mail.gmail.com>
 <760c2483-7c36-43ab-9fc5-7d100073375f@terglobo.nl>
Message-ID: <CAB2Z92CEyLtvAKnudjZoGo_ZaAUqMJqusWAt8x7aDfb+ipZXbg@mail.gmail.com>

Hi Raymond,

The rooms are for everyone. But I informed the contributor community first,
to give them a chance to get a room before the rest of the crowd.

So far - I did not hear back much.

So yes, please offer it to the Dutch QGIS community. First comes, first
served.

Marco promised to add the link to the HF and conf page - but apparently did
not do it so far. I guess I will do the Github page myself, since I can do
that without him.

Andreas

On Mon, 11 May 2026 at 10:14, Raymond Nijssen via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hi Andreas,
>
> For who are those rooms intended? Since you are mailing this to the
> developers list only I think it's meant for participants to the
> contributing meeting? But it is not clear and in the Dutch user group we
> have some members who are considering going to the UC but are looking
> for cheap accommodations. Can I tell them, and thus all other members,
> about this option?
>
> Adding the link to either the hackfest wiki page or otherwise to the UC
> website would be more clear?
>
> Kind regards,
> Raymond
>
>
>
> On 5/8/26 15:25, Andreas Neumann via QGIS-Developer wrote:
> > Dear QGIS contributors,
> >
> > I reserved a group accommodation (16 single rooms, 3 double rooms, 6
> > triple, one 4-bed and two 8-bed rooms). The prices range from 40 to 55 ?
> > per night - these are really affordable prices for Switzerland. It
> > includes breakfast (bread, butter, jam, cheese, cereals, fruits, tea and
> > coffee).
> >
> > If you are interested in such a room / bed, please let me know.
> >
> > More information at https://docs.google.com/spreadsheets/
> > d/1HMNEXrUyJimRMq31JtcCduSk56alEGu1XqR3RO0-7dM/edit?usp=sharing
> > <https://docs.google.com/spreadsheets/
> > d/1HMNEXrUyJimRMq31JtcCduSk56alEGu1XqR3RO0-7dM/edit?usp=sharing>
> >
> > About rooms: if you snore, please reserve a single room, otherwise I
> > would appreciate it if you could also fill the shared rooms.
> >
> > In order to reserve, please ask me for editing permission of the
> > spreadsheet and afterwards fill in your contacts.
> >
> > In case you fill in and then need to cancel the accommodation, please do
> > not forget to also remove yourself from the spreadsheet.
> >
> > Best regards,
> > Andreas
> >
> > --
> > Andreas Neumann
> > QGIS.ORG <http://QGIS.ORG> board member (treasurer)
> >
> > _______________________________________________
> > 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
>


-- 

--
Andreas Neumann
QGIS.ORG board member (treasurer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260511/3e8aa901/attachment.htm>

From gdt at lexort.com  Mon May 11 15:12:19 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 11 May 2026 18:12:19 -0400
Subject: [QGIS-Developer] qgis4 segfaults with qt6 6.11.0, ok with 6.10.2
In-Reply-To: <rmiecjjm82p.fsf@s1.lexort.com> (Greg Troxel via's message of
 "Sun, 10 May 2026 14:29:50 -0400")
References: <rmiecjjm82p.fsf@s1.lexort.com>
Message-ID: <rmi4ikdk33w.fsf@s1.lexort.com>

Yesterday I wrote that starting up qgis 4.0.2(+18 commits) (from
pkgsrc-wip/qgis) resulted in a crash.  It turns out the thing that
matters for crash vs works is not qgis version, but qt6 version.

(This is all about qgis 4, because qgis 3.44 uses qt5 (and both qgis 3.44
and qt5 are apparently stable).)

This is all on NetBSD 10 amd64.

QGIS	QT	RESULT	
4.0.0	6.10.2	works
4.0.2   6.10.2	works
4.0.0	6.11.0	crashes on opening project file
4.0.2	6.11.0	crashes on opening project file

Have other people tried to run qgis, or other complicated qt programs
built against qt6 6.11.0?   It looks to me like 6.11.0 redid a bunch of
things and I'm guessing they broke things.  But there could be a latent
bug in qgis.

From snigdha.lee75 at gmail.com  Wed May 13 01:02:21 2026
From: snigdha.lee75 at gmail.com (Sionigdha Sadhukhan)
Date: Wed, 13 May 2026 13:32:21 +0530
Subject: [QGIS-Developer] (no subject)
In-Reply-To: <CANrSSZ=Oe8DQfSUMEr=wA+CWZ9pOoZHd8=wayUiyLhZpEeYr-w@mail.gmail.com>
References: <CAGCrGoPZMOcxTwjtSYeuy6wxNbpRSHJ5KZPrHzW76tJWJM5mig@mail.gmail.com>
 <CANrSSZ=Oe8DQfSUMEr=wA+CWZ9pOoZHd8=wayUiyLhZpEeYr-w@mail.gmail.com>
Message-ID: <CAGCrGoMKcRssoCcv1JjMddngm+pp6K5YuSfiAEbNVL6-rdiifQ@mail.gmail.com>

Hi Valentin,

Firstly sorry for the late reply, I was finishing up my end semester exams
and couldnt reply until now.

Thank you for the kind words, it genuinely helps. And you are right that
the work was not wasted. I did come out of this understanding the QGIS
codebase and contribution process a lot better than when I started, and
that is valuable regardless of the outcome.

The plugin idea caught my attention. I am curious to know more about what
you had in mind, would it essentially be the same JSON toolkit algorithms
but packaged as a plugin rather than contributed directly to core? I am
asking because I want to understand whether this would be more of a
personal learning project or something that could eventually feed back into
the QGIS ecosystem in some way. Either way I am open to it, just want to
understand the direction better before diving in.

Best regards , Sionigdha

On Wed, 6 May 2026 at 03:54, Valentin Buira <valentin.buira at gmail.com>
wrote:

> Hi Sionigdha,
>
> I am sorry your proposal could not make it.
>
> I would like to thank you as well for the time you invested in your
> proposal. And reassures you that it's not all lost,  the design you
> did is there and could be used as a basis for future work
>
> I would also like to encourage you to pursue in the QGIS ecosystem. I
> was not accepted either in GSoC at the time, but here I am. I hope the
> community can offer you a way to get involved in QGIS project.
>
> Since you are not binded  to a GSoC proposal anymore, maybe having a
> prototype in the shape of a QGIS plugin would be doable ?
>
> Cheers,
> Valentin
>
>
> Le jeu. 30 avr. 2026 ? 20:40, Sionigdha Sadhukhan via QGIS-Developer
> <qgis-developer at lists.osgeo.org> a ?crit :
> >
> > Thank you all for your time.Thanks for guiding through.Specially Nyall
> ,Even and Valentine!
> > _______________________________________________
> > 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260513/5a774188/attachment.htm>

From rdmailings at duif.net  Wed May 13 03:23:51 2026
From: rdmailings at duif.net (Richard Duivenvoorde)
Date: Wed, 13 May 2026 12:23:51 +0200
Subject: [QGIS-Developer] qgis4 segfaults with qt6 6.11.0, ok with 6.10.2
In-Reply-To: <rmi4ikdk33w.fsf@s1.lexort.com>
References: <rmiecjjm82p.fsf@s1.lexort.com> <rmi4ikdk33w.fsf@s1.lexort.com>
Message-ID: <005d74f8-11b1-4628-8556-ae2807194cd4@duif.net>

I've succesfully compiled and ran QGIS4 with Qt 6.9.2 and 6.10.2 as those are available in Debian Testing.

The Flathub build is also on Qt 6.10: https://github.com/flathub/org.qgis.qgis/blob/master/org.qgis.qgis.json

Qt 6.11 is not packaged so much apparently?
Not sure what is used for the Osgeo4W builds?

Maybe you are the first one to hit an issue?

I think I've heard there were some issues with opening older project files in QGIS4, but as Qt6.10 is working that is probably not the issue here?

Can you create an issue maybe, preferably with a gdb trace on a debug build? Hopefully core devs have a clue then?

Regards,

Richard Duivenvoorde


On 5/12/26 00:12, Greg Troxel via QGIS-Developer wrote:
> Yesterday I wrote that starting up qgis 4.0.2(+18 commits) (from
> pkgsrc-wip/qgis) resulted in a crash.  It turns out the thing that
> matters for crash vs works is not qgis version, but qt6 version.
> 
> (This is all about qgis 4, because qgis 3.44 uses qt5 (and both qgis 3.44
> and qt5 are apparently stable).)
> 
> This is all on NetBSD 10 amd64.
> 
> QGIS	QT	RESULT	
> 4.0.0	6.10.2	works
> 4.0.2   6.10.2	works
> 4.0.0	6.11.0	crashes on opening project file
> 4.0.2	6.11.0	crashes on opening project file
> 
> Have other people tried to run qgis, or other complicated qt programs
> built against qt6 6.11.0?   It looks to me like 6.11.0 redid a bunch of
> things and I'm guessing they broke things.  But there could be a latent
> bug in qgis.
> _______________________________________________
> 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 andreaerdna at libero.it  Wed May 13 04:09:42 2026
From: andreaerdna at libero.it (Andrea Giudiceandrea)
Date: Wed, 13 May 2026 13:09:42 +0200
Subject: [QGIS-Developer] qgis4 segfaults with qt6 6.11.0, ok with 6.10.2
Message-ID: <b8ff179b-b5ce-4728-ab5d-e8008044799f@libero.it>

Il 13/05/2026 12:23, Richard Duivenvoorde via QGIS-Developer ha scritto:
> Not sure what is used for the Osgeo4W builds?

Hi Richard and list,
the latest QGIS 4.1.0-Master and QGIS 4.0.2 provided by OSGeo4W use Qt 
6.11.0.

Regards.

Andrea

From gdt at lexort.com  Wed May 13 05:23:06 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 13 May 2026 08:23:06 -0400
Subject: [QGIS-Developer] qgis4 segfaults with qt6 6.11.0, ok with 6.10.2
In-Reply-To: <005d74f8-11b1-4628-8556-ae2807194cd4@duif.net> (Richard
 Duivenvoorde's message of "Wed, 13 May 2026 12:23:51 +0200")
References: <rmiecjjm82p.fsf@s1.lexort.com> <rmi4ikdk33w.fsf@s1.lexort.com>
 <005d74f8-11b1-4628-8556-ae2807194cd4@duif.net>
Message-ID: <rmiecjfebx1.fsf@s1.lexort.com>

Richard Duivenvoorde <rdmailings at duif.net> writes:

> I've succesfully compiled and ran QGIS4 with Qt 6.9.2 and 6.10.2 as those are available in Debian Testing.

4.0.0 and 4.0.2+18 both work with 6.10.2, except that they fail to find
the authentication provider.  I suspect the authentication provider
problem is about some qt6 part not being in pkgsrc yet.

> I think I've heard there were some issues with opening older project
> files in QGIS4, but as Qt6.10 is working that is probably not the
> issue here?

4.0.2+18/6.10.2 will open a project file and act normally while
4.0.2+18/6.11.0 crashes on the same file.

Starting without a project file is ok.

Other complicated qt6-using programs work with 6.11.0 (on
NetBSD-current), according to others.

> Can you create an issue maybe, preferably with a gdb trace on a debug
> build? Hopefully core devs have a clue then?

I see from Andrea that osgeo4w has 4.0.2 with Qt 6.11.0, but I wonder

  does it work :-) ?

  surely that uses some different implementations than on POSIX, so
  while it's a very helpful data point, I'm not sure what I can
  conclude.

I should mention that I'm using X11 (which I've been using since I
upgraded from X10!), given the "wayland is the answer, what was the
question" problems in some corners of the GNU/Linux world.

Has anyone run qgis 4 with 6.11.x on POSIX with X11?

Overnight, pkgsrc got qt6 6.11.1, changelog "bugfixes".  I am updating
and will rebuild all and see how it goes.  If still not ok, I'll flip to
debug builds and build qt6 and qgis again, so gdb can get better
backtraces, and file an issue.

From sylvain.poulain at giscan.com  Wed May 13 07:12:38 2026
From: sylvain.poulain at giscan.com (Sylvain POULAIN)
Date: Wed, 13 May 2026 18:12:38 +0400 (MUT)
Subject: [QGIS-Developer] qgis4 segfaults with qt6 6.11.0, ok with 6.10.2
In-Reply-To: <rmiecjfebx1.fsf@s1.lexort.com>
References: <rmiecjjm82p.fsf@s1.lexort.com> <rmi4ikdk33w.fsf@s1.lexort.com>
 <005d74f8-11b1-4628-8556-ae2807194cd4@duif.net>
 <rmiecjfebx1.fsf@s1.lexort.com>
Message-ID: <1872529486.128862.1778681558794@email.ionos.fr>

Hello, 

No problem on my side:
QGIS 4.0.2-Norrk?ping
Libraries
Version de Qt 6.11.0
Version de Python 3.14.4
GDAL version 3.12.4 ? Chicoutimi
Version de Proj 9.8.1
Version de la base de donn?es du registre EPSG v12.029 (2025-10-02)
Version de GEOS 3.14.1-CAPI-1.20.5
SFCGAL version 2.2.0
GeographicLib version Pas de support
Version de SQLite 3.53.0
Version de PDAL 2.9.3
Version du client PostgreSQL 18.3
Version de SpatiaLite 5.1.0
Version de QWT 6.3.0
Version de QScintilla2 2.14.1
Version de l'OS Manjaro Linux

echo $XDG_SESSION_TYPE
x11

No crash on opening a qgz/qgs project

Best regards,
---
Sylvain POULAIN 


> Le 13/05/2026 16:23 +04, Greg Troxel via QGIS-Developer <qgis-developer at lists.osgeo.org> a ?crit :
> 
>  
> Richard Duivenvoorde <rdmailings at duif.net> writes:
> 
> > I've succesfully compiled and ran QGIS4 with Qt 6.9.2 and 6.10.2 as those are available in Debian Testing.
> 
> 4.0.0 and 4.0.2+18 both work with 6.10.2, except that they fail to find
> the authentication provider.  I suspect the authentication provider
> problem is about some qt6 part not being in pkgsrc yet.
> 
> > I think I've heard there were some issues with opening older project
> > files in QGIS4, but as Qt6.10 is working that is probably not the
> > issue here?
> 
> 4.0.2+18/6.10.2 will open a project file and act normally while
> 4.0.2+18/6.11.0 crashes on the same file.
> 
> Starting without a project file is ok.
> 
> Other complicated qt6-using programs work with 6.11.0 (on
> NetBSD-current), according to others.
> 
> > Can you create an issue maybe, preferably with a gdb trace on a debug
> > build? Hopefully core devs have a clue then?
> 
> I see from Andrea that osgeo4w has 4.0.2 with Qt 6.11.0, but I wonder
> 
>   does it work :-) ?
> 
>   surely that uses some different implementations than on POSIX, so
>   while it's a very helpful data point, I'm not sure what I can
>   conclude.
> 
> I should mention that I'm using X11 (which I've been using since I
> upgraded from X10!), given the "wayland is the answer, what was the
> question" problems in some corners of the GNU/Linux world.
> 
> Has anyone run qgis 4 with 6.11.x on POSIX with X11?
> 
> Overnight, pkgsrc got qt6 6.11.1, changelog "bugfixes".  I am updating
> and will rebuild all and see how it goes.  If still not ok, I'll flip to
> debug builds and build qt6 and qgis again, so gdb can get better
> backtraces, and file an issue.
> _______________________________________________
> 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 jostev at bgs.ac.uk  Fri May 15 09:11:56 2026
From: jostev at bgs.ac.uk (John Stevenson - BGS)
Date: Fri, 15 May 2026 16:11:56 +0000
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <abec0b1f-5396-4419-80f0-acbcd4225a93@gmail.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
 <CALuHMPCUJw6mXaDs95uxhSba-_Eydjjw87d50S==G0YgBsR3Hw@mail.gmail.com>
 <CAC7zN95yo1ShvAQih1AxeM93PQvr722PjvOwD4V873O5jD62hg@mail.gmail.com>
 <bf4f5f3b-2502-496a-88c3-9953a40f6612@gmail.com>
 <CAB28Asg_1NLm7hMPP45GRRDKxH93VeRSR-7FJSE7PyfjXjMq0Q@mail.gmail.com>
 <abec0b1f-5396-4419-80f0-acbcd4225a93@gmail.com>
Message-ID: <LO2P123MB54147148CBEA823FE3C52D3681042@LO2P123MB5414.GBRP123.PROD.OUTLOOK.COM>

Regarding this thread, I just spotted today that it is still possible to get a standalone Windows installer that includes the grids from the downloads page.

https://qgis.org/resources/installation-guide/#offline-standalone-installers

Thank you for making this available.

John

From: QGIS-Developer <qgis-developer-bounces at lists.osgeo.org> On Behalf Of R?gis Haubourg via QGIS-Developer
Sent: 24 March 2026 12:38
To: Nyall Dawson <nyall.dawson at gmail.com>
Cc: qgis-developer <qgis-developer at lists.osgeo.org>
Subject: Re: [QGIS-Developer] Reducing the size of our download packages


Haaa laughing of myself :)

Sorry for the noise.

Bien cordialement,

R?gis Haubourg
On 24/03/2026 12:02, Nyall Dawson wrote:

On Tue, 24 Mar 2026, 8:02?pm R?gis Haubourg via QGIS-Developer, <qgis-developer at lists.osgeo.org<mailto:qgis-developer at lists.osgeo.org>> wrote:

Maybe we could add a mechanism where proj grid files can be imported to the user profile, so any user could download grids.

Well, we already have https://github.com/qgis/QGIS/pull/31622

Is that what you mean?

Nyall


Some caveats to avoid with multi profile management. I'd be in favor of storing proj grids once per user $APPDATA profile, not in each QGIS profile

Bien cordialement,

R?gis Haubourg
On 24/03/2026 10:29, Matthias Kuhn via QGIS-Developer wrote:
Hi all,

Thanks for raising this discussion, Tim.
There recently was a discussion about that on a github issue.
The new macOS packages didn't ship grid packages out of the box in the beginning and this was a blocker for some users so I ended up bundling the data files again with the macOS packages. The full discussion can be seen here https://github.com/qgis/QGIS/issues/64486

Key takeaways for me: If we want to split this apart, we need to make it very easy for users to install missing bits, the current process would need some improvements. If this is shipped as a separate installer package, we need to make sure it works across all platforms.

Kind regards
Matthias

On Tue, Mar 24, 2026 at 9:33?AM Alexander Bruy via QGIS-Developer <qgis-developer at lists.osgeo.org<mailto:qgis-developer at lists.osgeo.org>> wrote:
If I'm not wrong, our standalone installer is based on the OSGeo4W and installs the latter. So users can easily
use the OSGeo4W installer to download any additional dependencies they want/need.

Another option would be to add an option to the standalone installer to download grids, similarly to what we had
in the old NSIS installer for Alaska dataset.

??, 23 ???. 2026??. ? 09:20 Tim Sutton via QGIS-Developer <qgis-developer at lists.osgeo.org<mailto:qgis-developer at lists.osgeo.org>> ????:
Hi all

Here in the infrastructure management club for QGIS we have been embarking on a plan to slowly divest ourselves of 'big tech'. At the end of last year we switched off cloudflare CDN and implemented our own caching servers. At that time we were doing around 130TB of throughput (including what was being soaked up by Cloudflare). As of last month we did 430TB of throughput without the help of Cloudflare.

We are trying to optimise costs - that bandwidth alone cost us in the neighbourhood of 500? per month. To reduce costs we can approach the problem in two way:

1. optimise the infrastructure - we (QGIS Devops team) are busy looking into ways to do that...
2. reduce the download size...

We are wondering if the datum shift files could be split out from the main installer and fetched as an optional extra? Or maybe on demand as you need them? We could set up some infrastructure for hosting them, but we would need some help on the application side to implement logic to go and grab shift files that are not locally cached. Is anyone able to help with this?

Regards

Tim




--

Tim Sutton
Kartoza Cofounder
Tim is a member of the QGIS Project Steering Committee

T : +27(0) 87 809 2702          E : tim at kartoza.com<mailto:tim at kartoza.com>          W : kartoza.com<http://kartoza.com/>

[https://kartoza.com/files/KartozaEmailSignature.gif]

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.
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer at lists.osgeo.org<mailto: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


--
Alexander Bruy
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer at lists.osgeo.org<mailto: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<mailto: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<mailto: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


This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260515/ab09007e/attachment-0001.htm>

From anitagraser at gmx.at  Sun May 17 03:29:52 2026
From: anitagraser at gmx.at (Anita Graser)
Date: Sun, 17 May 2026 12:29:52 +0200
Subject: [QGIS-Developer] 2026 QGIS Grant Proposals final results
Message-ID: <c886ebf1-89ce-42ba-9b26-67bb9fd1d455@gmx.at>

Dear QGIS Community,

On behalf of the QGIS project, I'm extremely pleased to announce the 
funded proposals for our 2026 QGIS grant programme:

Due to the high quality of proposals and since the budget situation 
allows us to increase the grant programme budget, we are happy to 
announce that all proposals that passed the discussion phase will be 
funded and that there is no need for a voting this year. Read the full 
announcement here:

https://blog.qgis.org/2026/05/17/qgis-grant-programme-2026-results/

Looking forward to seeing the improvements land in QGIS!

Regards,

Anita


From r.nijssen at terglobo.nl  Mon May 18 02:21:41 2026
From: r.nijssen at terglobo.nl (Raymond Nijssen)
Date: Mon, 18 May 2026 11:21:41 +0200
Subject: [QGIS-Developer] PSA: do NOT build QGIS with libspatialindex >=
 2.0
In-Reply-To: <CAB28AsgA0k+uiB9Wn-Ca9GSWgc6R3VcOcptcu50Rc7wMH1j=vw@mail.gmail.com>
References: <CAB28AsjMDFpAeDqLqtu7HdzkY6afb4bYfNKfV7zhOqwL27ts4w@mail.gmail.com>
 <CAB28AsgA0k+uiB9Wn-Ca9GSWgc6R3VcOcptcu50Rc7wMH1j=vw@mail.gmail.com>
Message-ID: <2a5f1851-16bc-4b3c-a2b1-f7b9e9ed085b@terglobo.nl>

Hi! Today I upgraded to Ubuntu 26.04 which ships with libspatialindex 
2.1 and could not compile QGIS. For anyone running into the same 
problem, you can set the compile option WITH_INTERNAL_SPATIALINDEX=ON 
and use the libspatialindex 2.0 shipped with QGIS.

https://github.com/qgis/QGIS/commit/0b1ba631b36dc6903f3dcdf7ffe3970cdedab4dd

Raymond


On 9/16/25 02:39, Nyall Dawson via QGIS-Developer wrote:
> 
> 
> On Tue, 16 Sept 2025 at 10:37, Nyall Dawson <nyall.dawson at gmail.com 
> <mailto:nyall.dawson at gmail.com>> wrote:
> 
>     Hi list,
> 
>     While tracking down the failures from https://github.com/qgis/QGIS/
>     pull/63180 <https://github.com/qgis/QGIS/pull/63180>, it's revealed
>     that using QGIS with libspatialindex >= 2.0 gives completely
>     misleading results for nearest neighbour geometry searches.
> 
>     The root cause is an optimisation from the upstream library
>     (https://github.com/libspatialindex/libspatialindex/
>     commit/6fe9ff769243579ed74f7f27409dd1dda6591634 <https://github.com/
>     libspatialindex/libspatialindex/
>     commit/6fe9ff769243579ed74f7f27409dd1dda6591634>) that breaks how
>     downstream clients could previously implement custom nearest
>     neighbour comparators. From my research I don't think this is
>     fixable in QGIS, and will need an upstream fix.
> 
> 
> Sorry -- to clarify, that should have been >= 2.1 . 2.0 did not include 
> the offending commit.
> 
> Nyall
> 
> 
> _______________________________________________
> 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 andreas at qgis.org  Mon May 18 23:43:30 2026
From: andreas at qgis.org (Andreas Neumann)
Date: Tue, 19 May 2026 08:43:30 +0200
Subject: [QGIS-Developer] Laax group accommodation - please reserve your
 spot in the next 2 weeks
Message-ID: <CAB2Z92BCJqBH_dKq-OoiLwqt4rK6VOuGjCtcVxFzeFxnsj=MsQ@mail.gmail.com>

Dear participants of the QGIS contributor meeting and conference in Laax,

As you may have heard, QGIS has organized group accommodation. See
information at
https://docs.google.com/spreadsheets/d/1HMNEXrUyJimRMq31JtcCduSk56alEGu1XqR3RO0-7dM/edit?usp=sharing

Since I get more and more requests from people who will not attend the
contributor meeting, I now blocked the remaining single rooms and a
three-bed room for participants of the contributor meeting.

For better planning I kindly remind people who want to book a room or bed
in a shared room as a contributor to reserve their room within the next two
weeks. After that I will make all rooms available for everyone.

Most likely we'll make the rooms / beds available for free for people who
attend the contributor meeting and charge only the people who do not
participate and contribute.

Best regards,
Andreas

--
Andreas Neumann
QGIS.ORG board member (treasurer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260519/2bfc9e76/attachment.htm>

From nirvn.asia at gmail.com  Thu May 21 02:35:38 2026
From: nirvn.asia at gmail.com (Mathieu Pellerin)
Date: Thu, 21 May 2026 16:35:38 +0700
Subject: [QGIS-Developer] QEP 409: Attribute Form QML Widget Editing
 Capabilities
In-Reply-To: <CAC_qv=pg9bnX42ujKULAtKPQacHMZX8vkUGjUzB8ajh-jTMUSQ@mail.gmail.com>
References: <CAC_qv=pg9bnX42ujKULAtKPQacHMZX8vkUGjUzB8ajh-jTMUSQ@mail.gmail.com>
Message-ID: <CAC_qv=o-jg+4PbhczOYQbfsXg57_dTiT71NChmCGoboqq-2TdQ@mail.gmail.com>

Good day,

We've had a healthy discussion on this QEP and I would like to call for a
vote on it now: cast your votes :)

Regards,

Mathieu

On Fri, Apr 10, 2026 at 5:01?PM Mathieu Pellerin <nirvn.asia at gmail.com>
wrote:

> Greetings all,
>
> This is to inform the developers mailing list of a QEP -
> https://github.com/qgis/QGIS-Enhancement-Proposals/pull/364 - which I had
> opened on February 1st, 2026. The QEP proposes to add editing capabilities
> for attributes form QML editor widgets.
>
> While it's been there for a while and @signedav added some comments, more
> discussion would be most welcome prior to calling for the vote.
>
> Best,
>
> Mathieu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260521/e59c5faf/attachment.htm>

From skampus at gmail.com  Thu May 21 02:53:03 2026
From: skampus at gmail.com (Stefano Campus)
Date: Thu, 21 May 2026 11:53:03 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
Message-ID: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>

Good morning everyone,

I?m writing to the dev list because I think this issue is of interest.

For the past few days, the SAGA Next plugin?which allows you to use SAGA
GIS modules within QGIS Processing?has been unavailable.

According to reports in the QGIS community?s Telegram group, maintaining
this plugin is becoming increasingly difficult due to developments in the
SAGA project, which can cause the plugin to stop working.

I recall that until a couple of years ago, SAGA was, like GRASS, a resource
installed directly within QGIS, but then, precisely because of the
difficulty in keeping up with SAGA?s developments, it was decided to treat
SAGA as a third-party resource accessible via plugins.

I believe it is right that this important resource should not be maintained
on a voluntary basis by a single developer/user, but that it should be
taken on by the community.

Do you think it would be a good idea to propose to the Steering Group that
its maintenance be taken on directly by the QGIS.org Foundation and that a
certain sum (1000?2000 euros?) be set aside in the annual budget for its
maintenance?

Thank you

stefano campus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260521/de11b453/attachment-0001.htm>

From sebastic at xs4all.nl  Thu May 21 03:40:36 2026
From: sebastic at xs4all.nl (Bas Couwenberg)
Date: Thu, 21 May 2026 12:40:36 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
References: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
Message-ID: <e4d5973f-3ab3-4993-8e73-8e3a8a6ec88f@xs4all.nl>

On 5/21/26 11:53 AM, Stefano Campus via QGIS-Developer wrote:
> Do you think it would be a good idea to propose to the Steering Group that
> its maintenance be taken on directly by the QGIS.org Foundation and that a
> certain sum (1000?2000 euros?) be set aside in the annual budget for its
> maintenance?

No, I think it makes more sense for the SAGA developers to commit to maintaining the QGIS plugin which will likely motivate them to stabilize their interface.

Kind Regards,

Bas

From skampus at gmail.com  Thu May 21 04:41:39 2026
From: skampus at gmail.com (Stefano Campus)
Date: Thu, 21 May 2026 13:41:39 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <mailman.16474.1779357198.622.qgis-developer@lists.osgeo.org>
References: <mailman.16474.1779357198.622.qgis-developer@lists.osgeo.org>
Message-ID: <CAHw6TZfhe+wLRbtWCTXD2uLf2zOXBS0bJFc5bvxwaPFXMf4uxw@mail.gmail.com>

If I?m not mistaken, over the years, the SAGA maintainers haven?t paid much
attention to integration with QGIS; proof of this is that they?ve changed
the structure of the modules, renamed them, and so on, without making any
announcement or contacting the QGIS maintainers in any way

Il giorno gio 21 mag 2026 alle ore 11:53 <
qgis-developer-request at lists.osgeo.org> ha scritto:

>
> *Bas Couwenberg* sebastic at xs4all.nl
> <qgis-developer%40lists.osgeo.org?Subject=Re%3A%20%5BQGIS-Developer%5D%20SAGA%20GIS%20plugin%20maintenance&In-Reply-To=%3Ce4d5973f-3ab3-4993-8e73-8e3a8a6ec88f%40xs4all.nl%3E>
> *Thu May 21 03:40:36 PDT 2026*
>
>
>    - Previous message (by thread): [QGIS-Developer] SAGA GIS plugin
>    maintenance
>    <https://lists.osgeo.org/pipermail/qgis-developer/2026-May/068253.html>
>    - *Messages sorted by:* [ date ]
>    <https://lists.osgeo.org/pipermail/qgis-developer/2026-May/date.html#68254>
>     [ thread ]
>    <https://lists.osgeo.org/pipermail/qgis-developer/2026-May/thread.html#68254>
>     [ subject ]
>    <https://lists.osgeo.org/pipermail/qgis-developer/2026-May/subject.html#68254>
>     [ author ]
>    <https://lists.osgeo.org/pipermail/qgis-developer/2026-May/author.html#68254>
>
> ------------------------------
>
> On 5/21/26 11:53 AM, Stefano Campus via QGIS-Developer wrote:
> >* Do you think it would be a good idea to propose to the Steering Group that
> *>* its maintenance be taken on directly by the QGIS.org Foundation and that a
> *>* certain sum (1000?2000 euros?) be set aside in the annual budget for its
> *>* maintenance?
> *
> No, I think it makes more sense for the SAGA developers to commit to maintaining the QGIS plugin which will likely motivate them to stabilize their interface.
>
> Kind Regards,
>
> Bas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260521/09b3e0a7/attachment.htm>

From gdt at lexort.com  Thu May 21 04:48:01 2026
From: gdt at lexort.com (Greg Troxel)
Date: Thu, 21 May 2026 07:48:01 -0400
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <CAHw6TZfhe+wLRbtWCTXD2uLf2zOXBS0bJFc5bvxwaPFXMf4uxw@mail.gmail.com>
 (Stefano Campus via's message of "Thu, 21 May 2026 13:41:39 +0200")
References: <mailman.16474.1779357198.622.qgis-developer@lists.osgeo.org>
 <CAHw6TZfhe+wLRbtWCTXD2uLf2zOXBS0bJFc5bvxwaPFXMf4uxw@mail.gmail.com>
Message-ID: <rmia4ttugpa.fsf@s1.lexort.com>

Stefano Campus via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> If I?m not mistaken, over the years, the SAGA maintainers haven?t paid much
> attention to integration with QGIS; proof of this is that they?ve changed
> the structure of the modules, renamed them, and so on, without making any
> announcement or contacting the QGIS maintainers in any way

Have you brought this up with them?  How do they view people using SAGA
code in a qgis context?  Supportive?  Indifferent?  Oppposed, except for
the usual "the license gives you the freedom to do stuff like that, but
we won't help."?

(Given that you're writing from gmail, the default assumption is that
you're writing as an indvidual member of the open source community and
not proxying concerns from some other entity.)

How much use of SAGA is there within the qgis world?  Is any of that at
companies?  Are they willing to pay say 10% of what ESRI licenses would
cost?  Have they contacted SAGA and asked about maintenance that would
benefit QGIS?  Would they be willing to pay into a QGIS.org maintenance
bucket for SAGA-related tasks?  This is not special about SAGA - just
trying to poke at who wants what and who's willing to pay.


From jef at norbit.de  Thu May 21 04:57:42 2026
From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer)
Date: Thu, 21 May 2026 13:57:42 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
References: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
Message-ID: <20260521115742.qhdvagbyx6yykibv@norbit.de>

Hi Stefano,

On Thu, 21. May 2026 at 11:53:03 +0200, Stefano Campus via QGIS-Developer wrote:
> According to reports in the QGIS community?s Telegram group, maintaining
> this plugin is becoming increasingly difficult due to developments in the
> SAGA project, which can cause the plugin to stop working.

That was also my guess, but is that the case?   Maybe there isn't any interest?

Nyall only needed to remove his repo to make it disappear completely.  There
apparently wasn't a single fork from contributors - not one.

I've built SAGA for years for OSGeo4W and have just updated it to the latest
version in response to a quick release they did, when we reported with the last
version of the plugin an issue.

More of a coincidence, I'm not a user either.   So I didn't follow SAGA or the
plugin much and with the repo gone it's unclear to me, whether it actually was
much work to maintain the plugin or just a lack of interest.

But I'm a bit suprised that the repo wasn't just archived, but removed.



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                  Matrix: @jef:osgeo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260521/019915c5/attachment.sig>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Pflichtangaben
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260521/019915c5/attachment.ksh>

From skampus at gmail.com  Thu May 21 05:15:58 2026
From: skampus at gmail.com (Stefano Campus)
Date: Thu, 21 May 2026 14:15:58 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <CAHw6TZfhe+wLRbtWCTXD2uLf2zOXBS0bJFc5bvxwaPFXMf4uxw@mail.gmail.com>
References: <mailman.16474.1779357198.622.qgis-developer@lists.osgeo.org>
 <CAHw6TZfhe+wLRbtWCTXD2uLf2zOXBS0bJFc5bvxwaPFXMf4uxw@mail.gmail.com>
Message-ID: <CAHw6TZdC0ceW14eAAKk3ZTTS2=pJW8-DKeL=mpGV25O1vv4JUw@mail.gmail.com>

First of all, thank you all for your feedback.

It is clear that the problem is not (solely) the SAGA plugin, but rather a
perspective on the sustainability of open-source projects, which, I
imagine, Nyall has rightly raised.

To avoid any misunderstanding and in response to Greg?s comments, in this
context I am simply a user who used to use SAGA very frequently some time
ago; as the features of QGIS/ Processing have improved and expanded, I
hardly use it anymore, except for rasterisation, which allows complete
control over the rasterisation values when, for example, I have overlapping
points, and SAGA allows you to choose whether to assign the minimum,
average, maximum, sum, etc., to the raster cell ? a function that GDAL does
not have.

However, I reiterate that I consider Nyall?s decision to be a ?provocation?
(in a positive sense, let?s be clear) to draw attention to sustainability.

Jurgen has stated the difficulty in keeping up with SAGA?s developments,
which are often unannounced, and attempts at structured collaboration ?
correct me if I?m wrong ? with SAGA?s maintainers have not yielded good
results.

So, returning to the specific case, I believe the solutions could be:

1) SAGA is no longer a third-party module provider, as it no longer
develops or maintains any plugins;

2) specific voluntary contributions are found, either short-term or
long-term

tertium non datur!


Regards

s.




Il giorno gio 21 mag 2026 alle ore 13:41 Stefano Campus <skampus at gmail.com>
ha scritto:

> If I?m not mistaken, over the years, the SAGA maintainers haven?t paid
> much attention to integration with QGIS; proof of this is that they?ve
> changed the structure of the modules, renamed them, and so on, without
> making any announcement or contacting the QGIS maintainers in any way
>
> Il giorno gio 21 mag 2026 alle ore 11:53 <
> qgis-developer-request at lists.osgeo.org> ha scritto:
>
>>
>> *Bas Couwenberg* sebastic at xs4all.nl
>> <qgis-developer%40lists.osgeo.org?Subject=Re%3A%20%5BQGIS-Developer%5D%20SAGA%20GIS%20plugin%20maintenance&In-Reply-To=%3Ce4d5973f-3ab3-4993-8e73-8e3a8a6ec88f%40xs4all.nl%3E>
>> *Thu May 21 03:40:36 PDT 2026*
>>
>>
>>    - Previous message (by thread): [QGIS-Developer] SAGA GIS plugin
>>    maintenance
>>    <https://lists.osgeo.org/pipermail/qgis-developer/2026-May/068253.html>
>>    - *Messages sorted by:* [ date ]
>>    <https://lists.osgeo.org/pipermail/qgis-developer/2026-May/date.html#68254>
>>     [ thread ]
>>    <https://lists.osgeo.org/pipermail/qgis-developer/2026-May/thread.html#68254>
>>     [ subject ]
>>    <https://lists.osgeo.org/pipermail/qgis-developer/2026-May/subject.html#68254>
>>     [ author ]
>>    <https://lists.osgeo.org/pipermail/qgis-developer/2026-May/author.html#68254>
>>
>> ------------------------------
>>
>> On 5/21/26 11:53 AM, Stefano Campus via QGIS-Developer wrote:
>> >* Do you think it would be a good idea to propose to the Steering Group that
>> *>* its maintenance be taken on directly by the QGIS.org Foundation and that a
>> *>* certain sum (1000?2000 euros?) be set aside in the annual budget for its
>> *>* maintenance?
>> *
>> No, I think it makes more sense for the SAGA developers to commit to maintaining the QGIS plugin which will likely motivate them to stabilize their interface.
>>
>> Kind Regards,
>>
>> Bas
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260521/7f1ca5c7/attachment-0001.htm>

From alexander.bruy at gmail.com  Thu May 21 05:30:48 2026
From: alexander.bruy at gmail.com (Alexander Bruy)
Date: Thu, 21 May 2026 13:30:48 +0100
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
References: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
Message-ID: <CALuHMPARpuRKO0J4V4KBfEJos+WVAnrTURswGFfieQ9K7fRpSg@mail.gmail.com>

Hi Stefano,

I would be a -1 to the proposed idea. We need to be careful not to
fuse the QGIS PSC and "the community". The PSC manages a project with
lots of needs and pain points (infrastructure, bugfixing,
documentation, packaging, just to name a few). I think that your
proposal that the PSC should allocate funds to maintain a specific,
third-party plugin sets a potentially problematic precedent. There are
thousands of QGIS plugins and many of them are incredibly useful but
not maintained anymore. What makes the SAGA plugin uniquely qualified
to receive QGIS funding over any other unmaintained plugin? If
QGIS.org starts funding the maintenance of external plugins from its
budget, where do we draw the line?

If the community truly feels this plugin is very valuable, the
solution should come from the ground up, not from the top down. The
users and organizations who rely heavily on SAGA should be the ones to
find funds and find developer(s) willing to step up, take ownership
and the maintenance burden.

I haven't followed the development of the SAGA NextGen plugin closely,
but from what I have seen, it was mainly only one person taking care
of it and only a few very occasional contributors. This suggests that
there is very low interest among users in actively supporting a tool
which may be crucial for at least some of them.

Also, as someone who was previously involved in the core SAGA plugin
maintenance and developed an alternative SAGA Processing provider for
my own needs, I can only confirm all previously raised points
regarding the overhead related to keeping up with SAGA's changes.
Command structures and names change frequently, things tend to break
here and there without a notice, and the only source of truth is the
source code. It is indeed a heavy burden and that's exactly why it was
removed from QGIS core in the first place.

Just to reiterate my main point: users who want to have a SAGA plugin
should organize a dedicated fundraising campaign or find development
volunteers themselves. That would be a fair and truly community-driven
solution, rather than asking QGIS.org to stretch its budget for a
third-party dependency.

??, 21 ????. 2026??. ? 10:53 Stefano Campus via QGIS-Developer
<qgis-developer at lists.osgeo.org> ????:
>
> Good morning everyone,
>
> I?m writing to the dev list because I think this issue is of interest.
>
> For the past few days, the SAGA Next plugin?which allows you to use SAGA GIS modules within QGIS Processing?has been unavailable.
>
> According to reports in the QGIS community?s Telegram group, maintaining this plugin is becoming increasingly difficult due to developments in the SAGA project, which can cause the plugin to stop working.
>
> I recall that until a couple of years ago, SAGA was, like GRASS, a resource installed directly within QGIS, but then, precisely because of the difficulty in keeping up with SAGA?s developments, it was decided to treat SAGA as a third-party resource accessible via plugins.
>
> I believe it is right that this important resource should not be maintained on a voluntary basis by a single developer/user, but that it should be taken on by the community.
>
> Do you think it would be a good idea to propose to the Steering Group that its maintenance be taken on directly by the QGIS.org Foundation and that a certain sum (1000?2000 euros?) be set aside in the annual budget for its maintenance?
>
> Thank you
>
> stefano campus
>
> _______________________________________________
> 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



-- 
Alexander Bruy

From andreaerdna at libero.it  Thu May 21 09:27:02 2026
From: andreaerdna at libero.it (Andrea Giudiceandrea)
Date: Thu, 21 May 2026 18:27:02 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
Message-ID: <4a671256-eb35-4803-b542-3496536dfa6f@libero.it>

Il 21/05/2026 13:57, J?rgen E. Fischer via QGIS-Developer ha scritto:

> Nyall only needed to remove his repo to make it disappear completely.  There
> apparently wasn't a single fork from contributors - not one.

Hi J?rgen and list,
actually there are various forks of the "Processing Saga NextGen 
Provider" repository still alive on GitHub [1].

AFAIK, mine [2] is up to date to Nyall's latest commit. I've also added 
the zipped file of the latest release of the plugin that was available 
on the plugins' server, version 1.1.0 [3].

Best regards.

Andrea Giudiceandrea

[1] 
https://github.com/rhurlin/qgis-processing-saga-nextgen/forks?include=active%2Cinactive%2Cnetwork&page=1&period=&sort_by=last_updated
[2] https://github.com/agiudiceandrea/qgis-processing-saga-nextgen
[3] 
https://github.com/agiudiceandrea/qgis-processing-saga-nextgen/releases/tag/1.1.0

From jef at norbit.de  Thu May 21 10:36:28 2026
From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer)
Date: Thu, 21 May 2026 19:36:28 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <4a671256-eb35-4803-b542-3496536dfa6f@libero.it>
References: <4a671256-eb35-4803-b542-3496536dfa6f@libero.it>
Message-ID: <20260521173628.2mh5tgvwwpamtyam@norbit.de>

Hi Andrea,

On Thu, 21. May 2026 at 18:27:02 +0200, Andrea Giudiceandrea via QGIS-Developer wrote:
> Il 21/05/2026 13:57, J?rgen E. Fischer via QGIS-Developer ha scritto:
> 
> > Nyall only needed to remove his repo to make it disappear completely.  There
> > apparently wasn't a single fork from contributors - not one.
> 
> actually there are various forks of the "Processing Saga NextGen Provider"
> repository still alive on GitHub [1].
> 
> AFAIK, mine [2] is up to date to Nyall's latest commit. I've also added the
> zipped file of the latest release of the plugin that was available on the
> plugins' server, version 1.1.0 [3].

um, odd.  apologies.   I looked for "qgis-processing-saga-nextgen" on github
and only got 2 results - rhurlin's (original?) repo with a 7 year old commit
being the latest and a docker image.

But I missed that rhurlin's repo has more current forks, which I would have
expected to see in the search too.


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                  Matrix: @jef:osgeo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260521/cf98756a/attachment.sig>

From girgink at gmail.com  Thu May 21 12:41:42 2026
From: girgink at gmail.com (Serkan Girgin)
Date: Thu, 21 May 2026 21:41:42 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <CALuHMPARpuRKO0J4V4KBfEJos+WVAnrTURswGFfieQ9K7fRpSg@mail.gmail.com>
References: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
 <CALuHMPARpuRKO0J4V4KBfEJos+WVAnrTURswGFfieQ9K7fRpSg@mail.gmail.com>
Message-ID: <CAFk4oFvydjTwBWOKcTLBu1GNmDUKwLeuAfoQ1Y3eyrt+WLTtVw@mail.gmail.com>

Hi all,

It might be possible that some of you are aware of this, but regarding
funding of open-source geospatial software there is a HORIZON Coordination
and Support Actions call with a budget of 6M euro, which was closed
recently:
https://www.horizon-europe.gouv.fr/services-and-business-incubator-geospatial-open-source-developments-41508

The call states: "Proposals should foresee a range of 45-60% of the
proposed budget for providing financial support to third parties (FSTP),
with the aim of establishing seed funding mechanisms to aid identified
critical geospatial open-source projects".

I think this might be a nice opportunity not only for SAGA, but for many
others (including QGIS) that may use available funding quite effectively.
Might be good to follow the developments.

Best,

Serkan


On Thu, 21 May 2026 at 14:31, Alexander Bruy via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hi Stefano,
>
> I would be a -1 to the proposed idea. We need to be careful not to
> fuse the QGIS PSC and "the community". The PSC manages a project with
> lots of needs and pain points (infrastructure, bugfixing,
> documentation, packaging, just to name a few). I think that your
> proposal that the PSC should allocate funds to maintain a specific,
> third-party plugin sets a potentially problematic precedent. There are
> thousands of QGIS plugins and many of them are incredibly useful but
> not maintained anymore. What makes the SAGA plugin uniquely qualified
> to receive QGIS funding over any other unmaintained plugin? If
> QGIS.org starts funding the maintenance of external plugins from its
> budget, where do we draw the line?
>
> If the community truly feels this plugin is very valuable, the
> solution should come from the ground up, not from the top down. The
> users and organizations who rely heavily on SAGA should be the ones to
> find funds and find developer(s) willing to step up, take ownership
> and the maintenance burden.
>
> I haven't followed the development of the SAGA NextGen plugin closely,
> but from what I have seen, it was mainly only one person taking care
> of it and only a few very occasional contributors. This suggests that
> there is very low interest among users in actively supporting a tool
> which may be crucial for at least some of them.
>
> Also, as someone who was previously involved in the core SAGA plugin
> maintenance and developed an alternative SAGA Processing provider for
> my own needs, I can only confirm all previously raised points
> regarding the overhead related to keeping up with SAGA's changes.
> Command structures and names change frequently, things tend to break
> here and there without a notice, and the only source of truth is the
> source code. It is indeed a heavy burden and that's exactly why it was
> removed from QGIS core in the first place.
>
> Just to reiterate my main point: users who want to have a SAGA plugin
> should organize a dedicated fundraising campaign or find development
> volunteers themselves. That would be a fair and truly community-driven
> solution, rather than asking QGIS.org to stretch its budget for a
> third-party dependency.
>
> ??, 21 ????. 2026??. ? 10:53 Stefano Campus via QGIS-Developer
> <qgis-developer at lists.osgeo.org> ????:
> >
> > Good morning everyone,
> >
> > I?m writing to the dev list because I think this issue is of interest.
> >
> > For the past few days, the SAGA Next plugin?which allows you to use SAGA
> GIS modules within QGIS Processing?has been unavailable.
> >
> > According to reports in the QGIS community?s Telegram group, maintaining
> this plugin is becoming increasingly difficult due to developments in the
> SAGA project, which can cause the plugin to stop working.
> >
> > I recall that until a couple of years ago, SAGA was, like GRASS, a
> resource installed directly within QGIS, but then, precisely because of the
> difficulty in keeping up with SAGA?s developments, it was decided to treat
> SAGA as a third-party resource accessible via plugins.
> >
> > I believe it is right that this important resource should not be
> maintained on a voluntary basis by a single developer/user, but that it
> should be taken on by the community.
> >
> > Do you think it would be a good idea to propose to the Steering Group
> that its maintenance be taken on directly by the QGIS.org Foundation and
> that a certain sum (1000?2000 euros?) be set aside in the annual budget for
> its maintenance?
> >
> > Thank you
> >
> > stefano campus
> >
> > _______________________________________________
> > 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
>
>
>
> --
> Alexander Bruy
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260521/7b1413b4/attachment-0001.htm>

From nyall.dawson at gmail.com  Thu May 21 16:55:13 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Fri, 22 May 2026 09:55:13 +1000
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
References: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
Message-ID: <CAB28AsgnUm444vSZ6-e6y6VmnbkCkx5oBst+ZYGyFvVTZhKtiA@mail.gmail.com>

On Thu, 21 May 2026 at 19:53, Stefano Campus via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> I?m writing to the dev list because I think this issue is of interest.
>
> For the past few days, the SAGA Next plugin?which allows you to use SAGA
GIS modules within QGIS Processing?has been unavailable.

Thanks for kicking off this discussion -- I've been waiting for someone to
raise it ??

To explain the situation:

I've been "maintaining" that plugin for years. That's an
over-exaggeration... it hasn't received any love from me beyond reviewing a
pull request once every couple of years. I initially forked it (SAGA
NextGen) from the core SAGA plugin back in 2019 to help solve issues with
SAGA availability of LTR releases and broken stable API. Then in 2019
https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230 followed,
when the built-in SAGA plugin was removed and it went from being an
out-of-the-box, "qgis.org maintained" plugin to relying on the third party
SAGA NextGen "community maintained" plugin. That's 100% because it was
concluded by all the developers responsible for that code that it wasn't up
to the quality standards of the rest of QGIS.

It was always a fragile mess of a plugin. Part of that was because of the
difficulties associated with SAGA versioning, part of that was because it
was initially forked from old python code that no-one had ever modernised.
To say it was held together with chewing gum would be a lie... it was held
together with some soggy wet toilet paper at best! ? This really bugged
me. I'd see constant user frustration because it never worked well, and IMO
this user frustration was harming the reputation of QGIS itself. It didn't
help that I'd keep reading blogs/guides/tutorials where people were
recommending using it for operations where QGIS native tools are SOOOO much
better (eg vector operations like buffering).

It was never my desire to become the maintainer of the plugin and put in
the work required to bring it up to the quality standard I hold to, rather,
I offered it on an initially voluntary basis to fix immediate issues I saw
users were experiencing and with the hope that making it a third party
plugin would help grow a healthy community that would take it over.

That never happened... Instead it was just another burden that I carried
for everyone, with the associated lack of thanks and lack of any
recognition beyond angry emails when it didn't work. ?. Ah well, that's
just life as a QGIS developer, we all deal with that, and I'm thick-skinned
enough to handle it!

At least, I thought so. Then the AI apocalypse hit in 2026.

As a response to my frustration with the lack of support the user community
is giving to open-source developers during this INCREDIBLY challenging
time, I decided to close off a bunch of my public repositories. Because,
hey, I don't want to directly train the technologies that will likely
destroy the whole economics behind open-source software development. So I
closed off repositories for things I'd voluntarily made public, including
dropping any QGIS plugin that I wasn't directly using myself anymore, and
that wasn't funded or in use by my customers (or where a better native tool
now exists). And that included the SAGA NextGen plugin. I have no use for
it, and none of my customers use it, and it's a PITA to "maintain".

I knew that by doing so I'd be stirring up trouble, and honestly, that was
partly my intention! I wanted to force a discussion about this, and raise
widespread attention to the issues that would otherwise go unnoticed. It's
the SAGA plugin today, but tomorrow it could easily be QGIS itself, or
GDAL, or PostGIS, or PDAL, or ... ?

My personal preference would be that we continue to port useful tools from
SAGA to native QGIS versions of these tools. I've done this in the past
(see https://github.com/qgis/QGIS/pull/53794,
https://github.com/qgis/QGIS/pull/61722) for tools that I need myself, or
that my customers rely on, and the QGIS native tools are so much better
(***FOR QGIS USERS***) then calling out to the SAGA versions. They have
full format support for all the data sources QGIS supports, they work with
massive rasters without memory issues, and they are much faster as they
don't require data conversion to intermediate formats. And on top of that,
they "just work" everywhere QGIS works -- there's no fussing around with
SAGA version compatibility, and no security risks with python code shelling
out to run random batch files.

(Please understand that I'm not insulting the SAGA developers or their
versions of these tools here... in my experience the SAGA developer's logic
is great, the code is well written and the algorithms themselves are well
designed. It's a testament to the SAGA developers how easy it is to port
the tools to QGIS, they are very readable and well documented. My point is
that we offer a better experience to **QGIS** users by porting the tools to
native equivalents using QGIS API directly).

If anyone has particular SAGA tools they rely on for their work, then
please reach out and I'll let you know how much it would cost to sponsor a
port of that tool.

Finally, please note that I didn't delete the plugin repository, I just
made it private instead of public. I'm happy to temporarily make it public
again if someone wants to fork it, but after they do that I'll then
permanently erase my repo. If someone wants to do this then let me know and
I'll re-open temporarily.

Nyall


>
> According to reports in the QGIS community?s Telegram group, maintaining
this plugin is becoming increasingly difficult due to developments in the
SAGA project, which can cause the plugin to stop working.
>
> I recall that until a couple of years ago, SAGA was, like GRASS, a
resource installed directly within QGIS, but then, precisely because of the
difficulty in keeping up with SAGA?s developments, it was decided to treat
SAGA as a third-party resource accessible via plugins.
>
> I believe it is right that this important resource should not be
maintained on a voluntary basis by a single developer/user, but that it
should be taken on by the community.
>
> Do you think it would be a good idea to propose to the Steering Group
that its maintenance be taken on directly by the QGIS.org Foundation and
that a certain sum (1000?2000 euros?) be set aside in the annual budget for
its maintenance?
>
> Thank you
>
> stefano campus
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260522/6a68556b/attachment.htm>

From daniel.lepold at infrared.city  Fri May 22 00:12:30 2026
From: daniel.lepold at infrared.city (Daniel Lepold)
Date: Fri, 22 May 2026 07:12:30 +0000
Subject: [QGIS-Developer] QGIS plugin - Infrared City GIS
Message-ID: <PA3P191MB2953141844B89321A70954C8E90F2@PA3P191MB2953.EURP191.PROD.OUTLOOK.COM>

Hi,
My name is Daniel, and we are developing a QGIS plugin called Infrared City GIS. It has already been uploaded to the platform and the review process has started.
Could someone please provide an update on the current review status or let us know if there are any updates regarding the review process?
Thank you in advance.
Best regards,

Daniel Lepold

AEC Software Developer

Infrared City GmbH

www.infrared.city



[cid:5abc81ca-e74e-4a68-bddf-886b9a5adfef]



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260522/3179253b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-m0zi3f2r.png
Type: image/png
Size: 5262 bytes
Desc: Outlook-m0zi3f2r.png
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260522/3179253b/attachment-0001.png>

From lova at kartoza.com  Fri May 22 00:41:04 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Fri, 22 May 2026 10:41:04 +0300
Subject: [QGIS-Developer] QGIS plugin - Infrared City GIS
In-Reply-To: <PA3P191MB2953141844B89321A70954C8E90F2@PA3P191MB2953.EURP191.PROD.OUTLOOK.COM>
References: <PA3P191MB2953141844B89321A70954C8E90F2@PA3P191MB2953.EURP191.PROD.OUTLOOK.COM>
Message-ID: <CAMLC-sDg_6LcM_v6A1TXQcqy5JAa9n3JuUZXn-N_Phpi-danFw@mail.gmail.com>

Hi Daniel,

I suggest visiting the Plugin's approval process docs at
https://plugins.qgis.org/docs/approval. As mentionned there, please get in
touch with Admire if you have any questions.
I hope this helps.

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.*


On Fri, 22 May 2026 at 10:12, Daniel Lepold via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hi,
> My name is Daniel, and we are developing a QGIS plugin called Infrared
> City GIS. It has already been uploaded to the platform and the review
> process has started.
> Could someone please provide an update on the current review status or let
> us know if there are any updates regarding the review process?
> Thank you in advance.
> Best regards,
>
> *Daniel Lepold *
>
> AEC Software Developer
>
> Infrared City GmbH
>
> www.infrared.city
>
>
>
>
>
>
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260522/2889788d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-m0zi3f2r.png
Type: image/png
Size: 5262 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260522/2889788d/attachment.png>

From strk at kbt.io  Fri May 22 00:49:14 2026
From: strk at kbt.io (Sandro Santilli)
Date: Fri, 22 May 2026 09:49:14 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <CAB28AsgnUm444vSZ6-e6y6VmnbkCkx5oBst+ZYGyFvVTZhKtiA@mail.gmail.com>
References: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
 <CAB28AsgnUm444vSZ6-e6y6VmnbkCkx5oBst+ZYGyFvVTZhKtiA@mail.gmail.com>
Message-ID: <ahAKeu7J_ZgFv-UR@c23>

On Fri, May 22, 2026 at 09:55:13AM +1000, Nyall Dawson via QGIS-Developer wrote:

> I decided to close off a bunch of my public repositories. Because,
> hey, I don't want to directly train the technologies that will likely
> destroy the whole economics behind open-source software development.
> So I closed off repositories for things I'd voluntarily made public

Had you consider publishing them on code forges that are not owned by
big corporations with the specific goal of exploiting open-source
software to train their proprietary AIs ?

We even have one such code repository available in OSGeo infrastructure !

https://gitea.osgeo.org

--strk;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260522/e2b0511f/attachment.sig>

From florian.schimmel at sap.com  Fri May 22 06:21:45 2026
From: florian.schimmel at sap.com (Schimmel, Florian)
Date: Fri, 22 May 2026 13:21:45 +0000
Subject: [QGIS-Developer] SAP HANA on MacOS
In-Reply-To: <PAVPR02MB94970DBBB1BCBDFD430E910A9068A@PAVPR02MB9497.eurprd02.prod.outlook.com>
References: <PAVPR02MB949786D8A35441FA2A1EBB85909EA@PAVPR02MB9497.eurprd02.prod.outlook.com>
 <CAC7zN96JrUKLpWgkH=_2o-5OghApuXyX+COn9oh939NhLnbTdA@mail.gmail.com>
 <PAVPR02MB949757440D4C89447EB239C5906BA@PAVPR02MB9497.eurprd02.prod.outlook.com>
 <c826b9d0-96a9-4e10-8d2b-0e89f5a678ec@spatialys.com>
 <PAVPR02MB94970DBBB1BCBDFD430E910A9068A@PAVPR02MB9497.eurprd02.prod.outlook.com>
Message-ID: <PAVPR02MB9497C19AFC727BCDFA47A5D2900F2@PAVPR02MB9497.eurprd02.prod.outlook.com>

Hey,

It was a bit of a hassle and took a while to add the odbccpp package to vcpkg<https://github.com/microsoft/vcpkg/pull/50152>, but it is now available. I created a change to include it in QGIS by vcpkg, but bumping up the vcpkg commit hash didn?t work because goal can?t build with the newest version of poppler. For me, it seems like a known problem and the best solution would bet to wait for the updates of the packages in vcpkg. I will add the odbccpp wrapper by vcpkg when this is solved.

In the meantime, I added already a change to enable HANA<https://github.com/qgis/QGIS/pull/66205>, I hope this is fine. Let me know, if there are any issues.

Best regards,
Florian

From: Schimmel, Florian <florian.schimmel at sap.com>
Date: Friday, 20. February 2026 at 15:47
To: Even Rouault <even.rouault at spatialys.com>; Matthias Kuhn <matthias at opengis.ch>
Cc: qgis-developer at lists.osgeo.org <qgis-developer at lists.osgeo.org>
Subject: Re: [QGIS-Developer] SAP HANA on MacOS

Hey Even,

Thanks for the hint, that makes sense. I will add it to the vcpkg repo and note this thread again after it is merged and the QGIS change is pushed.

Best regards
Florian

From: Even Rouault <even.rouault at spatialys.com>
Date: Friday, 20. February 2026 at 01:37
To: Schimmel, Florian <florian.schimmel at sap.com>, Matthias Kuhn <matthias at opengis.ch>
Cc: qgis-developer at lists.osgeo.org <qgis-developer at lists.osgeo.org>
Subject: Re: [QGIS-Developer] SAP HANA on MacOS

You don't often get email from even.rouault at spatialys.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>


Le 19/02/2026 ? 18:04, Schimmel, Florian via QGIS-Developer a ?crit :
Hey Matthias,

thank you for the reply, I like the idea and tried to implement it. I had to work into vcpkg and solve a few issues on the way, that took a while, but I have a working port now. While checking if it is possible to integrate the port in the QGIS build I noticed that there are custom ports in the repository. Since odbccpp is not broadly used, there is probably no application for a vcpkg port outside of QGIS, so would you mind if we add the port directly to the QGIS repository?

The GDAL HANA driver depends on odbccpp too, so for GDAL vcpkg users, having a standalone port could make sense

--
http://www.spatialys.com<http://www.spatialys.com/>
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260522/d7e2d483/attachment-0001.htm>

From rhurlin at gwdg.de  Sat May 23 02:03:32 2026
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Sat, 23 May 2026 11:03:32 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <20260521173628.2mh5tgvwwpamtyam@norbit.de>
References: <4a671256-eb35-4803-b542-3496536dfa6f@libero.it>
 <20260521173628.2mh5tgvwwpamtyam@norbit.de>
Message-ID: <c9cbbaaf-b810-43ab-ba3c-5630fb5e0dba@gwdg.de>

Hi J?rgen,

Am 21.05.26 um 19:36 schrieb J?rgen E. Fischer via QGIS-Developer:
> Hi Andrea,
> 
> On Thu, 21. May 2026 at 18:27:02 +0200, Andrea Giudiceandrea via QGIS-Developer wrote:
>> Il 21/05/2026 13:57, J?rgen E. Fischer via QGIS-Developer ha scritto:
>>
>>> Nyall only needed to remove his repo to make it disappear completely.  There
>>> apparently wasn't a single fork from contributors - not one.
>>
>> actually there are various forks of the "Processing Saga NextGen Provider"
>> repository still alive on GitHub [1].
>>
>> AFAIK, mine [2] is up to date to Nyall's latest commit. I've also added the
>> zipped file of the latest release of the plugin that was available on the
>> plugins' server, version 1.1.0 [3].
> 
> um, odd.  apologies.   I looked for "qgis-processing-saga-nextgen" on github
> and only got 2 results - rhurlin's (original?) repo with a 7 year old commit
> being the latest and a docker image.

Just for clarification: My version isn't the ?original,? but a fork from 
Victor Olaya's repo (volaya@). I have absolutely no idea why GitHub 
doesn't show this (?Fork from volaya/qgis-processing-saga-nextgen?). My 
patch in this fork was necessary in 2019 so that the plugin could use 
newer SAGA versions. After that, I never needed it again and lost track 
of it. Unfortunately, it also doesn?t seem to be updatable against 
original repo (pull ...).

Rainer

> But I missed that rhurlin's repo has more current forks, which I would have
> expected to see in the search too.
> 
> 
> J?rgen

From c at margo.co  Sun May 24 15:27:03 2026
From: c at margo.co (Pedro Camargo)
Date: Mon, 25 May 2026 08:27:03 +1000
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
Message-ID: <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>

Hello fellow QGISrs,





I maintain a couple of plugins that require a substantial number of extra Python packages (many of which have compiled/binary components). Hence, those plugins install all such requirements in a folder directly inside the plugin itself, keeping it quite clean when the user wants to remove said plugins.





I have been doing it this way for many years now, but this weekend I received security alerts that both plugins were taken down due to code that downloads extra dependencies (offending code at https://github.com/AequilibraE/qaequilibrae/blob/develop/qaequilibrae/download_extra_packages_class.py ).



Does anyone have any recommendations on how to proceed?? What is currently the recommended way for plugins to install further dependencies?



Cheers,

Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260525/6fb31aa0/attachment.htm>

From gdt at lexort.com  Sun May 24 16:36:12 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sun, 24 May 2026 19:36:12 -0400
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <19e5c19506b.73d9190c154183.6844791622465253461@margo.co> (Pedro
 Camargo via's message of "Mon, 25 May 2026 08:27:03 +1000")
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
 <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
Message-ID: <rmiy0h8l6s3.fsf@s1.lexort.com>

Pedro Camargo via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> I maintain a couple of plugins that require a substantial number of
> extra Python packages (many of which have compiled/binary
> components). Hence, those plugins install all such requirements in a
> folder directly inside the plugin itself, keeping it quite clean when
> the user wants to remove said plugins.
>
> I have been doing it this way for many years now, but this weekend I
> received security alerts that both plugins were taken down due to code
> that downloads extra dependencies (offending code at
> https://github.com/AequilibraE/qaequilibrae/blob/develop/qaequilibrae/download_extra_packages_class.py
> ).
>
> Does anyone have any recommendations on how to proceed?? What is
> currently the recommended way for plugins to install further
> dependencies?

I'm not really sure about plugins, but as a general comment about
packaging, it's a bug for the build of any program to download anything.
The preferred approach is to have packages for things that are needed
and express a dependency within the packaging system.  For example, qgis
depends on qt5 or qt6.

Plugins have a main conceptual path where they are just python code, and
only depend on qgis and things that are required by any qgis
installation.  That's fine when it works.

I don't see how to address this without turning the qgis plugin system
into yet another full-blown packaging system.

The only safe and sound approach I see is to ask the user to install --
with OS packages -- the external python/C modules that your plugin
needs.  But obviously that's not a good experience.

You can mitigate some of the risk by downloading only specific versions
identified by version number and hash, and checking the hash before
unpacking.

I wonder how many operating systems and CPUs your plugins work on.
Besides GNU/Linux, macOS, and Windows, qgis runs on various BSDs and
surely a few other systems, and likely a pretty large variety of cpu
types.   This is an area where download/build can be problematic if what
is downloaded is not adequately portable.

I realize this is generalities and handwavy and it will be interesting
to see what others say.

From even.rouault at spatialys.com  Sun May 24 17:32:36 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 25 May 2026 02:32:36 +0200
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <rmiy0h8l6s3.fsf@s1.lexort.com>
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
 <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
 <rmiy0h8l6s3.fsf@s1.lexort.com>
Message-ID: <6c289c3f-a216-436e-b706-b9bc4c6dd5d5@spatialys.com>


Le 25/05/2026 ? 01:36, Greg Troxel via QGIS-Developer a ?crit?:
> Pedro Camargo via QGIS-Developer <qgis-developer at lists.osgeo.org>
> writes:
>
>> I maintain a couple of plugins that require a substantial number of
>> extra Python packages (many of which have compiled/binary
>> components). Hence, those plugins install all such requirements in a
>> folder directly inside the plugin itself, keeping it quite clean when
>> the user wants to remove said plugins.
>>
>> I have been doing it this way for many years now, but this weekend I
>> received security alerts that both plugins were taken down due to code
>> that downloads extra dependencies (offending code at
>> https://github.com/AequilibraE/qaequilibrae/blob/develop/qaequilibrae/download_extra_packages_class.py
>> ).
>>
>> Does anyone have any recommendations on how to proceed?? What is
>> currently the recommended way for plugins to install further
>> dependencies?
> I'm not really sure about plugins,

Will not immediately help Pedro, but there have been past discussions 
related to plugin dependency management:

- https://github.com/qgis/QGIS-Enhancement-Proposals/issues/202

- https://github.com/qgis/QGIS-Enhancement-Proposals/issues/179

-- 
Very grumpy about LLMs: FOSS is about increasing public capital,
not becoming enslaved to private equity of giga corporations
--
http://www.spatialys.com
My software is free, but my time generally not.


From nyall.dawson at gmail.com  Sun May 24 18:12:20 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Mon, 25 May 2026 11:12:20 +1000
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
 <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
Message-ID: <CAB28Asj_24L9gJV35fVT+hTxFFmRx5AVq_wfFOD-B_4YvoLC6A@mail.gmail.com>

On Mon, 25 May 2026 at 08:27, Pedro Camargo via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:
>
> Hello fellow QGISrs,
>
>
>
> I maintain a couple of plugins that require a substantial number of extra
Python packages (many of which have compiled/binary components). Hence,
those plugins install all such requirements in a folder directly inside the
plugin itself, keeping it quite clean when the user wants to remove said
plugins.
>
>
> I have been doing it this way for many years now, but this weekend I
received security alerts that both plugins were taken down due to code that
downloads extra dependencies (offending code at
qaequilibrae/qaequilibrae/download_extra_packages_class.py at develop ?
AequilibraE/qaequilibrae).
>
> Does anyone have any recommendations on how to proceed?  What is
currently the recommended way for plugins to install further dependencies?

My personal 2c: a plugin should NEVER automatically install dependencies
like this. Rather, you should detect missing dependencies, warn the user,
and point them to a documentation page directing them how to install the
missing libraries on different operating systems.

I think it's EXTREMELY dangerous for a plugin to assume that it can mess
with the user's operating system in this way, as it risks completely
breaking their QGIS install or even their wider python environment. I would
like to see us explicitly blocking all plugins from the repository that do
this in future. ?

Nyall

>
> Cheers,
> Pedro
>
>
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260525/15933286/attachment.htm>

From c at margo.co  Sun May 24 20:35:35 2026
From: c at margo.co (Pedro Camargo)
Date: Mon, 25 May 2026 13:35:35 +1000
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <CAB28Asj_24L9gJV35fVT+hTxFFmRx5AVq_wfFOD-B_4YvoLC6A@mail.gmail.com>
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
 <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
 <CAB28Asj_24L9gJV35fVT+hTxFFmRx5AVq_wfFOD-B_4YvoLC6A@mail.gmail.com>
Message-ID: <19e5d33c97d.5bf7fc8a160332.3484047441793025941@margo.co>

Hey Nyall,



I hear you, but let me highlight two points of my original post.

? ? ? ?The plugin asks the user whether they want?to install the dependencies. 

? ? ? ?The dependencies are installed in the plugin folder and can therefore be removed without causing any lasting damage to the user's QGIS installation.


Installing additional dependencies in QGIS remains a painful task for less technical users, adding another (somewhat unnecessary) hurdle to?adoption.??



On that note, a fair question could be:? Is there a recommended low-effort (for users) path to install extra dependencies for plugins? 



If not, is that something being considered for the near future?





Cheers,

Pedro








From: Nyall Dawson <nyall.dawson at gmail.com>
To: "Pedro Camargo"<c at margo.co>
Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
Date: Mon, 25 May 2026 11:12:20 +1000
Subject: Re: [QGIS-Developer] Security issues with plugins







On Mon, 25 May 2026 at 08:27, Pedro Camargo via QGIS-Developer < mailto:qgis-developer at lists.osgeo.org > wrote:

>

> Hello fellow QGISrs,

>

>

>

> I maintain a couple of plugins that require a substantial number of extra Python packages (many of which have compiled/binary components). Hence, those plugins install all such requirements in a folder directly inside the plugin itself, keeping it quite clean when the user wants to remove said plugins.

>

>

> I have been doing it this way for many years now, but this weekend I received security alerts that both plugins were taken down due to code that downloads extra dependencies (offending code at qaequilibrae/qaequilibrae/download_extra_packages_class.py at develop ? AequilibraE/qaequilibrae).

>

> Does anyone have any recommendations on how to proceed?? What is currently the recommended way for plugins to install further dependencies?



My personal 2c: a plugin should NEVER automatically install dependencies like this. Rather, you should detect missing dependencies, warn the user, and point them to a documentation page directing them how to install the missing libraries on different operating systems.



I think it's EXTREMELY dangerous for a plugin to assume that it can mess with the user's operating system in this way, as it risks completely breaking their QGIS install or even their wider python environment. I would like to see us explicitly blocking all plugins from the repository that do this in future.??



Nyall


>
> Cheers,
> Pedro
>
>
>
> _______________________________________________
> QGIS-Developer mailing list
> mailto: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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260525/52b9f059/attachment-0001.htm>

From joona.p.laine at gmail.com  Sun May 24 22:47:55 2026
From: joona.p.laine at gmail.com (Joona Laine)
Date: Mon, 25 May 2026 08:47:55 +0300
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <19e5d33c97d.5bf7fc8a160332.3484047441793025941@margo.co>
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
 <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
 <CAB28Asj_24L9gJV35fVT+hTxFFmRx5AVq_wfFOD-B_4YvoLC6A@mail.gmail.com>
 <19e5d33c97d.5bf7fc8a160332.3484047441793025941@margo.co>
Message-ID: <CAKmgki60jiKx29_K07F01Ppsut4s=Oeed6snJO7AVkwEYCVcpA@mail.gmail.com>

Hello Pedro,

qgis-plugin-dev-tools (https://github.com/nlsfi/qgis-plugin-dev-tools#setup)
solves the dependency issue by including the dependencies with the plugin
package.

It can easily handle most of (non-binary) requirements by automatically
rewriting the imports of theses vendored dependencies in the build process.
This way it is possible to have multiple plugins using different version of
the same requirement without any conflicts.
It is also possible to include binary dependencies but there is no
operation system specific logic built yet at the moment.

There is also a tool called qpip (https://github.com/opengisch/qpip) for
dependency management, which might be worth checking out.

Cheers,
Joona



ma 25.5.2026 klo 6.35 Pedro Camargo via QGIS-Developer (
qgis-developer at lists.osgeo.org) kirjoitti:

> Hey Nyall,
>
> I hear you, but let me highlight two points of my original post.
>
>    -        The plugin asks the user whether they want to install the
>    dependencies.
>    -        The dependencies are installed in the plugin folder and can
>    therefore be removed without causing any lasting damage to the user's QGIS
>    installation.
>
> Installing additional dependencies in QGIS remains a painful task for less
> technical users, adding another (somewhat unnecessary) hurdle to adoption.
>
> On that note, a fair question could be:  Is there a recommended low-effort
> (for users) path to install extra dependencies for plugins?
>
> If not, is that something being considered for the near future?
>
>
> Cheers,
> Pedro
>
>
>
>
> From: Nyall Dawson <nyall.dawson at gmail.com>
> To: "Pedro Camargo"<c at margo.co>
> Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
> Date: Mon, 25 May 2026 11:12:20 +1000
> Subject: Re: [QGIS-Developer] Security issues with plugins
>
>
>
> On Mon, 25 May 2026 at 08:27, Pedro Camargo via QGIS-Developer <
> qgis-developer at lists.osgeo.org> wrote:
> >
> > Hello fellow QGISrs,
> >
> >
> >
> > I maintain a couple of plugins that require a substantial number of
> extra Python packages (many of which have compiled/binary components).
> Hence, those plugins install all such requirements in a folder directly
> inside the plugin itself, keeping it quite clean when the user wants to
> remove said plugins.
> >
> >
> > I have been doing it this way for many years now, but this weekend I
> received security alerts that both plugins were taken down due to code that
> downloads extra dependencies (offending code at
> qaequilibrae/qaequilibrae/download_extra_packages_class.py at develop ?
> AequilibraE/qaequilibrae).
> >
> > Does anyone have any recommendations on how to proceed?  What is
> currently the recommended way for plugins to install further dependencies?
>
> My personal 2c: a plugin should NEVER automatically install dependencies
> like this. Rather, you should detect missing dependencies, warn the user,
> and point them to a documentation page directing them how to install the
> missing libraries on different operating systems.
>
> I think it's EXTREMELY dangerous for a plugin to assume that it can mess
> with the user's operating system in this way, as it risks completely
> breaking their QGIS install or even their wider python environment. I would
> like to see us explicitly blocking all plugins from the repository that do
> this in future. ?
>
> Nyall
>
> >
> > Cheers,
> > Pedro
> >
> >
> >
> > _______________________________________________
> > 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260525/0c0afddb/attachment.htm>

From dmarteau at 3liz.com  Mon May 25 00:42:55 2026
From: dmarteau at 3liz.com (David Marteau)
Date: Mon, 25 May 2026 09:42:55 +0200
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <CAKmgki60jiKx29_K07F01Ppsut4s=Oeed6snJO7AVkwEYCVcpA@mail.gmail.com>
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
 <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
 <CAB28Asj_24L9gJV35fVT+hTxFFmRx5AVq_wfFOD-B_4YvoLC6A@mail.gmail.com>
 <19e5d33c97d.5bf7fc8a160332.3484047441793025941@margo.co>
 <CAKmgki60jiKx29_K07F01Ppsut4s=Oeed6snJO7AVkwEYCVcpA@mail.gmail.com>
Message-ID: <96e850a3-85e1-4769-b117-62b07312244a@3liz.com>

Imho,? ?(https://github.com/opengisch/qpip) is an elegant way for 
handling plugins dependencies.? You can manage isolation by using QGIS 
profiles.

David

Le 25/05/2026 ? 07:47, Joona Laine via QGIS-Developer a ?crit?:
> Hello Pedro,
>
> qgis-plugin-dev-tools 
> (https://github.com/nlsfi/qgis-plugin-dev-tools#setup) solves the 
> dependency issue by including the dependencies with the plugin package.
>
> It can easily handle most of (non-binary) requirements by 
> automatically rewriting the imports of theses vendored dependencies in 
> the build process.
> This way it is possible to have multiple plugins using different 
> version of the same requirement without any conflicts.
> It is also possible to include binary dependencies but there is no 
> operation system specific logic built yet at the moment.
>
> There is also a tool called qpip (https://github.com/opengisch/qpip) 
> for dependency management, which might be worth checking out.
>
> Cheers,
> Joona
>
>
>
> ma 25.5.2026 klo 6.35 Pedro Camargo via QGIS-Developer 
> (qgis-developer at lists.osgeo.org) kirjoitti:
>
>     Hey Nyall,
>
>     I hear you, but let me highlight two points of my original post.
>
>       * ? ? ? ?The plugin asks the user whether they want?to install
>         the dependencies.
>       * ? ? ? ?The dependencies are installed in the plugin folder and
>         can therefore be removed without causing any lasting damage to
>         the user's QGIS installation.
>
>     Installing additional dependencies in QGIS remains a painful task
>     for less technical users, adding another (somewhat unnecessary)
>     hurdle to?adoption.
>
>     On that note, a fair question could be:? Is there a recommended
>     low-effort (for users) path to install extra dependencies for
>     plugins?
>
>     If not, is that something being considered for the near future?
>
>
>     Cheers,
>     Pedro
>
>
>
>
>     From: Nyall Dawson <nyall.dawson at gmail.com>
>     To: "Pedro Camargo"<c at margo.co>
>     Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
>     Date: Mon, 25 May 2026 11:12:20 +1000
>     Subject: Re: [QGIS-Developer] Security issues with plugins
>
>
>
>         On Mon, 25 May 2026 at 08:27, Pedro Camargo via QGIS-Developer
>         <qgis-developer at lists.osgeo.org> wrote:
>         >
>         > Hello fellow QGISrs,
>         >
>         >
>         >
>         > I maintain a couple of plugins that require a substantial
>         number of extra Python packages (many of which have
>         compiled/binary components). Hence, those plugins install all
>         such requirements in a folder directly inside the plugin
>         itself, keeping it quite clean when the user wants to remove
>         said plugins.
>         >
>         >
>         > I have been doing it this way for many years now, but this
>         weekend I received security alerts that both plugins were
>         taken down due to code that downloads extra dependencies
>         (offending code at
>         qaequilibrae/qaequilibrae/download_extra_packages_class.py at
>         develop ? AequilibraE/qaequilibrae).
>         >
>         > Does anyone have any recommendations on how to proceed??
>         What is currently the recommended way for plugins to install
>         further dependencies?
>
>         My personal 2c: a plugin should NEVER automatically install
>         dependencies like this. Rather, you should detect missing
>         dependencies, warn the user, and point them to a documentation
>         page directing them how to install the missing libraries on
>         different operating systems.
>
>         I think it's EXTREMELY dangerous for a plugin to assume that
>         it can mess with the user's operating system in this way, as
>         it risks completely breaking their QGIS install or even their
>         wider python environment. I would like to see us explicitly
>         blocking all plugins from the repository that do this in
>         future.??
>
>         Nyall
>
>         >
>         > Cheers,
>         > Pedro
>         >
>         >
>         >
>         > _______________________________________________
>         > 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
>
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260525/a509d254/attachment-0001.htm>

From selma at kartoza.com  Mon May 25 03:17:01 2026
From: selma at kartoza.com (Selma Vidimlic)
Date: Mon, 25 May 2026 12:17:01 +0200
Subject: [QGIS-Developer] Request from QGIS docs writers
Message-ID: <CALarpe7cmQOaDJAWU9W0bNpy0ocRC=aqYKBWk0jWbq3XexSKPA@mail.gmail.com>

Hi devs,

Hope you're all doing well! We're reaching out from the documentation team
with a few requests.

As we work on documenting various features, we've run into challenges
finding good test data, particularly for 3D, point clouds, and specific
database formats. If any of you have sample data you could share, or know
of reliable sources where we could find suitable datasets, that would be a
huge help. And if you're aware, when developing things, that a format you
use is specific or hard to find online, please consider sending us your own
test data directly, that would be especially valuable.

We're also putting together content for the QGIS Open Day (QOD) series, and
3D features are high on our list. If you have suggestions for interesting
data sources that would showcase these features well, please share them
with us.

A couple of other things we'd like to flag:

**"Needs documentation" label**: It would mean a lot if you could keep an
eye on this label in the dev repository and action it when relevant.
Staying on top of it helps us keep documentation timely and accurate.
Sometimes we receive issue tickets in our repo and when working on them, we
might discover related PRs in the dev repo, or we might find new UI
elements without a corresponding issue ticket in our repo, then we need to
dig through the development repository. This process can take some time or
even confuse us as writers.

**Feature descriptions & use cases**: Whenever you have a spare moment,
even a brief description of a feature or a real-world use case goes a long
way in helping us document things properly.

We know you're busy, and we truly appreciate any time and input you can
spare.

Thanks so much,
Selma Vidimlic Husic
*QGIS Documentation writer*

*E:* selma 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260525/85e3d903/attachment.htm>

From rhurlin at gwdg.de  Mon May 25 09:25:33 2026
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Mon, 25 May 2026 18:25:33 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <CAB28AsgnUm444vSZ6-e6y6VmnbkCkx5oBst+ZYGyFvVTZhKtiA@mail.gmail.com>
References: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
 <CAB28AsgnUm444vSZ6-e6y6VmnbkCkx5oBst+ZYGyFvVTZhKtiA@mail.gmail.com>
Message-ID: <4544a675-453f-428f-8445-40df04b22ed6@gwdg.de>

Dear QGIS devs,
I am writing to you on behalf of the small group of SAGA GIS developers.
This thread has raised several points and perspectives that are of great 
interest to us, and we would like to share the SAGA team?s perspective 
on them.

However, before we contribute here, we would like to discuss this at our 
regular developer meeting next Friday (May 29). We have already added 
the topic to the agenda :)
After that, we will post here in the thread and try to outline our options.

@Nyall: Could you please make the ?SAGA Processing Nextgen? plugin, 
which is currently set to ?private?, public again for a while? I?d like 
to fork it, thanks!

Best wishes,
Rainer  (FreeBSD ports committer)


Am 22.05.26 um 01:55 schrieb Nyall Dawson via QGIS-Developer:
> On Thu, 21 May 2026 at 19:53, Stefano Campus via QGIS-Developer <qgis- 
> developer at lists.osgeo.org <mailto:qgis-developer at lists.osgeo.org>> wrote:
> 
>  > I?m writing to the dev list because I think this issue is of interest.
>  >
>  > For the past few days, the SAGA Next plugin?which allows you to use 
> SAGA GIS modules within QGIS Processing?has been unavailable.
> 
> Thanks for kicking off this discussion -- I've been waiting for someone 
> to raise it???
> 
> To explain the situation:
> 
> I've been "maintaining" that plugin for years. That's an over- 
> exaggeration... it hasn't received any love from me beyond reviewing a 
> pull request once every couple of years. I initially forked it (SAGA 
> NextGen) from the core SAGA plugin back in 2019 to help solve issues 
> with SAGA availability of LTR releases and broken stable API. Then in 
> 2019 https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230 
> <https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230> 
> followed, when?the built-in SAGA plugin was removed and it went from 
> being an out-of-the-box, "qgis.org <http://qgis.org> maintained" plugin 
> to relying on the third party SAGA NextGen?"community maintained" 
> plugin. That's 100% because it was concluded by all the developers 
> responsible for that code that it wasn't up to the quality standards of 
> the rest of QGIS.
> 
> It was always a fragile mess of a plugin. Part of that was because of 
> the difficulties associated with SAGA versioning, part of that was 
> because it was initially forked from old python code that no-one had 
> ever modernised. To say it was held together with chewing gum would be a 
> lie... it was held together with some soggy wet toilet paper at 
> best!???This really bugged me. I'd see constant user frustration 
> because it never worked well, and IMO this user frustration was harming 
> the reputation of QGIS itself. It didn't help that I'd keep reading 
> blogs/guides/tutorials where people were recommending?using it for 
> operations where QGIS native tools are SOOOO much better (eg vector 
> operations like buffering).
> 
> It was never my desire to become the maintainer of the plugin and put in 
> the work required to bring it up to the quality standard I hold to, 
> rather, I offered it on an initially voluntary basis to fix immediate 
> issues I saw users were experiencing and with the hope that making it a 
> third party plugin would help grow a healthy community that would take 
> it over.
> 
> That never happened... Instead it was just another burden that I carried 
> for everyone, with the associated lack of thanks and lack of any 
> recognition beyond angry emails when it didn't work.??. Ah well, that's 
> just life as a QGIS developer, we all deal with that, and I'm thick- 
> skinned enough to handle it!
> 
> At least, I thought so. Then the AI apocalypse hit in 2026.
> 
> As a response to my frustration with the lack of support the user 
> community is giving to open-source developers during this INCREDIBLY 
> challenging time, I decided to close off a bunch of my public 
> repositories. Because, hey, I don't want to directly train the 
> technologies that will likely destroy the whole economics behind open- 
> source software development. So I closed off repositories for things I'd 
> voluntarily made public, including dropping any QGIS plugin that I 
> wasn't directly using myself anymore, and that wasn't funded or in use 
> by my customers (or where a better native tool now exists). And that 
> included the SAGA NextGen plugin. I have no use for it, and none of my 
> customers use it, and it's a PITA to "maintain".
> 
> I knew that by doing so I'd be stirring up trouble, and honestly, that 
> was partly my intention! I wanted to force a discussion about this, and 
> raise widespread attention to the issues that would otherwise go 
> unnoticed. It's the SAGA plugin today, but tomorrow it could easily be 
> QGIS itself, or GDAL, or PostGIS, or PDAL, or ...??
> 
> My personal preference would be that we continue to port useful tools 
> from SAGA to native QGIS versions of these tools. I've done this in the 
> past (see https://github.com/qgis/QGIS/pull/53794 <https://github.com/ 
> qgis/QGIS/pull/53794>, https://github.com/qgis/QGIS/pull/61722 <https:// 
> github.com/qgis/QGIS/pull/61722>) for tools that I need myself, or that 
> my customers rely on, and the QGIS native tools are so much better 
> (***FOR QGIS USERS***) then calling out to the SAGA versions. They have 
> full format support for all the data sources QGIS supports, they work 
> with massive rasters without memory issues, and they are much faster as 
> they don't require data conversion to intermediate formats. And on top 
> of that, they "just work" everywhere QGIS works -- there's no fussing 
> around with SAGA version compatibility, and no security risks with 
> python code shelling out to run random batch files.
> 
> (Please understand that I'm not insulting the SAGA developers or their 
> versions of these tools here... in my experience the SAGA developer's 
> logic is great, the code is well written and the algorithms themselves 
> are well designed. It's a testament to the SAGA developers how easy it 
> is to port the tools to QGIS, they are very readable and well 
> documented. My point is that we offer a better experience to **QGIS** 
> users by porting the tools to native equivalents using QGIS API directly).
> 
> If anyone has particular SAGA tools they rely on for their work, then 
> please reach out and I'll let you know how much it would cost to sponsor 
> a port of that tool.
> 
> Finally, please note that I didn't delete the plugin repository, I just 
> made it private instead of public. I'm happy to temporarily make it 
> public again if someone wants to fork it, but after they do that I'll 
> then permanently erase my repo. If someone wants to do this then let me 
> know and I'll re-open temporarily.
> 
> Nyall
> 
> 
>  >
>  > According to reports in the QGIS community?s Telegram group, 
> maintaining this plugin is becoming increasingly difficult due to 
> developments in the SAGA project, which can cause the plugin to stop 
> working.
>  >
>  > I recall that until a couple of years ago, SAGA was, like GRASS, a 
> resource installed directly within QGIS, but then, precisely because of 
> the difficulty in keeping up with SAGA?s developments, it was decided to 
> treat SAGA as a third-party resource accessible via plugins.
>  >
>  > I believe it is right that this important resource should not be 
> maintained on a voluntary basis by a single developer/user, but that it 
> should be taken on by the community.
>  >
>  > Do you think it would be a good idea to propose to the Steering Group 
> that its maintenance be taken on directly by the QGIS.org Foundation and 
> that a certain sum (1000?2000 euros?) be set aside in the annual budget 
> for its maintenance?
>  >
>  > Thank you
>  >
>  > stefano campus
>  >
>  > _______________________________________________
>  > QGIS-Developer mailing list
>  > QGIS-Developer at lists.osgeo.org <mailto:QGIS-Developer at lists.osgeo.org>
>  > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>  > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> <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


From c at margo.co  Mon May 25 15:07:48 2026
From: c at margo.co (Pedro Camargo)
Date: Tue, 26 May 2026 08:07:48 +1000
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <CAKmgki60jiKx29_K07F01Ppsut4s=Oeed6snJO7AVkwEYCVcpA@mail.gmail.com>
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
 <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
 <CAB28Asj_24L9gJV35fVT+hTxFFmRx5AVq_wfFOD-B_4YvoLC6A@mail.gmail.com>
 <19e5d33c97d.5bf7fc8a160332.3484047441793025941@margo.co>
 <CAKmgki60jiKx29_K07F01Ppsut4s=Oeed6snJO7AVkwEYCVcpA@mail.gmail.com>
Message-ID: <19e612e0e43.5e4f5c0d167233.5910070623743781589@margo.co>

Hey?Joona,



I have looked into qpip, but it is not sufficient. Not only do most dependencies have binaries, but the process?also creates a somewhat cumbersome installation workflow for non-technical users.



In the end, the problem seems to be that the plugins I am talking about are not really GIS plugins, but rather bigger pieces of software with a very significant QGIS component, mostly for visualization purposes, so I must grant that as a large part of the problem.



We will likely explore deploying custom plugin repositories and developing?full installers. It's inconvenient for users, but there isn't?another alternative I can see right now.



Cheers,

Pedro?







From: Joona Laine <joona.p.laine at gmail.com>
To: "Pedro Camargo"<c at margo.co>
Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
Date: Mon, 25 May 2026 15:47:55 +1000
Subject: Re: [QGIS-Developer] Security issues with plugins



Hello Pedro,

qgis-plugin-dev-tools ( https://github.com/nlsfi/qgis-plugin-dev-tools#setup ) solves the dependency issue by including the dependencies with the plugin package.



It can easily handle most of (non-binary) requirements by automatically rewriting the imports of theses vendored dependencies in the build process.?

This way it is possible to have multiple plugins using different version of the same requirement without any conflicts.

It is also possible to include binary dependencies but there is no operation system specific logic built yet at the moment.



There is also a tool called qpip ( https://github.com/opengisch/qpip ) for dependency management, which might be worth checking out.



Cheers,

Joona







ma 25.5.2026 klo 6.35 Pedro Camargo via QGIS-Developer ( mailto:qgis-developer at lists.osgeo.org ) kirjoitti:





Hey Nyall,



I hear you, but let me highlight two points of my original post.

? ? ? ?The plugin asks the user whether they want?to install the dependencies. 

? ? ? ?The dependencies are installed in the plugin folder and can therefore be removed without causing any lasting damage to the user's QGIS installation.


Installing additional dependencies in QGIS remains a painful task for less technical users, adding another (somewhat unnecessary) hurdle to?adoption.??



On that note, a fair question could be:? Is there a recommended low-effort (for users) path to install extra dependencies for plugins? 



If not, is that something being considered for the near future?





Cheers,

Pedro









From: Nyall Dawson < mailto:nyall.dawson at gmail.com >
To: "Pedro Camargo"< mailto:c at margo.co >
Cc: "Qgis Developer"< mailto:qgis-developer at lists.osgeo.org >
Date: Mon, 25 May 2026 11:12:20 +1000
Subject: Re: [QGIS-Developer] Security issues with plugins







On Mon, 25 May 2026 at 08:27, Pedro Camargo via QGIS-Developer < mailto:qgis-developer at lists.osgeo.org > wrote:

>

> Hello fellow QGISrs,

>

>

>

> I maintain a couple of plugins that require a substantial number of extra Python packages (many of which have compiled/binary components). Hence, those plugins install all such requirements in a folder directly inside the plugin itself, keeping it quite clean when the user wants to remove said plugins.

>

>

> I have been doing it this way for many years now, but this weekend I received security alerts that both plugins were taken down due to code that downloads extra dependencies (offending code at qaequilibrae/qaequilibrae/download_extra_packages_class.py at develop ? AequilibraE/qaequilibrae).

>

> Does anyone have any recommendations on how to proceed?? What is currently the recommended way for plugins to install further dependencies?



My personal 2c: a plugin should NEVER automatically install dependencies like this. Rather, you should detect missing dependencies, warn the user, and point them to a documentation page directing them how to install the missing libraries on different operating systems.



I think it's EXTREMELY dangerous for a plugin to assume that it can mess with the user's operating system in this way, as it risks completely breaking their QGIS install or even their wider python environment. I would like to see us explicitly blocking all plugins from the repository that do this in future.??



Nyall


>
> Cheers,
> Pedro
>
>
>
> _______________________________________________
> QGIS-Developer mailing list
> mailto: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
 mailto: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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260526/522c2840/attachment-0001.htm>

From nyall.dawson at gmail.com  Mon May 25 15:09:34 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Tue, 26 May 2026 08:09:34 +1000
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <4544a675-453f-428f-8445-40df04b22ed6@gwdg.de>
References: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
 <CAB28AsgnUm444vSZ6-e6y6VmnbkCkx5oBst+ZYGyFvVTZhKtiA@mail.gmail.com>
 <4544a675-453f-428f-8445-40df04b22ed6@gwdg.de>
Message-ID: <CAB28AsgzjJNgfh2hmRccCg=6YBQyv1xhv6aQimgw_fhXObmu+Q@mail.gmail.com>

On Tue, 26 May 2026 at 02:25, Rainer Hurling <rhurlin at gwdg.de> wrote:

> Dear QGIS devs,
> I am writing to you on behalf of the small group of SAGA GIS developers.
> This thread has raised several points and perspectives that are of great
> interest to us, and we would like to share the SAGA team?s perspective
> on them.
>
> However, before we contribute here, we would like to discuss this at our
> regular developer meeting next Friday (May 29). We have already added
> the topic to the agenda :)
> After that, we will post here in the thread and try to outline our options.
>
> @Nyall: Could you please make the ?SAGA Processing Nextgen? plugin,
> which is currently set to ?private?, public again for a while? I?d like
> to fork it, thanks!
>

Done! Can you let me know when you've forked so that I can revert to
private again?

Thanks,
Nyall


>
> Best wishes,
> Rainer  (FreeBSD ports committer)
>
>
> Am 22.05.26 um 01:55 schrieb Nyall Dawson via QGIS-Developer:
> > On Thu, 21 May 2026 at 19:53, Stefano Campus via QGIS-Developer <qgis-
> > developer at lists.osgeo.org <mailto:qgis-developer at lists.osgeo.org>>
> wrote:
> >
> >  > I?m writing to the dev list because I think this issue is of interest.
> >  >
> >  > For the past few days, the SAGA Next plugin?which allows you to use
> > SAGA GIS modules within QGIS Processing?has been unavailable.
> >
> > Thanks for kicking off this discussion -- I've been waiting for someone
> > to raise it ??
> >
> > To explain the situation:
> >
> > I've been "maintaining" that plugin for years. That's an over-
> > exaggeration... it hasn't received any love from me beyond reviewing a
> > pull request once every couple of years. I initially forked it (SAGA
> > NextGen) from the core SAGA plugin back in 2019 to help solve issues
> > with SAGA availability of LTR releases and broken stable API. Then in
> > 2019 https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230
> > <https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230>
> > followed, when the built-in SAGA plugin was removed and it went from
> > being an out-of-the-box, "qgis.org <http://qgis.org> maintained" plugin
> > to relying on the third party SAGA NextGen "community maintained"
> > plugin. That's 100% because it was concluded by all the developers
> > responsible for that code that it wasn't up to the quality standards of
> > the rest of QGIS.
> >
> > It was always a fragile mess of a plugin. Part of that was because of
> > the difficulties associated with SAGA versioning, part of that was
> > because it was initially forked from old python code that no-one had
> > ever modernised. To say it was held together with chewing gum would be a
> > lie... it was held together with some soggy wet toilet paper at
> > best! ? This really bugged me. I'd see constant user frustration
> > because it never worked well, and IMO this user frustration was harming
> > the reputation of QGIS itself. It didn't help that I'd keep reading
> > blogs/guides/tutorials where people were recommending using it for
> > operations where QGIS native tools are SOOOO much better (eg vector
> > operations like buffering).
> >
> > It was never my desire to become the maintainer of the plugin and put in
> > the work required to bring it up to the quality standard I hold to,
> > rather, I offered it on an initially voluntary basis to fix immediate
> > issues I saw users were experiencing and with the hope that making it a
> > third party plugin would help grow a healthy community that would take
> > it over.
> >
> > That never happened... Instead it was just another burden that I carried
> > for everyone, with the associated lack of thanks and lack of any
> > recognition beyond angry emails when it didn't work. ?. Ah well, that's
> > just life as a QGIS developer, we all deal with that, and I'm thick-
> > skinned enough to handle it!
> >
> > At least, I thought so. Then the AI apocalypse hit in 2026.
> >
> > As a response to my frustration with the lack of support the user
> > community is giving to open-source developers during this INCREDIBLY
> > challenging time, I decided to close off a bunch of my public
> > repositories. Because, hey, I don't want to directly train the
> > technologies that will likely destroy the whole economics behind open-
> > source software development. So I closed off repositories for things I'd
> > voluntarily made public, including dropping any QGIS plugin that I
> > wasn't directly using myself anymore, and that wasn't funded or in use
> > by my customers (or where a better native tool now exists). And that
> > included the SAGA NextGen plugin. I have no use for it, and none of my
> > customers use it, and it's a PITA to "maintain".
> >
> > I knew that by doing so I'd be stirring up trouble, and honestly, that
> > was partly my intention! I wanted to force a discussion about this, and
> > raise widespread attention to the issues that would otherwise go
> > unnoticed. It's the SAGA plugin today, but tomorrow it could easily be
> > QGIS itself, or GDAL, or PostGIS, or PDAL, or ... ?
> >
> > My personal preference would be that we continue to port useful tools
> > from SAGA to native QGIS versions of these tools. I've done this in the
> > past (see https://github.com/qgis/QGIS/pull/53794 <https://github.com/
> > qgis/QGIS/pull/53794>, https://github.com/qgis/QGIS/pull/61722 <https://
> > github.com/qgis/QGIS/pull/61722>) for tools that I need myself, or that
> > my customers rely on, and the QGIS native tools are so much better
> > (***FOR QGIS USERS***) then calling out to the SAGA versions. They have
> > full format support for all the data sources QGIS supports, they work
> > with massive rasters without memory issues, and they are much faster as
> > they don't require data conversion to intermediate formats. And on top
> > of that, they "just work" everywhere QGIS works -- there's no fussing
> > around with SAGA version compatibility, and no security risks with
> > python code shelling out to run random batch files.
> >
> > (Please understand that I'm not insulting the SAGA developers or their
> > versions of these tools here... in my experience the SAGA developer's
> > logic is great, the code is well written and the algorithms themselves
> > are well designed. It's a testament to the SAGA developers how easy it
> > is to port the tools to QGIS, they are very readable and well
> > documented. My point is that we offer a better experience to **QGIS**
> > users by porting the tools to native equivalents using QGIS API
> directly).
> >
> > If anyone has particular SAGA tools they rely on for their work, then
> > please reach out and I'll let you know how much it would cost to sponsor
> > a port of that tool.
> >
> > Finally, please note that I didn't delete the plugin repository, I just
> > made it private instead of public. I'm happy to temporarily make it
> > public again if someone wants to fork it, but after they do that I'll
> > then permanently erase my repo. If someone wants to do this then let me
> > know and I'll re-open temporarily.
> >
> > Nyall
> >
> >
> >  >
> >  > According to reports in the QGIS community?s Telegram group,
> > maintaining this plugin is becoming increasingly difficult due to
> > developments in the SAGA project, which can cause the plugin to stop
> > working.
> >  >
> >  > I recall that until a couple of years ago, SAGA was, like GRASS, a
> > resource installed directly within QGIS, but then, precisely because of
> > the difficulty in keeping up with SAGA?s developments, it was decided to
> > treat SAGA as a third-party resource accessible via plugins.
> >  >
> >  > I believe it is right that this important resource should not be
> > maintained on a voluntary basis by a single developer/user, but that it
> > should be taken on by the community.
> >  >
> >  > Do you think it would be a good idea to propose to the Steering Group
> > that its maintenance be taken on directly by the QGIS.org Foundation and
> > that a certain sum (1000?2000 euros?) be set aside in the annual budget
> > for its maintenance?
> >  >
> >  > Thank you
> >  >
> >  > stefano campus
> >  >
> >  > _______________________________________________
> >  > QGIS-Developer mailing list
> >  > QGIS-Developer at lists.osgeo.org <mailto:QGIS-Developer at lists.osgeo.org
> >
> >  > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> >  > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > <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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260526/9933ad2a/attachment.htm>

From imajimatika at gmail.com  Tue May 26 00:07:35 2026
From: imajimatika at gmail.com (Ismail Sunni)
Date: Tue, 26 May 2026 14:07:35 +0700
Subject: [QGIS-Developer] Request from QGIS docs writers
In-Reply-To: <CALarpe7cmQOaDJAWU9W0bNpy0ocRC=aqYKBWk0jWbq3XexSKPA@mail.gmail.com>
References: <CALarpe7cmQOaDJAWU9W0bNpy0ocRC=aqYKBWk0jWbq3XexSKPA@mail.gmail.com>
Message-ID: <CAEh5jtFsGjN5nK7QTwznGvxpAz7Bk-=61GWjxQo5LSE7fYb4_Q@mail.gmail.com>

Hi Selma,

For 3D data, perhaps you check this list from Martin Dobias:
https://github.com/wonder-sk/3d-spatial-data *in case you haven't seen it
before.

Best regards

On Mon, May 25, 2026 at 5:17?PM Selma Vidimlic via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hi devs,
>
> Hope you're all doing well! We're reaching out from the documentation team
> with a few requests.
>
> As we work on documenting various features, we've run into challenges
> finding good test data, particularly for 3D, point clouds, and specific
> database formats. If any of you have sample data you could share, or know
> of reliable sources where we could find suitable datasets, that would be a
> huge help. And if you're aware, when developing things, that a format you
> use is specific or hard to find online, please consider sending us your own
> test data directly, that would be especially valuable.
>
> We're also putting together content for the QGIS Open Day (QOD) series,
> and 3D features are high on our list. If you have suggestions for
> interesting data sources that would showcase these features well, please
> share them with us.
>
> A couple of other things we'd like to flag:
>
> **"Needs documentation" label**: It would mean a lot if you could keep an
> eye on this label in the dev repository and action it when relevant.
> Staying on top of it helps us keep documentation timely and accurate.
> Sometimes we receive issue tickets in our repo and when working on them, we
> might discover related PRs in the dev repo, or we might find new UI
> elements without a corresponding issue ticket in our repo, then we need to
> dig through the development repository. This process can take some time or
> even confuse us as writers.
>
> **Feature descriptions & use cases**: Whenever you have a spare moment,
> even a brief description of a feature or a real-world use case goes a long
> way in helping us document things properly.
>
> We know you're busy, and we truly appreciate any time and input you can
> spare.
>
> Thanks so much,
> Selma Vidimlic Husic
> *QGIS Documentation writer*
>
> *E:* selma 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.*
> _______________________________________________
> 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
>


-- 
Ismail Sunni
Software Engineer
ismailsunni.id
ismailsunni.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260526/96640e34/attachment-0001.htm>

From phidrho at gmail.com  Tue May 26 06:06:03 2026
From: phidrho at gmail.com (=?UTF-8?Q?Vedran_Stojnovi=C4=87?=)
Date: Tue, 26 May 2026 15:06:03 +0200
Subject: [QGIS-Developer] Request from QGIS docs writers
In-Reply-To: <CALarpe7cmQOaDJAWU9W0bNpy0ocRC=aqYKBWk0jWbq3XexSKPA@mail.gmail.com>
References: <CALarpe7cmQOaDJAWU9W0bNpy0ocRC=aqYKBWk0jWbq3XexSKPA@mail.gmail.com>
Message-ID: <CAL9iSMH6ptMNsE8PNPxJvynUXrvB2vdYW44biP1jCBsi2gwwhQ@mail.gmail.com>

Hi Selma and list,

we (contributors from Croatia) have recently collected 3D point cloud for
purpose of QGIS development.
Do we have some digital warehouse location where we can put it online to
share it with everyone or should we push it to source code repository
directly?

Srda?an pozdrav / Kind regards,
Vedran Stojnovi?.


pon, 25. svi 2026. u 12:17 Selma Vidimlic via QGIS-Developer <
qgis-developer at lists.osgeo.org> napisao je:

> Hi devs,
>
> Hope you're all doing well! We're reaching out from the documentation team
> with a few requests.
>
> As we work on documenting various features, we've run into challenges
> finding good test data, particularly for 3D, point clouds, and specific
> database formats. If any of you have sample data you could share, or know
> of reliable sources where we could find suitable datasets, that would be a
> huge help. And if you're aware, when developing things, that a format you
> use is specific or hard to find online, please consider sending us your own
> test data directly, that would be especially valuable.
>
> We're also putting together content for the QGIS Open Day (QOD) series,
> and 3D features are high on our list. If you have suggestions for
> interesting data sources that would showcase these features well, please
> share them with us.
>
> A couple of other things we'd like to flag:
>
> **"Needs documentation" label**: It would mean a lot if you could keep an
> eye on this label in the dev repository and action it when relevant.
> Staying on top of it helps us keep documentation timely and accurate.
> Sometimes we receive issue tickets in our repo and when working on them, we
> might discover related PRs in the dev repo, or we might find new UI
> elements without a corresponding issue ticket in our repo, then we need to
> dig through the development repository. This process can take some time or
> even confuse us as writers.
>
> **Feature descriptions & use cases**: Whenever you have a spare moment,
> even a brief description of a feature or a real-world use case goes a long
> way in helping us document things properly.
>
> We know you're busy, and we truly appreciate any time and input you can
> spare.
>
> Thanks so much,
> Selma Vidimlic Husic
> *QGIS Documentation writer*
>
> *E:* selma 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.*
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260526/05804245/attachment.htm>

From rhurlin at gwdg.de  Tue May 26 08:54:08 2026
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Tue, 26 May 2026 17:54:08 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <CAB28AsgzjJNgfh2hmRccCg=6YBQyv1xhv6aQimgw_fhXObmu+Q@mail.gmail.com>
References: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
 <CAB28AsgnUm444vSZ6-e6y6VmnbkCkx5oBst+ZYGyFvVTZhKtiA@mail.gmail.com>
 <4544a675-453f-428f-8445-40df04b22ed6@gwdg.de>
 <CAB28AsgzjJNgfh2hmRccCg=6YBQyv1xhv6aQimgw_fhXObmu+Q@mail.gmail.com>
Message-ID: <e1c06318-b024-49a9-8506-af36aab15eaa@gwdg.de>

Hi Nyall,

Am 26.05.26 um 00:09 schrieb Nyall Dawson:
> 
> 
> On Tue, 26 May 2026 at 02:25, Rainer Hurling <rhurlin at gwdg.de 
> <mailto:rhurlin at gwdg.de>> wrote:
> 
>     Dear QGIS devs,
>     I am writing to you on behalf of the small group of SAGA GIS developers.
>     This thread has raised several points and perspectives that are of
>     great
>     interest to us, and we would like to share the SAGA team?s perspective
>     on them.
> 
>     However, before we contribute here, we would like to discuss this at
>     our
>     regular developer meeting next Friday (May 29). We have already added
>     the topic to the agenda :)
>     After that, we will post here in the thread and try to outline our
>     options.
> 
>     @Nyall: Could you please make the ?SAGA Processing Nextgen? plugin,
>     which is currently set to ?private?, public again for a while? I?d like
>     to fork it, thanks!
> 
> 
> Done! Can you let me know when you've forked so that I can revert to 
> private again?

Done, too!
Thank you very much for giving me the opportunity to fork your plugin 
before it is no longer accessible to the public. It can now be set to 
?Private? again :)

Rainer
(FreeBSD Committer, rhurlin at FreeBSD.org)


> Thanks,
> Nyall
> 
> 
>     Best wishes,
>     Rainer? (FreeBSD ports committer)
> 
> 
>     Am 22.05.26 um 01:55 schrieb Nyall Dawson via QGIS-Developer:
>      > On Thu, 21 May 2026 at 19:53, Stefano Campus via QGIS-Developer
>     <qgis-
>      > developer at lists.osgeo.org <mailto:developer at lists.osgeo.org>
>     <mailto:qgis-developer at lists.osgeo.org <mailto:qgis-
>     developer at lists.osgeo.org>>> wrote:
>      >
>      >? > I?m writing to the dev list because I think this issue is of
>     interest.
>      >? >
>      >? > For the past few days, the SAGA Next plugin?which allows you
>     to use
>      > SAGA GIS modules within QGIS Processing?has been unavailable.
>      >
>      > Thanks for kicking off this discussion -- I've been waiting for
>     someone
>      > to raise it???
>      >
>      > To explain the situation:
>      >
>      > I've been "maintaining" that plugin for years. That's an over-
>      > exaggeration... it hasn't received any love from me beyond
>     reviewing a
>      > pull request once every couple of years. I initially forked it (SAGA
>      > NextGen) from the core SAGA plugin back in 2019 to help solve issues
>      > with SAGA availability of LTR releases and broken stable API.
>     Then in
>      > 2019 https://github.com/qgis/QGIS-Enhancement-Proposals/
>     issues/230 <https://github.com/qgis/QGIS-Enhancement-Proposals/
>     issues/230>
>      > <https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230
>     <https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230>>
>      > followed, when?the built-in SAGA plugin was removed and it went from
>      > being an out-of-the-box, "qgis.org <http://qgis.org> <http://
>     qgis.org <http://qgis.org>> maintained" plugin
>      > to relying on the third party SAGA NextGen?"community maintained"
>      > plugin. That's 100% because it was concluded by all the developers
>      > responsible for that code that it wasn't up to the quality
>     standards of
>      > the rest of QGIS.
>      >
>      > It was always a fragile mess of a plugin. Part of that was
>     because of
>      > the difficulties associated with SAGA versioning, part of that was
>      > because it was initially forked from old python code that no-one had
>      > ever modernised. To say it was held together with chewing gum
>     would be a
>      > lie... it was held together with some soggy wet toilet paper at
>      > best!???This really bugged me. I'd see constant user frustration
>      > because it never worked well, and IMO this user frustration was
>     harming
>      > the reputation of QGIS itself. It didn't help that I'd keep reading
>      > blogs/guides/tutorials where people were recommending?using it for
>      > operations where QGIS native tools are SOOOO much better (eg vector
>      > operations like buffering).
>      >
>      > It was never my desire to become the maintainer of the plugin and
>     put in
>      > the work required to bring it up to the quality standard I hold to,
>      > rather, I offered it on an initially voluntary basis to fix
>     immediate
>      > issues I saw users were experiencing and with the hope that
>     making it a
>      > third party plugin would help grow a healthy community that would
>     take
>      > it over.
>      >
>      > That never happened... Instead it was just another burden that I
>     carried
>      > for everyone, with the associated lack of thanks and lack of any
>      > recognition beyond angry emails when it didn't work.??. Ah well,
>     that's
>      > just life as a QGIS developer, we all deal with that, and I'm thick-
>      > skinned enough to handle it!
>      >
>      > At least, I thought so. Then the AI apocalypse hit in 2026.
>      >
>      > As a response to my frustration with the lack of support the user
>      > community is giving to open-source developers during this INCREDIBLY
>      > challenging time, I decided to close off a bunch of my public
>      > repositories. Because, hey, I don't want to directly train the
>      > technologies that will likely destroy the whole economics behind
>     open-
>      > source software development. So I closed off repositories for
>     things I'd
>      > voluntarily made public, including dropping any QGIS plugin that I
>      > wasn't directly using myself anymore, and that wasn't funded or
>     in use
>      > by my customers (or where a better native tool now exists). And that
>      > included the SAGA NextGen plugin. I have no use for it, and none
>     of my
>      > customers use it, and it's a PITA to "maintain".
>      >
>      > I knew that by doing so I'd be stirring up trouble, and honestly,
>     that
>      > was partly my intention! I wanted to force a discussion about
>     this, and
>      > raise widespread attention to the issues that would otherwise go
>      > unnoticed. It's the SAGA plugin today, but tomorrow it could
>     easily be
>      > QGIS itself, or GDAL, or PostGIS, or PDAL, or ...??
>      >
>      > My personal preference would be that we continue to port useful
>     tools
>      > from SAGA to native QGIS versions of these tools. I've done this
>     in the
>      > past (see https://github.com/qgis/QGIS/pull/53794 <https://
>     github.com/qgis/QGIS/pull/53794> <https://github.com/ <https://
>     github.com/>
>      > qgis/QGIS/pull/53794>, https://github.com/qgis/QGIS/pull/61722
>     <https://github.com/qgis/QGIS/pull/61722> <https://
>      > github.com/qgis/QGIS/pull/61722 <http://github.com/qgis/QGIS/
>     pull/61722>>) for tools that I need myself, or that
>      > my customers rely on, and the QGIS native tools are so much better
>      > (***FOR QGIS USERS***) then calling out to the SAGA versions.
>     They have
>      > full format support for all the data sources QGIS supports, they
>     work
>      > with massive rasters without memory issues, and they are much
>     faster as
>      > they don't require data conversion to intermediate formats. And
>     on top
>      > of that, they "just work" everywhere QGIS works -- there's no
>     fussing
>      > around with SAGA version compatibility, and no security risks with
>      > python code shelling out to run random batch files.
>      >
>      > (Please understand that I'm not insulting the SAGA developers or
>     their
>      > versions of these tools here... in my experience the SAGA
>     developer's
>      > logic is great, the code is well written and the algorithms
>     themselves
>      > are well designed. It's a testament to the SAGA developers how
>     easy it
>      > is to port the tools to QGIS, they are very readable and well
>      > documented. My point is that we offer a better experience to
>     **QGIS**
>      > users by porting the tools to native equivalents using QGIS API
>     directly).
>      >
>      > If anyone has particular SAGA tools they rely on for their work,
>     then
>      > please reach out and I'll let you know how much it would cost to
>     sponsor
>      > a port of that tool.
>      >
>      > Finally, please note that I didn't delete the plugin repository,
>     I just
>      > made it private instead of public. I'm happy to temporarily make it
>      > public again if someone wants to fork it, but after they do that
>     I'll
>      > then permanently erase my repo. If someone wants to do this then
>     let me
>      > know and I'll re-open temporarily.
>      >
>      > Nyall
>      >
>      >
>      >? >
>      >? > According to reports in the QGIS community?s Telegram group,
>      > maintaining this plugin is becoming increasingly difficult due to
>      > developments in the SAGA project, which can cause the plugin to stop
>      > working.
>      >? >
>      >? > I recall that until a couple of years ago, SAGA was, like
>     GRASS, a
>      > resource installed directly within QGIS, but then, precisely
>     because of
>      > the difficulty in keeping up with SAGA?s developments, it was
>     decided to
>      > treat SAGA as a third-party resource accessible via plugins.
>      >? >
>      >? > I believe it is right that this important resource should not be
>      > maintained on a voluntary basis by a single developer/user, but
>     that it
>      > should be taken on by the community.
>      >? >
>      >? > Do you think it would be a good idea to propose to the
>     Steering Group
>      > that its maintenance be taken on directly by the QGIS.org
>     Foundation and
>      > that a certain sum (1000?2000 euros?) be set aside in the annual
>     budget
>      > for its maintenance?
>      >? >
>      >? > Thank you
>      >? >
>      >? > stefano campus
>      >? >
>      >? > _______________________________________________
>      >? > QGIS-Developer mailing list
>      >? > QGIS-Developer at lists.osgeo.org <mailto:QGIS-
>     Developer at lists.osgeo.org> <mailto:QGIS-Developer at lists.osgeo.org
>     <mailto:QGIS-Developer at lists.osgeo.org>>
>      >? > List info: https://lists.osgeo.org/mailman/listinfo/qgis-
>     developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>      > <https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     <https://lists.osgeo.org/mailman/listinfo/qgis-developer>>
>      >? > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-
>     developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>      > <https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     <https://lists.osgeo.org/mailman/listinfo/qgis-developer>>
>      >
>      > _______________________________________________
>      > QGIS-Developer mailing list
>      > QGIS-Developer at lists.osgeo.org <mailto:QGIS-
>     Developer at lists.osgeo.org>
>      > List info: https://lists.osgeo.org/mailman/listinfo/qgis-
>     developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>      > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-
>     developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> 


From julien.cabieces at oslandia.com  Wed May 27 03:27:52 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Wed, 27 May 2026 12:27:52 +0200
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <19e612e0e43.5e4f5c0d167233.5910070623743781589@margo.co> (Pedro
 Camargo via's message of "Tue, 26 May 2026 08:07:48 +1000")
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
 <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
 <CAB28Asj_24L9gJV35fVT+hTxFFmRx5AVq_wfFOD-B_4YvoLC6A@mail.gmail.com>
 <19e5d33c97d.5bf7fc8a160332.3484047441793025941@margo.co>
 <CAKmgki60jiKx29_K07F01Ppsut4s=Oeed6snJO7AVkwEYCVcpA@mail.gmail.com>
 <19e612e0e43.5e4f5c0d167233.5910070623743781589@margo.co>
Message-ID: <87a4tl87vb.fsf@julienlaptop.home>


Hi all,

I think qpip is the best way to solve this particular matter. IMHO, The only
drawback now is that you have to add qpip as a plugin dependencies to
then declare your dependencies. So the first time, QGIS would display
a popup-up to propose the user to install qpip, and then qpip would
propose the user to install the dependencies.

This is maybe what people consider combersome for users, but when it's
already installed, I think it's the proper way to go: We warn user that
something need to be installed, he agrees or not (just one click!), then
we install it or not.

Maybe, we should consider integrate it in the core so we skip the first
step. There is already a plugin dependencies management in QGIS core, so
that's maybe relevant to extend it to what qpip can do.

Regards,
Julien



> Hey Joona,
>
> I have looked into qpip, but it is not sufficient. Not only do most dependencies have binaries, but the process also creates a somewhat
> cumbersome installation workflow for non-technical users.
>
> In the end, the problem seems to be that the plugins I am talking about are not really GIS plugins, but rather bigger pieces of software with a
> very significant QGIS component, mostly for visualization purposes, so I must grant that as a large part of the problem.
>
> We will likely explore deploying custom plugin repositories and developing full installers. It's inconvenient for users, but there isn't another
> alternative I can see right now.
>
> Cheers,
> Pedro?
>
> From: Joona Laine <joona.p.laine at gmail.com>
> To: "Pedro Camargo"<c at margo.co>
> Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
> Date: Mon, 25 May 2026 15:47:55 +1000
> Subject: Re: [QGIS-Developer] Security issues with plugins
>
>  Hello Pedro,
>
>  qgis-plugin-dev-tools (https://github.com/nlsfi/qgis-plugin-dev-tools#setup) solves the dependency issue by including the dependencies
>  with the plugin package.
>
>  It can easily handle most of (non-binary) requirements by automatically rewriting the imports of theses vendored dependencies in the
>  build process. 
>  This way it is possible to have multiple plugins using different version of the same requirement without any conflicts.
>  It is also possible to include binary dependencies but there is no operation system specific logic built yet at the moment.
>
>  There is also a tool called qpip (https://github.com/opengisch/qpip) for dependency management, which might be worth checking out.
>
>  Cheers,
>  Joona
>
>  ma 25.5.2026 klo 6.35 Pedro Camargo via QGIS-Developer (qgis-developer at lists.osgeo.org) kirjoitti:
>
>  Hey Nyall,
>
>  I hear you, but let me highlight two points of my original post.
>
>  *        The plugin asks the user whether they want to install the dependencies. 
>  *        The dependencies are installed in the plugin folder and can therefore be removed without causing any lasting damage to the
>  user's QGIS installation.
>
>  Installing additional dependencies in QGIS remains a painful task for less technical users, adding another (somewhat unnecessary)
>  hurdle to adoption.  
>
>  On that note, a fair question could be:  Is there a recommended low-effort (for users) path to install extra dependencies for plugins? 
>
>  If not, is that something being considered for the near future?
>
>  Cheers,
>  Pedro
>
>  From: Nyall Dawson <nyall.dawson at gmail.com>
>  To: "Pedro Camargo"<c at margo.co>
>  Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
>  Date: Mon, 25 May 2026 11:12:20 +1000
>  Subject: Re: [QGIS-Developer] Security issues with plugins
>
>  On Mon, 25 May 2026 at 08:27, Pedro Camargo via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>  >
>  > Hello fellow QGISrs,
>  >
>  >
>  >
>  > I maintain a couple of plugins that require a substantial number of extra Python packages (many of which have
>  compiled/binary components). Hence, those plugins install all such requirements in a folder directly inside the plugin itself,
>  keeping it quite clean when the user wants to remove said plugins.
>  >
>  >
>  > I have been doing it this way for many years now, but this weekend I received security alerts that both plugins were taken down
>  due to code that downloads extra dependencies (offending code at
>  qaequilibrae/qaequilibrae/download_extra_packages_class.py at develop ? AequilibraE/qaequilibrae).
>  >
>  > Does anyone have any recommendations on how to proceed?  What is currently the recommended way for plugins to install
>  further dependencies?
>
>  My personal 2c: a plugin should NEVER automatically install dependencies like this. Rather, you should detect missing
>  dependencies, warn the user, and point them to a documentation page directing them how to install the missing libraries on
>  different operating systems.
>
>  I think it's EXTREMELY dangerous for a plugin to assume that it can mess with the user's operating system in this way, as it risks
>  completely breaking their QGIS install or even their wider python environment. I would like to see us explicitly blocking all plugins
>  from the repository that do this in future. ?
>
>  Nyall
>
>  >
>  > Cheers,
>  > Pedro
>  >
>  >
>  >
>  > _______________________________________________
>  > 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
>
> _______________________________________________
> 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 c at margo.co  Wed May 27 05:50:06 2026
From: c at margo.co (Pedro Camargo)
Date: Wed, 27 May 2026 22:50:06 +1000
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <87a4tl87vb.fsf@julienlaptop.home>
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
 <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
 <CAB28Asj_24L9gJV35fVT+hTxFFmRx5AVq_wfFOD-B_4YvoLC6A@mail.gmail.com>
 <19e5d33c97d.5bf7fc8a160332.3484047441793025941@margo.co>
 <CAKmgki60jiKx29_K07F01Ppsut4s=Oeed6snJO7AVkwEYCVcpA@mail.gmail.com>
 <19e612e0e43.5e4f5c0d167233.5910070623743781589@margo.co>
 <87a4tl87vb.fsf@julienlaptop.home>
Message-ID: <19e697c2e38.73bdcbc9190774.3935473177734196241@margo.co>

Hi Julien,

This is indeed a possibility. However, there is one thing I do not understand.

As far as I understand, the way qpip installs dependencies is very similar to what we do in AequilibraE (command system call). So why is that qpip is still available through the plugin store?  Is there an important difference I am missing there?

Cheers,
Pedro


From: Julien Cabieces <julien.cabieces at oslandia.com>
To: "Pedro Camargo via QGIS-Developer"<qgis-developer at lists.osgeo.org>
Cc: "Pedro Camargo"<c at margo.co>
Date: Wed, 27 May 2026 20:27:52 +1000
Subject: Re: [QGIS-Developer] Security issues with plugins

 > 
 > Hi all,
 > 
 > I think qpip is the best way to solve this particular matter. IMHO, The only
 > drawback now is that you have to add qpip as a plugin dependencies to
 > then declare your dependencies. So the first time, QGIS would display
 > a popup-up to propose the user to install qpip, and then qpip would
 > propose the user to install the dependencies.
 > 
 > This is maybe what people consider combersome for users, but when it's
 > already installed, I think it's the proper way to go: We warn user that
 > something need to be installed, he agrees or not (just one click!), then
 > we install it or not.
 > 
 > Maybe, we should consider integrate it in the core so we skip the first
 > step. There is already a plugin dependencies management in QGIS core, so
 > that's maybe relevant to extend it to what qpip can do.
 > 
 > Regards,
 > Julien
 > 
 > 
 > 
 > > Hey Joona,
 > >
 > > I have looked into qpip, but it is not sufficient. Not only do most dependencies have binaries, but the process also creates a somewhat
 > > cumbersome installation workflow for non-technical users.
 > >
 > > In the end, the problem seems to be that the plugins I am talking about are not really GIS plugins, but rather bigger pieces of software with a
 > > very significant QGIS component, mostly for visualization purposes, so I must grant that as a large part of the problem.
 > >
 > > We will likely explore deploying custom plugin repositories and developing full installers. It's inconvenient for users, but there isn't another
 > > alternative I can see right now.
 > >
 > > Cheers,
 > > Pedro?
 > >
 > > From: Joona Laine <joona.p.laine at gmail.com>
 > > To: "Pedro Camargo"<c at margo.co>
 > > Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
 > > Date: Mon, 25 May 2026 15:47:55 +1000
 > > Subject: Re: [QGIS-Developer] Security issues with plugins
 > >
 > >  Hello Pedro,
 > >
 > >  qgis-plugin-dev-tools (https://github.com/nlsfi/qgis-plugin-dev-tools#setup) solves the dependency issue by including the dependencies
 > >  with the plugin package.
 > >
 > >  It can easily handle most of (non-binary) requirements by automatically rewriting the imports of theses vendored dependencies in the
 > >  build process. 
 > >  This way it is possible to have multiple plugins using different version of the same requirement without any conflicts.
 > >  It is also possible to include binary dependencies but there is no operation system specific logic built yet at the moment.
 > >
 > >  There is also a tool called qpip (https://github.com/opengisch/qpip) for dependency management, which might be worth checking out.
 > >
 > >  Cheers,
 > >  Joona
 > >
 > >  ma 25.5.2026 klo 6.35 Pedro Camargo via QGIS-Developer (qgis-developer at lists.osgeo.org) kirjoitti:
 > >
 > >  Hey Nyall,
 > >
 > >  I hear you, but let me highlight two points of my original post.
 > >
 > >  *        The plugin asks the user whether they want to install the dependencies. 
 > >  *        The dependencies are installed in the plugin folder and can therefore be removed without causing any lasting damage to the
 > >  user's QGIS installation.
 > >
 > >  Installing additional dependencies in QGIS remains a painful task for less technical users, adding another (somewhat unnecessary)
 > >  hurdle to adoption.  
 > >
 > >  On that note, a fair question could be:  Is there a recommended low-effort (for users) path to install extra dependencies for plugins? 
 > >
 > >  If not, is that something being considered for the near future?
 > >
 > >  Cheers,
 > >  Pedro
 > >
 > >  From: Nyall Dawson <nyall.dawson at gmail.com>
 > >  To: "Pedro Camargo"<c at margo.co>
 > >  Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
 > >  Date: Mon, 25 May 2026 11:12:20 +1000
 > >  Subject: Re: [QGIS-Developer] Security issues with plugins
 > >
 > >  On Mon, 25 May 2026 at 08:27, Pedro Camargo via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
 > >  >
 > >  > Hello fellow QGISrs,
 > >  >
 > >  >
 > >  >
 > >  > I maintain a couple of plugins that require a substantial number of extra Python packages (many of which have
 > >  compiled/binary components). Hence, those plugins install all such requirements in a folder directly inside the plugin itself,
 > >  keeping it quite clean when the user wants to remove said plugins.
 > >  >
 > >  >
 > >  > I have been doing it this way for many years now, but this weekend I received security alerts that both plugins were taken down
 > >  due to code that downloads extra dependencies (offending code at
 > >  qaequilibrae/qaequilibrae/download_extra_packages_class.py at develop ? AequilibraE/qaequilibrae).
 > >  >
 > >  > Does anyone have any recommendations on how to proceed?  What is currently the recommended way for plugins to install
 > >  further dependencies?
 > >
 > >  My personal 2c: a plugin should NEVER automatically install dependencies like this. Rather, you should detect missing
 > >  dependencies, warn the user, and point them to a documentation page directing them how to install the missing libraries on
 > >  different operating systems.
 > >
 > >  I think it's EXTREMELY dangerous for a plugin to assume that it can mess with the user's operating system in this way, as it risks
 > >  completely breaking their QGIS install or even their wider python environment. I would like to see us explicitly blocking all plugins
 > >  from the repository that do this in future. ?
 > >
 > >  Nyall
 > >
 > >  >
 > >  > Cheers,
 > >  > Pedro
 > >  >
 > >  >
 > >  >
 > >  > _______________________________________________
 > >  > 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
 > >
 > > _______________________________________________
 > > 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 carrillo.german at gmail.com  Wed May 27 09:27:02 2026
From: carrillo.german at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Carrillo?=)
Date: Wed, 27 May 2026 11:27:02 -0500
Subject: [QGIS-Developer] Feedback on introducing a new (abstract) class:
 QgsSimpleCurve
Message-ID: <CANaz7mxYRfzxD9Vnw1kbjOmAS3NwG53qiN=+Yyr07tqvVgDMxg@mail.gmail.com>

Hi All,


In the context of the crowdfunded project to improve Circular Arcs support
in GEOS/QGIS, between Opengis.ch and Dan Baston from iSciences, we'd like
to ask you for technical feedback at an early stage of the QGIS
implementation.


We've come to the conclusion that in order to avoid code duplication in the
QgsGeos class, when importing/exporting LineString or CircularString
geometries from/to GEOS (used, e.g., in QgsGeos::fromGeos()
and QgsGeos::asGeos() methods), we would need to introduce a new abstract
class called QgsSimpleCurve.

This new class would inherit from QgsCurve and would be the base class for
QgsLineString and QgsCircularString. Namely, importing/exporting
QgsCircularString geometries would largely benefit from the existing
import/export code for QgsLineString, so we'd be reusing as much code as
possible.

Moreover, other projects like GDAL/OGR [1] and GEOS itself [2], already
have SimpleCurve classes to ease implementation, even if a SimpleCurve
class is not part of the SQL/MM standard.


An alternative would be to keep using QgsCurve as the base class, and add
some methods to it that would be ONLY used by
QgsLineString/QgsCircularString, ensuring that QgsCompoundCurve returns
exceptions when those methods are called.
Other alternatives are also welcome for the discussion, just let us know.


Since this decision is one of the building blocks for improving Circular
Arcs support in QGIS (e.g., for integrating a brand new Geometry Splitter
from GEOS, expected for the 3.15 release), we'd like to kindly ask for your
feedback before proceeding with a PR, so that we can assess early whether
the community estimates this move as risky or as a natural step for the
QGIS project.

Also, let us know if a QEP would be needed here, or if we could go on with
this discussion and then with a well isolated PR.
Thank you in advance.


Regards,

Germ?n
-----------
[1] https://gdal.org/en/stable/doxygen/classOGRSimpleCurve.html
[2]
https://github.com/libgeos/geos/blob/main/include/geos/geom/SimpleCurve.h
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260527/d9ee4a17/attachment.htm>

From axel.n.c.andersson at gmail.com  Wed May 27 13:25:53 2026
From: axel.n.c.andersson at gmail.com (=?UTF-8?Q?Axel_H=C3=B6rteborn?=)
Date: Wed, 27 May 2026 22:25:53 +0200
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <19e697c2e38.73bdcbc9190774.3935473177734196241@margo.co>
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
 <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
 <CAB28Asj_24L9gJV35fVT+hTxFFmRx5AVq_wfFOD-B_4YvoLC6A@mail.gmail.com>
 <19e5d33c97d.5bf7fc8a160332.3484047441793025941@margo.co>
 <CAKmgki60jiKx29_K07F01Ppsut4s=Oeed6snJO7AVkwEYCVcpA@mail.gmail.com>
 <19e612e0e43.5e4f5c0d167233.5910070623743781589@margo.co>
 <87a4tl87vb.fsf@julienlaptop.home>
 <19e697c2e38.73bdcbc9190774.3935473177734196241@margo.co>
Message-ID: <CAJj=OAoner2tFLGD13fsYKU-uLj7_y3otSivZsdYyaTJt4QFWA@mail.gmail.com>

Hi,

I'm maintaing the geodatafarm plugin where I have a few dependencies.
Earlier it was a hassel for many less thechnical users to install the
plugin on different OS etc. I can only recommend using the QPIP plugin as a
dependent qgis plugin, since it have solved these issues.

Best regards
Axel

Den ons 27 maj 2026 14:50Pedro Camargo via QGIS-Developer <
qgis-developer at lists.osgeo.org> skrev:

> Hi Julien,
>
> This is indeed a possibility. However, there is one thing I do not
> understand.
>
> As far as I understand, the way qpip installs dependencies is very similar
> to what we do in AequilibraE (command system call). So why is that qpip is
> still available through the plugin store?  Is there an important difference
> I am missing there?
>
> Cheers,
> Pedro
>
>
> From: Julien Cabieces <julien.cabieces at oslandia.com>
> To: "Pedro Camargo via QGIS-Developer"<qgis-developer at lists.osgeo.org>
> Cc: "Pedro Camargo"<c at margo.co>
> Date: Wed, 27 May 2026 20:27:52 +1000
> Subject: Re: [QGIS-Developer] Security issues with plugins
>
>  >
>  > Hi all,
>  >
>  > I think qpip is the best way to solve this particular matter. IMHO, The
> only
>  > drawback now is that you have to add qpip as a plugin dependencies to
>  > then declare your dependencies. So the first time, QGIS would display
>  > a popup-up to propose the user to install qpip, and then qpip would
>  > propose the user to install the dependencies.
>  >
>  > This is maybe what people consider combersome for users, but when it's
>  > already installed, I think it's the proper way to go: We warn user that
>  > something need to be installed, he agrees or not (just one click!), then
>  > we install it or not.
>  >
>  > Maybe, we should consider integrate it in the core so we skip the first
>  > step. There is already a plugin dependencies management in QGIS core, so
>  > that's maybe relevant to extend it to what qpip can do.
>  >
>  > Regards,
>  > Julien
>  >
>  >
>  >
>  > > Hey Joona,
>  > >
>  > > I have looked into qpip, but it is not sufficient. Not only do most
> dependencies have binaries, but the process also creates a somewhat
>  > > cumbersome installation workflow for non-technical users.
>  > >
>  > > In the end, the problem seems to be that the plugins I am talking
> about are not really GIS plugins, but rather bigger pieces of software with
> a
>  > > very significant QGIS component, mostly for visualization purposes,
> so I must grant that as a large part of the problem.
>  > >
>  > > We will likely explore deploying custom plugin repositories and
> developing full installers. It's inconvenient for users, but there isn't
> another
>  > > alternative I can see right now.
>  > >
>  > > Cheers,
>  > > Pedro?
>  > >
>  > > From: Joona Laine <joona.p.laine at gmail.com>
>  > > To: "Pedro Camargo"<c at margo.co>
>  > > Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
>  > > Date: Mon, 25 May 2026 15:47:55 +1000
>  > > Subject: Re: [QGIS-Developer] Security issues with plugins
>  > >
>  > >  Hello Pedro,
>  > >
>  > >  qgis-plugin-dev-tools (
> https://github.com/nlsfi/qgis-plugin-dev-tools#setup) solves the
> dependency issue by including the dependencies
>  > >  with the plugin package.
>  > >
>  > >  It can easily handle most of (non-binary) requirements by
> automatically rewriting the imports of theses vendored dependencies in the
>  > >  build process.
>  > >  This way it is possible to have multiple plugins using different
> version of the same requirement without any conflicts.
>  > >  It is also possible to include binary dependencies but there is no
> operation system specific logic built yet at the moment.
>  > >
>  > >  There is also a tool called qpip (https://github.com/opengisch/qpip)
> for dependency management, which might be worth checking out.
>  > >
>  > >  Cheers,
>  > >  Joona
>  > >
>  > >  ma 25.5.2026 klo 6.35 Pedro Camargo via QGIS-Developer (
> qgis-developer at lists.osgeo.org) kirjoitti:
>  > >
>  > >  Hey Nyall,
>  > >
>  > >  I hear you, but let me highlight two points of my original post.
>  > >
>  > >  *        The plugin asks the user whether they want to install the
> dependencies.
>  > >  *        The dependencies are installed in the plugin folder and can
> therefore be removed without causing any lasting damage to the
>  > >  user's QGIS installation.
>  > >
>  > >  Installing additional dependencies in QGIS remains a painful task
> for less technical users, adding another (somewhat unnecessary)
>  > >  hurdle to adoption.
>  > >
>  > >  On that note, a fair question could be:  Is there a recommended
> low-effort (for users) path to install extra dependencies for plugins?
>  > >
>  > >  If not, is that something being considered for the near future?
>  > >
>  > >  Cheers,
>  > >  Pedro
>  > >
>  > >  From: Nyall Dawson <nyall.dawson at gmail.com>
>  > >  To: "Pedro Camargo"<c at margo.co>
>  > >  Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
>  > >  Date: Mon, 25 May 2026 11:12:20 +1000
>  > >  Subject: Re: [QGIS-Developer] Security issues with plugins
>  > >
>  > >  On Mon, 25 May 2026 at 08:27, Pedro Camargo via QGIS-Developer <
> qgis-developer at lists.osgeo.org> wrote:
>  > >  >
>  > >  > Hello fellow QGISrs,
>  > >  >
>  > >  >
>  > >  >
>  > >  > I maintain a couple of plugins that require a substantial number
> of extra Python packages (many of which have
>  > >  compiled/binary components). Hence, those plugins install all such
> requirements in a folder directly inside the plugin itself,
>  > >  keeping it quite clean when the user wants to remove said plugins.
>  > >  >
>  > >  >
>  > >  > I have been doing it this way for many years now, but this weekend
> I received security alerts that both plugins were taken down
>  > >  due to code that downloads extra dependencies (offending code at
>  > >  qaequilibrae/qaequilibrae/download_extra_packages_class.py at
> develop ? AequilibraE/qaequilibrae).
>  > >  >
>  > >  > Does anyone have any recommendations on how to proceed?  What is
> currently the recommended way for plugins to install
>  > >  further dependencies?
>  > >
>  > >  My personal 2c: a plugin should NEVER automatically install
> dependencies like this. Rather, you should detect missing
>  > >  dependencies, warn the user, and point them to a documentation page
> directing them how to install the missing libraries on
>  > >  different operating systems.
>  > >
>  > >  I think it's EXTREMELY dangerous for a plugin to assume that it can
> mess with the user's operating system in this way, as it risks
>  > >  completely breaking their QGIS install or even their wider python
> environment. I would like to see us explicitly blocking all plugins
>  > >  from the repository that do this in future. ?
>  > >
>  > >  Nyall
>  > >
>  > >  >
>  > >  > Cheers,
>  > >  > Pedro
>  > >  >
>  > >  >
>  > >  >
>  > >  > _______________________________________________
>  > >  > 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
>  > >
>  > > _______________________________________________
>  > > 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
>  >
>
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260527/17cc60a9/attachment-0001.htm>

From gdt at lexort.com  Wed May 27 15:05:43 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 27 May 2026 18:05:43 -0400
Subject: [QGIS-Developer] Feedback on introducing a new (abstract)
 class: QgsSimpleCurve
In-Reply-To: <CANaz7mxYRfzxD9Vnw1kbjOmAS3NwG53qiN=+Yyr07tqvVgDMxg@mail.gmail.com>
 (=?utf-8?Q?=22Germ=C3=A1n?= Carrillo via QGIS-Developer"'s message of "Wed,
 27 May 2026 11:27:02 -0500")
References: <CANaz7mxYRfzxD9Vnw1kbjOmAS3NwG53qiN=+Yyr07tqvVgDMxg@mail.gmail.com>
Message-ID: <rmiv7c8eceg.fsf@s1.lexort.com>

Germ?n Carrillo via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> In the context of the crowdfunded project to improve Circular Arcs support
> in GEOS/QGIS, between Opengis.ch and Dan Baston from iSciences, we'd like
> to ask you for technical feedback at an early stage of the QGIS
> implementation.

I know there are various specifications and standards about kinds of
features.   I would like to see written up the high-level information
about what's going on, including:

  What are the relevant standards?

  For each, are there aspects that are not implemented in
  qgis/geos/gdal/postgis/?

  Do programs in the osgeo stack implement object types that  are not in
  the standards?

  In addition to actual standards, is the feature class under discussion
  implemented in any proprietary software?

  If the proposal is about an object type that's not in the standards,
  is there text available that is basically a proposed diff to each
  standard to add it?   Is there intent to actually propose that, or is
  this going down the path of diverging from the standard?

  In the design document that includes standards information, what would
  be the grand plan for which of the osgeo components would get support,
  and is there a preferred ordering to minimize effort?


I see you address gdal/geos but I don't see postgis mentioned.

> We've come to the conclusion that in order to avoid code duplication in the
> QgsGeos class, when importing/exporting LineString or CircularString
> geometries from/to GEOS (used, e.g., in QgsGeos::fromGeos()
> and QgsGeos::asGeos() methods), we would need to introduce a new abstract
> class called QgsSimpleCurve.
>
> This new class would inherit from QgsCurve and would be the base class for
> QgsLineString and QgsCircularString. Namely, importing/exporting
> QgsCircularString geometries would largely benefit from the existing
> import/export code for QgsLineString, so we'd be reusing as much code as
> possible.

An inheritance diagram would help to be sure I'm following.  And
explaining what the rules are for class membership.  I'm a little
worried about multiple inheritance and can't tell that you are intending
to really avoid that.

> Moreover, other projects like GDAL/OGR [1] and GEOS itself [2], already
> have SimpleCurve classes to ease implementation, even if a SimpleCurve
> class is not part of the SQL/MM standard.

is Simple Features also relevant?

> An alternative would be to keep using QgsCurve as the base class, and add
> some methods to it that would be ONLY used by
> QgsLineString/QgsCircularString, ensuring that QgsCompoundCurve returns
> exceptions when those methods are called.

This feels like adding rules to close off things and thus awkward.  My
gut reaction is don't do it; it will cause trouble.

> Since this decision is one of the building blocks for improving Circular
> Arcs support in QGIS (e.g., for integrating a brand new Geometry Splitter
> from GEOS, expected for the 3.15 release), we'd like to kindly ask for your
> feedback before proceeding with a PR, so that we can assess early whether
> the community estimates this move as risky or as a natural step for the
> QGIS project.
>
> Also, let us know if a QEP would be needed here, or if we could go on with
> this discussion and then with a well isolated PR.

If others think my requests for the larger picture make sense, that fits
with QEP.

From nyall.dawson at gmail.com  Wed May 27 15:59:38 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Thu, 28 May 2026 08:59:38 +1000
Subject: [QGIS-Developer] Feedback on introducing a new (abstract)
 class: QgsSimpleCurve
In-Reply-To: <CANaz7mxYRfzxD9Vnw1kbjOmAS3NwG53qiN=+Yyr07tqvVgDMxg@mail.gmail.com>
References: <CANaz7mxYRfzxD9Vnw1kbjOmAS3NwG53qiN=+Yyr07tqvVgDMxg@mail.gmail.com>
Message-ID: <CAB28AsiP73jWYA1fpuDF3i9LhkxVw_cMkVCDL7Q2iqG0GZ-gig@mail.gmail.com>

On Thu, 28 May 2026 at 02:27, Germ?n Carrillo via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:
>
> This new class would inherit from QgsCurve and would be the base class
for QgsLineString and QgsCircularString. Namely, importing/exporting
QgsCircularString geometries would largely benefit from the existing
import/export code for QgsLineString, so we'd be reusing as much code as
possible.

Makes sense to me ?
>
> Moreover, other projects like GDAL/OGR [1] and GEOS itself [2], already
have SimpleCurve classes to ease implementation, even if a SimpleCurve
class is not part of the SQL/MM standard.

If GDAL does this, then that's a good enough proof that it's not a bad move
to me.

Nyall


>
>
> An alternative would be to keep using QgsCurve as the base class, and add
some methods to it that would be ONLY used by
QgsLineString/QgsCircularString, ensuring that QgsCompoundCurve returns
exceptions when those methods are called.
> Other alternatives are also welcome for the discussion, just let us know.
>
>
> Since this decision is one of the building blocks for improving Circular
Arcs support in QGIS (e.g., for integrating a brand new Geometry Splitter
from GEOS, expected for the 3.15 release), we'd like to kindly ask for your
feedback before proceeding with a PR, so that we can assess early whether
the community estimates this move as risky or as a natural step for the
QGIS project.
>
> Also, let us know if a QEP would be needed here, or if we could go on
with this discussion and then with a well isolated PR.
> Thank you in advance.
>
>
> Regards,
>
> Germ?n
> -----------
> [1] https://gdal.org/en/stable/doxygen/classOGRSimpleCurve.html
> [2]
https://github.com/libgeos/geos/blob/main/include/geos/geom/SimpleCurve.h
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260528/a74b9673/attachment.htm>

From even.rouault at spatialys.com  Wed May 27 16:04:48 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Thu, 28 May 2026 01:04:48 +0200
Subject: [QGIS-Developer] Feedback on introducing a new (abstract)
 class: QgsSimpleCurve
In-Reply-To: <rmiv7c8eceg.fsf@s1.lexort.com>
References: <CANaz7mxYRfzxD9Vnw1kbjOmAS3NwG53qiN=+Yyr07tqvVgDMxg@mail.gmail.com>
 <rmiv7c8eceg.fsf@s1.lexort.com>
Message-ID: <2badf10e-cd7f-4a3c-ba73-de1af90489f9@spatialys.com>


Le 28/05/2026 ? 00:05, Greg Troxel via QGIS-Developer a ?crit?:
> Germ?n Carrillo via QGIS-Developer<qgis-developer at lists.osgeo.org>
> writes:
>
>> In the context of the crowdfunded project to improve Circular Arcs support
>> in GEOS/QGIS, between Opengis.ch and Dan Baston from iSciences, we'd like
>> to ask you for technical feedback at an early stage of the QGIS
>> implementation.

+1 from me for QgsSimpleCurve. Obviously strongly biased as the author 
of GDAL's OGRSimpleCurve.

If?QgsSimpleCurve appears in the SIP Python bindings, it might be 
appropriate to have a word in the doc about it being an implementation 
detail not covered by standards.

An alternative approach could have been to have QgsSimpleCurve as a 
member of QgsLineString & QgsCircularString, using composition rather 
than derivation, but that would likely be a rather verbose approach, 
probably not much better than copying&pasting code between both classes.

> I know there are various specifications and standards about kinds of
> features.   I would like to see written up the high-level information
> about what's going on, including:
>
>    What are the relevant standards?
>
>    For each, are there aspects that are not implemented in
>    qgis/geos/gdal/postgis/?
SQL/MM could possibly have exposed such a class, but I guess that's 
mostly seen as an implementation detail for implementations to avoid 
code duplication, rather than something impacting operability.
>    Do programs in the osgeo stack implement object types that  are not in
>    the standards?
Isn't that's > 90% of the job of making useful software, unless your 
software is just about making a reference implementation of a standard? 
Standards cover only the boring aspects :-)
>    If the proposal is about an object type that's not in the standards,
>    is there text available that is basically a proposed diff to each
>    standard to add it?   Is there intent to actually propose that, or is
>    this going down the path of diverging from the standard?
Personal opinion here: participation to standard working groups is time 
consuming and implies many year involvement due to slow motion / 
bureaucracy / opacity in group dynamics. That's not an activity 
structured for small/medium businesses (more for big commercial players 
that want to push their thing so they can later tick their 
implementation is compliant in call for tenders, or government agencies 
that have dedicated staff for interoperability topics), unless you are 
really fond of that or have significant funding.
> I see you address gdal/geos but I don't see postgis mentioned.
PostGIS is C, so inheritance is not a natural concept there. PostGIS's 
liblwgeom has identical layout for struct LWLINE 
(https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L480) 
and LWCIRCSTRING 
(https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L504) 

> An inheritance diagram would help to be sure I'm following.  And
> explaining what the rules are for class membership.  I'm a little
> worried about multiple inheritance and can't tell that you are intending
> to really avoid that.
See GDAL RFC 49 : 
https://gdal.org/en/stable/development/rfc/rfc49_curve_geometries.html#new-cass-hierarchy 

>> Moreover, other projects like GDAL/OGR [1] and GEOS itself [2], already
>> have SimpleCurve classes to ease implementation, even if a SimpleCurve
>> class is not part of the SQL/MM standard.
> is Simple Features also relevant?
SQL/MM is the ISO extension of Simple Features adding curve geometries. 
Old draft at 
https://web.archive.org/web/20071212154300/http://jtc1sc32.org/doc/N1101-1150/32N1107-WD13249-3--spatial.pdf 
, otherwise pay 100 + CHF to ISO. Although I see at the bottom of 
https://www.ogc.org/standards/sfa/ there's apparently an ongoing effort 
to reconcile both.

-- 
Very grumpy about LLMs: FOSS is about increasing public capital,
not becoming enslaved to private equity of giga corporations
--
http://www.spatialys.com
My software is free, but my time generally not.


From loic.bartoletti at oslandia.com  Wed May 27 20:15:10 2026
From: loic.bartoletti at oslandia.com (=?utf-8?B?TG/Dr2M=?= BARTOLETTI)
Date: Thu, 28 May 2026 05:15:10 +0200
Subject: [QGIS-Developer] Feedback on introducing a new (abstract)
 class: QgsSimpleCurve
In-Reply-To: <CANaz7mxYRfzxD9Vnw1kbjOmAS3NwG53qiN=+Yyr07tqvVgDMxg@mail.gmail.com>
References: <CANaz7mxYRfzxD9Vnw1kbjOmAS3NwG53qiN=+Yyr07tqvVgDMxg@mail.gmail.com>
Message-ID: <aheyzsWTUoAvEAO8@FreeBSD>

+1 from me for the QgsSimpleCurve class like gdal one.

Lo?c,

On 27/05/2026 11:27, Germ?n Carrillo via QGIS-Developer wrote:
>Hi All,
>
>
>In the context of the crowdfunded project to improve Circular Arcs support in
>GEOS/QGIS, between Opengis.ch and Dan Baston from iSciences, we'd like to ask
>you for technical feedback at an early stage of the QGIS implementation.
>
>
>We've come to the conclusion that in order to avoid code duplication in the
>QgsGeos class, when importing/exporting LineString or CircularString geometries
>from/to GEOS (used, e.g., in QgsGeos::fromGeos() and?QgsGeos::asGeos()
>methods), we would need to introduce a new abstract class called
>QgsSimpleCurve.
>
>This new class would inherit from QgsCurve and would be the base class for
>QgsLineString and QgsCircularString. Namely, importing/exporting
>QgsCircularString?geometries would largely benefit from the existing import/
>export code for QgsLineString, so we'd be reusing as much code as possible.
>
>Moreover, other projects like GDAL/OGR [1] and GEOS itself [2], already have
>SimpleCurve classes to ease implementation, even if a SimpleCurve class is not
>part of the SQL/MM standard.
>
>
>An alternative would be to keep using QgsCurve?as the base class, and add some
>methods to it that would be ONLY?used by QgsLineString/QgsCircularString,
>ensuring that QgsCompoundCurve returns exceptions when those methods are
>called.
>Other alternatives are also welcome for the discussion, just let us know.
>
>
>Since this decision is one of the building blocks for improving Circular Arcs
>support in QGIS (e.g., for integrating a brand new Geometry Splitter from GEOS,
>expected for the 3.15 release), we'd like to kindly ask for your feedback
>before proceeding with a PR, so that we can assess early whether the community
>estimates this move as risky or as a natural step for the QGIS project.
>
>Also, let us know if a QEP would be needed here, or if we could go on with this
>discussion and then with a well isolated PR.
>Thank you in advance.
>
>
>Regards,
>
>Germ?n
>-----------
>[1]?[1]https://gdal.org/en/stable/doxygen/classOGRSimpleCurve.html
>[2]?[2]https://github.com/libgeos/geos/blob/main/include/geos/geom/
>SimpleCurve.h
>
>References:
>
>[1] https://gdal.org/en/stable/doxygen/classOGRSimpleCurve.html
>[2] https://github.com/libgeos/geos/blob/main/include/geos/geom/SimpleCurve.h

>_______________________________________________
>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 gdt at lexort.com  Thu May 28 04:44:24 2026
From: gdt at lexort.com (Greg Troxel)
Date: Thu, 28 May 2026 07:44:24 -0400
Subject: [QGIS-Developer] Feedback on introducing a new (abstract)
 class: QgsSimpleCurve
In-Reply-To: <2badf10e-cd7f-4a3c-ba73-de1af90489f9@spatialys.com> (Even
 Rouault's message of "Thu, 28 May 2026 01:04:48 +0200")
References: <CANaz7mxYRfzxD9Vnw1kbjOmAS3NwG53qiN=+Yyr07tqvVgDMxg@mail.gmail.com>
 <rmiv7c8eceg.fsf@s1.lexort.com>
 <2badf10e-cd7f-4a3c-ba73-de1af90489f9@spatialys.com>
Message-ID: <rmi4ijrep2f.fsf@s1.lexort.com>

Even Rouault <even.rouault at spatialys.com> writes:

Thanks - especially GDAL RFC49 is enlightening.

>>    For each, are there aspects that are not implemented in
>>    qgis/geos/gdal/postgis/?
> SQL/MM could possibly have exposed such a class, but I guess that's
> mostly seen as an implementation detail for implementations to avoid
> code duplication, rather than something impacting operability.

The point that I didn't understand from the original mail is, I think,
that the new class is an implementation detail and not something that
will result in objects of that class being stored and read from files.

>>    Do programs in the osgeo stack implement object types that  are not in
>>    the standards?
> Isn't that's > 90% of the job of making useful software, unless your
> software is just about making a reference implementation of a
> standard? Standards cover only the boring aspects :-)

Sure, but it's good to know when that line is crossed, and there is
features of software, vs object types that are written and read and
might need to interoperate.

> Personal opinion here: participation to standard working groups is
> time consuming and implies many year involvement due to slow motion /
> bureaucracy / opacity in group dynamics. That's not an activity
> structured for small/medium businesses (more for big commercial
> players that want to push their thing so they can later tick their
> implementation is compliant in call for tenders, or government
> agencies that have dedicated staff for interoperability topics),
> unless you are really fond of that or have significant funding.

Understood.  I was trying to ask "could this be seen as a change to the
standard and if so is that written down", and asking what the plan is.

It sounds like this is an implementation detail and no objects of the
new type would be written to file formats.  Thus it is out of scope from
the standards.

>> I see you address gdal/geos but I don't see postgis mentioned.
> PostGIS is C, so inheritance is not a natural concept there. PostGIS's

In C, there is only the manual/hard/not-natural inheritance of
same-layout structs and casts :-)

> liblwgeom has identical layout for struct LWLINE
> (https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L480)
> and LWCIRCSTRING
> (https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L504)

but has no simplecurve.

> See GDAL RFC 49 :
> https://gdal.org/en/stable/development/rfc/rfc49_curve_geometries.html#new-cass-hierarchy

Thanks, that makes it all clear.  And this is "abstract class" which
means that there will never be an object of type OGRSimpleCurve in
memory, or written to a file.  And presumably, code won't return a
pointer to a QgsSimpleCurve object to a plugin, even if it could only be
accessed via virtual dispatch.

I missed the "(abstract)" (which is clearly present on rereading) in the
original question, and began to think about interoperability concerns.


This proposal seems fine to me and I withdraw my questions as mostly
answered and the rest explained why they don't really make sense to
answer.

From carrillo.german at gmail.com  Thu May 28 07:25:48 2026
From: carrillo.german at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Carrillo?=)
Date: Thu, 28 May 2026 09:25:48 -0500
Subject: [QGIS-Developer] Feedback on introducing a new (abstract)
 class: QgsSimpleCurve
In-Reply-To: <rmi4ijrep2f.fsf@s1.lexort.com>
References: <CANaz7mxYRfzxD9Vnw1kbjOmAS3NwG53qiN=+Yyr07tqvVgDMxg@mail.gmail.com>
 <rmiv7c8eceg.fsf@s1.lexort.com>
 <2badf10e-cd7f-4a3c-ba73-de1af90489f9@spatialys.com>
 <rmi4ijrep2f.fsf@s1.lexort.com>
Message-ID: <CANaz7mxGgkuuA-r7Mf-mTeZotw2=T0on=mKtPKp1kwmCHAWU3A@mail.gmail.com>

Hi,

Thanks Greg, Nyall, Even, and Lo?c for your responses.

And special thanks Even for clarifying the raised questions and for all the
shared resources.

If QgsSimpleCurve appears in the SIP Python bindings, it might be
> appropriate to have a word in the doc about it being an implementation
> detail not covered by standards.


Yes, we'll state this for Python bindings.

If others still want to share their thoughts on this, please do so.

I'll prepare a PR soon and let you know when that happens.

Regards,

Germ?n


El jue, 28 may 2026 a las 6:44, Greg Troxel via QGIS-Developer (<
qgis-developer at lists.osgeo.org>) escribi?:

> Even Rouault <even.rouault at spatialys.com> writes:
>
> Thanks - especially GDAL RFC49 is enlightening.
>
> >>    For each, are there aspects that are not implemented in
> >>    qgis/geos/gdal/postgis/?
> > SQL/MM could possibly have exposed such a class, but I guess that's
> > mostly seen as an implementation detail for implementations to avoid
> > code duplication, rather than something impacting operability.
>
> The point that I didn't understand from the original mail is, I think,
> that the new class is an implementation detail and not something that
> will result in objects of that class being stored and read from files.
>
> >>    Do programs in the osgeo stack implement object types that  are not
> in
> >>    the standards?
> > Isn't that's > 90% of the job of making useful software, unless your
> > software is just about making a reference implementation of a
> > standard? Standards cover only the boring aspects :-)
>
> Sure, but it's good to know when that line is crossed, and there is
> features of software, vs object types that are written and read and
> might need to interoperate.
>
> > Personal opinion here: participation to standard working groups is
> > time consuming and implies many year involvement due to slow motion /
> > bureaucracy / opacity in group dynamics. That's not an activity
> > structured for small/medium businesses (more for big commercial
> > players that want to push their thing so they can later tick their
> > implementation is compliant in call for tenders, or government
> > agencies that have dedicated staff for interoperability topics),
> > unless you are really fond of that or have significant funding.
>
> Understood.  I was trying to ask "could this be seen as a change to the
> standard and if so is that written down", and asking what the plan is.
>
> It sounds like this is an implementation detail and no objects of the
> new type would be written to file formats.  Thus it is out of scope from
> the standards.
>
> >> I see you address gdal/geos but I don't see postgis mentioned.
> > PostGIS is C, so inheritance is not a natural concept there. PostGIS's
>
> In C, there is only the manual/hard/not-natural inheritance of
> same-layout structs and casts :-)
>
> > liblwgeom has identical layout for struct LWLINE
> > (
> https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L480
> )
> > and LWCIRCSTRING
> > (
> https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L504
> )
>
> but has no simplecurve.
>
> > See GDAL RFC 49 :
> >
> https://gdal.org/en/stable/development/rfc/rfc49_curve_geometries.html#new-cass-hierarchy
>
> Thanks, that makes it all clear.  And this is "abstract class" which
> means that there will never be an object of type OGRSimpleCurve in
> memory, or written to a file.  And presumably, code won't return a
> pointer to a QgsSimpleCurve object to a plugin, even if it could only be
> accessed via virtual dispatch.
>
> I missed the "(abstract)" (which is clearly present on rereading) in the
> original question, and began to think about interoperability concerns.
>
>
> This proposal seems fine to me and I withdraw my questions as mostly
> answered and the rest explained why they don't really make sense to
> answer.
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260528/5ad1b088/attachment.htm>

From julien.cabieces at oslandia.com  Thu May 28 08:20:11 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Thu, 28 May 2026 17:20:11 +0200
Subject: [QGIS-Developer] Security issues with plugins
In-Reply-To: <19e697c2e38.73bdcbc9190774.3935473177734196241@margo.co> (Pedro
 Camargo's message of "Wed, 27 May 2026 22:50:06 +1000")
References: <19e5c048543.62349a8d153999.7192788050443117085@margo.co>
 <19e5c19506b.73d9190c154183.6844791622465253461@margo.co>
 <CAB28Asj_24L9gJV35fVT+hTxFFmRx5AVq_wfFOD-B_4YvoLC6A@mail.gmail.com>
 <19e5d33c97d.5bf7fc8a160332.3484047441793025941@margo.co>
 <CAKmgki60jiKx29_K07F01Ppsut4s=Oeed6snJO7AVkwEYCVcpA@mail.gmail.com>
 <19e612e0e43.5e4f5c0d167233.5910070623743781589@margo.co>
 <87a4tl87vb.fsf@julienlaptop.home>
 <19e697c2e38.73bdcbc9190774.3935473177734196241@margo.co>
Message-ID: <87pl2f8st0.fsf@julienlaptop.home>


Hi Pedro,

I don't think there is any checks yet about calling system command (using
subprocess) both used in your plugin and qpip.

I see nothing in the implemented security scan: https://github.com/qgis/QGIS-Plugins-Website/blob/18bf205e1c0733bc1f09f15430eff52c1a78a1a3/qgis-app/plugins/security_scanner.py#L67

I ran the security scan on your plugin and get those errors:

Detects suspicious file types, hidden files, or unexpected executables
- qaequilibrae-develop/.pre-commit-config.yaml': 'Hidden file detected'
- qaequilibrae-develop/docs/make.bat: 'Executable or binary file detected (.bat)'

So that should be easy to fix those so your plugin can pass the security scan.



Kind regards,
Julien


> Hi Julien,
>
> This is indeed a possibility. However, there is one thing I do not understand.
>
> As far as I understand, the way qpip installs dependencies is very
> similar to what we do in AequilibraE (command system call). So why is
> that qpip is still available through the plugin store?  Is there an
> important difference I am missing there?
>
> Cheers,
> Pedro
>
>
> From: Julien Cabieces <julien.cabieces at oslandia.com>
> To: "Pedro Camargo via QGIS-Developer"<qgis-developer at lists.osgeo.org>
> Cc: "Pedro Camargo"<c at margo.co>
> Date: Wed, 27 May 2026 20:27:52 +1000
> Subject: Re: [QGIS-Developer] Security issues with plugins
>
>  > 
>  > Hi all,
>  > 
>  > I think qpip is the best way to solve this particular matter. IMHO, The only
>  > drawback now is that you have to add qpip as a plugin dependencies to
>  > then declare your dependencies. So the first time, QGIS would display
>  > a popup-up to propose the user to install qpip, and then qpip would
>  > propose the user to install the dependencies.
>  > 
>  > This is maybe what people consider combersome for users, but when it's
>  > already installed, I think it's the proper way to go: We warn user that
>  > something need to be installed, he agrees or not (just one click!), then
>  > we install it or not.
>  > 
>  > Maybe, we should consider integrate it in the core so we skip the first
>  > step. There is already a plugin dependencies management in QGIS core, so
>  > that's maybe relevant to extend it to what qpip can do.
>  > 
>  > Regards,
>  > Julien
>  > 
>  > 
>  > 
>  > > Hey Joona,
>  > >
>  > > I have looked into qpip, but it is not sufficient. Not only do most dependencies have binaries, but the process also creates a somewhat
>  > > cumbersome installation workflow for non-technical users.
>  > >
>  > > In the end, the problem seems to be that the plugins I am talking about are not really GIS plugins, but rather bigger pieces of software with a
>  > > very significant QGIS component, mostly for visualization purposes, so I must grant that as a large part of the problem.
>  > >
>  > > We will likely explore deploying custom plugin repositories and developing full installers. It's inconvenient for users, but there isn't another
>  > > alternative I can see right now.
>  > >
>  > > Cheers,
>  > > Pedro?
>  > >
>  > > From: Joona Laine <joona.p.laine at gmail.com>
>  > > To: "Pedro Camargo"<c at margo.co>
>  > > Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
>  > > Date: Mon, 25 May 2026 15:47:55 +1000
>  > > Subject: Re: [QGIS-Developer] Security issues with plugins
>  > >
>  > >  Hello Pedro,
>  > >
>  > >  qgis-plugin-dev-tools (https://github.com/nlsfi/qgis-plugin-dev-tools#setup) solves the dependency issue by including the dependencies
>  > >  with the plugin package.
>  > >
>  > >  It can easily handle most of (non-binary) requirements by automatically rewriting the imports of theses vendored dependencies in the
>  > >  build process. 
>  > >  This way it is possible to have multiple plugins using different version of the same requirement without any conflicts.
>  > >  It is also possible to include binary dependencies but there is no operation system specific logic built yet at the moment.
>  > >
>  > >  There is also a tool called qpip (https://github.com/opengisch/qpip) for dependency management, which might be worth checking out.
>  > >
>  > >  Cheers,
>  > >  Joona
>  > >
>  > >  ma 25.5.2026 klo 6.35 Pedro Camargo via QGIS-Developer (qgis-developer at lists.osgeo.org) kirjoitti:
>  > >
>  > >  Hey Nyall,
>  > >
>  > >  I hear you, but let me highlight two points of my original post.
>  > >
>  > >  *        The plugin asks the user whether they want to install the dependencies. 
>  > >  *        The dependencies are installed in the plugin folder and can therefore be removed without causing any lasting damage to the
>  > >  user's QGIS installation.
>  > >
>  > >  Installing additional dependencies in QGIS remains a painful task for less technical users, adding another (somewhat unnecessary)
>  > >  hurdle to adoption.  
>  > >
>  > >  On that note, a fair question could be:  Is there a recommended low-effort (for users) path to install extra dependencies for plugins? 
>  > >
>  > >  If not, is that something being considered for the near future?
>  > >
>  > >  Cheers,
>  > >  Pedro
>  > >
>  > >  From: Nyall Dawson <nyall.dawson at gmail.com>
>  > >  To: "Pedro Camargo"<c at margo.co>
>  > >  Cc: "Qgis Developer"<qgis-developer at lists.osgeo.org>
>  > >  Date: Mon, 25 May 2026 11:12:20 +1000
>  > >  Subject: Re: [QGIS-Developer] Security issues with plugins
>  > >
>  > >  On Mon, 25 May 2026 at 08:27, Pedro Camargo via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>  > >  >
>  > >  > Hello fellow QGISrs,
>  > >  >
>  > >  >
>  > >  >
>  > >  > I maintain a couple of plugins that require a substantial number of extra Python packages (many of which have
>  > >  compiled/binary components). Hence, those plugins install all such requirements in a folder directly inside the plugin itself,
>  > >  keeping it quite clean when the user wants to remove said plugins.
>  > >  >
>  > >  >
>  > >  > I have been doing it this way for many years now, but this weekend I received security alerts that both plugins were taken down
>  > >  due to code that downloads extra dependencies (offending code at
>  > >  qaequilibrae/qaequilibrae/download_extra_packages_class.py at develop ? AequilibraE/qaequilibrae).
>  > >  >
>  > >  > Does anyone have any recommendations on how to proceed?  What is currently the recommended way for plugins to install
>  > >  further dependencies?
>  > >
>  > >  My personal 2c: a plugin should NEVER automatically install dependencies like this. Rather, you should detect missing
>  > >  dependencies, warn the user, and point them to a documentation page directing them how to install the missing libraries on
>  > >  different operating systems.
>  > >
>  > >  I think it's EXTREMELY dangerous for a plugin to assume that it can mess with the user's operating system in this way, as it risks
>  > >  completely breaking their QGIS install or even their wider python environment. I would like to see us explicitly blocking all plugins
>  > >  from the repository that do this in future. ?
>  > >
>  > >  Nyall
>  > >
>  > >  >
>  > >  > Cheers,
>  > >  > Pedro
>  > >  >
>  > >  >
>  > >  >
>  > >  > _______________________________________________
>  > >  > 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
>  > >
>  > > _______________________________________________
>  > > 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
>  > 

-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com

From rhurlin at gwdg.de  Sun May 31 10:58:56 2026
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Sun, 31 May 2026 17:58:56 -0000
Subject: [QGIS-Developer] QGIS 4: PostgreSQL layer properties 'Information
 from provider' is not displayed correctly
Message-ID: <3a1ad503-6378-436e-982b-da54c80a1e90@gwdg.de>

I was unable to attach a screenshot to a GitHub issue. Therefore, I am 
describing the following issue here in the list, as it is difficult to 
describe the error without an image.

In QGIS 4, in released versions up to 4.0.3 as well as in today's devel 
branch, the ?Information from provider? section in the properties of 
PostgreSQL layers is displayed incorrectly. This happens in the browser 
and also with loaded layers.

Instead of the expected information under Privileges or Spatial Index, a 
list of dots is displayed. Each dot in the list contains exactly one 
character. All characters in a list appear to be SQL commands or 
parameters? The attached screenshot shows a section where the display 
error can be seen.

This occurs on Windows 10, 11, and FreeBSD. In QGIS 3, the properties of 
PostgreSQL layers are displayed correctly.

Best regards,
Rainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QGIS4_Qt6_FreeBSD_PostgreSQL_layer_properties.jpg
Type: image/jpeg
Size: 88716 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260531/4b71b4b5/attachment-0001.jpg>