2017-07-23
18:01
<
clever >
Infinisil: lets see what happens if i lack /dev/kvm!
18:00
<
clever >
Infinisil: also, crippling the host with memory usage doesnt seem to make the problem more likely
17:57
<
clever >
and it will clone them
17:57
<
clever >
but the kernel/cpu is too dumb to know when you write zero's to the zero page
17:56
<
clever >
and the kernel probably gives it a CoW clone of that zero page
17:56
<
clever >
mmap(NULL, 1073745920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5f88ed7000
17:56
<
clever >
for an malloc this big, its probably going to mmap
17:56
<
clever >
sub connectmachine# [ 13.695150] xsession[867]: IceWM: using /root/.icewm for private configuration files
17:56
<
clever >
so gcc just omited everything
17:56
<
clever >
gcc knew that bzero only affects p, and nothing used p
17:55
<
clever >
and only if this is in as well
17:55
<
clever >
bzero(p, 1024*1024*1024);
17:55
<
clever >
this makes the program cripple my machine (as it was supposed to)
17:55
<
clever >
printf("%p\n", p);
17:55
<
clever >
this is instant
17:55
<
clever >
void *p = malloc(1024*1024*1024);
17:54
<
clever >
the instant i started to print the pointer with printf, it actualy got slow
17:54
<
clever >
thats only for freshly allocate memory
17:53
<
clever >
zero's out a range of memory
17:53
<
clever >
the bzero was to "use" the ram
17:52
<
clever >
Infinisil: it ran in 0.00 seconds, because even with the bzero, gcc knew i never referenced the data, and optimized it out
17:52
<
clever >
Infinisil: gcc is getting too smart, i wrote a program that malloc's 10gig of ram, and runs bzero over it all
17:45
<
clever >
nh2: yeah, i dont know why thats working either
17:44
<
clever >
sub connectmachine# [ 19.309685] xsession[849]: IceWM: MappingNotify
17:44
<
clever >
Infinisil: and the instant i say that, i get a new failure
17:43
<
clever >
Infinisil: i have yet to get it to fail
17:42
<
clever >
bhipple[m]: some of my php libraries dump every function argument in the backtrace, including the raw query, and the mysql password
17:31
<
clever >
bhipple[m]: that password will wind up in at least a .drv file in /nix/store/
17:31
<
clever >
bhipple[m]: there is a builtins.readFile, but that happens at eval time, so its not impure
17:30
<
clever >
bhipple[m]: yeah
17:29
<
clever >
bhipple[m]: i mostly do a passwords.nix containing { foo = "bar"; ... } and then near the top of a module, let passwords = import ./password.nix; in ...
17:28
<
clever >
and now that i think of it, hydra can also offer up its own nix store in full.....
17:27
<
clever >
there are some things like hydra where the code just doesnt allow reading the secrets from another location
16:53
<
clever >
nh2: i can also confirm rebase is in the hackage-packages.nix for vector-builder, under testHaskellDepends
16:52
<
clever >
so every failed build just sits there using space, until you reboot or rm -rf
16:52
<
clever >
mpickering: nix never cleans those up
16:52
<
clever >
mpickering: oh, where you building with -K a lot?
16:50
<
clever >
so it tends to be rather large
16:50
<
clever >
nh2: i dont think there are any existing tools that will trim the tree at leaves that are in the binary cache
16:49
<
clever >
mpickering: du /run/user/0 -h
16:47
<
clever >
mpickering: what is your free space like?
16:47
<
clever >
but some things like haskell want to modify the derivation to make it suitable for shell use
16:46
<
clever >
nh2: i also recently rediscovered, you can run nix-shell directly on a .drv file
16:46
<
clever >
nh2: nix-instantiate and nix-store -q --tree
16:45
<
clever >
does it give any other output when failing?
16:45
<
clever >
oh, on closer inspection, you already have that nix, lol
16:44
<
clever >
try this one
16:44
<
clever >
nix-store -r /nix/store/866pyym5zgvx78kr55pwas16xp1m0sjp-nix-1.11.11
16:43
<
clever >
ah, and i gave a bad path there
16:43
<
clever >
mpickering: what did you do to the system?, does /etc/nix/nix.conf exist?
16:42
<
clever >
mpickering: what about nix-store -r /nix/store/kw31dip97zpfjzz24q2j9bzsgcav6mgc-nix-1.11.1
16:25
<
clever >
Infinisil: oh, and due to the previously mentioned zfs trouble, nix-store --delete takes several minutes
16:23
<
clever >
error: getting status of ‘/home/clever/nixpkgs/warning:’: No such file or directory
16:23
<
clever >
+ nix-store --delete warning: you did not specify '‘--add-root’;' the result might be removed by the garbage collector /nix/store/c229x42kja0bkdj3mipvz12bhpcc66ym-vm-test-run-keymap-neo
16:20
<
clever >
just need to trigger the bug again
16:20
<
clever >
Infinisil: yep, already doing that
16:18
<
clever >
mpickering: my usual response to that is to throw strace at it
16:11
<
clever >
Infinisil: yep, found the cause
16:06
<
clever >
mpickering: anything in dmesg?
16:04
<
clever >
399 mke2fs -t ext4 ${cfg.bootDevice}
16:04
<
clever >
Infinisil: i suspect its hanging here, adding more prints
16:04
<
clever >
nixos/modules/virtualisation/qemu-vm.nix
16:02
<
clever >
this is the last thing a hung run has produced
16:02
<
clever >
machine# mke2fs 1.43.4 (31-Jan-2017)
16:01
<
clever >
Infinisil: this is the output from the middle of a passing run
16:01
<
clever >
machine# mke2fs 1.43.4 (31-Jan-2017)
16:01
<
clever >
machine# Creating filesystem with 131072 4k blocks and 32768 inodes
15:59
<
clever >
Infinisil: i think ive only had 2 failures in the last half hour
15:55
<
clever >
havent kept count
15:47
<
clever >
407acb80fc0890e62597e170cc00d9e873e37e34
15:46
<
clever >
which would imply that the nixos guest isnt responding on the serial console
15:46
<
clever >
Infinisil: after running it about a dozen times, it has hung, but the order of the prints i added says the accept blocks, and its not a race
15:45
<
clever >
accepted shell
15:42
<
clever >
line 240 then uses the socket accept made
15:42
<
clever >
line 179 will accept a connection from the child (does it block, or happen in the background??)
15:41
<
clever >
line 236 starts the qemu process (which will connect back to a listening unix socket)
15:41
<
clever >
Infinisil: oh, i wonder if this is a race condition...
15:40
<
clever >
so the perl code just starts it on-demand, the first time something is done to it
15:39
<
clever >
Infinisil: aha, the keymap test doesnt start the vm
15:36
<
clever >
Infinisil: patched my Machine.pm with more print statements, re-running
15:33
<
clever >
though timestamps in the logs will vary, so it will technically fail
15:33
<
clever >
Infinisil: i think this one makes it do the build 10 times, and complain if the outputs dont match exactly
15:29
<
clever >
[clever@amd-nixos:~/nixpkgs]$ nix-build nixos/release.nix -A tests.keymap.neo.x86_64-linux --option build-repeat 10 --check
15:28
<
clever >
Infinisil: and this nixos module provides a root shell on that dedicated serial port
15:28
<
clever >
[clever@amd-nixos:~/nixpkgs]$ nix-build nixos/release.nix -A tests.keymap.neo.x86_64-linux
15:27
<
clever >
so there is a dedicated serial port on the guest, linked to the shell unix socket
15:27
<
clever >
i forgot to run it under time
15:27
<
clever >
"-device virtio-serial -device virtconsole,chardev=shell " .
15:27
<
clever >
"-monitor unix:./monitor -chardev socket,id=shell,path=./shell " .
15:26
<
clever >
and it gets that socket by accepting a connection on shellS
15:26
<
clever >
it waits 300 seconds for a line to appear on the socket
15:24
<
clever >
second run passed, test script finished in 18.04s
15:24
<
clever >
Infinisil: i ran the test twice on my machine, first one failed timed out waiting for the VM to connect
15:22
<
clever >
the tests that have passed cant be restarted
15:00
<
clever >
Infinisil: my first guess is either timeouts due to a slow host, or iceWM eating keystrokes
14:59
<
clever >
machine# [ 31.289923] xsession[856]: IceWM: MappingNotify
14:58
<
clever >
machine: sending monitor command: sendkey f
14:58
<
clever >
machine# [ 30.265567] layer1[1012]: Waiting for 'f' to be typed
14:58
<
clever >
machine# [ 26.269645] layer3[955]: SUCCESS: Got back '}' as expected.
14:57
<
clever >
strange for only some of them to fail like that
14:55
<
clever >
yeah, but this test involves programaticaly sending keystrokes to the guest
14:53
<
clever >
then the vm acceleration should be working
14:53
<
clever >
Infinisil: and you have r/w to it?
14:52
<
clever >
Infinisil: does /dev/kvm exist?
14:50
<
clever >
then just edit the nix files, add debug, and re-run
14:50
<
clever >
Infinisil: that would launch the entire test, and print the result
14:50
<
clever >
Infinisil: nix-build '<nixpkgs/nixos/release.nix>' -A tests.keymap.x86_64-linux
14:49
<
clever >
Infinisil: so its likely, that the testreader isnt getting the keys that perl sent to the vm
14:48
<
clever >
then the host blocks on the guest creating files
14:48
<
clever >
and the testreader in the guest reads them
14:48
<
clever >
the perl on the host sends keys to the guest
14:47
<
clever >
so it has to use that to block on things inside the script
14:47
<
clever >
Infinisil: aha, line 69 runs a script in the guest, in the background
14:47
<
clever >
wait for a file, cat it, then delete it?
14:46
<
clever >
i cant even tell what that bash is doing
14:45
<
clever >
Jul 23 11:42:08 nas nix-gc-start[7180]: deleting ‘/nix/store/trash’
14:45
<
clever >
Jul 23 11:42:08 nas nix-gc-start[7180]: deleted or invalidated more than 16581001216 bytes; stopping
14:45
<
clever >
that is the true mystery of zfs
14:44
<
clever >
so why does 200mb of on-platter cache help more?
14:44
<
clever >
it could have bumped that up by 200mb, and gotten bigger benefits
14:44
<
clever >
Infinisil: it already has 1.7gig of in-ram cache
14:44
<
clever >
Infinisil: i think that perl function tuns the script under the context of the guest vm
14:42
<
clever >
its nice that its faster, but why is it faster?
14:42
<
clever >
Infinisil: it could have easily used another 300mb of ram and gotten better benefits...
14:41
<
clever >
Infinisil: it somehow feels much snappier after adding an L2 cache, even though its only using 200mb so far
14:35
<
clever >
in the past, i also had a bug in my gpu drivers that reduced it to about 1 line per frame, with vsync
14:32
<
clever >
after about 15 minutes, the ls of /nix/store finished, 236,608 files
14:32
<
clever >
mostly rwait
14:32
<
clever >
i'm seeing 40 reads/sec and writes/sec to each of the 3 drives
14:30
<
clever >
80 to 85% %util
14:30
<
clever >
Infinisil: iostat says its almost entirely IO bound
14:29
<
clever >
4gig of ram
14:29
<
clever >
model name : AMD A6-5400K APU with Radeon(tm) HD Graphics
14:28
<
clever >
a single GC cycle also ran overnight, and was still going when i woke up in the morning
14:27
<
clever >
a garbage collection is also running
14:27
<
clever >
over 10 minutes now
14:26
<
clever >
the nas is still doing an ls of store
14:25
<
clever >
Infinisil: my desktop can list /nix/store/.links/ in 1m 48sec, and it contains 1,045,532 entries
14:24
<
clever >
Infinisil: amd/nix on /nix/store type zfs (ro,noatime,xattr,noacl)
14:23
<
clever >
sssd.out 24,080 x /nix/store/v4fd35aal24a7incamr9xr9hqw0gx4vh-sssd-1.14.2/lib/libsss_nss_idmap.so.0.2.0
14:23
<
clever >
[clever@amd-nixos:~]$ ./apps/nix-index/result/bin/nix-locate libsss_nss_idmap.so.0
14:20
<
clever >
exactly what i'm wondering
14:20
<
clever >
real 0m27.629s
14:19
<
clever >
drwxrwxr-t 22684 root nixbld 84K Jul 23 09:50 /nix/store/
14:19
<
clever >
the desktop is currently an SSD mirror with an NVME log, no L2 right now
14:19
<
clever >
Infinisil: but my desktop with an SSD mirror ontop of an NVME L2 can be even slower
14:18
<
clever >
Infinisil: raidz1 across 3 magnetic drives
14:17
<
clever >
its been running for 2 minutes now
14:16
<
clever >
[root@nas:~]# ls -lh /nix/store/ | wc -l
14:16
<
clever >
Infinisil: i think i have 4x the number of subdirs, and the size is also ~4x
14:15
<
clever >
Infinisil: for size reference: drwxrwxr-t 46029 root nixbld 232K Jul 23 11:14 /nix/store/
14:11
<
clever >
Infinisil: reading the directory listing for /nix/store/ and /nix/store/.links/
14:11
<
clever >
dash: and i think i just found a concurrency issue in the GC process
14:10
<
clever >
Jul 23 11:10:30 nas nix-gc-start[6246]: error: getting status of ‘/nix/store/.tmp-link-2816-1576729590’: No such file or directory
14:10
<
clever >
Jul 23 11:10:30 nas nix-gc-start[6246]: deleting ‘/nix/store/.tmp-link-2816-1576729590’
14:10
<
clever >
sometimes, zfs is just really slow, for no obvious reason
14:09
<
clever >
getdents(15, /* 416 entries */, 32768) = 32752 <3.048378>
14:06
<
clever >
deltasquared: and vde_switch has some modes, where it can inject latency, bandwidth limits, and even packet corruption into the links
14:05
<
clever >
deltasquared: nixos tests use vde_switch to link all of the qemu instances together
13:20
<
clever >
joepie91: yes, php sucks :P
13:20
<
clever >
deltasquared: the php csv read function has no way to turn that escape feature off, making it imposible to read the file as-is
13:18
<
clever >
deltasquared: it escaped the end of field quote, causing my csv parser to eat half of the next field and go entirely out of sync
13:17
<
clever >
i recently discovered that a "CSV" export from MS access, includes fields like "1234\"
13:09
<
clever >
hodapp: is this in the right region?
13:08
<
clever >
also, the error looks unrelated
13:08
<
clever >
/tmp/nix-build-opencv-3.3.0-rc.drv-0/opencv-3.3.0-rc-src/modules/stitching/include/opencv2/stitching/detail/matchers.hpp:52:42: fatal error: opencv2/xfeatures2d/cuda.hpp: No such file or directory
13:08
<
clever >
then see what happens
13:08
<
clever >
hodapp: id patch this to just not call download_boost_descriptors
13:08
<
clever >
/tmp/nix-build-opencv-3.3.0-rc.drv-0/opencv_contrib/xfeatures2d/CMakeLists.txt:8 (download_boost_descriptors)
13:07
<
clever >
deltasquared: yeah
13:07
<
clever >
hodapp: and download_boostdesc.cmake appears to have the expected hash of each file it wants
13:06
<
clever >
set(hash_BGM "0ea90e7a8f3f7876d450e4149c97c74f")
13:03
<
clever >
Infinisil: some things like haskell and some event libraries will randomly switch threads for performance reasons
13:02
<
clever >
Infinisil: which means you must always call the functions in the same thread on the OS side
13:02
<
clever >
Infinisil: things can also be thread-local to the main cpu
12:59
<
clever >
every branch appears to contain different files
12:59
<
clever >
what files does this repo provide?
12:57
<
clever >
/tmp/nix-build-opencv-3.3.0-rc.drv-0/opencv_contrib/xfeatures2d/cmake/download_boostdesc.cmake:22 (ocv_download)
12:57
<
clever >
and cmake also gives a stack trace, nice
12:57
<
clever >
hodapp: the error is deep inside a generic ocv_download function
12:56
<
clever >
CMake Warning at /tmp/nix-build-opencv-3.3.0-rc.drv-0/opencv-3.3.0-rc-src/cmake/OpenCVDownload.cmake:188 (message):
12:53
<
clever >
and then it copies them into the right spot so cmake wont try to dl
12:53
<
clever >
yeah, an extra fetchFromGitHub is ran to pre-download the files
12:52
<
clever >
fetchFromGitHub is a different derivation, so it can have the network on, and nix will enforce it always giving the same result (via the sha256)
12:51
<
clever >
during the entire derivation, the network is off
12:51
<
clever >
nix will spawn a new container for every build, with no network access, and limited access to the /nix/store/
12:50
<
clever >
nix disables all network access during the build
12:50
<
clever >
it shouldnt be capable of doing any network now
12:49
<
clever >
configure has begun
12:48
<
clever >
hodapp: fetching deps
12:47
<
clever >
hodapp: build started...
12:33
<
clever >
so you can just pad it with ctrl+o's until you get the right answer
12:33
<
clever >
i got bored once and read the source of an !8ball script on irc, and it was a basic crc over the entire question, including non-printable characters
12:32
<
clever >
deltasquared: the color is probably just based on a hash of the nick
12:29
<
clever >
deltasquared: only thing that comes to mind for purple is willy wonka, lol
12:28
<
clever >
i cant see the colors on this end
12:28
<
clever >
deltasquared: who? heh
12:26
<
clever >
qknight: via config like normal
12:26
<
clever >
but if clang doesnt exist, it will be renamed, and take the place of clang
12:26
<
clever >
if clang already exists, the clangdir will be put INSIDE the existing clang, with its original name
12:26
<
clever >
cp -r ${clangdir} $sourceRoot/third_party/llvm/llvm/tools/clang
12:25
<
clever >
mpickering: i always cp -vi out of habbit, because i never get around to creating the alias
12:17
<
clever >
if you cd into the llvm dir it checks out, what does "git rev-parse HEAD" say?
12:15
<
clever >
and they havent noticed the mistake
12:15
<
clever >
my only guess is that the build script is out of date with the upstream cmake file
12:14
<
clever >
yeah, it looks right
12:12
<
clever >
ah, i see line 30 of the nix file now
12:10
<
clever >
the cmake files arent present on github?
12:07
<
clever >
mpickering: so thats going to try to patch the source it hasnt unpacked
12:07
<
clever >
mpickering: without an unpackPhase, postUnpack and src are broken
12:04
<
clever >
oh god, lol
12:04
<
clever >
and the more words you have, the worse it gets
12:04
<
clever >
so even with zero use of interpolation, it still does 2 concat operations
12:04
<
clever >
but its not doing any pre-processing at parse time
12:03
<
clever >
joepie91: what about the speed difference between "foo bar baz" and 'foo bar baz' ? lol
12:02
<
clever >
we need an Either type!
12:01
<
clever >
joepie91: yeah
12:01
<
clever >
zarel: i'm guessing you just manualy run cryptsetup open
12:00
<
clever >
joepie91: returns null upon error?!
11:59
<
clever >
returns false?
11:59
<
clever >
decode_json with a catch block i'm guessing
11:59
<
clever >
but id have to give it a test
11:57
<
clever >
joepie91: " <?php" or "?>\n" in a library!
11:56
<
clever >
deltasquared: so its imposible to automate any ingame action
11:56
<
clever >
deltasquared: but if any mod based code is in the stack, that permission is lost
11:56
<
clever >
deltasquared: things initiated by the game have a special priv, that lets them call special functions (that trigger ingame actions)
11:55
<
clever >
deltasquared: world of warcraft also uses a slightly modified lua engine for all of its mods
11:55
<
clever >
deltasquared: lua can often do that
01:18
<
clever >
and patchelf is expecting everything to be named
01:17
<
clever >
i'm guessing it has an un-named section, that is referenced only by its section index
01:16
<
clever >
which would imply that findSection was called with an empty string
01:16
<
clever >
that makes more sense
01:16
<
clever >
ah, version 0.3 has error("cannot find section " + sectionName);
01:15
<
clever >
there should be single quotes in the error, acording to the source
01:15
<
clever >
error("cannot find section '" + sectionName + "'");
01:14
<
clever >
ben: what if you add --debug to patchelf?
01:14
<
clever >
ben: the source isnt capable of producing only that output
01:13
<
clever >
ben: does the error say which section it cant find?
01:12
<
clever >
ben: what does the file command say about the binary?
00:48
<
clever >
and it will add a bash script around it to modify env variables for you
00:48
<
clever >
you can also add the wrapProgram i gave previously to this
00:46
<
clever >
does it build?
00:46
<
clever >
then run nix-build on that file
00:46
<
clever >
patchShebangs $out/bin/
00:46
<
clever >
cp -vi ${./input.python} $out/bin/output
00:45
<
clever >
mkdir -pv $out/bin/
00:45
<
clever >
with import <nixpkgs> {}; runCommand "script" { buildInputs = [ python ]; } ''
00:45
<
clever >
try putting this into a default.nix
00:43
<
clever >
if you gist your current script, i can modify it
00:43
<
clever >
nix should automaticaly patch it to /nix/store/<hash>-python/bin/python
00:43
<
clever >
and then put python into the buildInputs
00:43
<
clever >
for example, make a $out/bin/foo that starts with #!/usr/bin/env python
00:42
<
clever >
then write a nix expression that will generate a suitable script
00:40
<
clever >
which prevents that problem entirely
00:40
<
clever >
nix-shell ensures it will only be available in that shell, so nothing else can use it
00:32
<
clever >
so its going to be more likely to ignore the incompatible libz.so
00:32
<
clever >
that version wont look in /lib by default
00:30
<
clever >
nix-env will persist, nix-shell wont
00:30
<
clever >
either nix-env or nix-shell
00:29
<
clever >
'nix-env -iA nixpkgs.python' would place it at ~/.nix-profile/bin/python
00:27
<
clever >
that will spawn a shell that has the nix version of python in $PATH
00:27
<
clever >
nix-shell -p python
00:27
<
clever >
which defaults to looking in /lib
00:27
<
clever >
ah, that one is using the ld.so from your host
00:25
<
clever >
"which python", is it using the nix build of python?
00:23
<
clever >
but LD_LIBRARY_PATH has a higher priority, so it can break things
00:23
<
clever >
and normally have the search path pre-set
00:23
<
clever >
libraries in /nix/store should only ever be loading other libraries in /nix/store/