IRC channel logs
2026-06-16.log
back to list of logs
<dcunit3d>i had some problems on foreign distros with building guix for another mountpoint. on NixOS, it wants you to build the whole thing. i can't remember everything. <dcunit3d>it mostly works, but you really want to set that up early on. (i think they're gone though) <dcunit3d>is there a simple way to get geiser to connect to `guix repl --listen=tcp:54321` and just use that repl? <dcunit3d>geiser doesn't behave the same when i try that. it doesn't fully associate the buffer with the repl. <dcunit3d>i don't really have direnv on these systems and i can't easily set it up. <dcunit3d>configuring .dir-locals.el so that the geiser-load-path gets set correctly has been extremely confusing. i know it works for a guix checkout, but if i don't set the %load-path to my time-machine checkout with (guix-for-channels ...) unified modules then it just compiles forever <dcunit3d>i have two guile module roots in my dotfiles, so using geiser-repl-per-project-p doesn't work either <dcunit3d>the simplest way i know to get around most of this is to just run an emacs server/process that's set up just for guile/geiser and guix.el <dcunit3d>however, i idk that it's smart to have two magit instances from separate emacs processes working in the same repo. it could be fine idk. <ieure>dcunit3d, M-x geiser-connect RET, then enter the host/port doesn't work? <dcunit3d>ieure: it works, but then i can't switch between modules. i need to try it in a more isolated emacs profile <dcunit3d>it's wierd. i can evaluate some expressions. the result shows up in the *Geiser-Debug* buffer, but i'm not quite sure what the state of the geiser repl is. `geiser-repl-switch-to-module` jumps to the repl, but doesn't change the module namespace <dcunit3d>sorry ieure i rebooted, but had messed up my systemd-resolved on NixOS. i'm migrating from opnsense to vyos, so i have to finish fixing the DNS on that. i may get to the geiser/guile stuff later <csantosb>Morning, Guix ! I see that `ci.guix.gnu.org` is out of game today, same as `qa.guix.gnu.org` 😥 <Alavi_me>Hi guys. After a recent update, my neovim broke. I think the problem is that the tree-sitter-cli version in guix repos are old. `:checkhealth` in neovim says so. I want to try with nvim v0.11.5 again to see if downgrading fixes it, but `guix shell neovim@0.11.5` says it can't find that package (the current version is 0.12.1). It's because I'm on a newer revision of guix, but how can I use that older <identity>Alavi_me: (info "(guix) Invoking guix time-machine") <Alavi_me>identity: the guix manual is really hard to understand tbh <Alavi_me>LLM said get the commit of the generation that had that version of neovim with `guix pull --list-generation` <Alavi_me>then do `guix time-machine --commit=<commit> -- shell neovim <Alavi_me>I really could not have gotten this from the manual <identity>this is literally the first thing the manual says, but i guess offloading reading comprehension to an LLM is easier <kimjetwav>identity: I was trying so hard not to be that blunt but yeah lol <futurile>Alavi_me: you need a mental model for how the Guix archive works, that will help with why the 'commit' option is there. There's also some nice things you can do with channels etc. <futurile>I think it _is_ fair enough to say that the manual doesn't always have the most obvious example, or enough examples <kimjetwav>futurile: Mmm, true. It has gotten better. I remember time was "The Store Monad" was one of the earlier sections in the manual. At least they've renovated it since then. <futurile>kimjetwav: yeah agreed docs are getting better - I've spent so many hours reading sections of it heh <kimjetwav>I suppose you could argue that if you're /just/ skipping directly to the time-machine node without much understanding of how the guix command line parses, that an example with a multiply nested thing isn't super intuitive either, like guile inside of environment inside time-machine; though at that point maybe time-machine itself is a bit advanced for your usage. Hard to say. <apteryx>futurile: it's intended as a reference manual rather than a user guide :-) <apteryx>for examples, the idea is to have guix-cookbook fill these shoes <Alavi_me>identity: no the point was in guix pull --list-generation to get the commit version. The rest was in the example of the manual. <Alavi_me>I think the manual is too specific and verbose (classic GNU fashion). Which is ok for a manual but I think we need a simple, quick, onboarding and getting started with some pretty and simple to undertand visualizations and lists, so one doesn't have to start reading the manual from top to bottom to get going. I don't think guix should be aimed at non-technical users, because that's not the use case, <Alavi_me>but it should be simpler for technical users who don't want to spend too much time on learning it or are completely foreign with the concepts and ideas. <identity>if you do not want to spend «too much time on learning» a tool, then you are not going to acquire too much proficiency in the tool. the first paragraph says «The revision of Guix to be used is defined by a commit […]». the section directly preceding the section on time-machine vividly illustrates guix pull --list-generations and the fact that it displays the commit of the generations. if you did not know it <identity> did so, which is likely if you opened the manual in the middle, you could search the manual for the word ‹commit›, or, you know, ask a fellow living being. <kimjetwav>Alavi_me: Maybe, but when you go "LLM told me this solution and it worked", it makes it unclear what got you stuck and makes it sound like you didn't attempt to figure it out yourself first. That's the impression I got at least. <identity>^, every time i see «i asked an LLM» i am pretty close to assuming the person was met with any amount of resistance and just caved instantly <kimjetwav>identity: We have a guy in the lab where I work who has recently become prone to saying things like "ChatGPT says THIS about X" and the rest of us have started replying "why don't you come back when you have something to say about X yourself". <kimjetwav>identity: By interjecting the output of an unreliable black box in to the conversation, it makes it impossible for us to know what work or thoughts they actually started with, and instead demands that the rest of the group (who didn't consult the black box about this topic we are all mostly subject matter experts in) spend time replying to the black box. <yuuhei>hello, during a build, how can I detect whether I am running on privileged or unprivileged daemon? does (getuid) suffice? <civodul>yuuhei: hi! you cannot and the idea is that builds should produce the same result in both cases <civodul>out of curiosity, what’s the use case? <yuuhei>civodul: when building node@6, I have 3 tests failing on unprivileged daemon, but working fine on my GuixSD system. <yuuhei>due to test names being like `parallel/test-process-geteuid-getegid', I assume it is due to the privileged/unprivileged differences <civodul>yuuhei: oh, that’s a bug we should fix; could you make sure there’s an open bug report for this one? <yuuhei>so I wanted to skip those tests on the ubuntu builder, but keep them on my Guix laptop <yuuhei>fair enough, will send a bug report (though I do not use codeberg, so it will be to the mailing list) <civodul>unfortunately i and others haven’t been able to allocate much time to it <yuuhei>no worries, you all do plenty already, I grateful for all the effort everybody invests, Guix is really cool thing that managed to get built :) <apteryx>does ngraves hang around here sometimes? <futurile>ACTION sighs as Orange FR has lost all fibre into the valley and now the 5G is struggling <jlicht>how does one lose fibre? At least around here, that stuff is buried in the ground <futurile>heh, good question, we just get the informative "there is an issue in your area" <futurile>there's only one way into the valley, up a giant bridge which has to be checked/fixed for rock-fall in Autumn/Summer. My total guesstimate is that they manage to either accidently hack through it with a digger, OR there's some reason why they switch it off - as it seems to happen every time there's works there <futurile>lucky this isn't a town with a bunch of remote workers, conferences and so forth <civodul>so ci.guix and pulls.ci.guix were down (power outage at the MDC data center), and now they’re back <civodul>pulls.ci is starting anew though, meaning that it’s forgotten about all the pull requests it was building <civodul>you’ll have to rebase to let it know about your PRs… <noe>How bad is it if I, hypotetically, inadvertently pushed a world rebuild yesterday <csantosb>I'd like to update first paragraph in (info "(guix) Managing Patches and Branches") <csantosb>But I'm not sure if there is a relationship between codeberg pr nb and ci evaluation nb, is there ? <bdju>I'm trying to update my system and I'm now building my fifth version of openjdk in a row. It's done 13 through 17. Is it going to do every version up to 25..? <bdju>Oh. I think so. Further up it does say "The follow derivations will be built". Missed that before. <bdju>I think I'll cancel this and try again another time. I was hoping to actually use my computer today. :) <yelninei>dmd master now works on both 32bit and 64bit Hurd, bootstrapping it is still painful <attila_lendvai>so, if i cross-compile using the clang-toolchain, then it embeds an ld.so into the elf binary with a non-existent store path. i guess it captures it at package build time? what am i to do? my ultimate goal is to cross compile from x86 to arm and run the binary using qemu-aarch64 <attila_lendvai>IOW, how will i have a proper glibc-2.41/lib/ld-linux-aarch64.so.1 that matches what clang-toolchain embeds? <attila_lendvai>IOW, how can i specify in a manifest that i want glibc compiled for a specific --system <yelninei>cross compiling with clang does not really work as the CROSS_*_PATHS search paths are only respected via a gcc patch <attila_lendvai>there was some progress reported on the mailing list to clean up cross compilation toolchains. that sounded like good work. i wonder if that would have solved my problem... <attila_lendvai>FTR, adding a (cross-package-entry glibc "aarch64-linux-gnu") to my manifest results in an attempt to compile it locally that fails eventually with "objcopy: Unable to recognise the format of the input file `/tmp/guix-build-glibc-2.41.drv-0/build/libc_pic.os'" <eikcaz>/run/user does not exist after reconfiguring. Should %base-services be sufficient for /run/user to be populated on login? <eikcaz>I tried the same config with a guix version from a month ago and latest, so don't think it's a guix version problem <eikcaz>Hmm, well maybe I should have taken the "XDG" in XDG_RUNTIME_DIR to indicate I need something from "D"esktop services. But this is weird, does guix home (which requires /run/user/1xxx/shepherd/) not work without something like elogind-service-type on the system? <bdju>I use %base-services rather than %desktop-services, but I also have elogind-service-type, so not sure if I can answer that. I do have /run/user on my system, though. I don't use guix home. <ieure>I think you should have /run regardless of elogind. <ieure>But maybe not /run/user/$UID <eikcaz>bdju, ieure: that checks out. And wouldn't you know it, as I go to check where I should update the guix home docs, I find a note saying to install elogind...