Allow building other than Legacy-BIOS-only Proxmox images.
Default is unchanged.
To build UEFI proxmox image use:
proxmox.qemuConf.bios = "ovmf";
(default is "seabios")
To build image bootable using both "seabios" and "ovmf" use:
partitionTableType = "hybrid";
BIOS can be switched in Proxmox between "seabios" and "ovmf" and VM still boots.
(GRUB2-only, systemd-boot does not boot under "seabios")
To build systemd-boot UEFI image:
proxmox.qemuConf.bios = "ovmf";
boot.loader.systemd-boot.enable = true;
(cherry picked from commit 4729d5d7f6)
Packages built with `haskellPackages.callHackage` won't be rebuilt when
updating `all-cabal-hashes`.
The removed comment was keeping a reference to the `cabal2nix` call,
which itself depends on `all-cabal-hashes`, in order to keep this file
during a garbage collection.
The tradeoff is between:
- The current behavior: a mass rebuild, any change of `all-cabal-hashes`
triggers a rebuild of all the packages built with `callHackage` and
packages which depend on them. This can take hours, and may happen
after a "small" unrelated change (i.e. an user is bumping
`all-cabal-hashes` in order to use a new package from hackage). It
also have global impacts in a project (long rebuild in CI, new entries
in cache, developers need to fetch the new entries, ...). In this
context, `cabal2nix` entries are not garbage collected.
- The new behavior: No mass rebuild, but `cabal2nix` derivations need to
be recomputed after a garbage collection. This is usually fast (a few
seconds by call), linear with the number of calls and should not
happen a lot (i.e. users are not garbage collecting everyday).
See https://github.com/NixOS/nixpkgs/issues/194751 for details.
(cherry picked from commit 6f5fb11c421c616715982989fa586d937db720ff)
The tests TLS setup was bogus: the xmpp-send-message script was trying
to connect to the server through a bogus domain name. Injecting the
right one.
I'm a bit confused about that one. I know for sure this NixOS test
succeeded last time I checked it, but the TLS conf is bogus for sure.
I assume the slixmpp SNI validation was a bit too loose and was
tightened at some point.
(cherry picked from commit 8040c468ed)
The xmpp-sendmessage the slixmpp-powered python script tend to timeout
and block the nixos channels.
Adding a signal-based timeout making sure that whatever happens, the
script won't run for more than 2 minutes. That should be pleinty
enough time to finish regardless of the runner specs. As a data point,
it runs in about 10 secs on my desktop machine.
(cherry picked from commit 501d684de8)
The nixos-generate-config command mentioned in the manual fails with error:
nixos-generate-config: no need to specify `/` with `--root`, it is the default
This was introduced in 611b8c4472
(#161034). Now, the command should be called without any arguments.
(cherry picked from commit ee8ae2da4c)
