* libtpms: 0.7.4 -> 0.8.0
* libtpms: tpm2 support is out of experimental
Since db80bd9ea16894a1902c3ab787aea9d58e7d1e85 commit, tpm2 support is
not experimental anymore
Signed-off-by: Arthur Gautier <baloo@superbaloo.net>
* libtpms: remove extraneous output
Nothing was put in the $out output, remove the $lib and put everything
that was in it in the $out.
Signed-off-by: Arthur Gautier <baloo@superbaloo.net>
Co-authored-by: R. RyanTM <ryantm-bot@ryantm.com>
Instead of managing external plugins in the beets derivation, we
introduce a new top-level package set beetsExternalPlugins which the
beets derivation receives as an input. This change doesn't affect how
the beets derivation is built or overridden, so the change won't be
noticed by users, but it makes hydra evaluate and build external plugins
which should benefit users of those plugins and prevent future
regressions as we have experienced (currently on master
beets-alternatives fails to evaluate, but this wasn't picked up by
ofborg nor hydra).
The path to the used patch was broken, making the derivation fail
evaluation. However the patch needs to be updated as some new test
failure has cropped up.
This fixes hopefully all remaining missing lib inputs, likely introduced
as a regression by our recent treewide switch from stdenv.lib to lib.
These instances are all I could find using nix-instantiate --parse using
the following command:
find "$NIXPKGS" -name '*.nix' \
-and ! -path "$NIXPKGS/pkgs/development/interpreters/python/cpython/docs/template.nix" \
-and ! -path '$NIXPKGS/.git/**' \
-print0 | xargs -0 nix-instantiate --parse >/dev/null
* Reason: statically set `${NIX_BIN_PREFIX}` within generated
`direnvrc`.
* Before it only replaced the `-z ${NIX_BIN_PREFIX:-}` check
which therefore never was `true`. So, also `NIX_BIN_PREFIX` never got
set such that its usage later always failed execution with
`NIX_BIN_PREFIX: unbound variable`. With the fix, the line containing
the check will no longer be replaced.
* Solves https://github.com/nix-community/nix-direnv/issues/70
* See also discussion on #114622
Signed-off-by: Andreas Schmid <service@aaschmid.de>
fcitx contains functionality to execute xmodmap when changing the
layout, which triggers if ~/.Xmodmap is present. However, this breaks
if xmodmap isn't present in fcitx's PATH.
Brotli support was always on until v0.2.10. It is enabled by default
in the wal-g's 'official' releases and build instructions, so it makes
sense to enable it in nixpkgs too.
wal-g has a Makefile (not used by nixpkgs) which statically links to
brotli v1.0.7 (a C library). Nixpkgs dynamically links to brotli
v1.0.9.
I don't use these tools anymore, so it makes sense I shouldn't have an
opinion on PRs that change/update them. I know it's always unfortunate
losing a reviewer, but I'm not very active anymore anyway,
unfortunately. Apologies.
From now on, I'm trying not to add too many packages into nixpkgs, since
flakes are available. I guess when I first started using Nix I got
overexcited by how easy it was to contribute, so I added things for the
sake of adding things (not because I necessarily used them).
mons tries to detect if xrandr is installed in the PATH, failing
otherwise. However, this is not the way that packages are generally
packaged in nixpkgs.
This commit changes it to hardcode the path of xrandr explicitly instead
of depending of xrandr being declared in PATH.
the nix store may contain hardlinks: derivations may output them
directly, or users may be using store optimization which automatically
hardlinks identical files in the nix store.
The presence of these links are intended to be a 'transparent'
optimization. However, when creating a squashfs image, the image
will be different depending on whether hard links were present
on the filesystem, leading to reproducibility problems.
By passing '-no-hardlinks' to mksquashfs the files are stored
as duplicates in the squashfs image. Since squashfs has support
for duplicate files this does not lead to a larger image.
For more details see
https://github.com/NixOS/nixpkgs/issues/114331
'gcloud sql connect' command allows to connect to a CloudSQL instance
from a local machine. In order to do so, it starts local
'cloud_sdk_proxy' instance. google-cloud-sdk expects to find one in SDK
root (installed by 'gcloud components') or on the PATH, if SDK is not
correctly installed ('.install' directory is missing).
Since google-cloud-sdk on NixOS is properly installed 'gcloud sql
connect' never looks for 'cloud_sql_proxy' on the PATH and simply
doesn't work at all.
The patch slightly modifies the check by looking not only for
'.install' directory, but for actual 'cloud_sql_proxy' binary before
falling back to the search on the PATH.
With this patch it's now possible to use 'gcloud sql connect' on NixOS,
provided that 'cloud_sql_proxy' is available either in user or system
enviroment (available in nixpkgs).
I started out by copying the `tigervnc` derivation, which
does things like re-using `xorg.xorgserver.buildInputs`
(given that these VNC servers are all forks of Xorg),
but then removed that and all the dependencies that did not
appear to be needed or checked for in the CMake output.
The custom installPhase got broken as the rust build scripts only
provide $releaseDir in postInstall hooks. The default rust installPhase
installs the same files, so the custom one is unnecessary.
