Xen is a trademark of the Cloud Software Group; we're not packaging
Xen(Server), we're packaging the Xen Project Hypervisor, which is open
source and owned by the Linux Foundation.
This is based on advice from Kelly Choi, the Xen Project Community
Manager, who has assisted us in the branding aspects of pacakaging.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
The GUI of GlobalProtect-openconnect is unfree software, while the CLI is
licensed as GPLv3-only. This packaging work focuses on the CLI, and
components required for the CLI.
Link: https://github.com/yuezk/GlobalProtect-openconnect
Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
The 1.x iteration of globalprotect-openconnect is no longer being
developed. Remove related components from nixpkgs.
Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
- Cleans up downstream systemd units in favour of using upstream units.
- Xen 4.18 on Nixpkgs now supports EFI booting, so we have an EFI boot
builder here that runs after systemd-boot-builder.py.
- Add more options for setting up dom0 resource limits.
- Adds options for the declarative configuration of oxenstored.
- Disables the automatic bridge configuration, as it was broken.
- Drops legacy BIOS boot
- Adds an EFI boot entry builder script.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
Co-authored-by: Yaroslav Bolyukin <iam@lach.pw>
Using zfs.latestCompatibleLinuxPackages can result in downgrades to the kernel on a system, potentially causing breakage.
This breakage may not be apparent during build and switch, but only after attempting to reboot into the updated generation.
By forcing users to explicitly manage their kernel version, we can ensure that the breakage will be apparent at build time instead.
Also recommends the usage of sudo's -E flag if --use-remote-sudo cannot
be used. This should still be discouraged IMO, as it means Nix may write
root-owned files to the user's home directory.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
After a discussion on Matrix, it has become clear that building as root
is discouraged, and the (inappropriately named) --use-remote-sudo flag
should be enouraged as the de-facto way to selectively escalate to root
after a system build has finished.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
