`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.
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.
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.
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
This adds an option `services.mattermost.environmentFile`, intended to be
useful especially when `services.mattermost.mutableConfig` is set to `false`.
Since all mattermost configuration options can also be set by environment
variables, this allows managing secret configuration values in a declarative
manner without placing them in the nix store.
This should fix the flakyness of the test.
Forcefully killing the consul process can lead to
a broken `/var/lib/consul/node-id` file, which
will prevent consul from starting on that node again.
See https://github.com/hashicorp/consul/issues/3489
So instead of crashing the whole node, which leads to
this corruption from time to time, we kill the
networking instead, preventing any cluster
communication and then cleanly stop consul.
The keyd package already exists, but without a systemd service.
Keyd requires write access to /var/run to create its socket. Currently
the directory it uses can be changed with an environment variable, but
the keyd repo state suggests that this may turn into a compile-time
option. with that set, and some supplementary groups added, we can run
the service under DynamicUser.
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
The restic repository cache location defaults to ~/.cache/restic when
not overwritten either by the --cache-dir command line parameter or the
universal RESTIC_CACHE_DIR environment variable.
Currently, the --cache-dir variable is set to only some restic commands,
but, e.g., not to the unit's preStart command for the module's
initialize option. This results in two distinct cache locations, one at
~/.cache/restic for the initialize commands and one at the configured
--cache-dir location for the restic backup command.
By explicitly setting RESTIC_CACHE_DIR for the unit, only one cache at
the correct location will be used.
https://restic.readthedocs.io/en/v0.15.1/manual_rest.html#caching
Hydra Eval has been throwing these eval errors for the past four
months, which makes the yellow "Eval Errors" bubble pretty useless:
https://hydra.nixos.org/eval/1790611#tabs-errors
```
in job ‘nixos.tests.installer.separateBoot.aarch64-linux’:
error: Non-EFI boot methods are only supported on i686 / x86_64
in job ‘nixos.tests.installer.simple.aarch64-linux’:
error: Non-EFI boot methods are only supported on i686 / x86_64
in job ‘nixos.tests.installer.lvm.aarch64-linux’:
error: Non-EFI boot methods are only supported on i686 / x86_64
```
This PR moves the failure for the `!isEfi &&
!pkgs.stdenv.hostPlatform.isx86` case from eval-time to runtime, so
the failure gets categorized under the test that produced it, rather
than just being lumped in to the catch-all Eval Errors pile
which... apparently nobody cares about.
Some of the stuff used to be needed for a project, for others I found
alternatives that suited better my needs. Anyways, I don't intend to
spend time maintaining these, so no need to keep that.
`/api/v1/signing-key.gpg` spawns a `gpg` process,
which is great to test if `gpg` is available
and can be invoked from in the unit.
Which is somewhat relevant, since `gpg` was
missing from the unit's `$PATH` until recently.
And even after adding `gpg` to the unit's `$PATH`,
configuring commit signing for a instance
resulted in http/500s nonetheless.
That's due to `@memlock` being present in
`SystemCallFilter=~` and `gpg` trying to
use `mlock` (probably to prevent secrets
in the memory to swap), resulting in an
immediate `SIGKILL` of any spawned `gpg` processes.
