IRC channel logs


back to list of logs

<NewishContributo>One more question: some python packages import themselves in their pytest scripts, how do I handle this in a guix package? Right now I have a couple different packages that fail in their test cases with "ModuleNotFoundError: No module named 'this_package_name'"
<freakingpenguin>freakingpenguin: re. my earlier issue with resizing partitions, I did confirm the partition UUID matches what (canonicalize-device-spec) should expect. Not sure why it's not finding it.
<abbe__>how does committing to guix repository works, as in a typical flow of a derivation/package update/commit, esp. w.r.t. availability of binary packages on the substituters ?
<apteryx>abbe__: typically patches are sent to, then picks them up, builds them, and later when the commits are merged the packages/updates are ideally already substitutable
<Kolev>Who maintains Go? Hi lfam!
<lfam>Hi Kolev
<cornflake>hi y'all, I was just wondering if anyone has had any success installing a cursor from something like and getting it to work on any desktop environment on Guix System?
<cornflake>I've tried moving the files to ~/.icons, ~/.local/share/icons, regenerating the icon cache, renaming the index.theme files to cursors.theme, pretty much anything I can find, but I can't get it to work. I've tried the same stuff on Gnome and Xfce with no luck
<cornflake>has anyone done this before? Is it possible?
<cornflake>installing cursors using the guix package manager works just fine on both DEs
<Kolev>How is Rust in Guix?
<cornflake>Hey everyone, I fixed my cursor problem! I fixed it by adding this line to ~/.bash_profile:
<peanuts>"debian Pastezone"
<cornflake>I haven't tested it on Gnome, but it works on xfce, so it will probably work on gnome also
<cornflake>what the line does it add the ~/.local/share/icons folder to the XCURSOR_PATH environment variable, which is where the cursor setting app looks to find the cursors
<cornflake>you can also add ~/.icons to the XCURSOR_PATH if your cursors are in ~/.icons
<civodul>Hello Guix!
<sneek>efraim, you have 1 message!
<sneek>efraim, ngz says: Hello! I have around 40 Rust packages ready for updating xremap to 0.10.0. Shall I push them into "rust-team" or do you prefer me to send them through the ML?
<efraim>sneek: botsnack
<abbe__>thanks apteryx!
<MisterEsse>Hi. Can GNU Guix packages be personalized? For example, can I install ffmpeg without jack?
<MisterEsse>If yes, please give me an example on how to personalized one package.
<rekado>you can create arbitrary package variants and then use package transformations to replace any instance of ffmpeg with your custom variant. But note that you'll end up having to rebuild a *lot* of packages if you replace ffmpeg throughout the dependency graph of your environment.
<MisterEsse>rekado: yes.
<MisterEsse>I am trying to build ffmpeg from source here in my Parabola distro, but I am stuck at one point where I cannot move forward. How would an ffmpeg package variant installation on Guix be like?
<MisterEsse>rekado: ^ .
<anthk_>hello, what's the difference between guix install and guix package -i?
<adanska>anthk_: nothing
<adanska>its just an alias
<adanska>as is guix uninstall, guix search, guix upgrade
<civodul>MisterEsse: some customization can be done from the command line:
<peanuts>"Package Transformation Options (GNU Guix Reference Manual)"
<civodul>but for what you describe, you’d have to write you own variant along these lines:
<peanuts>"Defining Package Variants (GNU Guix Reference Manual)"
<efraim>ffmpeg as an individual package or used as an input for other packages?
<MisterEsse>efraim: as an individual package.
<MisterEsse>Are package recipes downloaded from some place? Or we have to write them from scratch?
<anthk_>uh, I should try the inria guix package generator, I would like to import the 203 and 216 srfi's for chicken (SICP helpers)
<MisterEsse>Are package recipes downloaded from some place? Or we have to write them from scratch?
<rekado>MisterEsse: all package definitions are here:
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<rekado>they are part of Guix
<rekado>you can see them with "guix edit", for example.
<cnx>how do i regenerate guix documenation for a modified service
<ngz>Hello Guix!
<efraim>gnome-shell is very much required for gnome, right?
<civodul>efraim: it’s the core of GNOME
<civodul>hi ngz!
<efraim>civodul: thanks, that's what I thought. I'm going to add eog unconditionally since it was only taken out because of the newer librsvg, which is also required by gnome-shell
<efraim>and I think I've fixed it so that gnome is supported on aarch64
<Deltafire>from the manual: "wayland? (default: #f)", is this incorrect? my install seems to have defaulted to using Wayland
<efraim> 97.5% of packages built on aarch64-linux!
<peanuts>"Branch master Guix Quality Assurance"
<Deltafire>(wayland? gdm-configuration-wayland? (default #t)) - documentation is incorrect
<picnoir>Hey guix! I know there's a procedure that prints the value of a sexpr before returning it. It's useful to printf debug guile code :) Sadly I can't remember its name and did not manage to find it in the manual so far. Does this ring a bell to you?
<Deltafire>picnoir: pk (for peek)
<picnoir>That's it! Thanks Deltafire :)
<MisterEsse>Cloning into 'guix'... fatal: repository '' not found .
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<ngz>efraim: Impressive!
<MisterEsse>^ cannot get the build recipes ^ .
<rekado>MisterEsse: that's not the clone URL
<rekado>you can find the clone URL at the bottom of the page
<MisterEsse>rekado: upps.
<MisterEsse>rekado: thanks.
<MisterEsse>At guix/gnu/packages/ there is no ffmpeg.scm ... Does anyone know where ffmpeg build recipe is located?
<ngz>MisterEsse: In video.scm, as pointed out, e.g., by `guix show ffmpeg'.
<MisterEsse>ngz: thanks. I still haven't installed guix package manager.
<ngz>When I use `wget -O- | git am`, it tries to grab the cover letter and fails because the first patch is empty. Is there a way to make it run smoothly, or do I have to finalize the process manually?
<efraim>why does gtk-vnc have node as an input?
<ngz>efraim: I don't know, but as a data point, Nix doesn't have this input.
<efraim>ngz: thanks. I removed it as an input
<ngz>There inputs are: gnutls, cairo, gdk-pixbuf, zlib, glib, libgcrypt, cyrus_sasl gtk3 and, optionally, libpulseaudio.
<ngz>efraim: BTW, do you mind if I merge my Rust patches (upgrading xremap) into "rust-team" branch, or would you rather review them beforehand? There's nothing fancy inside. And they are guaranteed free of "skip-build"."
<efraim>I haven't looked at them but it should be OK. do they all individually build? or at least fail during build and not due to missing unpackaged inputs?
<ngz>They all build, AFAICT.
<efraim>then it should be fine
<ngz>OK then. I'll apply them to "rust-team" branch shortly. Thanks!
<efraim>they're sorted alphabetically?
<ngz>Well, sort of. When updating some of the packages, I noticed order was not correct in crates-io.scm. The patches do not modify this.
<efraim>ok, that works.
<taeaad>Is there something I need to run other than "guix pull" for the newest version? I ran guix pull to get Python to 3.10.7. Today I tried to list Python on the same machine and it's back on 3.9.9. This doesn't make sense to me.
<cbaines>taeaad, are you sure you're using the guix you pulled? What does type -p guix and guix describe say?
<jakef>taeaad: you'll also need to do something like guix upgrade to actually upgrade your python
<taeaad>It's now saying 3.10.7 again when I had rerun guix pull.
<taeaad>I think I need to understand the way versioning works better. I thought that the idea is to have one guix version; the latest?
<taeaad>$ type -p guix
<taeaad>Generation 1 May 19 2024 10:15:21 (current)
<taeaad> guix e9b25a6
<apteryx>'herd disable virtlogd' doesn't stick on reboots
<m4xxed>Hello, I have searched the logs of this IRC and have not found a solution to the following issue (which might be off-topic, since it concerns a foreign distro - Arch):
<m4xxed>I found that I could no longer use yay (pacman  wrapper) after I installed guix (via official install script) because the fakeroot ( seems to be linking to the guix-based ld-linux and files which use glibc 2.35 while arch is already on 2.39 on my system. So I have a forward-compatibility issue and I was wondering if anyone
<m4xxed>here uses guix as a PM on a foreign distro aswell and has a solution for me, or a hint on where this should rather be discussed.
<singpolyma>Hmm, i do use on foreign but via apt install guix not via the install script
<singpolyma>Though it's unusual for a system lib to see a guix lib
<m4xxed>This is what confuses me aswell
<kaizer>m4xxed: Guix could be symlinking your environment so maybe check your ~/.bashrc, or /etc/bash_profile for it to load /etc/profile and if it does, you'll see a whole load of env vars being loaded. This could be where your problem is
<kaizer>Guix could also be setting variables from ~/.guix-profile
<m4xxed>I am using fish as my default shell.
<m4xxed>So I figure this complicates things somewhat further.
<kaizer>Then check your /etc/profile. If you see guix stuff in there check if there's some stuff about .guix-profile, if it's there, that's your most likely culprit
<m4xxed>Nothing about guix in there.
<kaizer>m4xxed: Not necessarily, unless you're using a service of which I don't think there's a home-fish-service-type
<kaizer>What about your ~/.profile?
<m4xxed>my ~/.profile is completely empty
<m4xxed>kaizer  What I discovered is that when I enter the fakeroot environment manually using "fakeroot /bin/bash" and use "type tty", guix executables are used from "/home/user/.guix-profile/bin/*"
<kaizer>That makes sense, cause everything is stored in gnu/store and symlinked to where linux expects them to be
<kaizer>m4xxed: Now even I'm confused. Here's what I know, guix initializes system variables on startup from your .profile. So if it's clobbering your environment check there. Because that's literally the only place where env variables can be instantiated.
<kaizer>Hope that helps
<m4xxed>kaizer: Alright, thank you for your help so far. I will clean up my configurations even further and find out how often and when "" is executed and whether for some reason this is also executed when fakeroot is started. Maybe I can figure it out. It is just an inconvenience since I cannot use the AUR right now, but most packages I use are
<m4xxed>covered by guix anyway. So thanks again :)
<panosalevro>hi, I believe I nuked my system in a very unpredictable way. my keyboard started acting up while I was using my pc (basically some keys didn't work) so I rebooted my pc. after I rebooted, I was prompted by the TTY to decrypt an internal drive (which was setup using config.scm). however, because the keyboard was still messed up, I entered my
<panosalevro>password wrong 3 times. as soon as I entered it wrong a third time, the TTY informed me that a filesystem change had occurred on my OS drive. I rebooted again, only this time BIOS couldn't even find my OS drive. using `lsblk` via a live image of another OS, I can only see my encrypted internal nvme (which is safe and sound) -- my OS nvme is nowhere
<panosalevro>to be found. what happened here? is this really how luks is configured with guix?
<ieure>Are you sure that was the Guix disk password prompt, and not a BIOS password?
<panosalevro>i am sure. i had the prompt for months (ever since i included the luks disk in config.scm)
<panosalevro>i don't have a BIOS password anyway
<panosalevro>step 1 is to get that drive detected again to work with it. then i can see what happened to that drive. any ideas?
<ieure>No, I've never heard of this behavior. lsblk should show it even if it got wiped. Maybe ask help-guix?
<panosalevro>i will try, thanks
<edrzmr>Guys, some one has experience with fedora silverblue? Right now I'm using nix on it, but I want move to guix, there are some tip about install guix on ostree based system?
<enigma9o7_irc>Hello. I'm attempting to try guix under an ubuntu based OS. I installed it with apt, then guix pull, but it's still using the original guix and not sur ehow to make it use the new one.
<enigma9o7_irc>I don't see a new copy of "guix" under ~/.guix_profile to use instead of the /usr/bin one... and the /usr/bin one has some comments that implies to me its supposed to work if user does guix pull
<picnoir>xdg-desktop-portal on sway is driving me crazy. I went through the whole check list xdg-desktop-portal-wlr checklist, set the appropriate env variables no luck. Does anybody here would have a functional setup posted somewhere online?
<picnoir>My (so far) unsuccessful attempts:
<peanuts>"guix-config/modules/services/desktop/sway.scm at master - picnoir/guix-config - Alternativebit"
<freakingpenguin>enigma9o7_irc: You could try using the ~/.config/guix/current/bin/guix. Make sure ~/.config/guix/current/bin is in your path.
<freakingpenguin>I have a system image I'm booting on an Arm SBC, but Shepherd seems to struggle to exec any process. Bunch of "exec of "/gnu/store/..." failed: Too many levels of symbolic links". Sound familiar to anyone?
<enigma9o7_irc>Well turns out all I had to do was logout and log back in.
<freakingpenguin>Ah, I think (info "(guix) Getting Started") discusses that.
<apteryx>I'm getting build errors like: guix.pt_BR.texi:11048: @pxref pointe vers un nœud « Requisitos » inexistant anyone resolved that?
<apteryx>re-running ./bootstrap didn't seem to help
<freakingpenguin>Make should rebuild everything when you regenerate the makefile I believe, but maybe make maintainer-clean just in case there's something left?
<freakingpenguin>Figure out my issue re. symlinks. I'm good, was related to qemu-binfmt.
<f1refly>hello, my current system is partitioned into an unencrypted root partition and a partition containing a luks volume. the luks volume contains two logical volumes, one is for /home, the other one is for swap. Currently, I set mapped-devices as a dependency for / so grub is configured to decrypt the luks volume and the swap becomes available for the linux kernel to resume. This causes the problem that
<f1refly>I'm asked for my fde password twice: once before grub with a qwerty layout and again after booting linux with my preferred layout
<f1refly>is there a better way to set this up so that I'm only asked for my password once, possibly using my preferred keyboard layout?
<Altadil>f1refly: I have the same setup… and the same problem. :)
<Altadil>If I understand correctly, it’s a limitation in the way the setup is implemented in Guix. It could be done in a better way, but that would require quite a lot of work.
<f1refly>Yes, that is my understanding as well
<f1refly>I just wanted to check in and ask if there's a different way nowadays
<xca>What is the correct way to resolve guix home package conflicts? I use guix home to configure one of my packages, and the most recent configuration of it creates a new "patched" version of it, conflicting with the previous version already present in the guix home profile (reconfiguriny with any previous configurations still works).  I think I
<xca>should delete the profile directory from ~/.guix-home, or maybe just delete instances of the backage in /bin or /sbin, but I'm not sure.
<freakingpenguin>xca: Are you saying guix home is trying to install two different versions of a package simultaneously?
<jonsger>ACTION don't understand while running "guix system reconfigure" && "guix gc" && "guix system reconfigure" leads to tons of substitution downloads on the reconfigure after garbage-collection
<freakingpenguin>jonsger: At a guess, any build-time dependency (native-input) is gc'd because it's not going to be linked in the profile.
<freakingpenguin>Not sure why it would feel the need to redownload them though if it doesn't need to rebuild anything, so that might not be it.
<xca>What I'm doing is running guix home reconfigure latest-config.scm  This results in the errors:
<xca>profile contains conflicting entries for 'package'
<xca>first entry: 'package  v1'
<xca>second entry: 'package v2'
<xca>hint: You cannot have two different versions or variants of `package' in the same profile.
<dariqq>f1refly: there is a luks-device-mapping-with-options to add a key file though I have not tried it out myself
<jonsger>freakingpenguin: it's maybe related to grafts
<freakingpenguin>Ah, there was a post about that recently I think
<freakingpenguin>xca: Can you post a pastebin of latest-config.scm?
<xca>freakingpenguin ok just a sec.  The errors only started happening after literally patching in new functionality
<peanuts>"debian Pastezone"
<xca>adding lines 36-38 is when the error occurred
<freakingpenguin>xca: What if you remove "dwl-guile" from (packages) in line 14? If home-dwl-guile-service-type is adding your patched dwl-guile to your profile and you're still adding the unpatched dwl-guile to your profile, that might cause the problem.
<xca>I did that before and it worked, but the %patch-swallow didn't seem function, so I thought maybe removing dwl-guile from the package list caused that.
<freakingpenguin>I don't know what home-dwl-guile-service-type is doing, but generally services that take a package in a configuration field add that package to the profile.
<freakingpenguin>You might have an easier time troubleshooting if you do (define my-dwl-guile (patch-dwl-guile.....)) (aka put it in a variable), return it at the end of the file, and use guix build -f <file> to confirm your patch is applying.
<xca>freakingpenguin this is where i got it from:
<peanuts>"GitHub - engstrand-config/home-service-dwl-guile: GNU Guix home service for the dwl window manager with dynamic configuration in Guile Scheme"
<xca>brb i want to check if something else is broken
<xca>ok so removing dwl-guile from package list also causes "spmenu" to stop working, and reverts back to using my previous configuration that used bemenu instead.
<freakingpenguin>I found an old patch (#69090) that I think will be useful but the submission is a bit wonky (email-wise, not code) and wasn't caught by CI. It still applies so I was thinking of resubmitting it to help with visibility, is that fine?
<freakingpenguin>Would I submit it as a v2 to the original or as a new patch entirely?
<peanuts>"[PATCH] gnu: services: Add resize-fs-service."
<xca>freakingpenguin I think this is just too advanced for at this point.  I can only go further if I'm able to understand programming better at some point.  Thanks for helping.
<ngz>freakingpenguin: Yes, you can resubmit it.
<freakingpenguin>ngz: Gotcha. Will QA catch it if it's a V2 on an issue that wasn't originally captured?
<ngz>No idea; there's only one way to know ;)
<freakingpenguin>Fair enough haha
<NewishContributo>Just to add on to freakingpenguin's question, is it a problem to submit patches as a .patch file instead of through git send-email? All of my unreviewed patches have been sent as patch files since my work email has authentication restrictions that prevent me from using git send-email.
<ngz>NewishContributo: As long as you use git format-patch, that's fine.
<NewishContributo>Yep I did, good to know thank you
<freakingpenguin>I'm trying to reconfigure an aarch64 system but the bootloader fails to upgrade. I think that's because efivars (/sys/firmware/efi/efivars) is mounted ro. What could be causing it to mount like that?
<vagrantc>what efi implementation are you using?
<freakingpenguin>How can I check that?
<vagrantc>for example, i do not think u-boot's EFI supports writing variables
<freakingpenguin>The boot chain on this board goes onboard_rom->SPI u-boot w/ UEFI->SD card GRUB->SD card linux.
<vagrantc>probably in one of the files under /sys/firmware/efi/ ... but just guessing
<freakingpenguin>Sorry, SPI NOR flash
<freakingpenguin>So the efivars are being carried over from u-boot and are physically located on the flash then?
<vagrantc>not sure how to workaround that issue ... short of implementing writeable efi support in u-boot
<vagrantc>freakingpenguin: more likely just some placeholder variables
<vagrantc>alternately, switching away from EFI and using the "extlinux" style menus might be an option ...
<vagrantc>or just telling guix system reconfigure to not write whatever variables it is trying to write
<vagrantc>i suspect it is using the default location for EFI e.g. efi/boot/bootaa64.efi or some such and your process is trying to update the efi variables to instead use efi/guix/grubaa64.efi or some such
<freakingpenguin>I suppose I can flat-out remove the bootloader from the OS field and only insert it when creating the image. I don't think it would delete it in that case.
<vagrantc>yeah, also a possibility ... although you still want to make sure it updates the grub configuration
<vagrantc>there are a few options ... none of them elegant :/