When you evaluate nixos/tests/simple.nix, you'll run into an infinite
recursion since 41b140cb25.
The reason is that udisks2 now pulls in gnupg because it now depends on
libblockdev, which in turn depends on volume_key and that depends on
gnupg.
Nevertheless, it's not the real reason, because this only means, that
since gnupg is now pulled into the closure of a basic nixos
configuration the real problem becomes visible:
In nixos/modules/config/no-x-libs.nix there is an overlay which does
something like this:
nixpkgs.overlays = singleton (const (super: {
pinentry = super.pinentry_ncurses;
}));
Now since pinentry_ncurses is already using pinentry.override we get an
infinite recursion because now the pinentry attribute refers to
pinentry_ncurses, which by itself is again referring to pinentry.
This is solved by using the self.pinentry.override instead, so that the
override used by pinentry_ncurses doesn't use the attribute from the
overlay.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @ttuegel
Signed-off-by: aszlig <aszlig@nix.build>
The usage of nixpkgs.config.packageOverrides is deprecated and we do
have overlays since quite a while.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra
A .la file specifies linker flags to link with the library it describes. Its
"dependency_libs" field lists the libraries that this library depends upon.
This list often contains "-l" flags without corresponding "-L" flags. Many
packages in Nixpkgs deal with this in one of these ways:
- delete .la file [1]
- clear dependency_libs [2]
- add -L flags to dependency_libs [3]
- propagate dependencies [4]
Sometimes "dependency_libs" contain wrong "-L" flags pointing to the "dev"
output with headers rather than to the main output with libraries. They have to
be edited or deleted to reduce closure size [5].
Deleting .la files is often but not always safe [6]. Atomatically deleting as
many of them as possible is complex [7]. Deleting .la files that describe
shared rather than static libraries is probably safe; but clearing their
"dependency_libs" field achieves the same effect with less potential for
unintended consequences. This is the approach that may be enabled for all
Nixpkgs.
[1] 2a79d296d3
[2] c83a530985
[3] 9e0dcf3bd9
[4] 01134e698f
[5] f6c73f1e37
[6] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Handling_Libtool_Archives
[7] https://github.com/gentoo/gentoo/blob/fb1f2435/eclass/ltprune.eclass
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/fwts/versions.
These checks were done:
- built on NixOS
- /nix/store/v5wy7231jv43gnni4s3jcq0lz1qx21bs-fwts-18.05.00/bin/fwts passed the binary check.
- Warning: no invocation of /nix/store/v5wy7231jv43gnni4s3jcq0lz1qx21bs-fwts-18.05.00/bin/kernelscan had a zero exit code or showed the expected version
- 1 of 2 passed binary check by having a zero exit code.
- 0 of 2 passed binary check by having the new version present in output.
- found 18.05.00 with grep in /nix/store/v5wy7231jv43gnni4s3jcq0lz1qx21bs-fwts-18.05.00
- directory tree listing: https://gist.github.com/8fb4995cd885cdeea7a35d51b7edca3b
- du listing: https://gist.github.com/8cc61b948b8e0aa4a1a8088464c5536d
