IRC channel logs


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.
<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:
<civodul>on i686
<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
<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.
<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.
<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
<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>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 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!
<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>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
<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