2019-02-13

<clever> :D
<clever> stites: you could also make a modified ISO with justdoit.nix in the imports, or just do a "normal" install to a usb stick, with justdoit.nix in the imports section
<clever> ssh back in, justdoit, and boom, its now nixos, all previous data is toast (youll want to not do that, i believe)
<clever> stites: so you just upload the tarball to any linux machine, unpack it to /, run /kexec_nixos, and boom, its running nixos entirely from ram
<clever> stites: the main thing in that directory, is a set of nix scripts to generate some kexec utils
<clever> stites: that module is added to the installer image, so the binary is in $PATH when you boot the installer
<clever> stites: i think it will work both ways, as long as you dont touch `zpool upgrade` or `zpool enable`
<clever> stites: you could also upgrade it from a single vdev to a mirror, using zpool attach
<clever> stites: https://github.com/cleverca22/nix-tests/blob/master/kexec/justdoit.nix is how i do most of my installs
<clever> stites: you could also try using /nix/var/nix/profiles/system/init as your stage2 init
<clever> stites: my only thought right now is that its maybe slow for one of the vdev's to come online, and stage2 is giving up
<clever> stites: not sure what the issue is then, would need to see more output as it boots
<clever> stites: also, is this booting in a vm, or on hardware?
<clever> some of those env vars may already exist, check with echo
<clever> stites: then youll need to manually mount root to /mnt-root, nix to /mnt-root/nix/ and then pivot_root manually
<clever> stites: and what does `zfs get mountpoint zroot/NIX/nix` say?
<clever> stites: what does `echo $$` say?
<clever> stites: one sec
<clever> stites: and then `zfs list` again, shows what?
<clever> stites: and if you try to `zpool import zroot`, what does it say?
<clever> stites: what does `zfs list` say?
<clever> stites: i dont think the number of vdevs has any impact on how nixos boots
<clever> yokyolu: also, that error message is far better then it used to be, it used to treat "command not found" as a series of 32bit ints, and then complain with the 1st int, lol
<clever> nix-store (Nix) 1.11.4
<clever> $ ssh clever@c2d nix-store --version
<clever> yokyolu: `ssh user@remote nix-store --version`
<clever> yokyolu: you can also use builtins.filterSource or lib.cleanSource, to limit what gets copied to /nix/store as it imports
<clever> dckc: i think you want the single-user mode for now
<clever> ,libraries samrose
<clever> yokyolu: did you do src = ./.; ?
<clever> mek42_laptop: i use nixos on my desktop, laptop, nas, and router

2019-02-12

<clever> oh, thats where it comes from
<clever> IFS='-' read -ra CHECKOUT <<< $checkout
<clever> change the ln to `-sv` and pastebin the output it makes
<clever> Ankhers: what if there are duplicates in that array?
<clever> Ankhers: your `cp --no-preserve=all` will just overwrite and merge when the target already exists
<clever> Ankhers: if _checkouts/''${CHECKOUT[-2]} exists, then ln will create the symlink inside it, rather then overwriting it
<clever> noonien: i think its for when you want to mutate the artifact with a postfetch script
<clever> catern: i think it always emails the meta.maintainers
<clever> pinkypie: shell.nix cant really do filesystem level things
<clever> fixed-output can basically do whatever it wants to the LAN
<clever> yeah, thats also a security thing ive been wary of
<clever> copumpkin: which is why i only recomend using it with IAM instance profiles
<clever> Vitalii: if IAM instance profiles are configured, there is pkgs.fetchs3
<clever> __monty__: define all 3 derivations in a let block first
<clever> __monty__: do omiting -A refers to derivation1
<clever> __monty__: you can do derivation1 // { key1=..; key2=...; }
<clever> __monty__: put an attrset in it, { key = thing1; key2 = thing2; }
<clever> there is also a checkbox to force allowing proton with "unsupported" games
<clever> 3.16-6 beta is what i use without issues
<clever> on the main settings page, under steam play, you can set the proton version
<clever> fearlessKim[m]: try choosing a different version of proton in steam?
<clever> fearlessKim[m]: it might be that proton is failing to start, do you have 32bit dri and 32bit pulse?
<clever> fearlessKim[m]: with PROTON_LOG=1 set, then proton will emit normal WINEDEBUG style logs to ~/steam-${GAMEID}.log
<clever> -rw-r--r-- 1 clever users 3.7M Feb 4 03:24 steam-544550.log
<clever> fearlessKim[m]: the other thing you can try, is to open the properties for the game, set launch options, `PROTON_LOG=1 %command%`
<clever> Ankhers: for x in ${toString list}; do
<clever> fearlessKim[m]: first, does any other proton game work? does steam print something on stdout when you run it?
<clever> yeah, i just looked closer and see that
<clever> > lib.concatStringsSep "," [ "a" "b" "c" ]
<clever> it does
<clever> > lib.intersperse "," [ "a" "b" "c" ]
<clever> __monty__: what line# does it say the error is on?
<clever> nativeBuildInputs
<clever> bbarker2: you need to add makeWrapper to your nativeBuildIputs
<clever> so it turned into a nix var reference, and didnt fail because the if bypassed it 90% of the time
<clever> related, there was a bug in nixpkgs a while back, where an escaped string was moved from a '' to a " string, but it was also behind an if statement
<clever> and there is the nix-hash command, which can convert both ways
<clever> duairc: there is a string in the nix source, with the entire series of chars it uses
<clever> duairc: part of it may be a font reason, oO0
<clever> bbarker2: then that package should be using wrapProgram to ensure its always set
<clever> bbarker2: why do you want that env var set?, what are you trying to do?
<clever> -A gives you an env suitable for building it, and your expected to then run it from the "wrong" place, so it needs the var
<clever> -p gives you a pre-built copy of wireshark in /nix/store/, so you dont need that env var
<clever> and the env var you pointed out, makes sense only for -A
<clever> -p instead runs the setup-hook files
<clever> bbarker2: shellHook only runs with -A, not -p
<clever> pie_: i typically enable this on my machines, which makes it easy to get backtraces
<clever> the problem, is that nix-build and nix-shell are the same binary
<clever> "" does nothing, so of course it doesnt make $out
<clever> and the error makes perfect sense
<clever> builder for '/nix/store/n0c2pbp0xsrfcj3z6fa02998plsnaf6s-shell.drv' failed to produce output path '/nix/store/zhvllv84l8dcldw1m7h5sapa9nj3ypj9-shell'
<clever> and the runCommand will run "" to build $out (it will never work)
<clever> it dynamically jams your list of packages into the buildInputs of a runCommand
<clever> this is the code behind -p
<clever> nix-shell -p 'callPackage ./foo.nix {}'
<clever> pie_: note, -p already imports nixpkgs for you
<clever> each .md will depend on exactly 1 .odt, and only rebuild when it has to
<clever> __monty__: splitting them up will prevent unnessesary rebuilds
<clever> __monty__: the spaces are the worst part of it, ive done far more complicated things involving 5000 page pdf files and converting it to csv
<clever> srhb: ^^
<clever> siers: but likely wont allow spaces still
<clever> __monty__: the singleOut function here takes a dir like ./. and a path like input, and produces a /nix/store/foo/Chapter 1 - Grey days at Farnfoss.odt
<clever> input is just the name of a file, and nix wont know to copy it, so you must append it to a path like ./.
<clever> ./. at a nix level, is a special value of type path, and when you try to treat it as a string, it magically turns into /nix/store/hash-name
<clever> so you get /nix/store/foo/Chapter 1 - Grey days at Farnfoss.odt
<clever> i think the only solution is to use filterSource that targets 1 file in the dir
<clever> nix doesnt allow spaces in the top-level names within /nix/store/
<clever> but if that file has spaces in its name...
<clever> __monty__: ${src + "/${input}"} is identical to ./file.odt, so it names it after that file
<clever> __monty__: ${src} names it after the directory that ./. is in, but bases the hash on the entire contents of ./.
<clever> which is now based on the hash of that 1 file
<clever> you want ${src + "/${input}"}
<clever> __monty__: you are converting src to a string too early, so its based on the hash of the entire ./. without filtering
<clever> __monty__: ${src}/${input} is the problem
<clever> and i use replace mode in my editor to 0 out a few digits, any time i change a rev
<clever> so if you have a string of 000's, its the wrong one
<clever> i tend to always pick the hash that has more entropy
<clever> got is what it actually downloaded
<clever> wanted is what you put into the nix expr
<clever> > let x = { y = null; }; in x.y or 5
<clever> or also doesnt check for null, but rather, the attr missing entirely
<clever> siers: which you use, depends on the situation your in
<clever> > let x = {}; in x.y or 5
<clever> >let x = {}; in x.y or 5
<clever> let x = {}; in x.y or 5
<clever> > let x = null; in if x == null then 5 else x
<clever> > let f = { a ? 5 }: a; in f {}
<clever> its getting late here, i should head off to bed
<clever> it will automatically figure out what args the file/function wants, and pass them from the right set
<clever> ,callPackage NemesisD
<clever> yokyolu: not really possible to get the list at the nix level i think
<clever> yokyolu: run ghc-pkg list?
<clever> yokyolu: not easily
<clever> and when its done, nix-copy-closure the result back the other way
<clever> Shados: `nixos-rebuild dry-run` should show a drv path at the very end, run `nix-copy-closure --to root@remotebox /nix/store/thatfile.drv`, then on the remote box, `nix-store -r /nix/store/thatfile.drv` to build it elsewhere
<clever> Shados: do you have access to another machine with nix(os)?
<clever> yokyolu: its inside a let block, and only ever passed to withPackages, so you cant really access it
<clever> pie___: split outputs can make things more tricky, but luckily, there is a helper for this
<clever> > lib.makeLibraryPath [ sqlite ]
<clever> pie___: not really
<clever> > "${sqlite}/lib"
<clever> so you need to wrapProgram the script with LD_LIBRARY_PATH to work around that
<clever> because what you have to patchelf into it, depends on what .py file you ran
<clever> the problem with python and other scripting languages, is that you cant patchelf the python binary
<clever> pie___: (propagated)buildInputs just magically adds to the buildInputs of other derivations, and nothing more
<clever> pie___: you need to add sqlite's lib folder to LD_LIBRARY_PATH
<clever> yokyolu: you will need to override the .env directly, as in the example i gave
<clever> yokyolu: your only choice is to .overrideAttrs the .env
<clever> yokyolu: ah dang, its the args passed to shellFor, not mkDerivation
<clever> yokyolu: all args to the original drv are also in the .env, so overrideCabal could maybe be used

2019-02-11

<clever> gchristensen: to sign windows binaries without ever putting the key into the nix store
<clever> was going to link some upstream docs here
<clever> 22 will likely fail the same way
<clever> dckc: move it to between 5&6, so its in the let block
<clever> dckc: line 19, you are passing a function to a derivation, that isnt allowed
<clever> while evaluating the attribute 'cellBuilder' of the derivation 'i2b2-hive-cells' at /nix/store/98f2ynld46gvwi26xh69f17hlgqa9kwy-nixpkgs-19.03pre166613.c052da08dcb/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:185:11:
<clever> dckc: can you pastebin your entire nix file?
<clever> dckc: add --show-trace to the build command, then check the line numbers it refers to
<clever> it needs () to force the function to be ran
<clever> that is a list with a function, and a something
<clever> dckc: are you running a function inside a list?
<clever> gchristensen: do you know if the docs already explain builtins.exec?
<clever> stressedprogramm: what does `nix-instantiate --find-file nixpkgs` return?
<clever> looks to be a package to me :S
<clever> > jetbrains.webstorm
<clever> but now you can do it in nix, rather then bash
<clever> so you will need to use some string manipulation logic to do something smarter then baseNameOf
<clever> __monty__: the name (the 1st arg to runCommand) contains a space here: https://gist.github.com/cleverca22/c9ac52d5b3dccc064a82c33418d67d54#file-example-nix-L7
<clever> __monty__: as i said, nix doesnt allow spaces in derivation names
<clever> NemesisD: you will need to include iana-etc in your image: https://github.com/input-output-hk/cardano-sl/blob/develop/nix/docker.nix#L58
<clever> NemesisD: first problem you will run into, is that /etc/protocols doesnt exist, so all network in haskell code immediately fails hard
<clever> NemesisD: i use it for some things
<clever> nvm, nDuff found something better then what i was about to write
<clever> __monty__: ah, then it does need some quotation, one sec
<clever> __monty__: i'm guessing line 8 of my original example, should be "${input}"
<clever> __monty__: at which level? what is the exact error?
<clever> __monty__: the paths there are based on the name= from the inputs, and nix does not allow spaces
<clever> das_j: both need to be combined with foldl' to operate on more then 2 items
<clever> das_j: lib.recursiveUpdate is a recursive one, // is non-recursive
<clever> __monty__: oops, you need to run toString on that
<clever> iqubic: if ~/data does exist, then ~/data/data is the name of the link
<clever> iqubic: `ln -sv ~/some/long/file/path/here/data ~/data` wukk create such a link, but only if ~/data does not yet exist
<clever> __monty__: you can also replace <nixpkgs> with (builtins.fetchTarball https://github.com/nixos/nixpkgs/archive/GITREV.tar.gz)
<clever> iqubic: i always do `ln -sv` and then look at the output to see what it did
<clever> __monty__: so you could use <nixos-unstable> if you have a channel by that name
<clever> __monty__: just replace <nixpkgs> with an expression for another channel
<clever> __monty__: i used `with import <nixpkgs> {};` so all of nixpkgs is in scope
<clever> so you can use self to refer to your own attrs
<clever> lib.fix (self: { ... }) will just pass the function its own return value
<clever> but any change to a, has zero effect on b, and that can make things difficult down the road
<clever> rec allows you to do: rec { a=5; b=a; }
<clever> __monty__: its baiscally the same as rec, but it doesnt suck as much
<clever> __monty__: just drop that into a directory full of .odt files, and run `nix-build example.nix -A allMds`
<clever> __monty__: writing an example...
<clever> and then you can loop over that list of derivations, and join them with a cat ${toString thelist} > $out in a final derivation
<clever> you can then generate a seperate derivation for every file of interest, creating one novel.md per file
<clever> __monty__: that will give you the listing of files in a given directory
<clever> builtins.readDir ./.
<clever> __monty__: that would also offer more caching
<clever> __monty__: you could also use builtins.readDir possibly
<clever> yokyolu: you could wrap and override it: haskell.lib.overrideCabal (.callCabal2nix ...) (drv: { ... })
<clever> __monty__: is there another language where you would prefer to do the string magic? or are the chappter numbers more predictable?
<clever> yokyolu: oh, you also have to trust the public key of that cache, via trusted-public-keys
<clever> __monty__: so you cant easily use the output of pandoc in the nix code
<clever> __monty__: the problem, is that the nix expressions have to run to completion, before the bash stuff even starts
<clever> yokyolu: if you add that to the substituters list in nix.conf, then it will work automatically
<clever> __monty__: you should be able to use normal bash logic to do that, as long as you escape every ${ via ''${
<clever> __monty__: what exactly are you trying to do?
<clever> NemesisD: yeah, a number of things in nix are doing crazy things like passing you your own return value as an argument
<clever> NemesisD: yeah
<clever> yokyolu: setting trusted-users allows you to bypass most of the safeties in nix, so there is likely something else you want to be setting instead, what --option flags are you using?
<clever> NemesisD: yep, including any future overlays your not yet aware of
<clever> __monty__: ^^
<clever> ,escape''
<clever> NemesisD: using rec breaks the entire idea of overlays, you must use self.foo when you want to refer to another attr
<clever> __monty__: ah yeah, forgot about that, i always start with a trace like this, and then write the rules based on what nix shows
<clever> src = builtins.filterSource (path: type: builtins.trace "${type} ${path}" (type == "file" && ext ".odt" path)) ./.;
<clever> __monty__: a quick test in nix repl says it should have worked...
<clever> __monty__: or just test the ext function within nix repl
<clever> __monty__: youll want to add some builtins.trace in the filterSource expr, to debug it further
<clever> so the for loop never runs, and novel.md is never made
<clever> but your filterSource may be buggy, and $src is just an empty dir
<clever> yokyolu: there is a trusted-substituters list in nix.conf
<clever> __monty__: before the for loop, do `ls -lha $src`
<clever> __monty__: $out can be a file, directory, or symlink, and your buildCommand must somehow create it
<clever> __monty__: you must copy it to $out
<clever> __monty__: change builder to buildCommand
<clever> __monty__: so it then searches $PATH, for that entire string!
<clever> __monty__: nix is treating that entire string, as the name of a command
<clever> there is also wrapProgram, which will rename the 1st arg, then use both the original and new name
<clever> __monty__: can you pastebin the exact error, and the new nix expression?
<clever> you need $src/* to make bash treat it as a list of files
<clever> $src is just a single directory, not a list of things
<clever> __monty__: but at a bash level, `for x in $src` will only set x to $src, and run the loop once
<clever> __monty__: filterSource limits what files are in $src
<clever> you want $src/*.odt
<clever> __monty__: oh, and `for x in $src` will run the for loop exactly once, on $src
<clever> __monty__: correct, you are defining a nix level function, that accepts an argument called pandoc, but then you never do anything with pandoc
<clever> __monty__: pandoc is also not in the buildInputs, so it cant be ran
<clever> __monty__: the for loop is setting $odt, but then your using $f inside the loop?
<clever> __monty__: can you pastebin your current files and i can see what your trying to do?
<clever> __monty__: 99% of the time, you dont want to use builder=
<clever> you can always rename as you copy the foo.nix into nixpkgs/foo/default.nix
<clever> but having default.nix contain the callPackage, saves you having to pass a name to nix-build
<clever> that also works as well
<clever> and then default.nix has the string from what {^_^} gave above
<clever> i tend to put the { stdenv, cmake }: part into packagename.nix
<clever> ,callPackage __monty__
<clever> or replace the <nixpkgs> in the nix file with another expression
<clever> so you would want the nix sandbox properly configured
<clever> yl[m]: what happens with nix-build on darwin?
<clever> i think its failing to build the files that protoc generates
<clever> ERROR: /private/tmp/nix-build-bazel-watcher-0.9.0.drv-0/output/external/com_google_protobuf/BUILD:378:1: C++ compilation of rule '@com_google_protobuf//:protoc' failed (Exit 1) cc_wrapper.sh failed: error executing command external/local_config_cc/cc_wrapper.sh -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -fcolor-diagnostics -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG ... (remaining 36 argument(s) skipped)
<clever> but the build has never once passed, so different changes are required
<clever> external/com_google_protobuf/src/google/protobuf/compiler/cpp/cpp_generator.h:40:10: fatal error: 'string' file not found
<clever> the build is failing on hydra
<clever> yl[m]: maybe hydra doesnt understand that?
<clever> yl[m]: hmmm, odd, the source says platforms.all
<clever> yl[m]: the platforms list isnt setup right, so hydra wont build it ever
<clever> nix-repl> :p bazel-watcher.meta.platforms
<clever> [ { } ]
<clever> nope, --arg doesnt do it
<clever> __monty__: hmmm, i just had a thought...
<clever> __monty__: but at this point, just put that entire string inside a shell.nix, and it will be easier to manage
<clever> __monty__: nix-shell -E 'with import <nixpkgs> { config={}; overlays=[]; }; stdenv.mkDerivation { name="name"; buildInputs = [ pandoc ]; }'
<clever> oops, quoting issues
<clever> __monty__: nix-shell -E "with import <nixpkgs> { config={}; overlays=[]; }; stdenv.mkDerivation { name="name"; buildInputs = [ pandoc ]; }'
<clever> __monty__: that entirely disables loading config/overlays
<clever> __monty__: when you `import <nixpkgs> {}` it will obey your config.nix, which is why i prefer `import <nixpkgs> { config={}; overlays=[]; }`
<clever> its sort of a fake backup though, it has the same schema as a backup, but is limited to the subset of paths included in the tar
<clever> it will also include a "backup" of the db.sqlite, so you can then restore that after unpacking, to make everything valid (but it will wipe any previous DB)
<clever> symphorien: there is also pkgs.callPackage <nixpkgs/nixos/lib/make-system-tarball.nix>, which can generate that tarball for you
<clever> dckc: both my laptop and desktop have 32gig of ram, and i regularly go into 32gig of swap on the desktop, so 64g would help perf
<clever> elvishjerricco: the hash matches what nix-prefetch-git added to the store, but it doesnt match what is downloaded at build time
<clever> elvishjerricco: it only works if the path for the given name+hash exists in /nix/store/, and due to giving the "wrong" hash (the submodule free one) it will fail for all others

2019-02-10

<clever> ottidmes: -R may also be required
<clever> ottidmes: ah, that should work
<clever> noonien: vnstat -i eth0 -l
<clever> ottidmes: not sure then
<clever> noonien: try downloading it with -L -O, then run `nix-store --add-fixed sha256 ./file`
<clever> ottidmes: you could just set the User= flag to run as that user
<clever> noonien: add -L to the flags
<clever> with just the url and no other flags
<clever> noonien: what happens if you manually run curl on the same URL?
<clever> ottidmes: last i looked, user services dont have any support for that, but it may have been changed recently
<clever> ottidmes: the restartifchanged flag is to disable that
<clever> ottidmes: it restarts when changed by default
<clever> ottidmes: an activation script might do it, but you need to be careful not to fail there, or the machine wont even boot
<clever> ottidmes: ah, not sure then
<clever> ottidmes: why is it Type=oneshot?
<clever> noonien: find doesnt follow symlinks
<clever> das_j: you could use systemd.services.nix-daemon.Environment to mess with TMPDIR, so all builds use a diff temp dir
<clever> simpson: it could just be a crypto-coin miner :P
<clever> simpson: but in some cases, having the build "never stop" could be worse
<clever> simpson: the build will only pass if $out has the hash you defined upfront, and will fail if anything else happens
<clever> das_j: not easily, why do you want to move it?
<clever> das_j: i believe nix-daemon will obey its $TMP or $TMPDIR
<clever> simpson: you can even open a reverse shell and let an attacker into the box (under the nixbld user)