QGIS 3x3 on NetBSD 10/11 + PostgreSQL 14/16/18

 

Started making QGIS version 3.44.8 early June 2026 on NetBSD processors

jump ahead:

$ ps auxww | head -2

USER        PID %CPU %MEM      VSZ    RSS TTY    STAT STARTED     TIME COMMAND

root      24310 93.3  1.1   427668 355252 pts/6  O+   12:18AM  0:02.14 /usr/pkg/gcc12/libexec/gcc/x86_64--netbsd/12.4.0/cc1plus -quiet -I /usr/pkgsrc/wip/qgis/work/QGIS-final-4_0_3/cmake-pkgsrc-build/src/core/qgis_core_autogen/include

Wed Jun 10 00:25:37 UTC 2026

$ TZ=EST date

Tue Jun  9 19:25:45 EST 2026

=> Checking file-check results for qgis-3.44.8

=> Creating binary package /usr/pkgsrc/geography/qgis/work/.packages/qgis-3.44.8.tgz

/// pkg_delete postgresql18-client qgis-3.44.8  py313-psycopg2-2.9.11

$ pkgin  show-deps "qgis" | grep -i client

        postgresql16-client>=16.0nb1

https://pkgsrc.se/wip/qgis

Version history: (Expand)

    (2026-06-02) Updated to version: qgis-4.0.3

    (2026-05-10) Updated to version: qgis-4.0.2.18

    (2026-03-09) Updated to version: qgis-4.0.0.0

    (2026-02-22) Updated to version: qgis-3.99.3

    (2026-02-21) Updated to version: qgis-3.99.2

FREEBSD ~~~

foobar:/etc # pkg search qgis

qgis-3.44.11                   Free and Open Source Geographic Information System

qgis-ltr-3.40.15_1             Free and Open Source Geographic Information System

something bollixed. Back to NetBSD.

~~~

amd64-12-core

$ ls -ltr /usr/pkgsrc/packages/All/qg*

-rw-r--r--  1 root  wheel  123201876 Jun  9 17:15 /usr/pkgsrc/packages/All/qgis-3.44.8.tgz

-rw-r--r--  2 root  wheel  124614138 Jun 26 16:10 /usr/pkgsrc/packages/All/qgis-3.44.11.tgz

-rw-r--r--  2 root  wheel  127333035 Jul 13 11:34 /usr/pkgsrc/packages/All/qgis-4.0.3.tgz

-rw-r--r--  2 root  wheel  131910253 Jul 15 23:27 /usr/pkgsrc/packages/All/qgis-4.2.0.tgz

amd64-4-core

5.3$ ls -l /root/pkg-local/qg*

-rw-r--r--  1 root  wheel  127333035 Jul 13 20:02 /root/pkg-local/qgis-4.0.3.tgz

amd64-2-core

[     1.000004] cpu0 at mainbus0 apid 0

[     1.000004] cpu0: Use lfence to serialize rdtsc

[     1.000004] cpu0: Intel(R) Core(TM)2 Duo CPU     L9400  @ 1.86GHz, id 0x1067a

[     1.000004] cpu0: node 0, package 0, core 0, smt 0

[     1.000004] cpu1 at mainbus0 apid 1

[     1.000004] cpu1: Intel(R) Core(TM)2 Duo CPU     L9400  @ 1.86GHz, id 0x1067a

[     1.000004] cpu1: node 0, package 0, core 1, smt 0

[     1.000004] acpi0 at mainbus0: Intel ACPICA 20221020

2 core had faults, see:

https://chaos.social/@jspath55/116834413083346711

old processor no numpy for you

RuntimeError: NumPy was built with baseline optimizations:
(X86_V2) but your machine doesn't support:
(X86_V2).

Pictures and exhibitions

Kept track of long compile times (~18 hours) on the slowest machine, as well as faster, looking at CPU temperature and process load (distributed across 1 or many "cores").

[

mastodon cc me

https://assets.chaos.social/media_attachments/files/116/846/959/384/561/931/original/96c70f8d89d6e49f.png

Go Speed Racer Go!

Pre 3-way build side quest:

Initial launch 4.0.3 June 2026

-rw-r--r--  1 jim  jim 20978 Jun 10 12:46 GIS/spots-rooms-q4.qgz

Side quest:

QGIS 3.44 on the machine I chose did not build, so the check with PG SQL 14 was inadequate. I changed the SQL version on that machine to 18, and it runs with the broken CPU message disabling various plugins (yet to be found).

This is the override of the database version when building from source, not installing pre-fabs.

$ pwd

/usr/pkgsrc/mk

$ diff pg*

28,30c28

< # PGSQL_VERSION_DEFAULT?=             16

< # Fri Jun 26 04:32:43 UTC 2026

< PGSQL_VERSION_DEFAULT?=               18

---

> PGSQL_VERSION_DEFAULT?=               16

Screengrab needs to be built from scratch; what I previously did with an X capture app has fallen into disrepair. At least xli still works.

$ ls -l `which qgis`

-rwxr-xr-x  1 root  wheel     390320 Jul  3 12:43 /usr/pkg/bin/qgis

-rw-r--r--  1 root  wheel  124615383 Jul  3 12:45 ./pkg-local/qgis-3.44.11.tgz

$ psql --version

psql (PostgreSQL) 18.4

Post 3-way build side quest of 3x3, going to 4:

Back to the fast machine and the newest (l+g). The work-in-progress version went from 4.0.3 to 4.2.0. Wow, quick change!

Build time ~8 hours with or without fumbles. Needs to be redone with a clean slate and only 2026Q4 pkgsrc to get things level. But it starts and connects to databases as it should.

$ time qgis --version

QGIS 4.2.0-Belém do Pará 'Belém do Pará' (exported)

real    0m2.522s

user    0m2.458s

sys     0m0.039s

Quick duck back to 3.44.11

Comparison table of the 12-core with 4.2.0 and the 2-core with 3.44.11.

Sidebar issue with Python caused the active plugins to be empty on the 2-core, but otherwise they are pretty much the same beyond QGIS itself and the Qt version going from 5 to 6.

Neither system shows a value for SFCGAL or GeographicLib. Not sure what impact that has.

Working on a list of projects for QGIS 4.2, including waypoints of Historic Trails, paths in the woods, and geocaching at the Bengies Drive-In Theatre.

NetBSD 11 RC3 heat, RC4, and more

The last post was about NetBSD 11, Release Candidate 3. Meanwhile, RC4 was just announced, so this write-up is mainly about testing RC3, with a little RC4 overlap as I upgraded several machines this week.

CPU metrics during User Testing

CPU temperature pattern, where I scheduled the automated test framework to run twice per day on a Raspberry Pi 3 (aarch64).

Now, running processes; the test cycles kick off a couple at a time. The spikes line up with heat generation, unsurprisingly.

Another Zabbix chart for a 48 hour period showing 1 minute average per core. Spikes above 0.5 are rare, and not always aligned in a test "burst", presumably due to the Zabbix data collection cycle where short duration events might be missed.

Interrupts per second. Not much above normal background load other than one obvious spike per test run. Might be interesting to drill down to the specific timeframe and see what tests were running.

Context switches per second, with occasional spikes. Some correspond to other metrics, some not. Closest match is interrupts.

 Test run failures

As with prior ATF runs, the errors differ from architecture to architecture. The one-core Raspberry Pi0W had the most faults, while the 4-core Pi3 had the least.

grep "failed test cases" tests-*txt | grep -v expected |  awk '{print $2}' | sort -n | uniq -c
   1 4
   4 5
   8 6
   5 7
  13 8
  11 9
   5 10
   3 11
   1 12
   1 13

Above is for an AMD64, which being the fastest of the systems tested, has more runs in a day/week. I did scatter plots to show the variations.

AMD64:

i386:

Pi0W:

Pi3:

These charts are not the standard distribution bell curve, but close, where the number of errors must be zero or a positive number. The variation in errors from one run to the next means the next analytical step is measuring frequencies of specific test failures

Doesn't look like any one test fails every time for this machine:

net/npf/t_npf:npf_guid, usr.sbin/tcpdump/t_tcpdump:promiscuous, fs/tmpfs/t_vnode_leak:main, modules/t_x86_pte:svs_g_bit_set, crypto/libcrypto/t_libcrypto:threads

net/carp/t_basic:carp_handover_ipv6_halt_nocarpdevip, net/npf/t_npf:npf_guid, fs/tmpfs/t_vnode_leak:main, fs/vfs/t_renamerace:puffs_renamerace_cycle, modules/t_x86_pte:svs_g_bit_set, crypto/libcrypto/t_libcrypto:threads

net/net/t_unix:sockaddr_un_fstat, net/carp/t_basic:carp_handover_ipv6_halt_nocarpdevip, net/ndp/t_ndp:ndp_cache_expiration, net/npf/t_npf:npf_guid, fs/tmpfs/t_vnode_leak:main, crypto/libcrypto/t_libcrypto:threads

net/carp/t_basic:carp_handover_ipv6_halt_nocarpdevip, net/carp/t_basic:carp_handover_ipv6_ifdown_nocarpdevip, net/npf/t_npf:npf_guid, fs/tmpfs/t_vnode_leak:main, fs/vfs/t_renamerace:msdosfs_renamerace, fs/vfs/t_renamerace:puffs_renamerace_cycle, modules/t_x86_pte:svs_g_bit_set, crypto/libcrypto/t_libcrypto:threads

net/carp/t_basic:carp_handover_ipv6_ifdown_nocarpdevip, net/ndp/t_ndp:ndp_cache_expiration, net/npf/t_npf:npf_guid, fs/tmpfs/t_vnode_leak:main, fs/vfs/t_renamerace:puffs_renamerace_cycle, crypto/libcrypto/t_libcrypto:threads

$ sort  /tmp/ers | uniq -c
   5 crypto/libcrypto/t_libcrypto:threads
   5 fs/tmpfs/t_vnode_leak:main
   1 fs/vfs/t_renamerace:msdosfs_renamerace
   3 fs/vfs/t_renamerace:puffs_renamerace_cycle
   3 modules/t_x86_pte:svs_g_bit_set
   3 net/carp/t_basic:carp_handover_ipv6_halt_nocarpdevip
   2 net/carp/t_basic:carp_handover_ipv6_ifdown_nocarpdevip
   2 net/ndp/t_ndp:ndp_cache_expiration
   1 net/net/t_unix:sockaddr_un_fstat
   5 net/npf/t_npf:npf_guid
   1 usr.sbin/tcpdump/t_tcpdump:promiscuous

NetBSD 11 RC3 upgrade foibles

 I like this peaking pattern, particularly since it stopped. Looping test case, repeated twice maybe?

Then, closer scrutiny shows the major test sections as cron restarts them daily. Faster systems I'd schedule more per day. This might squeak in 2 a day on the Pi 0. Maybe.

48 hours - 1 CPU, 2 test cycles

The upgrade process from 11.0 RC2 to RC3 was more complicated on the Pi 0W than on the 3 or 4, where the kernel resides in the root directory and can be replaced during sysupgrade or another method. For the 0w, the kernel and supporting files are in a boot filesystem and aren't replaced by the upgrade. I have used different ways to put the newer files into place; this time I installed a fresh image to another SD card, then carted over the necessary files under /boot.

$ ls -l /boot/
total 19320
-rwxr-xr-x  1 root  wheel     1594 Apr  4 10:08 LICENCE.broadcom
drwxr-xr-x  1 root  wheel     1024 Mar 10 15:48 System Volume Information
-rwxr-xr-x  1 root  wheel    52476 Apr  4 10:08 bootcode.bin
-rwxr-xr-x  1 root  wheel      115 Apr  4 10:08 cmdline.txt
-rwxr-xr-x  1 root  wheel      382 Apr  4 10:08 config.txt
drwxr-xr-x  1 root  wheel     2048 Mar  4 21:02 dtb
-rwxr-xr-x  1 root  wheel     7269 Apr  4 10:08 fixup.dat
-rwxr-xr-x  1 root  wheel     3180 Apr  4 10:08 fixup_cd.dat
-rwxr-xr-x  1 root  wheel  8055184 Apr  4 10:08 kernel.img
-rwxr-xr-x  1 root  wheel  7865424 Apr  4 10:08 kernel7.img
-rwxr-xr-x  1 root  wheel  2979264 Apr  4 10:08 start.elf
-rwxr-xr-x  1 root  wheel   808060 Apr  4 10:08 start_cd.elf

I could have "cherry picked" which dtb driver files to replace, but chose the slower copy-them-all. In prior upgrades, space was at a premium on the boot device. This iteration is not tight.

$ df /boot

Filesystem      1K-blocks         Used        Avail %Cap Mounted on
/dev/ld0e           81269        19655        61614  25% /boot

$ uname -a

NetBSD rpi 11.0_RC3 NetBSD 11.0_RC3 (RPI) #0: Sat Apr  4 06:08:56 UTC 2026  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/RPI evbarm

An issue from the RC2 tests hasn't reappeared on RC3, where a run triggered a runaway core or something, shown on the first image above. I have an open PR though it seems the report isn't a surprise.

The Pi3 and amd64 upgrades to RC3 worked well, and the former has the lowest test failure rate of the architectures I have available. The i386 port also has few failures, a couple of them caused by me using the CD image for an upgrade instead of using the sysupgrade package. Mainly because I wanted to test a different mode.

To fit the install code into 700MB or less, the NetBSD developers seem to have left out a couple of the test sets. I noticed the messages on running the upgrade, as they were unusual in my experience.

As I half-expected issues, I went ahead with the install without the 2 distribution sets. Eventually the test suite results flagged the glitch.

Failed test cases:

dev/audio/t_audio:AUDIO_SETINFO_pause_WRONLY_2, dev/audio/t_audio:open_audioctl_RDWR, lib/libutil/t_snprintb:snprintb, net/carp/t_basic:carp_handover_ipv6_halt_nocarpdevip, net/if_wg/t_misc:wg_rekey, net/npf/t_npf:npf_guid, usr.bin/mtree/t_sets:set_base, usr.bin/mtree/t_sets:set_xbase, fs/vfs/t_renamerace:ext2fs_renamerace_cycle

The list [] to be installed is determined by the optional arguments
passed to the command or, if none, from the value of the SETS
configuration variable.

< SETS=AUTO  # Guess from /etc/mtree/set.* files.

> SETS="tests xbase"

Finally downloaded the entire set (apparently ${SETS} applies to the install, *not* the fetch).

After effects (success in reinstalling missing sets):

Failed test cases:

net/carp/t_basic:carp_handover_ipv6_halt_nocarpdevip, net/carp/t_basic:carp_handover_ipv6_ifdown_nocarpdevip, net/if_wg/t_misc:wg_rekey, net/npf/t_npf:npf_guid, crypto/opencrypto/t_opencrypto:ioctl

RC3 info:

$ uname -a

NetBSD neti386 11.0_RC3 NetBSD 11.0_RC3 (GENERIC) #0: Sat Apr  4 06:08:56 UTC 2026  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC i386 i386 Intel 686-class NetBSD

I should summarize the test suite results across the several machine types I've installed 11.0 RC3 on, and analyze for frequency given many tests do not pass or fail 100% of the time. I had coined the term Heisenbergars for those maybe maybe not cases.