IRC channel logs


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>(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>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>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>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>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
<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
<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 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>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>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>Copyright (C) 2013 the Guix authors
<jmd>License GPLv3+: GNU GPL version 3 or later <>
<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>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.
<jmd>I'll try a git bisect to see if I can find an offending commit.
<civodul>what does test-suite.log show?
<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>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
<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>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>done whata?
<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.
<civodul>grr that's frustrating
<jmd>./configure ; make does not work.
<jmd>(from the gít HEAD)
<civodul>that was "make -j"?
<jmd>I had to do ./configure ; make -k ; make
<civodul>that was "make -j"?
<jmd>Then it works.
<jmd> ./test-env guix build guile-bootstrap runs fine now.
<jmd>But make check seems to be taking a very long time.
<civodul>yes, that's expected
<jmd>Oh. 3rd test just passed.
<civodul>i'll be afk for a couple of hours
<jmd>OK. Thanks for your help.
<jmd>How can I completely uninstall guix and reinstall it?
<mark_weaver>make uninstall
<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>along with make uninstall
<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)
<jmd>ok thanks.