Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/yq/versions.
These checks were done:
- built on NixOS
- /nix/store/11iw84skak8ag78s93klhmn4mhz1v3qh-yq-2.6.0/bin/.xq-wrapped passed the binary check.
- /nix/store/11iw84skak8ag78s93klhmn4mhz1v3qh-yq-2.6.0/bin/xq passed the binary check.
- /nix/store/11iw84skak8ag78s93klhmn4mhz1v3qh-yq-2.6.0/bin/.yq-wrapped passed the binary check.
- /nix/store/11iw84skak8ag78s93klhmn4mhz1v3qh-yq-2.6.0/bin/yq passed the binary check.
- 4 of 4 passed binary check by having a zero exit code.
- 4 of 4 passed binary check by having the new version present in output.
- found 2.6.0 with grep in /nix/store/11iw84skak8ag78s93klhmn4mhz1v3qh-yq-2.6.0
- directory tree listing: https://gist.github.com/d6c1ce31dff71d43e23d27c6d98e1925
- du listing: https://gist.github.com/a08a8e4ca7caa376a53ad39da72ba921
For some reason, building powershell derivation started failing with
these errors:
```
liblttng-ust.so.0 -> not found!
...
libpam.so.0 -> not found!
```
This patch adds these dependencies
OPAE is a software toolchain and for integration and use of programmable
accelerators, currently supporting Intel Arria 10 and Stratix 10 FPGAs.
This package only contains the userspace software SDK tools and C
libraries -- not the OPAE Linux drivers.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/guake/versions.
These checks were done:
- built on NixOS
- /nix/store/6bf1rgshbaq4696dch9py3ngz96f9k5a-guake-3.2.2/bin/guake passed the binary check.
- /nix/store/6bf1rgshbaq4696dch9py3ngz96f9k5a-guake-3.2.2/bin/..guake-wrapped-wrapped passed the binary check.
- /nix/store/6bf1rgshbaq4696dch9py3ngz96f9k5a-guake-3.2.2/bin/.guake-wrapped passed the binary check.
- 3 of 3 passed binary check by having a zero exit code.
- 0 of 3 passed binary check by having the new version present in output.
- found 3.2.2 with grep in /nix/store/6bf1rgshbaq4696dch9py3ngz96f9k5a-guake-3.2.2
- directory tree listing: https://gist.github.com/f55ea51bdc3ebebdb32210c0cae4f235
- du listing: https://gist.github.com/6b55cea09584855b2518fdc90469b1bf
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>
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
