"platforms.gnu" has been linux-only since at least 17.03:
$ nix eval -f channel:nixos-17.03 lib.platforms.gnu
[ "i686-linux" "x86_64-linux" "armv5tel-linux" "armv6l-linux" "armv7l-linux" "aarch64-linux" "mips64el-linux" ]
Unlike platforms.linux, platforms.gnu indicates "must use glibc"
which for the most part is not intended.
Replacing platforms.gnu with platforms.linux would be the same "today"
but let's err on preserving existing behavior and be optimistic
about platforms these packages work on.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/goxel/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/af30rki4lvc9cinx3nxq1nqdnfgi6g1b-goxel-0.8.0/bin/goxel --help’ got 0 exit code
- ran ‘/nix/store/af30rki4lvc9cinx3nxq1nqdnfgi6g1b-goxel-0.8.0/bin/goxel -V’ and found version 0.8.0
- ran ‘/nix/store/af30rki4lvc9cinx3nxq1nqdnfgi6g1b-goxel-0.8.0/bin/goxel --version’ and found version 0.8.0
- ran ‘/nix/store/af30rki4lvc9cinx3nxq1nqdnfgi6g1b-goxel-0.8.0/bin/.goxel-wrapped --help’ got 0 exit code
- ran ‘/nix/store/af30rki4lvc9cinx3nxq1nqdnfgi6g1b-goxel-0.8.0/bin/.goxel-wrapped -V’ and found version 0.8.0
- ran ‘/nix/store/af30rki4lvc9cinx3nxq1nqdnfgi6g1b-goxel-0.8.0/bin/.goxel-wrapped --version’ and found version 0.8.0
- found 0.8.0 with grep in /nix/store/af30rki4lvc9cinx3nxq1nqdnfgi6g1b-goxel-0.8.0
- directory tree listing: https://gist.github.com/ee8a96a0b785c0293e1e477b693c483b
This should not be needed because they are using `#!/usr/bin/env python` as the shebang and in fact it will break inkscape.x86_64-darwin.
https://hydra.nixos.org/build/73283875/
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/darktable/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/darktable-cltest help’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/darktable-cmstest -h’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/darktable-cmstest --help’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/darktable-cmstest help’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/.darktable-cmstest-wrapped -h’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/.darktable-cmstest-wrapped --help’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/.darktable-cmstest-wrapped help’ got 0 exit code
- found 2.4.3 with grep in /nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3
- directory tree listing: https://gist.github.com/70f09e7ec3ef4b1bba88d54f066cf9df
The first problem that was introduced in a276d5160c
was a linking error:
ld: cannot find -licui18n
ld: cannot find -licuuc
ld: cannot find -licudata
So I added icu to the buildInputs.
The second problem was that the interpreter wasn't patched in
share/filters, apparently this is only needed when building with
autotools:
make[3]: Entering directory '/build/inkscape-0.92.3/share/filters'
./i18n.py ./filters.svg > ./filters.svg.h
./i18n.py: /usr/bin/env: bad interpreter: No such file or directory
A similar error also occurs for share/palettes, share/patterns,
share/symbols and share/templates, so I added patching the interpreter
there as well.
Switching to autotools in Inkscape is a very bad idea, because upstream
currently still has their own autotools files in the 0.92.x tree but
master already has them removed, see this commit:
e471a664f9
However for the sake of trying to not break Inkscape on Darwin again,
I tried to keep the fixes minimal and not went back to CMake.
I did however mark the stuff that's unneeded for CMake, so that we can
avoid forgetting to remove that crap once we get back to CMake.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @matthewbauer
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/jpegoptim/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/c0w9l7rcn6kx098z11nx3x5q53dvcvmd-jpegoptim-1.4.6/bin/jpegoptim -h’ got 0 exit code
- ran ‘/nix/store/c0w9l7rcn6kx098z11nx3x5q53dvcvmd-jpegoptim-1.4.6/bin/jpegoptim --help’ got 0 exit code
- ran ‘/nix/store/c0w9l7rcn6kx098z11nx3x5q53dvcvmd-jpegoptim-1.4.6/bin/jpegoptim help’ got 0 exit code
- found 1.4.6 with grep in /nix/store/c0w9l7rcn6kx098z11nx3x5q53dvcvmd-jpegoptim-1.4.6
- directory tree listing: https://gist.github.com/ccc6411a2aca02d1769831b9c561f6b4
However, none of the exporters I tried actually _worked_, but now
shutter at least returns an error to the user (pop-up UI element)
instead of silently hanging and only leaving messages on stdout/stderr
about the missing deps.
AFAICS, this changes the failure of Screenshot->Export functionality
from a packaging bug to an application bug (upstream).
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/pqiv/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/1a0aav46qsmi791vj57cn12hlzsra59l-pqiv-2.10.3/bin/pqiv -h’ got 0 exit code
- ran ‘/nix/store/1a0aav46qsmi791vj57cn12hlzsra59l-pqiv-2.10.3/bin/pqiv --help’ got 0 exit code
- found 2.10.3 with grep in /nix/store/1a0aav46qsmi791vj57cn12hlzsra59l-pqiv-2.10.3
- directory tree listing: https://gist.github.com/bbde9f259adf44f69b8dfc44689b1e49
