<pkill9>would there be any issues with automatically setting the name of each input of a package to the name of that package, rather than specifying it manually? <pkill9>i suppose it would be more 'magic' where annoying bugs could appear ***jonsger1 is now known as jonsger
***daviid is now known as Guest84731
***catonano_ is now known as catonano
<alextee>is this a known bug? /home/alex/.guix-profile/include/stdio.h:407:24: error: redundant redeclaration of ‘fscanf’ [-Werror=redundant-decls] <alextee>it's defined in stdio.h and sys/cdefs.h <akoppela>I've seen a list of user system configurations somewhere <akoppela>anyone knows where I can find GuixSD configs? <Humanoid>What is the difference between /root/.guix-profile and /root/.config/guix/current ? Are those 2 different profiles? <marusich>Humanoid, yes, they are both profiles but serve a different purpose. /root/.guix-profile is the default profile for the root user. /root/.config/guix/current is the profile which holds the current Guix installation for the root user. <marusich>The /root/.guix-profile is the default profile used for commands like "guix package --install". The /root/.config/guix/current profile is usually not accessed directly via "guix package" commands, but you could do that (e.g., "guix package --list-generations --profile /root/.config/guix/current"). Instead, /root/.config/guix/current is usually manipulated via "guix pull". <Humanoid>Do I have to set the GUIX_PROFILE environment variable before running the daemon? <marusich>I presume you're on a "foreign" distribution? <Humanoid>Is GUIX_PROFILE needed by anything at all? Or is it just a temporary variable used in the installation instructions? <marusich>I don't think you need to set the variable if you just want to run the daemon, for example in a systemd unit file. Generally speaking, some programs might not behave correctly if the environment variables for the profile are not set correctly (via something like "GUIX_PROFILE=/path/to/the/profile; . $GUIX_PROFILE/etc/profile"). <marusich>To "activate" a profile, an easy way to do it is to do "GUIX_PROFILE=/path/to/the/profile; . $GUIX_PROFILE/etc/profile". I believe that's equivalent to running 'eval "$(guix package --search-paths --profile=/path/to/the/profile)"'. It sets environment variables for things in the profile, like PATH. <marusich>However, you can invoke programs directly from a profile without doing that. You can even invoke programs directly from the store, e.g. /gnu/store/.../bin/guix-daemon <marusich>Some programs won't like that, but I think guix-daemon is fine <marusich>The vast majority of programs will work fine even if you invoke it like that. <marusich>"Activating" the profile by setting the environment variables is just a convenient way to make the programs available. And using GUIX_PROFILE is just a convenient way to "activate" the profile, which really means just setting some environment variables. <Humanoid>How does a program from one package, know where to find the correct library if that library is in a different package? Does it look in the current profile? <marusich>Great question. If the program is an ELF executable, like C-based programs, then Guix embeds the path of the libraries in the rpath section of the ELF executable. <marusich>When the loader loads the executable, it will refer to the rpath to find the libraries - and it will find entries like /gnu/store/.../my-lib.so or whatever, and those in turn are ELF files with embedded rpaths, so it works recursively. <Humanoid>Ah, so the current profile is not needed for that. <marusich>For other program types, for example interpreted programs like Python or Guile, the usual way it's accomplished is by arranging to wrap the program with a script that sets the necessary environment variables (e.g., PATH, or PYTHONPATH, or GUILE_LOAD_PATH or similar), and then exec the actual program. <Humanoid>So the program will always load the exact same library, as embedded in the ELF executable, regardless of which libraries you have installed in your current profile. <marusich>Guix even modifies the loader so that it does not search in the usual system directories, like it would on a traditional distribution. This is desirable because it avoids accidentally depending upon a library which may exist on your system. <marusich>It's also very non-traditional, and sometimes painful if you are working with binaries that expect to find libraries in their conventional locations. <marusich>But, if you have the source, and if it's packaged in Guix, that is usually not a problem. <Humanoid>What is the correct way to stop the guix-daemon? Do I just "killall guix-daemon" or is there a specific signal, or some command I need to run? <marusich>The upside is that you won't have a situation where it breaks on your system because it accidentally uses a different library, or because the person who build it forgot to specify a dependency which they installed 8 months ago but forgot about, so it just happened to be there bey accident. <marusich>I think you can send it a SIGTERM, like with most processes. If you're using systemd you can just use the usual command to stop the unit, which I think is something like "systemctl stop guix-daemon.service" <marusich>but yeah sigterm is fine as far as I know <marusich>So, killall would be fine, as long as something like systemd doesn't restart it. <marusich>Then yeah, killall or SIGTERM is fine. I think you can also send it SIGINT via Control+C if you're running it in the foreground. <Humanoid>Is it possible to allow all users to use the exact same profile? <Humanoid>I only have 2 users, "root" and myself as a regular user, and I don't want to have to install a package twice every time. <marusich>Sure, that makes sense. You could use your rootly powers to make the "root" profile point to your unprivileged user's profile, for example. <marusich>There is nothing special about the root profile. It's just another user's profile. If you make /root/.guix-profile a symlink that points to /home/alice/.guix-profile, then root will use whatever alice installs. <marusich>I think guix-daemon is installed in ~/.config/guix/current/bin, so you can just start Guix that way <marusich>I'm not sure if you even need a root profile if you just always start it (as root) from the unprivileged user's profile. <Humanoid>Can also make /root/.config/guix a symlink to /home/alice/.config/guix ? <marusich>So, although of course you should test it out first to see if it works, you could probably just delete ~root/.config/guix/current and ~root/.guix-profile and always invoke the programs from ~alice/.config/guix/current and ~alice/.guix-profile instead. <marusich>The symlink is ~/.config/guix/current; ~/.config/guix is just a directory. <Humanoid>There's not going to be a problem with the files in /var/guix/profiles/per-user/<user>/ ? <marusich>If I were on a foreign distro and I wanted to avoid using root's profile at all, I would probably (1) make sure root's profile is empty first, with no remaining generations, and then (2) just leave both the ~/.config/guix/current symlink and the ~/.guix-profile symlink alone, rather than deleting them. <marusich>No, I don't think there would be a problem. My understanding is that the ~/.config/guix/current and ~/.guix-profile symlinks are just conveniences; you could create symlinks anywhere pointing at /var/guix/profiles/per-user/marusich/current-guix and /var/guix/profiles/per-user/marusich/guix-profile and it would work the same. <marusich>But...I still think if your goal is to just use one profile, the safest thing to do is just keep root's profile and Guix installation empty, and always invoke the programs you need from another profile, like your unprivileged user's profile. <marusich>You don't really have to delete the symlinks. <Humanoid>It seems if I run "guix package ..." as root, it will create a new profile in /var/guix/profiles/per-user/root/ and the regular user will not have his profile updated. So I'd have to make sure to always run guix package as the regular user. <marusich>One last thought. Multiple profiles is not necessarily a bad thing. It's probably not a great thing to start with, since it's more complex, but it lets you separate different collections of software into neat sets. For example, you could have a profile dedicated to C development, and another dedicated to media editing programs. Pierre wrote a good blog post explaining more about this here: https://guix.gnu.org/blog/2019/guix-profiles-in-practi <Humanoid>Look good! So I can have my "command line" locale, with all the programs I use on the command line. And a separate locale for some server. This way, when I upgrade a server, it doesn't touch my "command line" locale. <mjsb>Ciao Humanoid :), CI stands for "Continous Integration". <Humanoid>Where do I find the package definitions of the available packages? ***ng0_ is now known as ng0
<zimoun>Hi, the sources of the package gdsl (gnu/packages/datastructures.scm) <zimoun> are now down because gna.org is down (see bug#25913). Therefore, it <zimoun> is built using the source from ci.guix.gnu.org which currently works <zimoun> but it is not really nice. Given a look at Software Heritage, the <zimoun> sources are already inside. However, I do not know how to proceed: <zimoun> replacing the current source by the SWH one. Any advice or pointer? <zimoun>Hi, the sources of the package gdsl (gnu/packages/datastructures.scm) are now down because gna.org is down (see bug#25913). Therefore, it is built using the source from ci.guix.gnu.org which currently works but it is not really nice. Given a look at Software Heritage, the sources are already inside. However, I do not know how to proceed: replacing the current source by the SWH one. Any advice or pointer? Thank you in advance. <leoprikler>I think ci.guix.gnu.org has a higher priority than SWH, so you can pull a current source/substitute without bothering SWH. <zimoun>Yes, the issue is: in the package definition, the URL points to a down server (gna.org). So, now the source/substititue uses ci.guix.gnu.org which is nice. But there is still the issue: the package definition of gdsl use a non-existing anymore source. <leoprikler>Ah, yes. If you can find the URL where it's been moved to (if it has one), that would be nice. <zimoun>leoprikler: AFAIK, it has not been officially moved elsewhere. It can still be reach with archive.org. IMO, there are 3 solutions: 1. move by ourself to Gitlab (or any other public forge); or 2. use archive.org; or 3. use SWH (because it is its aim: provide lost sources). <civodul>zimoun: "guix lint -c archival gdsl" says the source is not on SWH <zimoun>which the same file that is in ci.guix.gnu.org <civodul>but anyway, does gdsl have a new home somewhere? <zimoun>civodul: all the files are in (for those I have checked). By "the archive itself is missing", you mean the .tar.gz, right? Or other? <zimoun>civodul: AFAIL, gdsl does not have new home. I mean after some search I have not found one. <zimoun>I proposed to create a new one, in order to correctly do the dance with SWH and "guix lint -c archival gdsl" will be ok. But I was asking if it is right and/or better to do. :-) <zimoun>Note that guile-dbi is still registered with gna.org. Do you a new home elsewhere? <ng0>zimoun: probably abandoned <ng0>if they haven't surfaced elsewhere <ng0>back then, when whoever created the gna.org thread, I looked at some and I'd just search the Internet for the name, see if something comes up <zimoun>ng0: yes, but our package bwa-pssm depends on and this one is not abandonned. <ng0>if not, see if you have enough interest and time to maintain it <ng0>well software can depend on other software which suddenly becomes unmaintained <ng0>if someone somewhere, someplace, sometime, has enough interest it will be picked up again <zimoun>ng0: yes. That's why I was asking about SWH, which is one of its aim. <zimoun>ng0: To be honest, I do not mind so much about the package gdsl -- I did not know about it 4 days ago. I just want to find the right solution to close the bug #25913 (that you openned :-)) <ng0>it's now 3 years open? <zimoun>ng0: 2 years, 36 weeks, 6 days ;-) <zimoun>It remains 2 packages: gdsl and guile-dbi. <civodul>zimoun: what i meant is that gdsl-1.8.tar.gz is missing from SWH <civodul>but guile-dbi-2.1.6.tar.gz is probably lost, except on our servers <zimoun>civodul: I propose to do the same for gdsl. <roptat>civodul, is there a way to save these tarballs on SWH? <zimoun>maybe we can pull request for guile-dbi-2.1.6.tar.gz <zimoun>roptat: it is work in progress (by lewo from Nix) <roptat>so that they don't disappear forever if they are removed from our servers (if we gc them, or we disappear)? <civodul>but lewo (of NixOS fame) is working on code that will allow SWH itself to grab the source we refer to <zimoun>civodul: yes, and is it not enough? From our perspective? <efraim>Has one checked fossies or debian or archive.org? <zimoun>efraim: fossies? "aptitude search gdsl" returns nothing on my Debian stable. Yes, it is on archive.org <brendyyn>Does this work for anyone else in Icecat? <akoppela>I did not find Vagrant and VirtualBox packages on Guix. I'm totally new to Guix and to Linux overall but I like both. I'm not sure I'm ready to write those packages myself because they seem to be complex. What could be the best way to get those packages to Guix? <pinoaffe>brendyyn: doesn't work for me on GNU IceCat 68.2.0esr ***jonsger1 is now known as jonsger
<pinoaffe>brendyyn: for me, the majority of multimedia players do not work in icecat on guix <pinoaffe>before the recent update of icecat, some that don't work no more used to display video but would have *really* distorted audio <brendyyn>I want to start a blog and post videos so i though peertube would be good <roptat>indeed, we don't have VirtualBox. I tried to package it, but it's really hard, as it requires an exotic build system <roptat>I don't know about Vagrant, but we have virtmanager, which I use now since I can't use vb <roptat>pinoaffe, brendyyn I can confirm the current version of Icecat can play much less audio / video than icecat 60 <roptat>although I don't know what's wrong <brendyyn>I see. I already upgraded to the beta version 68. probably its not safe to downgrade now and ruin my profile <brendyyn>roptat: i though virtualbox required a proprietary compiler for some vector math or something like that, from memory <civodul>zimoun: yeah you're right, with what lewo has been working on, we should have complete coverage <roptat>brendyyn, ah maybe? I don't know <civodul>brendyyn: yup my understanding is that VirtualBox requires a proprietary compiler for some of its stuff <roptat>ok, so I shouldn't put too much effort into building it then, thanks for the info! <fps>hm, i wonder (again, i think) why having texlive-latex-amsmath as input (alongside texlive-tiny and others) results in amssymb.sty not being found <dutchie>/gnu/store/z25x8xigqbqivbgccrirnbbj91l32rqr-texlive-latex-amsmath-49435/share/texmf-dist/tex/latex/amsmath doesn't contain it <dutchie>only amsbsy.sty amscd.sty amsgen.sty amsmath.sty amsopn.sty amstext.sty amsxtra.sty <fps>using texlive within a package is weird anyways <fps>i commented out my amsmath and amssymb uses. and i stumble over more and more errors <fps>the pdflatex doesn't find all kinds of things even if i add the relevant packages as input <fps>/gnu/store/4bg4waaiy59dqxjjh16ibwhkk0dcznf7-profile/share/texmf-dist/fonts/source/jknappen/ec/ecrm1000.mf <fps>that's in my GUIX_ENVIRONMENT, but pdflatex doesn't pick it up <fps>do i have to use the texlive-union procedure? <fps>hmmm, texlive-union fails.. <civodul>fps: i'd recommend looking at existing packages that use texlive-union <fps>civodul: i'm doing so (in tex.scm). <fps>ok, removing texlive-tiny from the union seeems to have worked. :) <zimoun>what is the "easy" way to download the source of a package? I mean, I am doing "guix build foo -S" then copying/uncompressing the result; which is not handful. Or I am doing "guix build foo --check -K" but even if compiling is often what I want, not always. Why not expose the source field in "guix package --show"? <fps>zimoun: i guess the "easiest" would be to write a small guile program to get the source field of the package <gnutec>I just upgrade my system right now to Linux-libre-5.3.11 (guix pull and sudo -E guix system reconfigure /etc/config.scm). After the reboot, my wireless stop work. I just reboot again. But I remove my USB mouse too. <zimoun>fps: it is not super user friendly ;-) <gnutec>Yes! I always need sudo -E guix system ... to upgrade system. But is work perfect with USB mouse after reboot. <gnutec>Everybody need a gparted to recovery pendrive if needed. But we have to install dosfstools and mtools to create a FAT32 file system. <grumbel>Has anybody managed to use guix on RaspberryPi3? Fails here with "builder for `/gnu/store/8gm5xfmmbbmsbw1d52la4255yhi6wxfw-guix-packages-base.drv' failed due to signal 11 (Segmentation fault)" <roptat>grumbel, could be a memory issue <roptat>do you have substitutes enabled? <roptat>if not, guix pull requires a bit more than 2GB of memory in my experience <grumbel>I think substitudes are already enabled. It's a 1GB machine, so might be that <grumbel>4GB RasyberrpPi4 seems to work for most part <roptat>use the hash with guix pull --commit=<the hash> <roptat>you'll be a few commits behind, but you'll get substitutes, which gets you there more quickly and reliably :) <gnutec>Is this a problem with upgrade system or install packages? You need for step. $ guix install glibc-utf8-locales glibc-locales <gnutec>$ export GUIX_LOCPATH="$HOME/.guix-profile/lib/locales" <gnutec>$ sudo -E guix system reconfigure /etc/config.scm <roptat>if you're having troubles with locales, it's probably because you just updated to a version after the core-updates merge, from a version before it <roptat>in general, you don't need to redefine GUIX_LOCPATH or reinstall gilbc-locales <gnutec>roptat: I need to do that. But it's OK now. <gnutec>I'd like to record my desktop, but don't know how to use simplescreenrecord. <gnutec>"ffmpeg -video_size 1366x768 -framerate 25 -f x11grab -i :0.0 -f pulse -ac 2 -i default Vídeos/test.avi" doesn't work. <pkill9>gnutec: you could use OBS (open broadcaster studio) <gnutec>leoprikler: How I do this with VLC? <leoprikler>I have no idea, I'm not using VLC for recording. <leoprikler>I used your command with :1.0 and another output file inside a `guix environment --ad-hoc ffmpeg` <roptat>ggoes, I think mate-desktop-service-type extends the package set already, so it could also add glib:bin to the set of additional packages it provides to the system profile? <roptat>it should be a fairly simple change <roptat>actually, it would probably be better to change the package that wants to run gio-launch-desktop to embed a store path to it, so guix can record the dependency explicitely ***drrrty is now known as drrty
<gnutec>leoprikler: But without guix environment... I didn't know. Why you use this? <ggoes>roptat: yeah, that sounds the most sensible thing to do. i'm not exactly sure which package needs it, but can take a look tonight. the problem is that out of the box, nothing in the MATE applications menu will launch. it has to be launched through Alt-F2 or a terminal. <civodul>ISTR someone had a fix or a lead for the Babl test failure yesterday, no? <leoprikler>gnutec: I didn't have ffmpeg installed, so I used the env <gnutec>leoprikler: Really? I use guix install ffmpeg. <leoprikler>Then it should even work outside of the env as long as you use the correct $DISPLAY ***apteryx_ is now known as apteryx
<atw>new java packages! thanks Julien! <olivuser>when installing dwm, is a sample config.h file supplied? <amz3>olivuser: ofcourse, otherwise, it would not compile <amz3>olivuser: look at: guix edit dwm <amz3>olivuser: show no particular config.h (patch or whatover) so it must be the default configuration. <amz3>olivuser: I understand better the question, the config.h is not installed. <amz3>olivuser: it rely on config.h found in upstream tarball <amz3>gnutec: I use green recorder in ubuntu <amz3>feels like a friday night ;) <olivuser>amz3, can you tell me how I would alter it if it comes from upstream? I'm trying to alter dwm's configuration and I was told that I have to alter the package definition accordingly ***MightyJoe is now known as cyraxjoe
<amz3>I think i found a bug (or a missing feature) <amz3>olivuser: the basic idea, is to create a package definition that inherit the original dwm and adds a `source`'s `patches` field <amz3>olivuser: the only method I can help you with is by settings up a channel... but other methods might work (like manifest) or guix package --install-from-file=FILE <olivuser>amz3, alright, thats a starter, thanks :) <olivuser>how is it that sddm-service-type is an "unbound variable"? <amz3>olivuser: in what file? what command do you use? <olivuser>I'm trying out alternatives to gdm session manager, and the manual states "sddm-service-type" to be the variable to use if I want sddm <olivuser>amz3, I'm not at dwm currently. I'm altering my operating system declaration, and use (service sddm-service-type) to use sddm instead of gdm <amz3>I am not sure, but usually 'unbound variable' happens because there is a missing import aka. "use-modules" <olivuser>yeah, but I looked up and sddm is part of display-managers.scm which I have bound (otherwise I couldnt have installed/set up dwm) <amz3>./gnu/services/sddm.scm\035: sddm-service-type <amz3>so you will need to add (gnu services sddm) to use sddm-service-type in config.scm <amz3>olivuser: sddm can be installed without its service registred for execution. <olivuser>amz3, is (gnu services) synonymous to (use-service-modules)? <olivuser>that is, do you mean the field in which I also specify things like xorg etc? <amz3>greping through the code of guix, leads me to gnu.scm where use-service-modules is defined. <olivuser>amz3, thanks for your effort. apparently they are, since I was able to successfully start a recofigure :) <olivuser>out of curiosity, do you know how I would have to set up my environment so that guile and mit-scheme can be used by geiser in emacs? <olivuser>I'd love to at least start delving into guix' source code (tooootal greenhorn), but this - admittedly - low barrier of entry prevents me from doing so <amz3>olivuser: I don't use geiser with guile. I only rely on `pk` that print all the arguments and return the last. <amz3>olivuser: I have installed rainbow-delimiters, bm and silversearcher-ag ext in emacs <amz3>olivuser: it is a procedure, try it at the guile REPL <Jalepeno_X>Would guix's ad-hoc containerization prevent the spread of say a ransom wear attack? Could I detonate a ransomware malware on a Guix VM and have it contained within it's container? If so how would I do that, I'm trying to us Guix in computer security research. <amz3>olivuser: I do only guile coding, but do not use geiser. <olivuser>amz3, but how do you use pk? 'pk gnu', for instance, did not work <amz3>olivuser: (pk 'gnu "foobar" 42) <amz3>olivuser: it is like a "print" but it returns the last argument. <amz3>olivuser: that will help. It avoids the need to nest let (a (foobar)) (pk a) (let ...) instead you do something like (let ((a (pk (foobar))) ...) <amz3>better will be something like (let ((a (pk 'foobar (foobar)))) ...) <amz3>Jalepeno_X: container != WM also, even if there might be some security concerns specific to guix, there is also linux-libre kernel concerns also. <amz3>olivuser: the definition of pk can be: (define (pk . args) (display args) (newline) (car (reverse args))) <amz3>I mean to write VM. WM = WindowManager. VM = Virtual Machine. Container usually means linux cgroups and friends. <amz3>maybe there were update in guix containers support. <Jalepeno_X>Oh I thought Guix did "ad-hoc" containerization of programs running in it... <amz3>Jalepeno_X: what is ad-hoc containerization? <Jalepeno_X>I assumed it's where a packaged program runs, but say most of the filesystem is hidden from it and other container like protections. <leoprikler>Jalapeno_X: Guix packages that are installed normally have a full view of the world <leoprikler>However, you /can/ use guix environment in a way that you get a container with less world view. <amz3>Jalepeno_X: there is also two linux-container.scm in guix source code. <leoprikler>btw. if you don't trust the program at all, you want to run this inside an empty subdirectory of /tmp <leoprikler>(so if you spawn a fresh shell, you share your /home/$USER, which is a bad idea) <Jalepeno_X>thank you very much leoprikler, I've written down everything you've advised and will start attempting to apply it asap. <ScaredySquirrel>when I try to get IPv6 addresses and DNS with dhclient -6 enp4s0 it says: RTNETLINK answers: oper/redr <ScaredySquirrel>when it is permitted, ntpd wakes up and prints out IPv6 address stuff but fails <ScaredySquirrel>and my desktop seems to use the same wireless card so that would be another rebuild and another fix on another machine that requires the same fixes <jackhill>Hi Guix! I beleive I've sumbled on another bug related to the root cause of #38163 (gtk+ not having libxrandr as an input). It is fixed on staging. Is there any reason to open a bug about it? <nckx>ScaredySquirrel: Guix doesn't include or support non-free firmware, so ath3k <http://paste.debian.net/plain/1116466> will never be supported unless there's a free version that I don't know about. Most system logs are in /var/log/messages, although the Shepherd doesn't log everything it should yet IIRC. <ScaredySquirrel>Isn't it easy enough to inherit and modify the linux-libre package to include all the non free firmware? <ScaredySquirrel>is discussing how to add the non free firmware non officially in here fine? <nckx>ScaredySquirrel: Perhaps, but that's off-topic for this channel 🙂 <nckx>(I typed that before your last message.) <ScaredySquirrel>this distro and it's Scheme configuration and package management system are a little new to me so it's a little hard to use <nckx>ScaredySquirrel: You add something like %desktop-services to your operating-system's (services …) field. <ScaredySquirrel>I have even (service gnome-desktop-service-type) in there but there is no Xorg <nckx>ScaredySquirrel: There is no openbox service. <nckx>ScaredySquirrel: I'm not able to help you with that non-free stuff, sorry. <nckx>There is no plain Xorg service at the moment, only display managers like slim(-service-type) and gdm(-service-type) that start Xorg for you. <civodul>jackhill: the gtk/libxrandr bug is not fixed on any branch currently <civodul>i guess you could file a bug or reply to the existing one to document the issue you encountered <smithras>civodul: Question, I was reading about Shepherd and was wondering if there was a newer roadmap available than the one from 2013 that's on the website? <reepca>I finally rebooted my laptop and now I can't log in via gdm - I enter my password (made sure it's correct several times), press enter, and after a few moments it boots me back to the account selection screen <vertigo_38>reepca: i yesterday had a similar issue (after adding a new user and trying to login with it, gnome/gdm) -- is the home directory for the user specified in your config.scm? <rockandska>is there anywhere a working "Dockerfile" example please ? <jackhill>civodul: ok, thanks. I think I'll create a new bug and mention the other one. However, at least my problem seems to be fixed in staging. <khimaros[m]>Are there packages which are strongly recommended to install as system packages in GuixSD? My luck with X11/Gnome apps has been hit or miss in terms of assets installed in places my desktop environment (Gnome) recognizes. <reepca>never mind, apparently after a reconfigure first option under the gear button at the password screen was "GNOME" instead of "i3". Of course, I don't have gnome installed or anything, so it would make sense that doesn't work. <reepca>I wonder why the option is even there, though. <apteryx>is it possible to disable the generation of Guix documentation through a configure flag?