<ngz>Assuming an installation of Guix on top of an existing system, am I supposed to call "guix pull" from root or from user? I tried the latter, quite a few packages were installed (libunistring, guile-2.0.11...) but also were removed on next "guix gc". It is odd.
<ngz>Maybe not "odd", but I expected core packages impossible to gc.
<civodul>ngz: it's "normal" that they are removed if nothing refers to them
<civodul>"guix pull" needs them, so it would redownload them again next time
<cehteh>well imo its one weakness (bit unrelated) in PGP that anyone can send signatures to a keyserver, signatures should be send to the key owner who then should import and sign this import by himself
<rekado>now ./configure stops with "GNU libgcrypt does not appear to be usable". I have not installed it into my profile as I just want to be using "guix environment". Should I pass --with-libgcrypt-prefix pointing at some item in the store then?
<ngz>Hello. I have strange locale issues since installing Guix on top of Archlinux. I installed Emacs from Guix, but now my Gnome session (from Arch) appears in English and accentuated characters are sometimes not recognized in Emacs.
<rekado>ngz: is installing Emacs all you did or did you also set any environment variables?
<rekado>Guix does not (by itself) alter the host environment in any way outside of the store and the localstatedir.
<civodul>so you probably need to make sure GNOME itself doesn't see that LOCPATH value
<mark_weaver>I seem to recall that in the case of Debian, setting LOCPATH to point to Debian's native locales directory caused locales to fail for Guix-compiled software, which suggests that somehow our locale directory was incompatible with Debian's.
<ngz>rekado: Thanks. I was doing guix package -l and read them from the last generation.
<mark_weaver>it is desirable to be able to set up an alternative environment with different environment variable settings, and to be able to launch subshells in that alternative environment without having them all be reset by .bashrc
<ngz>OK. So I move LOCPATH and LANG into bash_profile (along with possibly every export VARIABLE).
<mark_weaver>and if you want to use the 'guix environment' command, this is important
<ngz>Let me restart X to see if it changes something to Gnome...
<mark_weaver>to debug this further, it would be helpful to run 'strace' on a program that fails to load the locale, so that we can see what it's doing when it's looking for locales and how it's failing.
<mark_weaver>alternatively, I can offer a simple hack, namely to unset LOCPATH and instead put a symlink at /run/current-system/locales pointing to your $HOME/.guix-profile/lib/locale for now, since that's where Guix-compiled software will look for locales by default (in the absence of a $LOCPATH)
<mark_weaver>but obviously it would be good to find out what's happening here
<mark_weaver>pecg: you have (use-package-modules admin) near the top of the config file?
<ngz>Just above the /run/current-system/locale/ failing checks
<phant0mas>--with-native-system-header-dir= from %gcc-static should point to the current system glibc, or the target system?
<mark_weaver>ngz: this is a shot in the dark, but you did export LOCPATH, right?
<mark_weaver>on my system, I ran "LOCPATH=/home/mhw/locale strace -o trace.out guix package -I" and the trace.out contains open("/home/mhw/locale/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
<mark_weaver>ngz: if you set LOCPATH in .bashrc, then it would be set in your shells even if it wasn't set in gnome-session. what are the values of LOCPATH and LANG in /proc/<PID>/environ, where <PID> is the PID of gnome-session?
<mark_weaver>(I had been operating on the assumption the LOCPATH was set only in your .bash_profile)
<ngz>There, LANG=fr_FR.utf8 and LOCPATH doesn't exist.
<mark_weaver>can you paste the entire contents of /proc/<PID>/environ somewhere?
<ngz>But then, I would have noticed something since the beginning, not after installing emacs.
<mark_weaver>here's what "guix package -i emacs" does: it builds your new profile (tree of symlinks) in a directory in /gnu/store/*, and adds/modifies symlinks in $prefix/var/guix/profiles/per-user/ngz/
<mark_weaver>I'm at a loss for how that could break gnome-session launched from GDM, where no environment variables point to anything guix related.
<mark_weaver>I guess a next step would be to run a gnome program within strace, using the same environment variables that are being used to launch them where they are failing for you, and find out what's going on.
<mark_weaver>but first, I do think that you should fix the ownership and permissions on /, /var, and /root
<mark_weaver>it's possible that this is causing some breakage somewhere.
<civodul>alexshendi: did you try other X11 clients, like xterm or Evince?
<DusXMT>And some devices, like Android phones, use completely different bootloaders...
<jackdaniel>so given own kernel / u-boot it should be fairly easy for someone who knows guix?
<davexunit>DusXMT: yeah, so we'll have to make our bootloader stuff generic enough to handle all of this variety.
<jackdaniel>I can help a little, but first has to get some grasp on guix (I have a few armv7 boards)
<davexunit>jackdaniel: I like to pretend that I know guix, but I don't know how to get started on this, actually. :)
<alexshendi>civodul: xterm runs, but is unable to find some fonts. Evince seems to work as does hexchat :)
<davexunit>mark_weaver has done all of the work on armv7 thus far. I have a Novena to use now, but I haven't made an effort to bootstrap guix on it and figure out what to do next.
<DusXMT>jackdaniel: yup, you just have to implement the needed mechanisms. First would be good to figure out how to do it by hand, then once you know about the subject, you can start implementing it in Guix
<alexshendi>civodul: In fact I'm running a configuration based on the desktop config.
<davexunit>our build farm doesn't serve binaries for armv7 yet, so we all have to spent many hours compiling from scratch
<DusXMT>jackdaniel: but you'll have to do many design decisions when doing something like this, many of which'll need to go through long discussions
<jackdaniel>davexunit: if I'll compile stuff with guix - submitting binaries is explained in manual, right?
<civodul>alexshendi: an ARMv7 box would be very useful for our build farm, to begin with!
<mark_weaver>civodul: the "Binary Installation" section of the manual is missing a step: to create the build users and group
<civodul>mark_weaver: it has that in step #3, with an xref
<jackdaniel>civodul: have you considered creating "dumb" qemu armv7 box?
<civodul>jackdaniel: no but you're right, it could be a first step
<civodul>though we're also a bit short on Intel boxes currently ;-)
<mark_weaver>jackdaniel, civodul: there may be problems with doing that. qemu is meant to run correct code. it doesn't not promise to fail in all the ways that real machines might fail.
<zerwas>And while we're at it: There's no need to "cd" into the directory in step 2 of the binary installation instructions as tar can handle it with "-C /". Same for step 4 :)
<mark_weaver>and that might be problematic with the way that autoconf works.
<alexshendi>civodul: I used it (the ARM Chromebook) to run Arch Linux and Bodhi Linux. It has only a 16GB flash drive though ...
<gnusosa>Hi, does the guix binary tar contain guix's guile modules? I'm trying to do guix offload, I was succesful to have lsh with openssh working, and having guix archive --import working. <-- Thanks to rekado's conversation and bugs mails.
<gnusosa>But I can't get 'guile -c (use-module (guix config))' working :(
<mark_weaver>alexshendi: does it have any SATA interfaces? how much RAM does it have?
<gnusosa>Maybe I'm missing a PATH or ENV variable.
<rekado>bleh, networking is no fun :-/ I'm downloading substitutes and then midway things fail with "guix substitute: warning: failed to look up host 'hydra.gnu.org' (Name or service not known), substituter disabled"
<rekado>in the list of services I do not see dhcp-client-service, though. Just networking.
<cehteh>civodul: btw has dmd ways to implement preconditions/postconditions and wait (events) on these
<civodul>cehteh: no, it's just a simple DAG currently
<cehteh>for example, starting up a webserver should first check that port 80 isnt used, then start the webserver and afterwards check that the process just started listens on port 80
<cehteh>(little bit simple example, but there are some services which take a noticeable time to start up and dependent services should only start up after the fiormer is available and serving requests)