<quiliro>is there a mobi or epub version of the manual? ***Sornaensis is now known as THE_LORD
<lfam>bavier: I shared my wx.h problem with guix-devel <lfam>No problem. Feel free to ask more if you get stuck, but try to check the manual first. We'd like to know where it falls short <hodapp>I thought I had read that some ARM systems were in use, but are any instructions online for how to use GuixSD on an ARM system, even if some bootstrapping is needed? <lfam>hodapp: We currently support Guix (the package manager) on ARM, but GuixSD isn't there yet. There has been some work to support it but nothing that has made it all the way to completion, so far. <lfam>There might be other discussion in the archives of guix-devel, I'm not sure <lfam>Also, efraim is working on bootstrapping Guix for aarch64. If that's your hardware, you should see what they've done so far. ***Sornaensis is now known as THE_LORD
***pecg_ is now known as pecg
***pecg is now known as Guest51733
***Guest51733 is now known as pecg
***THE_LORD is now known as Sornaensis
<rekado>whenever I feel the need to use the REPL with Geiser I feel like I'm starting from scratch. <rekado>I'm playing around with the module (guix import cran) <rekado>I've entered the module with C-c C-m (guix import cran) <rekado>but I still cannot use any of the defined procedures <rekado>bleh, but I still have to manually input all the modules I want to use. <atheia>I've literally just started experimenting as a result of your messages <atheia>For me, as long as the modules I want to use are part of the geiser load path, C-c C-m works to provide access to the procedures imported by that module and the procedures defined in that module. <atheia>So I've just added some convenience keybindings to my projectile hydra (both great emacs packages) that from now on allow me to a) add the given project that I'm working on to Geiser's load path b) load the current buffer as a module in Geiser and switch to the REPL <rekado>I have access to the procedures but they don't seem to have access to procedures in other modules. <rekado>gives me this error: In procedure module-lookup: Unbound variable: http-fetch <rekado>but the module itself loads (guix http-client), which defines http-fetch. <rekado>not sure about the geiser load path. I have ~/dev/guix in my Guile %load-path. <atheia>Your example works for me — and you are right: I augment my guile-load-path, not geiser-load-path. <atheia>Do you get the same problem if you manually run through the steps in a geiser REPL? <rekado>more stuff happens already; it's compiling modules. <atheia>And this is in a Geiser Guile REPL or just a Guile REPL on the commandline? <rekado>just a Guile REPL (in a shell buffer in Emacs) <atheia>I see… so it'd be interesting to see whether it works in a Geiser Guile REPL too, if it works here, as a next step perhaps? <rekado>now I cannot even find the guix modules anymore in a Geiser session. <rekado>the %load-path still contains ~/code/guix <rekado>and when I load (guix) it says ERROR: In procedure dynamic-link: file: "libgcrypt", message: "file not found" <rekado>even though /var/guix/profiles/guix-dev/lib/libgcrypt.so.20 exists <rekado>I'll try resetting everything and start from scratch. <thomasd>Hi #guix! Is it difficult to define a package variation (using custom package and "inherits"?) that builds a package using a different compiler (version or brand...)? <efraim>configure flag of cc=clang and add clang to native-inputs? <thomasd>And what if one wanted to use (I hardly dare say it out loud) intel compilers? <efraim>I assume you'd have to package it yourself <thomasd>Probably one would have to (somehow) wrap the intel compilers in a Guix package. It's probably a bit opposed to Guix' goals, but quite a few HPC uses might be interested. <thomasd>I started to wonder after I read a comment by the author of Spack, that systems like Guix don't help the user to create their own variations of packages. I'm thinking it's not actually that hard. <efraim>its not too hard to copy elements from an existing package if you don't know how to make the modification <efraim>its much easier to "repeat the build steps" if the whole process is just `guix package -u' <efraim>I need to send some of my packages upstream, it turns out I have 16 packages locally <rekado>thomasd: do you mean replacing the compiler for every package? <thomasd>not necessarily for every package, but perhaps for a number of them <rekado>we have "guix build --with-input=PACKAGE=REPLACEMENT", which could be extended to also replace implicit inputs. <rekado>right now overriding the inputs that are added by the build system is not possible on the command line. <rekado>but you could write a procedure or a macro that takes a package and replaces any one input with another. <thomasd>specifically with intel and their math libraries, I believe you can run into issues combining libraries built with intel and packages built with GNU, I believe. For such scenarios, it would be nice if you could semi-automatically define variations on existing packages. <efraim>i guess you could replace gcc in the gnu-build-system with intel's compiler <rekado>or create a new build system and then define a macro to override the build system for a given package. <efraim>that'd be better, if you changed everything with gnu-build-system you'd have to fix the bootstrap process <thomasd>Yes, defining such a build system sounds like a robust solution. <thomasd>it seems that these spack features (essentially packages parametrized by version, toolchain, etc) could be built on top of Guix quite reliably (or at least an equally convenient alternative) <rekado>at the MDC we use Guix to provide different versions or variants of packages, simply by inheriting from a base expression. <rekado>on the command line package dependencies can be swapped out with "--with-input" <rekado>it's just toolchain changes that are not yet as convenient. <rekado>do note, though, that by changing the toolchain you would need to rebuild that part of the graph <rekado>because guix packages capture the complete dependency graph, not some arbitrary subset. <davexunit>ugh, that HN thread with the Spack person that dismisses guix over and over <davexunit>it's really common for people to complain about guix packages being too verbose <davexunit>some say that a package is *just* metadata and should be one package per json file or something <davexunit>some say that bash should be used to keep with the "UNIX philosophy" <davexunit>I've had people complain that the hello package should be at most 3 or 4 lines <davexunit>and that the hash being part of the package is bad, it should be in a separate file for easier updating. <davexunit>basically everyone thinks that packages should live in files/directories alone <hodapp>someone on HN being dismissive? I CAN'T EVEN IMAGINE! <quiliro>how can i check the log for guix system init /mnt/etc/bare-bones.scm /mnt --fallback <quiliro>even with fallback i get an error with 32 bit installation <rekado>quiliro: the log is printed to standard output, is it not? <quiliro>rekado: yes...but i cannot go back much when i change consoles <rekado>I'm always using the shell in Emacs so I can scroll back. <rekado>I'm not sure if there's an additional log <quiliro>would you please test 32 bit installation with any of the .scm system init templates? <quiliro>from /etc/configuration on the live usb <quiliro>i used guix system init /mnt/etc/bare-bones.scm /mnt --fallback <quiliro>and /mnt/etc/desktop.scm and /mnt/etc/lightweight-desktop.scm <quiliro>i am installing in a 32 bit machine so it takes a long time <quiliro>i can use a 64 bit machine but i cannot use it as my main machine then <rekado>have you run "guix pull" before installation? <quiliro>guixsd install usb does not provide irssi so installation takes a long time <quiliro>you suggest i suspend the compiling that is doing now and do that? <rekado>"guix pull" ensures that you have the latest version. <rekado>then you can download binary substitutes <rekado>that would likely be faster than compiling everything on your machine <rekado>the manual should actually have told you to run "guix pull" <quiliro>but guix pull will ensure i have the latest on the install edia, not on the hard disk <rekado>"guix pull" fetches the latest version of the guix library. <rekado>this means that the packages guix will want to build are the latest <rekado>and if they are not too old hydra can provide pre-built binaries <quiliro>well...the guix system installation manual never said guix pull...only on guix <quiliro>note: build failure may have been caused by lack of free disk space <rekado>did you start the cow-store service? <rekado>did you follow the instructions in the manual? <eus>quiliro: you need to mount --bind /mnt/tmp2 /tmp <eus>quiliro: I have been doing the same as you have been doing these past 4 or 5 days ;) <eus>quiliro: So, I have 50 GB of free space mounted at /mnt <eus>quiliro: But, I errored out due to insufficient disk space. <rekado>are you all building from source? <eus>quiliro: So, I unmounted /tmp, mkdir /mnt/tmp2, and then mount --bind /mnt/tmp2 /tmp. ***wilson is now known as ZeroIme
<eus>rekado: I didn't plan to do so. <eus>rekado: But, since I saw no info on "guix pull" in the manual... <eus>rekado: and some binaries were missing in Hydra... <eus>rekado: I did "guix system --fallback init ..." <eus>quiliro: Beside mount bind /tmp, I also needed to swapon a swap space. <eus>quiliro: I forgot to add swap since the manual didn't say that. <eus>quiliro: Then, the built failed because of OOM killer. <eus>rekado: I filed a bug w.r.t. to the manual mentioning "guix pull". <davexunit>the bug is that substitutes are GC'd for stable releases <eus>rekado: But, the suggested fix was that for Hydra to retain the binaries instead of adding "guix pull". <eus>quiliro: If you plan to build from source, you must add an option to prevent guix from downloading substitute. <eus>quiliro: So, my story goes that I did "guix pull". <eus>quiliro: Then, I did "guix system --fallback --keep-failed init /mnt/etc/config.scm /mnt". <eus>quiliro: the process always tried to get a substitute binary first. <eus>quiliro: After "guix pull", finding substitute binary should always be a success. <quiliro>i cannot go back on the history of irssi <eus>quiliro: However, for an unknown reason, during some binary substitute downloads, my wireless connection lost the capability to resolve hostname. <eus>quiliro: Due to "--fallback" option, guix tried to build from source. Building from source ended up with failure. <eus>quiliro: Finally just today, after "guix pull", I did "guix system init /mnt/etc/config.scm /mnt". Without "--fallback" option, whenever the DNS resolution failed, I simply repeated "guix system init /mnt/etc/config.scm /mnt" until all of the substitutes got downloaded. <quiliro>i did something and irssi was blocked <eus>quiliro: Yes, so after "guix pull" is done, do "guix system init ..." <eus>quiliro: If an error happened during substitute downloads, check your network connection. <eus>quiliro: I did "dhclient WIRELESS_INTERFACE_NAME". <eus>quiliro: Once you can "ping gnu.org", then just repeat "guix system init ..." <eus>quiliro: Yes, the bind command is still necessary to ensure that you have ample space in /tmp. <quiliro>please repeat the command because i lost it <eus>quiliro: 1. Setup network connection (I did wpa_supplicant ...) <quiliro>and the option 'failed' for guix system init too <eus>quiliro: 2. Mount the filesystem at /mnt. <quiliro>the mount command and the guix system init command too please <eus>quiliro: 3. Start: herd start cow-store /mnt <quiliro>i just need the bind command and the guix system init command <eus>quiliro: 4. mkdir /mnt/tmp2 <eus>quiliro: 5. umount /tmp <eus>quiliro: 6. mount --bind /mnt/tmp2 /tmp <eus>quiliro: 7. guix pull <eus>quiliro: 8. guix system init /mnt/etc/config.scm /mnt <quiliro>just /mnt/tmp that was created by the installer <eus>quiliro: is there /tmp? <quiliro>and in that directory are all the downloaded files <eus>quiliro: I made another directory called /mnt/tmp2 <quiliro>eus: sorry...you were right...i have umounted /tmp <eus>quiliro: if /tmp no longer exists, just do mkdir /tmp <eus>quiliro: Then, you can: mount --bind /mnt/tmp2 /tmp <eus>quiliro: I used /mnt/tmp2 to avoid any clash with guix using /mnt/tmp <quiliro>eus: i have mounted /tmp now as you suggested <quiliro>do i suspend guix pull and rerun it? <eus>quiliro: it might be a good idea. <quiliro>i have sda1 mounted on /mnt and on /tmp <quiliro>i cannot explain why...i did exactly what you said <eus>quiliro: That's what mount --bind does. <eus>quiliro: So now any write to /tmp actually writes to your /mnt/tmp2 <eus>quiliro: That means ample space. <quiliro>eus: i am doing that not but please explain... <quiliro>eus: all the files that used to go into /tmp go into /mnt/tmp2 and all the files that went into /mnt/tmp still go there? <eus>quiliro: No problem. <quiliro>ACTION is jumping up in the air laghing! <eus>quiliro: guix uses /tmp for building. <quiliro>so the installer should have used a bigger partition for that... <rekado>I guess you could have also restarted the guix-daemon after setting TMPDIR <rekado>the daemon respects the TMPDIR environment variable. <eus>rekado: Ah, I see that now. <rekado>by starting the daemon in an environment in which the TMPDIR variable is set to some location with more space you have the same result as bind mounting. <rekado>but it is unfortunate that this is needed in the first place. <rekado>I'm actually pretty sure that the installer reminds users to run "guix pull" in the motd <quiliro>rekado: perhaps the installer can check the available space and do what is needed...what do you think? <eus>quiliro: Perhaps in the future after guix is more mature. <rekado>quiliro: the installer is very primitive at the moment. <eus>quiliro: Currently the status is alpha according to the website. <rekado>to even call it an "installer" is perhaps a little too much <quiliro>rekado: i have just checked the manual and it does not sugest guix pull <rekado>it's a minimal GuixSD system with a shell. <atheia>2¢: yeah, Ludo suggested the fix should be that hydra holds on to release substitutes. <atheia>Which in my mind makes sense, because that should be a stable starting point. <atheia>That would avoid having people having to do guix pull before they start the installation… <rekado>quiliro: yeah, I saw that it's suggested only for "guix system reconfigure", but I was under the impression that the motd included a reminder. <quiliro>rekado: you mean...every time a user logs in? <quiliro>i guess i should help with that instead of suggestin... <eus>atheia: Frankly I prefer the hard way of "guix pull" rather than sticking to some stable release point in the past ;) <eus>quiliro: What other GNU/Linux distributions have you ever used before trying Guix? <davexunit>eus: it's safest to use a stable release first to initialize the system, and then upgrade after. <quiliro>so in my personal manual i have added mkdir /mnt/tmp2 && umount /tmp && mount --bind /mnt/tmp2 /tmp <eus>davexunit: Yes, of course, from the QA perspective. <quiliro>eus: parabola, trisquel, ututo, and before that ubuntu, redhat, <eus>quiliro: Plenty already. And, ututo is also source build, isn't it? Gentoo derivative? <quiliro>not a gentoo derivative it is like guixsd <atheia>Also, in theory, from a newbie experience: Normally a stable release guarantees a usable system -> a newbie will not be faced with some substitute not being available for their architecture or some such. <eus>atheia: I second that pretty much. <eus>quiliro: When you wrote "not a gentoo derivative it is like guixsd", what kind of difference do you have in mind? <quiliro>i think that it would be better to have a live guixsd released every week so that guix pull would not be necesary <quiliro>if it is a good idea, i can teach myself to take on that job <eus>quiliro: Won't the QA effort be too great? <quiliro>a gentoo derivative would use emerge <quiliro>ututo has its own package manager: uget <eus>quiliro: Ah, okay. So, ututo is also source-based, right? <quiliro>eus: maybe the packages were built with emerge and uget installed the binaries so maybe you are right...but i am not sure anymore...do not remember <eus>quiliro: I checked the site the other day. But, it has no English. <quiliro>eus: the QA will not be as great as the effort of the newbies that cannot install...or do you differ? <quiliro>eus: oh...that is right it is in spanish <eus>quiliro: It is because QA should be done with as many different computers as possible. <quiliro>eus: what would that affect having a weekly live? <eus>quiliro: So, I think the QA level might not be enough if you are only doing it with your own one or two computers. <quiliro>eus: but if there is an weekly live then more peaple will not have problems testing because it would be a working live <eus>quiliro: Yes, we can give it a try if you can do it. <eus>I am leaving now everyone. See you all again! <quiliro>i do not mean to press but i want to do useful work and not use my time uselessly <efraim>"here's the official release image and there's the unofficial monthly image" <sneek>quiliro, you have 1 message. <quiliro>sneek: later tell eus ututo.org is full of spam now <quiliro>guix system init /mnt/etc/light-desktop.scm /mnt <quiliro>guix system init /mnt/etc/light-desktop.scm /mnt --fallback <atheia>quiliro, so this is after guix pull? <atheia>and you have double-checked that you have a working and resolving internet connections <Gamayun>quiliro: Running the same here.. Fingers crossed ;) <quiliro>then: guix system init /mnt/etc/light-desktop.scm /mnt <quiliro>but that gave me a compilation error <quiliro>then i typed: guix system init /mnt/etc/light-desktop.scm /mnt --fallback <rekado>quiliro: compilation error for what package? <quiliro>now the last command is still compiling from hours ago <davexunit>quiliro: you should really aim for installing a more minimal system first <davexunit>also, if you are building emacs from source after getting the latest guix then you have done something very wrong <quiliro>i don't understand why it is compiling when i did guix pull <rekado>quiliro: is it downloading *any* binaries? <rekado>does it say anything before compiling? <rekado>it should tell you why it’s doing this <quiliro>rekado: don't know...have not seen any downloads <lfam>It had to have downloaded the source tarballs at least <rekado>it’s going to take time to compile everything from source <rekado>there are two things I can think of that cause it to compile from source. <rekado>1) no connection to the internet <lfam>3) Substitutes not available for these derivations <alezost>quiliro: try "guix system build --dry-run /mnt/etc/light-desktop.scm" at first and see its output <quiliro> substitute: updating list of substitutes fromm ..... <quiliro>that was the package it was working on before ctrl+c <alezost>quiliro: I think I get another idea (to what rekado said): you run "guix pull" as user and run "guix system ..." as root, so the root doesn't use the latest guix code <quiliro>configure: creatiting ./config.status <quiliro>because there are no ther users in the live guixsd <alezost>quiliro: break it for now, try "guix system build --dry-run --no-grafts /mnt/etc/light-desktop.scm" and tell what it is going to build and what to download <quiliro> by the way it is lightweight-desktop.scm <alezost>quiliro: could you tell what it displayed (what would be built/downloaded)? <alezost>could you tell what was the exact output of that "guix system build" command? <quiliro>last one is /gnu/store/...-sane-backends-1.0.24 <quiliro>alezost: i can see the whole screen covered with different packages <alezost>yes, the question is: are these packages going to be downloaded or built. You can pipe that command to see its full output: "guix system build --dry-run --no-grafts /mnt/etc/lightweight-desktop.scm | less" <alezost>pay attention to the messages like this: "The following file would be downloaded" <quiliro>pg dw or page up show a black screen with the word end at the bottom <alezost>hm, I think "... &> /tmp/guix-output" should work; and then look at that file <quiliro>13 pg up screens show a lot of the messages i mentioned earlier <alezost>quiliro: please, answer the question: are the listed package "would be downloaded" or "would be built"? <quiliro>alezost: the following deerivations will be built <alezost>if most packages would be built, it means something is wrong on your side. If only several packages would be built (and most downloaded) then it's likely that hydra doesn't have these substitutes <quiliro>the following files will be downloaded <alezost>ok, 2 pages of packages to build is a lot I think <alezost>can you name a couple of packages that will be built? <lfam>Many of those are just configuration files <lfam>So, they are trivial to build and should only take 1 or 2 seconds <lfam>I'm trying a dry-run system build of master now, to see what is available <lfam>quiliro: Yes, they are just configuration files that go in /etc <alezost>quiliro: I've tried "guix build --dry-run --no-grafts slim" and it said it would be downloaded. Could you try this command? <quiliro>alezost: guix build or guix system build? <alezost>quiliro: "guix build --dry-run --no-grafts slim" <lfam>I think that grafted derivations show up in "to be built", even though they are just going to be grafted. <alezost>lfam: btw what does "guix build --dry-run --no-grafts slim" produce for you? <lfam>That's master from sometime today <lfam>alezost: "will be downloaded: /gnu/store/91rzngsakwqkdn2w4cj7kk4bnk0js7q8-slim-1.3.6 \\n /gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1" <quiliro>the following file will be downloaded <lfam>So, sudo and xmonad must be built, based on my test. <lfam>Is xmonad really "lightweight"? I've never tried it, but I thought that Haskell was an expensive thing to build <lfam>I think that everything else "to be built" in my test is not a real package but some configuration file or wrapper <alezost>quiliro: my conclusion: you set it up correctly, the problem is: hydra doesn't contain some substitutes (including libsoup) :-) <alezost>quiliro: I recommend to build some really minimal system (bare-bones) for "guix system init", and after you'll boot into it, you can try something more complex with "guix system reconfigure" <davexunit>alezost: I've mentioned that several times but it's ignored each time. <alezost>quiliro: I never use --fallback as I don't like building software :-) <quiliro>/gnu/store/20kwgqmm377mcxxfzgk8jgijbr806xpk-parted-3.2.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source <alezost>quiliro: I usuall rerun the command when I see it <alezost>quiliro: no, no, no; I didn't told you that! <alezost>I told that I never use --fallback, but I didn't told it's the right way. And I think davexunit didn't tell either <alezost>quiliro: try to rerun your command. It may be a temporary networking (hydra) issue <alezost>btw what command are you running now? <quiliro>i am even more confused...are you telling me that it is not advisable to use it but use it when there are no substitutes? <quiliro>guix system init /mnt/etc/bare-bones.scm /mnt --fallback <alezost>I mean that it is not suitable for me: I prefer to download substitutes from hydra; but if you don't mind building some stuff, you can use --fallback. <quiliro>but it will not if i do not use --fallback <alezost>quiliro: here is what I would do: at first I would try --dry-run to see what would be built/downloaded, then I would decide if building is suitable for me or not <bavier>just found a bit of nonfree source in a maths package, when I remove the source, do I also remove the mention in the license.txt file? <alezost>quiliro: try to build bare-bones again without --fallback. Does it still failed on parted? <efraim>my lightweight os config i made for testing connman had openbox, xterm and connman, and %desktop-services <alezost>wow, my heavy-weight config doesn't contain %desktop-services :-) <quiliro>bavier: yes because the nonfree license covers only the nonfree software <quiliro>it will not need it when it is not included <quiliro>unless there is more nonfree software <quiliro>and i can see gcc compiling some packages <alezost>quiliro: ok, to make it clear: hydra often does not provide substitutes for the latest packages (because they have not been built yet). It's your choice to decide if you will build them locally or not. (I usually prefer to wait until hydra build what I need) <quiliro>alezost: i choose to use the substitutes for all packages even if there are new packages that have no substitutes <quiliro>but i do not understand why it is compiling if i do not use --fallbaack <bavier>quiliro: --fallback only affects the case where a substitute is available but fails to download for some reason <alezost>quiliro: because hydra does not provide substitutes for something. <adfeno>... And when it comes to: start guix-daemon <alezost>quiliro: as I said at first I look at "guix system --dry-run ..." to see what will be built <adfeno>... The current terminal stays busy. <alezost>adfeno: yes, it is expected: guix-daemon is a deamon <davexunit>I feel like the manual needs to mention this explicitly <davexunit>so many people come in here confused about it <adfeno>Oh... I always associated daemon with background process. :D <davexunit>it's obvious to me, but other people just don't get it. <alezost>actually I also expect from daemons to fork by default. Such programs usually provide --no-daemon option <quiliro>alezost: dry-run will tell me what needs to be built...it will not build it on the server <quiliro>i rather build...it will be less time <quiliro>it will fail if there is a network problem when i leave it for the night <quiliro>how can i make the process repeat if it stops for network and to rerun dhclient too if necessary <quiliro>otherwise i have to be here always and spend sever days installing a bare-bones installation <adfeno>Another question, I'm trying to install Guix on Trisquel, and after doing: guix archive --authorize < "/root/.guix-profile/share/guix/hydra.gnu.org.pub" <adfeno>... It says: warning: failed to install locale: Invalid argument <efraim>sneek: later tell ng0 I think qtdeclarative has qtquick and qml <bavier>adfeno: see the section title "Locales" in the manual <adfeno>But... Did it authorize the substitutes from Hydra already? <adfeno>Or, did it just ignore what I told it to do? <alezost>adfeno: it probably authorized; check if /etc/guix/acl exists <adfeno>It does accept the substitutes now. :D <alezost>adfeno: the locale warning is harmless (I think), you can ignore it <alezost>Gamayun: lucky you :-) Is it after "reconfigure" or "init"? <adfeno>Well... I guess so, although it can make things somewhat difficult for those who don't speak the native language of the packages. <adfeno>Or which don't have the US keyboard layout. <alezost>quiliro: I really hope it will not take several days. <adfeno>Oh my... I just installed glibc-locales as root... <adfeno>... I just hope other users can also use it. <Gamayun>alezost: "init" ... bare-bones.scm even <lfam>adfeno: Every user has their own packages, even root. Root's packages can't be used by other users. <lfam>adfeno: Does Trisquel use systemd? <adfeno>Mostly uses init and Upstart, has only one small part of it from systemd. <quiliro>i don't know about trisquel some time ago <lfam>adfeno: How do you run the guix-daemon? With init, Upstart, or sytemd? <adfeno>I have followed the instrunctions for Upstart, that is, doing: start guix-daemon <quiliro>i think the manual shoul not suggest to use desktop.scm or lightweight-desktop.scm <lfam>I never used Upstart, so I don't know how to set environment variables for systemd services. But, you can try setting GUIX_LOCPATH with Upstart somehow <lfam>I mean, "I never used Upstart, so I don't know how to set environment variables for Upstart services." <adfeno>I think I can look out for documentation related to that... <adfeno>(don't worry, I'm not systemd-hater) :D <lfam>quiliro: Does the manual suggest to use desktop.scm or lightweight-desktop.scm? <adfeno>(Oh, lfam just closed the tab by misstake I guess) <lfam>Yes, I quit my IRC client by accident. What did I miss? <quiliro>but as you say use bar-bones.scm and then guix system upgrade <adfeno>Most people say systemd's not modular, or say that it's an initialization system, that it reads binary configuration, and such and such... Most of these were proven not to be that way. <lfam>quiliro: That's what I do. It's faster and more reliable to start with bare-bones. <lfam>adfeno: People said a lot of things about it. I like that I can do unprivileged services as a user, and I like the logging system. <quiliro>lfam: they talk about monopoly by redhat <quiliro>read the spacefm developer's blog about systemd <lfam>I also like how simple the services files are compared to sysvinit shell scripts — you don't need to be an experienced Unix or GNU / Linux person to write them. <adfeno>As for the guix-daemon Upstart service, I'm reading some answers that say that one can simply use the export command as one does normally. <lfam>I'm not surprised that all the major distros decided to use it. And, by making the switch, they are more prepared to switch again if Red Hat does something terrible, although I don't really see a danger there. <quiliro>lfam: the manual sugest so in "proceeeding with installation", section 7.1.4 <lfam>On the other hand, we are using our own init / service manager, the Shepherd, so we are blissfully free of this debate :) <quiliro>adfeno: yes...he says red hat is trying to control everything <adfeno>mode="joke"; Oh... Shepherd... Rail the Shepherd.; mode="normal" <adfeno>quiliro: Can you point me to that publication? <quiliro>it is too difficult for me without a browser <lfam>quiliro: Yes, I see it. It's not a strong suggestion, but I can see how a person might think they had to follow the instructions verbatim. <quiliro>just make a web search for spacefm+blog+spacefm <adfeno>quiliro: Oh... I see... sorry for not paying attention to your case. <quiliro>i think it is rather he sees something other dev see <quiliro>but the ones that don't mind adapting pass <adfeno>On guix-daemon Upstart service file again... <adfeno>... Now I see a possible issue: The part which talks about export the specific locale variable for Guix uses $HOME inside... when evaluated by guix-daemon, will it take $HOME as "/root"? Or as "/home/user"? <lfam>It should be root, since root runs the guix-daemon <adfeno>I guess I'll just follow the guide then. I'm not really an exploring type of sysadmin. :D <adfeno>(Actually, I'm not really a sysadmin, I'm only good at marketing, public relations and organization management) <alezost>Gamayun: could you please mail to bug-guix@gnu.org with your config and the kernel panic reason (backtrace or error message or whatever) <adfeno>When doing: guix package -i font-gnu-freefont-ttf <adfeno>... It doesn't downlaod this font. <adfeno>All the others (gs-fonts and the dejavu one are downloaded normally). <lfam>adfeno: It works for me. How does it fail for you? <lfam>Why wouldn't you be able to do `guix pull`? <adfeno>I mean, for those using Guix on a foreign operating system, is it safe? (in the sense so as to avoid guix replacing some part of the host system)? <lfam>`guix pull` will update the Guix code and the package definitions to the latest. Yes, it's always safe to do, on GuixSD or on another distro <lfam>You should do it regularly or you will not get security updates <lfam>You must do `guix pull` and then `guix package --upgrade` for any package that you want to upgrade, or for all packages. <lfam>adfeno: I should clarify. `guix package --upgrade` will upgrade packages you have already installed. <adfeno>Now I see what you mean, thank you very much :D <adfeno>And the font was downloaded now. :D <adfeno>Let's see... A package that I don't have in Trisquel, that would be interesting to try... <adfeno>Hm... It seems Guix still shows that locale warning...