<clever>
the aws plugin already does extra things that cloud-init may not, like iam instance profiles and security groups
<clever>
the benefit i can see of installing fresh on aws, is that you wont have an extra generating eating up disk space, that doesnt match your nixpkgs
<clever>
aws, you could generate an AMI that boots the kernel/initrd with grub, and runs from ram
<clever>
packet can natively ipxe boot, so you just have to provide a url to an https source you trust
<clever>
for backends like packet and aws, you can also skip that kexec step
<clever>
and that rescue console function, is part of the plugin that deals with provisioning new hw over the api
<clever>
eyJhb: the basic idea in the above ticket, is that you create a function to boot the machine into a rescue console with ssh, then some reusable code can do the kexec and install steps
<clever>
eyJhb: it did have a script to install nixos over the rescue console at one point
2020-06-13
<clever>
but knowing the cmd, you can at least force it on
<clever>
i'm not sure why it works half the time and doesnt the other half
<clever>
also, `:set syntax=strace` in vim!
<clever>
srk: -ff says to append the pid to the filename, so you dont get 4 different procs interleaved in one big mess
<clever>
srk: it also helps to use `-ff -o trace.txt`
<clever>
wedens[m]: yeah, that should work
<clever>
if you keep the nixpkgs rev the same
<clever>
wedens[m]: you cant really, but if you copy the pre-built nixos to /mnt/, it will have a lot less to rebuild when it builds from the new configuration.nix
<clever>
tobiasBora: yeah, you need to switch over to nixos
<clever>
tobiasBora: `nix repl '<nixpkgs>'` then `postgresql_11.outPath`
<clever>
then it can reuse any other .o files your project isnt changing
<clever>
stteevveen: for fast interation, you usually want to run make in nix-shell
<clever>
stteevveen: add dontStrip = true; to the derivation
<clever>
ldlework: you usually want something more like: phases="configurePhase buildPhase" genericBuild
<clever>
Ashy: genericBuild would also copy $src to ., and then cd into whatever dir that created
<clever>
it does when you dont tell it what else to do
<clever>
ldlework: you usually have a shell.nix or default.nix in the current dir?
<clever>
ldlework: so its looking for either shell.nix or default.nix in the current dir
<clever>
ldlework: you told it what <nixpkgs> maps to, but not what file to actually open a shell for
<clever>
dkjii: it will use the bootstrap glibc, so nothing depends on outside sources
<clever>
dkjii: nix allows you to have many glibc's, based on what nixpkgs is saying to build
<clever>
dkjii: it may not be the version that nixpkgs wants though
<clever>
dkjii: what directory is gcc-9.3.0/ at?
<clever>
dkjii: 185-216 will then begin building things from that, but force glibc, binutils to stay behind
<clever>
dkjii: line 144 will override binutils, coreutils, grep, and gcc, and point all of them towards the bootstrap tools from the tar, thats enough to give a stdenv that can build some things
<clever>
dkjii: each stage will apply some overrides, to change a few packages, which will dynamically impact everything that depends on those packages
<clever>
dkjii: the bootstrap may build 2 gcc's, and unpack a 3rd from a tar
<clever>
it will then use that bootstrap gcc to build the bash everything else uses
<clever>
thats probably the bootstrap phase, where its building gcc from a gcc in a tarball
<clever>
depending on whats happening, you can just grep for one of those strings in nixpkgs to find the expr
<clever>
dkjii: that is the final output, after all of the functional expressions have been ran
<clever>
dkjii: run `nix show-derivation` on that path
<clever>
dkjii: and `nix-env -f expression.nix -i`
<clever>
dkjii: that would be the same as `nix-shell expression.nix` or `nix-shell -E 'import ./expression.nix'`
2020-06-12
<clever>
asheshambasta: more output may wind up in the journal for the service running pulseaudio
<clever>
selfsymmetric-mu: that tells gcc to search for either libpq.so or libpq.a, and link to it
<clever>
selfsymmetric-mu: and then link with -lpq
<clever>
selfsymmetric-mu: what happens if you just put postgresql in buildInputs?
<clever>
evanjs: you could also use cptofs with a smaller image, then manually expand it in a second derivation
<clever>
evanjs: maybe, i forget how trivial it is to use outside of nixos
<clever>
evanjs: yeah
<clever>
evanjs: and then use something like qemu-img to just change the length of the disk image, without touching the contents any
<clever>
evanjs: you can look at how the aws images resize themselves on boot
<clever>
evanjs: does the image need to be that big initially? why not resizefs after deploying?
<clever>
ramses_: its an attribute of the python package
<clever>
> python3.sitePackages
<clever>
does it really need a version field?
<clever>
name is auto-generated from the url, but you can still set your own name
<clever>
CMCDragonkai: just plain fetchzip { version=; meta=; ... }
<clever>
yeah
<clever>
CMCDragonkai: fetchzip is a derivation
<clever>
just use it naked
<clever>
fetchzip already produces the dir you want
<clever>
CMCDragonkai: fetchurl produces a single file, not a dir of many files
<clever>
CMCDragonkai: buildEnv requires the input dir to already have the right name, which is what cole-h's thing does
<clever>
CMCDragonkai: that would be much better
<clever>
CMCDragonkai: what does `top` say is actually running?
<clever>
CMCDragonkai: pkgs.fetchurl is using curl, does that behave the same way?
<clever>
noobly: not sure then, i dont know much about guix
<clever>
noobly: do you have the nix-store command?
2020-06-11
<clever>
dminuoso: ^
<clever>
> lib.optionalString false "foo"
<clever>
and a variant: nix edit -f . xorg.libX11, if your in a nixpkgs checkout
<clever>
inf: you can also do `nix edit nixpkgs.xorg.libX11`
<clever>
> xorg.libX11.meta.position
2020-06-10
<clever>
Ericson2314: the tool to generate the keypair, creates a file with the public key in the right format, and you just copy/paste
<clever>
the imports list cant depend on anything that comes from config, including extra arguments added via another module
<clever>
dminuoso: use the module framework more?
<clever>
dminuoso: but you can also mapAttrs over nodes
<clever>
dminuoso: nixops puts all nodes into /etc/hosts automatically
<clever>
dminuoso: { config, nodes, ... }: at the top of a module, then nodes.machine1.config.anything
<clever>
Ericson2314: `nix sign-paths` will put the signatures into db.sqlite
<clever>
dminuoso: or just assert on any env var, and have shell.nix set it
<clever>
doomlist3: builtins.getEnv, assert
<clever>
and modify it to use that from an env var
<clever>
urkk: you can just take the revision you gave to fetchGit, and feed that into the derivation
<clever>
urkk: why do you need .git?
<clever>
urkk: i dont think you can both keep .git and fetch a private repo
<clever>
cryptix: ah, thats a diff bug
<clever>
cryptix: you want nixos-rebuild boot when in a chroot
<clever>
then you can use step 4 from the nixops issue, to install that storepath
<clever>
then boot that usb stick, format the target disk, and mount to /mnt, and use the same nix copy, to copy it to that final disk
<clever>
wedens[m]: first, install nixos to a usb stick mounted at /mnt like normal, then build a 2nd nixos (the final one) and use nix copy to add it to the usb stick
<clever>
wedens[m]: yeah
<clever>
wedens[m]: then you can use `--to local?root=/mnt` again when booted into that stick, to copy it to whatever drive is mounted to /mnt
<clever>
wedens[m]: if you do a normal nixos-install against the usb stick, then you can use `--to local?root=/mnt/` to add more store paths to the usb, like a 2nd build of nixos
<clever>
wedens[m]: youll have 2 options then, either use 2 usb sticks, or 1 stick that isnt based on the iso
<clever>
wedens[m]: the example i linked goes over ssh, to copy from one machine into /mnt of a remote machine, and skip the tmpfs and usb entirely
<clever>
wedens[m]: that would put it into the nix store in /, which might be tmpfs based, and run out of ram
<clever>
wedens[m]: if you boot the normal nixos usb image, you can then use steps 3&4 to copy a pre-built nixos to /mnt/nix/store and then install the bootloader
<clever>
selfsymmetric-mu: are you using sudo with any of the recent nix commands?
<clever>
i forget why i had disabled them
<clever>
aanderse: line 9 makes the overlay impact the build being deployed, line 17+13 makes the overlays get copied, and impact the remote machine's builds
<clever>
cransom: `ls -ltrh /nix/var/nix/gcroots/auto` will also sort things, so you can see the order you made the result's in
<clever>
DigitalKiwi: just check /dev/zfs like you have OCD, and wait until it breaks again, lol
<clever>
not sure then, maybe it is a bug?
<clever>
jakobrs: what about `--option require-sigs false` ?
<clever>
jakobrs: and `id` ?
<clever>
jakobrs: what does `nix show-config | grep trusted-users` report?
<clever>
jakobrs: it sounds like the normal security mechanisms in nix
<clever>
jakobrs: yeah
<clever>
jakobrs: the cache needs to be added in configuration.nix for it to get into nix.conf
<clever>
DigitalKiwi: something must be breaking the permissions, youll need to figure out what you did to break it, and check /dev/zfs before and after running that cmd
<clever>
jakobrs: when nix-daemon is at play, only a trusted user can bypass signature checks
<clever>
DigitalKiwi: what permissions does /dev/zfs have?
<clever>
Athestus: fonts = [ "a" "b" "c" ]; to select 3 fonts
<clever>
srhb: the new version also fixes the download problems
<clever>
Athestus: oh, it was changed from withFont to fonts a few months ago
<clever>
angerman: oh, have you seen the hydra provisioning scripts?
<clever>
yeah, i see your PR
<clever>
ah
<clever>
heard of the aarch64 community box?
<clever>
so it can setup a dns record for you
<clever>
angerman: the aws backend can use route53 to update an entry in a hosted zone
<clever>
angerman: and yeah, youll need to deal with the ip and dns yourself, enless your using something like the aws backend
<clever>
angerman: on darwin, it used to add the remote machind as a builder, so you could build linux stuff, but multi-user nix (with a nix-daemon) breaks that
<clever>
yep
<clever>
Siyo: if your not going to use channels at all, you can instead use this to make <nixpkgs> still map to the right thing on the server
<clever>
and if you use pkgs.path, it will be the same nixpkgs your building with, which would be the above pin
<clever>
that would emulate nix-channel --update
<clever>
next, you need to use nix-env --profile /nix/var/nix/profiles/per-user/root/channels -i ${something}, against a derivation with the right name and with the right contents
<clever>
and that tar contains a pre-made programs.sqlite
<clever>
so you could pin nixops with `nixops modify -I nixpkgs=https://releases.nixos.org/nixos/unstable/nixos-20.09pre228204.467ce5a9f45/nixexprs.tar.xz`
<clever>
Siyo: when you try to download a channel, you get a 301 redirect to a tar for that specific version
<clever>
Siyo: you could set nixops to use a specific revision of a channel, and then deploy that to the /nix/var/nix/profiles/per-user/root/channels profile...
<clever>
no need to swap SD cards to repair things
<clever>
if i ever break something, i can just --rollback that profile, and it will boot once more
<clever>
ninjin: and the rpi will use this prefix when it tries to fetch things at netboot, so it uses the profile