I'm already a maintainer of the Gerrit package and I've done various
work on the Gerrit module. So it makes sense to be a maintainer there as
well.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Containers did not have *systemd-journald-audit.socket* in *additionalUpstreamSystemUnits*, which meant that the unit was not provided.
However the *wantedBy* was added without any additional check, therefore creating an empty unit with just the *WantedBy* on *boot.isContainer* machines.
This caused `systemd-analyze verify` to fail:
```text
systemd-journald-audit.socket: Unit has no Listen setting (ListenStream=, ListenDatagram=, ListenFIFO=, ...). Refusing.
systemd-journald-audit.socket: Cannot add dependency job, ignoring: Unit systemd-journald-audit.socket has a bad unit file setting.
systemd-journald-audit.socket: Cannot add dependency job, ignoring: Unit systemd-journald-audit.socket has a bad unit file setting.
```
The upstream unit already contains the following, which should make it safe to include regardless:
```ini
[Unit]
ConditionSecurity=audit
ConditionCapability=CAP_AUDIT_READ
```
For reference, this popped up in the context of #[360426](https://redirect.github.com/NixOS/nixpkgs/issues/360426) as well as #[407696](https://redirect.github.com/NixOS/nixpkgs/pull/407696).
Co-authored-by: Bruce Toll <4109762+tollb@users.noreply.github.com>
Signed-off-by: benaryorg <binary@benary.org>
Consider a user wanting to set up the Linux builder for the first time,
but with a slightly more generous allocation of resources compared to
the default. They'll do something like this:
```
{
virtualisation.cores = 3;
virtualisation.darwin-builder = {
diskSize = 40 * 1024;
memorySize = 4 * 1024;
};
}
```
This will fail with an error like this:
```
error: a 'aarch64-linux' with features {} is required to build '/nix/store/3acpgmwqwnk8g2gc5r05ar2lvmn01b8a-builder.pl.drv', but I am a 'aarch64-darwin' with features {apple-virt, benchmark, big-parallel, nixos-test}
```
But why would they have to rebuild the NixOS system?! All they did was
change the arguments passed to QEMU, and nothing those options control
would affect the NixOS configuration itself... right?
`config.system.build.toplevel` is defined with `allowSubstitutes` set to
`false` by default, which makes it so that the toplevel can't be
substituted if Nix is trying to use it "directly." So because the above
example would have to rebuild the VM runner, which references toplevel
directly, Nix refuses to substitute it, unless `always-allow-substitutes
= true` is set as a Nix option. (In the case where the QEMU options
aren't changed at all, Nix just substitutes the runner, which sidesteps
this issue as the runner itself doesn't use toplevel as an input.)
During testing of Kimai 2.32, it's been found that fixes done in PR
371917 [^1] is not enough to prevent error in the case of upgrading from
2.31 to 2.32.
Hinted by an upstream issue [^2], make sure that the cache is cleared
before running `kimai:install`, not after. This fixes upgrading from
2.31 to 2.32, and should prevent similar issue from popping up again.
[^1]: https://github.com/NixOS/nixpkgs/pull/371917
[^2]: https://github.com/kimai/kimai/issues/5437
I mistakenly added extra whitespace in
https://github.com/NixOS/nixpkgs/pull/401872 which negatively affects
aesthetics of our documentation.
Thought it was part of nixfmt-rfc-styles output, but can't reproduce.
Might have had configured the wrong nixfmt.
It was easy to accidentally trigger infinite recursion if you depended
on `toplevel` in any way before. For instance, if you used
`CopyBlocks` with an image containing `toplevel`. This was because
`toplevel`'s assertion / warning logic has to be evaluated, but that
means evaluating `image.repart`'s assertions / warnings, which
requires evaluating the `repartConfig` attrsets to check for malformed
`Label`s. That causes the module system to type check *all*
`repartConfig` keys, even though most of them aren't used in the
assertions / warnings. So evaluating `system.build.image` evaluates
`repartConfig.CopyBlocks`, which evaluates `toplevel`, which evaluates
assertions / warnings, which evaluates `repartConfig.CopyBlocks` to
type check it. Infinite loop.
Even ignoring this recursion problem, it's still better for the repart
module to have its own assertions / warnings options. You don't have
to use `toplevel` in a repart image, so its assertions / warnings
would have been ignored in that case anyway. This way they're *always*
checked when you build an image.
