2020-02-18

<clever> mikky: i think its a fully self-contained nixos, so you can do .config = { config, ... }: { ... config.networking.hostname
<clever> and the file i listed, is the cache of what is on a cache
<clever> duairc: that can happen any time a binary cache gets GC'd
<clever> duairc: try doing `rm ~/.cache/nix/binary-cache-v6.sqlite*` as root
<clever> peelz_: i think there is a checkbox in one of the menu bars to hold ctrl and/or shift
<clever> switch wont work inside the vm, but you can just shutdown, edit the host config, and build-vm again
<clever> just run that, and thats it
<clever> it will run your entire config, in a vm, with much more limited ram usage
<clever> `nixos-rebuild build-vm` would also help test faster
<clever> then file an issue
<clever> try breaking it again, for science!
<clever> maybe the perl/json encoder got upset?
<clever> that solves issues like another user winding up with that uid, and owning 2 /home folders
<clever> peelz_: the main purpose of that file, is for when you delete a user from configuration.nix, then re-add the user, it regains its old uid
<clever> peelz_: it could also have been an improper shutdown
<clever> peelz: do it!
<clever> peelz: delete uid-map, and nixos should repair itself
<clever> peelz: this perl script also runs on boot, as an activation script, its likely chewing up 60gig of ram, and getting OOM'd, before you can boot
<clever> peelz: sounds like disk corruption
<clever> peelz: what do the contents look like in a text editor?
<clever> peelz: that aint right
<clever> peelz: in the directory i just pasted
<clever> peelz: they should be json i believe
<clever> peelz: how do these 4 files look? are they fairly small?
<clever> [root@nas:~]# ls -ltrh /var/lib/nixos/
<clever> peelz: check the json file it got ran on
<clever> peelz: why is perl using 20gig of ram? lol
<clever> peelz: what does top say is using it all?
<clever> newuser99: weird
<clever> newuser99: is it in your .bash_profile or .bashrc?
<clever> weird
<clever> peelz: top
<clever> peelz: free -m
<clever> peelz: what does `dmesg` show at the end?
<clever> immae: microcode gets prepended to the initrd, and the kernel applies it before virtualmemory is even enabled
<clever> peelz: maybe also try disabling that, and see if its faster or not
<clever> peelz: try rebooting again, make note of the exact time it seems to hang, and when it resumes, and then pastebin the `journalctl -b 0` again, and report what timestamps is was hung during
<clever> peelz: which would be all of stage1, and the activation scripts
<clever> peelz: that is everything before systemd gained control
<clever> peelz: what about `systemd-analyze plot > boot.svg` and then look at that?
<clever> peelz: what about further up in the log?
<clever> around the timestamp of the hang
<clever> peelz: what do you see in `journalctl -b 0` ?
<clever> peelz: activation scripts happen before systemd is started
<clever> peelz: any custom activation scripts?
<clever> karantan: 67 defines a custom option, and then you can read it like any other nixos option
<clever> karantan: making it a module with options would be better
<clever> karantan: you could either define a custom nixos option and use it, or just start the file with `domain:` and then do `import ./file.nix "example.com"`
<clever> newuser99: simplest answer is to not include nix in the buildEnv
<clever> newuser99: you have nix inside the buildEnv, and its conflicting with the nix installed normally
<clever> newuser99: and they could be messing with some things elsewhere
<clever> newuser99: lines 19-29 dont do anything, becuase they arent in a derivation
<clever> newuser99: building with -Q will make the output more readable in some cases
<clever> newuser99: what kinds of things is it building?
<clever> newuser99: thats the issue, `NIX_REMOTE=daemon` says to connect to a nix-daemon process, which isnt used in single-user mode
<clever> newuser99: and the env var `$NIX_REMOTE` shouldnt be set
<clever> newuser99: looks like a single-user install, so user should own everything in /nix
<clever> newuser99: ls -lh /nix/var/nix/db/
<clever> newuser99: what distro are you on?
<clever> newuser99: is it a single-user or multi-user install of nix?
<clever> you can also install that tool locally
<clever> ,locate
<clever> NoctisLa1: tftp-hpa might be an option
<clever> ,locate bin tftp
<clever> NoctisLa1: you can also use `nix-shell` or `nix-env` to get one of those into PATH temporarily
<clever> NoctisLa1: if its due to you installing things, then its less of a bug
<clever> NoctisLa1: yeah, i would consider that a bug, somebody will have to decide if we want net-tools, inetutils, or both, and then somehow block one of the ifconfig's if we want both
<clever> NoctisLa1: depends on what is having a collision
<clever> its just pkgs.dvc
<clever> newuser99: its not in nixpkgs master, so its unlikely to be in any channel
<clever> newuser99: why do you think its in nixpkgs-unstable?
<clever> newuser99: and which package is missing?
<clever> newuser99: when is the last time you dod `nix-channel --update` ?
<clever> newuser99: what does `nix-instantiate --find-file nixpkgs` say?
<clever> newuser99: or edit shell.nix to use <nixpkgs-unstable> instead of <nixpkgs>
<clever> newuser99: use `-I nixpkgs=something` to map <nixpkgs> elsewhere
<clever> justan0theruser: you must put (dunst.override { dunstify = true; }) into your shell instead
<clever> justan0theruser: its disabled by default
<clever> 4 , libXinerama, libnotify, pango, xorgproto, librsvg, dunstify ? false

2020-02-17

<clever> evanjs: i was doing it all manually
<clever> evanjs: when i was building, initrd_source had to point to a bare cpio file, not gzip'd
<clever> ive not played with DynamicUser much yet
<clever> but overlays could mess with pkgs.lib
<clever> cole-h: and pkgs.lib is usually `import <nixpkgs/lib>`
<clever> cole-h: yeah
<clever> so it wont conflict with things
<clever> mikky: { lib }: imports <nixpkgs/lib> and skips the overlays
<clever> mikky: `pkgs.lib` depends on the value of your overlays (so overlays cant use that lib easily)
<clever> mikky: are you sure you are using lib.mkForce, the error would be something diff
<clever> Westixy: (builtins.fromJSON (builtins.readFile ./packager.json)).version
<clever> Westixy: you can also use () to combine those
<clever> Westixy: youll also want builtins.readFile
<clever> Westixy: builtins.fromJSON
<clever> __monty__: yeah, if you dont know the nixpkgs, your kinda screwed
<clever> so it largely depends on if your using the exprs to build or not
<clever> __monty__: but if you only have a naked $out, you cant do that
<clever> __monty__: if you have the .drv that creates that $out, you can work backwards with `nix show-derivation` to get the src
<clever> DigitalKiwi: the dns for cache.nixos.org could simply be pointed elsewhere...
<clever> just have aws ship you some snowballs with the data, delete it, then ship them back and ask for it to be copied back into place
<clever> if its only for a day, you dont need any actual storage
<clever> gchristensen: your better off using a bunch of snowballs
<clever> gchristensen: good luck moving that much data before the day is out
<clever> the main cache.nixos.org is never GC'd
<clever> aterius: nix-build --dry-run, on a given nixpkgs rev

2020-02-16

<clever> !!!!
<clever> the only way to replicate what a build machine is doing, is to actually add it as a builder, or add the source machine as a substituter
<clever> (if you tell it to include outputs)
<clever> it will copy the build-time deps, for everything in the closure of X!
<clever> but nix-copy-closure wont just copy what the remote end needs to build X

2020-02-15

<clever> pie_[bnc]: they may not know of it, or the cmake file doesnt accept it
<clever> pie_[bnc]: it replaces the configurePhase, and uses cmakeFlags instead of configureFlags
<clever> pie_[bnc]: read the cmake setup hook
<clever> pie_[bnc]: have you tried clangStdenv?
<clever> id need more context on what your doing
<clever> pie_[bnc]: .override can change the args on line 1, so you can swap out the stdenv it receives
<clever> linarcx: -d and --max-freed arent part of nix-store --gc, i believe
<clever> linarcx: i believe they are the same, if no extra args are used
<clever> NoctisLabs: each derivation is downloaded in full, but if a dependency hasnt changed, it reuses the copy it already had

2020-02-14

<clever> eacameron: if you want legacy booting on gpt, you must create a bios boot partition, 1mb, not formated, not mounted
<clever> simukis_: what stops non-interactive things from just using `nix-shell -p foo --run bar` ?
<clever> simukis_: why cant you use nix-shell?
<clever> simukis_: the setup hooks are supposed to automate it for you, so you dont need to do that
<clever> simukis_: for example, look at this: nix-shell -p pkgconfig ncurses --run 'echo $PKG_CONFIG_PATH'
<clever> simukis_: which adds the /lib/pkgconfig/ dir to the search path, so it can find the .pc files
<clever> simukis_: the stdenv will run the function in that hook, for every entry in buildInputs
<clever> simukis_: nix-shell will source this file, which will then add everything from buildInputs to PKG_CONFIG_PATH
<clever> simukis_: mkShell is just a helper that puts things into buildInputs, and still needs nix-shell to be ran on it
<clever> simukis_: the setup hook in pkgconfig must be ran for it to work, and only nix-shell and nix-build can run it
<clever> simukis_: nix-shell -p pytestEnv pkgconfig
<clever> simukis_: you must use nix-shell if you want pkgconfig to work at all
<clever> simukis_: buildInputs doesnt work on buildEnv
<clever> eacameron: if you booted with efi, then the efivars should be mounted un `mount`
<clever> simukis_: what nix file are you using and what command are you running?
<clever> simukis_: pkgconfig must be in the nativeBuildInputs, buildEnv will break the setup hook
<clever> Guest54: you are also still listed as a guest in irc
<clever> Guest54: yes
<clever> ben: but, if you already own /nix, it wont need sudo at any step, so you could just `mkdir /nix ; chown ben /nix`
<clever> ben: and it will sudo the parts that need root
<clever> ben: the installer shouldnt be ran as root, it must be ran as a non-root user
<clever> ,unstable cole-h
<clever> cole-h: if you want to only affect certain packages, its much simpler
<clever> cole-h: just change $NIX_PATH or use -I nixpkgs=/foo
<clever> dang typos!
<clever> (at least on nixos, not sure of home-manager)
<clever> (at least on nixpkgs, not sure of home-manager)
<clever> cole-h: nixpkgs.pkgs is already an option, that does the same thing
<clever> epl692: so just look at the name in `nix-channel --list`, and use that name
<clever> epl692: when you do `nix-env -iA nixos.hello`, the `nixos` says to use a channel named nixos
<clever> types.commas will merge stings with a ,
<clever> types.lines will merge things with a \n
<clever> depending on the type, nix will either append or fail, when you set it twice
<clever> cole-h: just set home.packages in each file
<clever> cole-h: the module system will always append if you set a list type thing twice

2020-02-13

<clever> pbb: youll need a custom linux .config file, or at least a few custom config entries, to force it down to 586
<clever> pbb: i686-linux is the codename for all 32bit x86 cpu's
<clever> ilya_g: figure out where your code is calling runInLinuxVM, within nixpkgs, and override that
<clever> ilya_g: import a second copy of nixpkgs, and get runInLinuxVM from that
<clever> ilya_g: use an older nixpkgs rev, or use a fork of nixpkgs with it fixed
<clever> ilya_g: crap, pkgs/build-support/vm/default.nix directly imports that file, you have no way to overlay it
<clever> ilya_g: 11 with import ../../../nixos/lib/qemu-flags.nix { inherit pkgs; };
<clever> evanjs: fixed-output and non-fixed use a different algo to compute $out
<clever> evanjs: now most things in nixpkgs use name = "source"; which i feel makes things worse
<clever> evanjs: previously, fetchFromGitHub included the rev in the name, but that caused some issues where nix-prefetch-git doesnt use the same name, and the sha256 isnt right
<clever> evanjs: so if the name changes, the hash totally changes, and it cant find the old $out, even with the same sha256
<clever> evanjs: basically, the algo is /nix/store/${hash sha256 name}-${name}
<clever> evanjs: the fetch name, not the main name
<clever> evanjs: if the name is set correctly, you dont have to
<clever> evanjs: and this lets you add another custom out-of-tree thing to a set
<clever> newLinuxPackages = oldLinuxPackages.extend (self: super: { foo = self.callPackage ./foo.nix {}; });
<clever> from the same linuxPackages set the kernel came from
<clever> evanjs: and use linuxPackages.callPackage to load your nix file, if your not yet editing nixpkgs
<clever> ilya_g: change from `-cpu host` to `-cpu Haswell`, or go backwards to the original `-cpu kvm64`
<clever> ilya_g: either override or edit nixpkgs, to undo that change, or move it to Haswell
<clever> ilya_g: the commit was made in april, but the PR didnt get merged until 12 days ago!
<clever> ilya_g: https://github.com/NixOS/nixpkgs/commit/2bd296a7e9551fcc74330460d6bf47810a8f9555 and click the PR link within the header
<clever> ilya_g: where you building from a channel other then unstable?
<clever> 'kvm64' is the most generic CPU, which does not support SSE4.2, AVX and other ISA extentions.
<clever> ilya_g: yep, it was changed last year
<clever> - x86_64-linux = "${qemuPkg}/bin/qemu-kvm -cpu kvm64";
<clever> + x86_64-linux = "${qemuPkg}/bin/qemu-kvm -cpu host";
<clever> Date: Thu Apr 18 19:35:51 2019 +0000
<clever> commit 2bd296a7e9551fcc74330460d6bf47810a8f9555
<clever> $ git log --patch nixos/lib/qemu-flags.nix
<clever> ilya_g: if you override lib.qemuBinary, that might fix it
<clever> ilya_g: ahhh, thats why
<clever> ]$ vi nixos/lib/qemu-flags.nix
<clever> 19 qemuBinary = qemuPkg: {
<clever> 20 x86_64-linux = "${qemuPkg}/bin/qemu-kvm -cpu host";
<clever> ilya_g: i dont see a -cpu host, on nixpkgs master
<clever> 195 qemuCommandLinux = ''
<clever> 197 -nographic -no-reboot \
<clever> 196 ${qemuBinary qemu} \
<clever> $ vi pkgs/build-support/vm/default.nix
<clever> ilya_g: you will also want to read the original nix expr for this
<clever> ilya_g: the problem is the -cpu host, which isnt as smart, you may be able to use -cpu again to overwrite it
<clever> ilya_g: the shell script qemu-kvm will test if /dev/kvm exists, and automatically omit -kvm if it doesnt
<clever> ilya_g: the gist contains a script that generates a script
<clever> ilya_g: but we want the output, not the buildCommand, which is in line 1 of your gist, now /nix/store/7cf2ziyfwd7r4dpxy46mf8fpcblgscgk-vm-run
<clever> ilya_g: that will extract 1 field for you
<clever> ilya_g: b: run `nix-store --query --binding buildCommand /nix/store/hash-vm-run.drv`
<clever> ilya_g: a: the path i gave you was the output, not the .drv file, that one is much cleaner
<clever> yeah
<clever> ilya_g: manually run the same nix-build in the container, to create the file
<clever> ilya_g: you have to run it in a container that has attempted to build the disk image
<clever> and then it "just works" without poluting your $PATH with things
<clever> boogiewoogie[m]: and 51-73 defines a psd-resync, that runs at a set interval
<clever> boogiewoogie[m]: line 34-49 defines a psd service, that will always be running, and it runs sync on startup, and unsync on shutdown
<clever> boogiewoogie[m]: step 3, read lines 30-77, and see that it never adds anything to systemPackages, it just configures a usermode timer, to run it at a given interval
<clever> boogiewoogie[m]: step 1, search for the option on https://nixos.org/nixos/options.html
<clever> ilya_g: just open a shell in the container and run cat on it
<clever> ilya_g: that is the shell script nix runs in this derivation
<clever> ilya_g: next, we need the contents of /nix/store/7cf2ziyfwd7r4dpxy46mf8fpcblgscgk-vm-run as well
<clever> ilya_g: my irc client doesnt react when you prefix messages with an @
<clever> jared-w: things only get incremental if you can rsync the result from local?root= and copy the differences
<clever> jared-w: --export and `nix copy --to local?root=` both produce the full closure, not incremental
<clever> ilya_g: you need to run the query in the container, after the build fails
<clever> ilya_g: the exact path, depends on the hash of all of the inputs, so it might change when you edit the source
<clever> OR[m]: if the additions within the latest nixpkgs are still too old, you may need to do what Yaniel said
<clever> OR[m]: sudo nixos-rebuild --upgrade switch`
<clever> ilya_g: what does `nix show-derivation /nix/store/cz3pxdglzyfq6nf6mxd8hcpdck9x6m3v-nixos-disk-image.drv` reveal?
<clever> ilya_g: thats weird, lines 1-8 show part of qemu did work, so why is it failing on 12
<clever> ilya_g: that gist says nothing about if kvm is working or not
<clever> ilya_g: does the old configuration still work? with the old nixpkgs
<clever> ilya_g: do you have the old code that used to work? how has it changed since then? does the old code still work?
<clever> ilya_g: but nested virtualisation likely isnt enabled, so you cant get kvm to work in darwin docker
<clever> ilya_g: docker on darwin lies to you, its running a full linux distro, in a vm, and then running linux docker within that
<clever> ilya_g: does it exist on the host?
<clever> ilya_g: does /dev/kvm exist within the docker container?
<clever> ilya_g: you either need to tell qemu to not use kvm, or ensure that /dev/kvm exists within the docker container
<clever> marek: as long as you ensure you only replace the right bytes, and dont change the lenght of the thing your replacing, you can patch almost any compiled binary like that
<clever> marek: the binary patching, is basically just replacing a char *foo="biglongstring"; with "small\0\0\0\0\0" (of the same length)
<clever> marek: haskell solves this with file-embed, build it once, with a magic string in the binary, then have a cheap derivation that will basically sed a new version into the raw binary
<clever> jared-w: once it lands in /nix/store, the dynamic stuff will keep working
<clever> jared-w: they dont have to be staticly linked, just import them the same way your importing this closure
<clever> that also sounds like an improvement
<clever> jared-w: but if your crappy UI lacks recursive upload, thats going to be even worse :P
<clever> jared-w: the benefit that has over --export, is that it only copies what is missing from the usb stick, so changes are incremental
<clever> jared-w: one idea i have had in the past, to deal with air-gapped machines, is to `nix copy --to local?root=/mnt/usb` then physically move the usb stick over the air gap, and --from on the other end
<clever> marek: you can then route that string down to whatever is building the version file
<clever> jared-w: the --export lacks signatures by default, and you need to either sign everything yourself, or disable signatures when importing
<clever> marek: this code is providing a default, for when hydra wasnt in use
<clever> marek: if you have an input named foo in hydra, then hydra will pass release.nix an attrset named foo, that contains the revision
<clever> jared-w: step 1, fix whatever is forcing you to jump thru such hoops :P
<clever> marek: hydra passes the git revision to release.nix as an argument
<clever> jared-w: there can be more optimal ways
<clever> jared-w: although, how are you uploading it to the machine?
<clever> jared-w: thats where i prefer `nix copy --to local?root=/dir`, then you can tar it up or rsync it over
<clever> jared-w: i use code like this, to bundle all of the things from niv into a single derivation (called ifd-pins here), and then you can nix-build and copy-closure that
<clever> so you need to copy that seperately
<clever> but the --export doesnt include the eval-time closure and IFD stuff
<clever> jared-w: that would be the pinned nixpkgs, which niv is downloading
<clever> jared-w: and why do you think its trying to download a channel?
<clever> jared-w: you can also --option substituters 'local?root=/mnt https://cache.nixos.org' to make nix look in there, and grab what it can
<clever> jared-w: nix copy --to local?root=/mnt/ might be simpler to manage
<clever> jared-w: --export doesnt generate a nar, it generates a stream containing many nar's
<clever> evanjs: what does --show-trace show?
<clever> heh
<clever> evanjs: --show-trace
<clever> evanjs: something must be adding it to extraKernelModules
<clever> gchristensen: i was also experimenting with a method of forking, to reduce heap and speed up eval, when we where at nixcon, its currently stalled in segfaults and concurrency bugs
<clever> rnhmjoj: something is -9'ing the entire eval
<clever> rnhmjoj: if nothing has changed, then it may not make a new eval
<clever> evanjs: recurseIntoAttrs only comes into play if you do nix-env -q
<clever> rnhmjoj: and only if everything under tested is green, will the channel then update
<clever> rnhmjoj: so once a day, it will eval the build inputs (also on the config page), and build whatever they contain
<clever> rnhmjoj: yep
<clever> rnhmjoj: you have to go up to the jobset overview first, then configuration
<clever> evanjs: are you trying to nix-build the entire kernelPackages or just .kernel?
<clever> evanjs: not sure what is causing that
<clever> rnhmjoj: check the configuration tab of the jobset
<clever> evanjs: yeah
<clever> then you would want to load it with callPackage, and change line 1 to just linuxPackages, linuxPackagesFor
<clever> evanjs: its in imports, so it must set boot.kernelPackages, not return a set of linuxPackages
<clever> evanjs: is this a module (in imports) or a package (loaded with callPackage)
<clever> evanjs: looks like it should be fine at a glance

2020-02-12

<clever> aminechikhaoui: and which user does /etc/nix/machines say to ssh into?
<clever> aminechikhaoui: .bashrc or /etc/bashrc ?
<clever> aminechikhaoui: `ssh user@host nix-store --version` is another test
<clever> aminechikhaoui: ~/.bashrc
<clever> pie_[bnc]: the phase functions still exist
<clever> pie_[bnc]: you can do patches with runCommand
<clever> pie_[bnc]: probably
<clever> gchristensen: i dumped a bunch of stuff in #nixos-on-your-router
<clever> ah
<clever> Profpatsch: when something like sudo or ssh asks for a pw, it opens /dev/tty, which bypasses any redirections, and goes to the tty that spawned it
<clever> gchristensen: i have the powah!
<clever> xavierzwirtz[m]: libredirect should work on any dynamic library, its using LD_PRELOAD to overwrite the open() function
<clever> gchristensen: curl https://github.com/cleverca22.keys