<quiliro>Hello...I wanted to make a presentation for Emacsconf by showing my Emacs keypresses. I was suggested to install key-mon. I found it exists asa a Guix package. So i installed it successfully. But I cannot open it. Would anyone care to test please?
<apteryx>more trouble with probing btrfs subvolumes: the partition needs to be mounted for it to succeed... We could attempt to mount it ourselves, but then, what if it's sitting on an encrypted LUKS block? That would ask for a password... and it's complex.
<apteryx>So I think to refrain from any *live* probing is a more sane choice for Guix and Btrfs submodules. It can do something basic that'll support 90% of use cases, and allow for declaring more complex scenarios in tho operating-system config for those users.
<nckx>You say this like they've been gone a while. They AFAICT haven't. OK.
<efraim>efl update needs a bunch of massaging, they switched from autotools to meson
<nckx>civodul: (Still) -ECANNOTREPRODUCE as I noted here on the 27th. I can ssh into both of them. Slowly, but that could just be the café wi-fi. Could you explain what exactly I should be looking for?
<Chiliparrot>Hi there! I'm playing with guix in a VM and have been waiting for a "system reconfigure" form more than a day to finish :-(
<Chiliparrot>Is there a simple way to pin the version of the kernel? Apparently, building is responsible for the delay, and I don't care about the kernel version
<nckx>They *are* both idle, but I can't berlin to find out why.
<nckx>Chiliparrot: That won't keep your kernel from being rebuilt when a dependency changes. And linux-libre was updated to 5.2 quite some time ago (a week? seems like a month :), substitutes would have been built by now.
<Chiliparrot>Mh, maybe just bad luck with the timing... just restarted the process, wish me luck ;-)
<efraim>efl-1.23.0 wants a bunch more propagated-inputs :/
<Chiliparrot>nckx now guix fetched llvm and is building xf86-video-vesa... but I'm coming from Gentoo, so I'm used to wait ;-)
<roptat>nckx, maybe it changed IP and berlin cannot access them anymore because of the firewall? It happened to mine once
<nckx>roptat: That's happened (my main ‘home server’ is off-line longer that expected due to RAID drive warranty issues, and it handled the DDNS which I now do by hand like an ape-man). But that's not the case now.
<nckx>roptat: dmitri.tobias.gr:5552 / sergei.tobias.gr:5551 — they should both resolve and listen to the Internet.
<roptat>I mean the firewall at the MDC only allows connections on a set of IPs, so if the IP linked to your domain changed, berlin cannot reach it
<roptat>I think (commit "commit n°"), but I don't find it in the manual anymore...
<roptat>yes, looking at the code, commit should work
<nckx>roptat: Possible, but ‘weirdness’ still happened on ext4 (which both my Overdrives now use). I run multiple Guix Systems on different btrfs configurations, all work fine. But of course none of those have been borged from Suse.
<roptat>ok, well I hope I can fix this and my internet quickly
<nckx>I mean, it's possible that SUSE was to blame, it just doesn't seem likely and I don't want to be quoted as such 🙂
<nckx>jonsger: It wasn't, and unfortunately (in hindsight) I was too focused on getting these machines up and not on fixing the issue. I changed far too many variables at once, then suddenly it worked.
<nckx>If not, you should look into how to make ‘sudo’ call your *user's* guix, not root's. ‘sudo -E’ usually does the trick although IIRC there's some gotcha on Ubuntu.
<nckx>root's Guix is only used for the daemon launched on non-Guix systems. You can edit /etc/systemd/system/guix-daemon.service to change that. I always change it to /var/guix/profiles/per-user/nckx/current-guix/bin/guix-daemon and never pull as root. Otherwise, you should pull as root once in a while to keep your daemon relatively up to date, but it's not as important.
<nckx>AFAIK all CVEs in the daemon are currently undiscovered 🙂
<desmes>nckx: I see. But If 'guix pull' updates the distribution only for the user who ran it, if I never run 'sudo guix pull', the root user will never have an updated distribution, will he? His guix tools and packages source code (for guix package) will be outdated.
<nckx>desmes: Root is ‘just another user’ on Guix.
<nckx>So it only matter if ‘root’ does things on their own. Which, on most single-user systems, isn't the case: you admin using sudo, not by logging in as root. I'm being vague because everybody does things slightly differently (roptat not using sudo‽ burn the wizard!).
<roptat>desmes, sudo guix system reconfigure should use the user's distribution, not root's, and then root's distribution is the one installed with the operating system (so it's also updated, but a different pace)
<nckx>Root will not even have their own profile, they'll only ‘see’ the packages installed system-wide from your system.scm. Which are kept up-to-date when you reconfigure. As a regular user 😛 OK, I can understand how this can be confusing.
<bricewge>grumbel: Thanks, it continue building now. Any idea on the source of the issue?
<roptat>now I'm not sure it's actually the case, I'm very confused by sudo
<roptat>that /etc/config.scm declares an operating system that is built by your current guix, so it uses packages in that guix version
<roptat>if you're not careful and use the system's guix, you'll be using the guix recipe from the system's guix, which is necessarily older than the current system guix (we can't guess git commit hash in advance ;)), so you'll downgrade your system
<roptat>that's why guix pull is so special and separate from your current guix: it's to prevent a downgrade
<roptat>now if you use "sudo guix system reconfigure", you should be using the user's guix installation in .config, so you shouldn't have any issues
<nckx>Or if that was a ‘tf is that’ question: it's a little (Guix-packaged) daemon that claims to generate some randomness from CPU jitter. I don't trust it enough to run it on, say, SSH/GPG-key generating machines, but it's nice for systems that have no external entropy source otherwise. It's an alternative to trusting RDRAND.
<Chiliparrot>Interesting point, bandali... I've seen systemd-dependency issues before (Funtoo has never used the old init system, and they want to stick with their solution); how big is this problem with shepherd?
<nckx>bandali: Not that I care about Gnome, but I'm going to hide under a strong rock for the week that that's announced ;-)
<Minall>Using guix pull will update the packages but permanently?
<nckx>Minall: It will update the packages *available* to ‘guix install’ and ‘guix system …’. It's persistent, yes, but not permanent in the sense that you can always ‘update’ to an older commit with ‘guix pull --commit=…’.
<nckx>Sigh. I'm going to have to create a ‘vanilla Guix VM’ soon for helping folks on IRC vs. ‘guix as she is used by nckx’ (git all the things, fork all the stuff)…
<Minall>I mean, If i do a guix pull, and then shutdown, do I have to make another guix pull?, or does it saves even if I don't reconfigure in that session?
<nckx>Minall: Yes, that's what persistent means. Guix wouldn't be very useful if it forgot about all its packages when you reboot.
<apteryx>do we currently validate at reconfigure time that a file system label exists, or other similar checks?
<guixmike>hello all, I have installed the binary installation of guix twice now and have run into a problem. Everytime I try to "guix install glibc-locales", the build process stops at libelf-0.8.13 with hash mismatch
<bavier>chez's bootstrapping is currently via bunch of binaries
<bavier>huh, even provides a "fibers" library based on wingo's
<desmes>How come I can't use Emacs as my WM? I have a very simple configuration, like the one in the documentation: https://paste.debian.net/1103759/. I aalso have EXWM inside Emacs' elpa folder (and this same Emacs config works flawlessly as my WM in Arch Linux).
<desmes>When I log in in the display manager nothing happens, I just have to login again, and again, etc.
<desmes>I guess it's not using my ~/.emacs.d config?
<Minall>What application can I install in order to use Matrix?
<g_bor>sirmacik: I've checked my config on the sway machine. The only thing I have in the config.scm is elogind-service and %base-services that relates to sway. Sway is installed in my user profile, and I start it from the command line.
<g_bor[m]>sneek: later tell sirmacik I've checked my config on the sway machine. The only thing I have in the config.scm is elogind-service and %base-services that relates to sway. Sway is installed in my user profile, and I start it from the command line.