2018-08-07
21:19
<
clever >
nixpkgs/pkgs/applications/altcoins/seth.nix: wrapProgram "$out/bin/seth" --prefix PATH : "${path}"
21:19
<
clever >
drakonis: thats not how makeWrapper is used
21:17
<
clever >
drakonis: if done right, it wont be able to conflict
21:15
<
clever >
drakonis: can you gist your nix expression?
21:15
<
clever >
sigtrm: not all, but i'm guessing most
21:14
<
clever >
drakonis: is it giving an error?
21:14
<
clever >
sigtrm: the above creates a hello-world binary linked against musl
21:12
<
clever >
(import <nixpkgs> { crossSystem = (import <nixpkgs/lib>).systems.examples.musl64; }).hello
21:11
<
clever >
sigtrm: it does have a musl cross-compile target
21:05
<
clever >
try curl on the same domain that fails in firefox
21:02
<
clever >
then why is firefox giving an error?
21:01
<
clever >
iqubic: try loading a page with curl next time to see what error it has
20:56
<
clever >
iqubic: what does /etc/resolv.conf say the nameserver is?
20:55
<
clever >
iqubic: same
20:54
<
clever >
the merge function on line 267 deals with merging things
20:54
<
clever >
fresheyeball: and the definition of attrsOf
20:54
<
clever >
types.attrsOf
20:53
<
clever >
thats the apache one
20:53
<
clever >
oops, wait
20:53
<
clever >
fresheyeball: its based on the type defined here
20:50
<
clever >
then it can scan .config and merge based on what .options defined
20:50
<
clever >
fresheyeball: the lazyness of nix allows it to read the full .options tree from every file, while sorta ignoring the .config trees
20:48
<
clever >
fresheyeball: in general, use the imports field to list multiple modules
20:47
<
clever >
fresheyeball: nope
20:40
<
clever >
but the merging is more inteligent then //
18:39
<
clever >
bobvanderlinden: id rather see it become c
18:39
<
clever >
bobvanderlinden: setup-etc.pl is the only reason not-os depends on perl
18:38
<
clever >
elvishjerricco: setup-etc.pl is one ive wanted to see ported
18:12
<
clever >
the above directions will put rclone into the PATH of rclone-browser
18:10
<
clever >
,runtimeDeps drakonis
18:09
<
clever >
das_j: install dependencies?
18:07
<
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
18:07
<
clever >
das_j: preferLocal is just a speed optimization, and it wont force it to be local
17:54
<
clever >
that will handle it for you
17:54
<
clever >
das_j: #!${pkgs.stdenv.shell}
17:33
<
clever >
since you need to rebuild things
17:33
<
clever >
it may also take you several hours to install something from source
17:29
<
clever >
you only want to use that when your internet is kaput
17:28
<
clever >
turns off all binary caches
17:27
<
clever >
iqubic: --option substituters ""
17:24
<
clever >
iqubic: sounds like it will work
17:22
<
clever >
tell mdadm to go away, and then repartition it again
17:21
<
clever >
tilpner: so it couldnt apply the new partition tables
17:21
<
clever >
tilpner: it sounds like part of sda was open (mdadm to blame?) when you repartitioned
17:21
<
clever >
tilpner: fdisk -l /dev/sda
17:18
<
clever >
tilpner: and `lsblk ; blkid` ?
17:15
<
clever >
tilpner: what does pvdisplay say?
16:33
<
clever >
rauno: nixpkgs.overlays = [ (super: self: { package1 = super.package1.overrideAttrs (old: { ... }); }) ];
16:32
<
clever >
rauno: but you can also use overlays and not use a git checkout
16:31
<
clever >
rauno: yeah
16:31
<
clever >
rauno: and the nix expression just builds all drivers, then copies the ones it needs
16:29
<
clever >
rauno: because hydra hasnt had a chance to build it yet
16:26
<
clever >
rauno: you want the nixos-18.03 branch of the nixpkgs-channels repo
16:26
<
clever >
rauno: thats not what hydra has tested
16:25
<
clever >
rauno: and is that git clone on a rev hydra has built?
16:24
<
clever >
and what is that?
16:23
<
clever >
rauno: which one is nixops using?
16:23
<
clever >
rauno: nix-instantiate --find-file nixpkgs
16:22
<
clever >
rauno: what is it?
16:22
<
clever >
rauno: what does nix-channel --list say?
00:36
<
clever >
similar problems can happen if your overlays are not applying right
00:35
<
clever >
chessai: note that changing a did not impact b at all
00:35
<
clever >
> (rec { a = 1; b = a; }) // { a = 2; }
00:35
<
clever >
> (rec { a = 1; b = a; } // { a = 2; }
00:35
<
clever >
because of how callPackage works
00:33
<
clever >
chessai: which results in future overrides using the 2nd vector, and now you have 2 vectors at play
00:33
<
clever >
chessai: depending on what its doing, it may overwrite the vector attribute, without changing the vector passed to every other package
00:22
<
clever >
but self.pidgin-lurch refers to the final result
00:22
<
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
00:21
<
clever >
and use self.pidgin-lurch so it refers to the fixed-point result of merging all overlays
00:20
<
clever >
switch that region to an overlay and it should work
00:20
<
clever >
packageOverrides are applied before overlays
00:19
<
clever >
kisik21: and is it giving a clear error?
00:13
<
clever >
too much work to try to audit the entire git history
00:13
<
clever >
thats why ive been rewriting mine as i move things into the public repo
00:12
<
clever >
kisik21: ah, can you gist your files, or link them on github?
00:11
<
clever >
kisik21: so you need to use self if you want something from a future overlay
00:11
<
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
00:10
<
clever >
kisik21: no
00:10
<
clever >
chessai: that would explain why some overrides are not taking full effect on things
00:09
<
clever >
chessai: i think makeRecursivelyOverridable is broken and not merging overlays correctly
00:06
<
clever >
kisik21: xfce4.callPackage i think
2018-08-06
23:57
<
clever >
chessai: can you gist the nix expressions that caused this?
22:23
<
clever >
then set the env var to the storepath of a config file, and dont use /etc at all
22:23
<
clever >
ldlework: then patch it to accept an env var with the path to the config?
22:13
<
clever >
kisik21: its just using nix-index, which you cain install youself
22:13
<
clever >
odd that the bot is claiming python though
22:13
<
clever >
,locate bin xsltproc
22:13
<
clever >
ah, wrong cmd
22:13
<
clever >
,locate xsltproc
22:12
<
clever >
libxslt.bin 29,008 x /nix/store/1hmq8lvxfd9yfnxxandk3kahdah610r3-libxslt-1.1.29-bin/bin/xsltproc
22:12
<
clever >
,find xsltproc
15:14
<
clever >
maerwald: try using .overrideAttrs instead of overrideDerivation
15:10
<
clever >
maerwald: also, you probably want to use super, not pkgs, in that override
15:09
<
clever >
maerwald: is pkgconfig in the buildInputs?
15:08
<
clever >
maerwald: yeah, reading it...
14:49
<
clever >
maerwald: can you gist your nix file and the error it gives?
14:43
<
clever >
buildInputs = oldAttrs.buildInputs ++ [ pkgs.autoreconfHook ];
14:43
<
clever >
maerwald: thats what the oldAttrs argument is for
14:37
<
clever >
maerwald: pkgs.autoreconfHook
14:32
<
clever >
maerwald: autoreconfHook would work better, it runs autoreconf for you
14:05
<
clever >
so no nix-daemon at play
14:05
<
clever >
and because the new nix.conf isnt in effect, nix silently ignores the custom binary cache that cachix configured
14:04
<
clever >
the new nix.conf isnt taking effect
14:04
<
clever >
yeah, that could be an issue
14:04
<
clever >
sudo launchctl kickstart -k system/org.nixos.nix-daemon || true
14:04
<
clever >
ah, thats before the .travis.yml even started
14:03
<
clever >
tee: /etc/nix/nix.conf: No such file or directory
14:01
<
clever >
i suspect that it may need the binary cache in /etc/nix/nix.conf, for nix-daemon to obey it?
13:15
<
clever >
maybe there is a bug in the normal shells, that double-evals NIX_PATH
13:15
<
clever >
samueldr: yeah, but the weird part is that it seems to work fine for normal shells, and breaks with `sudo foo` shells
13:11
<
clever >
and $HOME is not a valid directory in the cwd
13:11
<
clever >
yeah, ive noticed lately that sudo puts a literal $HOME into $NIX_PATH
11:58
<
clever >
Kim: it includes a python based plugin for accessing slack
11:57
<
clever >
Kim: this is how i manage my weechat
11:47
<
clever >
weechat jammed them together, so you must decide between using the wrapper or changing src
11:46
<
clever >
that allows you to override the src of firefox-unwrapped, and then still use the wrapper easily
11:46
<
clever >
and then a seperate firefox in its own default.nix
11:46
<
clever >
firefox and chrome split things up more, so you have firefox-unwrapped
11:45
<
clever >
or learn what it works and use it to your advantage
11:45
<
clever >
Kim: so you need to set configure = null; in your .override
11:44
<
clever >
changing the src attribute on that bash script wont have the expected result
11:44
<
clever >
but if configure is set to anything else, it returns a bash script defined on line 120
11:44
<
clever >
Kim: if configure is null, then it returns the weechat your trying to override
11:42
<
clever >
Kim: oh, i think i see something
11:42
<
clever >
Kim: do you happen to have anything else weechat related in your systemPackages list?
11:41
<
clever >
Kim: thats odd, the version suffix on line 17 of your overlay is missing
11:40
<
clever >
Kim: and `realpath /run/current-system/sw/bin/weechat` ?
11:40
<
clever >
Kim: what does `which weechat` return?
11:34
<
clever >
Kim: i would expect that to continue to work, what error does it give?
11:10
<
clever >
ldlework: which is why i said earlier to callPackage the unstable qtile from the stable pkgs, so your not mixing opengl's
11:10
<
clever >
ldlework: its possible that the problem comes from using the unstable version of opengl against the stable opengl
10:52
<
clever >
ldlework: how does it mention overlays?
10:50
<
clever >
ldlework: and if you realpath that one?, its the updated version?
10:49
<
clever >
ldlework: `type qtile`, not try to start it
10:47
<
clever >
before you remove the overlay
10:47
<
clever >
ldlework: ctrl+alt+f1, login, and check `type qtile` again
10:40
<
clever >
ldlework: you may need to reboot after adding that overlay, it sounds like its doing something funky
10:38
<
clever >
ldlework: and does `ps` show several bashes?
10:38
<
clever >
ldlework: what about `echo $PATH` ?
10:38
<
clever >
ldlework: it shouldnt be giving a full storepath
10:37
<
clever >
ldlework: thats not right
10:36
<
clever >
ldlework: what does `type qtile` respond with?
10:36
<
clever >
have you considered just running nixos-unstable for the whole system?
10:33
<
clever >
unstable wants a list of overlays
10:32
<
clever >
`value is a set while a list was expected`
10:32
<
clever >
and look at the error closer
10:32
<
clever >
2018-08-06 07:07:51 < clever> its missing a { config = {}; overlays = []; }
10:32
<
clever >
value is a set while a list was expected, at /nix/store/797yi4rh4mzs1vfx6im9yznc9l4sj7bb-source/pkgs/top-level/stage.nix:175:8
10:32
<
clever >
overlays = {};
10:31
<
clever >
ldlework: oh, i found the problem
10:31
<
clever >
ldlework: line 66 shows that the problem comes from something you put into systemPackages
10:29
<
clever >
emily: ah, container may lack it
10:28
<
clever >
emily: you can also `man configuration.nix` and search with /
10:26
<
clever >
map can only ever return a list
10:24
<
clever >
ldlework: line 7 is shadowing builtins.filter
10:19
<
clever >
environment.variables.BROWSER = let foo = pkgs.writeScript "name" "body"; in "${foo}";
10:19
<
clever >
emily: a let block, lol
10:16
<
clever >
emily: you can also use pkgs.writeScript to just get a naked script at /nix/store/hash-name
10:16
<
clever >
emily: that will return a path to a directory that contains a bin/name binary
10:16
<
clever >
> pkgs.writeScriptBin "name" "#!${pkgs.stdenv.shell}\necho things"
10:15
<
clever >
emily: writeScriptBin
10:13
<
clever >
ldlework: looks good
10:07
<
clever >
its missing a { config = {}; overlays = []; }
10:07
<
clever >
but the "pure" pkgs will still obey your config.nix and overlays, which can screw things up
10:07
<
clever >
that will use the impure _pkgs to fetch a specific revision, when the pkgs arg has not otherwise been set
10:05
<
clever >
ldlework: by default, it just grabs a tarball
10:04
<
clever >
ldlework: yeah
10:04
<
clever >
every time you eval the expression, nix will import that path and hash it
10:03
<
clever >
pie_: src = ./.;
09:57
<
clever >
qtile = self.unstable.qtile;
09:57
<
clever >
then you need to overwrite qtile with an overlay
09:56
<
clever >
but you can also just directly do pkgs.unstable.qtile in the nixos config
09:56
<
clever >
that is also an option
09:56
<
clever >
ldlework: several options, unstable.qtile is one
09:54
<
clever >
ldlework: if you load the same overlay in both nixpkgs, it can cause recursion
09:53
<
clever >
pie_: $out hasnt been made yet, try postInstall instead
09:53
<
clever >
but in your case, you dont want the `qtile = unstable.qtile` overlay, because that would cause infinite recursion
09:52
<
clever >
you can then optionally give it its own overlays
09:52
<
clever >
ldlework: i generally import nixpkgs with { config = {}; overlays = []; } to make it pure
09:51
<
clever >
pie_: yeah
09:50
<
clever >
and ignore nixos-unstable entirely
09:50
<
clever >
you can also just download the current qtile/default.nix and load it with callPackage in your overlay
09:49
<
clever >
then it will cache things better
09:49
<
clever >
you can also replace nixos-unstable in the above example, with the current git rev of nixos-unstable
09:48
<
clever >
your better off using pkgs.fetchFromGitHub if your going to use a sha256
09:48
<
clever >
since its imported with {}, it will read ~/.config/nixpkgs/
09:47
<
clever >
also note, that unstable will not obey the same config/overlays
09:47
<
clever >
but that will re-download the tar every the you nixos-rebuild, and will update things without warning
09:44
<
clever >
but if you break it up in a let block, there is no need to force it
09:44
<
clever >
without that, `map m filter f list` would have tried to map over the filter function, and it would have immediately failed
09:44
<
clever >
filter originally had it, to force `map m (filter f list)` to filter first, then map on the result
09:43
<
clever >
the lines dont matter
09:43
<
clever >
its more about forcing the order of evaluation
09:43
<
clever >
the outer most set isnt needed
09:43
<
clever >
9 also has a useless set of parens
09:42
<
clever >
which is why 6 and 8 have to append path and n together
09:41
<
clever >
n just contains the name
09:40
<
clever >
you could, just add that to the filter function on 5
09:40
<
clever >
you need to give it the path to a directory that will only contain overlays and nothing else
09:37
<
clever >
ldlework: because now nixcfg_overlays_default.nix is also being loaded as an overlay
09:36
<
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
09:35
<
clever >
and 8 is missing a trailing ;
09:34
<
clever >
let content =
09:33
<
clever >
ldlework: the let keyword is missing after the = so it wont parse right
09:29
<
clever >
it then runs the filter on 53 over that
09:28
<
clever >
attrNames on 54 reduces it to a list of names
09:28
<
clever >
which is a set mapping name to type (string)
09:28
<
clever >
line 51 is the result of readDir
09:27
<
clever >
i dont think its recursive
09:27
<
clever >
ldlework: an importing map that takes a directory of overlays
09:22
<
clever >
but the python setup hooks generate PYTHONPATH from that, and may copy it into the makeWrapper
09:22
<
clever >
propagatedBuildInputs on its own has no impact on the runtime
09:22
<
clever >
pie_: sorta
2018-08-05
21:40
<
clever >
try just looking near the installPhase
21:39
<
clever >
and then you can just backspace it out
21:39
<
clever >
the ^M should now be visible
21:38
<
clever >
or maybe its `:set ff=unix`
21:37
<
clever >
petersjt014[m]: try `:set ffs=unix` i think
21:34
<
clever >
petersjt014[m]: and if you run the `file` program on that file?
21:32
<
clever >
double-check the installPhase you pasted into that file, is it free of \r's?
21:31
<
clever >
i cant find it in nixpkgs master
21:30
<
clever >
petersjt014[m]: can you grep all of your nix expressions, including nixpkgs, for broadcom-rpi3-extra or a shorter variant
21:28
<
clever >
petersjt014[m]: does that name exist in any of your nix expressions?
21:24
<
clever >
its doing something like buildPhase = ''\nfoo\r\nbar\n'';
21:24
<
clever >
read the .nix file for the derivation that failed
21:24
<
clever >
petersjt014[m]: then the variable for the current phase contains a \r
21:20
<
clever >
if vim detects it as linux line endings, it will render the \r specially, because its not expected
21:19
<
clever >
mount the hdd on another box?
21:16
<
clever >
petersjt014[m]: you can also just scp the file to another box
21:16
<
clever >
petersjt014[m]: vim can show the line endings
21:15
<
clever >
petersjt014[m]: the line numbers are offset a bit by compiling it
21:15
<
clever >
petersjt014[m]: run an editor on the copy in the nix store, to get context
21:08
<
clever >
stdenv-linux has a copy of this file
21:04
<
clever >
yeah, once you confirm it works you can file a PR
21:04
<
clever >
petersjt014[m]: you need to edit a copy of nixpkgs that you clone from github
20:16
<
clever >
oops, nixpkgs, not noxpkgs
20:14
<
clever >
elvishjerricco: `nix run noxpkgs.xfce.xfconf` first to get it into PATH
20:11
<
clever >
just try manually running it from a text console at first
20:09
<
clever >
what happens if you run xfconf-query as the right user, without any X running?
20:08
<
clever >
selfsymmetric-mu: see if you cant find a way to edit the config in $HOME without xfce running?
19:45
<
clever >
mikky: but it think it will still copy the kernels into the fat32
19:44
<
clever >
mikky: the source claims systemd-boot works in that setup
19:41
<
clever >
then the kernels+initrds are on ext4 for ex, and only the .efi stub is on fat32
19:40
<
clever >
boot.loader.efi.efiSysMountPoint = "/boot/EFI/"; allows that
19:40
<
clever >
mikky: nixos also lets you use fat for /boot/EFI/ and then anything not encrypted for /boot/
19:39
<
clever >
mikky: as long as /boot is fat32, efisystem, and mounted correctly, systemd-boot should just work
19:31
<
clever >
mikky: ah, if you have control over another bootloader, it doesnt matter as much
19:28
<
clever >
mikky: you can usually set the installAsRemovable option for grub, and then it will boot
19:24
<
clever >
mikky: your welcome :)
19:19
<
clever >
or config files in /etc/
19:14
<
clever >
jonreeve: does `ls /run/current-system/sw/share/applications` show the desktop files?
19:13
<
clever >
jonreeve: have you logged out and back in since installing them?
19:04
<
clever >
judson: all you have to do is set enableACME = true;
19:03
<
clever >
judson: the nginx modules in nixos handle .well-known for you automatically
18:13
<
clever >
azazel: note lines 9, 12, 16, and 22
18:13
<
clever >
azazel: you should already have a $NIX_BUILD_TOP and the various temp vars should be pointing within it
18:03
<
clever >
azazel: and if you add this to the buildInputs glibcLocales
17:58
<
clever >
export a variable in preCheck?
17:55
<
clever >
everything from invalid utf8 combinations to sql injections to brain injections, lol
17:55
<
clever >
azazel: this file contains strings known to break some software
17:48
<
clever >
so its just constantly reconnecting
17:48
<
clever >
and then it rescans all directories, and fails once more
17:48
<
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
17:48
<
clever >
azazel: all i could do to find my issue was to strace the program and look over the logs closely
17:46
<
clever >
azazel: find all non-utf8 filenames and move them out of the searchpath of that program, lol
17:43
<
clever >
and ive got got old files made by another os, that upset it
17:43
<
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