<malaclyps>when I do "guix system reconfigure foo.scm", what user should I be? I've been doing "sudo guix system reconfigure /home/malaclyps/system.scm", but should i precede that with "sudo guix pull; sudo guix package -u"? Will a simple sudo refer to the right installation, or will my user environment variables screw it up?
<malaclyps>I'm muddling through right now, but I'm never confident I'm doing it correctly.
<leoprikler>After your first `guix pull` as user and logging into a new shell, everything should work just fine
<leoprikler>Guix is nice enough to tell you what to do, though.
<guix-vits>malaclyps: sometimes you'll need to log off and log in (like with a gcc-toolchain package), or reboot (Kernel updates).
<malaclyps>Blackbeard, I'm using the Guix system (ie just Guix, no underlying distribution) now
<malaclyps>well my current PATH is /home/malaclyps/.local/bin:/run/setuid-programs:/home/malaclyps/.config/guix/current/bin:/home/malaclyps/.guix-profile/bin:/home/malaclyps/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin
<malaclyps>I'm not sure of the difference between all of those
<Blackbeard>malaclyps: yes sorry, for a second I got distracted and your mention about the guix binary made me think of the binary for other distributions
<malaclyps>I guess (filter (lambda (x) (access? x X_OK)) (map (lambda (x) (string-append x "/guix")) (string-split (getenv "PATH") #\:))) indicates there's a system guix, and a user guix ... maybe I don't even need the user installation?
<nckx>malaclyps: What do ‘guix’ and ‘installation’ mean in that sentence?
<nckx>Some truths: - you should never guix pull on Guix System unless you're doing special things and know why; - you should never ‘install guix’ with ‘guix install’.
<nckx>Shit. s/never guix pull/never guix pull AS ROOT/ of course.
<malaclyps>what's the deal with using installing guix as the root user on non-Guix System distributions? Is that just to bootstrap matters, or should you keep that root guix profile updated and upgraded?
<malaclyps>nckx, to answer your questions, I guess I meant 'guix' == the binary, and installation == copy of that binary in a user or system directory. Here's the result of that scheme fragment on my machine: https://pastebin.com/FadG2Bd9
<nckx>Blackbeard: Shepherd doesn't ‘create root’. When Guix System boots, an activation service does create user entries in /etc/passwd &c., including root's. But that's just a name tag. The actual user called root (UID 0) is a concept built into the kernel, it exists from the start.
<nckx>There's no chicken & egg if that's what you mean.
<malaclyps>and I guess I'm trying to understand what the difference between all those execution paths are. I have two copies, apparently, of the guix binary (I don't have guix installed with "guix install") -- does it matter which one is used? Why are they both available?
<nckx>malaclyps: Describing /run/current-system/profile/bin/guix as a read-only bootstrap guix (so you can ‘guix pull’ and create your per-user, writable /home/malaclyps/.config/guix/current/bin/guix) makes sense.
<nckx>malaclyps: 's Why I often ask things like ‘what do you mean by installed?’. With traditional distros, installed == files on disc and files on disc == installed. With Guix, not at all. I think Guix's separation makes perfect sense but it takes a while to unlearn the simplism.
<davidl>Im trying to build guix but Im failing the make check stage for a number of tests: builders, build-utils, challenge, channels, containers, cpan, cran and debug-link for commit 6e003bd4ccd7470247b1fdbee3a6c6a0ad8054ac. I was just trying to build it to use ./pre-inst-env guix build some-package to contribute, and not sure if it's important that these tests PASS or not when just contributing some packages?
<rekado_>hmm, getting ‘connection refused’ trying to fetch from git.savannah.gnu.org
<gagbo>Hello, do I need to do the FSF contributor thing to propose a package for guix ? I just built a few guile 3.0 derivations of packages I use and I wonder how I can get guix pull / guix package -u to automatically update those
<guix-vits>gagbo: anyone can contribute. Contributions are reviewed by crew :)
<oliverp_>without sI don't there this an overstatement that an improvement (and more feature complete) shepherd is very exciting promise and something which I assume would prove to be quite beneficial for guix (and gnu in generel)
<abralek>rekado_: hm I had to install guile on the remote and it looks better now
<mbakke>jsoo: I switched away from the (defunct) git repo to the official releases
<mroh>json: maybe, one of the emacs packages you use misses the /bin/sh substitution we have for lots of emacs-packages. maybe try something like `ag "/bin/sh" /gnu/store/*emacs*` to find it... have you tried dumping w/o magit (as the missing /bin/sh seems to happen there)?
<apteryx>that search-path should just set the var to lib/NetworkManager/VPN, I think, because: /gnu/store/wxgraqcr3rx6ws4y4k1gwh9cdw892mha-network-manager-openvpn-1.8.10/lib/NetworkManager/VPN/nm-openvpn-service.name
<bricewge>Does someone already tried to send a patch series with `git send-email` in one go with the `--no-chain-reply-to`?
<bricewge>I was fumbling in the git manual and the debbugs usage page and for what I understand it would allow us to avoid waiting for the debbugs bug number
<apteryx>about search-paths; why do we usually encounter them as 'native-search-paths' rather than just 'search-paths' (twice as many hits grepping) ?
<apteryx>IIRC, native-search-paths will set the path both at build time and run time, because the default value for the search-paths is native-search-paths. But in my case (and the case of any plugins) I think it doesn't make sense to use native-search-paths :-)
<apteryx>I tried to debug network-manager-openvpn plugin as instructed here: https://wiki.gnome.org/Projects/NetworkManager/Debugging, but I get: nm-openvpn <warn> Failed to initialize a plugin instance: Connection ":1.331" is not allowed to own the service "org.freedesktop.NetworkManager.openvpn" due to security policies in the configuration file. Ideas?
<apteryx>Ah! I had to restart the dbus-session service.
<apteryx>Strange that reconfiguring my system didn't take care of that alone -- perhaps a dependency missing.
<apteryx>well, now in syslog, I see: result="fail" reason="The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed." upon trying to up my openvpn connection with nmcli. Hmm.
<apteryx>I see this kind of error in dbus-monitor, seemingly related to policy-kit: error_name=org.freedesktop.DBus.Error.AccessDenied on the interface interface="org.freedesktop.PolicyKit1.Authority.
<apteryx>(what I did was: 1) reconfigure after modifying my network-manager-service-type to add the network-manager-openvpn plugin to its config 2) test 3) sudo herd restart networking 4) test 5) sudo herd restart dbus-session 6) test)
<apteryx>civodul: when a services extends another one (such as network-manager extending dbus), is the extended service restarted upon reconfiguring?
<apteryx>It seems recently things improved (used to be that nothing would be restarted, IIRC), but that's not true for everything IIUC.
<guix-vits>someone possibly should update the online Manual: in info i'm just read: "only supports ext4, btrfs, and JFS file systems." While online version only mention ext4 and btrfs.
<civodul>apteryx: what gets restarted has nothing to do with extensions
<civodul>quoth the manual: reconfigure "starts system services specified in FILE that are not currently running; if a service is currently running this command will arrange for it to be upgraded the next time it is stopped (e.g. by ‘herd stop X’ or ‘herd restart X’)."
<civodul>in general, you wouldn't want reconfigure to unilaterally restart your running X or SSH server :-)
<apteryx>I'm asking this in the context of booting from NFS. I'm still pretty naive about the subject, so the question might not make sense (perhaps GRUB should be network aware for a NFS boot to work).
<vagrantc>i find the updating of the kernel configs tedious and have taken a liking to using the defconfig kernel variants :)
<vagrantc>i should probably remove the arm-veyron config ... it hasn't worked for me for ages and have been using -arm-generic
<vagrantc>and would like to add linux-libre-arm64-generic too
<lfam>Are you using the pinebook pro? Does it feel fast enough for Guix?
<vagrantc>lfam: it seems reasonable, though i haven't yet tested a GUI yet
<vagrantc>mostly just trying to get the kernel and bootloader working out of the box with minimal changes
<lfam>I feel like some of the Guix commands are not that quick even on amd64 so I've avoided all the A53 machines, but the pinebook pro has some A72s, so that is nice
<vagrantc>i find "guix pull" to be useable ... which is debateable on some of the other arm platforms
<vagrantc>yes, the A72 cores make a big difference
<lfam>It was really painful using Cortex A7 a few years ago
<seepel>Hi there, I'm trying to run the light weight window manager system configuration from the manual by using guix system vm, when it opens gdm in qemu I only get a blank screen, does anyone have any hints on how I can debug?
<seepel>I guess while I'm getting bites, I have another question. I'm also trying to fine tune my trackpad settings using the extra-config field of xorg-configuration. What is the fastest way that I can test my changes? Right now I keep rebooting, is there an easier way?
<guix-vits>seepel: try to log-off and go to tty2, and `herd stop gdm` or so, then `herd start` ?
<nckx>lfam: Having gone back to read the history, I should clarify: I *really* appreciate you sticking your neck out to respond and think that it's important to address such misinfo for the benefit of everyone else.
<lfam>It's okay, there are as many opinions and points of view as there are people. It's natural. I hope that eventually Guix takes over the world
<Blackbeard>lfam: because of ungoogled-chromium or something ?
<Blackbeard>That's insane the FSF certification exists for a reason
<lfam>Yeah, that's the main sticking point. They think we did not audit it carefully enough, although I think we audited it extensively
<seepel>The basic idea of guix is that you can pretty much fully specify your system declaratively via a scheme file. Then rather than having to remember and go through a set of imperitive steps to configure the system, it is all defined in one place.