IRC channel logs


back to list of logs

***les is now known as Guest73877
<davexunit>hello #guix
<davexunit>woo containers now use a pivot_root
<davexunit>now... can I figure out how to forward stdin and create a psuedo-terminal?
<civodul>Hello Guix!
<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>sorry, I was mistaken
<mark_weaver>you're right, icecat is already built on hydra
<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>not at all
<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 ''"
<mark_weaver>anyway, I have to go...
<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.
<mark_weaver>probably EDITOR has to be just "emacsclient"
<mark_weaver>okay, really going now :)
<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.
<sneek>Got it.
<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.
<rekado_>Hi Guix, could someone please take a look at this patch:
<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_: thanks!
<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 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 with the relevant details: version of guix install image, lsusb output, whatever else you can think of.
<davexunit>I recall another mac user having issues.
<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>and then build the image.
<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>rekado_: done
<civodul>davexunit: oh oh, --container with interactive shell?
<davexunit>civodul: yeah, turns out it "just worked"
<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'
<rekado_>civodul: thank you!
*Steap is going to crowd-fund a "package OpenStack in Guix" project one of these days
<davexunit>that will be cool/painful
<davexunit>sooooo many dependencies
<amz3>Steap: :)
<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>taht shit never works
<amz3>you work on OpenStack?
<Steap>you always end up not knowing what it installs on your computer
<Steap>it is a terrible pain
<Steap>amz3: yes
<amz3>an area in particular?
<amz3>welll this is fully OT
<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 ?
<Steap>pipdeptree you mean ?
<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
<amz3>I mean, do it later
<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
<ngz>No problem, at all!
<amz3>ah I get it
<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
<amz3>try to guix pull then
<ngz>I guix pull'ed yesterday.
<amz3>I'm tryin
<paron_remote>hi *
<amz3>hey paron_remote :)
<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
<amz3>evince is ok too
<ngz>OK. So I'm guix pull'ing again.
<ngz>Thank you for the help.
<Steap>"waiting for locks or build slots..."
<Steap>love getting this