2018-08-07

<clever> nixpkgs/pkgs/applications/altcoins/seth.nix: wrapProgram "$out/bin/seth" --prefix PATH : "${path}"
<clever> drakonis: thats not how makeWrapper is used
<clever> drakonis: if done right, it wont be able to conflict
<clever> drakonis: can you gist your nix expression?
<clever> sigtrm: not all, but i'm guessing most
<clever> drakonis: is it giving an error?
<clever> sigtrm: the above creates a hello-world binary linked against musl
<clever> (import <nixpkgs> { crossSystem = (import <nixpkgs/lib>).systems.examples.musl64; }).hello
<clever> sigtrm: it does have a musl cross-compile target
<clever> try curl on the same domain that fails in firefox
<clever> then why is firefox giving an error?
<clever> iqubic: try loading a page with curl next time to see what error it has
<clever> iqubic: what does /etc/resolv.conf say the nameserver is?
<clever> iqubic: same
<clever> the merge function on line 267 deals with merging things
<clever> fresheyeball: and the definition of attrsOf
<clever> types.attrsOf
<clever> thats the apache one
<clever> oops, wait
<clever> fresheyeball: its based on the type defined here
<clever> yeah
<clever> then it can scan .config and merge based on what .options defined
<clever> fresheyeball: the lazyness of nix allows it to read the full .options tree from every file, while sorta ignoring the .config trees
<clever> fresheyeball: in general, use the imports field to list multiple modules
<clever> fresheyeball: nope
<clever> but the merging is more inteligent then //
<clever> bobvanderlinden: id rather see it become c
<clever> bobvanderlinden: setup-etc.pl is the only reason not-os depends on perl
<clever> elvishjerricco: setup-etc.pl is one ive wanted to see ported
<clever> the above directions will put rclone into the PATH of rclone-browser
<clever> why?
<clever> ,runtimeDeps drakonis
<clever> ,runtime
<clever> das_j: install dependencies?
<clever> das_j: ive seen some derivations that should have taken 3 seconds, take 30mins, because it had to upload 2gig of deps, over wifi
<clever> das_j: preferLocal is just a speed optimization, and it wont force it to be local
<clever> that will handle it for you
<clever> das_j: #!${pkgs.stdenv.shell}
<clever> yeah
<clever> since you need to rebuild things
<clever> it may also take you several hours to install something from source
<clever> you only want to use that when your internet is kaput
<clever> turns off all binary caches
<clever> iqubic: --option substituters ""
<clever> iqubic: sounds like it will work
<clever> tell mdadm to go away, and then repartition it again
<clever> tilpner: so it couldnt apply the new partition tables
<clever> tilpner: it sounds like part of sda was open (mdadm to blame?) when you repartitioned
<clever> tilpner: fdisk -l /dev/sda
<clever> tilpner: and `lsblk ; blkid` ?
<clever> tilpner: what does pvdisplay say?
<clever> rauno: nixpkgs.overlays = [ (super: self: { package1 = super.package1.overrideAttrs (old: { ... }); }) ];
<clever> rauno: but you can also use overlays and not use a git checkout
<clever> rauno: yeah
<clever> rauno: and the nix expression just builds all drivers, then copies the ones it needs
<clever> rauno: because hydra hasnt had a chance to build it yet
<clever> git remote add channels https://github.com/nixos/nixpkgs-channels/
<clever> rauno: you want the nixos-18.03 branch of the nixpkgs-channels repo
<clever> rauno: thats not what hydra has tested
<clever> rauno: and is that git clone on a rev hydra has built?
<clever> and what is that?
<clever> rauno: which one is nixops using?
<clever> rauno: nix-instantiate --find-file nixpkgs
<clever> rauno: what is it?
<clever> rauno: what does nix-channel --list say?
<clever> similar problems can happen if your overlays are not applying right
<clever> chessai: note that changing a did not impact b at all
<clever> > (rec { a = 1; b = a; }) // { a = 2; }
<clever> > (rec { a = 1; b = a; } // { a = 2; }
<clever> because of how callPackage works
<clever> chessai: which results in future overrides using the 2nd vector, and now you have 2 vectors at play
<clever> chessai: depending on what its doing, it may overwrite the vector attribute, without changing the vector passed to every other package
<clever> but self.pidgin-lurch refers to the final result
<clever> super.pidgin-lurch will refer to the result of applying most overlays, and will depend heavily on the order the overlays get proccessed in
<clever> and use self.pidgin-lurch so it refers to the fixed-point result of merging all overlays
<clever> yep
<clever> switch that region to an overlay and it should work
<clever> packageOverrides are applied before overlays
<clever> kisik21: and is it giving a clear error?
<clever> too much work to try to audit the entire git history
<clever> thats why ive been rewriting mine as i move things into the public repo
<clever> kisik21: ah, can you gist your files, or link them on github?
<clever> kisik21: so you need to use self if you want something from a future overlay
<clever> kisik21: in your case, the overlays are applied in the order they are listed in the overlays config, super will give you the pkgs set for every overlay up to and including the previous one, while self is the result of all overlays
<clever> kisik21: no
<clever> chessai: that would explain why some overrides are not taking full effect on things
<clever> chessai: i think makeRecursivelyOverridable is broken and not merging overlays correctly
<clever> kisik21: xfce4.callPackage i think

2018-08-06

<clever> chessai: can you gist the nix expressions that caused this?
<clever> then set the env var to the storepath of a config file, and dont use /etc at all
<clever> ldlework: then patch it to accept an env var with the path to the config?
<clever> kisik21: its just using nix-index, which you cain install youself
<clever> odd that the bot is claiming python though
<clever> ,locate bin xsltproc
<clever> ah, wrong cmd
<clever> ,locate xsltproc
<clever> libxslt.bin 29,008 x /nix/store/1hmq8lvxfd9yfnxxandk3kahdah610r3-libxslt-1.1.29-bin/bin/xsltproc
<clever> ,find xsltproc
<clever> maerwald: try using .overrideAttrs instead of overrideDerivation
<clever> maerwald: also, you probably want to use super, not pkgs, in that override
<clever> maerwald: is pkgconfig in the buildInputs?
<clever> maerwald: yeah, reading it...
<clever> maerwald: can you gist your nix file and the error it gives?
<clever> buildInputs = oldAttrs.buildInputs ++ [ pkgs.autoreconfHook ];
<clever> maerwald: thats what the oldAttrs argument is for
<clever> maerwald: pkgs.autoreconfHook
<clever> maerwald: autoreconfHook would work better, it runs autoreconf for you
<clever> so no nix-daemon at play
<clever> ah
<clever> and because the new nix.conf isnt in effect, nix silently ignores the custom binary cache that cachix configured
<clever> Configured https://mpickering.cachix.org binary cache in /home/travis/.config/nix/nix.conf
<clever> the new nix.conf isnt taking effect
<clever> yeah, that could be an issue
<clever> sudo launchctl kickstart -k system/org.nixos.nix-daemon || true
<clever> ah, thats before the .travis.yml even started
<clever> tee: /etc/nix/nix.conf: No such file or directory
<clever> i suspect that it may need the binary cache in /etc/nix/nix.conf, for nix-daemon to obey it?
<clever> maybe there is a bug in the normal shells, that double-evals NIX_PATH
<clever> samueldr: yeah, but the weird part is that it seems to work fine for normal shells, and breaks with `sudo foo` shells
<clever> and $HOME is not a valid directory in the cwd
<clever> yeah, ive noticed lately that sudo puts a literal $HOME into $NIX_PATH
<clever> Kim: it includes a python based plugin for accessing slack
<clever> Kim: this is how i manage my weechat
<clever> not sure
<clever> weechat jammed them together, so you must decide between using the wrapper or changing src
<clever> that allows you to override the src of firefox-unwrapped, and then still use the wrapper easily
<clever> and then a seperate firefox in its own default.nix
<clever> firefox and chrome split things up more, so you have firefox-unwrapped
<clever> or learn what it works and use it to your advantage
<clever> Kim: so you need to set configure = null; in your .override
<clever> changing the src attribute on that bash script wont have the expected result
<clever> but if configure is set to anything else, it returns a bash script defined on line 120
<clever> Kim: if configure is null, then it returns the weechat your trying to override
<clever> Kim: oh, i think i see something
<clever> Kim: do you happen to have anything else weechat related in your systemPackages list?
<clever> Kim: thats odd, the version suffix on line 17 of your overlay is missing
<clever> Kim: and `realpath /run/current-system/sw/bin/weechat` ?
<clever> Kim: what does `which weechat` return?
<clever> Kim: i would expect that to continue to work, what error does it give?
<clever> ldlework: which is why i said earlier to callPackage the unstable qtile from the stable pkgs, so your not mixing opengl's
<clever> ldlework: its possible that the problem comes from using the unstable version of opengl against the stable opengl
<clever> ldlework: how does it mention overlays?
<clever> ldlework: and if you realpath that one?, its the updated version?
<clever> ldlework: `type qtile`, not try to start it
<clever> before you remove the overlay
<clever> ldlework: ctrl+alt+f1, login, and check `type qtile` again
<clever> ldlework: you may need to reboot after adding that overlay, it sounds like its doing something funky
<clever> ldlework: and does `ps` show several bashes?
<clever> ldlework: what about `echo $PATH` ?
<clever> ldlework: it shouldnt be giving a full storepath
<clever> ldlework: thats not right
<clever> ldlework: what does `type qtile` respond with?
<clever> have you considered just running nixos-unstable for the whole system?
<clever> unstable wants a list of overlays
<clever> `value is a set while a list was expected`
<clever> and look at the error closer
<clever> yep
<clever> 2018-08-06 07:07:51 < clever> its missing a { config = {}; overlays = []; }
<clever> value is a set while a list was expected, at /nix/store/797yi4rh4mzs1vfx6im9yznc9l4sj7bb-source/pkgs/top-level/stage.nix:175:8
<clever> overlays = {};
<clever> ldlework: oh, i found the problem
<clever> ldlework: line 66 shows that the problem comes from something you put into systemPackages
<clever> emily: ah, container may lack it
<clever> emily: you can also `man configuration.nix` and search with /
<clever> emily: https://nixos.org/nixos/options.html#systemd.user.services
<clever> map can only ever return a list
<clever> ldlework: line 7 is shadowing builtins.filter
<clever> environment.variables.BROWSER = let foo = pkgs.writeScript "name" "body"; in "${foo}";
<clever> emily: a let block, lol
<clever> emily: you can also use pkgs.writeScript to just get a naked script at /nix/store/hash-name
<clever> emily: that will return a path to a directory that contains a bin/name binary
<clever> > pkgs.writeScriptBin "name" "#!${pkgs.stdenv.shell}\necho things"
<clever> emily: writeScriptBin
<clever> ldlework: looks good
<clever> its missing a { config = {}; overlays = []; }
<clever> but the "pure" pkgs will still obey your config.nix and overlays, which can screw things up
<clever> that will use the impure _pkgs to fetch a specific revision, when the pkgs arg has not otherwise been set
<clever> ldlework: by default, it just grabs a tarball
<clever> ldlework: yeah
<clever> every time you eval the expression, nix will import that path and hash it
<clever> pie_: src = ./.;
<clever> qtile = self.unstable.qtile;
<clever> then you need to overwrite qtile with an overlay
<clever> ah
<clever> but you can also just directly do pkgs.unstable.qtile in the nixos config
<clever> that is also an option
<clever> ldlework: several options, unstable.qtile is one
<clever> ldlework: if you load the same overlay in both nixpkgs, it can cause recursion
<clever> pie_: $out hasnt been made yet, try postInstall instead
<clever> but in your case, you dont want the `qtile = unstable.qtile` overlay, because that would cause infinite recursion
<clever> you can then optionally give it its own overlays
<clever> ldlework: i generally import nixpkgs with { config = {}; overlays = []; } to make it pure
<clever> pie_: yeah
<clever> and ignore nixos-unstable entirely
<clever> you can also just download the current qtile/default.nix and load it with callPackage in your overlay
<clever> then it will cache things better
<clever> you can also replace nixos-unstable in the above example, with the current git rev of nixos-unstable
<clever> your better off using pkgs.fetchFromGitHub if your going to use a sha256
<clever> since its imported with {}, it will read ~/.config/nixpkgs/
<clever> also note, that unstable will not obey the same config/overlays
<clever> but that will re-download the tar every the you nixos-rebuild, and will update things without warning
<clever> ldlework: unstable = import (builtins.fetchTarball https://github.com/nixos/nixpkgs-channels/archive/nixos-unstable.tar.gz) {};
<clever> but if you break it up in a let block, there is no need to force it
<clever> without that, `map m filter f list` would have tried to map over the filter function, and it would have immediately failed
<clever> filter originally had it, to force `map m (filter f list)` to filter first, then map on the result
<clever> the lines dont matter
<clever> its more about forcing the order of evaluation
<clever> nope
<clever> the outer most set isnt needed
<clever> 5-7 also
<clever> 9 also has a useless set of parens
<clever> maybe
<clever> which is why 6 and 8 have to append path and n together
<clever> n just contains the name
<clever> you could, just add that to the filter function on 5
<clever> you need to give it the path to a directory that will only contain overlays and nothing else
<clever> ldlework: because now nixcfg_overlays_default.nix is also being loaded as an overlay
<clever> ldlework: the filter on line 7 will filter the list to only include files like ./foo.nix and ./foo/default.nix, and ./. on 2 is going to cause many problems
<clever> and 8 is missing a trailing ;
<clever> let content =
<clever> ldlework: the let keyword is missing after the = so it wont parse right
<clever> yeah
<clever> it then runs the filter on 53 over that
<clever> attrNames on 54 reduces it to a list of names
<clever> which is a set mapping name to type (string)
<clever> line 51 is the result of readDir
<clever> i dont think its recursive
<clever> ldlework: an importing map that takes a directory of overlays
<clever> but the python setup hooks generate PYTHONPATH from that, and may copy it into the makeWrapper
<clever> propagatedBuildInputs on its own has no impact on the runtime
<clever> pie_: sorta

2018-08-05

<clever> try just looking near the installPhase
<clever> and then you can just backspace it out
<clever> the ^M should now be visible
<clever> or maybe its `:set ff=unix`
<clever> petersjt014[m]: try `:set ffs=unix` i think
<clever> yeah
<clever> petersjt014[m]: and if you run the `file` program on that file?
<clever> double-check the installPhase you pasted into that file, is it free of \r's?
<clever> i cant find it in nixpkgs master
<clever> petersjt014[m]: can you grep all of your nix expressions, including nixpkgs, for broadcom-rpi3-extra or a shorter variant
<clever> petersjt014[m]: does that name exist in any of your nix expressions?
<clever> its doing something like buildPhase = ''\nfoo\r\nbar\n'';
<clever> read the .nix file for the derivation that failed
<clever> petersjt014[m]: then the variable for the current phase contains a \r
<clever> if vim detects it as linux line endings, it will render the \r specially, because its not expected
<clever> mount the hdd on another box?
<clever> petersjt014[m]: you can also just scp the file to another box
<clever> petersjt014[m]: vim can show the line endings
<clever> petersjt014[m]: the line numbers are offset a bit by compiling it
<clever> petersjt014[m]: run an editor on the copy in the nix store, to get context
<clever> stdenv-linux has a copy of this file
<clever> yeah
<clever> yeah, once you confirm it works you can file a PR
<clever> petersjt014[m]: you need to edit a copy of nixpkgs that you clone from github
<clever> oops, nixpkgs, not noxpkgs
<clever> elvishjerricco: `nix run noxpkgs.xfce.xfconf` first to get it into PATH
<clever> just try manually running it from a text console at first
<clever> what happens if you run xfconf-query as the right user, without any X running?
<clever> selfsymmetric-mu: see if you cant find a way to edit the config in $HOME without xfce running?
<clever> yep
<clever> mikky: but it think it will still copy the kernels into the fat32
<clever> mikky: the source claims systemd-boot works in that setup
<clever> ahh
<clever> then the kernels+initrds are on ext4 for ex, and only the .efi stub is on fat32
<clever> boot.loader.efi.efiSysMountPoint = "/boot/EFI/"; allows that
<clever> mikky: nixos also lets you use fat for /boot/EFI/ and then anything not encrypted for /boot/
<clever> mikky: as long as /boot is fat32, efisystem, and mounted correctly, systemd-boot should just work
<clever> mikky: ah, if you have control over another bootloader, it doesnt matter as much
<clever> mikky: you can usually set the installAsRemovable option for grub, and then it will boot
<clever> mikky: your welcome :)
<clever> or config files in /etc/
<clever> jonreeve: does `ls /run/current-system/sw/share/applications` show the desktop files?
<clever> jonreeve: have you logged out and back in since installing them?
<clever> judson: all you have to do is set enableACME = true;
<clever> judson: the nginx modules in nixos handle .well-known for you automatically
<clever> azazel: note lines 9, 12, 16, and 22
<clever> azazel: these are the env vars set by nix itself, before it even loads the stdenv: https://github.com/cleverca22/nix-tests/blob/master/bare-env.txt#L9-L23
<clever> azazel: you should already have a $NIX_BUILD_TOP and the various temp vars should be pointing within it
<clever> azazel: and if you add this to the buildInputs glibcLocales
<clever> export a variable in preCheck?
<clever> everything from invalid utf8 combinations to sql injections to brain injections, lol
<clever> azazel: this file contains strings known to break some software
<clever> so its just constantly reconnecting
<clever> and then it rescans all directories, and fails once more
<clever> the more anoying part, is that it catches the exception at a bit of a bad place, assumes it was network trouble, and reconnects to the server
<clever> azazel: all i could do to find my issue was to strace the program and look over the logs closely
<clever> azazel: find all non-utf8 filenames and move them out of the searchpath of that program, lol
<clever> and ive got got old files made by another os, that upset it
<clever> azazel: ive found that one of the python functions for recursively reading a directory tends to throw exceptions if any non-utf8 filenames exist in its path