IRC channel logs

2013-10-18.log

back to list of logs

<bavier>I checked out a fresh copy of guix from git, and after configure, make fails during creation of doc/images/bootstrap-graph.png. I think the reason is that doc/images isn't being created beforehand
<mark_weaver>bavier: I think it's probably because the modification time of the source code for that file turned out to be newer than the .png file.
<mark_weaver>bavier: try "touch doc/images/bootstrap-graph.png"
<mark_weaver>(you'd need graphviz to generate that file from the source, but better to just keep the one that's already there)
<bavier>well, there isn't already a doc/images/bootstrap-graph.png
<mark_weaver>indeed, that's true. hmm. I wonder how I managed to get my copy? well, you can copy it from the guix-0.4 tarball
<bavier>I'm doing a vpath build, and it doesn't look like there are any rules to check that the doc/images path exists
<mark_weaver>can you email bug-guix@gnu.org about it?
<bavier>sure
<mark_weaver>thanks!
<Infiltrator>I'm obviously missing something obvious here, but I launched the 0.4 qemu image, and when I try to do 'guix package -l', I get: 'guix package: error: profile ... does not exist'.
<Infiltrator>Right... because it's '-I', not '-l'.
<Infiltrator>When I try to -i hello, though, I get: 'guix package: error: Protocol not supported'.
<mark_weaver>you have to start networking. I believe the command is "deco start networking" or something like that.
<Infiltrator>mark_weaver: Thanks, mate. I knew that it would be something simple.
<mark_weaver>glad to help. keep in mind that the qemu image is very preliminary work.
<Infiltrator>Yeah; I looked at /var/log/messages. :P
<Infiltrator>Woohoo! I got hello installed!
<gzg> Infiltrator: On the 0.4 image, you won't get more than GNU hello on there actually, keep in mind -- I wasn't even able to get parted and related file-system utils going, to expand the partitions in said image. :^P
<zacts>so will guix-1.0 be a comlete gnu/linux distro?
<gzg>zacts: Ideally, I'd assume that's the route/convention civodoul will probably try to hit, but I'm not sure. 0.5 will likely bare a fairly complete live-image though -- so it'd be on track, I think.
<mark_weaver>zacts: that's definitely where we're headed, although I don't know what the version number will be.
<gzg>Right now, just about everything besides kbd, some network utilities, conkeror, and maybe a desktop manager like slim -- my daily software stack is covered (well not stumpwm, but I plan to port and play around with guile-wm, eventually, and ratpoison can tide me over until then... :^J) So as soon as we have an installable image, I'm likely flocking to it.
<gzg>zacts: Of which, I'm personally trying to knock out the first two out -- but I think we need to compile a list of "must have" basics to ship in the "minimal image", which really isn't to far off from what we have in the demo, it's just the lack of space is so tight right now, that's there's little to no wiggle room working off of it.
<gzg>The EDSL is obviously the next big barrier, to get something orbiting the notion set-forth by NixOS, and it's something that will more-or-less be "needed", I think -- before we formally hit 1.0 status as a community.
<Infiltrator>By the way, to what extent is guix based on nix? Is there any shared code; or is it all concepts?
<mark_weaver>we use a slightly modified version of the nix-daemon.
*gzg is still very excited about DmD, but is worried about the prospects such as GNOME choosing to more-or-less make systemd like init-systems, a hard dependency.
<Infiltrator>Hahaha. Trying to install parted: 'guix package: error: build failed: writing to file: No space left on device'
<mark_weaver>there are a lot of ways we can cope with that. we could patch the relevant gnome modules, or we could add systemd-style interfaces to dmd, or some mix of these two approaches.
<gzg>mark_weaver: I know very, very little about about the software stack on this level; Though this is certainly an area of interest for me -- but for the time being, I'll take your word for it. It'd be quite ironic/sad if we couldn't pull such a thing off though. :^P
<gzg>Infiltrator: Yup and I don't think it ships with any other file-systems manipulation tools, either; So yeah, atm it's relatively useless -- but I'm tremendously hopeful that in ~4 months time, we'll have a solid live image; Even if said image isn't installable, it'd be nice to have a solid tech demo out and one we could point to. :^)
<Infiltrator>gzg: Like mark_weaver said, if it comes to it, with gnome being free software, we could just patch it.
<gzg>Infiltrator: Yeah, I think it's do-able, probably just going to be a big pain though and resources thusfar, are relatively slim (but hopefully, once said live-image is available -- it'll catch on like wildfire. :^) )
<Infiltrator>By the way, what's the correct way to shut down the qemu image?
<Infiltrator>Also, why does it seem to allow only two logins and then no more?
<mark_weaver>there's not yet any way to shut down properly.
<mark_weaver>I don't know about the two logins.
<gzg>Infiltrator: Define "allow".
<gzg>Maybe it doesn't come with/couldn't fit "useradd" and/or other related utilities?
<mark_weaver>Infiltrator: do you mean that there are only login prompts on the first two virtual terminals, or that after two logins on the same terminal, you can't log in again?
<Infiltrator>mark_weaver: The latter. Apologies for being so vague.
<Infiltrator>gzg: It in fact does not seem to come with useradd.
<gzg>gzg: I suspected as much, or lack there-of. :^P
<gzg>How did I even do that... Infiltrator*
<gzg>:^I
<Infiltrator>Infiltrator: I do that sometimes; people call me mad; what do you think?
<Infiltrator>Infiltrator: Nah; they're the crazy ones.
<gzg>Infiltrator: Internal-to-external dialogues are always fun! :^)
<Infiltrator>They are indeed.
<mark_weaver> https://lists.gnu.org/archive/html/guix-devel/2013-10/msg00174.html
<gzg>mark_weaver: Very cool -- too bad I don't have any such device, to play around with such a thing. :^/
<Arne`>For me guix pull fails again…
<Arne`>(I first noticed it yesterday)
<Arne`>it fails when compiling '/nix/store/zhgkbdk6hnizybh0j7l3m6mjl5rfxfzp-guix-latest/gnu/packages.scm' and before that starts with many possibly unbound variables:
<Arne`>guix/build/download.scm:121:17: warning: possibly unbound variable `make-session
<Arne`>two errorlogs (with --bootstrap and without): http://bpaste.net/show/141593/ http://bpaste.net/show/141594/
<Arne`>now I’ll go and reinstall it (./bootstrap; ./configure; make ; sudo make install)
<Arne`>guix pull still fails…
<civodul>howdy!
<mark_weaver>Hello Guix!
<civodul>mark_weaver: great that you went this far on MIPS!
<mark_weaver>Thanks for all the great groundwork you'
<mark_weaver>you've laid to make it possible and pleasurable :)
<civodul>heh
<mark_weaver>Thanks to Nikita also! I found that some of his patches were already in master, and I benefitted greatly by looking at the patches on his branch.
<gzg>Should ncursew be called, when I add ncurses to inputs?
*gzg is noticed gtypist isn't packaged and thought he'd knock that out relatively quick.
<mark_weaver>gzg: I can't make sense of your question. what is "ncursew", and what does it mean to call it?
<gzg>mark_weaver: Ncursesw, to my understanding, allows wide-characters -- and by "call" I mean as just add it to my inputs.
*gzg is trying to reset his sleep schedule, so he's a bit more far-gone than usual, so maybe he's missing something, but it looks pretty straight forward...
<emk->hi
<mark_weaver>ah, so it's a separate library based on ncurses.
<viric>when you build ncurses, you can build namely ncurses or ncursesw, depending on configure flags, iirc
<mark_weaver>hi emk-
<gzg>mark_weaver: Separate, but it seems like it might ship with said package?
<emk->GUIX is pure GNU distribution, right?
<viric>ncurses/ncursesw is just the result of using different configure flags building from the ncurses tarball
<mark_weaver>emk-: it depends what you mean by "pure". if you mean only GNU packages, then no.
<viric>emk-: but it's all kosher in guix
<mark_weaver>but's it's definitely oriented toward using GNU components wherever practical.
<gzg>emk-: It's a api and package-manager, on top of the nix daemon, that'll serve as the basis of "the GNU distribution" eventually, now it's just self contained.
<mark_weaver>and it's 100% free software.
<gzg>more-or-less.
<gzg>viric: Would I need to build another package expression then, or?
<mark_weaver>viric: a quick web search on 'ncursesw' suggests that it's actually a separate library that's mostly compatible. but maybe that information is out of date?
<civodul>gzg: libncursesw is part of the 'ncurses' package
<civodul>so all you need is to add 'ncurses' as an input
<civodul>try: ls $(guix build ncurses)/lib
<viric>right, that.
<viric>it's usual even to have *only* libncursesw, as ncurses build result. :)
<viric>I think having both creates some mess...
<emk->is it actually usable?
<gzg>civodul: Oh yeah, it's listed. Why wasn't it being recognized then, when I did "ncurses" as an input prior then? :^P
*gzg goes off to try again.
<civodul>emk-: i think this is answered at http://gnu.org/s/guix :-)
<emk->yes, indeed it is
<gzg>civodul: Yup, still failing as an input ("ncurses" ,ncurses).
<civodul>gzg: can you paste the exact command and error?
<gzg>civodul: http://paste.lisp.org/+2ZND
<civodul>gzg: ah, this is terrible
<civodul>can you run "guix build gtypist --keep-failed" and check config.log?
<civodul>sometimes programs expect the ncurses headers in a subdir, sometimes not
<gzg>civodul: http://paste.lisp.org/+2ZNE
<gzg>Fyi, I need to pick a friend up from the bus-station in about half an hour -- too after that, I'm likely going to be for the night (... thinking about it, probably not the best time to start on this expression.) :^/
<gzg>*sleep for the night
<mark_weaver>gzg: okay, thanks for working on it. ttyl!
*gzg seems to pick the worst times and gets into the worst mental-states, to get "antsy" and want to work on something. :^U
<gzg>If there's any suggestions, I'll surely leave this buffer running overnight (or at least most of which). :^P
<civodul>gzg: precisely it expects ncursesw/ncursesw.h, whereas our ncurses package provides ncursesw.h
<civodul>so if there's a --with-ncurses-prefix flag or something, that's the way to do it
<civodul>at worst, you'll have to patch things
<gzg>civodul: I'll add a note and ask if I can't figure it out. It'll likely be Monday, before I have any free-time again to work on any guix package again. :^/
<civodul>np!
<gzg> /me got about half of Mediagoblin yesterday, going. Just needs to add some python-related stuff added and hopefully that'll be on the horizon too. :^)
<mark_weaver>on my guix system , I see only cursesw.h (without the 'n')
<gzg>Aw, /me screwed up. :^I
<civodul>mark_weaver: ah right; gtypist tries <ncursesw/ncurses.h> but we provide <ncurses.h>
<civodul>mark_weaver: ah right; gtypist tries <ncursesw/ncurses.h> but we provide <ncurses.h>
<mark_weaver>Guix is a great way to find problems in build systems :)
<gzg>Okay AFK; Peace people. o/
<bavier>i'm looking at packaging serveez
<bavier>most everything is working, except one test
<bavier>is localhost available during builds?
<mark_weaver>the loopback interface is certainly available, but I don't know about name lookups.
<civodul>bavier: name lookups aren't available
<mark_weaver>bavier: an easy solution would be to pass (arguments `(#:tests? #f))
<civodul>so you need to s/localhost/127.0.0.1/
<mark_weaver>a better solution would be to disable that single test, using a patch.
<mark_weaver>better yet, fix the test, as civodul suggested :)
<civodul>yep :-)
<bavier>I think it might be a simple bug
<civodul>something like (substitute* (find-files "tests" ".*") (("localhost") "127.0.0.1"))
<civodul>bavier: i don't think so; name lookups are not supported in the chroot
<bavier>they are using 127.0.0.1
<bavier>miscommunication...
<civodul>ah, oh
<civodul>then yes, it could be an actual bug
<bavier>the tests pass outside of the guix build for me, so there is something I do need track down
<civodul>could you paste the failing test?