2018-08-31

<clever> services.nginx.appendHttpConfig = "server_names_hash_bucket_size 64";
<clever> services.nginx.appendHttpConfig
<clever> Zajcev: appendHttpConfig is the nixos option to add things to that area
<clever> If a large number of server names are defined, or unusually long server names are defined, tuning the server_names_hash_max_size and server_names_hash_bucket_size directives at the http level may become necessary.
<clever> Zajcev: nginx: [emerg] could not build server_names_hash, you should increase server_names_hash_bucket_size: 32
<clever> Zajcev: journalctl -u nginx | tail -n30
<clever> Zajcev: how are you testing it, and how is it not working?
<clever> pip3000: looks like nixos-unstable should have 13
<clever> lfish: when done, you can ./result/bin/switch-to-configuration boot, to update the bootloader
<clever> lfish: yep
<clever> lfish: nix-store -r /nix/store/aj8yk779bng82q1z6a0i6mn2sv590dxm-nix-2.0.4 ; /nix/store/aj8yk779bng82q1z6a0i6mn2sv590dxm-nix-2.0.4/bin/nix-build '<nixos/nixos>' -A system
<clever> infinisil: ah yeah, and i have sorta messed up my laptop before, by installing nix master
<clever> lfish: you need to use the version {^_^} gave, after applying the variable expansion
<clever> lfish: can you gist the whole error, and the cmds you ran?
<clever> samueldr: yeah, it will need to be documented properly, it doesnt matter that much that the nix2 is recent, just that it can parse the nixpkgs
<clever> samueldr: using the cmd {^_^} just gave, you should be able to upgrade almost anything
<clever> --fast stops nixos-rebuild from trying to build the "right" nix, and just uses whatever is in PATH
<clever> > "lfish, try doing: nix-store -r ${nix} ; PATH=${nix}/bin:$PATH nixos-rebuild boot --fast"
<clever> lfish: oh oops, let me fix a typo
<clever> > "lfish, try doing: nix-store -r ${nix} ; nixos-rebuild boot --fast"
<clever> gchristensen: but checking the source, i can see that @nix_x86_64_linux@ isnt baked into the nixpkgs, so the cmd i gave lfish above likely wont work
<clever> but if your nixos-rebuild is too old, it wont have the safety
<clever> gchristensen: which will just use `nix-store -r` to download a compatible nix
<clever> gchristensen: the error is refering to the safety code in here: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/installer/tools/nixos-rebuild.sh#L263-L299
<clever> lfish: what happens if you run `sh ~/.nix-defexpr/channels/nixos/nixos/modules/installer/tools/nixos-rebuild.sh build` ?
<clever> gchristensen: the safety in nixos-rebuild requires the new nixos-rebuild with the safety
<clever> when previously, it wasnt getting that far
<clever> it probably got past cabal2nix and passed a bottleneck, then tried to download 5 things at once from your cache
<clever> i cant think anything else to check
<clever> ah
<clever> if you re-add that, it can get cabal2nix from there, but the problem will remain for anything you built yourself
<clever> one minor thing, cache.nixos.org is missing from your binary cache list
<clever> doesnt matter which core it locks
<clever> if you re-run the last command with --repair, it will repair them
<clever> nothing at all should have been modified
<clever> run `nix-store --verify --check-contents` on the server
<clever> `_: is curl returning the same sig for that path?
<clever> with the right path
<clever> `_: try adding nix.extraOptions = "secret-key-files = /etc/nix/keys/secret-key-file"; to configuration.nix on the server
<clever> `_: cant remember if it needs to be configured or not, check the curl i gave above, on the hydra domain, and see what it says
<clever> yep
<clever> if its enabled
<clever> the hydra UI also includes a nix-serve compatible cache, so you can also just use hydra.example.io as a cache
<clever> ah
<clever> `_: will this machine be running hydra?, some of the config implies it is
<clever> `_: it repeats one of the steps twice when signing, and creates invalid signatures
<clever> `_: oh right, there is a bug in nix-serve at one point
<clever> what does `nix-store -r -vvvvv /nix/store/aqhld814irl57k6fbj5szh4ds4hkzai0-cabal2nix-2.9.2` output?
<clever> double-check that the pubkey in the server matches the pubkey in nix.conf
<clever> i cant see mistakes like that when its censored
<clever> and does the domain actually match what is in nix.conf on the client machine?
<clever> what does the Sig: header in the narinfo say?
<clever> does the nix-serve user have permission to read the private key?
<clever> `_: the public key is in nix.conf
<clever> can you pastebin the contents of configuration.nix and /etc/nix/nix.conf ?
<clever> did you nixos-rebuild after editing it?
<clever> thats what configuration.nix should be doing
<clever> `_: and they appear in /etc/nix/nix.conf as well?
<clever> `_: you must add both the URL and the pubkey in configuration.nix
<clever> `_: and does the local machine have the public in `nix.conf` ?
<clever> `_: grep NIX_SECRET_KEY_FILE /etc/systemd/system/nix-serve.service
<clever> one
<clever> `_: ah wait, on min
<clever> `_: what does `ps aux | grep nix-serve` show?
<clever> `_: nix-serve does not support the signatures managed by `nix sign-paths`, you must give nix-serve the path to the secret, and it will sign things on-demand

2018-08-30

<clever> kiloreux: probably
<clever> it allows you to do .foo on the derivation to get the value, but the derivation itself has no clue its there, the value wont impact the computation of $out, and it doesnt have to be a flat string
<clever> kiloreux: passthru is basically the same as (stdenv.mkDerivation { ... }) // { foo = "bar"; }

2018-08-29

<clever> -f is a path
<clever> bgamari: -f tells it to load the expression from a file
<clever> bgamari: bugs in the `nix build` arg parser not detecting invalid choices
<clever> -p generates a derivation to shell into, but a path points to one
<clever> bgamari: you cant mix paths and -p
<clever> can mostly ignore those
<clever> kini: try `nixos-rebuild test --fast --option substituters ""`
<clever> Zajcev: you would use whatever nix file you originally gave to `nixops create`
<clever> nixops will then save that -I flag in the state file, and you dont have to remember to `export NIX_PATH` every time you deploy
<clever> Zajcev: i generally do `nixops modify -I nixpkgs=https://nixos.org/channels/nixos-unstable-small/nixexprs.tar.xz ./deployment.nix`
<clever> jtojnar: you could use LD_LIBRARY_PATH to inject the debug version of it into the search path
<clever> yeah
<clever> Lisanna: you uninstall by name, not attributepath
<clever> Lisanna: once installed, nix-env has no clue what channel or attribute it came from
<clever> michas: yeah, then you should be on the version you linked from github
<clever> mpickering: what does `nix-channel --list` show for root?
<clever> ,pills
<clever> nefix: pop that into shell.nix, and then just run nix-shell with no args
<clever> with import <nixpkgs> {}; stdenv.mkDerivation { name = "foo"; buildInputs = [ go ]; }
<clever> nefix: make a shell.nix file
<clever> --delete-generations just gets rid of the GC root, so you can delete it
<clever> if you want to actually remove the path from the store
<clever> yeah, some of the command like stuff is a bit buggy with names
<clever> then you can `nix-store --delete` it
<clever> `nix-env --delete-generations 12` will get rid of generation 12
<clever> nix-env -e /nix/store/hash-foo
<clever> using the full storepath can make it simpler
<clever> but .'s in the name can confuse nix-env
<clever> the name is what is returned by -q
<clever> d1rewolf: use -e with either the same storepath, or the name
<clever> check nix-env -q to see it
<clever> yep
<clever> its in your current generation, you need to first uninstall it with nix-env -e
<clever> ls -l /nix/var/nix/profiles/per-user/d1rewolf/profile
<clever> ah, its in use by a generation of nix-env
<clever> d1rewolf: and then run `nix-store --delete` on the path?
<clever> d1rewolf: you want nix-store --query --roots
<clever> its nearly 7am, i should get back to bed
<clever> ldlework: *eyes line 8*
<clever> its how the pkgs arg is even getting passed to you
<clever> that should work on both nixos and home-manager
<clever> ldlework: then just { yourthing, pkgs, lib, ... }: everywhere
<clever> ldlework: also, _module.args.yourthing = import ./it_once.nix;
<clever> nefix: oh, yeah, i see that now
<clever> ldlework: this allows you to create your own set of functions, that use overlay syntax, but are not mutating pkgs
<clever> and you can call .extend on the result of extend, to add more overlays
<clever> so your overlay can mutate what self is (both for the initial self: {} and other overlays)
<clever> and .extend will insert an overlay between the return-value of that function, and the self value
<clever> lib.makeExtensible takes a function in the form of (self: { }), and will add a .extend method to it
<clever> > ( (lib.makeExtensible (self: {})).extend (self: super: { a = "foo"; }) ).a
<clever> ldlework: lib.makeExtensible (self: {}) may be of interest to you
<clever> ldlework: possibly
<clever> ldlework: i think the value of nixpkgs.config depends on services.xserver.enable, which depends on pkgs, which depends on nixpkgs.config
<clever> ldlework: which depends on services.xserver.enable
<clever> ldlework: which depends on nixpkgs.config
<clever> line 66 of the error says that _module.args depends on the nixos option nixpkgs.pkgs, which makes sense
<clever> and mine on line 27 (39 of the gist) depends on pkgs
<clever> ldlework: and on line 44, you can see _module.args
<clever> ldlework: yeah, the problem is when trying to compute pkgs
<clever> ldlework: ah, then its not it
<clever> nvme will enable nvme+uefi in justdoit, and qemu
<clever> uefi_sata for example, will enable uefi in qemu and justdoit, and use a sata disk
<clever> and each one, changes the config for justdoit, and the qemu config
<clever> adamantium: the first one boots the kexec kernel+initrd, with justdoit, and a hdd, the 2nd boots with just the hdd
<clever> adamantium: each attribute in this set, generates a pair of bash scripts
<clever> adamantium: let me also link my test utils
<clever> adamantium: sure
<clever> ldlework: it has to eval config.mine's keys, to know if this should enable or not
<clever> adamantium: mine though has uefi, nvme, and luks support
<clever> adamantium: it looks like your script has more runtime configurability, while mine needs all inputs to be set in nix and rebuilt with nix-build
<clever> jtojnar: check $dev instead of $out ?
<clever> hmmm, but you said postFixup, so it should exist
<clever> jtojnar: if you assign fixupPhase to a string, then the fixupPhase() function will never run
<clever> adamantium: dont see how it could have caused that, try adding -vvvv to the command?
<clever> nefix: you usually want types.str
<clever> adamantium: its probably working, check `top` in another terminal
<clever> nefix: also, the string type is not what you want: https://github.com/NixOS/nixpkgs/blob/master/lib/types.nix#L210-L212
<clever> dont think its related
<clever> jtojnar: put an `ls -l $out` in postfixup
<clever> nefix: line 230 appears to deal wit the options tree
<clever> yep
<clever> need to force it to concat before it reads the dir
<clever> adamantium: getDir (dir + "/${file}")
<clever> adamantium: ah, oops, made the same mistake when testing locally
<clever> nefix: i prefer gist.github.com
<clever> nefix: can you pastebin your modules?
<clever> dir = ./.;, yeah, that looks fine
<clever> adamantium: i think so, but it depends on how recimport is called
<clever> nefix: can you paste the --show-trace and your code?
<clever> you would add it to your livecd image when building it
<clever> justdoit.nix is a nixos module, that adds the compiled script into systemPackages
<clever> and this gist will generate an aws AMI image with a zfs based install
<clever> this bash script will do the entire install with a single command
<clever> adamantium: try just editing the nix then
<clever> then getDir dir + "/${file}"
<clever> just stop quoting the dir and the problem will go away
<clever> (./. + "/kexec") does not fail, but "${./.}/kexec" does
<clever> adamantium: also, there is a better fix, i confirmed what i said above
<clever> yes, there is a space there
<clever> other way around, from /mnt to /
<clever> adamantium: in your case, it would be: nix copy --from local?root=/mnt/ --to local /nix/store/gby17w2w1f35ab099khkf1wcblxx7ddi-modules
<clever> adamantium: this worked on my end
<clever> [root@amd-nixos:~]# nix copy --from local?root=/home/clever/fakeroot/ --to local /nix/store/c755gda2r90mhsrz1k6fd8w62ffvshyb-nix-tests
<clever> adamantium: i was doing it from memory, let me confirm it on this end
<clever> but dir + "/${file}" wont copy it, and will preserve the original path, and then work, possibly
<clever> "${dir}/${file}" will copy dir to /mnt/nix/store, then nix2 tries to read it from /nix/store and it fails
<clever> change it to: then getDir dir + "/${file}"
<clever> then getDir "${dir}/${file}"
<clever> adamantium: it might be possible to work around it entirely
<clever> adamantium: the problem, is when you try to readDir a storepath when nix2 is chrooting
<clever> adamantium: and i can confirm the problem on this end
<clever> i think that will work around it for now
<clever> adamantium: nix copy --from local?root=/mnt /nix/store/gby17w2w1f35ab099khkf1wcblxx7ddi-modules --to local
<clever> adamantium: no, its likely a bug within nix 2
<clever> testing it locally
<clever> but some parts of the code forget to prefix the paths with /mnt/
<clever> nix 2.0 lets you act on a store like /mnt/nix/store without doing a real chroot
<clever> adamantium: its possible that the chroot stuff in nix2 is breaking
<clever> adamantium: what about in /mnt/nix/store/ ?
<clever> adamantium: what about the modules dir above it?
<clever> adamantium: ls -lh /nix/store/gby17w2w1f35ab099khkf1wcblxx7ddi-modules/nixos
<clever> adamantium: does the path /nix/store/1f17y165kcd82dyhig5iychb2j60l058-modules/home exist?
<clever> nikivi: no idea whats wrong there
<clever> nikivi: thats not the real error
<clever> adamantium: can you also pastebin recimport.nix ?
<clever> adamantium: add --show-trace and re-paste the error
<clever> it returns glibc on linux, and some darwin stuff on darwin
<clever> pkgs.libiconv is an alias to deal with this exact problem
<clever> then you should be able to just nix-env -iA postgis -f '<nixpkgs>'
<clever> adamantium: yeah, i would try to always use relative imports, since absolute mess with the chroots during install
<clever> nikivi: step 2 is to then add one of those with an override
<clever> nikivi: to see what packages contain iconv.h
<clever> nikivi: that ls command wont change anything
<clever> adamantium: curl https://github.com/nix/install | sh i believe
<clever> nikivi: quick&dirty first step, `ls -l /nix/store/*/include/iconv.h`
<clever> nikivi: youll need to find out what package provides it, and then create an override to fix it
<clever> nikivi: on linux, iconv.h is part of glibc, but darwin doesnt use glibc
<clever> adamantium: ive made 2 of those
<clever> and there should be a more detailed error above that one
<clever> i'm guessing it will fail at some point, and reveal why it was marked as linux-only
<clever> i made a typo above
<clever> postgis isnt spelled right
<clever> yeah, that should also force it to build
<clever> i prefer nix-build when testing things, since nix-env persists more, and has generations
<clever> nikivi: nix-build will just build and create a result symlink, nix-env will build and add it to ~/.nix-profile/
<clever> nikivi: that supplies the contents of config.nix directly on the cmd line
<clever> nikivi: nix-build '<nixpkgs>' -A postgix --arg config '{ allowUnsupportedSystem = true; }'
<clever> ldlework: yep
<clever> nikivi: yep, thats it
<clever> ldlework: and only once it knows what root-level keys each module returns, can it know which module provides the value of _modules
<clever> nikivi: try the above nix-build first
<clever> ldlework: and for the nixos module system to merge all modules together, it must know what keys every module is returning
<clever> ldlework: the problem, is that pkgs comes from the config._modules.args.pkgs setting
<clever> nikivi: `nix-build '<nixpkgs>' -A postgis` will explain how to set allowUnsupportedSystem
<clever> nikivi: its currently tagged as being linux only, but you can set allowBroken to bypass that
<clever> once some of the prefix is constant, it can lazily skip your code until later
<clever> so you need to do config = mkIf config.mine.workstation.enable { mine = ...; };
<clever> it must know the keys your config= defines, to be able to find pkgs
<clever> due to how pkgs works
<clever> ldlework: oh, one theory, the keys within config= might not be allowed to depend on pkgs
<clever> yeah, the traces are a bit cryptic
<clever> yeah, it is strange that its failing like that
<clever> ldlework: try using self to get at lib functions?
<clever> ah, that one doesnt exist
<clever> > lib.traceShow "traceme" "returnme"
<clever> but the bot cant show trace output
<clever> > lib.traceShowVal "foo"
<clever> ldlework: there is also a lib.traceShowVal
<clever> ldlework: i run builtins.toJSON over it
<clever> bkchr[m]: patchShebangs should be ran over the scripts to fix that up
<clever> bkchr[m]: id say its a bug to be using /usr/bin/env in any finished build on nix
<clever> bkchr[m]: ah, that package needs to be fixed to patchShebangs its own scripts
<clever> bkchr[m]: run patchShebangs before attempting to use that script
<clever> bkchr[m]: if the sandbox is enabled, it wont exist
<clever> ldlework: the problem appears to be near config.news, which isnt in the gist
<clever> adisbladis: yeah
<clever> hmmm, that doesnt look like a package
<clever> > mate
<clever> > mate.meta.description
<clever> yeah
<clever> baimafeima: guixe uses nix-daemon, but has a different language in place of nix, and only allows free software
<clever> baimafeima: the github repo that describes all packages, https://github.com/nixos/nixpkgs/
<clever> baimafeima: the livecd has some nonfree firmware enabled, and all of the nonfree stuff is described in nixpkgs, but will only install if you enable unfree
<clever> baimafeima: if you leave allowUnfree at the default of false, it will only allow you to install free software
<clever> hyper_ch2: though, that is just how to patch the pre-built firefox, there is a second nix file for actually building it
<clever> hyper_ch2: i have previously done my own re-encoding to watch things on an android tablet, and i found some of them recently, and they sounded like shit, lol
<clever> hyper_ch2: it feels like the plex pass would unlock more features, and also avoid the problem of having to buy the app on every platform
<clever> LnL: one area ive noticed where plex may still require payment, the android app stops playback after 90 seconds
<clever> ,libraries
<clever> DenialAdams: nix-env -e

2018-08-28

<clever> koselig: youll want to check for and maybe file a bug on nixpkgs then
<clever> koselig: it looks like a bug within systemd.network, until its fixed you will want to set its enable to false
<clever> koselig: and what does `sudo nix-channel --list` report?
<clever> koselig: what does it output if you use --show-trace and can you pastebin your configuration.nix?
<clever> > builtins.isFloat 3.14
<clever> it would be in the nix manual
<clever> > builtins.typeOf 3.14
<clever> v0|d: `Hint: Run "cryptsetup benchmark" to see which one is fastest on your machine`
<clever> v0|d: thats an example, not the default
<clever> Thra11: yeah
<clever> hmmm wait no
<clever> v0|d: do you want hibernation?
<clever> Thra11: then why was the version= bumped?
<clever> leotaku: your nix version is too new, you need to temporarily put the same nix version as the remote end in PATH
<clever> Thra11: yeah, id say thats wrong, the url doesnt match the version
<clever> if you try to nix-env -iA a set, it will install every package in the set, and they are installed "normally" so they show up in nix-env -q and can be updated/removed seperately
<clever> johnny101: just do mystuff = { inherit (pkgs) firefox chromium; }; in your override
<clever> johnny101: but there is a change you can do to get that data back, use a bare set instead of a buildEnv
<clever> johnny101: there is no difference between installing and updating
<clever> johnny101: nix-env -iA nixos.thatbuildenv --dry-run
<clever> joko: i just switch back to nix-build when i want that
<clever> ixxie: nixops always uses root
<clever> ldlework: substituteAll accepts an isExecutable flag, no need for writeScript
<clever> the all variant just uses env vars at build-time
<clever> check nixpkgs for examples
<clever> ldlework: this is a function that calls substituteInPlace for you