IRC channel logs
2025-12-21.log
back to list of logs
<redacted>Is there an existing automated way to check for unused imports in Guile modules? <loquatdev>What would be the best place to start with optimizing a Guix system? I'm experimenting with running Guix on lower-end devices. While it seems to run great, it also seems to use more RAM. I'm not sure if there's actual performance issues or if it's just different forms of caching since Guix is more disk-based in how it uses the store. What <loquatdev>experiences have you all had with optimizing Guix and/or using it on low-end devices? <sneek>Welcome back loquatdev, you have 1 message! <sneek>loquatdev, ieure says: The command a shepherd service ran is in the output of `herd status SERVICE'. <nomike>For that, I've added nss-certs as an input to prusa-slicer and I'm using `(assoc-ref %build-inputs "nss-certs")` to patch the file. However, prusa-slicer seems to need a single .pem file merging all the CAs together. nss-certs unfortunately only provides individual files though. On my foreign Ubuntu distro they also provide the file /etc/ssl/certs/ca-certificates.crt which contains all valid root CAs. How is this usually solved on <cbaines>noneofyourbusine, not much activity, I still need to rebase and migrate the patches I previously sent to Codeberg <cbaines>and I'm stuck bashing my head against the data service at the moment <ity>Installing Guix system is really difficult for me ... <ity>I was even a Nix trainee for half a year. <ity>yelninei: Why are you online? Is it a bot, a coincidence, or...? <Rutherther>ity: Asahi is not officially supported, so you might want to seek for help elsewhere. I don't think anyone here would be able to help. Also it seems their readme has outline of the installation <ity>yelninei: Sorry~ I saw a lot of people suddenly online, but many of them don't reply, lol <ity>Rutherther: Isn't this the largest gathering place for guix users? <yelninei>x86_64-gnu seems to be out of commencement now on ci, it wont get far from there but thts atleast something. for i586-gnu gcc-final is substitutable and it seems to work through the rest <Rutherther>yelninei: I am seeing some Failed (dependency), while no dependency displayed is failing, so that confuses me a little <yelninei>Rutherther: Maybe it has not realised yet that the dependency is now available? cuirass is also a bit confused because it goes through 2 layers of offloading <Rutherther>yelninei: could be, hopefully it will get restarted automatically then <bdju>If I'm missing some of the commands needed to run the guix installer on a foreign distro, is there anything I can do? > [ FAIL ] Missing commands: groupadd groupdel useradd userdel newgidmap. <bdju>It's a rather minimial and niche distro for ARM devices with no package manager and I was thinking if I could get guix on there, maybe I could then easily install more stuff. <identity>bdju: you need to install shadow-utils first, however you will go about doing that <Rutherther>bdju: the only other way would be doing the install manually, copying the steps from guix-install.sh, replacing the groupadd etc. with the commands you do have available, even if it meant editing of /etc/passwd and /etc/group for example <Rutherther>as for newgidmap I cannot really say for sure what it's used for, but from my experience if it fails, all still runs, so with that one you could just symlink it to /bin/true <Rutherther>but you might be missing out on some features, I don't know exactly <yelninei>Rutherther: i586-gnu is also out of commencement now. <Rutherther>Yay, I presume that could mean that the final inputs self contained check could now be working (with changes in #4979), it's been failing make distcheck <Rutherther>I am also trying to get riscv64 out of commencement, it failed on gcc for unknown reason, so I restarted it <Rutherther>no, just cuirass-supported-systems and that's %supported-systems minus powerpc (32bit) and mips <Rutherther>yelninei: I know, but I am hopeful it could succeed maybe :) <Rutherther>the final inputs for riscv64 are substitutable from bordeaux at least, but I would like if CI was able to catch up so that it could produce a guix binary tarball for riscv64 for the release later on <yelninei>ACTION is glad to not have to worry about accidently gc-ing the hurd gcc-finals <basicnpc>Hello! I use desktop service in my system config, so in tty1 I was greeted by a login UI (with Guix logo on the screen). But after I login, the screen just turns black and nothing happens. <basicnpc>Then if I switch to tty2 and back to tty1, I was sent back to the tty login interface.. <Rutherther>what greeter are you using? most on Guix are on tty7, not tty1 <Rutherther>anyway, it would be good if you looked in the /var/log/messages for errors, presumably for "xorg-server" service <basicnpc>I am trying to use sway, and I just put %desktop-services into my system.scm.. <basicnpc>Oh, I see. I thought that was on tty1, but it's indeed tty7. Soon after booting I was switched to tty7 automatically. <basicnpc>So logging in via that UI would send me a dark screen, hanging there. Switching to other tty and back.. it would prompt me with the GUI login interface again. <identity>basicnpc: gdm can not see sway because it is not installed system-wide <identity>you can either add it to your system.scm, or, better, remove gdm from your system.scm and just log in at the console and «exec sway» from there <identity>there is also (info "(guix) Sway window manager") <identity>also note that swaylock does not work correctly by default, see ‘screen-locker-service-type’ under (info "(guix) X Window") <basicnpc>So should I get rid of %desktop-services from my system.scm? I tried that, but guix starts to complain many things are not provided.. and I didn't know what to do. <lilyp>basicnpc: given a specification like "glib:bin" it not only gives you the package, but the output as well <identity>basicnpc: you can use ‘modify-services’, see (info "(guix) Service Reference") <identity>basicnpc: also see (info "(guix) Packages with Multiple Outputs") <RavenJoad>I am updating a package that searches $PATH for some programs. I can substitute some of the searching with a store path. Can I assume that rm, mv, and generally coreutils are in $PATH at runtime and do not need to substitute* the program's source? <cbaines>referencing dependencies with absolute filenames is preferable, but you can also wrap with a PATH containing coreutils/other binaries if using absolute filenames isn't feasible <RavenJoad>That's what I thought. I'm not sure which will be easier. I'll have to look at wrapping first, since several lookups like that happen. <yelninei>Rutherther: Are you sure the the self-contained-check is correct? For the hurd targets i would expect it to fail because of guix/guix#1783 <Rutherther>yelninei: not at all, I am not sure, I didn't really have time to check it thoroughly <yelninei>the reference is only indirect via propagation of the headers and hurd-minimal. I dont know how to solve this though <hanker>Is there a way to modify Shepherd's `default-environment-variables` at runtime? <hanker>I tried `herd eval root "(default-environment-variables (cons* \"WAYLAND_DISPLAY=$WAYLAND_DISPLAY\" (default-environment-variables)))"`, to no avail. <yelninei>it isnt in practice , but still glibc-bootstrap is required for every package because of it which does not seem right <Rutherther>yelninei: as in, if you do 'guix build hello', the build environment of hello is going to have glibc-bootstrap? <yelninei>Rutherther: Yes and no. the build environment has hurd-minimal via hurd-core-headers which links to it but it it is not used for anything else <Rutherther>yelninei: looking into the self contained check, it checks only store path references, so yeah, it won't catch anything that's just propagated, but not referenced by the output <RavenJoad>When writing the programs to add to $PATH with wrap-program inside of a phase, what is the preferred way to get at programs? (assoc-ref inputs ...) or a gexp for the program? <Rutherther>RavenJoad: neither, search-inputs-files should generally be the most preferred one. After it I would say this-package-input <nomadnomaxx>im considering switching to a gnu-first distro because im thinking of minimizing corporate surveillance <nomadnomaxx>thought id join guix for sum of dat advice, since guix is one of the distros i am considering <nomadnomaxx>ive heard that people commonly have issues with linux-libre distros in terms of hardware support, especially when it comes to wifi cards <RavenJoad>Rutherther: Even for things that come from coreutils? I guess explicitly spelling out the coreutils programs mu relies on is not a bad thing. <RavenJoad>nomadnomaxx: There are additional channels which offer full Linux. <identity>i know of a channel, singular, they have a channel: #nonguix <nomadnomaxx>i'll come back if i need something else to know from yalls cya <Rutherther>RavenJoad: Oh, sorry, you were just asking how to get it in the PATH, I thought you were substituting them. I would say substitution is generally better, especially if the program you're working with is starting other sw, because then it inherits the environment <Rutherther>RavenJoad: but for PATH only, I would say this-package-input is preferred to assoc-ref or gexping #$coreutils directly. Because that way you can easily replace it <Rutherther>(comparing #$coreutils with #$(this-package-inputs "coreutils") you can easily replace them. Comparing assoc-ref vs this-package-input, the latter is the newer style working with gexps which are generally preferred) <RavenJoad>Rutherther: The problem with substituting the program name strings is that the lookup will still happen in $PATH. In mu, there is g_find_program_in_path("prog"). If I substitute "rm" for "/gnu/store/...-coreutils/bin/rm", $PATH is still searched. Hence, the need for wrapping. <Rutherther>RavenJoad: I don't think that implies need for wrapping - why not substitute whole g_find_program_in_path("prog") with the known path for prog? <RavenJoad>Rutherther: Yeah, that could be done too. That would be a little trickier, because of C++ reasons. <noe>Rutherther, very sorry for making you wait I’m taking a look now <noe>I think I might be sick <Rutherther>noe: no worries at all, I think I figured it all out afterall <ElephantErgo>Hey Guix Gang, I'm having quite a bit of trouble with getting a "guix system reconfigure"able config working on my PineBook Pro, and I'm going a little nuts. Can anyone help me figure out what's going wrong? I run "init" on the config and it's bootable, and then I run "reconfigure" on the same config (with adjusted paths for the bootloader to correspond to the same disk under /dev/), and then it doesn't boot anymore 😕 <ElephantErgo>I will provide the config in question on a paste site in just a moment <noe>ham5urg, use (recursive? #t) option in the git-reference <noe>there doesn’t seem to be any submodules in the repository you’re using 🤔 <Rutherther>ham5urg: you're using wrong git-fetch definition, because you're using (guix build git) module. YOu typically don't use "(guix build" modules like that in files with package definitions. <Rutherther>ham5urg: other than that there are a couple more things wrong with your definition. You should never hardcode paths to the store, rather you should add them to inputs and refer to the inputs. That means you would use for example "(arguments (list #:configure-flags #~"(,(string-append "-XYZ=" #$(this-package-input "spirv-llvm-translator"))` <Rutherther>ham5urg: next is that usage of @@ is typically discouraged and not necessary at all here, llvm-16 is exported, so you can just #:use-module. You could at least use just single @ which refers to public symbols <Rutherther>ham5urg: also, you shouldn't typically put gcc to native-inputs, it can make sense under some circumstances, but I would be surprised if these were satisfied. And you also should not mix gcc and clang like that, it has very low chance of success <ham5urg>Rutherther, yes, in parts. I try to learn how to write a package definition. Got a Intel GPU to play around. Would like to use Guix for that. <Rutherther>ElephantErgo: what's the output of "fdisk -l" on that machine? Also how exactly did you change the config from the one you had on init? <ElephantErgo>Rutherther: I'll unfortunately have to generate a new image using "init" real quick in order to see the results of that command. Let me see if I can bang that out real quick <ElephantErgo>Rutherther: The only change is that "sde" becomes "mmcblk1" <ElephantErgo>Rutherther: So this config is used to deploy a system to an SD card. I create it from an x86 desktop running Guix, and insert it into the Pinebook Pro to boot. After running reconfigure, the SD Card is no longer bootable, so I don't currently have a system that boots on the PBP for running fdisk on <ElephantErgo>Rutherther: I could certainly insert the non-booting SD card into my desktop in order to see how it's laid out, though. Let me try that real quick and give you the paste for that <Rutherther>ElephantErgo: are you able to see any boot logs from the device or not at all? <ElephantErgo>Rutherther: TOWBoot provides something along the lines of not 'finding a partition table', but let me attept a boot with the bad SD Card and get you what it tells me verbatim <ElephantErgo>Goodness gracious, what a mess. With God as my witness, this was not booting last night. <Rutherther>the SD card started touching the pins on the board? :D <Rutherther>ElephantErgo: note that the image example in guix repository has 16 MiB offset at the start of the disk, while you seem to have only 32 KiB. Not sure if that could cause issues later on <ElephantErgo>Aw man, yea, I'll have to see if I can fix that. I tried setting it in GParted, but it kept throwing a tantrum with it either wanting empty space at the end, or at the beginning, but not both. I really ought to learn some command line tool for setting the byte counts more accurately. What would you recommend for that <Rutherther>why didn't you generate the image and just dd it on the sd card? <ElephantErgo>The reseating thing is what's confusing me the most. A proper reseat was my first thought, but the same seating that allowed the first successful boot didn't seem to allow the second <ElephantErgo>The only other thing that changed is that I disconnected a USB hub I was using for networking. And honestly? I could see it being a culprit, who knows... <ElephantErgo>I ended up writing my own image specifically because I wanted to battle test something as close to the reconfiguration step that I was having failures at as possible, which lead me to partition my disk by hand <Rutherther>since you used guix system init you don't seem to have used images in the first place <ElephantErgo>That is correct. I used the image at one point in time, but I did it by hand on later passes <ElephantErgo>Man... Is there any chance I can safely move the first partition so I don't have to take all the time to recompile what I'm missing? What do you think about that? <ElephantErgo>Also, thank you a bunch for your help with me, it's been really nice 🙂 <Rutherther>I am not sure, it's always risky, though it should be supported <ElephantErgo>I think I'll try that gamble rather than risk having a reconfigure in the future toast my system unexpectedly <ElephantErgo>Ok, well... I figured it out, kinda... If the AC adapter is plugged in, it can't find the SD Card. I have no idea why. <ElephantErgo>This is the first time I tried a boot disconnected from the wall. <ham5urg>I changed the file a bit, I hope it is now in better shape. Now I get an ERROR: In procedure %resolve-variable: Unbound variable: gexp <ham5urg>I have a #:use-module (guix gexp) . Idk why I got that error. <cbaines>ham5urg, because the gexp module isn't available in the build environment <cbaines>you probably want to change the quasiquoted arguments for a gexp <ham5urg>(string-append "-DSPIRVLLVMTranslator_DIR=" (package-output (this-package-input "spirv-llvm-translator") "out"))) is my current guess but it does not work <Rutherther>ham5urg: juts remove the quasiqote, the ` you have after (arguments <Rutherther>and no, do not use the package output, #$(this-package-input "spirv-llvm-translator") will already give you the out output <Rutherther>ham5urg: that's the default, so the -D option you came up with doesn't have any effect it seems <Rutherther>I am not sure, I am not that experienced with cmake