fix(flake.nix): build dev shells with per-system package sets#158
Open
samlaf wants to merge 1 commit into
Open
fix(flake.nix): build dev shells with per-system package sets#158samlaf wants to merge 1 commit into
samlaf wants to merge 1 commit into
Conversation
The flake exposed both x86_64-linux and aarch64-linux devShells, but most inputs were still built from a top-level x86_64-linux pkgs set. As a result, devShells.aarch64-linux.default contained mostly x86_64 tools and ran under Rosetta/binfmt in Lima on Apple Silicon. Only the mkosi wrapper was parameterized by system. Move the package set and dev-shell inputs into a perSystem function so each devShell is constructed from the matching nixpkgs system. This makes measured-boot, dstack-mr, bash/curl/git, mkosi, and the mkosi tool environment native to the selected devShell system. The target image architecture is unchanged; mkosi configs still control that separately via Architecture=x86-64. This only changes the architecture of the host/dev-shell tooling.
Member
|
I vaguely recall doing some of the weird system stuff because the arm binaries were causing reproducibility issues. at the very least, measured-boot should be running native. but regardless, measured-boot will be deprecated very soon since ill be switching to https://GitHub.com/easy-tee/attest . i have a PR to that repo that I'll push in the next day or two that overhauls the attest cli, which should make it a drop in replacement for measured boot |
Member
|
ill dig thru my commit/slack history to see if I documented why I changed that and see if i have access to an ARM Mac shell somewhere. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This changes flake.nix so dev-shell inputs are built from a per-system pkgs set.
I ran into a very weird segfault error while trying to measure an image due to this (I believe). Haven't been able to repro so likely a heisenbug, but made me think that this nix setup was a mistake and not intentional (though see bottom section).
Currently the flake exposes both x86_64-linux and aarch64-linux devShells, but most inputs are created from a top-level x86_64-linux pkgs set. As a result, devShells.aarch64-linux.default contains mostly x86_64 tools and runs under Rosetta/binfmt in Lima on Apple Silicon. Only the mkosi wrapper is parameterized by system.
This moves reprepro, measured-boot, measured-boot-gcp, mkosiTools, mkosiToolsEnv, and the mkosi wrapper into a perSystem function so each dev shell uses packages native to its system.
The target image architecture should be unchanged. mkosi configs still control that separately via Architecture=x86-64. This only changes the architecture of the host/dev-shell tooling.
Not 100% sure: was the previous behavior intentional?
If the build tooling requires the dev shell itself to be x86_64 when targeting x86_64 images, then this may not be the right approach. But my understanding is that mkosi's target architecture config is the thing that controls the image architecture, while the outer Nix dev-shell tools can run natively on the VM system.
Or perhaps measured-boot really needs to be built for x86 even when ultimately emulated on aarch64? In any case if this was intentional then I feel like it should be commented.