IRC channel logs
2025-04-21.log
back to list of logs
<sham1>Oh, I just realised that it's called cuirass because it's a CI and it guards production, like an armour <RavenJoad>ieure: I have that happen to me too. I usually find its either because the server is overloaded (too many evaluations going on simultaneously) or it's just something weird and a "herd restart cuirass" fixes it. <ieure>RavenJoad, Super frustrating. <ieure>RavenJoad, In this case, it got wedged so hard that I removed the service, reconfigured, rm -rf'd the postgres data dirs, and stood it back up clean. But it's still not working right. <RavenJoad>Hmmm... Does a guix pull (or time-machine) of the channels relevant to that particular eval-job actually complete? <RavenJoad>I run my cuirass on a few-core VM, so I see weird things sometimes. <RavenJoad>I still need to fix mine too. I cannot get the web interface to come up. <ieure>There was a race for a while where the UI wouldn't wait for the backend, so would crash immediately when it tried to start. I think that's fixed now. <RavenJoad>Oh really! That might have been my problem. I could never get the web UI to start (even if I manually stopped it, started the backend, and then started the web UI). <RavenJoad>Perhaps I should reconfigure the machine again. <apteryx>has someone noticed that a wireguard service sometimes can fail starting, apparently because the network is not fully up? <apteryx>$my-domain is a domain name like example.com and $wg-port something like 50000 <apteryx>restarting the service after the machine has fully booted succeeds <apteryx>I guess it should depend on 'network-online', which so far is just a one-shot snippet in our manual. <RavenJoad>apteryx: Does the shepherd-service have (requirement '(networking))? Because otherwise, I have no ideas. Guix's & Shepherd's notion of something being available now is still somewhat of a mystery to me. <RavenJoad>ieure: I finally got around to figuring out my Cuirass issue. Turns out a misplaced paren in the channels list in the specifications caused a parse failure in the main cuirass fiber. <RavenJoad>This parse failure caused cuirass to "start" as seen by shepherd, but cuirass had exited, so the /var/run/cuirass/bridge socket was never created. <RavenJoad>Perhaps this should be a bug filed somewhere, since all of cuirass, cuirass-remote-server, and cuirass-remote-worker "started fine", but cuirass-web did not. <apteryx>RavenJoad: it already does have networking, yes <apteryx>I think it may be because I've used a host name instead of an IP address; maybe. <apteryx>I guess it if happens on every boot I'll test the networking-online one-shot as a shepherd requirement to my wireguard service to see if it cures the problem. <apteryx>I'm trying to test the 'start-service' from (gnu services herd) against my unprivileged user Shepherd instance, but getting a permission error: "In procedure connect: Permission non accordée". Something like: guile -c "(begin (use-modules (gnu services herd)) (start-service 'emacs))" <apteryx>ah, it uses a %shepherd-socket-file parameter which defaults to "/var/run/shepherd/socket" <pastor>The thing we are not sure about is this line here: <pastor>This GPLv3 software makes a curl call to fetch a javascript source code. Does the GPLv3 license cover the file fetched with curl? <meaty>There is no actual documentation on how to split packages that are too large. there are pages for 'guix size' and how to specify output in manifests, etc. and the cookbook shows a package defs with outputs that do nothing <ruther>meaty: What do you mean that the outputs 'do nothing'? <meaty>ruther: I mean the package def in the cookbook 'Extended example' page defines (outputs '("out" "debug")) but doesn't actually refer to those outputs again anywhere else in the def <ruther>meaty: right, because out is the default that everyting builds to, and debug is a special meaning one that is taken care of by gnu-build-system's strip phase <meaty>Is there a way to make certain inputs only be used by certain outputs like the guix-size page suggests? <meaty>or is it just for partitioning off data for that package in particular <ruther>meaty: uh. Kinda. They are still necessary for the build. But as long as the output doesn't reference the inputs, they are fine for gc collection. <ruther>meaty: if your goal is to not require them at all, that would warrant a new package definition that builds only something, it's not possible with outputs. <ruther>meaty: The outputs are all to be built with guix build, it's not possible to build just one, that is because of how the outputs work - you just copy from the build folder to the output folder during the build. <meaty>my goal is to make a package ultimately take up less space on the sytem. I'm updating beets, which has a 2218.2 MiB closure, 943.6 of which is due to an optional feature according to guix size. <meaty>how do I associate a package input with an output, then, so that they can be gc'd if i don't use that output <ruther>meaty: you don't associate inputs with outputs <ruther>meaty: if the output won't reference to it anywhere, it won't be treated as reference at all, so it's fine for gc collection. <ruther>meaty: it's like if you put a random package to inputs of your package, it will be required for build, but as long as that package is not used by the build at all, it won't be reference of that store path, so it's fine for gc collection. <meaty>ruther: so guix "automagically" detects which outputs link, import, call etc. different imports? <ruther>meaty: I wouldn't say 'automagically', it's just scanning of the output to pick up what the references actually are. <ruther>meaty: it's quite simple, really <ruther>meaty: it's the daemon that does that, Eelco Dolstra is covering it in their thesis. <meaty>ruther: interesting... and this works with arbitrary languages and encodings? is it just calling "strings" or is it more than that? <meaty>how does it sort out propagated/"runtime" inputs <ruther>meaty: it just looks through the contents, like if it was text files, scanning for the gnu store paths that can be there (all the inputs), and ignores the rest. It doesn't matter what language it is then <ruther>meaty: propagated inputs aren't taken care of by the daemon at all. It doesn't know what 'propagated' inputs are. It's the packages that have this information inside themselves. <ruther>meaty: the same goes for native-inputs, if you reference native input in the output, it will be picked up as reference by the daemon. The daemon doesn't know nor care what 'inputs' they are <csantosb>Ey Guix ! I'm afraid offlineimap broke with the upgrade to python-3.11, see #77952 <lilyp>csantosb: I pushed some of your emacs-team patches, but am too lazy to do the bookkeeping around them <lilyp>feel free to close their issues at your leisure <sozuba>Hi, I tried guix a few months ago and loved it, but the one thing that led me to take a different path is it being primarily source based. Has there been any change toward having a binary repo? <sozuba>i have a very low spec laptop as my daily driver and only machine. So compilation and stuff is too hard on it, and so would love to have a binary option <ruther>sozuba: no and there never will. That is point of Guix that it's source based... It's impossible to use it without the source, because you don't know which path is which in the store. <ruther>sozuba: you don't need to compile anything if you use the substitutes, and make sure to stay on commits that have substitutes available already. <sozuba>ruther, thank you for your response. Fair point. I did come across substitutes, but i think at that point in time i didn't full understand. So, now i can build an entire system from substitutes? for all the common and major packages, including browsers, etc? <ruther>sozuba: the only thing you can't build is the things specific to the system itself - the store path that contains merge of all the packages, your grub config etc., but all those are just created with simple build scripts that symlink files or write easy text files. <ruther>sozuba: so you can substitute all common and major packages, including browsers <ruther>sozuba: this goes for the Guix channel, if you're going to use other channels, you need to check with them if they have substitutes and what for. <sozuba>ruther, understood, i will give it a try <sozuba>so the building of store paths, grub configs won't be cpu and disk intensive like compiling packages right? <ruther>sozuba: it shouldn't be. And takes just a few seconds on modern hw, depending on how low-spec we go it might be more than that, like 20 seconds or something... <sozuba>is there a way to search for substitutes on a substitute server? <ruther>sozuba: I am not sure I understand what you mean. There is the `guix weather` command that can tell you what is substitutable for the guix revision you're using. <csantosb>lilyp: By the way, is there any schedule for merging with master ? <lilyp>I would have to check how many packages are still failing <lilyp>last time I recall we look quite a lot better than we previously did; thanks also to your effort <sozuba>ruther, got it. also realized how wrong my question was, these are not just packages, these are just substitutes for packages built for a certain environment (matching local build results) as such can't be universally searched, but instead i can search from within the environment using 'guix weather' on what is available. <ruther>sozuba: Exactly, it's like a big /gnu/store, you don't really know what paths you want without the source. <futurile>Oh worth noting - the comment period for GCD002 "Migrating repositories, issues, and patches to Codeberg" ends on Wednesday (23rd) <futurile>just realised as I was doing something else <futurile>see guix-devel for the giant discussion thread heh heh <lilyp>yeah there was an announcement <kyoji>does anyone here know what the cadence is (if any) for upgrading the GNOME version? Version 46 is currently offered. I looked around and couldn't find any discussion about upgrading the package(s) to 47 or 48 <PotentialUser-4>I am unable to `guix pull` as it returns the error guix pull: error: Git error: SSL error: syscall failure: Resource temporarily unavailable. It seems like nobody on the internet knows the solution to this. <futurile>PotentialUser-4: it looks to me as if the gnu.org infrastructure is having a bad day, if you've only just had this problem maybe it's that - "Resource temporarily unavailable" might mean that <PotentialUser-25>Would someone care to share their opinion on this, and correct me if necessary? <ruther>PotentialUser-25: it already has python as a dependency, but python package doesn't provide 'python' binary, it provides 'python3' <ruther>PotentialUser-25: so the correct fix here would be to convince the package to use 'python3' instead, usually with a configure flag or make flag <ruther>PotentialUser-25: upon checking the source, setting PYTHON=python3 make flag could work <ruther>Probably, I didn't actually try building it yet. <PotentialUser-25>It looks "simple enough" that I think I could manage it. If I had the time. And adhering with the Guix best practices is also something I need to work on. <PotentialUser-25>One more question, isn't there an automated testing environment where the derivations are testes? <PotentialUser-25>One more question, isn't there an automated testing environment where the derivations are tested? <ruther>PotentialUser-25: there is a CI that builds them, so it's possible to check, but there isn't really a strict rule about everything building. <ruther>PotentialUser-25: so it happens that maintainers sometimes merge even something that break some packages. <PotentialUser-25>Is the CI used only for some packages that are more relevant, or is the output of the CI disregarded on some packages? <ruther>PotentialUser-25: The CI builds all packages, all packages will get substitutes thanks to that. <ruther>PotentialUser-25: I think there just aren't really clear rules on how to treat new build failures. Moreso I don't think the CI can actually tell you a package has just become broken, so it might be harder to track down if the breakage came from a particular change the maintainer is merging <PotentialUser-25>About the new rootless build daemon, I suppose it ought to be safe for Guix systems that have few changes. Would I be right? <futurile>looking at the python-team merge it broke a lot of packages; I think the r breakage was known though - it's quite a few packages <ruther>PotentialUser-25: Sorry, safe in what way? <PotentialUser-25>Oh, I now see I was not explicit. Safe in "my system will continue to work without incidents or needing changes". <PotentialUser-25>futurile I was happy when I saw that a new version of Python was now available. So, things are not fine with this version update? <ruther>PotentialUser-25: If you're on Guix System, yeah, it should be safe, but I can't really say it's guaranteed, don't see any tests for it. <ruther>But there shouldn't really be anything else done manually apart thanfrom changing the configuration <csantosb>futurile: branches are not built before merging them ? I understood this mechanism aims at avoiding this kind of problems. <kyoji>futurile: thanks, I've seen the tag and was just making sure i wasn't missing some discussion happening elsewhere, appreciate it <the_tubular> What is the easiest way to run guix daemon as user ? <the_tubular>set the `privileged?' field to `#f' where is that field ? <ruther>the_tubular: in guix-configuration <ruther>the_tubular: no, it's the value of guix-service-type, you need to edit that service in your services field list <the_tubular>So something like (service guix service type (privileged #f)) ? <ruther>the_tubular: no, you're missing the guix-configuration constructor which should have privileged? inside. But even so, you probably have desktop-services or base-services, and this service is in them, so you need to use modify-services. <PotentialUser-90>Hello I need help for config.scm. I am trying to install my first system and in three days I will not be able to do it. I have never used irc chat. <ruther>PotentialUser-90: so what are you struggling with? <ruther>PotentialUser-90: no, use paste.debian.net for uploading a lot of text <PotentialUser-90> (initrd-modules (append (list "vmd" "dm-mod" "dm-snapshot" ) %base-initrd-modules)) <ruther>PotentialUser-90: please use paste site, do not send a lot of text here. Your messages got trimmed <ieure>PotentialUser-90, If you're using non-free kernel/firmware/etc, you'll have to ask for support from whoever provides that stuff (#nonguix probably). <ieure>Assuming your problem is with those parts. <the_tubular>How do i know if I should just append a service or modify it ? I guess I just have to list what is in base services correct ? <ruther>the_tubular: yes, you can't have the same service twice <ieure>PotentialUser-90, What problem are you having? <ieure>the_tubular, If the service supports extensions, that should handle either case. <ruther>the_tubular: easiest is to grep the source probably, or you could use the repl <ieure>the_tubular, What service are you modifying, what do you want to change? <PotentialUser-90>Can not build the system, can open luks drives but can not mount lvm root <the_tubular>Was trying to test the new unpriviledged guix daemon <ruther>PotentialUser-90: Your configuration doesn't say anything about LVM. Also LVM root is not supported on Guix System <the_tubular>I'd like to see where it's defined in the source code if possible <ieure>the_tubular, The guix daemon is in %base-services on all Guix System installs. <PotentialUser-90>I went through manual, chatgpt, deepseek. I have not seen a statement about no lvm root. Are you sure about that. <the_tubular>Yeah, i use base-services, but not desktop-services, was curious what was in both <ieure>the_tubular, It depends. gnu/services/base.scm and gnu/services/desktop.scm should have their definitions. <the_tubular>ieure, what do you mean about supporting extension ? <ieure>PotentialUser-90, LLMs are useless, especially for niche stuff like Scheme / Guix. I would recommend not wasting your time with them. <PotentialUser-90>Okay, but no lvm root is deal breaker for me, are definetly sure about that. I have trying install guix, learned scheme and read the manual but no lvm root, I will quit guix for now <ieure>the_tubular, Many Guix services support extension, which solves the "do I update or add" problem. So if you want to set an environment variable in Guix Home, you can do (simple-service 'set-variable home-environment-variable-service-type '(("VAR" . "some-value"))) <ieure>the_tubular, vs. creating one instance of home-environment-variable-service-type which centralizes every environment variable. <ieure>This lets you add services that do the specific thing you want, and will do the right thing whether there's an existing service of that type or not. <ieure>But it has to be supported by the specific service, and not all support it. It doesn't make sense for every service too, but I think the guix service ought to support it better. <ruther>the_tubular: It's not, guix-service-type supports extensions of only authorized keys and substitutes. <ieure>the_tubular, Anything that doesn't have meaningful configuration, probably stuff like urandom-seed, host-name, etc. <ruther>(also extra chroot directories and build machines) <ruther>the_tubular: I would say that extensions make sense mainly for list types where you can append to them, they don't make much sense on stuff like true/false fields, where you can't be sure what will end up in the field if multiple services extend it... <mrh57>not unheard of build problem, sbcl is trying to create some directory in the store which it doesn't have permission to do <ieure>mrh57, I think it's the (uiop:ensure-pathname "/gnu/store/rsx3ws29hm7yz2aldv56qv15a9iqayp1-sbcl-taglib-0.0.0/share/common-lisp/sbcl/taglib" :truenamize t :ensure-directory t) call in the SBCL commandline that's breaking stuff. <the_tubular>Sorry about that, at this point should I not even pull base-services and just start every services by myself ? <ruther>the_tubular: why do you want to do that? <the_tubular>If I have to fight between starting and modificating services and which ones supports it and other stuff <ruther>the_tubular: I don't really understand what you have to 'fight' with <ieure>the_tubular, You don't have to fight with anything. If you want to change the guix daemon configuration, you need modify-services. The guix daemon is essential to Guix System and will always be in your services list. <ieure>For 99% of other cases, use service extension. <ieure>I don't understand what you have to "fight" here. <the_tubular>It's a bit hard for a beginner to know why some services are not managed the same as some others <ieure>I don't think anyone is insulted, just don't understand what the conflict is. <the_tubular>You are probably right, once you know your way around guile, that's a non issue <ieure>There's a definite learning curve. I also think the Guix manual does a poor job explaining service extension. <the_tubular>Do you know of anything that does a better job at explaining it ? <mrh57>ieure: hm that line itself runs fine (and looks okay to me), its only on the (require :taglib) where the error occurs <mrh57>ieure: actual error being "Can't create directory /gnu/store/dgsnjc7h0ff27ikvb2p00g4sss77kvk9-sbcl-optima-1.0-1.373b245/lib/common-lisp/sbcl/optima/lib" <mrh57>cl-taglib .asd deps are actually (#:optima #:optima.ppcre ...) <mrh57>the package inputs are (sbcl-optima sbcl-cl-ppcre ...) <ruther>mrh57: is the build trying to create directory in one of the inputs? <mrh57>interesting optima.ppcre isn't packaged, hopefully packaging it should work <weary-traveler>is it possible to wrap a package in guix without requiring a full rebuild of the package being wrapped? i want to define a custom wrapper for emacs that sets some environment variables without having to rebuild it locally <ieure>weary-traveler, Make a package that takes emacs as an input and outputs the wrapper. <ruther>weary-traveler: I think the most straightforward way is to utilize union-build to copy everything from the old one, then you can do the wrapper. But note that you might need to replace path to the binary in the .desktop files if you're using those. <futurile>csantosb: yes packages are generally built for a team branch before they are merged into master. It's one of the reasons we have a log jam sometimes (because we don't have enough resources to build more than 2-3 branches). I don't believe python-team was showing so many packages failing, so not sure - Sharlatan probably knows what's happened. <untrusem_>getting `sdl_renderer: Couldn't find matching render driver` while running any roms <mrh57>I've in an odd state where in SBCL I can (require :optima) without having optima in my config? 100% of my packages are installed via guix system + guix home <mrh57>optima is in /gnu/store/... as a dep for other sbcl packages, and I can see some of those paths that are being looked at by asdf via (asdf/source-registry:default-system-source-registry) <mrh57>regardless when I (require :optima.ppcre) I get the error I posted a bit ago: "Can't create directory /gnu/store/<hash>-sbcl-optima-1.0-1.373b245/lib/common-lisp/sbcl/optima/lib" <mrh57>which is identical to the error produced on the build side <ieure>I see ASDF will hook into REQUIRE, but it's implementation-dependent. <mrh57>ieure: it's loading optima.ppcre which fails (I just double checked with '(asdf:load-system :optima.ppcre)') <mrh57>ieure: loading the :optima system works <bdju>Okay, *now* I find something that broke since last reboot. My compose key in Sway isn't working and has returned to being a capslock for some reason. I think this has happened before, but I don't recall how I fixed it. <ieure>bdju, Are you using the xmodmap home service? <bdju>I'm not using Guix Home at all, as far as I know. <bdju>I have this line in my Sway config in a section for my specific input device: xkb_options compose:caps <bdju>Ah, I should verify my keyboard still shows up with the same ID and stuff, I think that might've changed on me once. <mrh57>bdju: not sure exactly how sway works, but my config has an 'input "type:keyboard'" for keybind switches <bdju>Yeah, so you can do that for global settings, which I have some of (like changing repeat rate of keys), but then I set the keyboard layout per-keyboard so I can have my external keyboard be normal us qwerty layout (because I have it set up for Workman in QMK) and the laptop's internal keyboard be Workman layout. <bdju>I have not touched this config in ages and unless Sway had a breaking change, it should be fine. <bdju>It seems like the compose key on the internal keyboard is working fine. <ieure>mrh57, I can reproduce your problem, and I think it's a package bug. It ships lib/ppcre.lisp, but doesn't ship a .fasl for it. I think when ASDF loads the system, it triggers compilation, which tries to create the output directory, which fails. <bdju>Ah, I replugged the keyboard and now it's working... Maybe that's what I did last time also. <ieure>mrh57, I believe the package should ship .fasl files for any Lisp source. It only ships them for files in src/, and PPCRE support is in lib/ <ieure>mrh57, Not sure why it's doing that. Worth a bug report. <mrh57>ieure: Thanks for taking a look. What do you mean by shipping a .fasl? I don't see any .fasl files in the repo, for either :optima or :optima.ppcre? <mrh57>ieure: also sad the repo hasn't been active in 10 years and was archived 7 years ago (I suppose trivia is more popular for new projects) <ieure>mrh57, FASLs are compiled binaries of the Lisp source, you don't see them in the source repo for the same reason you don't see .o files in the source repo of a C project. <ieure>mrh57, But if you run `find $(guix build sbcl-optima) -type f', you'll see that there are .fasl files for everything in src/ and nothing in lib/ <ieure>So that's what I think is wrong, when you load the system, it looks for object code, there is none, so it tries to compile the .lisp file, but can't write it into the store. <ieure>Well, FASLs are what SBCL uses to cache object code, probably other implementations do something else. <mrh57>ieure: ah okay, so the problem is with the asdf-build-system/sbcl not ceating .fasl's from any source .lisp files which aren't in either the source root or src? <ieure>mrh57, Well, there are no .lisp files in the root of that repo, but yeah, it's not compiling all the source. <mrh57>ieure: right yeah not in this case <ieure>mrh57, Someone who knows the asdf-build-system better would probably know what's wrong. Docs say it'll handle any system with an .asd file in the repo root, and it does find the system, just doesn't compile the files. That smells like a bug to me. <f1refly>I had an issue with my rtc battery, booted my system with wrong time and now it's doing weird things <f1refly>when I type "sudo -s" in a shell in my desktop environment and enter my password it just seems to hang forever <f1refly>this persists even now that the clock is set correctly <f1refly>shepherd definetely hung at 100% on a core on one of the boots, but it stopped now <jA_cOp>did you get the RTC working again? if you can write the current time to the RTC, you should be able to reboot and have it working normally again <jA_cOp>if your RTC is not working, can you set the system time in the BIOS before booting into Guix? <mrh57>ieure: good call, I'm gonna clone the repo and do some testing <f1refly>I set the roughly correct time in my bios, ntpd set the correct time after connecting to the net <f1refly>but sudo still hangs after I type my password <jA_cOp>yeah, I don't think you can really do anything but reboot, considering the bug is in PID 1. It's pretty awful, happens now and then on my laptop that doesn't have a separate RTC battery <f1refly>I was able to get a root shell on a different tty, but I'm not able to run herd or shutdown there <f1refly>so my only option would be holding the power button <f1refly>but it still won't let me shutdown normally <jA_cOp>yeah, you won't be able to shutdown normally <jA_cOp>to make sure the time is written to the RTC, you can run `hwclock -w` from a root shell after ntpd has updated the system time <f1refly>that was properly scary, not gonna lie <jA_cOp>yeah, honestly that's been the roughest corner of Guix I encountered so far... np