2019-11-18

<clever> but none of the profiles are setup, so youll need to manually run `/nix/store/hash-nix/bin/nix-env -i /nix/store/hash-nix` after you boot the system, and fix permisions and such
<clever> aranea: that will copy a given storepath to /mnt/nix/store
<clever> aranea: nix copy --to local?root=/mnt /nix/store/hash-nix
<clever> colemickens: the network is always disabled while building, nix must fetch the deps for you
<clever> less confusing that way
<clever> i try to only use channels on root
<clever> niso: what does nix-channel --list report?
<clever> the function i mentioned
<clever> niso: and channels_root/ will update if you run update as root
<clever> niso: yeah
<clever> chessai made a vim function that runs nix-prefetch-url, i still need to see how it works
<clever> etu: same as the number of cards in a deck i believe
<clever> that will insert 52 0's
<clever> in vim, you can just 52i0<escape>
<clever> that will build it with the new ui, but not apply, so you still need to follow it up with a nixos-rebuild switch
<clever> magneticduck: nix build -f '<nixpkgs/nixos>' -A system
<clever> fresheyeball: check the storepath you and MichaelRaskin pasted
<clever> fresheyeball: your on version 2.24
<clever> lovesegfault: the only real benefit home-manager has, is for non-nixos users that want the same benefit
<clever> lovesegfault: the same way such modules got written for home-manager (which duplicates some nixos stuff)
<clever> dminuoso: but a nixos module to configure those things could easily be made
<clever> magneticduck: or, why did you update the channel and then not nixos rebuild immediately to save yourself that problem a week later :P
<clever> magneticduck: its more a question of, do you want to download 2gig of apps to update 1 config file, or split it into 2 groups?
<clever> magneticduck: yeah, i could also use another channel to pull plex in from stable
<clever> i have to give up plex (or move it to nix-env) if i want to rebuild
<clever> for example, plex-media-player doesnt build on master, so i cant nixos-rebuild at all
<clever> magneticduck: oh, and the ability to nixos-rebuild, without non-system stuff blocking the update
<clever> magneticduck: about its only major value, in my eyes, is multi-user nixos machines, or getting the same setup on a non-nixos machine
<clever> magneticduck: everything else it does could be done with nixos
<clever> magneticduck: i think about the only thing you really gain from home-manager, is the ability to modify things without having root
<clever> lovesegfault: tells you if something is an element in a list
<clever> infinisil: its more of just a shortcut, you basically always need stdenv, saves you from adding another arg to callPackage inputs
<clever> ive seen bigger
<clever> or stdenv.lib
<clever> not sure then
<clever> LarryTheCow: does `ls /sys/firmware/efi/efivars/ | grep -i system` find anything related to systemd?
<clever> Boot0001 is the important one
<clever> LarryTheCow: the man page should explain how to remove entries
<clever> LarryTheCow: i dont think they are the problem, but it cant hurt to clean them up
<clever> LarryTheCow: i see evidence of 2 previous ESP's, which may or may not exist anymore
<clever> LarryTheCow: what does `efibootmgr -v` print out?
<clever> LarryTheCow: what does systemd-boot show?
<clever> LarryTheCow: is /boot mounted?
<clever> so you just need the name to also match
<clever> the hash matches the drv file
<clever> "outputHash": "09i467hyskvzj2wn5sj6shvc9pb0a0rx5iknjkkkbg1ng3bla7nm",
<clever> hr[m]: try adding `--name source` as well
<clever> did you include --unpack ?
<clever> hr[m]: try nix-prefetch-url --unpack file:///path/to/file ?
<clever> hr[m]: if it results in anything other then /nix/store/zjwrdr9wz0dacqximknidpf27sfbw762-source, then it failed
<clever> try the cmd i gave above
<clever> hr[m]: or use `nix-prefetch-url --unpack`
<clever> hr[m]: so you must nix-store --add a directory, after you unpack the tar file
<clever> hr[m]: this is the result of pkgs.fetchzip
<clever> "outputHashMode": "recursive",
<clever> hr[m]: can you pastebin the output of `nix show-derivation /nix/store/gp78c3dj8awxd85s0vr8wqgd9ny2plvv-source.drv` ?
<clever> 2019-11-18 01:03:58 * hr[m] sent a long message: < >
<clever> hr[m]: i cant even see the question!
<clever> mog: and then add that package to services.udev.packages
<clever> other paths?
<clever> wedens[m]: it does use $NIX_PATH, it will search for <nixpkgs>
<clever> infinisil: if you put the url right into NIX_PATH, it wont get the new url till you reopen the shell
<clever> infinisil: ah, thats similar to what i do
<clever> infinisil: i think this will fetch a given rev, and add it to the channels list
<clever> 2019-11-17 03:49:22< clever> wedens[m]: if you `nix-channel --add https://githib.com/nixos/nixpkgs/archive/REV.tar.gz nixos`, and then `nix-channel --update nixos`, it will fetch the given rev
<clever> infinisil: it is possible to point nix-channel to a single rev i believe
<clever> infinisil: main issue ive seen with that, is the change wont take effect until you reload all shells
<clever> so it will put jobs on a certain machine first
<clever> lovesegfault: with remote builders, you also have a speed factor, which tells nix the relative speed difference between machines
<clever> thats for things where copying is more expensive then building
<clever> this build will try to skip the remote build machines, and build on the local instead
<clever> you also have the reverse
<clever> > removeReferencesTo.preferLocalBuild
<clever> chromium is a wrapper script, that sets env vars
<clever> > chromium.browser.requiredSystemFeatures
<clever> so nix wont allocate it to weaker machines
<clever> the kernel is specially flagged to only run on build machines that have the "big-parallel" feature
<clever> > linux.requiredSystemFeatures
<clever> thats where system features like big-parallel and preferLocalBuild come into play
<clever> ah
<clever> what could be optimized more?
<clever> lovesegfault: the topo-sort forces it to build gcc first, before it can do anything else
<clever> so it doesnt delete the A packages every single time
<clever> one weird thing i discovered in the garbage collection code, is that it intentionally random-sorts the entire list of garbage, before deleting things
<clever> plus a topo-sort
<clever> 2019-11-15 22:11:51-{^_^}:#nixos- [nixpkgs] @jonringer opened pull request #73481 → steam: use 32bit version of libva → https://git.io/JeoZN
<clever> dont remember the exact difference between disk-image-tests and example
<clever> lordcirth__: and then nix-build '<nixpkgs/nixos>' --arg configuration ./example.nix
<clever> you probably want to load nixpkgs/nixos instead, and pass this in as a config file
<clever> lordcirth__: there is also nothing special to the name config.system.build.laptop, you can just shorten that out
<clever> {}
<clever> just import ./nixpkgs {]
<clever> lordcirth__: rather then importing top-level, you want to import the default.nix in the root dir
<clever> lovesegfault: --argstr system i686-linux
<clever> lovesegfault: rec {
<clever> lovesegfault: it must be in a let block, above stdenv.mkDerivation
<clever> lovesegfault: so you could just ignore the 64bit version
<clever> lovesegfault: also of note, you can run the 32bit version on a 64bit os without trouble, 99% of the time

2019-11-17

<clever> lovesegfault: but it rejects any binary with the "wrong" value
<clever> lovesegfault: also, it has a path in the headers to the dynamic linker (like ld.so)
<clever> lovesegfault: the darwin kernel rejects any binary that isnt dynamic
<clever> though darwin doesnt allow static binaries
<clever> lovesegfault: and these let you figure out if you need otool or patchelf
<clever> > stdenv.isLinux
<clever> > stdenv.isWindows
<clever> > stdenv.isDarwin
<clever> lovesegfault: a lookup table lets you add more systems in the future
<clever> > let table = { i686-linux = "a"; x86_64-linux = "b"; }; in table.${stdenv.system}
<clever> you can also use a lookup table
<clever> > stdenv.system
<clever> lovesegfault: use an if statement against stdenv.system
<clever> lordcirth__: nixos/lib/make-disk-image.nix
<clever> mikky: and what is the contents of configuration.nix?
<clever> mikky: that should have worked, what is the exact command you used?
<clever> mikky: but if you specify 2 paths like that, things wont work right
<clever> mikky: i also notice you gave nix-build 2 files, nixpkgs and nixpkgs/nixos/release.nix
<clever> mikky: then netboot.x86_64-linux should work
<clever> mikky: if you instead `nix repl nixpkgs/nixos/release.nix`, and eval `netboot`, what does it contain?
<clever> mikky: might just be that master is broken
<clever> mikky: are you on a channel or master?
<clever> darthdeus: nix-build --dry-run i think
<clever> mikky: and rather then supportedSystems, you want -A netboot.x86_64-linux
<clever> mikky: i think you want `--arg configuration 'import ./my-custom-config.nix'`
<clever> Yaniel: https://github.com/NixOS/nixpkgs/pull/73299 is the wpa issue
<clever> not much point in activating things and then immediately rebooting
<clever> shapr: if your planning to reboot, use `nixos-rebuild boot`
<clever> switch loaded things in a different (working) order, compare to booting
<clever> so if i reboot, wpa_supplicant can no longer start
<clever> but, the act of loading bonding, breaks wpa_supplicant
<clever> a recent problem i had, is that bonding can start up just fine, if thats all that changed
<clever> so switch is basically test+boot
<clever> and test will activate without touching the bootloader config
<clever> shapr: boot.kernelPackages = pkgs.linuxPackages_latest;
<clever> mikky: i add them to the imports section of configuration.nix, and it builds with the rest of nixos
<clever> mikky: netboot_server.nix and justdoit.nix are nixos modules
<clever> mikky: justdoit.nix?
<clever> its a bash script that will partition, format, mount, and nixos install
<clever> mikky: 48 then puts the entire thing into the root dir for nginx
<clever> mikky: 11 pulls in the netboot stuff, 12 pulls in a custom module, 13 configures it, and then 16-19 are copied from release.nix
<clever> niso: oh, i avoid them whenever possible :P
<clever> kolbycrouch: normal wpa_supplicant
<clever> maybe ~/.zshrc?
<clever> wedens[m]: you can also test with `ssh user@host nix-store --version`
<clever> wedens[m]: thats an issue due to .profile not being source for non-interactive shells, you need to make sure PATH gets updated in .bashrc too
<clever> wedens[m]: that allows the build machine to use its own substituters, but both machines will still pre-download the inputs, then realize they didnt need it
<clever> some time*
<clever> but it will waste some copy copying the inputs over
<clever> yep
<clever> wedens[m]: if its not a substituter, it will download the build-time deps, copy them to the build machine, then instantly 'build' the thing, and copy the result back
<clever> wedens[m]: that would just help the performance a little bit
<clever> kolbycrouch: networking.interfaces.<name?>.ipv4.addresses.*.address
<clever> lovesegfault: the default unpack code expects all tar files to product a directory of things
<clever> lovesegfault: maybe: unpackPhase = "unpackFile $src ; export sourceRoot=.";
<clever> lovesegfault: unpackPhase = "unpackFile $src";
<clever> wedens[m]: and if you arent home, `nixops deploy --include laptop` to limit it to just one
<clever> wedens[m]: to manage multiple machines at once, so you can just run `nixops deploy` on the laptop, and it updates both laptop&desktop
<clever> wedens[m]: so the laptop can build things on its own, and optionaly farm it out to other systems to speed itself up
<clever> wedens[m]: i would make the laptop run nixops, and configure the desktop to be a build machine
<clever> wedens[m]: nixops doesnt copy the configuration.nix file over, so you would need to sync that over yourself first
<clever> ,callPackage lovesegfault
<clever> lovesegfault: looks fairly close, what happens if you try to nix-build it?
<clever> wedens[m]: why do you need the build-time closure on the remote machine?
<clever> wedens[m]: nixops only copies the runtime closure to the remote machine
<clever> you can also toss in a `pwd` and `ls -lh` to see what you have to copy from
<clever> yeah
<clever> and { inherit (a) b; } is just { b = a.b; }
<clever> lovesegfault: basically, { inherit a; } is just { a = a; }
<clever> lovesegfault: fetchurl and stdenv
<clever> lovesegfault: stdenv.mkDerivation will unpack the src for you
<clever> lovesegfault: though, you could also use the postFetch on fetchurl, to move it there
<clever> lovesegfault: then a non-fixed output (like stdenv.mkDerivation or runCommand) to copy it to $out/bin/foo
<clever> lovesegfault: you would use fetchurl to generate a fixed-output drv that downloads it
<clever> so you dont have to relaunch your shells to make the new NIX_PATH take effect
<clever> it also means the NIX_PATH variable wont change, instead, your updating a dir that NIX_PATH points to
<clever> wedens[m]: which can cause delays if you try to run stuff without internet
<clever> wedens[m]: if its in NIX_PATH, nix will try to re-download the tar every hour, even though it cant have changed
<clever> wedens[m]: if you `nix-channel --add https://githib.com/nixos/nixpkgs/archive/REV.tar.gz nixos`, and then `nix-channel --update nixos`, it will fetch the given rev
<clever> wedens[m]: you can force nix-channel to use a specific revision, rather then an actual channel
<clever> wedens[m]: thats why i try to avoid changing NIX_PATH, set it to a constant value, and instead change what it points to
<clever> once nix.nixPath has set NIX_PATH, you dont need the -I flags anymore
<clever> nix.nixPath sets NIX_PATH for you
<clever> or just use the right -I flag the 1st time
<clever> id say thats a bug, it should fail hard when you do that
<clever> lovesegfault: text tells home-manager to write it to a file for you, source says to copy an existing file
<clever> lovesegfault: you want only text or source, not both
<clever> lovesegfault: Logs: https://logs.nix.samueldr.com
<clever> > writeText "foo.json" (builtins.toJSON { a="${hello}"; })
<clever> if you need to, you need to switch to pkgs.writeText
<clever> so you cant do that
<clever> > builtins.toFile "foo.json" (builtins.toJSON { a="${hello}"; })
<clever> toFile has the limit that the file cant depend on anything
<clever> and that returns a path it gets written to
<clever> > builtins.toFile "foo.json" (builtins.toJSON { a=42; })
<clever> lovesegfault: yep, you can use it anywhere in nix
<clever> > :p builtins.toJSON { a=42; b="two"; }
<clever> i use nix for the templating, the json for the transfer to other stuff
<clever> lovesegfault: why do we need yet another text format for cfg? https://xkcd.com/927/
<clever> i heard the same is true for toml somewhere, but i cant remember where
<clever> lovesegfault: though i heard its a superset of json, so if you just .toJSON, you can still parse it as toml
<clever> lovesegfault: there is a fromTOML but no toTOML
<clever> but thats dirty
<clever> lovesegfault: though you can builtins.getEnv to read env vars...
<clever> lovesegfault: dont think so, thats only visible in nixos modules
<clever> nope
<clever> yep
<clever> all of the options your setting, appear under config
<clever> lovesegfault: config.boot.kernelPackages
<clever> you cant know the value of networking.hostName until you know what all the imports are
<clever> also, that will fail
<clever> if you append a string to a path, you get a path
<clever> lovesegfault: imports = [ (./machines + "/${name}.nix") ];

2019-11-16

<clever> dansho: and since you didnt, it was running nix-shell for you, inside another nix-shell
<clever> dansho: i think you want to give stack.yaml the path to a shell.nix file, and stack calls nix-shell for you
<clever> screen recording and rdp dont work for me
<clever> i think virtualbox only needs to be compiled specially for usb3 support to the guest and some of the more advanced features
<clever> evanjs: guest additions work on my windows guest, without having to build the host stuff
<clever> evanjs: 4.19.37 on the router
<clever> i havent changed any special flags, so my vbox comes from the binary cache
<clever> evanjs: my router has a dual-socket Intel(R) Xeon(TM) CPU 3.20GHz, with 8gig of ecc ram
<clever> evanjs: those are the scripts that watch a hydra, and update channels
<clever> evanjs: you could even just have your own custom channel, that only updates when all machines build, then point auto-upgrade to that!
<clever> evanjs: thats basically how nix-channel's are managed
<clever> evanjs: so i moved it to my nas
<clever> evanjs: initially, i ran hydra on the router, but the hdd was too io bound
<clever> and hydra will distribute the work between things, and avoid duplicating it
<clever> evanjs: then i can check hydra and see how healty things would be if i choose to upgrade
<clever> evanjs: instead, i have a hydra configured to build my config against unstable, but not apply the changes to any machine
<clever> autoUpgrade would keep updating the channel on me, and cause Thra11's issue, where i have to issue 20 rollbacks to get to a working revision
<clever> if i want to keep using it as is, i need to avoid updating channels, until i fix that
<clever> evanjs: for example, slim was recently deprecated, so my config no longer even builds on the latest nixos-unstable
<clever> evanjs: not directly, but the changes it brings in may
<clever> evanjs: i try to avoid auto-upgrade, since it can lead to unexpected breakage
<clever> Thra11: not really
<clever> evanjs: yeah, sshServe just serves whatever is in /nix/store/
<clever> dansho: and how did you load that nix file?
<clever> evanjs: but if its only for personal use, sshServe seems simpler
<clever> evanjs: you could garbage collect things with sshServe, and you need enough storage and bandwidth to host the things you want to share
<clever> ,libraries dansho
<clever> and also --delete-generations
<clever> [root@amd-nixos:~]# nix-env --profile /nix/var/nix/profiles/system --list-generations
<clever> Thra11: you could delete the bad generations after you rollback, so they are skipped
<clever> Thra11: rollback goes to current-1, not previous, ive ran into that problem before
<clever> but if you only have 1 flag, it doesnt really matter
<clever> just cfg.enable
<clever> sondr3: the let cfg= is just a handy shortcut, so you dont have to type config.mine.blah everywhere
<clever> sondr3: one is using options which isnt the right way to read the config
<clever> random_user: did you plug it in while the machine was off?
<clever> betawaffle: builtins.readFile ./foo.txt
<clever> betawaffle: builtins.readFile ?
<clever> timokau[m]: yeah, the nix exprs and evaluation happens entirely on the user side, and nix-daemon doesnt know how to parse nix files
<clever> timokau[m]: though you can get similar if you bake a copy of nixpkgs into /run/current-system/nixpkgs
<clever> timokau[m]: thats what nix-channel mostly saves you from, keep NIX_PATH constant, and change the dir (or symlink) its pointing to
<clever> timokau[m]: logging out and back in may also do it
<clever> timokau[m]: it also only takes effect after you relaunch the shell
<clever> timokau[m]: nix.nixPath only takes effect after nixos-rebuild completes, and wont affect the current build
<clever> xwvvvvwx: what file are you changing, what command are you running?
<clever> xwvvvvwx: that should detect changes every time you re-run the nix commands
<clever> xwvvvvwx: how are you importing nixpkgs from a local copy?
<clever> FRidh: there is also the escape-hatch of builtins.exec
<clever> FRidh: then you can just `nix-shell -A action` and the shellHook will run things, with the buildInputs already in PATH, and then shellHook can either `exit 0` or `exit 1`
<clever> FRidh: i just use shellHook in nix-shell
<clever> srhb: wooo!
<clever> otwieracz: you may need to configure nixos-container to bind mount /dev/fuse into the guest
<clever> otwieracz: does /dev/fuse exist in the container?
<clever> i see over 6 PR's involved in adding libva to steam, in recent irc logs, lol
<clever> 2019-11-12 10:16:05-{^_^}:#nixos- [nixpkgs] @worldofpeace merged pull request #73281 → [19.09] steam: Add libva to chrootenv → https://git.io/JewXK
<clever> 2019-11-10 09:10:39-{^_^}:#nixos- [nixpkgs] @ikervagyok opened pull request #73157 → steam: add libva as a dependency, otherwise steam doesn't start anymore → https://git.io/JeVNz
<clever> 2019-11-15 22:11:51-{^_^}:#nixos- [nixpkgs] @jonringer opened pull request #73481 → steam: use 32bit version of libva → https://git.io/JeoZN
<clever> and you need to either remove one of the values, or use lib.mkForce
<clever> nixos will complain that you set the value twice
<clever> and it would still work under imports
<clever> but its not really using the pkgs key, so line 1 could be deletded
<clever> how are you importing the set?
<clever> lovesegfault: i just spew things all over the root dir :P
<clever> srhb: another weird thing, is that the string type, complains if you set it to both "foo" and "foo"
<clever> srhb: but if you set type = types.bool;, it will silently merge true and true, but complain about true and false
<clever> srhb: yep
<clever> srhb: if you dont set the type of something, then set the value to both true and false, it will silently true
<clever> ,locate bin shutdown
<clever> srhb: i was also horified to discover, that if you dont set a type on something, the default merge rule inspects the types of the 2 args, and for bools, will just logical or them
<clever> and the type of a
<clever> lovesegfault: depends on if the set cointains more options or is an option itself
<clever> gjabell: i often find it simpler to just clone and grep, but that doesnt work when you dont know what to clone
<clever> lovesegfault: but i only use it for the slack plugin and nothing else
<clever> so grub still points to an x86 nixos
<clever> lovesegfault: when you nixos-rebuild under arm, it only updates the arm bootloader config
<clever> lovesegfault: so you just get 2 builds of nixos in using nix-copy-closure, and then configure 2 different bootloaders, to start at different paths
<clever> lovesegfault: the trick, is that nix just lets storepaths from other arches co-exist in /nix/store/