IRC channel logs
2026-05-12.log
back to list of logs
<decipaliz>ok seems like the issue was with zig's internal linker. strange. the build works when using lld <graywolf>great, apparently my channels file is againts the rules now... <graywolf>why is the sandbox applied to local files as well, it was fine until now :/ <decipaliz>a question of style - when a package definition needs so much patching to be buildable in guix, what is preferrable to do? i don't imagine a package definition with a giant patch file is something that's great to push to guix. submit a pr to the original package's git repo? <decipaliz>at least i've not seen any packages in guix that had so many changes <egnuun>But Guix does take it's time. I executed "guix shell -C firefox" almost an hour ago. <egnuun>Well, I have to go to bed now. So, I will tell you tomorrow, if it worked. ;-) <egnuun>Wow, but it is working hard in the background. <egnuun>htop says roughly 20 out 32 GB RAM are used and all of the 8 CPU cores are at 100%. <egnuun>But the rest of the system is nonetheless running normal. <bjc>firefox is enormous and takes hours to build even on very beefy hardware <bjc>it often also requires llvm of multiple vintages, which are also enormous <egnuun>When I just installed it from nonguix, it didn't take that long. <bjc>if there are substitutes available, you're not building it, just copying something the substitute server built, so it's quite a lot faster <egnuun>It probably just gave me a precompiled version. <egnuun>But why would guix shell not take that one? <bjc>guix weather firefox <bjc>also try librewolf. for whatever reason, i have substitutes for that but not firefox <egnuun>I use Librewolf. But I could try it with the container. Thanks for the idea. <egnuun>Wow, yes, that is way faster. :D <egnuun>Ah, and now it even finds the profiles! <egnuun>Thank you very much, ieure, bjc ! <yaircul>I enjoy utilizing GNU Guix so much it's impossible :-D <apteryx>any suggestion on rewording "Installation with a bind mounted store" to something more general? I'm struggling a bit. Maybe, "Installation using a storage device different from that of root file system" ? But that's very long. <apteryx>or "Installation with a pre-mounted store" ? <apteryx>I guess pre-mounted store is to the point and succinct <apteryx>has anyone seen their *shell* buffers in Emacs terminated when putting their machine to sleep? I've asked in Emacs, but perhaps that's a Guix-specific thing. <czan>I haven't noticed that, but I guess I use eshell more than shell. Does it happen every time you put your machine to sleep? <bdunahu>maybe for some reason this is an intended feature, but pressing C-d on an empty line terminates shell, ansi-term, and vterm without any config loaded <bdunahu>I guess that is unrelated since it only terminates the one shell <bdunahu>oh C-d sents EOF to the shell process if the point is at the end of the buffer... why would it do that... <bdunahu>maybe your shells are also getting EOF <apteryx>czan: I'm not sure it happens everytime... maybe only when I'm in a 'guix shell' ? <apteryx>"Process shell<1> processus arrêté" after a quick suspend/resume <apteryx>that was in a 'guix shell' in the Guix tree. <apteryx>it looks like it only happens if the shell buffer is in focus when I suspend <apteryx>is it just for me? perhaps I have something odd in my shepherd setup/elogind config. <czan>Can you try running "cat -" in the shell before the suspend/resume? I'm wondering if it's sending a C-d when it wakes up? (Although presumably the "guix shell" case would have shown if this was the case...) <czan>The fact that it only happens when the buffer is in focus is pretty suspicious. <apteryx>hm, both "cat -" or "strings" show just an empty line before Emacs prints that the process shell has been stopped <bdunahu>apteryx: does it happen in `emacs -Q`? Me pressing `M-x shell` then typing `loginctl syspend` command does not result in the shell being killed when it wakes <apteryx>ah, maybe my keyboard is to blame (an ergodox running qmk) <apteryx>when I resume in 'emacs -Q', the shell is not killed but the keyboard appears stuck sending the RET key or something <czan>Are you suspending/resuming by physically moving part of the machine? Or by running "loginctl suspend" or similar? <apteryx>I'm using the GNOME suspend option; I'd expect it calls out to loginctl; I can try the later manually to be sure <apteryx>interesting; sudo loginctl suspend didn't exhibit the problem <czan>Yeah, that's fine. I was just trying to rule out "something is causing the keyboard to physically send inputs". <czan>Oh, that is interesting! <czan>Also, incidentally, I don't need sudo for loginctl to work. <apteryx>I think if I resume using the enter key on my keyboard, this triggers the issue even with loginctl suspend :-) <apteryx>so probably some interaction between qmk firmware and kernel while resuming <apteryx>unless I use sudo, nothing happens for me <apteryx>but the repeated key is not what kills the process; this seems to happen only when using emacs running as a daemon (started with emacsclient) <apteryx>(#define USB_SUSPEND_WAKEUP_DELAY 500) <apteryx>correction: I see the shell buffer of an emacs *daemon* terminated the same when using 'sudo loginctl suspend' <apteryx>it looks like having emacs run as a daemon is key to reproduce this. <apteryx>(to do so I just launch it via the Emacs (Client) launcher in GNOME, currently, not a home or shepherd service) <apteryx>ipv6 connectivity to a hetzner seems to be broken, or is it just me? <apteryx>to a hetzner vps (I've set the correct address using the static-networking-service-type service) <apteryx>on a different ovh vps using the same strategy, I can both ssh in and also ping6 <switchy>I don't have any vps to test with, but I do have ipv6 <apteryx>switchy: I think I need to set a trailing digit to my IPv6 for Hetzner, to what they give me <apteryx>like they give me $ipv6::/64, and I think I need to assign to my machine $ipv6-provided::2/64 for example <apteryx>for OVH I didn't have to do that, I guess they give you the IP of the machine directly on their site <switchy>you probably just have the whole prefix to roam around in <apteryx>hehe, unlocked root access to my box with a bind mount: sudo mount --bind /tmp/sshd_config /gnu/store/akig7vawwh449q03673lz3y1i3l7aws6-sshd_config <apteryx>(and then 'sudo herd restart sshd'); at least I still had sudo <apteryx>got the config file name with 'herd configuration sshd' <futurile>what is the convention for comments in our source, some have XX: blah-blah, and some have FIXME: blah-blah <apteryx>XXX: means "this is suboptimal, dirty, should be revisited when we know better" <apteryx>still don't know how to set the ipv6 on the hetzner box; I've created a debian box to compare against; it seems to be responding on ::1 <cbaines>I think there have been some changes in Guix since then though that might have resolved the "scope link" issue <apteryx>shouldn't our dhcpcd service just get an ipv6 address on these environments? <apteryx>(that'd be configure and trouble-free) <cbaines>I don't think it's configured to do that by default (see dhcpd-configuration) <apteryx>I was at least missing (ipv6? #t) for the route <apteryx>the added route for guix-hetzner-2 seems just for the local ipv6 interface, right? fe80. Maybe I should avoid setting ::1 from my given ipv6 network as the default route for hetzner? <cbaines>you can run ip -6 route from the Debian box if you want to compare <cbaines>the fe80 bit is important though, so the default route should be fe80::1 <apteryx>yep, it now works. It takes the whole ip for itself, if you want to run VMs I guess the suffix of ::1 would make sense <apteryx>or maybe that's fine, you'd have e.g. the main machine at 2a01:...7f0f::, then 2a01:...:7f0f::1, etc. ? <apteryx>cbaines: the fe80 bit was indeed the important missing bit <gabber>is it possible to change the state (approve, changes requested) of a pull request in fj-mode? <apteryx>but I think it is with emacs-forgejo <janneke>bjc: made some progress, now trying to intstrument console-run, but it seems to wrong before i can get anything to print, of course; see #hurd <duongph2098>Hello. I can't sign with gpg. When I ran `echo "SOMETHING_HERE" | gpg -a --default-key A_KEY --detach-sig`, it returns `gpg: signing failed: Operation cancelled`. Is anybody facing the same issue or just me? <zeromind>do you have pinentry or so installed to prompt for the key's passphrase? <duongph2098>zeromind: I have this `pinentry-program /gnu/store/y9vdrmjfba0iqdd377q052h5kc7hs1gq-pinentry-tty-1.3.2/bin/pinentry-tty` in gpg-agent.conf <zeromind>ah, am not too familiar with guix yet, but missing pinentry was the usual cause for me on other systems; can't help futher, unfortunately <bjc>janneke: saw the update. i never would have guessed the symlink was the problem. i got bushwhacked trying to trace through startup myself <janneke>bjc: the story continues, there seems to be an interaction with /dev/console to be a translator instead of a plain file, or it may even be one or the other <janneke>i'm wondering if we even /want/ the /hurd symlink; i'm seeing if we can get rid of it altogether <bjc>yeah, i was thinking that, too. but i'm also thinking it really shouldn't matter <bjc>i'm not real sure how to handle it. the issue being, like, how do you handle booting a previous system generation if it's not a symlink? <bjc>it'd make activation more complex, and it'd have interactions with the pre-activation boot sequence <bjc>hmm. maybe not. we're encoding store paths directly in grub <janneke>you'd have to re-create all device nodes, which i think we're doing anyway? <janneke>possibly it's a good thing to keep the symlink <bjc>i think we have to in order to get translator paths right? <bjc>yeah, we're creating the full set on boot <janneke>if we had it in a profile, then it would be OK <bjc>it almost feels like it should be in /run/current-system <bjc>that's probably a bridge too far, though <janneke>ACTION is building their 20th image of today...man <janneke>yeah, /run/current-system/profile/hurd might be OK; but then why not #$hurd "/hurd" <janneke>anyway, we need this second-booth thingy to work :) <bjc>i think in most places it is <janneke>yeah, so that's what i'm doing in hurd-boot too now <bjc>so /hurd on my system points to /gnu/store/…-system/profile/hurd <bjc>so i guess it is a profile? <bjc>i think since everything under /hurd is a symlink, it just symlinks that too. might be able to test a work-around by sticking an empty computed-file in there <janneke>but an extra indirection, which is weird <janneke>come to think of it, once we get system reconfigure to work <janneke>what would we want to happen with the translators in the dev/ nodes? <janneke>after reconfigure /run/current-system is being updated <bjc>there's a lot of work for that atm. i tried for a while, but gave up for lower-hanging fruit <bjc>(system reconfigure) <bjc>i think we'd have to restart translators as part of activation <janneke>just wondering; our choice for the /hurd symlink may be dependent on what reconfigure needs <bjc>it's akin to figuring out what shepherd services to restart, i guess. you wouldn't want to restart ext2fs most likely, or storeio <janneke>one nice thing about the /hurd symlink is: if we somehow manage to remove it just before/upon a second boot, the second boot works <bjc>but otherwise, since the translators all reference /hurd, a reconfigure shouldn't need to touch them <bjc>oh, so the initial image doesn't have a symlink for /hurd? <janneke>can we somehow, early on, before we run console-run, or at the top of console-run, remove that symlink? <janneke>bjc: nope, /hurd is created upon first boot <bjc>now i'm very confused <janneke>by our guile init's hurd-boot-system in hurd-boot.scm <janneke>so, we only have /hurd after most of the boot has happened <janneke>iwbn if in console-run we could do (pseudo code) <bjc>i've thought about it very strongly =) <janneke>..even if the file-system is unclean/has errors <bjc>you may have already said this and i didn't get it, but i wonder if the issue is that /dev/console has a translator pointing to /hurd/term on 2nd boot <bjc>but on first boot it has no translator at all and /hurd doesn't even exist <bjc>in which case, maybe the answer is to never set a passive translator on /dev/console <yelninei>janneke /hurd consists of the /hurd of the system profile (which are more translators than just #$hurd/hurd, ie netdde, but also 3rdparty ones ). Weirdly there is operating-system-hurd which does not get added to /hurd at all (i have an issue about that, but it is tricky because we need shepherd to shadow the hurd reboot) <janneke>bjc: than may well be the problem -- and the solution <bjc>gimme a few to try it out <janneke>playing with "system: hurd-boot: Remove /hurd symlink after creating device nodes." or reverting it all the time :) <janneke>err, make that: gnu: hurd: Do not substitute "/hurd/" in console-run: <janneke>ACTION is drowning in branches/wip-commits <bjc>ok, so ever hard-recreating /dev/console doesn't help, so that's a non-starter <yelninei>janneke: the /hurd name is embedded in the api with _HURD in hurd/paths.h so other software or hurd itself expect the hurd servers to be there <janneke>paths.c defines _HURD but uses that as a suffix <janneke>i tried changing "/hurd/" in paths.h and that exploded <yelninei>at least glibc uses these names (see mknodat.c) so it would need to be in the headers (and the hurd package) so a full rebuild <bjc>we need to keep /hurd (or an equivalent in /run) for dynamic run-time support <bjc>as long as the boot-time stuff has appropriate paths it shouldn't matter <janneke>yelninei: okay, so we need to keep /hurd; that's good to know <janneke>ACTION tries to patch console-run to remove /hurd <janneke>no idea if that will work, esp not with a dirty file-system, which is what this was all about! <bjc>if ext2fs doesn't throw an error when you pass --writable to it on a dirty filesystem, that should be patched <bjc>there's no way it's at all safe to modify a dirty fs <janneke>bjc: so, if a running system needs /hurd, and if a booting system must not have /hurd; then we really have problem <bjc>janneke: yeah, i agree. we can't be reliant on cleanup routines, so somehow we have to figure out how to boot with those files present, or some way to never create them <bjc>latter won't work, so that leaves the former <janneke>well, my remove_slash_hurd_symlink (void) hack in console-run doesn't seem to work <janneke>but as you said, this shouldn't work on a dirty fs, so it's a useless idea anyway <janneke>"doesn't seem to work" and also, i'm blind there before we have a console :-( <bjc>the lack of stdio in console-run is frustrating to be sure <bjc>i'm not quite at the point of attaching gdb, and i'm not even sure that 'd work <bjc>ok, so it seems to be something in /dev <bjc>if i remove the entire /dev heirarchy, then put /dev/console back, the 2nd boot is fine <bjc>the /hurd fs is still there <bjc>this is making me want to tmpfs mount /dev even more <janneke>...BUT i theorized only dev/console would be the problem and focussud just on that <janneke>which also doesn't seem to help (and breaks the console output of the shepherd starting) <bjc>that's already done in the rc script <bjc>what i'd like to know is where /dev/cons comes from and why /dev/console re-appears after the rename in rc <bjc>ok, 2nd try and confirmed that deleting /dev and re-creating /dev/console is sufficient <bjc>so there's something in /dev that's getting used and causing trouble <janneke>bjc: are you sure it's not just dev/console? <janneke>what if you move /dev/console, rm -rf dev, mkdir dev, put console back? <bjc>i can try again, but i've had other attempts that failed where all i did was delete /dev/cons* <bjc>i did re-create /dev/console afterwards <janneke>ah, but using `touch' or with a translator? <bjc>i'm doing this in linux <bjc>mount the disk image and manipulate /dev <bjc>i assume that, ideally, we start with an empty /dev every time and fill it during activation <janneke>i'm not convinced that rm -f dev/console && touch dev/console wouldn't fix the problem... <bjc>tmpfs should solve that, but i don't know how to set that up that early in boot <bjc>you can try, but it didn't work for me <janneke>but i have no idea where to do that; exceppt for yeah tmpfs <janneke>iwbn if there's "just" some problem with what we create in /dev <janneke>and if we omit (or fix?) those nodes, that everything works <bjc>alright, i just tried again to be double-sure: removing only /dev/cons*, touching /dev/console, and rebooting hangs in the same way <bjc>so there's something else in there for sure <janneke>i think i'll try bisecting removing stuff from set-hurd-device-translators <janneke>bjc: it would make sense, as debian also has /hurd and /dev/console <bjc>i'm wondering what happens if we change the calls to set-translator to use the store paths rather than /hurd <janneke>yeah, i have a commit that does that <bjc>my very wild guess is that some device is being used, but at this point in boot the translator for it can't be found or started <janneke>but it also removes the /hurd symlink <bjc>i'm sure that's not necessary <janneke>we could try doing a mix of that commit: using stor paths, but also keeping /hurd/ <bjc>i'm just deleting random stuff in /dev and seeing if it lets me boot <janneke>i haven't tried that; but getting that commit correct to use store paths was quite a bit of work <janneke>so you might want to reuse that if that's what you want to try <bjc>i can do this pretty quickly. longest part is waiting for boot <janneke>ACTION is comment-ing out random stuff in set-hurd-device-translators too see what happens :) <folaht>Is it possible to define a package variant that only adds a patch or do I have to always add a source to it? <janneke>shepherd: error: "/gnu/store/my5w75h626paa733168ik0f7agz7lifz-shepherd.conf": exception thrown while loading configuration file <bjc>i wish ‘halt’ didn't take so long <janneke> (inherit (package-source <original-package>)) <yelninei>janneke: do you know why there is this discinction between the hurd in the system/profile and system/hurd <bjc>let me try this from a clean setup, but it's promising <bjc>ah, /dev/random is trying to use /var/lib/random-seed <bjc>that is unlikely to work with an r/o /var/lib <bjc>you can test in hurd itself <bjc>before reboot: rm -f /dev/console && touch /dev/console && rm /dev/random && reboot <bjc>now how does debian work around this? <janneke>bjc: i don't even need to remove dev/console <janneke>it seems that without /dev/random i cannot ssh into the hurd... <janneke>Connection closed by 127.0.0.1 port 11022 <bjc>let me check that. it should recreate on reboot <janneke>ah, well; i "Just" removed creation of /dev/random in set-hurd-device-translators altogether <janneke>i mean, how are we supposed to remove /dev/random upon boot; same problem? <yelninei>janneke: there is /run/current-system/hurd which is the hurd package from the os definition and the union of /hurd subdirs of all packages in /run/current-system/profile/hurd. The second one is used for /hurd <bjc>janneke: i can ssh in after reboot <bjc>but you are correct, i only need to remove that one node <janneke>bjc: yeah, but you have /dev/random re-created, right? <bjc>oh, the console → console- rename happens before the node is created. that answers that question <bjc>seems weird to do that, but whatever <bjc>dang, we're relying on passive translators when setting up /dev <bjc>i was hoping we could just set an active translator and not have to worry about it <bjc>maybe i can hack around it <janneke>ACTION puts /dev/random back, but creates a /var/lib/random-seed <bjc>pretty sure that won't work, but i'd be happy to be surprised <bjc>i'm trying to move the creation of /dev/random to runsystem after the fsck and remount <bjc>unfortunately, that needs a complete rebuild, so it'll take a while <bjc>oh, no, this isn't going to work either <bjc>wait, maybe it will if i don't use -p <janneke>ACTION makes 3 typos trying to create that file...rebuild, rebuild, rebuild...sigh <bjc>i long for the day when i can test things that happen post-boot =) <janneke>yelninei has been fixing many things in the post-boot realm <bjc>do you know how smp is shaping up? that'll be a huge boon to dev cycles <janneke>i don't really know; there's codeberg.org/guix/guix/pulls/8349 <janneke>and we need to decide on how to go forward <janneke>but i'm kinda puzzled how to actually make use of those cpus <janneke>you have to run something like: smp /bin/sh <janneke>before they're available, afaik; so yeah <janneke>bjc: sorry to say that you're right, creating a /var/lib/random-seed doesn't fix the second boot hang <janneke>so indeed, how the hell does debian get around this? <futurile>yelninei: I saw you separated out the Perl update, is that going to be merged separately? <bjc>maybe it's some kind of boot order thing <bjc>like, something's using /dev/random before remount for us, but on debian whatever that process is happens later <bjc>too bad there's no lsof for hurd <bjc>worth a shot, i guess <yelninei>futurile: I think it would still need to be core-packages-team because it rebuilds all of commencement :(, i separated it because i kept adding random other things into the mess that is updating coreutils to hopefully make it easier to review <bjc>i wonder if it's possible to do tmpfs mounting in grub multiboot? <bjc>i have no idea how any of that stuff works, though =/ <futurile>yelninei: OK, do you know if there's a plan to merge there at any point. I'm not paying attention to that area. <futurile>yelninei: or who should I bug, because really these long running branches are killers <yelninei>futurile: core-packages-team is not getting merged any time soon, you could maybe push it to the misc-world-rebuild branch (which also rebuilds all of commencement) but i think the goal was there to keep breakages to a minimum and the operator precedence change does that <futurile>yelninei: what's the "operator precedence change" ? <janneke>err, to redifine /dev/urandom rather <janneke>bjc: i believe it's actualy /dev/urandom that's causing the hang <janneke>(removing /dev/random makes /dev/urandom a dangling link on current master) <bjc>yeah, and ssh needs urandom <bjc>still breaks for me even with that there <janneke>i only need to remove /dev/urandom, and i get a second boot <janneke>...but if we don't create /dev/urandom => no ssh <bjc>ah, yeah, i mean i need urandom for ssh <bjc>what i'm trying is creating /dev/random in runsystem, but without the passive translator <bjc>that way on reboot there's no translator there and hopefully things fail recoverably <bjc>i forgot the urandom symlink, though so i have to build again =) <yelninei>futurile: I guess you have to ask civodul or enge on what to do, the core-packages-team branch is in a really bad shape currently :( <janneke>bjc: on my hurd-boot branch, i have dev/urandom as a separate translator with --fast, just like debian <bjc>ah, i'm still using it as a symlink <bjc>on my debian install, though, dev/urandom is just a symlink to random <bjc>and /dev/random's translator is the same as guix' <janneke>i'm running latest debian-hurd-amd64-20260314 <bjc>i did an apt update recently on my debian install <janneke>root@debian:~# ls -ltrF /dev/*random* <janneke>crw-r--r-- 1 root root 0, 0 Mar 14 22:27 /dev/random <janneke>crwxr-xr-x 1 root root 0, 0 May 12 06:36 /dev/urandom <janneke>root@debian:~# showtrans /dev/urandom <janneke>/hurd/random --seed-file /var/lib/random-seed --fast <janneke>root@debian:~# showtrans /dev/random <janneke>/hurd/random --seed-file /var/lib/random-seed <janneke>and was ready to give up for the day... <bjc>hmm. i don't think hurd needs a patch, lemme check <bjc>yeah, that should be sufficient <bjc>mind you, this is only clean boots. we still lack a working fsck for dirty boots, but hopefully that'll be easy <bjc>i still think the proper solution is tmpfs dev, but i'll take this for now <janneke>bjc: cherry-picked and pushed to my hurd-boot; let's see <bjc>it might need the parent patch. not sure. i'm not at the point of cleaning this up yet <janneke>indeed, (my) fsck.ext2 needs work, i know that; should be trivial? (fameous last words) <janneke>ACTION has at least a handful of patches on their branch that are also reverted; we'll cleanup later! <bjc>verified it's booting with --readonly, too <janneke>bjc: what i don't get is why this needs to be done in bash, why can't it be done in scheme (hurd-boot)? <bjc>hahaha, i tried a dirty reboot and: ext2fs: part:1:device:wd0: warning: UNCLEANED FILESYSTEM NOW WRITABLE <bjc>yeah, it's because in hurd boot we can only set passive translators <bjc>if i knew how to set active ones i would have tmpfs mounted dev days ago and moved on with my life =) <janneke>ah, okay -- and active translators are ephemeral <bjc>they're active, which passive translators become automatically <bjc>and yeah, as long as there's no passive translator on that node everything is fine across reboots <janneke>we could do with an extra comment :) <bjc>maybe we should move more stuff to runsystem, tbh <bjc>not sure why so much needs to be in scheme <janneke>for now i cherry-picked your commit onto my adding of /dev/urandom, which is kinda silly <bjc>i think that'll break <janneke>and also left the commented-out code there; also silly <bjc>if /dev/urandom has its own translator referencing /var/lib/random-seed, my bet is things still fail <janneke>we want most everything in scheme, no? bash -- yuck! :) <bjc>eh, it's a matter of when it runs <bjc>runsystem is when we toggle fs writing, so it makes sense to set things up after that <janneke>isn't that what debian is also doing rigth now? <bjc>not my debian, no. it's just a symlink <bjc>lemme apt update and see if that changes things <janneke>i've modified your runsystem patch to create what debian does, as a first test <bjc>i just did a full-upgrade on my debian install and urandom is still a symlink to random <yelninei>janneke, bjc : For fsck.ext2 afaik, e2fsprogs should get added to the system automatically when it detects an ext file system in the operating system with file-system-service-type or is that only used on linux? <bjc>yelninei: hurd's e2fsprogs lacks fsck <janneke>bjc: confirmed, second boot works on my hurd-boot! <bjc>with the --fast change to /dev/urandom? <janneke>which was what all this was about... <bjc>ambushed by a hairy yak <janneke>i've hardcoded it to /dev/wd0s1 for now, but how do we get the device <bjc>you can get it from fsysopts maybe? <janneke>possibly using hurd's fsck works better? <bjc>well /dev/wd0s1 need to be rw for fsck to work? <bjc>because that could be a problem <janneke>ext2fs --writable --relatime --store-type=typed part:1:device:wd0 <bjc>yeah, we could sed the last bit out if necessary <bjc>actually, we have that already on the command line <janneke>anyway, this should be easy peasy -- check if hurd's fsck works and otherwise do some sed'ing <yelninei>janneke: the hurd fsck should set this up and call fsck.FS assuming it can find e2fsprogs <bjc>there should be a root=part:1:device:wd0 available <janneke>so that's how it's supposed to work! <janneke>we can just call fsck and only need e2fsprogs installed? <bjc>i have e2fsprogs installed from my patch <bjc>but it doesn't have fsck. however, on my separate vm with a more recent guix, it's there <bjc>oh, something funky is happening with it <yelninei>thas what the FSCK_SEARCH_FMTS is for and it should work for any filesystem <bjc>no, i'm dumb. i have it called from bin, not sbin <bjc>ugh, e2fsck doesn't like long args <janneke>(with fsck.ext2 and hardcoded /dev/wd0s1) <bjc>i suppose the reboot is necessary <janneke>i stole that code from debian's salsa runsystem <bjc>well, maybe not. it's not like linux reboots post-fsck in case the kernel was mangled <bjc>doesn't really hurt anything i guess <janneke>now to try yelninei's suggestion and not call fsck.ext2 directly <bjc>yeah, e2fsck is borking on trying to use ‘/’ instead of a device, too <yelninei>janneke: Is the sutils/fsck.c substitute now wrong by substituting sbin twice <yelninei>(also I dont like that it will only work with ext2 insted of generic one as long as the corresponding fsck is available) <janneke>(i saw your comment, but afaik ext2 is currently the only fs for the hurd; an ext3-compatible journaled variant being in the works) <yelninei>janneke: guix already has the mechanism to add the correct fsck program to the profile so having fsck specialize on e2fsprogs feels weird <janneke>yelninei: i was so happy that second boot worked, and that also booting from a dirty root fs worked! <bjc>using ‘check-file-system’ as ludo says is probably right <bjc>janneke: me too, and this is a decent stop-gap in my opinion <janneke>but it could well be that fsck.ext2 wasn't found and that the file-system wasn't cleaned <janneke>yelninei: re-trying with single /sbin/ substitution! <janneke>well, fsck.ext2 is still not called, i believe... <janneke>we could try (possibly in a new PR?) try to call fsck.ext2 directly, using some sed magic; dunno <yelninei>i just have had bad experiences when temporary hacks were not as temporary as originally thought <bjc>is hurd even using ‘mount-file-system’? <janneke>yelninei: sure, but what is temporary here? <janneke>we're including e2fsprogs; most probably no other file-system utilities even compile for the hurd because only ext2 is supported? <janneke>bjc: i'm unsure how we could use (check-file-systems) at this time <bjc>likewise. i think that's pretty far off <janneke>iirc, runsystem needed to be a bash script before guile can berun <janneke>ideally, we'd remove all [ba]sh from the boot process... <janneke>it had something to do with pipe, cannot remember <bjc>i think guix is different enough that at some point we're going to want to figure out our own boot sequence, rather than patching debian's forever <janneke>settrans -c /servers/socket/1 /hurd/pflocal <janneke>needs to be called from bash, and that guile wouldn't start without that <bjc>guile needs pflocal set up to run? <bjc>that seems like a guile bug to me, tbh <bjc>or maybe glibc depending on where it's happening <yelninei>janneke: Just using /run/current-system/profile/sbin and letting it work with any fsck that is available there instead of hardcoding e2fsprogs <yelninei>else wed need to that anyway once there is a non ext filesystem available (at least dostools builds but i am not sure if it can get mounted) <janneke>just look what's in /bin/ and hope that it works... <janneke>i think civodul argued against using /run/current-system/? so yeah, hard call? <janneke>anyway, ISTM that fsck calling fsck.ext2 doesn't work at all for us atm, so i'm currently trying the manual route (depending even more on ext2fsprogs) <bjc>i think for now we have to depend on it, because we're not using the stuff to handle mounting from operating-system at all <bjc>at least pre-shepherd <yelninei>janneke: And check-file-system is more guixy? it just calls system*/tty and relies on PATH to find the utility which got put into the system profile by a guix service <ieure>Shouldn't it be `check-file-system!' <loquatdev>Are there any build systems or channels I can look at that can build software using gradle? <ieure>loquatdev, There was a guix-devel discussion about gradle a while back, I believe someone had gotten it bootstrapped to some minimally usable version. <janneke>yelninei: i guess that's as good an argument as any! <bjc>ooohhh i think i understand why ours crashes <bjc>because as part of boot we set passive translators on /dev/random <bjc>but to do that, we first have to look at it to see if the translator is set <bjc>which then starts the translator <bjc>debian dgaf, so it's not a problem <janneke>bjc: but we no longer use passive translators, at least on #8536? <bjc>correct. i'm thinking of the current master behavior <bjc>i think i'm wrong anyway, since by the time rc runs we should be read-write <bjc>what if it's guile that needs /dev/urandom <janneke>we could check calling guile in runsystem <janneke>before and after the pfinet or urandom thing <bjc>i'm moving some stuff around <bjc>this next test should tell me <janneke>we could just call guile -c '(display "here0\n")' <bjc>i was mid build when i thought of it <bjc>since i was trying to move the active translator setup to guile from runsystem anyway <gabber>how can i evaluate simple expressions within a #~(list ) expression? <ieure>Yes, #~(list #$expr) is the gexp equivalent of `(list ,expr) <gabber>but what if instead of a #~(list ..) i need more like a #~(let (...) (list ...)) ? <neonio>i think the ungexp environment would not contain those 'let's <neonio>however whatever the ungexp expression evals to would be subject to evaluation in the gexp environment, which *does* have those 'let's? if anyone can verify <gabber>i have a bunch of very long path strings that are prepended to a bunch of test files that need to be excluded from being run. using the whole paths each time is both ugly and likely exceeds maximum line length. <janneke>strings /gnu/store/zy06wabzfq16jrxp6q5l76hhg1bvxplr-hurd-0.9.git20251029-0.6290b4c/sbin/fsck | grep fsck.% <janneke>/gnu/store/870pnhdq6i505l5j05iw7csib7scpx5b-e2fsprogs-1.47.2/sbinfsck.%s <neonio>you can break them up with \ gabber <janneke>well, /me is going to go with yelninei's advice and use /run/current-system/profile/sbin/ anyway for now <janneke>let's see if we make this mistake more ofnet <bjc>right, whatever is breaking is happening pre-runsystem, so pre-rc <bjc>that's unfortunate, because it means if someone sets a passive translator on /dev/random by accident it renders the system unbootable <bjc>janneke: are you trying to call fsck from /run/current-system? <gabber>neonio: yeah, i know. it's still kinda ugly to repeat them. in no-gexp context i'd just (let ((foo (lambda (p) (string-append "prefix/" p)))) (list (foo "a") (foo "b") (foo "c"))) <janneke>bjc: yes, i was going to try to do that, instead of from e2fsprogs <bjc>i don't think that'll work on 1st boot <bjc>there's no /run set up until relatively late <bjc>at least not current-system <bjc>if you're doing this in ‘runsystem’ you can get use $system/profile/sbin i think <bjc>you'll have to move the arg parsing up to the top, though <yelninei>i missed that, so that would be profile of ther previously booted generation? annoying <bjc>or nothing at all if 1st boot <bjc>ugh. there's fsck in there, but not e2fsck <bjc>might have to propagate that input <yelninei>file-system-service-type should add e2fsprogs automatically after seeing an ext2 / (it is in hurd-default-essential-services), but this does not work for me <bjc>i don't think that stuff is fully bolted in to the hurd yet <janneke>in the PR, i've added ext2fsprogs to %base-packages/hurd <janneke>this is all very early stages; i don't mean that we should make a mess of it <janneke>just that when people start running the hurd, all of this will probably change anyway <bjc>yeah, i look at a lot of this as scaffolding <cluelessguixer>Yikes. Memtest has run 3 passes without any errors. At this rate I'll have to change my motherboard and CPU. <yelninei>mhh maybe is possible that the hurd guix services dont extend file-system-service-type, ill take a look <janneke>bjc: yeah, only after we have pfinet, guile runs <janneke>ACTION adds a comment about guile and pfinit <janneke>as e2fsprogs in also in (linux) %base-packages, i think i'll keep it also in %base-packages/hurd anyway, but this is a nice fix <yelninei>janneke: the operating-system-default-essential-services on linux also has non-boot-file-system-service which would do that for all other declared filesystems but i got an error for file-system-service-type being declared more than once <sneek>Welcome back bartk, you have 1 message! <bdunahu>I don't know if it should count if you pre-queue your greeting <cluelessguixer>So a short memtest (4 passes) looked fine. I've updated the BIOS and tried hammering the server a bit to induce something, and a second system reconfigure did produce the following: https://bpa.st/Q4HQ <cluelessguixer>I just cancelled it and redid it without issue, and the server seems stable otherwise. <cluelessguixer>Maybe the BIOS update helped, dunno. Could try to resync Monero from scratch to see what happens, but eh. <PotentialUser-57>Hi been thinking about switching to guix and wanted to know how hardware compatibility was for a thinkpad x220? <ieure>PotentialUser-57, It's good, the only issue is going to be firmware for WiFi. But that's a problem on basically everything. <PotentialUser-57>Okay thanks are there any recommendations in regards to wifi cards or atleast the project recommends? <stephen0>I have a t430 that I'm waiting for a new wifi card, I hear there's a channel that mix *fix* the problem, but I like this solution better. <ieure>PotentialUser-57, ath9k is the newest WiFi hardware which doesn't require blobs, it's about three generations old. <ieure>I forget if the X220 is using m.2 or miniPCIe. ath9k is widely available & cheap in miniPCIe formfactors, and expensive in m.2. <PotentialUser-57>I know enough to know syntax and functions but only have tried elisp and commonlisp <ieure>PotentialUser-57, Scheme is a lisp. <ieure>It's one of the two major Lisp families. <PotentialUser-57>Is it quite different? I'm just asking if there are any major caveats, don't mind learning though <ieure>PotentialUser-57, It's different, but less different than coming from a non-Lisp. Think of it as the RISC approach to Common Lisp style CISC. <PotentialUser-57>oh so is it less intensive on hardware or? I don't think I got the analogy ;-; <ieure>No, nothing like that. The metaphor failed to land, ignore it. <ieure>PotentialUser-57, It's an attempt to make a Lisp free of some of the legacy of early Lisps, so thing tend to be a bit less featureful, there are fewer ways to do things, and it's a bit more consistent. <ieure>PotentialUser-57, Scheme is a Lisp-1, so there are no function/variable cells in symbols, so no special handling of those types (no FUNCALL, FSETF, FMAKUNBOUND, etc etc), because they're not needed. <stephen0>PotentialUser-57: what wiki page were you referring to? <ieure>PotentialUser-57, Also no difference between DEFVAR and DEFUN, Scheme uses DEFINE for everything. Defining functions in Scheme is (define (foo argA argB ...)) vs. (defun foo (argA argB ...)) <ieure>It's a mixed bag for me, I like a Lisp-1, but miss a fair number of things from the more CL style lisps. Nil punning is probably the thing I miss the most. <PotentialUser-57>can't say I have as much experience with it more than creating some elisp functions tbh <sham1>FWIW, just using NIL for false implicitly is considered bad form even in CL, or at least that's what I recall hearing. So you'd want to use a predicate for it <PotentialUser-57>but I use nixos so im a stickler naturally so I kind of don't like the idea of nil punning <cluelessguixer>Isn't Common Lisp more or less an amalgamation of all the lessons learned over the many years and many Lisps? A part of me wishes Emacs and Guix were CL based. <ieure>cluelessguixer, More or less, but it's a double-edged sword. <sham1>Yes. CL was basically an attempt to unify the various Lisps around at the time into a standard that could be agreed to most people. Hell, Scheme was one of those Lisps, since CL took lexical scoping from Scheme <ieure>cluelessguixer, Since many of the lessons were learned later, there are many internal inconsistencies. Example, you can't specialize a CLOS method on a primitive type, only a CLOS type. <sham1>(Too bad it didn't take TCO guarantees, bleh) <ieure>sham1, That's not what I'm talking about. <ieure>sham1, nil punning lets you use nil as an empty collection of most types. In a CL style Lisp, you can do stuff like: (butlast (cdr (assoc 'bar '((foo . 1))))) <sham1>Is it not? Because from what I can tell, NIL punning is about the way that NIL can be used for different purposes in different contexts, some being with it being the falsy value and others with it being the empty list <ieure>PotentialUser-57, Good luck! <ieure>sham1, Yes, but I don't care about the falsey value case, I care about the empty collection case. <ieure>sham1, In that example code, the assoc returns NIL, and NIL puns to an empty list, so the other functions operate on it; the NIL propagates through the layers and you don't have to do anything. <ieure>sham1, In Scheme, you get #f out of the assoc and everything else blows up because #f isn't a list and doesn't pun to one. <ieure>So you have to do something about it. At every layer. I do not care for it. <cluelessguixer>At the end of the day, as long as I get my parentheses, I'm happy. :-) <sham1>(chain-and (assoc 'bar '((foo . 1)) (cdr _) (drop-right _ 1)), but I see what you're getting at <bjc>janneke: good to know about guile. something to put on the pile of things to be addressed later i guess =) <bjc>i've got a version that moves the /dev/random and urandom setup into guile, but it doesn't buy us much <ieure>sham1, Yeah, I am mostly adapted at this point, but have about 10x the years of experience with other Lisps as Scheme... so it was startling. I know there are ways to work around it, but none seem as elegant as CL style nil punning. <bjc>i sort of understand why scheme doesn't use nil like that, but i miss it too <bjc>always made me feel like i was doing it right if i could condense things down to nil <sham1>I guess the rationale originally was an idea of type safety. And, well, (CAR NIL) and (CDR NIL) evaluating to NIL really doesn't make much sense <sham1>Since NIL of course wouldn't be a real pair. Which is of course why (car '()) and (cdr '()) will have the implementation barf at you <ieure>Right, I think this is downstream of promoting "pair" to its own type in Scheme.