<clever>
for example, you may find yourself unable to nixos-rebuild a simple 1 line config change, because virtualbox needs 2 hours to compile
<clever>
i think the main value of home-manager is to update stuff in your user, seperately from nixos
<clever>
vika_nezrimaya: have fun with problems like this :P
<clever>
Apr 06 04:50:45 router kernel: e1000 0000:04:02.1 enp4s2f1: Detected Tx Unit Hang
<clever>
vika_nezrimaya: that can work, as long as its not a network error causing the failure you want to debug
<clever>
vika_nezrimaya: about the only thing of importance i can think of is the uid map (or define all uid's in configuration.nix) and the journals
<clever>
vika_nezrimaya: note that if you have any result symlinks in NFS, and you run a garbage collection when it isnt mounted, the things they point to will get deleted
<clever>
vika_nezrimaya: technically, all nixos needs to boot is /nix, but you will need /boot mounted to update the config, and the rest is more what you want to have persist
<clever>
vika_nezrimaya: yeah, that should boot just fine
<clever>
vika_nezrimaya: `nixos-rebuild build-vm` and the ISO's basically boot just like that
<clever>
peelz: i dont think it is, it only works from within that nix-shell
<clever>
peelz: you can also run `nix-shell` in that dir, to get a shell with the "right" nix-universal-prefetch
<clever>
bhipple: but, i have since discovered that the SSD i was running on at the time, had a firmware bug
<clever>
bhipple: it then took just as many hours to delete those .drv files
<clever>
bhipple: i tried btrfs on nixos a while back, i ran some hydra related stuff, and it took several hours to create 1000's of .drv files (rather slow performance) and then hard-crashed the machine
<clever>
Guest1: i run zfs on all of my machines
<clever>
peelz: or re-write gclient in nix
<clever>
peelz: the only real solution is to patch gclient to be able re-patch more gclients after fetching but before running a post-fetch hook, so the patch spreads like a virus
<clever>
peelz: yeah
<clever>
peelz: and some of those post-fetch hooks, run a copy of gclient, that was shipped with that dep, and hasnt been patched yet
<clever>
peelz: the problem is that gclient will run post-fetch hooks in the dependencies
<clever>
peelz: i think so, you start from a git repo and a DEPS file, and that DEPS file says what version of things to get, recursively
<clever>
Guest1: the longer its running, the more likely it is to scramble things
<clever>
Guest1: but your better off just rebooting asap
<clever>
Guest1: i would stop the browser before copying it
<clever>
peelz: but, when the product is 30gig in size, it becomes a pain to re-download when one piece changes, so you want to do something more like yarn2nix, where it uses pkgs.fetchurl to fetch each piece, and puts it all together
<clever>
peelz: the simplest is the route pkgs.fetchgit does, just define the hash of $out, and run a tool in a derivation to generate $out, and if you can create a bit-identical $out each time, you win
<clever>
peelz: there are 2 main routes you can go
<clever>
peelz: ive not looked into how electron is doing webrtc
<clever>
peelz: the reason the whole gclient2nix thing started, is because i had a bug in electron (hanging), and needed a build with debug symbols
<clever>
peelz: just override the nixpkgs electron derivation to change the src, and your done
<clever>
peelz: ive mostly just been patchelf'ing the binary builds of electron
<clever>
peelz: ive yet to even get nix to download electron's source in a pure manner, its a nightmare :P
<clever>
evertedsphere: yeah, ive ran not-os on my rpi's before
<clever>
evertedsphere: nope, not-os can boot on qemu withotu any docker
<clever>
peelz: which is a nightmare to try and get nix to wrap, so i was trying to re-implement gclient in nix
<clever>
peelz: but gclient also wants to patch things as it goes, and re-run copies of itself (that havent been nixified) after it downloads them
<clever>
peelz: gclient wants to download over 30gig worth of junk to build electron, this code is supposed to download everything as seperate fetchurl/fetchzip/fetchFromGitHub calls, and then mash it all together into a single 30gig heap
<clever>
ehmry: i already have nix compiling rpi firmware
<clever>
vika_nezrimaya: it runs a range of systemd services (grafana, prometheus, nginx, oauth_proxy, and others) under runit, inside a single docker image
<clever>
evertedsphere: it was originally meant to be an embedded image in a server
<clever>
evertedsphere: just never tried to port it over
<clever>
evertedsphere: the biggest thing not-os currently lacks, is xorg
<clever>
vika_nezrimaya: i have a half-working util to translate systemd to runit
<clever>
evertedsphere: you would need to add the services you care about, or fully translate systemd->runit, like my recent docker thing
<clever>
niso: i think part of the point of a microkernel, is to have fewer things in ring0, and out-of-tree modules dont give you that
2020-04-09
<clever>
zeta_0: you could modify line 22 to do the `env { something}` for you
<clever>
zeta_0: yeah, 22 is making env not a function anymore, remove it
<clever>
zeta_0: line 22 breaks env being used as a function
<clever>
zeta_0: what errors is it throwing?
<clever>
energizer: nope, only after the pr gets merged
<clever>
energizer: thats how things like fetchgit can run tools like git to fetch things
<clever>
energizer: if you declare the hash of $out, nix gives you unrestricted access to the network, but the build fails if you dont meet the claimed hash
<clever>
energizer: what if my fixed-output derivation does a query against 192.168.1.1 ?
<clever>
energizer: what if i upload a derivation with `src = /etc/shadow;` ?
<clever>
energizer: if you let others upload to it, youll have a security nightmare
<clever>
energizer: you can just run your own hydra and build whatever you want
<clever>
zeta_0: i think so
<clever>
energizer: correct
<clever>
numkem: probably
<clever>
numkem: the `-I nixpkgs=` will change what <nixpkgs> refers to, and nixops internally uses <nixpkgs> to load everything
<clever>
numkem: you can just point it to an existing revision on the original nixpkgs, whatever a channel was last on
<clever>
numkem: and it will keep using it every time you deploy
<clever>
numkem: when you run `nixops create` or `nixops modify` with a `-I nixpkgs=`, nixops will remember that override
<clever>
zeta_0: so if you do `(developPackage { returnShellEnv = false; ... }).env { withHoogle = true; }` then it will work
<clever>
zeta_0: the .env attr, is actually a function, that takes a { withHoogle = ?; }
<clever>
numkem: if the machine is already created, then you need to use the none backend, which wont do any aws special things
<clever>
numkem: though, nixops will add that metadata, if in use
<clever>
numkem: only at runtime i believe
<clever>
asbachb: yeah
<clever>
asbachb: nix uses the hash of the build directions to compute $out, so if the steps to make somehting havent changed, it finds the old product in the store, and just reuses it
<clever>
and defexpr will restore itself every time you login
<clever>
DamienCassou: there shouldnt be a channels folder in the home dir, just def-expr
<clever>
chpatrick: if its not set, then it defaults to auto, which tests if it can write to things in /nix
<clever>
chpatrick: i believe it first checks $NIX_REMOTE, daemon means use the daemon, auto is the default, which tests if it has write to stuff in /nix
<clever>
ah, out of ideas then
<clever>
chpatrick: does the output device appear in pavucontrol?
2020-04-08
<clever>
timokau[m]: much more readable :)
<clever>
timokau[m]: and if you throw some ``` around the quote, it will keep the <clever> from irc intact
<clever>
timokau[m]: sure, my github username is @cleverca22
<clever>
timokau[m]: if you use `--argstr system aarch64-linux`, then your telling nixpkgs to do an aarch64 build, and leaving the local arch intact
<clever>
timokau[m]: if you use `--option system`, then your lying to nix that the LOCAL machine is aarch64, which causes builtins.currentSystem to repeat that lie, and nix will try to run aarch64 binaries (causing your issue)
<clever>
timokau[m]: id recomend against using `--option system`, that will break a lot of things
2020-04-07
<clever>
lovesegfault: yeah, anything in the buildInputs (and some parts of the stdenv) can add themselves to phases
<clever>
lovesegfault: patchShebangs, it uses the binary already in $PATH
<clever>
gchristensen: can the metadata be obtained at a later time, via the api?
<clever>
gchristensen: probably
<clever>
gchristensen: yeah, and then you can use stuff like ram size to adjust limits of programs, and cpu core count to adjust concurrency
<clever>
gchristensen: and nixops can do similar, via a file in /tmp/
<clever>
gchristensen: simplest option i can see is to just encode all of that metadata as json (or hnix it into nix), and then have a nix file in /etc/nixos/ that sets something like hardware.packet.metata = builtins.parseJSON (builtins.readFile ./metadata.json);
<clever>
gchristensen: for normal nixos, or nixops?
<clever>
gchristensen: ask away
<clever>
atemu12[m]: measured boot in the TPM also helps, smaller firmware blob involved in the critical thing
<clever>
atemu12[m]: but somebody could backdoor the binary in the ESP, and steal your pw
<clever>
atemu12[m]: yeah, the ESP can be seperate from /boot/
<clever>
atemu12[m]: the efi firmware cant deal with decryption, so the ESP must be in plaintext
<clever>
atemu12[m]: if you encrypt /boot, are you using efi or legacy?
<clever>
srid: the repo your nix-env'ing could be different from the main one, just a helper repo
<clever>
srid: then the default.nix could re-fetch the repo, using builtins.fetchgit
<clever>
srid: the default.nix within the tar, must then have a `{ gitrev ? "default" }:` and fetch that one
<clever>
srid: its so you can do something like `nix-env -E 'channels: (import channels.nixos {}).hello' -i` i believe
<clever>
srid: you want to likely add a `_:` to the start of the expr
<clever>
srid: but note, it must return a function, and nix-env will run that function with every channel as a set
<clever>
srid: nix-env -E works just fine
<clever>
xfix: i choose to use a either a fat32 or ext4 /boot, with zfs on luks for /
<clever>
gchristensen: of note, zfs cant encrypt the dataset names, so if you have a tank/uber-secrets, somebody is going to have questions for you when they notice it :P
<clever>
xfix: ah, that would explain things
<clever>
lordcirth: online, damn!!
<clever>
srid: simplest, is to use builtins.readFile to read the file in the derivation
<clever>
,ifd srid
<clever>
thibm: more for when your using nixops, you can `nixops deploy --build-only`, then copy that product up
<clever>
thibm: but for any FS the distro already supports, nix + nix copy would likely do
<clever>
thibm: if your doing zfs, it would probably be simpler to kexec into nixos
<clever>
depends on what the cloud provider offers
<clever>
ixxie: you could also package the kernel+initrd from it, into a normal /boot with grub, and then just boot that as a disk image
<clever>
ixxie: kexec is also somewhat optional, since you could also use the nix copy trick in the above issue
<clever>
mounted&
<clever>
assuming things have already been partitioned and installed
<clever>
thibm: if you install just nix, then you can use phase 3 here, to copy a pre-built nixos to /mnt/nix/store on a remote machine
<clever>
vika_nezrimaya: so, nixos, on apple hardware, with a zfs root, and then darwin in qemu, with zfs volumes for the disk image
<clever>
vika_nezrimaya: its only legal if you do it on apple hardware
<clever>
vika_nezrimaya: darwin under qemu, on nixos
<clever>
vika_nezrimaya: every time the darwin guest reboots, nixos will do a zfs rollback of it
<clever>
vika_nezrimaya: the nixos mac builders all use darwin in qemu on nixos+zfs
<clever>
vika_nezrimaya: basically, you make an install media with justdoit included, boot it on something, type justdoit into the shell, and it does it