Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/fvwm/versions.
These checks were done:
- built on NixOS
- /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/fvwm2 passed the binary check.
- /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/fvwm-perllib passed the binary check.
- /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/fvwm-convert-2.6 passed the binary check.
- /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/fvwm-menu-xlock passed the binary check.
- /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/fvwm-menu-directory passed the binary check.
- Warning: no invocation of /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/fvwm-menu-desktop had a zero exit code or showed the expected version
- /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/fvwm-menu-headlines passed the binary check.
- Warning: no invocation of /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/xpmroot had a zero exit code or showed the expected version
- /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/fvwm passed the binary check.
- /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/FvwmCommand passed the binary check.
- Warning: no invocation of /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/fvwm-root had a zero exit code or showed the expected version
- /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/fvwm-config passed the binary check.
- /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8/bin/fvwm-bug passed the binary check.
- 10 of 13 passed binary check by having a zero exit code.
- 3 of 13 passed binary check by having the new version present in output.
- found 2.6.8 with grep in /nix/store/kycw0a7gqxh0v7lxq001j9sjysnz1v6h-fvwm-2.6.8
- directory tree listing: https://gist.github.com/94e21d8ab3a4808980c94f1fbb20f1b6
- du listing: https://gist.github.com/6db3d3e079f7808b93a1bbc20e5f396e
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
This reverts a part of 5bd12c694b.
Apparently there's no way to specify user for RuntimeDirectory in systemd
service file (it's always root) but tor won't create control socket if the dir
is owned by anybody except the tor user.
These hardenings were adopted from the upstream service file, checked
against systemd.service(5) and systemd.exec(5) manuals, and tested to
actually work with all the options enabled.
`PrivateDevices` implies `DevicePolicy=closed` according to systemd.exec(5),
removed.
`--RunAsDaemon 0` is the default value according to tor(5), removed.
