IRC channel logs
2026-02-24.log
back to list of logs
<apteryx>hello guix! is there perhaps some switches we can provide to xorgserver-for-tests to avoid libEGL warning: DRI3 error: Could not get DRI3 device u/ <apteryx>we have 400k pending builds on CI, lol <apteryx>uh, much of texlive is broken on aarch64? <apteryx>is there a way to setup some /bin/sh symlink inside a gexp->derivation ? The root is read-only <apteryx>hm, what piece of code does perform-git-download ends up calling? <apteryx>I don't see a "git fetch" or "git clone" invocation in the daemon directly <apteryx>the daemon seems to simply invoke the perform-download script, e.g. "guix", "perform-download", drvPath.c_str(), output.c_str(), NULL in builtins.cc <apteryx>which would end up calling git-fetch-with-fallback from perform-download.scm <apteryx>ah, OK, I think it invokes git-fetch, the procedure from (guix build git) in the end <trev>anyone using hyprpaper? i think there is a bug with EGL and the latest kernel that is preventing it from working. worked well before updating to kernel 6.19 <apteryx>how often does cuirass fetch the branches? <acidbong>i love building programs from team branches: <acidbong>`guix build gucharmap` -> "The following derivations will be built: `all versions of Rust`" <acidbong>(i guess everything is uncached due to the recent glibc workaround?) <yelninei>apteryx: Hi, what do you think of setting --with-ca-path=/etc/ssl/certs to make the updated libcurl find certs? <csantosb>yelninei: this is also valid with foreign Guix ? <janneke>yelninei: you have quite some interesting hurd patches pending: if you want to "wait" for some of them and amend the hurd post for another week or two that's fine; we'll have to align with futurile anyway for when to schedule our blog posts; we can possibly also choose to publish in a couple of days, WDYT? <janneke>futurile: and what is your plan/are your whishes wrt your blog post? <yelninei>csantosb: probably not, it would depend on what the foreign guix is but it is also the setting for nixos (which is where i got the idea from). I dont know what else to do to have libcurl find certs as the patch no longer applies against updated curl <yelninei>janneke: I think it is ready now and fixes (almost) all test issues on x86_64, apart from the ones that are fixable by changing qemu settings and am not sure what to do about those. Still not sure about git-fetch-from-tarball and it awaiting new x86_64 bootstrap files <csantosb>yelninei: Does the native-search-paths SSL trick in w3m help ? <yelninei>csantosb: No, because libcurl does not honor SSL_CER_DIR only the cli does. We currently have a patch to make libcurl do this but no longer applies when I update curl and rebasing it is tricky. <futurile>janneke: I can push it today if it doesn't block you publishing? <futurile>janneke: and then I'll work on another one about guix days <futurile>apteryx: where do you see that there are 400k pending builds? <csantosb>This is a factor of 4 with respect to beginning of February <janneke>futurile: sure, no problem; we can easily wait another week, right yelninei? <csantosb>How can one use gcc-15 with gnu-build-system, instead of the default gcc-14 ? <csantosb>Adding gcc-15 to native-inputs is enough ? <futurile>janneke: if I push today, you could go on Thursday/Friday if you wanted. Or wait a week - I don't think we'll overwhelm our readers :-) <futurile>csantosb: ah thanks, I didn't scroll down - I thought it was a giant table heh heh <janneke>this has been 1.5y in the making, a week (or two) doesn't really matter <gr1n>futurile: I read on your webpage that you used vim, do you still use it for guile/guix? any plugins or workflow you can share? <gr1n>I have tried but can't really grok emacs and its a big learning curve when I only want some niceties while editing <futurile>gr1n: honestly, it's a pretty awful situation heh heh. I just use Vim and I cut-n-paste stuff into a 'guix repl' that I have open in another split <futurile>gr1n: I couldn't get any of the repl stuff to evaluate inside Vim without potentially hanging it - and I have a very heavy vim buffers approach so losing an instance of Vim was too painful for me <futurile>gr1n: there is an nrepl option - but right now Conjure doesn't work with it - there might be someone working on it atm <futurile>gr1n: there's also a Visual Studio Code option if you don't want to learn Emacs. It's basic but does the job <efraim>futurile: there's vim-slime which I think I tried out before <efraim>also with vim-guix-vim you can use :Guix commands, including repl <efraim>it's a bit slower than outside because of the speed of the terminal, but yeah that works <efraim>I also normally run guix lint from :Guix <futurile>I have a load of automation 'justfile' scripts that I've been working on - they update pull requests, build guix, create worktrees and run all the tests we're supposed to do <futurile>it's pretty good, except for some limitations around guix shell <efraim>in my vimrc I have 'let g:guix_binary = "/home/efraim/workspace/guix/pre-inst-env guix "' so I can use ./pre-inst-env from any directory <efraim>at some point I need to go back and see about improving guix.vim, I feel like there's a lot more it could be doing <futurile>I'm kinda thinking about moving to nvim, there's all the snazzy stuff there, but the async stuff is probably useful for not crashing vim <futurile>it's just a big move - I have too many customisations/plugins and stuff heh heh - ridiculous to spend so much time on it really <efraim>ok, I think we worked a lot on making sure vim plugins autoload, so `guix shell vim vim-guix-vim -- vim -c ':Guix lint hello'` should just work for a sample <gr1n>thanks all for the feedback, I got pampered with LSP and auto linting in other languages and want to get something close for scheme <efraim>found I was missing a space, added that <efraim>and I check for call-with-input-file twice but I missed call-with-output-file <futurile>gr1n: you can definitely get LSP, coloured brackets in VS Code - it's jut not perfect compared to where things are in something like Clojure <mange>I'm having trouble with a channel with some home/os configs which use specification->package (from (gnu packages)). "guix pull" fails pretty hard because specification->package is unable to find a matching package. Is there any way for me to use specification->package in a channel? Or do I need to rewrite my configurations to use package definitions directly? <mange>Obviously I can always move these definitions out of the way and make a .guix-channel which specifies some subdir which the "guix pull" call should build, but I don't want to do that for code organisation reasons. <gr1n>futurile: dont like vscode much but If I get a nice vim setup ill share <lilyp>mange: specification->package is more meant for user-facing code than internal thingys; you can get it to work if you have your modules resolved and loaded, but there's no guarantee when using it at "compile time" so to say <mange>lilyp: I expected that was the answer. I'm essentially taking some of my configuration files and putting them into my private channel for reasons, but doing so hasn't been quite as smooth as I'd hoped. It's not *hard* to rewrite things to avoid specification->package, but I have to contemplate which I prefer out of "move things around and set up .guix-channel to exclude them" or "stop using specification->package". <mange>need the whole chain of git authentication. <futurile>how is nixpkgs only 38MB, when they're so massive? <futurile>I read the article, it's interesting - and they have a few others on their blog which are worth reading about 'package management' as a problem space <mange>Maybe that's not the size of the channel file you pull down with "nix-channel --update". <identity>¾ of my ~/.config/guix/current is ccache <identity>not idea if nix counts ccache, if any, in that number <mange>ccache meaning .go files? If we didn't include them then a "pull from tarball" would still have to do the whole "compile guix" step before being usable, right? <mange>That's part of what I'd want to avoid, given how long it can take on underpowered machines. <mange>Again, I don't know how the nix channel pull works at all, so I should probably stop randomly finding files and trying to claim something. :P <mange>But in general: guix pull is a bit of a pain point, given it is quite slow. I just wonder whether we could, in principle, build and distribute signed tarballs as an alternate option? It's a different security/convenience trade off. <lilyp>note: `guix pull` is a `git checkout` followed by a "few" "small" package builds <lilyp>the reason it is so slow is that some of these builds are rarely if at all substitutable and thus happen entirely on your machine <lilyp>it's like you're back to using Gentoo :P <Guest21>I have the default SSH configuration. Why do I require to login on the machine so I can use SSH login with my other machine? I installed it through the installer with KDE. I don't understand, SSH is a system service not a home service <futurile>Guest21: sorry, I'm not totally clear what you mean? <futurile>Guest21: You installed sshd as part of your guix system configuration? <futurile>Guest21: or you're trying to ssh from guix to another system? <Guest21>futurile: It's okay, I have problems in describing. Basically I wonder why I can't just start the machine and login with SSH. I need to be actually logged in with my user on the physical machine, or else SSH is not working. Hope this is better explained <Guest21>and with SSH I mean, I don't want to login in that machine, I use a different machine and SSH in to the Guix machine <futurile>Guest21: hmm, yeah the SSH service should be running if it's part of your 'system' configuration. <futurile>Guest21: did you try and use ssh -vvv (not sure how many!) from your other system - see what it says <futurile>Guest21: I'd say 'key configuration' is the most common problem <Guest21>futurile: I need to go. Will respond later (thanks for helping bw) <acidbong>identity: futurile: Nix fetches channels and inputs only as tarballs, there's no way of initiating a git repo and make it track the upstream like Guix does, while maintaining build purity <acidbong>and Nix is purely an interpreter, there's no compilation artifacts after an evaluation <acidbong>also the current tarball of Nixpkgs, as downloaded from GitHub, weighs 46 MB (and 310 MB unpacked), Guix is twice as small <acidbong>even "pkgs.fetchgit" (one of origin fetchers in Guix terms) checks out the repo in a networked sandbox, removes .git and treats the source the same as an unpacked tarball, same with eval-time fetchers <futurile>acidbong: huh, interesting, thanks for the info. I guess they decided that git as a database wasn't useful. <futurile>acidbong: does Nix check there are signatures/checksums or something on what it's getting <futurile>acidbong: if you happen to know - I could always go look myself - but you piqued my interest <andreas-e>I do not think that the conclusions of the article apply to us - they end with saying that git is good for software, and we are software ;-) <acidbong>futurile: there is a git-powered database in .cache/nix, but it only caches evaluations <acidbong>no automatic signature checks, only if you customize a fetcher's postFetch phase (and invoke gpg/signify explicitly), and I'm aware of no `guix git authenticate` alternative (per-commit auth) <andreas-e>Moving from git to tarballs would imply storing one complete tarball per commit to make something like "guix time-machine" work. <bjc>has anyone successfully installed the 64bit hurd from the 1.5.0 installer? i'm getting an i/o error from ext2fs when it tries to open wd0 (the device exists) <trev>is there a reason why guix reconfigure needs to "look for substitutes" even when no new packages are being installed? shouldn't it be lazy? <futurile>andreas-e: I'm sure you're right, also who would do the code, it would be a massive change. Wish we could do something though heh <acidbong>trev: and no `guix pull` happened since the last reconfigure? <identity>trev: it is building the system profile, right? so guix tries to substitute the output before building it. or at least that is my guess <yelninei>bjc: Where did you install it? With qemu you'd need to pass '-M q35' (or reduce the memory to < 3584) <sunless>just discovered that you can view videos from the tty (with mpv), are there other gui applications that can run in the tty? <sunless>how can i use the gui version of emacs in the tty? <untrusem>you can't? there is tty version of emacs sunless <untrusem>theesm: hello, read your post an comparing drvs, most of the the stuff went over my head as i am starting in learning fundamentals but I got the idea of it :) <theesm>untrusem: hey there o/ hope my writing was okayish enough to follow (want to grow a habit out of writing sth technical regarding guix at least once a month), did you also try the utility? (always appreciate feedback on how to make the output more useful) <sunless>untrusem: i can't see specific tty version, for reference i'm using emacs-next-pgtk, i'm only forced to use the "emacs -nw" in the tty which can't view pdf's, images and emojis <untrusem>emacs need to have sixel lib inbuilt for that <untrusem>are you using a terminal with sixel or chafa? <sunless>i'm using the default guix tty, i think it's mingetty <sunless>why does mpv open videos in the tty then? <Guest21>futurile: I am back. I think I know why. The system is not connected via ethernet. Therefore I need to login, since GDM starts all the GUI services, which means NetworkManager, too. NetworkManager does create the WiFi connection. It would also explain, why it simply works in a VM. A VM is connected through "ethernet". I hate WiFi to be honest. <Guest21>Makes things more complicated than there are already <trev>identity: system and/or home <bjc>yelninei: ah, i was using 440fx, assuming q35 wouldn't work <bjc>yelninei: is uefi also ok? <yelninei>idk try if it works, i am only using the hurd-vm-service because I want it stateless and with guix-offloading support <bjc>also: does the hurd have a 'dmesg' equivalent? i'd love to be able to look at boot logs <yelninei>some things will be in /var/log but i think the kernel logs does not work on 1.5 yet (it works on master now) <bjc>as soon as i get guix installed i'll work on that =) <yelninei>there are currently still a lot of test failures for 64bit so dont expect to much <bjc>i'm not. i know this is gonna be pretty jank <bjc>i've been messing with the hurd for near 30 years now. jank is the expected value <futurile>Guest21: ah nice you figured it out - would never hae guessed that heh <futurile>anemofilia: did you check your underlying filesystem doesn't have problems and/or hardware <futurile>anemofilia: seems like that error is associated with hardlinking from a quick google search <bjc>i have been unable to produce a bootable hurd from the guix installer over uefi <bjc>not sure why. maybe uefi vars aren't being set. tianocore can't find the boot partition. guix does create it, though <bjc>dunno. didn't get that far <bjc>figured i'd give it a shot, though <anemofilia>futurile: guix gc runs fine, but doesn't solve the issue <futurile>anemofilia: all the ones I found are due to the source and destination being on different filesystems <anemofilia>futurile: Yeah, that's what I found too, I mentioned it on the issue. Thing is that I haven't made any changes in the fs since the last guix pull, and it used to work fine <futurile>efraim: are you holding rust crate updates somewhere? I saw you were dealing with an update to jujutsu and ofc I'd like to use it heh <anemofilia>futurile: Reconfiguring the system, as the link you sent suggests, solved it. Thanks :) <futurile>efraim: oh straight into master - ignore me <futurile>anemofilia: nice - no idea what the cause is, that thread seemed unclear to em <bdunahu>does anyone know why signal desktop hasn't been put in the main guix repository? Specifically, is it known to have non-free components, or is it just not feasible to package? <ieure>bdunahu, It's a bootstrapping issue, is my understanding. <bdunahu>sorry, can you describe a bit more on what that means? <bjc>yep, efivar won't built on hurd, so that's that. bios-only for now <bdunahu>ieure: is it a build system issue, since it's electron? <futurile>bdunahu: for something to come into guix both itself and all of it's dependencies have to be Free Software <futurile>bdunahu: so I guess electron is just so massive that trying to get that, and then everything it requires is an impossible/very-hard <futurile>bdunahu: so that's what ieure means - which is why it's available only in #nonguix <bdunahu>Okay thanks! If it is just something that isn't feasible to package yet I consider adding an external repo... but seeing as I also am not able to find it in parabola or trisquel, I will assume it is nonfree <bjc>dang it. fresh hurd install from 1.5.0 on guix pull: "guix pull: error: setting synchronous mode: unable to open database file" <janneke>bjc: that's "right", sadly guix pull isn't working/supported on the hurd; you may have more luck by pulling from a local tree: guix pull --url=$HOME/src/guix/master <janneke>ACTION is not sure if all dependencies for that build just yet, but we're very close <stikonas>janneke: hmm, I haven't checked but nix guys were claiming they have full x86_64 bootstrap working... <stikonas>(perhaps this is more suited for #bootstrappable though) <janneke>stikonas: yeah, that's what i've heard too <ekaitz>stikonas: at this pace they'll have riscv before we do <stikonas>it's a pitty they didn't upstream bug fixes... <janneke>well, they even wrote a bachelors thesis without pinging us? <janneke>stikonas: and meanwhile, stefan got the x86_64 bootstrap working, so we'll have that anyway <stikonas>yeah, and as a bonus that one was direct to tcc if I remember correctly <stikonas>skipping the need to maintain tinycc fork <janneke>(with possibly a small handful of patches to upstream, it depends) <bjc>janneke: got it, thanks. does the normal guix dev build process work (the pre-inst-env stuff on a git checkout)? <stikonas>well, a small number of patches is not too bad anyway <stikonas>if it's just a few of them on modern tree, not too hard to rebase <janneke>bjc: yes, that should work -- although i'm not sure if automake builds at the moment; there were problems with the test suite <simendsjo>I think I might have broken my system?! After a system+home upgrade, I deleted old generations as things seemed to be working fine. But I get PAM errors when running sudo/su. So I cannot reconfigure, and I have no older configurations because of my cleanup. Any other way to fix it than building an installation media and chrooting? <simendsjo>"su: pam_start: error 26" and "sudo: unable to initialize PAM: Critical error - immediate abort" <ieure>I don't have a good answer for you. <simendsjo>Logging in as root gives the same error as sudo. <ieure>Does the issue persist across reboots, or have you not done that out of fear that things will be even more broken after? <simendsjo>Oooooh... I see guix gc has deleted what /etc/pam.d linked to! ... that's pretty bad ... <ieure>simendsjo, Did you edit your config in between reconfigures? Feels like the latest one broke badly. <ieure>simendsjo, I know it's not helpful at this present moment, but I would recommend keeping the current generation when reconfiguring, and/or not gc'ing until you boot the new one. <simendsjo>ieure: I re-enabled rclone (and my dropbox service type) for my home configuration. So I don't think that is the cause. <ieure>simendsjo, It's the system configuration that's broken. <ieure>simendsjo, Unless you have the home service-type in your os config. <simendsjo>ieure: My system is from 20:03, and my uptime is from 20:40, so it's the same system. I didn't touch the system configuration. .... but come to think of it, I did first boot into an older generation because at first my wifi didn't work. But I couldn't see anything in the logs and rebooted again, and the wifi was back up. Then I did the cleanup.