IRC channel logs
2026-01-03.log
back to list of logs
<abbe>nevermind, I figured it. :) <gabber>can i do what "mixed-file" does but into a string? i need to reference alsa-lib (a package output) in a system service configuration <ieure>gabber, No, but you don't need to do that. <gabber>so, what's the Guix way to achieve that? <gabber>i've never gexp'd and ungexp'd outside of package arguments (i think) <ieure>gabber, For the field that has the package, write a serializer which returns a gexp like #~(string-append "ThingPath " #$file-like). Then create the config file with (mixed-text-file "my.conf" (serialize-configuration config)). <gabber>unfortunately i want to fill in the extra-options (a string) field of alsa-configuration <Rutherther>hah that's unfortunate, the alsa config file is using mixed-text-file but unquoting the extra-options. I think we should change that <Rutherther>there is a way to do what you're asking for, gabber, however, it's not a good way at all, it would require opening a store connection yourself. Really the proper solution here is making it support gexps <gabber>Rutherther: i'm absolutely up for that! <ieure>Rutherther, Semi-related, I'm close to a solution on that profile question from the other day. Here's where I'm at: <ieure>(derivation->output-path (run-with-store (open-connection) (profile-derivation (packages->manifest (list (car (assoc-ref (package-native-inputs collectd) "python")) python-mpdmetrics)) #:hooks '() #:locales? #f))) <gabber>so i'll have to gexp/ungexp alsa-config-file instead of the quasiquote? <Rutherther>ieure: hm, that seems rather complicated to me, I would expect ungexp on the profile to just work. Or... I am sure it does work, I have used it in the past <ieure>Rutherther, I'm not sure what to do with this profile record like you were suggesting. The profile-search-paths procedure doesn't take a profile record, rather, the path to the built profile. So I have to build it. <Rutherther>what I was suggesting was passing the (guix profiles) to the service so that you can execute that only when the service runs <ieure>Rutherther, The GUIX_PYTHONPATH of the profile needs to be written to the config file. <ieure>I'm making the config file and then the shepherd service, but there's no way to pass an arbitrary value through from there into serialize-configuration to the serializer so it can end up there. <Rutherther>hm, I am not sure if it changes something, I am tired now, though and have to go already. So maybe I am missing something <gabber>Rutherther: in the example you gave, can i select a specific output? <Rutherther>(define* (derivation->output-path drv #:optional (output "out")) <RavenJoad>What is the Guix way of creating a script inside of a package phase? There's program-file, but that returns a gexp, which is not what I need right now. <RavenJoad>Essentially, I want to have a wrapper around a program to provide some CLI arguments by default. <ieure>RavenJoad, Have you grepped the Guix repo's gnu/packages directory for "wrapper?" <RavenJoad>ieure: I had not before. I did at your suggestion. The most obvious one was in mpi.scm for mpich. That uses call-with-output-file and constructs the file by hand, which is essentially what I need. <RavenJoad>I will have to do a TON of wrapping too with wrap-program/wrap-script, so I am figuring out the best way to do this. <ieure>RavenJoad, wrap-program is what I was thinking of. Why are you using a wrapper to pass CLI arguments? Is that the only to pass some thing the program needs from the store or something? <RavenJoad>Pretty much, yes. I need to specify a program (gtoolkit) and an image to launch (gtoolkit.image). So normally, the CLI would be `gtoolkit --image ./gtoolkit.image`. I want to "replace" gtoolkit with a script that does the whole --image nonsense automatically. <adanska>rip codeberg... it appears to be down <adanska>appears to have happened like 15 mins ago <ieure>adanska, Believe it or not, Codeberg is still much, much more reliable than Savannah, which is what Guix was using before. <adanska>ieure, Oh I was there hahaha, this is leagues better than Savannah <adanska>not digging codeberg at all, stuff happens <mroh>has someone tried to seed guix on radicle.xyz? <mroh>looks like, it cant handle such big repos. My experience is indeed only with (very) small repos, but these work well. I like it. <Guix1800>I keep getting this error when trying to install Firefox <mroh>looks like a typo "appens" -> "append". <nmeum>I just did a guix pull and wanted to reconfigure my system but now I am getting "guix system: error: error parsing derivation `/gnu/store/6148xpqq25vxqnqj4db9xyrjw85jd5qn-module-import.drv': expected string `Derive(['" (the .drv is an empty file for some reason). how do I figure out what is going on here? <nmeum>I also cannot revert to an old generation as doing so gives me the same error <identity>nmeum: try guix gc --verify=contents,repair <nmeum>ah, thanks! that allowed me to switch generations again <identity>nmeum: it probably means disk corruption/unclean writes <ekaitz>hi! i found this in the manual refering to home-x11-service-type: As a user, you probably don’t need to worry or explicitly instantiate home-x11-service-type. Services that require an X Window graphical display, such as home-redshift-service-type below, instantiate it and depend on its corresponding x11-display Shepherd service (see Managing User Daemons). <ekaitz>but if i add unclutter to my home-config it says nobody provides x11-service <ekaitz>so what's right? i have to add it myself or it should be made automatically? <identity>ekaitz: the unclutter service does not instantiate home-x11-service <identity>it is the only one in (gnu home services desktop) that does… <ekaitz>so the "services that [...] such as home-redshift-service-type" should be just "home-redshift-service-type" <identity>or, perhaps, the other services should actually do what the says they do <Rutherther>I think it would be better if they did not. This allows for replacement with a custom x11-service. There might be people who want a different approach <ekaitz>we should at least rewrite the docs <Guix1800>I just need to access Firefox browser and also activate wifi on my guix <Rutherther>how do the manual translations work? For example I made this PR https://codeberg.org/guix/guix/pulls/5118 that changes a message that has couple of translations. What's going to happen with the translations, are they going to become obsolete since the string won't match? <identity>Rutherther: i think so, it should be displayed in English in the translated manuals until it is translated again <PotentialUser-35>who is in charge of approving mex to the mailing lst guix develsome mex are stuck there for a week <Rutherther>I doubt anyone here knows that. It's not someone from Guix, it's someone from GNU <loopified>Just resuming my trial of the 1.5 RC and, apparently, no config.scm was generated on /etc/guix. Since the manual still states it will be there, is this intended? <noe>lilyp, apteryx: I looked into packaging gst-plugins-rs (for gst-plugins-gtk4, needed by snapshot and decoder) but even with my best hacking around I couldn’t get it to build without rust edition 2024. So I think we’ll have to wait on rust team merge for these. <Rutherther>loopified: and to be clear, you mean you installed guix system from the installation iso and now in the installed system there is no /etc/config.scm? <csantosb>So apparently it is possible to fetch content from a private repository, similarly to a private channel <csantosb>Except that this is currently broken, see #2913 again <csantosb>I guess I'll request its merge rather soon, in case someone keeps an eye on this <loopified>Rutherther: through the ISO, following the interactive setup (not providing my own configuration and starting from scratch). <Rutherther>loopified: then it is expected you will have /etc/config.scm in the target root's file system. And I don't really see how it could be otherwise since the installer installs from that file, so it has to create it, otherwise it has nothing to install <Rutherther>loopified: what is your partition setup? Anyway you can find your configuration file in /run/current-system/configuration.scm <loopified>Rutherther: went with one partition to try it out. <loopified>Yes, it's weird, but it's definitely not there (on /etc/guix). <ngz>Hello. I just activated Guix Home on a foreign distro (Debian), and I encounter a strange problem. Any application I launch using personal keybindings takes ages to appear on the screen. For example, it takes around 20 seconds for gnome-terminal window to appear. When I launch the application from a terminal, it appears instantly. I don’t even understand how this could be related to Guix Home, but that is the latest change to my system <ngz>and all was fine before. <hugo>loopified: I think the config file should be /etc/config.scm (and that is also what Rutherther says), so not in /etc/guix <Rutherther>ngz: that usually happens when there is a desktop portal involved and the request on it are in timeout. Ie. in case you would use a sipmle WM, but have xdg-desktop-portal-gnome. Can you check what portals you have installed in your guix home, if any? For example with "guix home describe -I" <ngz>Rutherther: I don’t have any xdg nor portal related packages in guix home describe -I <hugo>PotentialUser-35: How do you know the messages are stuck? Is there a way to check the message queue? I sent my first message to guix-devel on Jan 1st, to introduce myself (as I registered for the Guix Days), but that message is not in the archive, so maybe it needs to be approved by these illustre list maintainers first <Rutherther>ngz: when you launch gnome-terminal from a terminal, what does it say during the launch and after it gets launched? <Rutherther>hugo: yes it does and it takes roughly a week nowadays <ngz>Rutherther: Nothing, event with the verbose option <Rutherther>ngz: like instantly or with the delay you mentioned? <ngz>From the terminal, it is instant <ngz>The delay appears when I use a Gnome keybindig to start it. <ngz>Unfortunately, I don’t think I can see the output of the command when started that way (from a keybinding). <hugo>Rutherther: thanks. My message was in no means urgent (although I do wish everyone a happy new year), so it's fine. Maybe proofing my thought that an introduction message is good, because hopefully this pre-approves my address so my more timely messages will get through faster in the future <ngz>Rutherther: I have two of them: gtk-launch and gtk4-launch <Rutherther>ngz: and "gtk-launch gnome-terminal.desktop" also launches it instantly? <ngz>No application "gnome-terminal.desktop" <Rutherther>guess it's org.gnome.Terminal.desktop, idk, you will have to look into /usr/share/applications <ngz>Note that the delay also happens with local applications, i.e., application that do not have an associated desktop file. <ngz>OK, looking into it. <ngz>OK, gtk-launch starts it instantly. <Guest18>so the BIOS helpfully erased the boot option because of power loss. i think i can recreate it, but i have no idea what path i should input. i assume i need the first stage boot loader, but where is that on Guix for the grub-efi loader, if it is different than normal? <Rutherther>Guest18: grub is the only bootloader that Guix uses when you use grub-efi, if by first stage bootloader you mean UEFI, that is not managed by Guix <ngz>I may try to associate the command "gtk-launch org.gnome.Terminal.desktop" to my keybinding to see how is goes. <Rutherther>ngz: I have doubts that would help, it seems to me the issue is going to be something in the environment of Gnome launcher and if so, it's going to stay the same. You have relogged after installing guix home, right? <ngz>I even rebooted a couple of times, yes. <ngz>You’re right; it didn’t change anything <Rutherther>ngz: the most I can think of is that you could start up "dbus-monitor" and look what appears there when you launch the application through gnome, if anything. In cases where it would really be a timeout waiting for a dbus reply, you would notice it there <Guest18>Rutherther: by first stage i mean whatever code stored on the hard drive that is the first to run in the boot process <Rutherther>Guest18: with efi that is the efi file of grub on your ESP <Rutherther>but it has nothing to do with your problem of missing a boot entry, that is stored in NVRAM <Guest18>right, i think the NVRAM got cleared and i can no longer boot, i get a "No Sys Loader!" message <loopified>hugo: ouch! Yes, that is there. ':D My eyes deceived me a few times. <Guest18>so i want to know the path i need to recreate the boot entry, or at least get at a grub prompt <loopified>I have added a channel to a ~/.config/guix/channels.scm. Running `guix pull` after that lists the channel, displays that the derivation for the channel is being built and finishes with success. After that, though, `guix describe` only lists the guix channel. What am I missing? <Rutherther>loopified: did guix pull not tell you a hint to source the profile? After first pull you either need to source it yourself or relog <ngz>Rutherther: The output of dbus-monitor is rather verbose. It pauses at various times. I noticed the following message: "string "Could not get owner of name 'org.gnome.keyring': no such name". Apart from it, I cannot see any other error-like message. <loopified>Rutherther: years ago, I had problems decrypting that hint. Seems like I still failed to understand it. I thought just restarting the shell was enough, and that somehow it was only related to foreign distro installations. Yes, logging out and back in worked. <ham5urg>would you use use elogind to poweroff a headless workstation via the power buttton? Or is acpid a viable option? <sleepydog>acpid is viable but you might want elogind for other stuff like suspend, screen locking w/swaylock, or its pam config <sleepydog>elogind is not necessary but going without it means you have to do more stuff yourself <gabber>is it possible that creating a link to some ~user/.bash_profile through special-files-service creates /home/user as root:root without write permission for ~user? <Rutherther>for sure, it will create the folders and since it's ran on activation, it's going to be ran prior to the user-homes shepherd service <Rutherther>I would argue that the user-homes service should probably make the home folders owned properly. But still it will mean the homes won't be properly initialized in the case you outlined. There is probably not much to do other than using something else than special-files-service. I don't think that service is well suited for initializing user homes <gabber>i am working on a headless/embedded device and i thought this was a nice shortcut to have guix log in that unprivileged user at boot and execute stuff automatically <gabber>having a (nice) user home configuration would mean to manually work in two steps: system, then user (re-)configuration which i want to omit <Rutherther>why would it mean that? There is the guix-home-service-type for guix system that does activate guix home <Rutherther>and there are other possibilities like making custom shepherd or activation services for this, really I don't see why manual work would be required <gabber>can i create a `guix home` like environment in an (operating-system) declaration? <Rutherther>also note the field "skeletons" of operating-system allowing you to override the skeletons copied to user homes <Rutherther>gabber: yes, that is the guix-home-service-type, it will take the home-environment and run the activation for the given user <gabber>i don't think i've ever heard of that field <umanwizard>I just did a guix system reconfigure for the first time since Nov. 26, and now I'm getting a blank screen when launching Mate -- I tried Fluxbox and that still works, but I prefer to keep using Mate... <umanwizard>Can anyone think of a faster way to debug this than git bisect? Or know anything major that changed in the meantime? <gabber>umanwizard: i'd roll back ASAP and only after figuring out what went wrong reconfigure again <Rutherther>umanwizard: okay. I don't know about any issues at that commit. Have you tried logging in as freshly created user, not your regular one? <umanwizard>BTW, I should mention that I'm on aarch64, not x86 <umanwizard>gabber: well, I might never figure out what went wrong, and I'd rather not be stuck on 2025-era Guix for the rest of my life :) <umanwizard>anyway, for now I'm bisecting the guix repo, which will take all day probably (11 steps to bisect, but each step is really slow) <gabber>umanwizard: lol. sorry, i thought this was maybe your main workstation <steelman94>hi, i am new to guix and I've found something baffling. First, I installed Guix from the official tarball on top of Debian (I disabled /etc/profile.d/zzz-guix.sh, which may be the reason, bare with me). Second: I did `guix pull` and things happened. I had a new guix(1) (1.4.0 → 396a6ce2da58a07d016f37e64c2b412ab22e31f5). I played a bit (didn't <steelman94>install much though, I did `guix pull` it was fast) and tried running `guix gc`. Storage space has been freed (oh, well probably something was needed as a build dependency during pull). Now, I tried `guix pull` once again and it was very slow. Apparently `gc` removed something `pull` thinks is needed. IMHO this shouldn't flip-flop like this. Do you <steelman94>have any suggestion how to discover, what exactly `gc` throws away that `pull` thinks is needed? <Rutherther>umanwizard: so have you tried logging in as a new user already? <umanwizard>no, I'll try reconfiguring with a new user now, hang on <gabber>i think `guix gc` actually tells you (while it is at it) what it does <Rutherther>steelman94: so what was guix pull building and why do you think it's related to gc? <umanwizard>Rutherther: tried with the fresh user, same issue as before <steelman94>Rutherther: let me try this now, bc I did `pull` just a moment ago and it was relatively fast (it did rebuild guix) <steelman94>`note: currently hard linking saves 2176.56 MiB` `guix gc: freed 196 MiB`, let's `pull` <steelman94>`Computing Guix derivation` is spinning… `nothing to be done`. It took a minute or two but it wasn't that bad. <Rutherther>umanwizard: for me mate works fine in a VM. AArch64 <umanwizard>That's interesting. Can you share the details of your VM setup? What Vm software do you use, what host OS, etc. <Rutherther>steelman94: right, but that has nothing to do with guix gc. Currently that's just how it is, the guix derivation has to be recomputed on every guix pull <Rutherther>umanwizard: the host is RPi5 running Alpine. The VM is using the gnu/system/examples/desktop.tmpl configuration. The GPU is virtio-gpu. <umanwizard>I'll try bisecting and see where that gets me, I suppose <umanwizard>Are you using either of `qemu-guest-agent-service-type` and/or `spice-vdagent-service-type` ? <steelman94>Rutherther: I'll keep watching. Maybe I did somehting more (it was late). BTW another odd thing I've spotted is that without many packages installed I've got xz 5.2.5 *and* 5.2.5 each installed twice (with different hash). <steelman94>i didn't `guix install` anthing except `glibc-locales` <steelman94>i've got four /gnu/store/[a-z0-9]{32}-xz-5.[24].5 directories each with their `bin/`, `lib/` etc. <steelman94>and neither of them is listed by `guix gc --list-dead` <Rutherther>right, that is normal, any input change will lead to a different package. Looking directly to the gnu store is not going to tell you much as to where they came from. <umanwizard>if package A depends on xz 5.2.5 and package B depends on 5.4.5 and you install both A and B, xz won't be dedpulicated, you will get both versions <umanwizard>in fact, this can be true even if the version of xz is the same (if one of its inputs, or, recursively, one of its inputs' inputs, etc...) has changed. Or really, if anything abuot the derivation changed at all, e.g. one of the versions was built without running tests (even if the resulting output is bit-for-bit identical!) <umanwizard>This is quite fundamental to the idea of Guix (and Nix) and how they work <Rutherther>if the output is bit-by-bit identical, it will be deduplicated by using hard links <umanwizard>Rutherther: sorry, I meant that both paths will exist, each with their own hash <umanwizard>But you're right that they'll be dedupilcated in the sense of not requiring more disk space <steelman94>Rutherther: they aren't deduplicated. /gnu/store/hashA-xz-5.2.5/bin/xz and /gnu/store/hashB-xz-5.2.5/bin/xz are different and not hardlinked (same for 5.4.5 duplicates). I guess I am ok with having 5.2.5 and 5.4.5 side by side (that's what Guix is about after all) but the same version installed twice seems odd. I mean, I know something requires it <steelman94>(it's not garbagecollected) but, maybe those packages which require two different instances of xz-5.2.5 could be rebuilt to use one. <umanwizard>steelman94: You are correct in principle that if whatever derivation is depending on those xz instances were changed to rely on exactly the same *derivation* of xz (not merely the same version), then you wouldn't see that duplication <umanwizard>Trying to figure out how and why they differ, and what is depending on them, might be a fun exercise. <umanwizard>Maybe there's an actual reason why they need to be different. Maybe not. <Rutherther>steelman94: having something in /gnu/store does not mean it's 'installed', it just means that something relied on it at some point. That is why I was saying that merely looking in the /gnu/store is not going to tell you anything. While it can happen Guix source would have both the packages, it is not the case with xz. Only one xz version is in the guix source, so the second path is presumably no longer used by the profiles you are currently using <Rutherther>and if you want to get rid of it, you would have to remove the gc roots, presumably by removing your previous profile versions, like the profile made from guix pull and from guix install - also don't forget to do guix upgrade after pulling <steelman94>this looks funny: 5kj8ly…-guix-1.4.0 → (requires) c8isj4…-xz-5.2.5 and 5kj8ly…-guix-1.4.0 → 17rcyc…-guile-lzma-0.1.1 *but* 17rcyc…-guile-lzma-0.1.1 → aggsb6…-xz-5.2.5, and they all come from the original tarball. (see `tar -tf guix-binary-1.4.0.x86_64-linux.tar.xz | grep xz-5.2.5/bin/xz$`) <steelman94>which means this sort of can happen. I am asking because I'd like to play with guix on a tiny VPS with not much storage (and evel less RAM) so I'd like to avoid having real duplicates like these and learn to fix them when they happen. <Rutherther>yes it can indeed happen, for example when using different configurations for bootstrap or for a particular package <steelman94>Rutherther: I'll be watching carefully. this is quite new stuff for me. thanks for the explanations. <lfam>Are we currently frozen for the release process? Or is it still okay to push updates to 'master'?