Overengineered for no good reason, especially since upstream Xen
recommends downstreams to use the latest stable branch anyway (instead
of the pinned release revision)
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
- Migrates to the new platform declaration style.
- Removes the separate output TODO, as it is an impossible task.
- Removes some superfluous comments.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
`xl` needs a full path to the efirom executable.
This does not fix the qemu-dm issue. A stubdom is still required.
Reported-by: HeHongbo <hehongbo@mail.com>
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
If the environment provides the variable (as NixOS does when the i18n option is
set), keep it rather than overriding unconditionally.
Fixes https://github.com/NixOS/nixpkgs/issues/354887
We are migrating packages that meet below requirements:
1. using `callPackage`
2. called path is a directory
3. overriding set is empty (`{ }`)
4. not containing path expressions other than relative path (to
makenixpkgs-vet happy)
5. not referenced by nix files outside of the directory, other
than`pkgs/top-level/all-packages.nix`
6. not referencing nix files outside of the directory
7. not referencing `default.nix` (since it's changed to `package.nix`)
8. `outPath` doesn't change after migration
The tool is here: https://github.com/Aleksanaa/by-name-migrate.
This replaces the mess of buildEnvs with a single Rust binary that
spits out a mostly-complete root filesystem for an fhsenv.
The main goal is to have includeClosures, as we want all of the
dependencies to be in the fhsenv to avoid Steam's (and others')
LD_LIBRARY_PATH shenanigans, but without 32-bit libraries leaking
into lib64 when a 64-bit package like mangohud depends on a 32-bit
version of itself.
We "fix" this by actually looking at the files and explicitly moving
32-bit stuff to $out/lib32. This could be avoided if we had recursive
Nix, or at least system info in exportReferencesGraph, but alas.
For some reason this also shrinks the fhsenvs massively, even though
there's currently no layout optimization (e.g. a package with paths
like lib/foo/{bar,baz} will produce two symlinks in the output, even
when it's more optimal to symlink lib/foo to $out/lib/foo directly).
Originally, we switched to bsdtar from libarchive to solve a reproducibility issue related to hardlinks
As of gnu cpio 2.14 the --ignore-dirnlink option is introduced and now included in --reproducible, which solves this issue
By switching back, we are in turn solving an issue in libarchive >=3.7.5 erroring out with "Error reading archive -: (null)"
Change-Id: Ib6140d599b6547d8e941b0251ce996e303c41fa6
