Jonas Chevalier

Yeah why not. The important part first is to define a set of interfaces that make this work easily extensible. For example if we stored all the profiles under `

Related to that, I think all the nixos profiles should be moved under `` and have a profilesPath added to nixos so they become easily referencable without using the ``...

Maybe we can work on it here since it will probably be drowned with the other issues upstream. Either works for me.

It depends on 2f943ebc2501437e973f7c1ee193d02dfeea311d in nixpkgs, Date: Fri May 22 04:03:46 2020 -0400 Is it possible that you are using nixos-20.03 or older?

Yeah it seems more related to a nixpkgs + LXC issue. This project just takes the nixos profiles and creates a generic interface to produce the images, with a bit...

Injecting that type of metadata into the output means that it will be rebuilt on every nixpkgs commit, even if the result doesn't change. The output is quite large so...

I could be wrong but I think that NixOS reduces the churn by only pushing the image once in a while instead of at each channel release. It would be...

A better route would be to generate an image that can be consumed by the import-snapshot API: https://docs.aws.amazon.com/vm-import/latest/userguide/vmimport-import-snapshot.html 1. Tweak nixos-generators to output a EC2-optimised vmdk 2. Upload the image...

To rebuild the system you need a copy of the `configuration.nix` and also the version of nixpkgs that was used to build the system in the first place. ```nix {...

You can do that already. The image path is output on stdout and the build logs on stderr. The only thing that's missing is a wrapper script that buffers stderr...