Heads: Add packaging & project metadata #681
Conversation
OPNA2608
force-pushed
the
init/heads
branch
2 times, most recently
from
471c970 to
7776386
Compare
OPNA2608
force-pushed
the
init/heads
branch
7 times, most recently
from
3a641ad to
8507f6a
Compare
OPNA2608
changed the title
|
Would it be possible to split this into smaller PRs? Both so that CI can build the packages properly without timing out and for us to review it better. |
| # Theoretically, it should be possible to extract these in the updateScript by running the corresponding download | ||
| # scripts in /blobs/* with a curl/wget that prints out the given URL, and collecting all the requested URLs & their | ||
| # output names | ||
| blobs = [ |
There was a problem hiding this comment.
Note: I am unhappy to announce that while deps.nix is still 100% generated, the new blobs attrset in package.nix likely belongs in there logically… It was just easier to extract those few downloads with their peculiarities by hand than to hack together an automatable solution for now.
Unlike the mountain of dependencies that is deps.nix, manually updating these by skimming the scripts in /blobs/* should at least be fairly doable.
To help with CI load, I've only allowed a single board target to be generated for now - The bulk of the code here is still necessary for building even this mostly-emulated board target. The only things I could cut for now are:
If you think cutting them for now is worth it, then I can go ahead with that. |
OPNA2608
force-pushed
the
init/heads
branch
6 times, most recently
from
3934999 to
b42cdca
Compare
OPNA2608
changed the title
OPNA2608
changed the title
| options.programs.heads = { | ||
| enable = lib.mkEnableOption "symlinking the Heads ROM for qemu-coreboot-fbwhiptail-tpm1-hotp"; | ||
| }; |
There was a problem hiding this comment.
We do have binary artefacts in our data model now! Ah, but complementing them with tests and examples seems not straightforward?
There was a problem hiding this comment.
This is used in the test, to have a fixed location where we can find the ROM at. @eljamm said that currently, it's not possible to refer to the binary attrset.
Also, referencing pkgs in binary (in order to point it at the artifact from the build), currently makes eval blow up, which is why it's commented out: #773
There was a problem hiding this comment.
@eljamm said that currently, it's not possible to refer to the binary attrset.
Because it's not mapped back, but we can do this if we need to.
Closes #547
We're running upstream's build setup, which requires significant fetching & some patching to behave nicely.
deps.nix, and placed/patched in where needed before starting the build. Or in the case of subprojects that get unpacked during the build, have our patch files prepared & put into place for heads to apply during the build.qemu-coreboot-fbwhiptail-tpm1-hotp, because:fetchSubmodulesis currently incomplete: fetchgit: pass --checkout when fetching submodules NixOS/nixpkgs#286228qemu-coreboot-fbwhiptail-tpm1-hotpROM in qemu. We can't test full functionality, but we can at least test for successful booting & the first few menusVM screenshots (menu images look broken, but OCR'd fine, so likely just an issue with the image taking in non-interactive sessions)