Change:
packageOverrides = self: super: { pyqt5 = super.pyqt5.override { withLocation = true; <ins> # FIX sip and pyqt5_sip compatibility. See: https://github.com/NixOS/nixpkgs/issues/273561 # Remove this fix in NixOS 24.05. pyqt5_sip = python3.pkgs.callPackage ./pyqt5-sip.nix { }; </ins> }; }; };

Discussion:
I ran into a bug in QGIS which I described in an . To summarise, constructing some objects in the embedded Python is not possible as usual, and trying to work around the bug results in a crash. Importantly, this only happens in the current (unstable or 23.11) NixOS build of QGIS, not in the upstream Flatpak or in a 22.05 NixOS build. recent NixOS QGIS build with . Python Console () and run You should get this error: QGIS should crash with SIGSEGV. the same on an older package () or from the Flatpak. The first example should work without errors and the second should throw an error (invalid args). Same as the official Flatpak: no crashes and a success for the first code snippet. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
, thanks for reporting. I confirm that QGIS is crashing on my system as well
, are you able to check which Python version is used in your Flatpak QGIS package ?
Sure, here's :
QGIS Flatpak configuration -
I tried to build QGIS with Python 3.10 and it can be crashed with the same command.
I did some investigation, but for now, I can't see any potential nixpkgs packaging issue related to this problem.
Thanks, I did some digging of my own, and I think it's a problem with SIP. In one of the generated files () I found the generated interop function for the faulty constructor, . It contains a call to with a string "pattern" which defines how arguments should be extracted. Now it's . I looked at both the parser and generator code, and I can't find what the colon should be doing, so given that the crash is in this function's descendant, I think this pattern string is the problem. I'm trying to build QGIS with a different version of SIP, but the latest 6.8.0 . EDIT: SIP 6.8.1 was just released, so I'll try with that.
Thank you very much for debugging . I very much appreciate it and hope it will help us to move forward with this issue.

I immediately expected the problem with sip upgrade, but there is only very small version difference between nixos 23.05 and unstable (6.7.7 -6.7.11). If this is really silent regression which we didn't notice at all, then we pay a big price for not running unit tests ().
Looking at failed tests from , many of them fail on . Like this one
Sadly my build with SIP 6.8.1 crashes just as with 6.7.11. I'm not entirely sure I built it correctly. It might also be a good idea to try downgrading SIP to 6.7.7, but full builds take an hour+ on my computer, so I won't be doing that today. I finally found what the means: is or , so it's a regular flag that's just read by an "ungrepable" process.
Upstream is installing in their testing container. in Ubuntu 22.04 or even in Debian Sid is SIP version 4 . Maybe we should try to build with package. I'll try that now.
To build with , I had to remove from because it was dragging sip 6. Then build failed on . I am now trying to build with patch mentioned in `
didn't help with
I just noticed that the backtrace from the crash contains , not : . I don't know what the difference is actually, but it could be that we have a problem with using different sip packages to build and to run the resulting binary. Running prints , which is in a different package. (Don't mind the version, it's actually 6.8.1, I forgot to update package metadata).
This is most likely the cause. contains its own copy of , the runtime that, among other things, parses arguments. NixOS' version 12.11.0 is old and doesn't support the specifier introduced after sip 6.7.7. The code then popped off an argument, didn't understand the specifier, and skipped it, mangling the parsing state. The issue can be fixed by updating in nixpkgs, but I think it's worth investigating how/why there are two sip versions and how to sync the versions. Should QGIS' own bindings even be using ? I also think upstream should add more runtime checks here.

They version ABIs, but apparently never check them. Also, throwing an error on an unknown arg specifier would have saved us both some hours of debugging.
In latest nixpkgs master:
I can now confirm upgrading fixes the issue. could you make an update PR?
Great thanks once again ! I'll make a PR tomorrow. I am just building QGIS with updated pyqt5sip to version 12.13.0.
, you are very welcome to join if you are interested.
PyQT5_SIP PR created -
, update of was merged to branch and will hopefully appear in master soon. I am not sure what is the best approach to fix QGIS in stable branch. Backporting of 12.13.0 can cause regressions for other packages (or maybe it will fix bunch of packages, we really don't know). What I need before starting some changes in stable branch is to know what are the compatible options. I was trying to find some compatibility matrix between and but I haven't found any information ( is was not very useful). How did you know which versions are compatible ?
Or maybe do it other way around and write some code which will test compatibility. Then we can use it as a package test for both of them.
Checking which is used to build QGIS Flatpak package: in branch 5.15-21.08 (older one) they build sip-6.7.9 with PyQt5sip-12.12.1 in branch 5.15-23.08 (latest one) they build sip-6.8.1 with PyQt5sip-12.13.0 In Nixpkgs we have 23.11: sip 6.7.12 + pyqt5_sip 12.11.0 unstable: sip 6.7.12 + 12.13.0 (after our PR) (EDIT: sip 6.8.0 is now in branch)
Found some in QGIS.
Unfortunately, all sip tests passed with both pyqt5sip 12.13.0 and 12.11.0 .
I'm about as confused as you are, so I sent a message to the , hopefully someone will clarify. My guess is that the version of corresponds to a SIP ABI version.

Right now, the latest is v12.14, but we only have v12.13.0. The latest compatible pair then seem to be SIP v6.7.12 and v12.13.0.
Yes, this makes a sense.
PR for stable branch created
This issue has been mentioned on NixOS Discourse. There might be relevant details there: