I couldn't find any reference as to why this dependency would be
required for 0.4.2. Digging into the changelog, it looks like 0.4.0
dropped the libswscale dependency, so this seems like it's now unneeded.
This was added in 2005 back in r51ce4ea2. This was not commented or
explained anywhere, and it does not seem to be necessary anymore
according to some quick testing I did.
Reduces mono closure size by ~100M.
Only the actual shared libraries are required to be installed, and they
are imported directly by path via ctypes. The package's patchPhase
already takes care of embedding the Nix store paths of the required
libraries into pyopengl.
This reduces the transitive closure size of PyOpenGL: 622M -> 136M.
patchelf seems to generate an ELF that "strip" cannot process:
strip: /tmp/stNGAZvd: not enough room for program headers, try linking with -N
strip:/tmp/stNGAZvd[.interp]: bad value
(This unfortunately does not cause any errors or even error output in
the build log, since the default strip hook redirects them to /dev/null
and ignores failures.)
The lack of stripping ends up leaking paths to the compiler in the debug
symbols. This more than doubles the transitive closure size of
alacritty.
Impact on closure size: 314.5M -> 131.8M.
Context: discussion in https://github.com/NixOS/nixpkgs/pull/82630
Mesa has been supporting S3TC natively without requiring these libraries
since the S3TC patent expired in December 2017.
Fixes some dependency ordering problems at boot time with services that
require DNS. Without Type=notify these services might be started before
stubby was ready to accept DNS requests.
v2.14 introduced a new experimental React UI and changed how web assets
are bundled with Prometheus. A separate pre-build command is required to
generate an asset bundle that gets statically linked into the Prometheus
binary.
Greatly decreases zbar-lib transitive closure size: assertion messages
contain paths to Qt header files, causing zbar-lib to depend on
qtbase-dev.
The Qt specific mkDerivation normally does this automatically, but we
can't use it here due to having only a small part of the project being
Qt related.
This was introduced in 2010 in 9e16b812 and as far as I can tell the
issue mentioned in the comment does not exist anymore. In a stripped
mono build, I was able to:
- Run "mcs --version" without trouble (original test case)
- Run "keepass" (mono app)
- Build packages that depend on mono (e.g. f# and others).
$ nix path-info -sh
Before: 537.8M
After: 304.3M
$ nix path-info -Sh
Before: 1.2G
After: 867.0M
(Transitive closure size decreases more than the package size itself
because mono ended up depending on gcc through leaked paths in .so files
before.)
No dependencies within nixpkgs, and the package has not built
successfully since 2018-04-29 according to Hydra[1].
[1] https://hydra.nixos.org/build/100604053
nix path-info -rSh on mono:
Before: /nix/store/p7zix8ypkqdwz86jvirzn0hmqhkbfhf7-mono-5.20.1.27 1.2G
After: /nix/store/zwg8d5m2d7hbi1ylh6rq00wyghyyzpsp-mono-5.20.1.27 881.3M
Mostly due to not dragging in cairo-dev, mesa-dev, etc.
The recent bump to 0.96.2 now requires pyyaml 5.1.1. The PRs upgrading
home-assistant to a newer version and the one pinning to an old PyYAML
version raced each other and we ended up with both submitted.
Fixes home-assistant build.
The SDL2_PATH environment variable is space-separated. However, CMake
lists are semicolon separated, and doing set(list "a" ${var}) will end
up with list containing "a;b c d". This causes downstream users to fail
parsing the include dirs list.
Normalize the include dirs list to a normal CMake semicolon-separated
list using separate_arguments.
ibus-qt has not seen a release in 5 years and is only relevant for Qt
4.x, which is becoming more and more rare. Using my current laptop as a
data point, ibus-qt is the only dependency left that drags in qt-4.8.7.
References to the host toolchain are leaking through debug symbols in
glibc, causing gnu cross-builds to always depend on the host toolchain.
The decision to not strip was made in 2012 in order to improve GNU/Hurd
support, and I suspect the reasons that justified it back then do not
apply anymore in 2019.
Closure size before:
/nix/store/v5pxj0bgg627hic2khk4d43z6cjp5v7d-hello-2.10-armv7l-unknown-linux-gnueabihf 596.8M
After:
/nix/store/llp1ncmpar406rc2vhj7g5ix4yqwna3n-hello-2.10-armv7l-unknown-linux-gnueabihf 23.6M
This is tagged as version 9.26a in the ghostpdl repo, but unfortunately
there are no tarballs released with that version number so far. We'll
continue calling this version 9.26 for now for simplicity's sake (and we
can switch to 9.26a and remove the patch when it's properly released).
Fixes#58262Fixes#58089
The original upstream at http://zbar.sourceforge.net/ has not produced a
new release or a new commit on their repository in about 7 years. Most
distros (Debian, Gentoo, Arch, ...) have switched already to the more
maintained fork at https://github.com/mchehab/zbar
Update dependencies from qt4 to qt5, reducing "electrum" closure size in
the process (now only depends on one Qt version).
GS ships with a fork of lcms2 ("lcms2mt"), but the ABI separation
between the fork and the original seems insufficient. If libgs is linked
alongside liblcms2 (for example, this is the case with imagemagick) then
it will call into the original library instead of the fork, causing
segfaults.
Follow the example of both Arch and Debian in this regard -- they both
use the systemwide lib instead of the fork.
Python packages depending on the protobuf library often use the "protoc"
tool from pkgs.protobuf to codegen at build time.
This fixes a few regressions from 5c7531872f
When building with -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON the compiler-rt
CMake configuration attempts to use CMAKE_*_COMPILER_TARGET variables,
which are usually only defined in cross-compilation mode.
Pierre Bourdon