IRC channel logs
2026-04-28.log
back to list of logs
<nox>Is it possible to add an arbitrary string to grub.cfg ? <nckx>nox: I don't think so. Guix's menuentry records are unreasonably restrictive (it won't even let you boot ‘linux’ without an ‘initrd’ IIRC). Newlines in ‘file names’ (and ignoring ugly boot-time errors) are a hacky work-around. <rogerfarrell>I just read up on the Hurd VM service. Is there something like it for Guix system containers? <nox>> nox: I don't think so. Guix's menuentry records are unreasonably restrictive (it won't even let you boot ‘linux’ without an ‘initrd’ IIRC). Newlines in ‘file names’ (and ignoring ugly boot-time errors) are a hacky work-around. <nox>It also doesn't provide `insmod lvm`, even with luks. <nox>lvm.mod isn't even part of another package <GalaxyNova>Hey can someone help me figure out why my .guix-channel file isn't working? <GalaxyNova>I get: `.guix-channel:12:4: error: channel dependency has an invalid introduction field` <apteryx>how can I tell the exit status of a one-shot? service? <Rutherther>GalaxyNova: the only thing I see is that you do not have two spaces in the middle of the fingerprint. Not sure that's a requirement, though <sneek>Welcome back Rutherther, you have 1 message! <Rutherther>And even moreso I should've done it two months ago :) <Rutherther>But it's not so trivial, just pushing this to master will not fix it fully, also need to backport to 1.5.0 branch and fix in all translations <apteryx>(info "(shepherd) Defining Services") says "As for other services, the ‘start’ method of a one-shot service must return a truth value to indicate success, and false to indicate failure.", but that's not what I'm seeing when I use make-forkexec-constructor with a program-file guile script that throws an exception as argument <Rutherther>apteryx: you shouldn't fork in oneshots in the firstplace. Make forkexec will return the pid, so always truthful value <apteryx>but it says "as for other services"; so that's not true? <apteryx>I'm pretty sure that's how make-forkexec-constructor is used "for other services", right? <apteryx>I guess the difference is that in this case the service is short lived, so shepherd doesn't do some monitoring of the service life (it's expected to stop), while it would on the pid of a long lived (not one-shot) service? <Rutherther>apteryx: other services accept PID as start value that forkexec gives them <apteryx>would raising an exception in a one-shot start lambda procedure counts as a falsy value? or do I need to handle exceptions and return #f? <Rutherther>apteryx: yes, it does not do service monitoring at all since it doesn't have a way to do that, as it accepts truthful value for success and failjre for not. Not pid <apteryx>thanks, I'm starting to see clearly. <apteryx>by the way, our code base has lots of make-forkexec-constructor in one-shot?, perhaps worth raising an issue about that <apteryx>their exit status will be silenced (always passing) <apteryx>ah... I was using make-forkexec-constructor because I wanted to run it as a specific user/group <apteryx>I guess I need to do my own waitpid and check for the exit code manually then <apteryx>probably simpler to just use 'su' if it's on PATH though. <rutherotg>oh yeah that's not good that in Guix there are services that do that. Presumably. But just changing them to something like spawn can also be problematic <rutherotg>because ideally it should not really be blocking for too long <rutherotg>apteryx: I've been meaning to ask you for a couple of weeks about something you said <rutherotg>apteryx: you said something like it would be nice having certificates as an extensible service in guix system. Why is that since you can just add a package with etc/ssl/certs in its output to `packages` and add certificates like that? <apteryx>maybe I was thinking about the new way it works for gnutls; it now relies on p11-kit, which is itself configured to trust the nss-certs by default <apteryx>that's all configurable/overridable via p11-kit and configuration files, I had read, but there could be abstractions in Guix to do that more easily, perhaps. I don't remember if that's what I was hinting at :-) <apteryx>commit 38e7132dcfd was the one making use of p11-kit in gnutls <rutherotg>well I tried to 'hunt' you sooner but the timezone difference is just too much to not miss you typically <rutherotg>so I understand it's already too late for you to remember well <efraim>I'm working on a maybe-nasm package input and of course I chose a package that takes a while to build :/ <test202020>hello guys. how to clean all profiles and save only from home reconfigure? <ebrasca>Make file can't find the vulkan libraries, that is the problem. <identity>‹it›, being? you would need to be more informative for us to be able to give you help <efraim>add pkg-config to your environment and try adding `pkg-config --cflags glfw3` to your CFLAGS <efraim>'-lvulkan' looks like it would come from the vulkan-loader package <ebrasca>It is stated in the tutorial that I need vulkan-loader, thank you. <efraim>you might need to adjust the LDFLAGS also to use `pkg-config --libs` on the different libraries you're linking to <ebrasca>Not sure how to use pkg-config, trying to figura thet part out <efraim>a quick look would suggest changing "-lglfw" to `pkg-config --libs glfw3` (with the backticks so it gets evaluated) <efraim>try messing around with the different options from `pkg-config -h`, but in general I default to assuming pkg-config --cflags for the CFLAGS and pkg-config --libs for the LDFLAGS <ebrasca>efraim: I got past the glfw error, thank you! <mightysands>Hey, I was here yesterday complaining about the usb installation of guix not working. Seems the mystery continues today <mightysands>I tried the same usb on a second laptop. The first was a Thinkpad R400, the second, which I tried today was a Thinkpad T60 <mightysands>With the R400, booting into the usb stick got me to a welcome to boot guile message, and then a kernel panic. With the T60 however, I got to a different looking grub menu (I'm guessing because of the different aspect ratio) but then selecting guix just gives me a black screen with a blinking cursor, and typing anything on the keyboard doesn't type anything on the screen. <mightysands>Do these symptoms fit the description of a bad dd write to the usb stick ? I'm just trying to think of all possible causes before I change anything <mightysands>I thought GUIX worked well with these models of laptop ? <efraim>can you try switching to a different tty? I don't have a 32-bit machine to test the 32-bit iso on <mightysands>I don't think I can actually. I'm not even sure it reaches the point where it opens a primary tty in fact <mightysands>it's not your standard cursor. It's without a prompt, and is the blinking underscore cursor. All the key combos I know for switching tty's aren't working to change anything <nckx>You could try dd'ing the exact number of bytes the ISO is long back off the USB drive and see if the checksums even match… (Some day having this built into the installer would be nice.) <mightysands>nckx: I wouldn't be sure how to forumulate the command to do that. Could you give me an example ? <nckx><Do these symptoms fit> Well, they fit what's usually an unsupported GPU, but that is unlikely on a T60. Also the cursor is… odd. Also Guix doesn't do ‘quiet boot’ so not seeing the kernel talk about its day and IRQs and stuff is always unexpected. <nckx>Uh, not off the top of my head, but… <mightysands>I was wondering if the sync command at the end of guix's manual's recommended dd command might have something to do with it <mightysands>usually a dd command for burning an iso to usb includes some value for byte spacing, around 4mb, right ? <mightysands>I'm just thinking out loud here, I recognise that this probably didn't cause it <nckx>dd if=/dev/foo bs=1 count=$(stat -c%s the-guix.iso) | sha1sum; sha1sum the-guix.iso <mightysands>thanks, I'll try that later this afternoon and get back to you <nckx>That is off the top of my head but it should work. <nckx>The bs=14M is just for performance (which is why my bs=1 is silly but it's the only way I know to count= bytes), it doesn't affect bootability at all. <nckx>Also, I don't know why I didn't just use ‘head -c’ instead of dd but meh. It matters little. <efraim>I am sometimes worried that our i686 packages really target 32-bit emulation and not actual hardware, but I don't have a way to test it <nckx>I think that is a very justified concern because I think it's de facto true. <efraim>it's possible that that's what the issue is here, but I would've expected a kernel panic and not for it to hang <nckx>We do enable magic sysrq so if you happen to know for sure what your T60 recognises as SysRq, you could try to reboot, and you'd know that your problem is a running-ish kernel that can't draw to the screen, but… this is a T60. In text mode (cursor). I don't think it would tell us much. <nckx>(Or adding ‘panic=10’ to the GRUB linux command line, same idea. Not that it's really worth trying IMO.) <ieure>That's when Lenovo still knew how to make a good keyboard. <mightysands>Well the R400 throws a kernel panic. The T60 hangs, though I think specifically it's the version of the T60 that doesn't use an INTEL GPU <mightysands>I haven't come across the term sysrq before, nckx. Could you elaborate a little on what you mean ? <ieure>mightysands, On a ThinkPad T60, Fn+PrtScr emits a SysRq scancode. <mightysands>nckx: Hey, just to clarify, with your dd command from earlier, you mention the guix.iso in two places, inside and then after the parentheses. Is that referring both times to the downloaded guix iso sitting on my working laptop ? Or the guix iso inside the usb stick ? <mightysands> dd if=/dev/foo bs=1 count=$(stat -c%s the-guix.iso) | sha1sum; sha1sum <ieure>mightysands, If you have a T60 with nVidia, have you figured out whether it has one of the defective ones? nVidia shipped a ton of faulty GPUs with a very high failure rate in that era. <ieure>mightysands, Do not use bs=1! <ieure>mightysands, bs=1 will destroy flash media, it says to use a 512-byte block size. You want: bs=1M <mightysands>I'm not sure it's Nvidia. All I know so far is that the sticker on it says "graphics by ATI" <mightysands>ieure: So is it right to mention the path to the original downloaded iso file both times like that in the command ? <ieure>mightysands, I'm not sure why nckx wrote the command that way, I don't have the scrollback for it. <mightysands>dd's input file is /dev/sdd and then (stat -c%s /home/me/downloads/isos/guix.iso ) | sha1sum; sha1sum /home/me/downloads/isos/guix.iso <ieure>Okay, yeah, this is *reading* off the USB. The initial command is correct. Just never *write* to flash media with bs=1. <identity>ieure: «The bs=1M is just for performance (which is why my bs=1 is silly but it's the only way I know to count= bytes), it doesn't affect bootability at all.» <ieure>identity, Yeah, I see in the scrollback (on another box) now. <ieure>Not that long, a few minutes. <ieure>Probably bottlenecking on compute for sha1sum there. <mightysands>wow, yeah. This is actually almost using up 100% of both of my duo cores <identity>…and my laptop's cores, by the sound of the fans. weird temperature spike timing <mightysands>I hope I'll actually be able to gnuboot these laptops and run guix system on them <mightysands>the code is apparently experimental for gnuboot, on T60's. Come to think of it, I'm not even sure gnuboot is compatible with non-intel GPU T60's <ieure>Yeah, not sure. The main issue is that if it has the nVidia GPU, the hardware is a time bomb that *will* fail in an unrepairable way. <mightysands>Wouldn't surprise me if that's what's already happened... <ieure>No, you would know if it happened, the video would be all screwed up. <ieure>Lenovo built a handful of builds with corrected GPUs for corporate customers, and sold a handful with no GPU, but those are rare. <mightysands>Will that happen even if I don't use a GUI ? and rest exclusively in console tty ? <ieure>It was a big deal, class action lawsuits. <identity>the is framebuffer on the GPU either way <ieure>That's a good sign, but check lshw or lspci to verify. <mightysands>Well I'd love to check with lshw or lspci, but for the time being, I can't even get a shell prompt <ieure>MacBooks also shipped with these GPUs. <ieure>All ancient history now, ha. <mightysands>jesus, what is with my spelling mistakes today ? You'd think I'm ESL <janneke>yelninei: i've just run my first successful guix pull on the 64-bit hurd! \o/ <yelninei>hurray, how long did it take? (just guix pull, no dependencies) <janneke>with dependencies, it took me about 48h? <janneke>i'm testing the pull without dependencies right now <samplet>Cangrats, janneke, and long time no see! <janneke>it's been running for about 25minutes right now, but looking good <janneke>hey samplet, thanks and great to see you! <samplet>I keep thinking it would be fun to try and run the HURD on my ol’ ThinkPad X200. <janneke>ACTION was thinking about addding a bit to the mes documentation, about how my initial idea/holy grail of bootstrapping would be to jump from assembly into scheme -- and saw that you've also/already written just that in your blog (and implemented it for the most bit, of course :) <janneke>samplet: yeah, that would be so nice <janneke>i've got no idea where the 64-bit hurd currently stands wrt hardware <janneke>samplet: also, ekaitz reached the mes repl today (yesterday night?) on his compiler branch <samplet>It’s amazing that any of that Guix HURD stuff is even dream-able let alone on a road map. <samplet>I was catching up on ekaitz’ blog today, and was wondering about exactly that. <samplet>I have my own good news, which is that a fully bootstrapped Germ can now replace Guile as “#:guile” when building the GNU Hello package. (All the standard GNU tools stay in place, but Germ runs all the build-side Scheme code.) <janneke>samplet: oh wow, congrats -- and well done! <samplet>But we have a downside that you’re all too familiar with... <samplet>...phase `patch-usr-bin-file' succeeded after 527.0 seconds <janneke>it's one of the reasons i decided to give up syntax-case support five years ago, at least until we would have a compiler <janneke>(apart from the fact that i didn't have/find a ready-to-use implementation) <ieure>Am I dreaming, or is the double entry of LUKS passphrases now a solved issue? <janneke>ieure: the solution has landed on master! <samplet>Adding Scheme-level bignums has slowed things down. I could make gains by using explicit fixnums where appropriate. Also, loading the gnu-build-system module takes 2 minutes and that could fixed by the heap imaging system. <samplet>There are so many rabbit holes when it comes to performance, though. I’ve read Dybvig’s Three Implementations paper a few times by now! <janneke>samplet: ouch, i'm wordering if ekaitz knows about that paper <janneke>he's been looking quite a lot at performance, and took an interesting path <janneke>where i had always (initially?) focussed on a very minimal core in C, ekaitz looked at candidates of functions written in scheme that could speed-up things significantly when moved to C <janneke>and he's done that with some success, at the "cost" of having more code in C...but for the current mes approach that is not a problem; so yeah <samplet>I’ve done the same thing as you, but out of necessity. I can’t really write a bunch of Scheme primitives in assembly (for each architecture). <janneke>samplet: initially, i used only simple c because i planned to translate it all to assembly / commented-machine code some time <janneke>only after stage0 adoption, i let go of that path <janneke>where i postponed that problem, it's the problem that you started with, i think -- pretty cool! <janneke>yelninei: i built a vm yesterday based on devel-hurd46 and didn't get it to boot/past grub; so silly...any ideas? <janneke>ACTION should probably try without --nographic and com0, and run it in a terminal <yelninei>do you have -M q35 and noide? no clue what else could be the problem <janneke>yelninei: is there still a memory constraint that you know? <janneke>ACTION has removed noide because they thought youpi mentioned noide was purely a 32-bit thing -- so i want[ed] to test/make sure of that <yelninei>i saw something in #hurd about problems when one tries extremely huge amounts of ram but i think "regular" amounts should work <janneke>yelninei: okay, i've got something booted again, on master; phew and thanks for listening <janneke>using --machine q35, -m 6144 and without noide (64-bit); plain master <yelninei>without noide? I thought it was still required to find the right root <janneke>yelninei: yes. noide is apparently only effective (and necessary) on 32-bit. <yelninei>janneke: Ah a6e48bf329d914b91731d58423fe4cb503252cb1 changed the grub config to always use rumpdisk for 64bit <janneke>there are no IDE drivers in 64-bit gnumach <janneke>yelninei: hmm, to get smp, we need to compile gnumach with --enable-ncpus=x, or so it seems <janneke>i'm hoping that without the qemu setting --smp [n], you automagically get 1 <janneke>not sure what the performance impact is, in that case <mightysands>ncxk: I've ran the dd command for the guix iso, and the contents of the liveusb, and the bad news is they're identical checksums <janneke>yelninei: for now, i have: "--enable-ncpus=8" ;8 CPUs should be enough for anyore <yelninei>but if say --enable-ncpus=4 does it work with --smp 2 <janneke>i've got no idea; but i'm gonna try --enable-ncpus=8 without smp, and with --smp 2 for now <janneke>yelninei: Generation 2 Apr 28 2026 18:43:40 (current) <janneke>took less than 80min, don't know exactly <mightysands>eieur: Any idea what could be causing the problem with the guix iso if the checksums are actually identical ? <janneke>oh, i do know exactly, the time is right there; started 17:24 <yelninei>debian also has 8 (appearently also on 32bit?) <janneke>almost exactly 80min, on a 8GiB single-core <mightysands>Has guix system 1.5 actually been tested on i686 32 bit hardware ? <mightysands>Because I've verified the iso is identical on my install usb and it throws kernel panic on a Thinkpad R400 and it doesn't even get as far and just hangs on a Thinkpad T60 (I think with an ATI GPU) <mightysands>I'll try an OpenBSD install later this evening and if that works, then that should reveal it to be a guix bug and not a hardware issue on my end <mightysands>otherwise, any input would be appreciated 'cause I'd love to get guix working to try it out <yelninei>janneke: I wonder how much faster it would be with the guile jit enabled but the comment about obscure crasbes (from 2020) is not promising <janneke>yelninei: ouch, the jit is disabled? (because of obscure crashes?) -- hmm, ouch <janneke>well, at least my whole build and double guix pull was entirely stable <janneke> 6:56:48 PM up 2.4 days, 0 users, load averages: 18.32, 3.60, 2.06 <janneke>using many `guix copy --from=childhurd' requests <janneke>yeah, let's ask him when he's around <yelninei>but this was for guile 3.0.2 maybe it is now fixed? <janneke>we'd have to find a volunteer to test that :-D <janneke>ACTION is currently very happy with all guix pull dependencies built, after some 48h <yelninei>janneke: I have all the %final-inputs, all things with hour long tests (bison, libtool, cmake, ...) and a slightly custom version of the manifest gcrooted in my linux home folder <yelninei>janneke: nothing against having llvm/clang fail after 20h <janneke>yeah, we'd probably best make a copy/extra inheritance of the guile package (guile-next)? and only change the configuration there <janneke>ACTION was/is not looking forward to a world rebuild because of changing one guile configure flag that would also cause guile-boot0 to be rebuilt <yelninei>we could try with guile 3.0.11 (that is used for guix pull) <janneke>someone should add a entry to the milestone <janneke>(possibly prefixed with [nice to have], dunno) <janneke>ACTION suspects/hopes for a new blog post some time soonish with the amazing germ news :) <janneke>yelninei: i've built gnumach with --enable-ncpus=8, but during the build i get <janneke>i386/i386/io_perm.c:314:2: warning: #warning SMP support missing (notify all CPUs running threads in that of the I/O bitmap change). [-Wcpp] <janneke>/proc/cpuinfo (and during boot) i only see cpu0 <janneke>and the smp programm (that should enable smp, fails with: <janneke>/gnu/store/3jsd80smwk1kj946hznjmiwrhbs9mxgz-profile/sbin/smp: gnumach does not have the expected processor sets, are you running smp kernel?: Function not implemented <janneke>hmm, /me may have done something wrong again...waitaminute <janneke>yelninei: well, the gnumach with --enable-ncpus=8 says on any guix command: Killed, even without qemu --smp, so yeah -- dunno <janneke>the `smp' program runs without error, but i cannot install `stress' to test it <janneke>also, /proc/cpuinfo still shows only one cpu; while booting with --smp 4 i do see 4 cpus... <yelninei>did you try mach from git / steal some of the debian patches? <lechner>Hi, why would Guile's pretty-print output in Guix be different from that in Debian, please? Both are on Guile 3.0.11. Thanks! <janneke>yelninei: no, i used guix master vanilla gnumach <yelninei>janneke: Also I saw debian has a pae kernel for 32bit which should support up to 8Gib ram which has been the limiting factor for e.g. guix pull/ guix build guix <janneke>the 64-bit hurd seems in a very good state, it's "just" the fact i haven't seen it run on real iron just yet... <yelninei>For me right now the 32bit version still feels faster for some things but smp would solve that as well <janneke>that could very well be; i guess using 32bit the cache[s] are still just as large, but the program/data sizes ae probably half as big <janneke>having 8GiB available would be very nice, though, for compiling gcc, for guix pull (and later probably guix systtem reconfigure) <yelninei>maybe we could add a -pae (and -smp) variant of the kernel? <janneke>a variant? that could be interesting <janneke>although, maybe we should wait with -smp until we get it to actually work <janneke>if using -pae is always OK, we could maybe just enable it? <yelninei>do you know what is still missing for system reconfigure apart from the guix tests and winning the shepherd test race? <janneke>no, i actually haven't tested that just yet <janneke>i wanted to have a sucessful guix pull first <yelninei>i guess grub fails tests because missing qemu <yelninei>(at least according to the manifest) we need gdk-pixbuf with all the python problems <yelninei>and librsvg but I think that should still be the non rust version <yelninei>ACTION gives up on core-packages-team again <loquatdev>Hello, everyone. I'm drafting a service that will automatically `guix pull` and build some system/home configurations once a week. How should I approach this in terms of service structure? I'm guessing a shepherd timer that runs the commands under a new user created for this purpose. <ieure>loquatdev, I'd say a home service with a timer that runs under your normal user. Otherwise you'll have a second checkout/copy of Guix for the dedicated user, which will waste disk. <Rutherther>loquatdev: are you aware of the unattended-upgrades-service-type? <loquatdev>Rutherther: I am not. I didn't see it in the manual... I'll check the source real quick. <loquatdev>ieure: I'm doing it on a server, so I imagine it'll be different somehow. The idea is to prebuild my user configurations remotely so I can then just pull the substitutes. <loquatdev>Rutherther: Thank you. I misspelled my search. <Rutherther>I think your service can be very similar to this one, except you will not reconfigure, but just build <nckx>ieure: …reading with bs=1 will not destroy the flash media, what the hell… <loquatdev>Rutherther: It very likely will. Thanks for the tip! I'll get to work. <ieure>nckx, I corrected my misunderstanding. <nckx>OK, I see it in the log. Thanks. Scrollback for everyone! <yelninei>nckx: for your help2man problem yesterday you might have a stale guile launcher in your guix checkout linked against the wrong guile version <janneke>yelninei: guix system reconfigure fails with: <janneke>- 'check' phasebuilder for `/gnu/store/v589jz68916pjz07drslbhnjfy6ig39m-guile-fibers-1.4.3.drv' failed with exit code 1 <yelninei>hmm, I have built that, do you know which tests? <yelninei>guix build /gnu/store/v589jz68916pjz07drslbhnjfy6ig39m-guile-fibers-1.4.3.drv <janneke>ACTION just restarted the system reconfigure, possibly it succeeds now? <janneke>Signals delivery fails constantly at GC #189 <janneke>/gnu/store/d367xck1ml092xgcr95p17dbmfq008h7-bash-minimal-5.2.37/bin/bash: line 6: 13661 Aborted (core dumped) top_srcdir="/tmp/guix-build-guile-fibers-1.4.3.drv-0/source" ./env /gnu/store/kg0v4mrk6748xnvba4rbri3di8px4pvg-guile-3.0.9/bin/guile --no-auto-compile -s ${dir}$tst <janneke>ACTION is not sure if they're happy with he build, or unhappy with the unreproducible error... <yelninei>janneke: I skipped the preemption test because that is waiting for an interrupt that never arrives maybe we should add dynamic-wind* to that as well just to be sure? <noxi>Is it possible to do multiline replacements with substitute* ?