<fredmanglis>The daemon is run as root though, right? Could the version mismatch between the daemon, and my user's version of guix be causing the failure in 'guix package --install/--update..." and 'guix pull'
<fredmanglis>I've never run `guix pull` as root, since install: `guix --version` as root gives "guix (GNU Guix) 0.11.0" while as frederick I get "guix (GNU Guix) 66660960ba75233ae5b6c539f43d97d06d64e9ad"
<efraim>In that case I would suggest 'sudo -E guix pull' so you can use "Fred's" guix binary for guix pull and not need to upgrade Root's guix version incrementally
<fredmanglis>efraim: Thanks. That did not work though, "Fred's" guix is broken, and will not install/update or pull anything...
<fredmanglis>I'm trying to repair it, but if my run as root fails, I'm nuking the install and starting over.
<civodul>fredmanglis: what failure do you get exactly?
<cehteh>with 512MB ram only i bet it becomes unbearable slow
<elpogo>i'm not doing anything else on that VM, so should be fine. i'll try zswap if it doesn't work like you say
<cehteh>guix / guile itself is the memory hog, and swapping is few orders if magnitude slower than ram
<cehteh>if memory only leaks and gets swapped out (common problem on bad java programs :D) then its not much a problem, but when it has to swap things in constantly then swap is so slow that it doesnt make any sense
<elpogo>does zswap help because some of the 'swapping' happens via compression to RAM?
<cehteh>compression ration is usually around 50% or better, offering half your ram to zswap means that it wont hit the disk early, z3fold is newer and can stash 3 compressed pages in one for pages which compress really good, lz4 costs more cpu on compressing but compresses better than lzo
<civodul>essentially the base system first needs to be compiled
<thomasd>Am I correct that, by default, no shell is available in a build environment?
<thomasd>(And if I need one for the build process, is bash-minimal the preferred one?)
<laertus>every time i run "guix package -i glibc-locales" guix tells me "substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable" and then proceeds to "updating list of substitutes from 'https://mirror.hydra.gnu.org'..."
<ng0>does someone know how I can find anything that is not plain ascii symbols in a texinfo file (with less or with emacs)? I get @u8 not being a unicode char problem. I tried an with C-M-s and then [ -~] but once I start moving in this very long file I loose the marked content
<laertus>also, it tells me "guix package: warning: Consider running 'guix pull' followed by 'guix package -u' to get up-to-date packages and security updates." should i do that before continuing with the "guix package -i glibc-locales" (which still has a boatload of packages to install) ?
<bavier`>laertus: anyhow, to answer your question about 'guix graph' vs 'guix package -i .. -n', it's because 'guix graph' has all these different view types :)
<bavier`>depending on what part of the graph you're interested in
<laertus>so what am i looking at here? does stuff like "/gnu/store/rsbi86fbhjf4j6305hj2iy1qkmzh6isf-glibc-locales-2.25.drv" -> "/gnu/store/sx2hjydw6fmc47bns32gj3jd0yvr3zk0-gcc-5.4.0.drv" mean that glibc-locales-2.25 depends on gcc-5.4.0?
<sadiq[m]>it would be nice if /usr/bin/env was provided by guix
<laertus>strange that neither subversion or tcsh are listed in the graph, but they're both in the "guix package -i glibc-locales -n" output, and tcsh is what fails when i try to do "guix package -i glibc-locales"
<laertus>(and it mentions something about subversion failing to build too)
<laertus>nextos: i'm a notmuch user, but i haven't synced local tags with server-side folders.. i'm basically trying to use my webmail interface as little as possible and use notmuch as much as possible, so don't really care if they sync
<laertus>so i can't help... but there is a #notmuch you can ask on
<laertus>bavier`: "guix build -K mkfontscale" completed successfully, but i'm still getting the same tcsh test failure when i try to "guix package -i glibc-locales"
<bavier`>laertus: what does 'guix package --dry-run -i glibc-locales' say?
<laertus>janneke: ok, that returns: /gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin/nice
<janneke>great, so you know this command is available in and in PATh in the container when tcsh is built
<laertus>janneke: interestingly, when i then "cd tcsh-6.20.00/" and proceed to run the "nice" test from the tcsh testsuite as: ./tcsh -f -c '/gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin/nice set var=1; echo $?var'
<laertus>it tells me: /gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin/nice: ‘set’: No such file or directory
<laertus>when i "cd /var/tmp/guix/guix-build-tcsh-6.20.00.drv-0/; bash" and in bash: ". environment-variables ; cd tcsh-6.20.00 ; /gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/sh ./tests/testsuite"
<laertus>then test 68 (the "nice") test passes, but these tests fail: 35 40 134 154
<laertus>so there does seem to be some critical differences between my setup outside the build and inside the build
<laertus>well, if there's no solution to this tcsh issue at the moment, is there some way i can force guix to just keep building other packages that it needs to install glibc-locales?
<laertus>i'd like to use this time productively...
<ng0>laertus: do you consider working on xfs for guix, or did I understand the message wrong? If you want to, I can give you a head start with what I have, because I won't be finishing or working on it anytime soon
<laertus>ng0: i'd love to, but i'm afraid i don't have time to do any development work.. i barely have time to just install and start using guix
<laertus>hopefully i can make some time to learn how to create new packages and maybe contribute something to that
<laertus>what i wrote about xfs above was just that i used it as my root filesystem under Gentoo
<ng0>imo, I've used Gentoo for some time too, there is no real gain for building only fronm source.
<laertus>and over that i'd mounted zramfs just for the guix build directory, but that i could test removing that zramfs mount to see if it would make a difference with building tcsh (it didn't)