Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/feh/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/n3q1mfdip3l49wx7dh293pwrxqhlrqgd-feh-2.26.1/bin/feh -h’ got 0 exit code
- ran ‘/nix/store/n3q1mfdip3l49wx7dh293pwrxqhlrqgd-feh-2.26.1/bin/feh --help’ got 0 exit code
- ran ‘/nix/store/n3q1mfdip3l49wx7dh293pwrxqhlrqgd-feh-2.26.1/bin/.feh-wrapped -h’ got 0 exit code
- ran ‘/nix/store/n3q1mfdip3l49wx7dh293pwrxqhlrqgd-feh-2.26.1/bin/.feh-wrapped --help’ got 0 exit code
- found 2.26.1 with grep in /nix/store/n3q1mfdip3l49wx7dh293pwrxqhlrqgd-feh-2.26.1
- directory tree listing: https://gist.github.com/1e8258220f00de69ea28c57fffe352aa
- du listing: https://gist.github.com/65e35fd7395eca9058de10721f96b7d3
When opening `shutter` it adds an indicator icon to the status bar.
However this doesn't happen (and an ugly default icon will be used) if
`shutter` can't find the `hicolor-icon-theme`. In such a case a warning
like this can be found in `stderr`:
```
Gtk-WARNING **: Could not find the icon 'image-png'. The 'hicolor' theme
was not found either, perhaps you need to install it.
```
As I don't think that we should force users to install this theme
globally and several other packages including `tor-browser`, `gparted`
or `clawsmail` add `hicolor-icon-theme` to their closure this seems to
be a fair measure.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/imagemagick/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/sjpf6fsvmv7aj4x1ngl8ri423cym07cj-imagemagick-7.0.7-29/bin/magick-script -h’ got 0 exit code
- ran ‘/nix/store/sjpf6fsvmv7aj4x1ngl8ri423cym07cj-imagemagick-7.0.7-29/bin/magick-script --help’ got 0 exit code
- ran ‘/nix/store/sjpf6fsvmv7aj4x1ngl8ri423cym07cj-imagemagick-7.0.7-29/bin/magick -h’ got 0 exit code
- ran ‘/nix/store/sjpf6fsvmv7aj4x1ngl8ri423cym07cj-imagemagick-7.0.7-29/bin/magick --help’ got 0 exit code
- ran ‘/nix/store/sjpf6fsvmv7aj4x1ngl8ri423cym07cj-imagemagick-7.0.7-29/bin/magick help’ got 0 exit code
- found 7.0.7-29 with grep in /nix/store/sjpf6fsvmv7aj4x1ngl8ri423cym07cj-imagemagick-7.0.7-29
- directory tree listing: https://gist.github.com/12ed56d2de915ea05dcb89d5486181f8
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/graphicsmagick/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/j8gk0alkmajz7wsv7wn368blshmk89mk-graphicsmagick-1.3.29/bin/gm help’ got 0 exit code
- ran ‘/nix/store/j8gk0alkmajz7wsv7wn368blshmk89mk-graphicsmagick-1.3.29/bin/GraphicsMagick++-config --version’ and found version 1.3.29
- ran ‘/nix/store/j8gk0alkmajz7wsv7wn368blshmk89mk-graphicsmagick-1.3.29/bin/GraphicsMagick-config --version’ and found version 1.3.29
- ran ‘/nix/store/j8gk0alkmajz7wsv7wn368blshmk89mk-graphicsmagick-1.3.29/bin/GraphicsMagickWand-config --version’ and found version 1.3.29
- found 1.3.29 with grep in /nix/store/j8gk0alkmajz7wsv7wn368blshmk89mk-graphicsmagick-1.3.29
- directory tree listing: https://gist.github.com/014b06393c82c79d1f5dfeea620b71f3
"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
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/80y2wx9ga0c647w0m0nhkx2hgfhnwpv5-pqiv-2.10.4/bin/pqiv -h’ got 0 exit code
- ran ‘/nix/store/80y2wx9ga0c647w0m0nhkx2hgfhnwpv5-pqiv-2.10.4/bin/pqiv --help’ got 0 exit code
- ran ‘/nix/store/80y2wx9ga0c647w0m0nhkx2hgfhnwpv5-pqiv-2.10.4/bin/pqiv help’ got 0 exit code
- found 2.10.4 with grep in /nix/store/80y2wx9ga0c647w0m0nhkx2hgfhnwpv5-pqiv-2.10.4
- directory tree listing: https://gist.github.com/4743505ebdeb4ef63b3c2637f5d6879d
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).
