From lova at kartoza.com  Fri Oct  3 07:00:00 2025
From: lova at kartoza.com (Lova Andriarimalala)
Date: Fri, 3 Oct 2025 17:00:00 +0300
Subject: [QGIS-Developer] QGIS Full Stack Developer Report from September 08
 to October 03, 2025
Message-ID: <CAMLC-sBTCTufLvk1Qrd0kSZ86R7FVrrVdMfP++ND7dp191WOjg@mail.gmail.com>

Hello everyone,

Please find below some highlights regarding the development and maintenance
of the QGIS Websites for the last two weeks, from September 08 to October
03, 2025 (*Note: I was on leave during the week of September 15*).

*QGIS.org:*

   - Add automated content guidelines
   <https://github.com/qgis/QGIS-Website/pull/727> [New PR]
   - Fix wording for clarity in community guidelines section
   <https://github.com/qgis/QGIS-Website/pull/726> [New PR]
   - Add new user groups <https://github.com/qgis/QGIS-Website/pull/723> [New
   PR]
   - Add Volunteer Contributors list page
   <https://github.com/qgis/QGIS-Website/pull/700> [Updated PR]
   - Use slug when fetching members for more effective updates
   <https://github.com/qgis/QGIS-Website/pull/720> [Deployed]
   - Update patterns paper tests
   <https://github.com/qgis/QGIS-Website/pull/716> [Deployed]
   - Disallow downloads in robot.txt
   <https://github.com/qgis/QGIS-Website/pull/711> [Deployed]
   - Update macOS instructions
   <https://github.com/qgis/QGIS-Website/pull/710> [Deployed]
   - Add Privacy page and update menu structure
   <https://github.com/qgis/QGIS-Website/pull/709> [Deployed]
   - Refactor citation year handling and add yeartag shortcode
   <https://github.com/qgis/QGIS-Website/pull/708> [Deployed]

*QGIS Hub:*

   - Add issue templates
<https://github.com/qgis/QGIS-Hub-Website/pull/107> [New
   PR]
   - Use resend for email sending
   <https://github.com/qgis/QGIS-Hub-Website/pull/106> [Deployed]
   - Add support for <at> alg decorator processing scripts
   <https://github.com/qgis/QGIS-Hub-Website/pull/105> [Deployed]
   - Refactor style handling to support multiple types
   <https://github.com/qgis/QGIS-Hub-Website/pull/104> [Deployed]
   - Contributors commit stats API
   <https://github.com/qgis/QGIS-Hub-Website/pull/103> [Deployed]

*QGIS Feed:*

   - Add issue templates
   <https://github.com/qgis/QGIS-Feed-Website/pull/150> [New PR]
   - Use resend for email sending
   <https://github.com/qgis/QGIS-Feed-Website/pull/148> [New PR]


*QGIS Plugins:*

   - Add support for multiple image attachments in feedback forms
   <https://github.com/qgis/QGIS-Plugins-Website/pull/174> [Draft PR]
   - Use resend for email sending
   <https://github.com/qgis/QGIS-Plugins-Website/pull/173> [Deployed]
   - Fix plugin updates errors
   <https://github.com/qgis/QGIS-Plugins-Website/pull/176> [Deployed]
   - Use resend for email sending
   <https://github.com/qgis/QGIS-Plugins-Website/pull/173> [Deployed]
   - Send plugin upload notifications to a specific group members only
   <https://github.com/qgis/QGIS-Plugins-Website/pull/168> [Deployed]
   - Add a feature for version bulk delete
   <https://github.com/qgis/QGIS-Plugins-Website/pull/167> [Deployed]
   - Block replace approved plugin version
   <https://github.com/qgis/QGIS-Plugins-Website/pull/166> [Deployed]

*QGIS Infrastructure:*

   - Script for automatic floating IP and DNS setup
   - Staging deployment test with Tim

Have a nice weekend,

Lova Andriarimalala


*QGIS Full Stack Developer   *
*T *: +27(0) 87 809 2702          *E *: lova at kartoza.com          *W* :
kartoza.com



*This email and any attachments are confidential and intended solely for
the use of the individual or entity to whom they are addressed. If you *
*have received this email in error, please notify the sender immediately
and delete it from your system. Unauthorised use, disclosure, or copying*
*of the contents is prohibited.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20251003/2f2c7f37/attachment.htm>

From fredrikl at gvc.gu.se  Tue Oct  7 23:58:47 2025
From: fredrikl at gvc.gu.se (Fredrik Lindberg)
Date: Wed, 8 Oct 2025 06:58:47 +0000
Subject: [QGIS-Developer] numpy version 2
Message-ID: <GVYP280MB1211F7D25D23D7170A544DAB85E1A@GVYP280MB1211.SWEP280.PROD.OUTLOOK.COM>

Dear all,
Are there any plans to implement numpy v2 in any near future as 1.26 is becoming rather old at this stage?

best wishes,
Fredrik

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

From gdt at lexort.com  Wed Oct  8 04:54:07 2025
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 08 Oct 2025 07:54:07 -0400
Subject: [QGIS-Developer] numpy version 2
In-Reply-To: <GVYP280MB1211F7D25D23D7170A544DAB85E1A@GVYP280MB1211.SWEP280.PROD.OUTLOOK.COM>
 (Fredrik Lindberg via's message of "Wed, 8 Oct 2025 06:58:47 +0000")
References: <GVYP280MB1211F7D25D23D7170A544DAB85E1A@GVYP280MB1211.SWEP280.PROD.OUTLOOK.COM>
Message-ID: <rmiqzvdobhc.fsf@s1.lexort.com>

Fredrik Lindberg via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> Are there any plans to implement numpy v2 in any near future as 1.26
> is becoming rather old at this stage?

Can you summarize what you found out when reading the build
documentation about whether the qgis master branch can be built against
numpy2, and what happened when you tried to build against it?

>From numpy's release dates it looks like it is only roughly a year since
it has been reasonable to use numpy in production.   It's an interesting
question how the numpy-using community views it, in terms of which is
the first 2.x to be safe to use in production.

From variablestarlight at gmail.com  Wed Oct  8 05:18:24 2025
From: variablestarlight at gmail.com (=?UTF-8?Q?Hern=C3=A1n_De_Angelis?=)
Date: Wed, 8 Oct 2025 14:18:24 +0200
Subject: [QGIS-Developer] numpy version 2
In-Reply-To: <rmiqzvdobhc.fsf@s1.lexort.com>
References: <GVYP280MB1211F7D25D23D7170A544DAB85E1A@GVYP280MB1211.SWEP280.PROD.OUTLOOK.COM>
 <rmiqzvdobhc.fsf@s1.lexort.com>
Message-ID: <CAFSWWyofsSWuVcOOB4sDpF_Hz4-rZo2NktYTz2ROEYuh7Kp15Q@mail.gmail.com>

If it helps, I have been compiling the master branch regularly for sometime
using numpy > 2 (currently 2.3.3, with python 3.13.7 on openSUSE
Tumbleweed) without any apparent issue or malfunction that I have been
aware of. I am not an expert on these matters though, and there may be
issues that have escaped my attention.

On Wed, Oct 8, 2025 at 1:54?PM Greg Troxel via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Fredrik Lindberg via QGIS-Developer <qgis-developer at lists.osgeo.org>
> writes:
>
> > Are there any plans to implement numpy v2 in any near future as 1.26
> > is becoming rather old at this stage?
>
> Can you summarize what you found out when reading the build
> documentation about whether the qgis master branch can be built against
> numpy2, and what happened when you tried to build against it?
>
> From numpy's release dates it looks like it is only roughly a year since
> it has been reasonable to use numpy in production.   It's an interesting
> question how the numpy-using community views it, in terms of which is
> the first 2.x to be safe to use in production.
> _______________________________________________
> 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/20251008/7a2d6ccc/attachment.htm>

From fredrikl at gvc.gu.se  Wed Oct  8 07:18:49 2025
From: fredrikl at gvc.gu.se (Fredrik Lindberg)
Date: Wed, 8 Oct 2025 14:18:49 +0000
Subject: [QGIS-Developer] numpy version 2
In-Reply-To: <rmiqzvdobhc.fsf@s1.lexort.com>
References: <GVYP280MB1211F7D25D23D7170A544DAB85E1A@GVYP280MB1211.SWEP280.PROD.OUTLOOK.COM>
 <rmiqzvdobhc.fsf@s1.lexort.com>
Message-ID: <GVYP280MB121125A8BD55CA5EB492E01985E1A@GVYP280MB1211.SWEP280.PROD.OUTLOOK.COM>

I did not try to build nor have read the documentation, I have only started to experience conflicts in some of my plugins where third-party packages, started to require np>=2...
________________________________
Fr?n: QGIS-Developer <qgis-developer-bounces at lists.osgeo.org> f?r Greg Troxel via QGIS-Developer <qgis-developer at lists.osgeo.org>
Skickat: den 8 oktober 2025 13:54
Till: Fredrik Lindberg via QGIS-Developer <qgis-developer at lists.osgeo.org>
?mne: Re: [QGIS-Developer] numpy version 2

Fredrik Lindberg via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> Are there any plans to implement numpy v2 in any near future as 1.26
> is becoming rather old at this stage?

Can you summarize what you found out when reading the build
documentation about whether the qgis master branch can be built against
numpy2, and what happened when you tried to build against it?

>From numpy's release dates it looks like it is only roughly a year since
it has been reasonable to use numpy in production.   It's an interesting
question how the numpy-using community views it, in terms of which is
the first 2.x to be safe to use in production.
_______________________________________________
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/20251008/93b365cc/attachment.htm>

From maplabs at light42.com  Wed Oct  8 13:58:57 2025
From: maplabs at light42.com (Brian M Hamlin)
Date: Wed, 8 Oct 2025 13:58:57 -0700
Subject: [QGIS-Developer] numpy version 2
In-Reply-To: <rmiqzvdobhc.fsf@s1.lexort.com>
References: <GVYP280MB1211F7D25D23D7170A544DAB85E1A@GVYP280MB1211.SWEP280.PROD.OUTLOOK.COM>
 <rmiqzvdobhc.fsf@s1.lexort.com>
Message-ID: <bd2074fc-1723-5a69-7e76-41a10dd4271c@light42.com>

for the python3 stack (large, complex)? #osgeolive has not made the 
switch to Numpy v2+

 ? https://trac.osgeo.org/osgeolive/wiki/noblenightly57

--Brian M Hamlin??? /? MAPLABS? /? #osgeolive PSC


On 10/8/25 04:54, Greg Troxel via QGIS-Developer wrote:
> Fredrik Lindberg via QGIS-Developer <qgis-developer at lists.osgeo.org>
> writes:
>
>> Are there any plans to implement numpy v2 in any near future as 1.26
>> is becoming rather old at this stage?
> Can you summarize what you found out when reading the build
> documentation about whether the qgis master branch can be built against
> numpy2, and what happened when you tried to build against it?
>
>  From numpy's release dates it looks like it is only roughly a year since
> it has been reasonable to use numpy in production.   It's an interesting
> question how the numpy-using community views it, in terms of which is
> the first 2.x to be safe to use in production.
> _______________________________________________
> 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 dvdkon at konarici.cz  Thu Oct  9 01:29:10 2025
From: dvdkon at konarici.cz (=?UTF-8?B?RGF2aWQgS2/FiGHFmcOtaw==?=)
Date: Thu, 9 Oct 2025 10:29:10 +0200
Subject: [QGIS-Developer] Progress on SIP incremental build grant
Message-ID: <94d95f45-a586-4f85-99fb-b0fb9e2a8579@konarici.cz>

Hi all,
I'd like to share with you a report of the work I did on QEP 338 (SIP 
incremental builds):

My original plan was to build each header file as a separate binding, 
then use SIP from a Python script, overriding a few methods to allow 
building just one binding out of a project.

After a lot of effort, this plan sadly doesn't seem workable. PyQt's 
bindings aren't modularised enough, so building a single binding still 
needs to parse almost all of PyQt. Furthermore, SIP has a multi-stage 
parse-resolve-generate design, but the "parser" does more than just 
parse the code into an AST, not all references are resolved in the 
resolve phase, and imports are currently basically done by textual 
inclusion.

I've tried making the necessary changes to SIP [1] and QGIS [2], but for 
the above reasons, I don't think the performance benefits for 
single-file builds are worth the added complexity and performance 
penalty for clean builds (which look to be over an hour currently).

The good news is that with the knowledge from working on SIP, I've been 
able to improve the performance of regular clean builds, and those 
improvements might soon be merged into SIP itself [3]. I've also made 
some changes on the QGIS side to not rebuild unchanged code generated by 
SIP [4]. With code compilation now taking longer than SIP code 
generation, this effectively gives us incremental builds, just at a 
larger granularity.

David Ko?a??k

[1]: https://github.com/dvdkon/sip/tree/qgis-gb
[2]: https://github.com/dvdkon/QGIS/tree/sip-incremental-build
[3]: https://github.com/Python-SIP/sip/pull/87
[4]: https://github.com/qgis/QGIS/pull/63160

From julien.cabieces at oslandia.com  Thu Oct  9 07:59:36 2025
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Thu, 09 Oct 2025 16:59:36 +0200
Subject: [QGIS-Developer] New QEP: Customized Toolbars and Menus
In-Reply-To: <DAVIIPR68RAY.3P1NZWE55FXVW@oslandia.com> (Jacky Volpes via's
 message of "Wed, 25 Jun 2025 11:38:59 +0200")
References: <DAVIIPR68RAY.3P1NZWE55FXVW@oslandia.com>
Message-ID: <87bjmgw27b.fsf@julienlaptop.home>


Hi list,

I have considerably updated the custom toolbars QEP and you have want to
take a look at it.

As part of this QEP, I propose to remove the "Widgets" customization
part because it's probably never user, completely out of sync and very
fragile. Please let me know if you think otherwise.

Regards,
Julien

> Hi list!
>
> We propose to add a way to create custom toolbars and custom menus to QGIS.
>
> It will allow users to have their favorite tool buttons / menu items
> grouped together in their own toolbars and menus.
>
> See https://github.com/qgis/QGIS-Enhancement-Proposals/pull/343
>
> Best regards

-- 

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

From apasotti at gmail.com  Tue Oct 14 05:59:36 2025
From: apasotti at gmail.com (Alessandro Pasotti)
Date: Tue, 14 Oct 2025 14:59:36 +0200
Subject: [QGIS-Developer] Github actions analysis
Message-ID: <CAL5Q670wm-kY_vW_2jQzt2Zc-_C_jdxMA9+z84EWgaT2M31=4w@mail.gmail.com>

Hi,

During the last PSC meeting we talked briefly about how to solve the
problem that we have with the Github CI limitations, one of the possible
solutions that we discussed was to start migrating part of the CI to
self-hosted runners.

I've just made an attempt to understand the hardware requirements that we
would need and I have collected some statistics from our Github account,
summarized here for the period of the last 30 days:

https://docs.google.com/spreadsheets/d/16-tiSLndm-ISxRFgZcE-Ewytr8cwLj00gdYs1iBsz58/edit?usp=sharing

Considering that the standard public runner on Github runs on a 4 CPU + 16
GB RAM machine intel arch, the rough conclusion is that we would need 4.5
of these machines to handle the actual workload, please note that this a
very rough estimation and does not take into account that we probably have
peaking hours and we'd need more power if we don't want the jobs to sit in
a queue for too long.

Anyway, it's a start.

Another thing to consider is that we could possibly cut some CI workflows
(e.g. mingw64, is that useful?) or move some to a daily cronjob (ogc?).

Any thoughts?


-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20251014/3cb660de/attachment.htm>

From apasotti at gmail.com  Tue Oct 14 06:06:05 2025
From: apasotti at gmail.com (Alessandro Pasotti)
Date: Tue, 14 Oct 2025 15:06:05 +0200
Subject: [QGIS-Developer] Github actions analysis
In-Reply-To: <CAL5Q670wm-kY_vW_2jQzt2Zc-_C_jdxMA9+z84EWgaT2M31=4w@mail.gmail.com>
References: <CAL5Q670wm-kY_vW_2jQzt2Zc-_C_jdxMA9+z84EWgaT2M31=4w@mail.gmail.com>
Message-ID: <CAL5Q672WUzDk5Yw0gd3vR6N9YbDqKoy7btboVuw1cu23N1LoMg@mail.gmail.com>

Sorry, in my previous email I wrote "we would need 4.5 of these machines"
while I meant 3.5 machines.

On Tue, Oct 14, 2025 at 2:59?PM Alessandro Pasotti <apasotti at gmail.com>
wrote:

> Hi,
>
> During the last PSC meeting we talked briefly about how to solve the
> problem that we have with the Github CI limitations, one of the possible
> solutions that we discussed was to start migrating part of the CI to
> self-hosted runners.
>
> I've just made an attempt to understand the hardware requirements that we
> would need and I have collected some statistics from our Github account,
> summarized here for the period of the last 30 days:
>
>
> https://docs.google.com/spreadsheets/d/16-tiSLndm-ISxRFgZcE-Ewytr8cwLj00gdYs1iBsz58/edit?usp=sharing
>
> Considering that the standard public runner on Github runs on a 4 CPU + 16
> GB RAM machine intel arch, the rough conclusion is that we would need 4.5
> of these machines to handle the actual workload, please note that this a
> very rough estimation and does not take into account that we probably have
> peaking hours and we'd need more power if we don't want the jobs to sit in
> a queue for too long.
>
> Anyway, it's a start.
>
> Another thing to consider is that we could possibly cut some CI workflows
> (e.g. mingw64, is that useful?) or move some to a daily cronjob (ogc?).
>
> Any thoughts?
>
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   www.itopen.it
>


-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20251014/a1ddabd5/attachment.htm>

From julien.cabieces at oslandia.com  Tue Oct 14 06:27:22 2025
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Tue, 14 Oct 2025 15:27:22 +0200
Subject: [QGIS-Developer] Github actions analysis
In-Reply-To: <CAL5Q670wm-kY_vW_2jQzt2Zc-_C_jdxMA9+z84EWgaT2M31=4w@mail.gmail.com>
 (Alessandro Pasotti via's message of "Tue, 14 Oct 2025 14:59:36
 +0200")
References: <CAL5Q670wm-kY_vW_2jQzt2Zc-_C_jdxMA9+z84EWgaT2M31=4w@mail.gmail.com>
Message-ID: <87bjm9txz9.fsf@julienlaptop.home>


Hi,

Thank you for this work

> Considering that the standard public runner on Github runs on a 4 CPU + 16 GB RAM machine intel arch, the rough conclusion is that we would
> need 4.5

Isn't it 3.5 instead ? That's the number you get in the table

Assuming that we would have a better control on these machine, maybe we
could have more disk space and so maybe more build cache that would
speed up the build time. It could also reduce the time to pull some
resource elsewhere (docker, oracle/hana binary...).

It's highly hypothetical, I'm just wondering.

Regards,
Julien


> Hi, 
>
> During the last PSC meeting we talked briefly about how to solve the problem that we have with the Github CI limitations, one of the possible
> solutions that we discussed was to start migrating part of the CI to self-hosted runners.
>
> I've just made an attempt to understand the hardware requirements that we would need and I have collected some statistics from our Github
> account, summarized here for the period of the last 30 days:
>
> https://docs.google.com/spreadsheets/d/16-tiSLndm-ISxRFgZcE-Ewytr8cwLj00gdYs1iBsz58/edit?usp=sharing
>
> Considering that the standard public runner on Github runs on a 4 CPU + 16 GB RAM machine intel arch, the rough conclusion is that we would
> need 4.5 of these machines to handle the actual workload, please note that this a very rough estimation and does not take into account that we
> probably have peaking hours and we'd need more power if we don't want the jobs to sit in a queue for too long.
>
> Anyway, it's a start. 
>
> Another thing to consider is that we could possibly cut some CI workflows (e.g. mingw64, is that useful?) or move some to a daily cronjob
> (ogc?).
>
> Any thoughts?

-- 

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

From gdt at lexort.com  Tue Oct 14 06:39:31 2025
From: gdt at lexort.com (Greg Troxel)
Date: Tue, 14 Oct 2025 09:39:31 -0400
Subject: [QGIS-Developer] Github actions analysis
In-Reply-To: <CAL5Q672WUzDk5Yw0gd3vR6N9YbDqKoy7btboVuw1cu23N1LoMg@mail.gmail.com>
 (Alessandro Pasotti via's message of "Tue, 14 Oct 2025 15:06:05
 +0200")
References: <CAL5Q670wm-kY_vW_2jQzt2Zc-_C_jdxMA9+z84EWgaT2M31=4w@mail.gmail.com>
 <CAL5Q672WUzDk5Yw0gd3vR6N9YbDqKoy7btboVuw1cu23N1LoMg@mail.gmail.com>
Message-ID: <rmi8qhdeh64.fsf@s1.lexort.com>

(psc dropped because it will bounce)

As part of this, I think it would be good to consider how things might
be different after a move from github to either codeberg or self-hosted
forgejo.  I don't mean to really design that, just a background thought
of "if we (qgis.org) buy this hardware, and we later move, will we wish
we had done something different, or will we just need more, and this
will all be entirely usable, so it's fine".  I suspect it really is
fine.

16 GB sounds like low RAM for a CI machine for qgis.   I would want to
make sure it's expandable to at least 64G, and would start a bit higher.

From matthias at opengis.ch  Tue Oct 14 13:09:54 2025
From: matthias at opengis.ch (Matthias Kuhn)
Date: Tue, 14 Oct 2025 22:09:54 +0200
Subject: [QGIS-Developer] Github actions analysis
In-Reply-To: <rmi8qhdeh64.fsf@s1.lexort.com>
References: <CAL5Q670wm-kY_vW_2jQzt2Zc-_C_jdxMA9+z84EWgaT2M31=4w@mail.gmail.com>
 <CAL5Q672WUzDk5Yw0gd3vR6N9YbDqKoy7btboVuw1cu23N1LoMg@mail.gmail.com>
 <rmi8qhdeh64.fsf@s1.lexort.com>
Message-ID: <CAC7zN96v6deDw0obvQVqWvNUwctu6c9KC8jTQTV6M6+mnTrwog@mail.gmail.com>

According to my understanding we don't have any pressure at the moment to
move the build machines themselves, "just" to find a solution for the cache
eviction.
We could also use some cheap S3 storage as a drop in replacement with the
risk that this is not as fast as the current github cache, but this would
be easier to do than to deploy our own runners.

... however, if we want to move to self hosted runners, a few thoughts:

 - We will need multiple architectures (I assume at least windows x64,
linux x64, macos arm64)
 - We will need to install the required dependencies (build tools etc) and
manage the system images. I guess on linux that's straightforward with
docker, not sure how this should be done on other platforms (some VMs?)
 - We will need to do the required system administration and maintenance

For the vcpkg builds, I would appreciate having our own runners, as it
would make the operating system and build tool updates more predictable.
Right now, this happens every few weeks when github rolls out new runner
images. Every time this happens all dependencies are rebuilt which takes a
few hours (more than 6 hours which is the github runner limit). Such full
rebuilds could be reduced.

If we provision our own runners we should probably also get stronger ones
than the free ones from github.

Cheers
Matthias

On Tue, Oct 14, 2025 at 3:39?PM Greg Troxel via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> (psc dropped because it will bounce)
>
> As part of this, I think it would be good to consider how things might
> be different after a move from github to either codeberg or self-hosted
> forgejo.  I don't mean to really design that, just a background thought
> of "if we (qgis.org) buy this hardware, and we later move, will we wish
> we had done something different, or will we just need more, and this
> will all be entirely usable, so it's fine".  I suspect it really is
> fine.
>
> 16 GB sounds like low RAM for a CI machine for qgis.   I would want to
> make sure it's expandable to at least 64G, and would start a bit higher.
> _______________________________________________
> 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/20251014/3096f811/attachment-0001.htm>

From r.nijssen at terglobo.nl  Thu Oct 16 04:22:48 2025
From: r.nijssen at terglobo.nl (Raymond Nijssen)
Date: Thu, 16 Oct 2025 13:22:48 +0200
Subject: [QGIS-Developer] Execute SQL tool
Message-ID: <9a8dc0e5-bf9f-4a1d-8538-13b2ff7d5d47@terglobo.nl>

Dear devs,

Lately I've been working with the Execute SQL tool on gpkg database 
files, cause I'm trying to switch from the DB Manager to the QGIS native 
tool. I was told the DB Manager is going to be deprecated in the near 
future. Is that the goal?
I'm wondering if other people are using the 'Execute SQL' tool as well, 
as I'm not really satisfied with the current functionality and I cannot 
find any complains in the mailing list or github issues.

Some problems I encounter:
* The result table is (randomly?) not showing the FID or other PK 
columns, nor the geometry column. But those are often important while 
writing SQL queries.
* Loading the QueryLayer always creates a multigeometry layer not 
showing anything on the map. (Btw I think QGIS should be able to render 
multigeometries, or at least to set a 'point', 'line' or 'polygon' style 
to the multigeometry layer to force it rendering that type.)
* The cursor somehow jumps randomly to other lines when (re)focusing on 
the SQL S
* The clear button works *very* well, when you accidentally press it you 
loose the entire query without warning and ctrl-Z won't bring it back.
* The error widget is large and leaving only a few lines of the SQL 
editor to find an fix my error. The splitter between them does not show 
the handle for resizing the widgets.

If developers are interested in fixing this, please let me know. I'm 
happy to help and test and I can also try finding some funding for this.

For me, a more productive SQL tool in QGIS would be:
* In a dockable panel
* Connected to one or more layers that update every time I execute my 
SQL (like the map in DBeaver)

QGIS could be the best geo SQL editor in the world!

There are current issues:
https://github.com/qgis/QGIS/issues?q=is%3Aissue%20state%3Aopen%20%27execute%20sql%27

Should I add all mine?

Kind regards,
Raymond