IRC channel logs
2013-11-30.log
back to list of logs
<civodul>mark_weaver: thanks for emailing Mark for Guile-WM <civodul>i have a preliminary guile-xcb package around, just in case ;-) <civodul>i have guile-ssh too, but there's an RPATH issue <gzg>Trying to build docbook-xml, but guix doesn't seem to want to open up it as a *.zip. <jmd>I need to add a phase before 'check which starts an x server. How do I do it? <mark_weaver>well, first you need to know how to insert a new phase. for an example, see the use of 'alist-cons-before' on line 45 of gnu/packages/m4.scm <jmd>Yeah I'm digesting a similar example now. <jmd>What does this expression mean: <jmd>(#:key inputs #:allow-other-keys) <mark_weaver>that's not an expression, it's a formals list in the lambda* <mark_weaver>and it means that only keyword arguments are accepted <mark_weaver>the keyword #:inputs will be recognized, and the following argument will be bound to 'inputs' <mark_weaver>and #:allow-other-keys means that other keywords will be silently ignored, instead of being an error as would happen by default. <mark_weaver>that lambda* expression defines an anonymous procedure which tells what to do when the phase is run by the build process. <mark_weaver>in fact, the procedure is given a large number of keyword arguments. in this case, only #:inputs was needed. <jmd>Anyway it seems I need to call something like (system* "Xvfb :1") but presumable I need to get the path of Xvfb from the xorg-server package. <mark_weaver>look on line 49 of gnu/packages/m4.scm. see the (let ((bash (assoc-ref inputs "bash"))) ...) ? <mark_weaver>that binds 'bash' to a string of the form "/nix/store/XXXXXXXXXXXXXXXXX-bash <mark_weaver>so that's the directory in /nix/store of that input. <mark_weaver>so then see on line 55, where (format #f "~a/bin/bash" bash) returns the absolute pathname of the bash executable <jmd>I'll give it a go. Thanks. <mark_weaver>so the string "bash" in the call to 'assoc-ref' corresponds to the string of the corresponding input. <jmd>I bet I'm going to run into all sorts of issues, killing the damn server afterwards ... <mark_weaver>guix-daemon might take care of killing all the processes in the container. <mark_weaver>if it does, then there's no problem. let me know if that's not the case. <mark_weaver>the other option would be to _wrap_ the make check phase with code that starts and then kills the x server; instead of a separate phase before. <jmd>The other issue is finding a unique DISPLAY id <mark_weaver>well, the build process is fairly well isolated using the namespaces feature of recent linux. <mark_weaver>I know that the PIDs are private, and that the network is private. <mark_weaver>regardless of what displays are present in the outside world. <jmd>But what if someone else, in another package tries the same trick as me? and both packages get installed in parallel? <mark_weaver>each build process is in it's own distinct chroot/namespace, and actually they have distinct userids also. <jmd>Ok, then :0 might be ok. <mark_weaver>doesn't :0 correspond to a unix domain socket anyway? i.e. a special file in the filesystem? <mark_weaver>well, it doesn't even matter whether it's that or a network socket. either way, each build process has the relevant namespace private. <mark_weaver>it has a private network environment, and a private filesystem. <mark_weaver>so, while I'm not 100% sure, I strongly suspect you can just count on :0 being available. <jmd>how can I tell system* put the process in the background? <mark_weaver>have you written code that uses 'fork' before, in any language? <jmd>I guess I could call a shell to do it. But then I need bash as another input. <mark_weaver>so you could just use 'system' and include '&' in the string, I think. <mark_weaver>well, maybe you'd have to use nohup too, I'm not sure. <jmd>(system* "foo &") wont work. <jmd>it looks for a command called "foo &" <jmd>where are these documented? <mark_weaver>btw, normally I try to convince people never to use 'system', but always 'system*'. <mark_weaver>but in this case, the command is a fixed constant, so there are no security issues or robustness issues because of shell quoting, etc. <mark_weaver>yes, 'system' and 'system*' are documented. if you read the guile manual in emacs, "i system RET" would bring you right to the relevant manual entry. <mark_weaver>yet another option is to use the (ice-9 popen) module, which is meant for launching background subprocesses. <mark_weaver>if you did that, you'd probably want to use 'open-output-pipe', such that stdout and stderr would be left unchanged and your only pipe would be to the input. <mark_weaver>the only thing you have to be careful of is to keep a reference to the pipe "alive" (from the GC) for as long as the subprocess needs to live. <mark_weaver>because the (ice-9 popen) automatically takes care of killing subprocesses that are GC'd. <jmd>This is odd. It looks as if Xvfb wants to be root. <jmd>_XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. <jmd>Right. And I need to chown it to root. Is that possible? <mark_weaver>i guess there's probably some a way to launch xvfb without root <jmd>Normally there is. But is relies upon /tmp/.X11-unix existing. <jmd>I mean, in my own environment I can start it as a mortal. <mark_weaver>does it really insist on /tmp/.X11-unix being owned by root, or are the requirements more lax? do you know? <jmd>I'm reading the X docs now. <jmd>Anyway, the message _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root <jmd>Shouldn't the xorg-server package have already done that? <mark_weaver>the package builds never create anything outside of their /nix/store/* <mark_weaver>when you "install" a package in your profile, it's just creating a new tree of symlinks to be pointed at by ~/.guix-profile <mark_weaver>anyway, /tmp traditionally gets cleared on boot anyway <mark_weaver>/tmp/.X11-unix doesn't get created by any usual boot process, as far as I know. I assume it gets created by the first X server that discovers it missing. <mark_weaver>if so, add #o1777 as a second argument to the 'mkdir'. <jmd>OK. I'll investigate a bit and see what I can find. <jmd>I think I need to have a (lambda* (#:key inputs #:allow-other-keys) which allows inputs as well as outputs. how do I do that? <jmd>More specifically, I need the path of the build directory. because I neeed to set an environment variable to it. <jmd>What are "native-inputs" ? <jmd>Is nix maintained? How do we patch the nix daemon if we need to? <jmd>I get a guile error whenever I try to install anything. <jmd>srfi/srfi-1.scm:576:29: Throw to key `match-error' with args `("match" "no matching pattern")'. <jmd>builder for `/nix/store/xvxvg4dwi5prvianmg1p4fqd57ss6qf4-profile.drv' failed with exit code 1 <jmd>guix package: error: build failed: build of `/nix/store/xvxvg4dwi5prvianmg1p4fqd57ss6qf4-profile.drv' failed <civodul>jmd: could you post the contents of ~/.guix-profile/manifest and the command you're running? <jmd>The command I'm running is <jmd>guix package --install=hello <jmd>and here's the full error: <civodul>there's an older Guix in your profile <civodul>though i don't think this is suppoosed to be problematic <civodul>jmd: does it work to explicitly use the other Guix that's on your system? <civodul>(i assume you've installed Guix from 'master' somewhere) <jmd>This is the master from Git. <jmd>(plus the two patches which I posted a few minutes ago) <civodul>yes, but there's also Guix 0.4 in your profile <jmd>I did have 0.4, but I removed it. <civodul>can you post the manifest after 0.4 was removed? <jmd>Well perhaps at some stage I did "guix package --install=guix" <jmd>That would have installed guix in my profile. <civodul>and that could be a problem if the installed Guix (which is older) cannot handle the new profile <jmd>But the guix I am using is 0.5 <jmd>I get the same error when I try "guix package --remove=guix" <civodul>i'm trying to reproduce it here, but it's difficult <jmd>john@jocasta:~$ guix --version <jmd>Copyright (C) 2013 the Guix authors <jmd>This is free software: you are free to change and redistribute it. <jmd>There is NO WARRANTY, to the extent permitted by law. <civodul>jmd: in union.scm:206, could you change "directories" to "(pk 'DIR directories)"? <civodul>and then run ./pre-inst-env guix package -i hello <civodul>also, can you show the value of $GUILE_LOAD_PATH and $GUILE_LOAD_COMPILED_PATH ? <jmd>Both those variables are unset. <jmd>BTW, make check fails 11 tests for me. <civodul>can you check test-suite.log to see what's going on? <jmd>*shrug* Some projects have general policy that unreleased versions might not even compile. <jmd>I'll try a git bisect to see if I can find an offending commit. <civodul>why doesn't /Scratch/john/guix-dev/test-tmp/store exist? <civodul>could you rerun "make check" and see? <jmd>Something's totally messed up now. I can't even bootstrap <jmd>Uggh. I have pkg-config. <jmd>It's the worst thing anyone ever invented. <jmd>Same 11 failures, and test-tmp/store does exist. <civodul>jmd: can you run: ./test-env guix build guile-bootstrap <jmd>$ ./test-env guix build guile-bootstrap <jmd>accepted connection from pid 1095, uid 1000 <jmd>guix build: error: build failed: opening file `/Scratch/john/guix-dev/test-tmp/store/kdqspxjnqi9ria4n7x6b84h5gbwx8hq9-guile-bootstrap-2.0.drv': No such file or directory <jmd>The directory exists, but that file within it does not. <jmd>I'll do one better. I'll remove the build dir and start again. <jmd>Hmm. Should a running guix daemon cause problems when building? <jmd>Now I get an error while building. <jmd>ice-9/boot-9.scm:106:20: In procedure #<procedure 9402440 at ice-9/boot-9.scm:97:6 (thrown-k . args)>: <jmd>ice-9/boot-9.scm:106:20: missing interface for module (gnutls) <jmd>This looks like a problem with guix/scripts/build.scm <civodul>jmd: did you remove the incompatible guile-gnutls package that you had before? <jmd>I completely removed the build directory. That should have done it? <civodul>i mean: sudo apt-get remove guile-gnutls <civodul>remember, Debian's guile-gnutls package was linked against Guile 1.8, making it unusable here <jmd>Package 'guile-gnutls' is not installed, so not removed <jmd>0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. <jmd>Anyway, I have now successfully run make. <jmd>But something is wrong. <jmd>./configure ; make does not work. <jmd>I had to do ./configure ; make -k ; make <jmd> ./test-env guix build guile-bootstrap runs fine now. <jmd>But make check seems to be taking a very long time. <jmd>Oh. 3rd test just passed. <jmd>OK. Thanks for your help. <jmd>How can I completely uninstall guix and reinstall it? <mark_weaver>well, that doesn't blow away the database or /nix/store <jmd>So how do I do that? <mark_weaver>what problem are you having that makes you think you have to? <jmd>Inconsistent problems. <mark_weaver>I guess you could just rm -rf /nix and $PREFIX/var/nix <mark_weaver>and you probably want to blow away ~/.config/guix/latest as well <mark_weaver>(that's the directory that "guix pull" populates with new stuff)