IRC channel logs
2015-05-18.log
back to list of logs
<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 <ngz>civodul: That what I though, but somehow it surprised me (I expected them to be there already, and impossible to gc). <taylanub>I seem to remember you saying you use Guix on top of Arch, so I guess the reason explained there applies to you too. (in my case Debian) <ngz>So, what did you do? <taylanub>well it should probably be fixed eventually. :) just no priority (for me at least) <ngz>Hmm. I cannot find guix.el. I see some references to it in the store, but I cannot load it in my Emacs. <rekado>so, on GuixSD if I want to work on guix, should "guix environment guix" just work? <rekado>because it doesn't for me. I get this error: "checking whether the C compiler works... no" <svetlana>what is Luis Felipe López Acevedo's irc nickname? <rekado>taylanub: same with and without --pure. <rekado>so, the error is with the linker: "ld: cannot find crt1.o: No such file or directory" <Sleep_Walker>env -i /path/to/git/pre-inst-env guix environment -e '(@@ (gnu packages package-management) guix-devel)' --pure <rekado>hmm, I don't know how to make it work :( <rekado>I took my guix working directory from my Fedora machine; I want to reconfigure everything, but with the linker not working right I can't do that. <davexunit>I can never remember... how do I run an individual test file in our test suite? <davexunit>in this case, I want to run tests/guix-package.sh <daviid>sorry! wireless keyboard cleaning time ... nice source of bug right? :) <bavier>davexunit: you set the TESTS make variable to the file name. <rekado>hmm, even with "guix environment -e '(@@ (gnu packages package-management) guix-devel)' --pure" I get an error when running ./configure :( <rekado>configure: error: C compiler cannot create executables <davexunit>rekado: strange, I've never had such an issue. <civodul>rekado: i can't reproduce it with a current Guix <civodul>notice the super-efficient hot line ;-) <davexunit>bootstrapping outside the environment could lead to a broken configure script *civodul tried with guix-0.8.2.tar.gz, so no bootstrapping here <davexunit>oh I assumed we were working with the git repo here <davexunit>civodul: what kind of tests do you feel are necessary for that new 'guix package' option that I proposed? <davexunit>an integration test in tests/guix-package.sh is all I could come up with. <bavier>btw, I'm not so fond of the name "apply" for that new option <davexunit>the patch was a quick proof of concept for demonstration purposes. I didn't want to waste too much time thinking about a name. <civodul>davexunit: yes, tests/guix-package.sh sounds good; the test will have to restrict itself to installing %bootstrap-guile <civodul>--manifest sounds better than --apply, indeed <rekado>I forgot to bootstrap after replacing Fedora with GuixSD. <civodul>that may be the reason, like config.cache referring to Fedora's compiler or something <civodul>rekado: did you use 'guix system init /' or did you install from the USB image? <rekado>I'm just reusing my home partition. <rekado>inside "guix environment" shouldn't all environment variables be set as needed? Running ./bootstrap I get an error about "error: possibly undefined macro: PKG_CHECK_MODULES". <rekado>I suppose I need to manually set a few more environment variables. <civodul>since guix-devel depends on Automake and pkg-config, that one should be set automatically <civodul>but guix-0.8.2 does *not* depend on Automake, and so you don't get ACLOCAL_PATH for that one <rekado>hmm, so I ran "guix environment -e '(@@ (gnu packages package-management) guix-devel)' --pure" and then "./bootstrap". <rekado>that fails with undefined macros GUILE_MODULE_AVAILABLE and PKG_CHECK_MODULES <civodul>here it has $guile/share/aclocal and $pkgconfig/share/aclocal <rekado>it's set to /home/rekado/dev/guix-dev-profiles/guix/share/aclocal, a value I set in .bashrc (for when I used Fedora). <rekado>I thought guix environment would overwrite the environment variables. <civodul>here your .bashrc overrides what 'guix environment' sets <rekado>makes sense. Thank you and sorry for bothering everyone :) <civodul>.bash_profile is for login shells, and .bashrc for non-login shells <civodul>it took me hmm 15 years of GNU/Linux hacking to understand this ;-) <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? <rekado>I would have liked it better if I could have just used guix environment. <civodul>yeah, the problem is that we cannot guess libgcrypt's location <civodul>even though it's in the environment, you need to pass --with-libgcrypt-prefix=... <civodul>i haven't found a nice way to avoid that <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. <ngz>I export LOCPATH from bashrc. <ngz>(value: ~/.guix-profile/lib/locale). <civodul>ngz: you probably need to "guix package -i glibc-locales" also <civodul>and then make sure the LOCPATH value is right in Emacs' environment <ngz>I have glibc-locales installed too. <ngz>In fact I have 3 packages: recutils, glibc-locales and emacs. <civodul>you might need "guix package -i gsfonts font-dejavu", for the X11 fonts <ngz>Oh, and that one too. <ngz>So, I have 4 packages. <rekado>ngz: you can get a list of all installed packages with "guix package -I" ;) <ngz>Upon reboot, Gnome asked me if I wanted to rename usual desktop folders (e.g., Téléchargements into Downloads or whatever) <civodul>could be related to the fontconfig cache <civodul>oh, looks like LOCPATH is causing problems for the rest of GNOME or something? <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. <ngz>I can try to remove LOCPATH altogether. I added it because I was trying to solve "warning: failed to installe locale: Invalid argument" issues when calling guix command. <ngz>But it failed. So I have no reason to keep it. <mark_weaver>well, you will need LOCPATH to be set in order for Guix-compiled programs to load locales properly <ngz>But how guix-compiled programs know the locale I want to use? <mark_weaver>but then it needs to look up the actual locale information, which it finds via LOCPATH <ngz>So, do I have to export LANG from bashrc too? <mark_weaver>well, normally you would get environment variables from .bash_profile, but yes <ngz>.bash_profile just sources bashrc anyway. <mark_weaver>the problem with setting environment variables from .bashrc is that they all get set from *every* interactive shell <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... <ngz>Unfortunately, Gnome is still in English. <mark_weaver>do you find that your environment variable settings are present in your shells now? <mark_weaver>it may be that nothing is loading .bash_profile because there is no login shell launched. <ngz>echo $LANG from urxvt gives fr_FR.utf8 <ngz>~/.guix-profile/lib/locale <mark_weaver>tilde expansion is done by shells, but is generally not valid within an environment variable setting. <ngz>OK. Let me start over with the full expansion. <pecg>Hello, I'm running: guix system init /mnt/etc/configurate/config.scm /mnt <pecg>using the default no-x11 configuration <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. <pecg>but then: ERROR: unbound variable tcpdump <pecg>where would be a good place to start? <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? <mark_weaver>pecg: are you doing this from our 0.8.2 USB installer? <pecg>mark_weaver: my config.scm is exactly the same as the one suggested in guix installation guide. <ngz>mark_weaver: every call to guix command warns about a local invalid argument. However, strace "guix package -I" is rather large. <pecg>I want to build GuixSD in a VM <mark_weaver>pecg: okay, you're running from qemu, but what system are you running within qemu? <ngz>I see a few errors. Namely open("/run/current-system/locale/locale-archive", ...) (No such file or directory) <pecg>mark_weaver: the host is parabola <ngz>The same goes for "/run/current-system/locale/fr_FR.utf8/LC_IDENTIFICATION" <mark_weaver>ngz: it should also look in the directory specified by $LOCPATH <ngz>an error because LANG is fr_FR.utf8 and the directory is named fr_FR.UTF-8 <ngz>It only tries various /run/current-system/... locations. <ngz>At least, that doesn't appear in strace output. <mark_weaver>ngz: and the LOCPATH variable was set for that process? <ngz>I called it from urxvt, where $LOCPATH contains something. <ngz>something being /home/ngz/.guix-profile/lib/locale <ngz>There is also that line: <ngz>open("/gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 7 <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) <ngz>Then I obtain open("/home/ngz/.guix-profile/lib/locale/fr_FR/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 7 fstat(7, {st_mode=S_IFREG|0444, st_size=316, ...}) = 0 <ngz>But still "warning: failed to install locale: Invalid argument" <ngz>At that point, I have "export LOCPATH=..." in both bashrc and bash_profile, out of despair. <ngz>(I had already at the first strace call) <ngz>echo $LANG => fr_FR.utf8 <pecg>mark_weaver: i'm using guix 0.8.2, but managed changing the line of packages from: (packages (cons tcpdump %base-packages)), to: (packages (cons* %base-packages)) <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>Sure. Hold on a sec, please. <mark_weaver>ngz: I don't see any environment variables pointing to anything Guix-related, so I'm at a loss of how Guix could be affecting the behavior of GNOME from Arch. <mark_weaver>did you change your locale setting when you installed Guix? <ngz>Note the change happened when installing emacs from guix, not when installing recutils (though the warning from guix calls already existed) <mark_weaver>did you compiled guix from source code manually and run "make install" ? <mark_weaver>installing emacs from guix broke your GNOME from Arch? <ngz>No, I followed instructions from manual (extracting guix-install IIRC, creating user groups, etc.) <mark_weaver>there are a few different options for installing. did you compile guix from source code, or did you unpack one of our "guix-binary" tarballs? <mark_weaver>okay, there was an issue discovered with that method, namely that it changes the metadata (ownership/permissions) on a few directories such as /root and /var <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. <ngz>I don't understand either. <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. <ngz>OK. I'll look into it. <ngz>I have to go AFK for now. Thank you for taking time looking into it. <mark_weaver>it may be helpful to send an email to bug-guix@gnu.org about it, and then others can comment on it, not just whomever happens to be on IRC right now :) <bavier>exciting, I didn't realize we already have rdesktop available <paroneayea>I wonder if more tools can't be written to help us tell when to update packages, and help write the package updates <davexunit>rekado: per your guix environment issues earlier: './configure --with-libgcrypt-prefix=$(guix build libgrypt | head -1)' <phant0mas>%gcc-static in make-bootstrap.scm uses the glibc, meant for the target system, right? <phant0mas>I think that glibc-for-bootstrap, does not choose the right glibc from base, because the macro I added doesn't evalutate right. <amirouche>paroneayea: is sfxr looks very useful, maybe awesome <amirouche>huh I don't need portable .dotfiles yet. I just switch projets :)) <civodul>phant0mas: i would need to look at the code that you have, notably the macro that selects the libc <civodul>a simple way to debug it is by adding 'pk' calls, or by inspecting the package objects at the REPL <phant0mas>civodul: I think it's time to send some of the code to the list for reviewing *jackdaniel installs binary guix on top of archlinux <alexshendi>HI, folks I have installed GuixSD 0.8.2 on my system, but I'm having a few problems: <amirouche>alexshendi: what do you to do ? compile something? <amirouche>alexshendi: try "find / -name "header_filename.h"" <alexshendi>I don't seem to have fonts like 9x15 or 10x20 installed? <alexshendi>how do I get a receipe for an exsisting package? <amirouche>you mean, find the scheme file declaring the recipe? <amirouche>I think it appears when you do «guix pakage -s {{ PACKGE NAME }}» or try «git clone guix» then in guix://gnu/packages/emacs.scm for instance <jackdaniel>how long should /root/.guix-profile/bin/guix-daemon --build-users-group=guix-builder take? <amirouche>alexshendi: look in the directory from where you installed <amirouche>it's looks like a zombie but it's dubbed daemon because it aims to be useful :)) <jackdaniel>is `warning: failed to install locale: Invalid argument` something crucial, or I can ignore it? <alexshendi>Actually I'm only trying to use Edwin from inside MIT-Scheme. <civodul>alexshendi: for most X11 clients you'll need to install gsfonts, and possibly font-dejavu in your profile <civodul>jackdaniel: you can ignore the warning; i'll add something in the manual describing how to fix that <davexunit>civodul: should it be possible to create a profile with %bootstrap-guile in tests/guix-package.sh or must I do a dry run? <jackdaniel>civodul: any eta when guix sd will be available for arm? or resources I can read on topic? <alexshendi>civodul: Thanks! Actually the error msg I get is: ";Can't find any usable display type" :( <alexshendi>Maybe it was compile w/o X11 support ans is unhappy with the terminal emulator. <civodul>jackdaniel: it wouldn't be difficult now that Guix itself (+ packages) is available on ARM, so it mostly "needs to be done" ;-) <civodul>i don't have access to armv7 hardware, and few people do <civodul>well, there's still the difficulty that for ARM we'd need a bootloader other than GRUB <davexunit>and a different boot loader depending on the hardware <DusXMT>also, each of those devices has different firmware <davexunit>for example, the novena requires a u-boot fork. <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? <davexunit>jackdaniel: well, no one "submits" binaries. guix builds them all from the recipes we define. <alexshendi>davexunit: I have an Samsung ARM-based chromebook, which I would be willing to donate ... but I think it has a custom bootloader. <davexunit>the HACKING file describes our guidelines and workflow <jackdaniel>guix package: error: build failed: the group `guix-builder' specified in `build-users-group' does not exist <- <mark_weaver>jackdaniel: you need to create the users and groups, as described in section 2.4.1 (Build Environment Setup) <mark_weaver>jackdaniel: I see that the "binary installation" section fails to mention that step, sorry about that. <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. <bavier>hrmm, can't run any programs with mesa on top of my Trisquel distribution: "Gen6+ requires Kernel 3.6 or later." <bavier>might be time to upgrade to Triquel 7... <alexshendi>mark_weaver: That is all I know about the hardware myself :) <jackdaniel>one more question - how hard it is to add separate build server with custom recipes to my env (including configuration of such server)? <mark_weaver>jackdaniel: see section 2.4.2 (Using the Offload Facility) of the guix manual <civodul>bavier: fear not, upgrade to GuixSD! ;-) <bavier>civodul: I may actually be able to soon. ;) <mark_weaver>alexshendi: hmm, the lack of a fast disk interface may or may not be a problem. I'd be curious to know how long it takes to bootstrap the system up to the "hello" program. <civodul>gnusosa: the tarball does include the modules; you probably need "export GUILE_LOAD_PATH=/root/.guix-profile/share/guile/site" or similar <davexunit>I plan to upgrade my laptop to guixsd real soon <mark_weaver>well, for ease of comparison, the time to build gcc might be a good thing to measure. <civodul>bavier: it would be fun to be able to claim that there is a computer at your company running it :-) <davexunit>after I finish some patches and get my dotfiles under control <civodul>davexunit: you'll have to blog about that ;-) <civodul>oh, and about version control of your profile and so on <bavier>civodul: certainly, esp. if I want to make arguments about deploying it elsewhere <davexunit>I plan to use guix for as much as possible at my new job. <civodul>as silly as i am, i managed to "sell" Spack to my HPC coworkers <davexunit>it will be relegated to just my workstation to start with,. <bavier>did we want to create torrents for the 0.8.2 release? <civodul>but again, i'd rely on someone else to do the actual work ;-) <rekado>when building stuff I get this "error: build error: executing `/gnu/store/cnqmkmj40jmssnx6fkf9n0n3bqj5x426-guile-2.0.11/bin/guile': Permission denied" <rekado>civodul: yes, the file is executable. <rekado>another thing I often experience is a problem with name resolution. <rekado>I can resolve gnu.org but not necessarily hydra.gnu.org. <rekado>I haven't been able to figure out a pattern to this yet, but it seems to be related to awaing from suspend. <civodul>rekado: is this on an NFS mount or something? <civodul>re name resolution, our libc attempts to talk to nscd by default <civodul>if nscd is not running, it'll dlopen the NSS modules specified in nsswitch.conf <rekado>no, it's on my local machine, everything is on local disks. <civodul>can you execute that program by hand? <rekado>the "non-executable" guile? Yes, I can execute it just fine. <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>it works for a couple of seconds and then ... just fails again. <civodul>how many dhclient processes are running? <civodul>and then "guix pull && guix system reconfigure" so you get the dhclient fix <rekado>should deco start networking spawn a dhclient process? <civodul>yes, if you're using dhcp-client-service <rekado>is there a way to list all available services with dmd? <civodul>"deco status networking" returns the PID of the dhclient process <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) <cehteh>think about tor, freenet, yacy etc <cehteh>i would really like such, service supervision by checking that the service is actually doing what it should do, not just that some process is running <cehteh>that would be a kindof killer feature for a init system <gnusosa>civodul: is it normal to not have guix scheme files in a user profile, and only in the root guix profile? <civodul>gnusosa: normally one doesn't install Guix in ~/.guix-profile, except if you used the binary tarball, in which case it's normal <civodul>gnusosa: you should probably make /usr/local/share/guile/site point to /root/.guix-profile/share/guile/site <civodul>that way, the Guix modules will be visible from there <civodul>then you need to set GUILE_LOAD_{,COMPILED_}PATH accordingly <gnusosa>thanks, I just wanted to know if it was normal. <civodul>alexshendi: i get ";Can't find any usable display type" as well, so it's probably a problem with our package <civodul>it doesn't depend on libX11, that would be something to add <alexshendi>civodul: That's why I asked how to find X includes. I would like to recompile from source... <civodul>you could edit gnu/packages/scheme.scm and add ("libx11" ,libx11) to the input list <civodul>and then run "guix build mit-scheme" <alexshendi>civodul: I can only find "/gnu/store/sfw64fin80dhmn160cq71f46v7hfgbfm-guix-0.8.2/share/guile/site/2.0/gnu/packages/scheme.scm"? <rekado>alexshendi: you should never edit anything in /gnu/store *alexshendi is now thoroughly confused. <rekado>alexshendi: oh, I did not mean to confuse you. <civodul>alexshendi: you could git clone Guix, and start from there <rekado>If you have a git checkout you can feely edit stuff there. <civodul>or copy the scheme.scm file that you found above to $HOME <alexshendi>civodul: COpying and editing the file sound reasonable.