Switch to systemdb-hwdb to build the udev hwdb.bin, as "udevadm hwdb" is
deprecated. This fixes an issue where the order of conflicting keys is
not respected. The systemd-hwdb command creates a newer format (v3) of
hwdb.bin that respects the ordering of duplicate keys, with later
values replacing earlier occurrences.
A release note is included, as some mappings may be affected.
This option has been introduced in 678eed323f without realizing there was this
PR inflight, unfortunately, it collide with what this PR does and make
it irrelevant.
Therefore, I remove it here.
which allows the use of custom packages, that may not have binaries called `consul` or `consul-alerts` in their `/bin/*` (though arguably pretty unlikely to be ever used)
This allows users to set
`programs.firefox.nativeMessagingHosts.euwebid = true` to make the
native companion app available in Firefox.
It's used by the Web eID browser extension
(https://addons.mozilla.org/en/firefox/addon/web-eid-webextension/),
which can be tried out at https://web-eid.eu/ - pressing the
"Authenticate" button there should open a new window.
Bind mount the base dirs of the tls key and chain into the service.
Make sure to bind every directory just once. The test failed on ofborg
when /nix/store and the certificate path in /nix/store/<some path> were
bound.
I think this is required for the gdbus invocations used to implement
the test, rather than for power-profiles-daemon itself.
Fixes: a813be071c ("nixos/polkit: don't enable by default")
Else the files in the runtime can't be accessed from the vimrc. I also remove the /etc. I thought it's a leftover of the old runtime implementation which is replaced in 307b125.
Co-authored-by: linsui <linsui555@gmail.com>
`make-disk-image` is a tool for creating VM images. It takes an argument
`contents` that allows one to specify files and directories that should
be copied into the VM image. However, directories end up not at the
specified target, but instead at a subdirectory of the target, with a
nix-store-like path, e.g.
`/target/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-source`. See issue
https://github.com/NixOS/nixpkgs/issues/226203 .
This change adds a test for make-disk-image's contents directory
handling and adds a fix (appending `/` to rsync input directory names).
This closes issue https://github.com/NixOS/nixpkgs/issues/226203 .
This change fixes two problems with the qemu testing code:
1. Previously, the qemu-img command was missing a disk image format
argument.
2. Previously, if a test assertion failed, the test hung because the VM
was not torn down.
Fixes https://github.com/NixOS/nixpkgs/issues/223289.
This doesn't reduce the security in any way since it was already possible for normal users to do what I do here and create such a fake repo for themselves and set their $IPFS_PATH variable to it. It was and still is also possible to just use the --api CLI option.
This change just removes the manual setup that would otherwise be required.
We wouldn't need this workaround if https://github.com/ipfs/kubo/pull/9366 was merged but the fix seems to have been ignored upstream. Patching it ourselves seems like a bad idea since the patch has security implications.
- Use `runTest` instead of `handleTest`, which simplifies the code a little
- Use `lib.maintainers` instead of `pkgs.lib.maintainers`
- Use `ipfs add --quieter` instead of `ipfs add | awk '{ print $2 }'`
- Whitespace and comment changes
The underlying problem with OCR in this test has been that the only
font installed was DejaVu Sans, a proportional font, which xterm would
try to render as monospace. This produced very broken looking text,
which the OCR understandably had trouble with. With an actual
monospace font installed, there are no more problems and we don't need
the hacks.
After the introduction of structured settings in #208299 the old
string-style options / types which were kept for compatibility are now
removed in preparation for the 23.05 release.
and `lib.getExe` allows a safe handling and potential backport of this.
But for that to work it would require 22.11 to set `pkgs.grafana-agent.meta.mainProgram = "agent"`
Relevant upstream release: https://github.com/grafana/agent/releases/tag/v0.31.0
When kubo is force killed with `pkill -KILL ipfs` or by systemd-oomd,
it doesn't unmount /ipfs and /ipns. That prevents it
from starting up the next time. So, unmount on postStop.
The module is doing much more than just enabling the ipu6 kernel
module, so extending the enable options scope to support for these
camera modules seems a better fit.
This query yielded no results on search.nixos.org.
I don't think I can make all options magically appear, but you can
the other options by reading the text.
This change allows the number of sidekiq processes and which job classes
they handle to be configured.
An instance admin may choose to have separate sidekiq processes handling
jobs related to local users (`default` job class) and jobs related to
federation (`push`, `pull`, `ingress`), so that as the instance grows
and takes on more federation traffic, the local users' experience is not
as impacted.
For more details, see https://docs.joinmastodon.org/admin/scaling/#sidekiq
This pr also includes the following changes suggested in review:
- adds syslog identifiers for mastodon services
- moves working directory config to common cfgService
- adds mastodon.target
1. Launching an app externally (like we do in tests) does not dismiss the GNOME Shell’s Activities view opened on log-in.
2. Activities view grabs input so that user can type to search.
3. Due to a regression in Mutter 44, a window focus is not acquired when Shell grabs input
3ac82a58c5
As a result, trying to determine the WMClass would throw:
TypeError: global.display.focus_window is null
Let’s dismiss the Activities view with Escape key as a workaround.
Starting terminal with autostart makes it harder to control when it is activated.
This reverts commit 7aaf526225.
Unfortunately, we cannot simply just go back since that would fail
as mentioned in the reverted commit.
It appears that this is due to the app not being able to find DISPLAY,
since switching to a different terminal emulator will complain:
(kgx:1612): Gtk-WARNING **: 01:12:49.988: cannot open display: :0.0
Let’s use D-Bus activation rather than executing the program through su.
That will hopefully take care of all the necessary environment variables.
And since GNOME Terminal does not support D-Bus activation for the app,
let’s switch to GNOME Console. It probably makes sense anyway,
as it is the default terminal emulator.
Also let’s unify the WMClass detection a bit. Though, weirdly,
the WMClass differs on Wayland.
This commit deletes the assertions that were added in 4ec456b. Those
assertions weren't even working to begin with, and they also cause
assertions leak into the generated YAML.
This allows other services to refer to the generated smokeping config,
which is e.g. necessary to run smokeping with nginx as frontend, rather
than thttpd.
Remove absolute reference to xsltproc. This reference breaks cross-compilation: instead of host version builder tries to execute binary for target and fails.
In order to fix
https://github.com/NixOS/nixpkgs/issues/114552 (profile name with
special characters), all OSError have been ignored while only the OSError
with errno 22 (invalid argument) could has been ignored.
The drawback of ignoring all OSError is that the "No space left on
device" error is also ignored. When the /boot doesn't have enough
available disk space, the switch-to-configuration script succeeds
while the boot menu has not been updated: the user thinks it's system
has been updated, but on the next reboot it is actually rollbacked.
0d7cd66652 broke validation for hashes with options
such as those generated with `mkpasswd --method=sha-512 --rounds=1000000`:
$6$rounds=1000000$xpzZ6Rfg873gZnDY$RxS7lpVnohfDrrKG3lt9UFHED1KoiPGzH7zQv/HzwalZepo/IfFtxw05ap25duEJSKYhC14.Fn9eXszEpWVtF.
This fixes it.
This commit adds a derivation `gcc-stageCompare` to
`pkgs/test/stdenv/default.nix`.
It is important to always build this derivation whenever building
`stdenv`! Because we are using a Nix-driven bootstrap instead of
gcc's built-in `--enable-bootstrap`, the `gcc` derivation no longer
performs the post-self-compilation sanity check. You must build
this derivation in order to perform that sanity check.
The major benefit of this new approach is that the sanity check
(which involves a third compilation of gcc) can be performed
*concurrently* with all packages that depend on `stdenv`, rather
than serially. Since `stdenv` has very little derivation-level
parallelism it cannot take advantage of more than one or perhaps two
builders. If you have three or more builders this commit will
reduce the time-to-rebuild-stdenv by around 20% (one of three gcc
rebuilds is removed from the critical path, and stdenv's build time
is dominated by roughly 3*gcc + 1*binutils + 1*bison-test-suite).
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Make sure that JIT is actually available when using
services.postgresql = {
enable = true;
enableJIT = true;
package = pkgs.postgresql_15;
};
The current behavior is counter-intuitive because the docs state that
`enableJIT = true;` is sufficient even though it wasn't in that case
because the declared package doesn't have the LLVM dependency.
Fixed by using `package.withJIT` if `enableJIT = true;` and
`package.jitSupport` is `false`.
Also updated the postgresql-jit test to test for that case.
This is useful if your postgresql version is dependant on
`system.stateVersion` and not pinned down manually. Then it's not
necessary to find out which version exactly is in use and define
`package` manually, but just stay with what NixOS provides as default:
$ nix-instantiate -A postgresql
/nix/store/82fzmb77mz2b787dgj7mn4a8i4f6l6sn-postgresql-14.7.drv
$ nix-instantiate -A postgresql_jit
/nix/store/qsjkb72fcrrfpsszrwbsi9q9wgp39m50-postgresql-14.7.drv
$ nix-instantiate -A postgresql.withJIT
/nix/store/qsjkb72fcrrfpsszrwbsi9q9wgp39m50-postgresql-14.7.drv
$ nix-instantiate -A postgresql.withJIT.withoutJIT
/nix/store/82fzmb77mz2b787dgj7mn4a8i4f6l6sn-postgresql-14.7.drv
I.e. you can use postgresql with JIT (for complex queries only[1]) like
this:
services.postgresql = {
enable = true;
enableJIT = true;
};
Performing a new override instead of re-using the `_jit`-variants for
that has the nice property that overlays for the original package apply
to the JIT-enabled variant, i.e.
with import ./. {
overlays = [
(self: super: {
postgresql = super.postgresql.overrideAttrs (_: { fnord = "snens"; });
})
];
};
postgresql.withJIT.fnord
still gives the string `snens` whereas `postgresql_jit` doesn't have the
attribute `fnord` in its derivation.
[1] https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-JIT-ABOVE-COST
Closes#150801
Note: I decided against resuming directly on #150801 because the
conflict was too big (and resolving it seemed too error-prone to me).
Also the `this`-refactoring could be done in an easier manner, i.e. by
exposing JIT attributes with the correct configuration. More on that
below.
This patch creates variants of the `postgresql*`-packages with JIT[1]
support. Please note that a lot of the work was derived from previous
patches filed by other contributors, namely dasJ, andir and abbradar,
hence the co-authored-by tags below.
Effectively, the following things have changed:
* For JIT variants an LLVM-backed stdenv with clang is now used as
suggested by dasJ[2]. We need LLVM and CLang[3] anyways to build the
JIT-part, so no need to mix this up with GCC's stdenv. Also, using the
`dev`-output of LLVM and clang's stdenv for building (and adding llvm
libs as build-inputs) seems more cross friendly to me (which will
become useful when cross-building for JIT-variants will actually be
supported).
* Plugins inherit the build flags from the Makefiles in
`$out/lib/pgxs/src` (e.g. `-Werror=unguarded-availability-new`). Since
some of the flags are clang-specific (and stem from the use of the
CLang stdenv) and don't work on gcc, the stdenv of `pkgs.postgresql`
is passed to the plugins. I.e., plugins for non-JIT variants are built
with a gcc stdenv on Linux and plugins for JIT variants with a clang
stdenv.
Since `plv8` hard-codes `gcc` as `$CC` in its Makefile[4], I marked it
as broken for JIT-variants of postgresql only.
* Added a test-matrix to confirm that JIT works fine on each
`pkgs.postgresql_*_jit` (thanks Andi for the original test in
#124804!).
* For each postgresql version, a new attribute
`postgresql_<version>_jit` (and a corresponding
`postgresqlPackages<version>JitPackages`) are now exposed for better
discoverability and prebuilt artifacts in the binary cache.
* In #150801 the `this`-argument was replaced by an internal recursion.
I decided against this approach because it'd blow up the diff even
more which makes the readability way harder and also harder to revert
this if necessary.
Instead, it is made sure that `this` always points to the correct
variant of `postgresql` and re-using that in an additional
`.override {}`-expression is trivial because the JIT-variant is
exposed in `all-packages.nix`.
* I think the changes are sufficiently big to actually add myself as
maintainer here.
* Added `libxcrypt` to `buildInputs` for versions <v13. While
building things with an LLVM stdenv, these versions complained that
the extern `crypt()` symbol can't be found. Not sure what this is
exactly about, but since we want to switch to libxcrypt for `crypt()`
usage anyways[5] I decided to add it. For >=13 it's not relevant
anymore anyways[6].
* JIT support doesn't work with cross-compilation. It is attempted to
build LLVM-bytecode (`%.bc` is the corresponding `make(1)`-rule) for
each sub-directory in `backend/` for the JIT apparently, but with a
$(CLANG) that can produce binaries for the build, not the host-platform.
I managed to get a cross-build with JIT support working with
`depsBuildBuild = [ llvmPackages.clang ] ++ buildInputs`, but
considering that the resulting LLVM IR isn't platform-independent this
doesn't give you much. In fact, I tried to test the result in a VM-test,
but as soon as JIT was used to optimize a query, postgres would
coredump with `Illegal instruction`.
A common concern of the original approach - with llvm as build input -
was the massive increase of closure size. With the new approach of using
the LLVM stdenv directly and patching out references to the clang drv in
`$out` the effective closure size changes are:
$ nix path-info -Sh $(nix-build -A postgresql_14)
/nix/store/kssxxqycwa3c7kmwmykwxqvspxxa6r1w-postgresql-14.7 306.4M
$ nix path-info -Sh $(nix-build -A postgresql_14_jit)
/nix/store/xc7qmgqrn4h5yr4vmdwy56gs4bmja9ym-postgresql-14.7 689.2M
Most of the increase in closure-size stems from the `lib`-output of
LLVM
$ nix path-info -Sh /nix/store/5r97sbs5j6mw7qnbg8nhnq1gad9973ap-llvm-11.1.0-lib
/nix/store/5r97sbs5j6mw7qnbg8nhnq1gad9973ap-llvm-11.1.0-lib 349.8M
which is why this shouldn't be enabled by default.
While this is quite much because of LLVM, it's still a massive
improvement over the simple approach of adding llvm/clang as
build-inputs and building with `--with-llvm`:
$ nix path-info -Sh $(nix-build -E '
with import ./. {};
postgresql.overrideAttrs ({ configureFlags ? [], buildInputs ? [], ... }: {
configureFlags = configureFlags ++ [ "--with-llvm" ];
buildInputs = buildInputs ++ [ llvm clang ];
})' -j0)
/nix/store/i3bd2r21c6c3428xb4gavjnplfqxn27p-postgresql-14.7 1.6G
Co-authored-by: Andreas Rammhold <andreas@rammhold.de>
Co-authored-by: Janne Heß <janne@hess.ooo>
Co-authored-by: Nikolay Amiantov <ab@fmap.me>
[1] https://www.postgresql.org/docs/current/jit-reason.html
[2] https://github.com/NixOS/nixpkgs/pull/124804#issuecomment-864616931
& https://github.com/NixOS/nixpkgs/pull/150801#issuecomment-1467868321
[3] This fails with the following error otherwise:
```
configure: error: clang not found, but required when compiling --with-llvm, specify with CLANG=
```
[4] https://github.com/plv8/plv8/blob/v3.1.5/Makefile#L14
[5] https://github.com/NixOS/nixpkgs/pull/181764
[6] c45643d618
A change made in #166308 added `networking.resolvconf.package` to the
`environment.systemPackages` list, so it is installed as part of the
system image. However it does so unconditionally, meaning that even if
the `config.networking.resolvconf.enable` is set to false the package
listed in the `networking.resolvconf.package` would still be intalled.
This change makes it so the package installation will depend on the
status of the `config.networking.resolvconf.enable` option instead.
`bridge` is used by iproute2, so using this name for protonmail-bridge
made it very likely to produce a name "conflict".
Also `bridge` is used in the Makefile by upstream project Makefile but
it apparently is renamed later on when packaged in rpm/deb so even for
coherence purposes it does make sense to revert it back to the name
`protonmail-bridge` that were previously being used.
Signed-off-by: Arthur Outhenin-Chalandre <arthur.outhenin-chalandre@proton.ch>
