| 11 Feb 2024 |
 Ivan Mincik (imincik) | And you don't want to maintain them anymore ? | 18:30:05 |
 das-g | No, of the packages I already maintain or co-maintain explicitly, I'm ready to stay a maintainer. | 18:30:22 |
| Ivan Mincik (imincik) | In reply to @das-g:matrix.org
I'll probably file another pull request to remove myself from teams.geospatial. I've underestimated how many geospatial packages there are in NixPkgs about which I know nothing and thus can't really contribute, yet receive notifications from GitHub. Of course, it is your decision. | 18:31:11 |
| das-g | It's just that through teams.geospatial I'm now indirectly treated as a maintainer of too many packages I don't care about, so the signal-to-noise ratio of my GitHub notifications ("signal" as in stuff I sufficiently understand and is actionable for me) kinda got too low for my taste. | 18:32:58 |
| Ivan Mincik (imincik) | In reply to @das-g:matrix.org
It's just that through teams.geospatial I'm now indirectly treated as a maintainer of too many packages I don't care about, so the signal-to-noise ratio of my GitHub notifications ("signal" as in stuff I sufficiently understand and is actionable for me) kinda got too low for my taste. I am sorry for that. I see you are more after maintenance of OSM software. | 18:36:23 |
| Ivan Mincik (imincik) | What we currently maintain is the list of most important geo software. | 18:37:35 |
| Ivan Mincik (imincik) |
I'll probably file another pull request to remove myself from teams.geospatial.
Would you please do this change in separate PR ? Thanks.
| 18:44:57 |
| das-g | Sure. | 18:46:43 |
| das-g | Should I hold off the current one then, until my removal from the team is merged, so that I'm at no point in the history doubly maintainer of the affected packages? | 18:47:31 |
| Ivan Mincik (imincik) | In reply to @das-g:matrix.org
Should I hold off the current one then, until my removal from the team is merged, so that I'm at no point in the history doubly maintainer of the affected packages? Yes, we should merge your removal from the team . If you are really sure... | 18:48:25 |
| das-g | Or I could change the current one to add the team and remove myself from the individual packages, and than re-add myself when I remove myself from the team. (Though that seems like unnecessary noise in the packages' histories.) | 18:48:53 |
| das-g | Alright, here's my self-removal from the team: https://github.com/NixOS/nixpkgs/pull/288118 | 18:57:23 |
| das-g | In reply to @imincik:matrix.org
I am sorry for that. I see you are more after maintenance of OSM software. No worries. I still think the teams are a good idea. It's just that the scope of the geospatial team is too big for me. I'll still stay in this room to keep up-to-date on what's going on in this field. | 19:00:31 |
| das-g | In reply to @imincik:matrix.org
I am sorry for that. I see you are more after maintenance of OSM software. About OSM software: Yeah, but mostly because some of it was still missing in NixPkgs when I needed it, so I've packaged it if I was able to do so. I do use other geospatial software (such at QGIS), too. | 19:01:12 |
| das-g | In reply to @imincik:matrix.org
What we currently maintain is the list of most important geo software. Is the packages to which I'd like to add the team as a co-maintainer in scope for the geospatial team? I kinda assumed so, but probably not all of them are part of the "most important geo software". | 19:03:45 |
| das-g | In reply to @imincik:matrix.org
What we currently maintain is the list of most important geo software. * Is the packages to which I'd like to add the team as a co-maintainer with https://github.com/NixOS/nixpkgs/pull/288107 in scope for the geospatial team? I kinda assumed so, but probably not all of them are part of the "most important geo software". | 19:04:15 |
| das-g | * Are the packages to which I'd like to add the team as a co-maintainer with https://github.com/NixOS/nixpkgs/pull/288107 in scope for the geospatial team? I kinda assumed so, but probably not all of them are "most important geo software". | 19:12:17 |
| Ivan Mincik (imincik) | In reply to @das-g:matrix.org
Are the packages to which I'd like to add the team as a co-maintainer with https://github.com/NixOS/nixpkgs/pull/288107 in scope for the geospatial team? I kinda assumed so, but probably not all of them are "most important geo software". I would be happy to maintain all geo software, but I am not sure about protozero or ili2c. All OSM tools are OK. | 19:13:29 |
| das-g | protozero is a dependency of osmium and osm2pgsql | 19:14:40 |
| das-g | (and, at least until now, of nothing else in nixpkgs) | 19:15:05 |
| das-g | ili2c is a part of the Interlis ecosystem. While Interlis is a general data modelling language (and collection of data formats both for the model metadata and for the such-modelled data itself), it's focus is on modelling and transferring spatial data, which is also reflected by its slogan/tagline "The GeoLanguage". | 21:28:22 |
 nh2 | I'm at the GeoWeek 2024 currently (my startup benaco.com is exhibiting with a booth), and I just talked with Howard Butler, devleoper of PDAL :)
Greetings to the Nix geospatial community | 22:07:01 |
| Ivan Mincik (imincik) | In reply to @nh2:matrix.org
I'm at the GeoWeek 2024 currently (my startup benaco.com is exhibiting with a booth), and I just talked with Howard Butler, devleoper of PDAL :)
Greetings to the Nix geospatial community Nice to hear from you. Good luck with your exhibition! Greetings to hobu as well. | 22:12:20 |
| 15 Feb 2024 |
|  kenji joined the room. | 19:15:46 |
| 21 Feb 2024 |
 l0b0 | Got a tip from a colleague which might lead to a fix of the missing LERC compression in GDAL. Basically, -DGDAL_USE_INTERNAL_LIBS=OFF means we have to specify all the corresponding variables to include the libraries in other variables. | 01:18:03 |
| l0b0 | In the meantime I'd really appreciate a review of a prep PR which enables devs to run each of the GDAL tests separately. | 01:19:03 |
| l0b0 | * Got a tip from a colleague which might lead to a fix of the missing LERC compression in GDAL. Basically, -DGDAL_USE_INTERNAL_LIBS=OFF means we have to specify all the corresponding variables to include the libraries in other variables. Update: my attempt failed - nix-build -A gdal.passthru.tests.compress-lerc fails. I'd appreciate any tips. | 02:39:10 |
| l0b0 | * Got a tip from a colleague which might lead to a fix of the missing LERC compression in GDAL. Basically, -DGDAL_USE_INTERNAL_LIBS=OFF means we have to specify all the corresponding variables to include the libraries in other variables. Update: my attempt failed based on the build instructions failed - nix-build -A gdal.passthru.tests.compress-lerc says LERC compression is not available. I'd appreciate any tips. | 02:40:27 |
| Ivan Mincik (imincik) | I spent some time on fixing #238882 , but it looked to me as some kind of bug or problem on GDAL side. I was not able to find any problem in our packaging. l0b0 , have you seen it working (is for example Debian package or GDAL docker image working as expected ?) | 15:27:53 |
| l0b0 | In reply to @imincik:matrix.org
I spent some time on fixing #238882 , but it looked to me as some kind of bug or problem on GDAL side. I was not able to find any problem in our packaging. l0b0 , have you seen it working (is for example Debian package or GDAL docker image working as expected ?) I've only ever seen it work with the internal library, such as in this documentation. I guess most people (including distro maintainers) don't care too much about vendoring these libraries, but this video talks about why NixOS maintainers in particular should care. | 19:24:53 |
