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
Nextcloud manages the CA bundle on its own by default, but we patch this
out and replace it with the system-wide bundle.
Since this was originally designed for the objectstore feature, this
test ensures that an S3 behind a reverse proxy with TLS and its own CA
works fine.
I looked at the release notes and this was half of the 25.05 highlights
when it's mostly upgrade notes. I didn't really want mostly technical
details to be that prominent, even though it's a big update.
All the upgrade notes should be in Backward Incompatibilities, not the
highlights, so move things around.
Before this change, this NetBox test required NIXPKGS_ALLOW_INSECURE=1,
because of its use of the end-of-line NetBox version.
This meant that the GitHub CI failed to evaluate the tests,
and so didn't run them.
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.
