Hello,
Currently nixpkgs' gdal is missing zstd support. It can be fixed by adding zstd to buildInputs of libtiff:

gdal = pkgs.gdal.override {
  libtiff = pkgs.libtiff.overrideAttrs (attrs: {
    buildInputs = (attrs.buildInputs or []) ++ [pkgs.zstd];
  });
};

(tested with gdalinfo, gdal 3.8.5)

Should I create a PR?

In reply to @kidanger:kidanger.net

Hello,
Currently nixpkgs' gdal is missing zstd support. It can be fixed by adding zstd to buildInputs of libtiff:

gdal = pkgs.gdal.override {
  libtiff = pkgs.libtiff.overrideAttrs (attrs: {
    buildInputs = (attrs.buildInputs or []) ++ [pkgs.zstd];
  });
};

(tested with gdalinfo, gdal 3.8.5)

Should I create a PR?

In reply to @kidanger:kidanger.net
done, https://github.com/NixOS/nixpkgs/pull/311922

In reply to @imincik:matrix.org
Ah, great. Can I add it to nixpkgs ?

In reply to @sikmir:matrix.org
Here it is https://github.com/NixOS/nixpkgs/pull/312708, welcome to review)

In reply to @imincik:matrix.org
Trivial to review QGIS version bump - https://github.com/NixOS/nixpkgs/pull/313097

Hi guys, just wondering what you consider an appropriate level of PR review for bot-generated patch releases like libgeotiff: 1.7.1 -> 1.7.2. Some things to consider:

• Anybody doing a review has finite time, and want to do the best possible job in that finite time.
• Somewhere between 11 and 100 packages rely on this one, as detected by ofborg. So the impact of a broken package isn't tiny.
• The package passthru tests are run automatically, but it's hard to gauge at a glance whether those are as complete as they should be, because it's not like we report some kind of coverage front and centre.
• I don't think NixOS tests are typically linked to the package passthru tests, so it's non-trivial to figure out whether any NixOS tests should be run for a particular PR. Do you have any tricks/heuristics for figuring out which tests to run, better than rg libgeotiff nixos/tests (which won't detect tests of packages which depend on libgeotiff)?

Hi guys, just wondering what you consider an appropriate level of PR review for bot-generated patch releases like libgeotiff: 1.7.1 -> 1.7.2. Some things to consider:

• Anybody doing a review has finite time, and want to do the best possible job in that finite time.
• Somewhere between 11 and 100 packages rely on this one, as detected by ofborg. So the impact of a broken package isn't tiny.
• The package passthru tests are run automatically, but it's hard to gauge at a glance whether those are as complete as they should be, because it's not like we report some kind of coverage front and centre.
• I don't think NixOS tests are typically linked to the package passthru tests, so it's non-trivial to figure out whether any NixOS tests should be run for a particular PR. Do you have any tricks/heuristics for figuring out which tests to run, better than rg libgeotiff nixos/tests (which won't detect tests of packages which depend on libgeotiff)?
• If a rubber stamp of "the build passes" is considered sufficient, why don't we automate the merging of such PRs?

Hi guys, just wondering what you consider an appropriate level of PR review for bot-generated patch releases like libgeotiff: 1.7.1 -> 1.7.2. Some things to consider:

• Anybody doing a review has finite time, and want to do the best possible job in that finite time.
• Somewhere between 11 and 100 packages rely on this one, as detected by ofborg. So the impact of a broken package isn't tiny.
• The package passthru tests are run automatically, but it's hard to gauge at a glance whether those are as complete as they should be, because it's not like we report some kind of coverage front and centre.
• I don't think NixOS tests are typically linked to the package passthru tests, so it's non-trivial to figure out whether any NixOS tests should be run for a particular PR. Do you have any tricks/heuristics for figuring out which tests to run, better than rg libgeotiff nixos/tests (which won't detect tests of packages which depend on libgeotiff)?
• If a rubber stamp of "the build passes" is considered sufficient, why don't we automate the merging of such PRs? Then people could spend their time reviewing actually interesting PRs, and we might get more ROI on review time.