***les is now known as Guest73877
<davexunit>now... can I figure out how to forward stdin and create a psuedo-terminal? <ngz>Hello. I did a guix pull recently. I'm not sure it is related, but now, when I call "guix edit ..." I get an error telling me that "execlp" is nowhere to be found. Any idea about what is going wrong? <ngz>Another (different) issue: I'm running "guix package -u" but the update process runs out of disk space when trying to compile icecat. I allow substitutes and, according to hydra, icecat on x86_64 is not failing. So, why don't I get the substitute instead of having to compile it? <mark_weaver>hydra is currently building icecat for x86_64. it hasn't caught up yet. <mark_weaver>whenever a change to the guix source repository that would require things to be recompiled, there is always a window when you must compile things yourself. <ngz>OK. Thank you. I missed the information about icecat not being built already. OOC, where is this information available in hydra's UI? <mark_weaver>have you downloaded any substitutes? did you authorize hydra's key? <ngz>Yes, substitutes are usually fine. <mark_weaver>well, unfortunately I have to leave very soon and won't have time to debug your problems right now. <mark_weaver>but you should paste the exact error message you get regarding "execlp" <mark_weaver>and it would be good to also show the output of "guix build icecat" <mark_weaver>did you make any modifications to your package recipes? <ngz>error message for execlp is really "no such file or directory" <ngz>guix build icecat reports a note about probable low disk space. <mark_weaver>ngz: you might need to get your EDITOR environment variable <mark_weaver>"execlp" is a system call. it's not that "execlp" cannot be found, but the program that guix is trying to run using "execlp" that cannot be found. <ngz>I have it to "emacsclient -c -a ''" <ngz>OK. Thank you anyway <mark_weaver>ngz: I think it's probably looking for a program called "emacsclient -c -a ''", with the spaces and dashes and single-quotes in the filename. <ngz>Well, it worked with this value before guix pull. <rekado_>sneek: later tell davexunit Sent you another patch for guix-web; adding support for a "search" GET request parametre. <amz3>ngz: seems like EDITOR only accept scripts <amz3>I mean since command with no options <amz3>ngz: I created a script with `emacsclient -c -a ""` and now guix edit works, you are right it's kind of no very friendly <ngz>It is surprising. A few days ago, I could use guix edit without an external script. <ngz>With that same EDITOR value. <davexunit>guix environment --container --ad-hoc bash coreutils -E bash <sneek>Welcome back davexunit, you have 1 message. <sneek>davexunit, rekado_ says: Sent you another patch for guix-web; adding support for a "search" GET request parametre. <davexunit>rekado_: I won't have time to properly test this for a little while <davexunit>I suspect there are some problems with it, but it's a very good start. <jogo_>Hey, it is some time ago that I used GNU/Linux distro being forced by my workplace to use OSX. But I want to use another os again and try to install GuixSD on my macbook but have a problem setting up grub. <jogo_>I tried installing it pointing to /dev/sda but that will complain about efi. <jogo_>The guix partition as target will result in a message about embedding not supported. <jogo_>Can maybe anybody point me in the right direction? <davexunit>jogo_: I'm not sure what our story is right now related to EFI. <davexunit>if no one answers you here, you should send an email to guix-devel@gnu.org about it. <davexunit>that's our mailing list, and people that aren't logged into IRC right now will see it. <jogo_>Another problem is that the internal keyboard is not working. lsusb will show it though. <jogo_>Thanks for the pointer to the list, I will write a mail to it. <davexunit>perhaps we're not loading the correct kernel module for your keyboard <davexunit>for that you could write to bug-guix@gnu.org with the relevant details: version of guix install image, lsusb output, whatever else you can think of. <jogo_>Is there any way to continue an installation/init? At the moment I had to erase the partition/reboot before being able to start init again, otherwise it would complain about existing symlinks. <davexunit>jogo_: that's a bug that has been fixed in our master branch. <davexunit>so the released installation image still has the problem. <jogo_>Is it possible to create an image from master without a running system? <davexunit>jogo_: you can run guix standalone on a GNU/Linux host. <davexunit>that is, the package manager, not the GuixSD distro. <davexunit>I realize that is more than your bargained for. <davexunit>I wonder if we can put a system in place for automatically building pre-release install images for folks that want to try out the bleeding bleeding edge. <jogo_>Hmm, time to install another GNU/Linux host first. <davexunit>jogo_: alternatively you can do all of this from a vm or something. <civodul>davexunit: oh oh, --container with interactive shell? <davexunit>my problem now is how 'guix environment' spawns subprocesses <davexunit>it uses 'system', but I want it to use 'system*' outside of a container, and 'execlp' inside a container. <davexunit>currently, the command to evaluate must be quoted at the shell: guix environment -E "ls /home" <davexunit>I think this would be better: guix environment -E ls /home <davexunit>if I have an array of args, I can use 'system*' and 'execlp' *Steap is going to crowd-fund a "package OpenStack in Guix" project one of these days <Steap>davexunit: we have a huge bash script called "devstack" <Steap>that is supposed to install everythig you need to quicly start hacking on it <Steap>you always end up not knowing what it installs on your computer <amz3>I tried to package flake8 but it fails <Steap>amz3: no, I basically fix bugs the client is interested in :) <amz3>what do you think of piptreedeps ? <amz3>yes. it's helpful to have in the toolbox <amz3>(I can't reproduce right my bug with flake8 but I will come back to it later or send a patch if I succeed) <civodul>davexunit: i think it's ok to quote the arguments <civodul>plus system* would have different semantics; you wouldn't be able to do -E "cd foo; bar", for instance <ngz>Something weird is going on. When I try to update packages some of them are downloaded (e.g., solfege) but others are compiled (e.g., icecat). I guess my authorizations are fine since I get derivations from the former category. However, I do not understand why many packages fall into the second one. <amz3>read the output, I think it's written that hydra (the build server) is failing <ngz>Actually there are not "many" packages in the latter category. But icecat definitely is, and I cannot compile it due to lack of disk space anyway. <amz3>wait another time to do the update <ngz>If I use "guix package -u icecat -n", I get that it will compiled right from the start. OTOH, if I use "guix package -u vlc -n" it tells me it will be downloaded. <ngz>So I don't think it is related to the build server. <amz3>try too times the same thing? <ngz>I do not understand. What do you mean? <amz3>try to time the same command. <amz3>I am doing the same on my side for icecat <ngz>For icecat: real: 12.105 s <ngz>For vlc: real: 13.222 s <amz3>my writting is very poor, I'm not focused <amz3>maybe the new version of icecat is not built on hydra <amz3>since that the dryrun output, it can be that <ngz>I checked hydra already. It seems to be built (for x86_64, which I'm interested in). <amz3>sometime, what happens, is that the guix command try to download the files, but fails and then fallback to building. That's not what's happening here. <amz3>ngz: then I don't know sorry. <amz3>I have the same output as yours <ngz>I guix pull'ed yesterday. <amz3>ngz: after guix pull, it's icecat is marked for download <amz3>ngz: tell me another package that you need to build, so that I test <ngz>amz3: there is also evince <ngz>OK. So I'm guix pull'ing again. <ngz>Thank you for the help. <Steap>"waiting for locks or build slots..."