IRC channel logs

*gzg is finding it problematic to resize te FSes in the VM image. :^P

<gzg>Parted doesn't find the disk label.

<mark_weaver>what device did you ask it to look at?

<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>(that would make a 1.5 GiB image)

<mark_weaver>oops, sorry, that's not quite right.

<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!

<civodul>Hello Guix!

<civodul>damn, test failure in GLib: http://hydra.gnu.org/build/30957/nixlog/1/raw

<civodul>on i686

<jmd>Odd. I built it several times last night.

<jmd>I even got it cross compiling!

<civodul>woow!

<jmd>(although I had to cheat)

<civodul>it must be a non-deterministic failure

<civodul>because it's worked well in the past

<civodul>it needs an update, BTW

<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>and then it worked.

<jmd>... may have been co-incidence ...

<civodul>yes, a coincidence

<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.

<civodul>ok

<jmd>As I recall it was one of the dbus tests failing. So perhaps the problem is in dbus and not glib

<civodul>hmm, ok

<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>OK. I will do.

<jmd`>civodul: I've got a very basic version of my linter working.

<civodul>jmd`: nice

<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.

<civodul>:-)

<davexunit>what does the linter do?

<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?

<davexunit>is it for guix in particular?

<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 ."

<mark_weaver>poor man's continuous integration :)

<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?

<civodul>so died after 1hr of silence

<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.

<mark_weaver>"guix build -n glib" prints nothing at all, btw.

<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

<civodul>ttyl

<jmd>What is the policy about changes which cause coreutils rebuilds?

<civodul>jmd: we open a core-updates branch for rebuild-the-world changes

<civodul>why?

<jmd>Well its unlikely that such a change will never be required.

<civodul>ah right, of course

<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.

<civodul>hmm!

<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

<sbp>(end)

<civodul>sbp: oh, thanks for the detailed report!

<civodul>was it with 0.5?

<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`

<civodul>oh

<civodul>ah right, i see

<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

<civodul>ok

<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>(on /nix/store)

<sbp>the install was successful after that

<civodul>i see

<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)

<sbp>back in a while

<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

<civodul>well, startup file

<civodul>which is where i started from

<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>would be neat!

<civodul>so you got it running?

<civodul>i was trying in Xnest, whereas i'd rather use Xephyr, i'm told

IRC channel logs

2013-12-16.log