buildRustCrate has a handy `include` helper, that only imports those whitelisted
files and folders to the store.
However, the function's matching logic is broken and includes all files,
regardless of whether or not they're whitelisted, as long as the whitelist
contains at least one name (regardless of whether that name exists). This is
because it doesn't take into account that
`lib.strings.removePrefix "foo" "bar" == "bar"` (that is, paths that don't match
the prefix are passed straight through).
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).
Consider example:
$ nix-instantiate ./nixos -A system --arg configuration '
{
boot.isContainer = true;
nixpkgs.overlays = [ (self: super: {
nix = self.pkgsStatic.nix;
}) ];
}'
When resolving package through overlays, we figure out that
nix == self.pkgsStatic.nix
=>
nix == (import <nixpkgs> { inherit overlays; }).nix
=>
nix == (import <nixpkgs> { overlays = [(self: super: { nix = self.pkgsStatic.nix; })];}).nix
and we enter infinite recursion of nixpkgs evaluations.
The proper fix should terminate recursion by assigning self fixpoint
to inner custom package set. But I get infinite recursion somehow, so
I use `super`. It is less correct modulo deep custom overrides, but behaves
correctly for simple cases and doesn't OOM evaluator.
Fixes https://github.com/NixOS/nixpkgs/issues/57984
This otherwise does not eval `:tested` any more, which means no nixos
channel updates.
Regression comes from 0eb6d0735f (#57751)
which added an assertion stopping the use of `autoResize` when the
filesystem cannot be resized automatically.
There was a bunch of stuff in the cross section that haddn't had any
attention in a while. I might need to slim it down later, but this is
good for now.
`pkgsBuildTarget` allows us to avoid repeated and confusing conditions.
The others merely provide clarity for one the foreign package set's
target platform matters.
This is needed to avoid confusing and repeated boilerplate for
`fooForTarget`. The vast majority of use-cases can still use
`buildPackages or `targetPackages`, which are now defined in terms of
these.
$(shell ...) looks a little sketch like it will be run no matter what.
And there are problems building the manual on darwin so hopefully this
fixes them.
When pass was installed with extensions in the system environment, the
man pages for the selected extensions were not available globally
because they were only available in a buildInput of the password-store
derivation.
This commit resolves the problem by linking the man pages from the
extensions environment into the output directory of the password-store
derivation.
Bug 56850
