2017-07-31
21:39
<
clever >
pie_: try adding pkgconfig to the nix-shell args
21:28
<
clever >
mpcsh: for example, just run the inner most fetchurl in nix-repl
21:28
<
clever >
mpcsh: and also run the parts in nix-repl
21:10
<
clever >
so it will be doing 2 downloads at eval time
21:09
<
clever >
but since you lack the nix hash, you need to use builtins.fetchurl again to download it
21:09
<
clever >
you can then readfile, fromjson, and build another url based on the version in there
21:09
<
clever >
if you run builtins.fetchurl on the above url, it will check it with some internal caching
21:08
<
clever >
mpcsh: depends on where you get the json from
21:07
<
clever >
Infinisil: you can also just builtins.fromJSON and builtins.readFile then manipulate it with nix
19:29
<
clever >
ixxie: if you are importing nixpkgs in your nix file, then you have to set config in there
19:27
<
clever >
ixxie: it will depend on what your running nix-shell against as well
19:27
<
clever >
kiloreux: strange, i dont see the default.nix in that dir
19:24
<
clever >
ixxie: maybe --arg config '{ allowUnfree = true; }'
19:23
<
clever >
kiloreux: i need more of the ls output
19:21
<
clever >
ixxie: set allowUnfree in your users config.nix file
19:20
<
clever >
kiloreux: and ls -ltrh
19:19
<
clever >
kiloreux: what is the output of nix-build -v ?
19:19
<
clever >
i suspect that kiloreux is using the full script, rather then the stub in the gist
19:18
<
clever >
same path as me
19:17
<
clever >
pull also works, but ive found push auth to be tricky
19:16
<
clever >
srhb: are you aware that you can just run "git clone" on a gist url?
19:16
<
clever >
srhb: your default.nix is one byte longer, as is the script.py
19:14
<
clever >
srhb: can you gist the output of running ls -ltrh and nix-build -v
19:12
<
clever >
srhb: yv4148n89z0j5n57fwz6kwcj640fnvsh ?
19:12
<
clever >
srhb: and if you test that gist?
19:10
<
clever >
kiloreux: what error do you get with that gist?
19:08
<
clever >
works on this end
19:03
<
clever >
can you gist both files?
19:02
<
clever >
builtins.fetchTarball
18:59
<
clever >
fetchtarball, not fetchurl
18:59
<
clever >
can you gist the entire file?
18:59
<
clever >
import takes that path, and returns the object (a nix function)
18:59
<
clever >
builtins.fetchurl takes a url and returns a string pointing to the store
18:58
<
clever >
it needs the with still
18:54
<
clever >
you almost never need to delete things from the store
18:54
<
clever >
just leave it
18:53
<
clever >
once you put in the right git rev, yeah
18:51
<
clever >
to isolate it from changes the user may have in ~/.nixpkgs/config.nix
18:51
<
clever >
an example i yanked from my #nixos logs
18:49
<
clever >
set the $NIX_PATH env variable
18:48
<
clever >
you have to pass the same -I every time if you want it to keep having an effet
18:48
<
clever >
the -I flag doesnt change any config
18:47
<
clever >
kiloreux: you appear to be using nixpkgs f2c4af4e, not a7c8f5e419
18:45
<
clever >
kiloreux: nix-instantiate --find-file nixpkgs
18:43
<
clever >
kiloreux: what does this return?
18:43
<
clever >
nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion
18:33
<
clever >
yeah, its just a string value
18:33
<
clever >
so even if you unquote it, its still a string
18:33
<
clever >
Infinisil: the nix parser treats all URI's as strings
18:31
<
clever >
Infinisil: looks like it
18:30
<
clever >
Infinisil: one sec
18:28
<
clever >
Infinisil: those should all be reasonably modern
18:28
<
clever >
1tb Seagate Barracuda 7200.14 (AF) * 3 + Western Digital Caviar Green 1tb
18:27
<
clever >
Infinisil: the raidz1 is over modern drives, the L2 is on a slightly older drive
18:27
<
clever >
Infinisil: raidz1 over 3 drives, with an L2 arch on a 4th to speed up reads
18:26
<
clever >
Infinisil: an example of how slow gc can get
18:26
<
clever >
Jul 31 04:07:36 nas nix-gc-start[29805]: note: currently hard linking saves 86631.22 MiB
18:26
<
clever >
Jul 31 00:17:23 nas nix-gc-start[29805]: deleting unused links...
18:20
<
clever >
thats what wrapProgram is doing
18:18
<
clever >
its in the search path, it should work
18:18
<
clever >
thats strange
18:16
<
clever >
kiloreux: can you gist the contents of result/bin/output?
18:08
<
clever >
tilpner: no real way to do that right now, and calling wrapProgram twice results in an infinite loop
18:08
<
clever >
tilpner: are you trying to modify how it wraps it?
18:06
<
clever >
/home/clever/apps/nixpkgs/pkgs/tools/security/eid-viewer/default.nix: wrapProgram $out/bin/eid-viewer --suffix LD_LIBRARY_PATH : ${pcsclite}/lib
18:06
<
clever >
/home/clever/apps/nixpkgs/pkgs/tools/filesystems/fuse-7z-ng/default.nix: wrapProgram $out/bin/${pname} --suffix LD_LIBRARY_PATH : "${libs}/p7zip"
18:05
<
clever >
/home/clever/apps/nixpkgs/pkgs/development/compilers/rust/cargo.nix: ${stdenv.lib.optionalString stdenv.isDarwin ''--suffix DYLD_LIBRARY_PATH : "${rustc}/lib"''}
18:05
<
clever >
a grep over nixpkgs should provide examples
18:05
<
clever >
i think its this one
18:04
<
clever >
you want to use the --append mode in wrapProgram
18:03
<
clever >
it will eval to the full store path
18:03
<
clever >
by including the exact string, ${gnome2.gtk}/lib/, inside default.nix
18:02
<
clever >
so you want to append ${gnome2.gtk}/lib/ to LD_LIBRARY_PATH
18:02
<
clever >
kiloreux: gnome2.gtk is the attribute path with that library
18:02
<
clever >
which is anti-nix
18:02
<
clever >
that relies on the end-user installing things
18:00
<
clever >
clearing LD_LIBRARY_PATH will only make it worse
17:59
<
clever >
you need to append the gtk lib dir to LD_LIBRARY_PATH
17:58
<
clever >
kiloreux: which arguments did you give to wrapProgram?
17:55
<
clever >
Infinisil: i think the nix-hash command can do it
17:51
<
clever >
and auto only gets cleaned up at gc
17:51
<
clever >
and the autolinks point into an area of /tmp that gets cleaned up pretty fast
17:51
<
clever >
i think nix-push has one derivation per derivation
17:50
<
clever >
Infinisil: and remember, nix uses a non-standard base32
17:50
<
clever >
Dezgeg: how the hell does that happen.......
17:47
<
clever >
kiloreux: can you gist everything from the console when you tested it?
17:45
<
clever >
and it has to read all of that to give a directory listing
17:44
<
clever >
Infinisil: yeah
17:44
<
clever >
c2d is xfs, the rest are zfs
17:43
<
clever >
ls -lhd /nix/store/.links/
17:43
<
clever >
c2d: drwxr-xr-x 2 clever clever 1.9M Feb 8 2016 /nix/store/.links/
17:43
<
clever >
nas: drwxr-xr-x 2 root root 1.6M Jul 31 14:39 /nix/store/.links/
17:43
<
clever >
amd: drwxr-xr-x 2 root root 1022K Jul 28 22:10 /nix/store/.links/
17:42
<
clever >
i'm only building a small subset of nixpkgs
17:40
<
clever >
tilpner: you ran nix-store --optimize at some point, and it made hardlinks to save space
17:39
<
clever >
causing reads and writes to be interleaved
17:39
<
clever >
nix-collect-garbage also has to lstat every single entry, and conditionaly unlink
17:38
<
clever >
thats from my new hydra setup
17:38
<
clever >
real 4m0.277s
17:38
<
clever >
[root@nas:~]# time ls /nix/store/.links | wc -l
17:38
<
clever >
and thats on a less used nix build slave
17:38
<
clever >
real 0m0.710s
17:38
<
clever >
clever@c2d ~ $ time ls /nix/store/.links/ | wc -l
17:37
<
clever >
LnL: so duplicate files hardlink to the same hash, and share the on-disk data
17:37
<
clever >
LnL: after nix-store --optimize, every single file in the entire store is hardlinked to /nix/store/.links/<hash>, based on the hash of the file
17:36
<
clever >
Infinisil: nix-collect-garbage has to list the contents, and delete everything with a hardlink count of 1
17:35
<
clever >
LnL: and /nix/store has the same problem to a lesser degree
17:34
<
clever >
jluttine: nix-prefetch-url -A foo.src
17:34
<
clever >
too many files in one directory
17:33
<
clever >
LnL: reading /nix/store/.links/ takes hours
17:33
<
clever >
so its still better
17:33
<
clever >
but its only a cost at gc, while dedup would be a cost at every write
17:33
<
clever >
yegortimoshenko: on my NAS, that part of the GC can take upwards of 10 hours
17:32
<
clever >
yegortimoshenko: depending on your filesystem, it can make garbage collection unusually slow
17:16
<
clever >
kiloreux: you want nix-build -I nixpkgs=https://github.com/NixOs/nixpkgs/archive/a7c8f5e419.tar.gz
17:16
<
clever >
i ctrl+f'd for binary, found no definitions, and then looked at the with's
17:15
<
clever >
ixxie: because they used with statements, you guess
17:15
<
clever >
kiloreux: so nix-build continues to use the previous version
17:15
<
clever >
kiloreux: and it doesnt change any config
17:15
<
clever >
kiloreux: that nix-env command tells nix-env to install EVERYTHING in nixpkgs
17:14
<
clever >
ixxie: line 41, i suspect its using chromium.upstream-info.binary
17:14
<
clever >
kiloreux: why do you think its doing the wrong thing?
17:13
<
clever >
kiloreux: nix will detect when things have changed and do the right thing
17:13
<
clever >
kiloreux: 90% of the time, you dont need to
17:10
<
clever >
ixxie: can you link an example?
17:10
<
clever >
hodapp: when you give it a path to a nix file, it just runs the top level value, in the same way as -A
17:07
<
clever >
hodapp: they wont run until you run the unpackPhase and patchPhase
17:03
<
clever >
kiloreux: i tested it against a7c8f5e419
17:01
<
clever >
kiloreux: which channel are you building this on?
17:01
<
clever >
kiloreux: my opencv doesnt try to load gtk when i run it
17:00
<
clever >
kiloreux: this is a different so file
16:59
<
clever >
kiloreux: thats not the same problem, thats an entirely different problem
16:55
<
clever >
kiloreux: try closing that shell and re-opening it, other env variables you set might be messing with it
16:52
<
clever >
Phillemann: does it have the ability to detect if the file has already been downloaded?
16:51
<
clever >
Phillemann: if its doing network during a build, its already broken, and that should be stopped first
16:50
<
clever >
nix-build creates a result symlink in the directory you ran it in
16:49
<
clever >
kiloreux: that doesnt start with ./result/
16:46
<
clever >
kiloreux: and what happens when you run ./result/bin/output ?
16:42
<
clever >
kiloreux: can you gist the output of nix-build?
16:41
<
clever >
nixos-rebuild may also accept -v
16:40
<
clever >
rydnr: add -v to the nix-build command and you will see every file its reading
16:38
<
clever >
rydnr: it looks like you customized NIX_PATH and it now ignores all channels
16:05
<
clever >
pie_: i mainly use nix-shell and then ./configure && make
16:03
<
clever >
nix-env is not the way to test things
16:03
<
clever >
kiloreux: i run nix-build on it
15:58
<
clever >
bkchr: use wrapProgram to prepend sshfs to PATH
15:31
<
clever >
list everything you need in the default.nix and nix will fetch them for you
15:31
<
clever >
the entire point of nix, is to make it work without the user having to install other things
15:30
<
clever >
surprisingly, python.withPackages delt with the opencv libs automatically
15:29
<
clever >
kiloreux: i dont get any errors when i run the script produced by that gist
15:22
<
clever >
it doesnt have the LD_LIBRARY_PATH fix yet, i'm waiting for opencv3 to compile to test that
15:21
<
clever >
no need to mess with PYTHON_PATH
15:21
<
clever >
that is what i have so far
15:20
<
clever >
but you have done neither
15:20
<
clever >
because the nix expression should also be patching LD_LIBRARY_PATH
15:19
<
clever >
thats what the nix expression should be doing for you
15:16
<
clever >
kiloreux: how is numpy getting into the python search path?
15:16
<
clever >
FRidh: all interpreted languages, because we cant patchelf the interpreter
15:15
<
clever >
kiloreux: attribute, not store path
15:15
<
clever >
FRidh: its a problem common to all of java and python
15:14
<
clever >
kiloreux: and what was the nix attribute path for opencv?
15:12
<
clever >
kiloreux: can you add a simple python script that imports the problem module?
15:12
<
clever >
kiloreux: i dont see that changing LD_LIBRARY_PATH any
15:02
<
clever >
gchristensen: and would also open up the option to make it more cross-platform, if we ever get multi-user on ubuntu for ex
15:00
<
clever >
gchristensen: does the above util sound useful?
14:56
<
clever >
gchristensen: sudo update-nix.conf --append binary-caches ... --append binary-cache-public-keys ... --restart
14:56
<
clever >
gchristensen: i was just thinking, what about a util for nix on darwin, that would help manipulate nix.conf and reloading nix-daemon
04:58
<
clever >
thats the kernel to blame
04:56
<
clever >
sauyon: in this case, the error was because a list containing a set was passed to makeLibraryPath
04:55
<
clever >
cmcdragonkai: qt5.full
04:55
<
clever >
qt5.full.out 0 s /nix/store/kg36kcq4kx2m0j33ynz3bjllsd7li4zk-qt-5.8.0/lib/libQt5Core.so.5
04:54
<
clever >
correction, only qt5 is a set
04:53
<
clever >
cmcdragonkai: qt4 and qt5 are sets, not derivations
04:50
<
clever >
cmcdragonkai: can you gist your nix expression?
04:46
<
clever >
i'm not sure when the last or next one even is here, lol
04:44
<
clever >
sauyon: mkdir -pv $out/bin/
04:43
<
clever >
same, i just use cp
04:40
<
clever >
cmcdragonkai: the stdenv will cd into it for you, so .
04:37
<
clever >
my NAS was setup before i did that, and now i have to delete several weeks worth of backups just for nix-collect-garbage to have any effect
04:36
<
clever >
i turned off snapshots for /nix
04:35
<
clever >
Infinisil: so it always copies, and cant even share the blocks on-disk (enless i turn on dedup!)
04:35
<
clever >
Infinisil: in my case, / and /nix are seperate datasets in the same zfs pool, and the linux kernel isnt smart enough to understand that
04:35
<
clever >
cmcdragonkai: still simpler to test under nix-shell
04:34
<
clever >
cmcdragonkai: atomic doesnt really matter much in this case, it just makes mv as slow as cp
04:33
<
clever >
if you are using a sandbox, or the FS's dont match up, a move is just cp + rm
04:33
<
clever >
though if your not using a sandbox, and /tmp is on the same fs as /nix/store, a move might be atomic
04:32
<
clever >
Infinisil: for a normal build it wont matter, but it can make testing under nix-shell harder
04:31
<
clever >
copy is usually better then move
04:30
<
clever >
cmcdragonkai: or strace the program to see what paths it tries to open
04:22
<
clever >
dalaing: another simpler option might be to just try changing the nixpkgs channel hydra is using temporarily
04:22
<
clever >
dalaing: then it might have been a problem with the ghc that pandoc linked to
04:21
<
clever >
dalaing: did it fix the problem when it did so?
04:21
<
clever >
dalaing: yeah, hydra will either download it from the binary cache, or re-build it
04:14
<
clever >
simpson: have a look at the vid i just linked
04:12
<
clever >
Infinisil: cats will do that
04:11
<
clever >
normally, if you want something off, you just turn it off in the nixos config, and it ceases to exist
04:11
<
clever >
sauyon: the entire enable/disable section of systemd has been disabled, everything is just on all the time
04:00
<
clever >
sauyon: depends heavily on what the os has done to generate the iso
04:00
<
clever >
which was already usb bootable to begin with
04:00
<
clever >
sauyon: those modes break the nixos image
03:59
<
clever >
sauyon: unetbootin has special modes to extract the kernel and initrd and mess with things to make iso only images boot from usb
03:58
<
clever >
Infinisil: the nixos iso is a specially made hybrid image, that can boot on usb or an iso, just burn the iso directly to a usb
03:57
<
clever >
the nixos iso can just be dd'd directly to a usb stick
03:57
<
clever >
unetbootin breaks the nixos ISO
03:54
<
clever >
noobly: what about ps aux | grep wpa_suppicant
03:52
<
clever >
noobly: wpa_cli, then status, scan, and scan_results
03:51
<
clever >
noobly: journalctl -f -u wpa_supplicant
03:33
<
clever >
dalaing: rebooting is the simplest way to clear them all, something has come up now
03:33
<
clever >
dalaing: ah yeah, nix also checks for roots in /proc, for in-use files
03:33
<
clever >
Kaydee: and it will conflict with the other ghc's that have packages you want
03:32
<
clever >
Kaydee: the main ghc attribute lacks all packages on hackage, so its not of much use
03:30
<
clever >
Kaydee: check the man page for nix-collect-garbage, the --delete-older-than i think
03:29
<
clever >
Kaydee: no more spam, and if things break horribly and you hard-reset, all changes are undone
03:29
<
clever >
Kaydee: "nixos-rebuild test" will activate it without putting it into the bootloader
03:28
<
clever >
sauyon: pastebin
03:27
<
clever >
Kaydee: there is also stack2nix, which can generate a tree of haskell packages for every version in your stack file
03:26
<
clever >
Kaydee: i never experience cabal hell
03:26
<
clever >
Kaydee: i learned nix before stack&cabal, so i just dont use either
03:25
<
clever >
Kaydee: you have to create a new ghc, using ghcWithPackages
03:25
<
clever >
Kaydee: one reason for that, there is no way to tell that ghc what packages it can import
03:25
<
clever >
Kaydee: things like ghc shouldnt be installed, but loaded in a nix-shell
03:24
<
clever >
dalaing: you can also try manualy deleting those hydra roots, and then nix-store --delete the bad path
03:24
<
clever >
Kaydee: but nix-env can search current and root
03:24
<
clever >
Kaydee: poor UI, nix-channel --list only shows the current user
03:23
<
clever >
Kaydee: adding channels to users tends to make things harder to manage
03:23
<
clever >
Kaydee: that tells it to use the channel called nixos
03:22
<
clever >
Kaydee: what does that do?
03:22
<
clever >
Kaydee: and nix-env -iA nixos.ghc
03:21
<
clever >
Kaydee: what does "ls -lh ~/.nix-defexpr/" say?
03:20
<
clever >
Kaydee: they will use roots channels automatically
03:19
<
clever >
mpcsh: services.kbfs.mountPoint = "...";
03:19
<
clever >
dalaing: and are those jobsets set to keep 0 evals?
03:18
<
clever >
dalaing: did you start the hydra-update-gc-roots service?
02:56
<
clever >
i think you need ip -6 route
02:53
<
clever >
so it wont block you right away
02:53
<
clever >
tilpner: oh, that block script only runs every 10mins
02:51
<
clever >
dhess: cabal2nix will detect if you generate docs, and set the right boolean to activate my changes
02:50
<
clever >
Infinisil: did you link the script on gist?
02:46
<
clever >
tilpner: the logs for named (the dns server)
02:45
<
clever >
i find slim still works for all of my systems
02:42
<
clever >
its just enabled by default
02:41
<
clever >
yeah, that often :P
02:41
<
clever >
so they update more often
02:40
<
clever >
the -small channels wait for testing, but not full binary cache coverage
02:40
<
clever >
dhess: it appears to be in nixos-unstable-small
02:38
<
clever >
dhess: and with master, and running strip over the binary, it went down to 30mb
02:38
<
clever >
dhess: with master, it was 151mb
02:38
<
clever >
dhess: with nixos-unstable, the closure of a shake script is 1.6gig
02:38
<
clever >
dhess: the docs are now in a .doc output, and can potentially be GC'd out
02:37
<
clever >
dhess: a PR i recently got into master handles that fully
02:37
<
clever >
i run my browser in a terminal, just because it likes to randomly segfault, and i want to see that
02:37
<
clever >
which is the journal for the display-manager.service unit
02:36
<
clever >
and if you launch something from the xfce panel and such, stdout goes to the same stdout as the display manager
02:36
<
clever >
i think chrome is only logging to stdout
02:24
<
clever >
it could also be that they are just testing you, to see if you can join in a later attack
02:23
<
clever >
so no level of source based blocking will stop it, you are blocking based on the intended target, not the real source
02:22
<
clever >
and if your dns server was an open recursive resolver, you would join the DDoS, by sending a 4kb reply
02:22
<
clever >
it sounds like those chinese IP's your seeing, are actually the victims, with a spoofed source ip