IRC channel logs
2026-04-20.log
back to list of logs
<dajole>For some reason nftables fails to start on startup but starts fine when I run `sudo herd start nftables`. No error messages that I can find. Any ideas what might be going on? <ieure>dajole, Is it starting before you connect to your network? <dajole>Hm...I'm not sure. How do I check? It's just a normal `(service nftables-service-type (nftables-configuration (ruleset (local-file "nftables.conf"))))` entry in my config. <ieure>No idea. Presumably it has some kind of error about why it failed to start? <dajole>`sudo herd status nftables` doesn't show anything <dajole>Actually let me restart and double check. <ieure>dajole, Maybe set debug-levels in nftables-configuration? Look in /var/log? <dajole>Nothing in `/var/log` as far as I can tell. I'll try the debug-levels. Thanks! I wonder if it somehow could be connected to WireGuard...hm... <dajole>`/var/log/messages` just says `The following service could not be started in the background: nftables.` <ieure>Okay, probably turning up logging will help. <dajole>Ah, yes, `Error: Interface does not exist`. I'll need to track it down; it doesn't say, but I suspect this is the wg0 interface. Thanks for your help, ieure! <dajole>It looks like many service configurations allow for a `requirement` or `shepherd-requirement` option, but nftables-configuration does not. As far as I can tell, adding it would mostly involve adding the field to `define-configuration/no-serialization nftables-configuration` and then use it in the service definition itself. How do I test whether this actually works locally? <dajole>Ah I guess I could try to just hack together a modified version of the service directly in my config...hm... <ieure>dajole, Shepherd services can have requirements; it looks like `nftables-shepherd-service' doesn't list any. This feels like a problem that might need a general solution, do you want to open an issue? <ieure>dajole, If you wanted to fix this for your configuration, you'd have to duplicate nftables-shepherd-service and modify it to have the correct requirement, then also duplicate nftables-service-type, modifying it to call your modified service. <ieure>dajole, But, I'm not sure this is actually a good idea, since it means you wouldn't have any firewall at all until your tunnel starts. That seems bad. <dajole>Yes, I'll look into opening an issue, currently reading up on that in the manual. <dajole>Hm...you might be right. Perhaps this is best fixed elsewhere. Wireguard has a `post-up` hook. Perhaps that could somehow be used to amend the nftables config... <meatoid>How is everyone doing suspend-to-disk? I found a way by writing to /sys/state but this leaves the system in unlocked and in sudo -i on wake, which is no good <meatoid>On other systems it seems this is done via a systemd command <switchy>(which is kind of just doing it the systemd way) <YARs2>Wait.. .home doesn't work on farign distros? <bdunahu>meatoid: it is probably `loginctl hibernate`, but mine doesn't work because I have no swap <YARs2>ok.. .back to the old laptop method <IHopeIAmNotSick>Hello :3 I am mounted into my new system on the installer and I try to clone a dotfiles repositor with a Git command and I get: "server certificate verification failed." I have actually tried installing nss-certs and configuring it according to the manual. I get "Git error: the SSL certificate is invalid" on `guix pull` <folaht>How can I know which store item I'm using? <yarl>folaht: What do you mean? <folaht>yarl, well I tried 'guix build', so now I have multiple store items of one package <folaht>And I'm not seeing the changes I made to that build <folaht>It's the xkeyboard-config package though. I don't know if that has a binary. <untrusem>you could use "guix build --check" instead of "which" <folaht>I'm not sure how that would work. guix build will rebuild that package right? <folaht>So does that mean that I would have yet another store item? <folaht>Well I would have to know a <binary> for it to work. <untrusem>/gnu/store/mbf9a6znimzaf9rh7j4wn4c8iq5wjd5a-xkeyboard-config-2.44 <folaht>which: no mbf9a6znimzaf9rh7j4wn4c8iq5wjd5a-xkeyboard-config-2.44 in (/gnu/store) <efraim>/gnu/store/mbf9a6znimzaf9rh7j4wn4c8iq5wjd5a-xkeyboard-config-2.44 is a directory <untrusem>my guix might be on different commit then yours, i did `realpath $(guix build xkeyboard-config)` <folaht>Oh, I see now. The build I made isn't being used. Is there a way to specify which build guix should use? <folaht>Like I would want guix to use /gnu/store/2r2vd9wfnrlf075vjwfg82b5k79pf2ir-xkeyboard-config-2.44 instead of /gnu/store/mbf9a6znimzaf9rh7j4wn4c8iq5wjd5a-xkeyboard-config-2.44 <folaht>Because the former is where I've created my patch <yarl>folaht: Yeah, guix build does not put the package in a profile. <yarl>how do you manage your packages? <yarl>Do you use guix package (or guix install, guix remove, etc)? <yarl>okay, just try to replace the command line you used to build (guix build ...) with guix package -i <folaht>yarl, can I use a '--with-patch=' with the 'guix package -i' command? <yarl>If you look at the guix manual, 5.2 Invoking ‘guix package’, at the bottom, you'll see that guix package supports Package Transformation Options. <yarl>(and common build options) <yarl>"since [it] may actually start build processes" <folaht>yarl, nice! Thank you. I'll look into that once I've finished my packages upgrades. <yarl>short answer : guix package --help-transform <folaht>yarl, I did 'guix package -i xkeyboard-config --with-patch=xkeyboard-config=./xkeyboard-config-yr.patch', but realpath $(guix build xkeyboard-config) is still showing the same store item <kestrelwx>You would want to see the path for `which $executable`. <folaht>xkeyboard-config is not a binary executable <yarl>You tried to look at realpath of `guix build xkeyboard-confg` <yarl>But now, your patched version is in your profile <yarl>I have to go, will be back in ~1h <kestrelwx>`guix package -I`, I think that prints paths too. <folaht>kestrelwx, ah, I see the package there <folaht>And that package does have the patch <folaht>But when I choose languages, I don't see the change. <jschwart>hi all, I'm trying out Guix, but it seems I'm missing some part <jschwart>I am using a Raspberry Pi 4 with Raspberry PI OS (Debian) as the foreign distro and used the script to install <jschwart>it seems that `guix` is not added to PATH however but all further instructions seem to assume that it is <nikolar>just a silly question, did you log in and out <jschwart>is that ok or should all sessions be closed? <jschwart>it looks like the installation script doesn't fully run <jschwart>I reinstalled and answered 'n' for the AppArmor part, now it works <mwette>jschwart: is `guix' in /usr/local/bin ? If so, try `/usr/local/bin/guix install hello' <jschwart>hmm. now I ran `guix pull` and it's stuck on building all sorts of stuff <jschwart>does that mean it's compiling or something else? <jschwart>I was hoping the performance of Guix would be better after the 1.5.0 release... <jschwart>when I tried Guix a few years ago, I ran into the same issue, that `guix pull` would always take hours to complete <jschwart>from what I understand from the documentation it's only fetching binaries, so I don't really understand why this takes so long <ieure>jschwart, `guix pull' will build a new copy of the guix binary. Do you have substitutes enabled? It shouldn't be compiling much of anything; it is slow, but hours is very very uncommon. <ieure>jschwart, It has to compute derivations, which is CPU-bound and not something which can be substituted. <ieure>I pull/reconfigure every 1-4 weeks, depending, and this usually takes on the order of 10 minutes for me. <jschwart>I see a single guile process that is using a lot of CPU <jschwart>building /gnu/store/61ixqhl5zv3nzz1751hjcys1k4zais58-guix-packages-base.drv <noe>jschwart, yeah, that means the substitutes were not found and its building guix from source. Unfortunately, this happens often if there was a recent commit when you guix pull <jschwart>I triggered this about 2 hours about I think <jschwart>is there a way to avoid building from source? <ieure>jschwart, Wait and try again. What hardware is this on? <ieure>Raspi hardware is very, very slow. <ieure>jschwart, Also, Guix System? If you have a system config you can share, I'd like to see one. I have a raspi I want to put Guix System on. <jschwart>julius@raspberrypi:~ $ guix pull --commit d636e801be0d5de46273c283b80fb940b0f9a05a <jschwart>guix pull: fout: ongeldig argument: Missing required argument after `--commit' <ieure>jschwart, --commit=d636e801be0d5de46273c283b80fb940b0f9a05a <jschwart>I'm using Raspberry Pi OS (Debian) as the foreign host distro <yarl>You will probably encounter memory problem if the daemon builds in tmpfs /tmp. <ieure>jschwart, Ah yeah, I have that setup as well. Don't like it. <cbaines>noe, data.guix.gnu.org is better to point to, as it's used for building the "guix pull" derivations <ieure>Yes, you need swap to build most anything on a raspi. <yarl>The trick is to build on disk. <yarl>Debian's on systemd. the trick is <yarl>Environment=LC_ALL=C.UTF-8 TMPDIR=/mnt/tmp <cbaines>jschwart, try --commit=72d81789e9399854899eba380fda9e0b99e84540 instead <yarl>in /usr/lib/systemd/system/guix-daemon.service <yarl>to avoid problemswith big packages. <jschwart>it's now doing the computing derivation stuff <jschwart>what are the minimum system requirements for Guix you'd say? <ieure>Disk is probably the main one, 16gb is the lowest I'd run. It doesn't *require* much hardware, you just need to compensate for the spec drop with patience. Or a faster machine to offload builds to. <bjc>even with a fast machine, guix is often a test of patience <jschwart>I see, I was hoping things would be faster <folaht>yarl, I now have two different xkeyboard store items when I search for my current xkeyboard-config in use. One listed at `guix package -I xkeyboard-config` and another one at `realpath $(guix build xkeyboard-config) <jschwart>so this computing derivation stuff should take how many minutes? <folaht>I want the `guix package -I xkeyboard-config` store item to be the one that I use. <bjc>less than an hour? often more than 15 minutes? a long time but not into completely insane territory <folaht>But I get the feeling that it's not. <jschwart>I suppose the people maintaining the i686 bits are the masters of patience ;) <bjc>but even after computing the derivation, there's *still* a bunch of work to do a lot of the time <jschwart>I was hoping it would be slow only the first time after installation <bjc>guix pull is only a "decent" speed if you do it every couple days or more. and even then it's slow <ieure>jschwart, There has been some talk about performance improvements, but nothing concrete done as far as I know. Many of the issues are complex or involve external projects. Like this libgit2 issue which makes updating repositories unnecessarily slow, which has been open and unfixed for nine years: https://github.com/libgit2/libgit2/issues/4230 <ieure>That one directly affects `guix pull', since guix uses guile-git, which uses libgit2; and the performance issue is worsened by large repositories, which Guix most definitely is. <jschwart>this one /gnu/store/61ixqhl5zv3nzz1751hjcys1k4zais58-guix-packages-base.drv <bjc>honestly, except for the very first pull, i don't think the libgit issue is the biggest problem <bjc>whatever was done to fix the reproducible build slowed it down so, so much <bjc>enough that i kind of want a flag to turn it off, because i don't care anywhere near enough about reproducibility to pay the price i'm paying <jschwart>I think when I tried 1.4.0 I had the same experience, even getting a progress bar to move a single percentage just took very long... <jschwart>Guix is quite an interesting project, but performance-wise it feels like my system would be spending running guix more than any other program... <bjc>i don't remember when that change went in. but it was never fast. just that now it's really, really slow <jschwart>I just ran uninstall, I hope in the future I can try again... <usernew>Do you guys know how to inspect logs on guix system (besides opening the individual lig text files in emacs) <usernew>Also cause there is various log files (dbus-daemon, messages, ntpd, secure) and I hope there is some organic way to look at them. Couldnt find info on the manual :( <usernew>Second question: do I need to do anything particular when I boot my guix system afyer a crash? <meatoid>or /var/log? it's not systemd, there is no journalctl or something like that <meatoid>there is nothing special that needs to be done after a crash, unless you suspect something special happened :) <ekaitz>usernew: if you do (sudo) herd status $service_name -> that gives you the log file <usernew>ekaitz: thanks. How do I know what the various oog files represent? <ekaitz>i'm checking at system-level and they don't give me the log file lol <usernew>meatoid: thanks. Var/log but I dont know what the files in there represent <usernew>So everything goes through herd? ekaitz <ekaitz>usernew: you have messages -> that is normal messaging <usernew>Is debux in the herd universe or guix universe? ekaitz <meatoid>usernew: they are plain text files usually, perhaps compressed if there are enough of them <usernew>What do you meanat system level they dont give you the log? <ekaitz>usernew: i don't want to confuse you: just go to /var/log <usernew>meatoid: is there any docs to show how to orient myself in these log files <ekaitz>there you'll find logs by application and also some that are not filtered by application <ekaitz>those that are by app are named after the application that generated them <usernew>Yea I see . What does herd status system-log show me? <ekaitz>before systemd took over the world I think this was the standard <ekaitz>usernew: that shows you the log folder <usernew>And then I click on the log file im interested in? <meatoid>usernew: unfortunately the layout of log files is mostly unix/linux tradition, but i would start by doing `cat <logfile> | tail` for whatever interests you <ekaitz>it says: Log files: /var/log/messages <yelninei>efraim: I opened the gdc-11, gdc-14, dmd port pr. I am afraid it is a bit too big but is is more or less the same patch in 3 different variations with a world rebuild for gcc-11. <meatoid>is there a way for an administrator to restrict how other users use the 'guix' command? <meatoid>i.e. if an admin wanted to save store space, could they disable the guix time-machine command or stop users from pulling in unauthorized channels <yelninei>you can set regular permissions on the daemon socket directory but nothing more granular <meatoid>yelninei: as in the build daemon? so that only certain users can trigger new builds <yelninei>metaoid: For guix-system there are the socket-directory-permissions, socket-directory-user, socket-directory-group fields in the config <meatoid>yelninei: where are the docs for this? i can't find these options <vagrantc>whoah, newer versions of mrustc can bootstrap rustc 1.90 ... i think the current mrustc in guix only bootstraps up to 1.54 ? that could cut out a *lot* of builds. <vagrantc>although, apparently the version in guix in theory could bootstrap straight to 1.74? so maybe there are challenges in the difference between theory and practicee <ieure>Ah yes, let me dust off this old chestnut... In theory, theory and practice are the same. In practice, they're different. <yelninei>there is a rust-bootstrap-1.74 built with mrustc but only on x86_64 <dajole>Noob question: is there a better way to try whether a package definition build succeeds than using `guix build -L. foo`? This often gives completely meaningless errors, e.g. "unknown package", that have nothing to do with what is actually wrong (like missing required fields). <ieure>dajole, There's some nuance in your question, because the errors you're talking about are not errors with the build, but errors in the expression of the instructions about how to build it. <ieure>dajole, So, no, there isn't really a better way to see if a build succeeds, but the cases you're wondering about aren't really that. <ieure>dajole, I would recommend using the REPL to develop the package definition, which will give you much clearer errors of the type you're interested in. Syntax issues, incorrect nesting, wrong values, missing fields, etc. Once that works, try building it -- you can do that from either the CLI or within the REPL. <dajole>Do you write out the entire package in the REPL and then copy it to a file once it works? <ieure>dajole, It depends on your dev setup. I'm an Emacs superfan, so I open a file containing the package definition and C-c C-k loads it into my REPL. <dajole>I'm still figuring out how to work with scheme efficiently. The workflows seem quite different to other languages I've used where you just write your code in a file and then run it. <dajole>I'm using Emacs, too. I probably need to read up more on how to properly use Geiser. Thanks for your tips! <ieure>dajole, See "The Perfect Setup" section of the Guix manual. <ieure>dajole, This REPL-driven (or at least REPL-assisted) workflow is near-universal among Lisps. <ieure>Common Lisp, Clojure, Emacs Lisp all work (or *can* work) this way. <dajole>Will do, thanks! I think the last time I looked at that manual section I got distracted trying to decide whether to manage Emacs packages with Guix or use-package :D <dajole>(or rather with use-package + straight, since you could still use use-package and the Guix Emacs packages, as far as I understand) <ieure>dajole, Yes, I have kind of a mishmash, since my Emacs configuration still needs to work on non-Guix platforms. So package install with Guix on Guix System, or straight.el on anything else. use-package configures them, however they got installed. <ieure>straight is very fiddly compared to Guix for Emacs package management.