| 27 Sep 2024 |
 autra | In reply to @imincik:matrix.org
I did successful bisecting on qgis once. It took long time but i found the issue. The bisect just finished, it took nearly 48h | 18:06:58 |
| autra | I could have been more clever by checking long-lived branches first, because those would have made a better use of cache.nixos.org, I'm sure. | 18:07:57 |
| autra | The gmt build is broken by 25bc618215a7: libxml2: 2.12.7 → 2.13.2.
The error is (during the build of gmt) :
nix/store/81xsp348yfgmaan9r5055mcdjfw7a8wc-binutils-2.42/bin/ld: /nix/store/hfb55givv2afsz93b705hkjd9y98wqam-libspatialite-5.1.0/lib/libspatialite.so.8: undefined reference to `xmlNanoHTTPCleanup@LIBXML2_2.4.30'
collect2: error: ld returned 1 exit status
It's not the only one having this error (https://github.com/NixOS/nixpkgs/pull/331127 and https://github.com/NixOS/nixpkgs/issues/331121), but I don't know how to apply it to gmt. It does not depend directly from libxml2
| 18:50:17 |
| autra | https://github.com/NixOS/nixpkgs/pull/331166/files same fix | 18:50:37 |
| autra | is there a way to get all the dependencies of a derivation without building it? libxml2 is a dependency of libspatialite, but the fix is already applied... But maybe it draws libxml2 from somewhere else too? | 18:51:33 |
| autra | omg, it's on netcdf. | 19:07:54 |
| autra | ok so everyone seems to have fixed that by using (libxml2.override { enableHttp = true; }). But gmt does not depend directly from it. It depends from libxml2 through libspatialite (the fix is already applied) and through netcdf. | 19:39:51 |
| autra | If I patch netcdf, it works, but is it ok? | 19:40:04 |
| autra | I also did:
(netcdf.override { libxml2 = (libxml2.override { enableHttp = true; }); })
In gmt's build input, but that does not work
| 19:40:42 |
| autra | Ah I need to do that in all-packages, it's probaly too late in buildInputs. | 19:49:10 |
| autra | All right, sorry for the noise, PR time :-) | 19:49:17 |
| 30 Sep 2024 |
 Ivan Mincik (imincik) | autra: thanks for your investigation. Reading your messages now. | 07:30:22 |
| 1 Oct 2024 |
|  -_o joined the room. | 20:59:47 |
| 2 Oct 2024 |
|  Raul Nanclares joined the room. | 14:38:30 |
| 3 Oct 2024 |
| autra | Hi! do we have blockers for 24.11? (I didn't see any but...) | 07:43:27 |
| autra | maybe we want to ship postgis 3.5 before the "no breaking change" | 07:43:54 |
| autra | window though | 07:43:56 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
Hi! do we have blockers for 24.11? (I didn't see any but...) I just wanted to report that we don't have any blockers, but I agree that we should try to get postgis 3.5 to 24.11. | 11:45:08 |
| autra | ok pushing my wip now :-) | 11:59:37 |
| autra | As soon as we think we are ready, we should check the box here: https://github.com/NixOS/nixpkgs/issues/344920 | 13:15:39 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
As soon as we think we are ready, we should check the box here: https://github.com/NixOS/nixpkgs/issues/344920 Yes. | 14:48:30 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
ok pushing my wip now :-) PR looks good. Can I merge now ? | 14:50:44 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
ok pushing my wip now :-) * autra: PR looks good. Can I merge now ? | 14:50:55 |
| Ivan Mincik (imincik) | I think, we should also try to merge
https://github.com/NixOS/nixpkgs/pull/342101
and
https://github.com/NixOS/nixpkgs/pull/344664
| 14:57:21 |
| autra | In reply to @imincik:matrix.org
autra: PR looks good. Can I merge now ? I wanted to take the opportunity to add two little tests in nixos/tests | 15:35:18 |
| 4 Oct 2024 |
| autra | Ivan Mincik (imincik): btw, about the "QGIS: don't build with GRASS by default" issue in the board, what's the rational? (I use it from time to time and I'll be moderately in favor of keeping it by default for the discoverability in the processing pane) | 06:58:23 |
| autra | that being said, a withGrass makes sense. | 07:35:47 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
Ivan Mincik (imincik): btw, about the "QGIS: don't build with GRASS by default" issue in the board, what's the rational? (I use it from time to time and I'll be moderately in favor of keeping it by default for the discoverability in the processing pane) To make a QGIS closure small by default | 08:28:03 |
| Ivan Mincik (imincik) | In reply to @autra:trancart.eu
that being said, a withGrass makes sense. Yes, but we really need to come with a better way of unwrapped package overriding . | 08:28:53 |
| autra | In reply to @imincik:matrix.org
Yes, but we really need to come with a better way of unwrapped package overriding . at the same time, I'd say we can start simple and see after. If we have only 5-10 parameters, just propagating them to the callPackage ./unwrapped {} thing is really ok imo. | 09:21:56 |
