<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>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.
<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).
<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
<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.
<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)"
<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.
<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
<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?
<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
<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.