<globin>
niksnut: committed the nixborg module to its repository, what are the next steps to move this forward, shall I open a PR to the nixos infrastructure repo?
jtojnar has quit [(Remote host closed the connection)]
dos4gw has quit [(Quit: dos4gw)]
Guest99066 has joined joined #nixos-dev
Guest99066 has quit [(K-Lined)]
jtojnar has joined joined #nixos-dev
<vcunat>
mguex: [community CDN] actually lower speed of *upload* to the cache might not be a big problem. We will want to upload each path immediately when it's available and not in the moment of channel release. I can remember the pain of having to wait for channel bumps if you wanted binaries (years ago). Another advantage is that this makes the upload much less bursty. Still, *downloads* from cache just have to be able to get to megabyt
<vcunat>
es per second for each well-connected client, unless it can significantly benefit from similarities between updated paths (seems unlikely in short term).
FRidh has quit [(Ping timeout: 260 seconds)]
FRidh has joined joined #nixos-dev
<copumpkin>
niksnut: if I implemented something with roughly this behavior, would you consider it as a mergeable feature? https://github.com/NixOS/nix/issues/1619. Trying to split up a bit of the Hydra logic into bits reusable in other CI scenarios (like my company's internal nix cache builder). Happy to discuss specifics of the tooling so that it might be useful to hydra as well
<mguex>
vcunat: sure. however the current solution has some assumptions and basically implements the stuff that the current hydra/s3 binary cache is missing, namely a structure to realize garbage collection of old releases
<mguex>
so currently there is a rsync'able, scp'able and ipfs-shareable solution for cache.nixos.org, at least for all derivation outputs (no buildInputs etc.)
<mguex>
everything else needs to be built into hydra and this is currently the domain of niksnut. my understanding is that there is currently little motivation to change things
<niksnut>
copumpkin: hm, it's not exactly clear to me what the semantics of this command would be
dos4gw has joined joined #nixos-dev
<copumpkin>
niksnut: "ensure that store X (possibly remote) contains these outputs" is the simplest way I can state it I think
dos4gw has quit [(Client Quit)]
<copumpkin>
this could even use the magic S3 cross-bucket copy if relevant between stores :O
<copumpkin>
although that's not really an immediate priority for me :)
orivej has quit [(Ping timeout: 260 seconds)]
<copumpkin>
I guess we could even call it something like `nix build --into` :P
Guest29157 has joined joined #nixos-dev
<vcunat>
IIRC some nix sub-commands already have the possibility of overriding the location of the (abstracted) nix store to act upon
<niksnut>
copumpkin: I just tried booting a c5.* instance. It fails to mount the root device. I guess some kernel module is needed in the initrd.
<copumpkin>
damn :)
<copumpkin>
yeah probably need moar virtio
<copumpkin>
vcunat: yeah that's what I'm alluding to there. `nix copy --to` vs. `nix build --into`
<niksnut>
I'll boot an Amazon AMI to see what they need
<vcunat>
copumpkin: for #1607 it might just work to use nix path-info --store https://cache.nixos.org
<vcunat>
you only need to get the output paths comfortably
<vcunat>
`nix-env -q --out-path` is the only way I know
<copumpkin>
ouch :)
<copumpkin>
so like `nix-store -r` without the actual realizing?
<vcunat>
yes
<vcunat>
and --json prints lots of nice info
<vcunat>
`nix-env -q --out-path` isn't _too_ comfortable with multiple outputs, too
<vcunat>
copumpkin: you *can* use --store argument to nix build
<vcunat>
Eelco showed an example for building in dislocated chroots
Guest29157 has quit [(Quit: gone sailing)]
<vcunat>
but I don't know what that would do with a remote store
orivej has joined joined #nixos-dev
FRidh has quit [(Ping timeout: 240 seconds)]
Sonarpulse has joined joined #nixos-dev
<copumpkin>
niksnut: you found it!
<niksnut>
yup, it works
<niksnut>
will build new AMIs later
<copumpkin>
niksnut: how about I fix my other 17.09 bug tonight US time and then we make new AMIs tomorrow or something?
<niksnut>
ah great
<copumpkin>
yeah sorry, that bug was on backburner :)
<copumpkin>
but now that you have another reason to make AMIs I'll just fix it
qqq has quit [(Ping timeout: 260 seconds)]
<Dezgeg>
the timestamp thing?
<copumpkin>
yup
<copumpkin>
making the change is trivial but testing it isn't, at least not for me
<copumpkin>
I have no virtualization-enabled linux hardware and I wanted to make a change to VM test
<copumpkin>
maybe I'll just fix and test later (famous last words :P)
zraexy has quit [(Remote host closed the connection)]
vcunat has quit [(Ping timeout: 240 seconds)]
zraexy has joined joined #nixos-dev
__Sander__ has quit [(Quit: Konversation terminated!)]
vcunat has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 260 seconds)]
phreedom has joined joined #nixos-dev
phreedom has quit [(Client Quit)]
phreedom has joined joined #nixos-dev
phreedom has quit [(Client Quit)]
phreedom has joined joined #nixos-dev
phreedom has quit [(Client Quit)]
jtojnar has quit [(Quit: jtojnar)]
phreedom has joined joined #nixos-dev
phreedom has quit [(Client Quit)]
jtojnar has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
Sonarpulse has quit [(Ping timeout: 268 seconds)]
orivej has quit [(Remote host closed the connection)]
Sonarpulse has joined joined #nixos-dev
romildo has joined joined #nixos-dev
<Mic92>
I have proprietary software that also uses /build as sandbox directory and now nix things, the build was messed up because a shared library contains the string /build m(
<copumpkin>
I guess we could rename it to nix-build
<copumpkin>
or just fix it to not hold onto its build directory?