IRC channel 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>(if it exists, else 'inputs' will be #f)

<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>s/being/triggering/

<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.

<jmd>How do I do that?

<mark_weaver>look on line 49 of gnu/packages/m4.scm. see the (let ((bash (assoc-ref inputs "bash"))) ...) ?

<jmd>I see that, yes

<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

<mark_weaver>so presumably you want something like that

<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.

<mark_weaver>okay, good luck!

<jmd>I bet I'm going to run into all sorts of issues, killing the damn server afterwards ...

<mark_weaver>yeah, I was wondering about that.

<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.

<mark_weaver>that wouldn't be too hard either.

<jmd>Right.

<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>and of course, it's in a chroot.

<jmd>Might be ok then.

<mark_weaver>I suspect it will just always be :0

<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?

<jmd>It depends ...

<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>well, there are a few ways to do it

<mark_weaver>one way is to just call 'primitive-fork' yourself.

<mark_weaver>have you written code that uses 'fork' before, in any language?

<jmd>Well C, yes.

<mark_weaver>it's basically the same here

<jmd>a second way ?

<jmd>I guess I could call a shell to do it. But then I need bash as another input.

<mark_weaver>bash is an implicit 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.

<mark_weaver>use 'system', not 'system*'

<jmd>it looks for a command called "foo &"

<jmd>oh.

<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>(guile)Top > Guile Modules > POSIX > Processes

<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.

<mark_weaver>maybe you just need to create that directory

<mark_weaver>(mkdir "/tmp/.X11-unix")

<jmd>Right. And I need to chown it to root. Is that possible?

<mark_weaver>no

<jmd>bummer

<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.

<mark_weaver>reading the source code might be better :)

<jmd>Anyway, the message _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root

<jmd>seems pretty clear.

<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>but what if that first X server is not run as root?

<mark_weaver>maybe it wants the mode to be 1777

<mark_weaver>if so, add #o1777 as a second argument to the 'mkdir'.

<mark_weaver>maybe worth a try

<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?

<civodul>Hello Guix!

<jmd>hello Ludo

<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

<jmd>

<civodul>jmd: could you post the contents of ~/.guix-profile/manifest and the command you're running?

<jmd> http://pastebin.ca/2485414

<jmd>The command I'm running is

<jmd>guix package --install=hello

<jmd>and here's the full error:

<jmd> http://pastebin.ca/2485418

<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

<civodul>so which one is used here?

<jmd>I did have 0.4, but I removed it.

<civodul>can you post the manifest after 0.4 was removed?

<jmd>I just did.

<civodul>hmm http://pastebin.ca/2485414 does have Guix 0.4

<civodul>what did i miss?

<jmd>Well perhaps at some stage I did "guix package --install=guix"

<jmd>That would have installed guix in my profile.

<civodul>yes

<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

<civodul>ok

<civodul>hmm

<jmd>I get the same error when I try "guix package --remove=guix"

<civodul>and guix --version really says 0.5?

<civodul>i'm trying to reproduce it here, but it's difficult

<jmd>john@jocasta:~$ guix --version

<jmd>guix (GNU Guix) 0.5

<jmd>License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

<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>ok

<jmd>

<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>similar result.

<jmd>Both those variables are unset.

<jmd>BTW, make check fails 11 tests for me.

<jmd>is that expected?

<civodul>what do you think? :-)

<civodul>of course it's unexpected

<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.

<civodul>heh

<jmd>I'll try a git bisect to see if I can find an offending commit.

<civodul>what does test-suite.log show?

<jmd> http://pastebin.ca/2485422

<civodul>why doesn't /Scratch/john/guix-dev/test-tmp/store exist?

<jmd>It does.

<civodul>well it seems it didn't then

<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>s/have/hate/

<jmd>It's the worst thing anyone ever invented.

<jmd>...rebuilding...

<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

<civodul>there's something very broken here

<civodul>can you try 'make clean && make'

<civodul>then try again the above command?

<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>

<jmd> http://pastebin.ca/2485428

<jmd>This looks like a problem with guix/scripts/build.scm