IRC channel logs
2013-12-16.log
back to list of logs
*gzg is finding it problematic to resize te FSes in the VM image. :^P <gzg>Parted doesn't find the disk label. <gzg>mark_weaver: Just /dev/sda -- sorry, just saw the new Evil Dead. <mark_weaver>well, from within qemu, the device name is /dev/vda I believe. <gzg>mark_weaver: I'll check it out, thanks. :^) <mark_weaver>the code to build these images is in guix/gnu/system/vm.scm. search there for /dev/vda. <mark_weaver>it might be easier to just build a new image. 'system-qemu-image' accepts an optional keyword argument for the disk image size. It defaults to 900 MiB. <mark_weaver>to build the image with the defaults: ./pre-inst-env guix build -e '(@ (gnu system vm) system-qemu-image)' <mark_weaver>it's a bit awkward, but to make a larger image, it would be something like: ./pre-inst-env guix build -e '(@ (gnu system vm) system-qemu-image (@@ (gnu system vm) %demo-operating-system) (* 1.5 (expt 2 30)))' <mark_weaver>./pre-inst-env guix build -e '(@ (gnu system vm) system-qemu-image (@@ (gnu system vm) %demo-operating-system) #:disk-image-size (* 1.5 (expt 2 30)))' <gzg>mark_weaver: Very cool -- thanks! <jmd>Odd. I built it several times last night. <jmd>I even got it cross compiling! <jmd>(although I had to cheat) <civodul>it must be a non-deterministic failure <civodul>because it's worked well in the past <jmd>Right. Now that I look, I did experience that failure a couple of times. But assumed that it was something I did wrong. <jmd>civodul: This line may be wrong in glib.scm <jmd>(lambda* (#:key inputs outputs #:allow-other-keys <jmd>I changed it locally to <jmd>(lambda* (#:key inputs native-inputs outputs #:allow-other-keys <jmd>... may have been co-incidence ... <civodul>it'd be great if you could gather more info if you can reproduce the failure <civodul>or maybe we should upgrade and see what failures are left? <jmd>I'm doing a build now. I'll let you know what happens. <jmd>As I recall it was one of the dbus tests failing. So perhaps the problem is in dbus and not glib <jmd>Unfortunately I cleaned my /tmp so I don't have a record of what failed. <civodul>well, if/when you rebuild it, do use --keep-failed :-) <jmd`>civodul: I've got a very basic version of my linter working. <civodul>make sure to discuss this early on the list ;-) <jmd`>Yeah, I'll get a something working and post it. It'll need some tweeking from some guile experts. <klrr_>my guess its a program that suggest code improvements <klrr_>like hlint for haskell for example <davexunit>klrr_: yeah I know what linters do, but what does this one do? <mark_weaver>strange. the build directory for glib-2.38.0 was left in /tmp, but looking at the build log, it looks like it completed successfully, and the output is in /nix/store/*-glib-2.38.0 (with the same hash as in the build log) <mark_weaver>this is on the Loongson 3A machine, which I periodically run tests on where I do "guix build -K $pkg" for almost every $pkg listed by "guix package -A ." <civodul>davexunit: i guess we'll know more real soon ;-) <civodul>mark_weaver: could it be that it left a process behind, and thus never completed? <mark_weaver>more to the point: how can I determine whether that happened, after the fact? is the information recorded anywhere? <mark_weaver>"guix build glib" prints the two store directories referenced in the build log, so I guess it considers the build successful. <jmd>civodul: FYI glib has succesfully built here (albeit with a small local change) <mark_weaver>it built successfully here too. I have no idea why the build directory was left, but afaict, in every detectable way that matters, the build succeeded. <civodul>mark_weaver: you could check the exit code of "guix build" and its error output; the "timed out" message would be there, but not in the log <jmd>What is the policy about changes which cause coreutils rebuilds? <civodul>jmd: we open a core-updates branch for rebuild-the-world changes <jmd>Well its unlikely that such a change will never be required. <civodul>last time we merged such a branch was ~3 weeks ago <jmd>For cross-builds I think it will be necessary to have a config.site file and set the CONFIG_SITE envvar for the configure phase. <sbp>civodul: hey, had a few notes on my guix install the other day: <sbp>1. there was a permissions error writing to $GUIX/nix/profiles/per-user/sbp *after* a long installation process. the permissions of this directory should have been checked at the very start of the process <sbp>2. since $GUIX/nix/profiles/per-user belongs to root, root has to manually add and chown a new directory for every user. can't users manage their own profiles themselves? why does ~/.guix-profile *have* to be a symlink? <sbp>3. there was an "guix package: error: build failed: unexpected end-of-file" error when trying to install python. it was transient: when I tried installing again straight away, it worked without that error <sbp>4. package download statuses keep getting printed over and over. a_e noted that this is because my term was too narrow, but I use the standard 80 columns. progress indicators with CR should be robust <sbp>5. after another long installation process, I got "error: build failed: builder does not have write permission to `/nix/store'; try `chgrp 1001 /nix/store; chmod 1775 /nix/store'". this should also have been checked at the *start* of the installation process <civodul>sbp: oh, thanks for the detailed report! <sbp>you're welcome. yep, 0.5 <civodul>AFAICS the error "Please create the `~a' directory, with you as the owner" should occur right at the beginning of 'guix package' <civodul>is that the one you're talking about? <civodul>the error in 5. should occur early too <civodul>by "installation process", did you mean "make install" or something else? <civodul>it'd be better to discuss this on the list actually <sbp>the error in 5. was at the end of `guix package -i python` <sbp>it appears that the error in 1. was actually at the start of a (prior invocation of) `guix package -i python`, so my notes are wrong on that <sbp>or perhaps it hung for a long time before arriving at that conclusion; I'd have to check. there's no term output above the error message, though <civodul>actually no, the error is in 'startBuilder', which is invoked at the start of a build <civodul>could it be that the permissions on /nix/store were changed in the middle somehoww? <sbp>if they were changed in the middle, it would have to have been from the build process. nothing else was running. single-user, controlled test of guix <sbp>it had downloaded quite a few packages as part of the process. the most recent one was bzip2 <sbp>specifically v532psmi7s45hd91m9cxpb4pcrwvvs15-bzip2-1.0.6; the last message before the error was "87.2 KiB transferred" <sbp>when I checked, the perms were "drwxr-xr-x 25 root root". I changed them to "drwxrwxr-t 25 root guix-builder" <sbp>the install was successful after that <civodul>actually, downloading goes through that 'startBuilder' method, which does the permission check <civodul>so i wonder how it failed to be detected earlier <sbp>hmm. when I started it again (after fixing the permissions error), it started with xz. the next one was bzip2. so it was downloading packages in a different order to the previous invocation, including one that it had already downloaded <sbp>(was followed by gawk, perl, etc., and eventually python) <jmd>sbp: Typically the downloads are done in parallel, so the order you observe will not be consistent. <gzg>So, is there a plan on impleenting anything like explicit meta-packages and/or "package collections" -- or am I missing something? <gzg>So far -- grabbing all need components of x11, to get guile-wm working has been a pain. <gzg>I mean, shouldn't 'xorg-server' just "do it"? <gzg>I'm probably just going to add xinit -- maybe I just don't understand xsession enough. <civodul>gzg: no real plan for meta-packages, but that may be a useful addition, indeed <civodul>though for guile-wm, all you need is guile-wm, no? <gzg>civodul: I'm just trying to figure out how to start it via a tty and I might just be ignorant on/to the subject, seeing I've only messed with .xinitrc. :^P <civodul>gzg: i actually gave up before i could use it! <civodul>the source tarball has an example config file <gzg>civodul: I've played around with it on my Debian install, that had xorg already setup and I just added it to said .xinintrc -- right now I'm on my minimal Parabola install, I dedicated to Guix and tryieg to figure it out. <gzg>Eventually, I want to generate and possibly host a test VM with GNU ~0.5+ Emacs, and Guile-WM. <gzg>Maybe Guilemacs eventually too. <civodul>i was trying in Xnest, whereas i'd rather use Xephyr, i'm told