IRC channel logs
2026-02-03.log
back to list of logs
<pomel0>when booting the guix installer on my laptop with libreboot (straight from grub) it complains it can't find partition 31393730-3031-3031-3139-313133333833. Is that UUID? And for what? The partition in the usb drive that contains the installer? <pomel0>I tried changing the root in the grub entry to /dev/sdb1, /dev/sda1... but kernel panicked <ieure>pomel0, Yes, that's a UUID, if you're booting the installer, that'll be the partition containing it. <rustyguix>untrusem- that's awesome, will give it a try. Was trying on my side to add 1.92 and 1.93, and I got stuck on some problems with 1.91 failing to install, as a dependency for 1.92, etc. <burley>New Guix system user here. I just got a bare metal install set up. Most things work great, but I'm running into minor issues with xfce4. For some reason I can't change the desktop font, or the icons. I did some searching, but came up with nothing. Has anyone else run into this issue on xfce4 with guix? <mange>When you say you "can't change" the desktop font or icons, what do you mean? Are the options unavailable, or do they have no effect? <mange>I've just built and run an xfce vm, and all the options I'm trying seem to be working as I expect, so I assume I'm looking at the wrong options. <burley>mange: the option is there, but when selected it has no effect. <burley>the exact setting I'm trying to switch: settings -> appearance -> icons <mange>What are you trying to change it from/to? <burley>I'm trying to change it from the default to anything else. There are two other defaults and two that I installed later. <mange>Hmm, yeah, that seems broken. I tried a few things to get it working (adding new themes using a tarball, adding gtk+:bin so it had gtk-update-icon-cache, etc.), but I couldn't get it to work. <burley>Same here. Thanks for confirming that <untrusem->rustyguix: so that means install phase has problems, i will look into it <rustyguix>untrusem-: yeah, cool, trying to troubleshoot right now. <apteryx>is offloading broken for anyone else? I'm using --system=powerpc64le-linux (I have such a build-machine configured for offload, and 'guix offload test' succeeds), and it fails like: while setting up the child process: in phase exec: executing `/gnu/store/50z55cgvm4j45c7kv2f4mcc6fjpmixnq-guile-3.0.9/bin/guile': No such file or directory <apteryx>apparently it attempts to run this foreign Guile binary (it's a powerpc build) locally <untrusem->rustyguix, I pushed some changes in my channel try this <clone>excited for the fosdem talks to start getting uploaded <futurile>heh heh how long do they normally take, a week or so? <clone>there's already some up, but i can't get any of the guix or guile ones to load yet <untrusem->can we use last build's content, so we don't have to rebuild everytime <untrusem->rust-1.91 build phase is successfull, install phase needs fixes, but I have to rebuild everything I want to test something and it would take over 1 hr 30 min on my machine <futurile>untrusem-: yeah, unfortunately there's no 'restart a build' <untrusem->futurile, has there been a discussion about that? I am sure I am not the first one to want that <futurile>untrusem-: good question, I don't know. I think there was a half-written attempt last year maybe, but it was never finished <futurile>untrusem-: you could ask on guix-devel whether it's moved forward - I've forgotten the details <kestrelwx>I was also wondering that. I guess that could be a lot of disk space to keep each phase. <futurile>kestrelwx: yeah - damm I can't find the patch series - generally that's the big trade-off, using a lot of disk space, particularly when you're rebuilding a lot heh <untrusem->also it would make testing and debugging easier on low resource machines <rustyguix>untrusem- not sure why it worked yesterday, but troubleshooting now. Yesterday, I actually just used a snippet of your fork, and added 1.92 and 1.93 on top. I managed to build & install 1.92 successfully, meaning that 1.91 was fully working. But somehow introduced a regression meanwhile working on 1.93, and the night was getting very late, and <rustyguix>somehow did not properly keep track of changes. <untrusem->ohh interesting rustyguix 1.92 was also built successfully <rustyguix>untrusem-: well, that was many hours ago :)ย now things don't work :) <rustyguix>will trying digging to recover the working commits <rustyguix>untrusem-: I also wonder how we can speed up the troubleshooting phase, as it does take a lot of time to retry builds. <untrusem->we will have to ask in guix-devel about this <futurile>yeah sorry, I'm completely blanking on who did that patch series, Nick ??? and it was about building open office, I think they created a guix command extension - bah my brain is not cooperating today <untrusem->ohh nice and the install phase rustyguix ? which defination you used the latest one with your changes or the previous one? <untrusem->rustyguix, have your tried using that with x.py install ? <rustyguix>untrusem-: no have not tried using options with `x.py` as it failed with respect to generate-copyright <rustyguix>ย The issue is generate-copyright runs during install and calls cargo metadata which fails on patched checksums. <rustyguix>What workflow do you use to test your own work on CI? <untrusem->you have to request to add your own channel to it <untrusem->sent a mail to guix-devel about the `restart the build` option futurile rustyguix <rustyguix>is there a little guide of some sort for ci.guix.moe? Or I just can go ahead and submit a request? <untrusem->futurile requested to subscribe to guix-devel, and I think it takes quite a few days for your first mail to reach guix-devel right? <futurile>untrusem-: your first one has to be authorised, probably will take 24-48 hours depening on when nckx sees it (I think they are the only mod so the load falls on them) <untrusem->rustyguix, you can submit a request, there is not a guide or something <futurile>untrusem-: well I guess cos Guix is a small project, and it's a rare person who's willing to use their own time to 'moderate' a mailing list - I mean thank-goodness for good people, I wouldn't do it <untrusem->people my age wouldn't even know what a mailing list is <untrusem->rustyguix, can you share your rust-1.91 nar with me <futurile>untrusem-: would communicating in Guix be easier if there was a Discourse or similar, interested in whether you think it would be useful? <untrusem->wouldn't that be another thing people would need to signup for, considering most of the people using guix are familiar with irc and email, I don't think it would be that useful as guix's current state <rustyguix>untrusem-: how do I share it, you mean the file itself right? <futurile>untrusem-: it's more like an 'additional' option, so I'm not on the Matrix but some users are <rustyguix>ran the build again with `--check` and it worked <rustyguix>yes, for reproudicibility check `guix build --check ...` <untrusem->aah I though you ran with `--stage=2` option in install phase <untrusem->I am curious about its result, but your solution works fine too ๐ ig <untrusem->futurile, yes I am on matrix channel, I guess it won't hurt to have another communication medium but that would need another good person for maintainence and all <rustyguix>from what I gathered using `x.py` will not work, but I am not sure at all could try <untrusem->rustyguix, to share the nar you could do `guix archive --export <rust-1.91 local store path> > rust-1.91.nar <rustyguix>yes, I did that, but can I share files in here? <mange>Is this in a local checkout? Is it up-to-date? <mange>Completely new checkout? Or have you built it before? You might need to do a "make clean-go" and recompile things due to a change in a macro, or something. I'm not 100% sure of the details of that error specifically. <isf>the new version of guix is finally possible to install? <isf>because, in can not even boot it with my T420 <bigbookofbug>working on building the wayland output for qtile, i noticed that the verion in the guix packages is version "0.34.1". this version of qtile specifies a dependency on python 3.12 <bigbookofbug>to my knowledge, guix builds with 3.11 -- is this still the case? on my system it builds with 3.11, and it results in a runtime type error when trying to run the wayland backend due to changes in asyncio between versions 3.11 and 3.12 <yelninei>is it possible to create a "profile" without the union of all packages in a single directory, in the same way this is done in build environemnts? <untrusem->rustyguix, so you basically cleaned my definations, nice ๐ <yelninei>i would like to get an environment for cross building and unioning breaks things as it mixes the cross and native parts <untrusem->nice, you are right we 1.92 inherits from rust-1.91 we don't need to remove things again if they are already being done in 1.91 but I am curious about why you didn't remove libffi and libz-sys, from my experience from other programs they don't pose any problems while even when they are listed as ;;TODO <untrusem->so that might be why it doesn't pose any errors when your remove them for rust-1.92 <yelninei>found rutherthers cross shells, this looks promising <untrusem->rustyguix, yep I saw your comment and fixed the version type <rustyguix>untrusem-: ok, I see. Will try later or tomorrow, as I have one build attempt in progress now. <rustyguix>So what is the typical cycle for such a PR? Besides the obvious requirement of building and installing, what kind of tests must it go through before it gets approved and merged into rust-team branch? <jonsger>ACTION finds it cool that we (Guix Foundation) got a donation from SUSE :) <ekaitz>efraim: In RISC-V it's not possible to guix shell -m manifest.scm in Guix, mumi and other things don't build <ekaitz>lol and for some reason using `guix shell -D guix` later doesn't let ./configure find guild <futurile>sorry it's on Youtube, I don't have a server with bandwidth <futurile>and there's a lot of me saying 'umm... uh' because I didn't practise it <ekaitz>futurile: is that the video or did you copy the wrong link? <Rutherther>I want a refund, Simon Tournier and Tanguy Le Carrour are not in the room with me :( <futurile>heh - I guess you don't have to buy them beers then <futurile>also I have no idea why I stuttered over Tanguys name (but don't tell him about it) <ekaitz>I don't know how to pronounce it so I won't criticize <ekaitz>futurile: about the conference, I just want to help <ekaitz>i can even host something in my city <futurile>ekaitz: OK brill, I'll email and we can chat about it <ekaitz>(i'm also an nlnet grantee and have ideas about a grant system) <futurile>ekaitz: OK, I have some research and a proposal I've written up for the SAC to comment/decide about. I'd love a review of it and any comments <emacsomancer>how do people handle connecting to Signal in a "pure" Guix setup? just don't? something with a signal-matrix bridge? <ieure>Signal is very insecure on Linux, so I don't use it there. <ieure>My understanding is that Signal data is not encrypted at rest on Linux. Happy to be shown to be incorrect. <emacsomancer>yeah, that's the line I've seen GrapheneOS and SecureBlue take. <emacsomancer>it's not just the storage issues, I think, but also the default Electron client <ieure>I believe Signal is available in third-party Guix channels, if that risk is acceptable to you. <emacsomancer>yeah, I know. lots of ways of getting Signal on a Guix machine. I have one set up like that. But also one that I'm trying to keep fully reproducible. <emacsomancer>(still I often want to be able to type more at length and phone keyboards are difficult for me) <ieure>Yeah, I hate using Signal on my phone. <emacsomancer>likewise. but end up having to do a lot of communication via Signal. being able to do it on a proper computer is so much better. but the security posture is at least theoretically not great there. <loquatdev>Hello, everyone. Has anyone else here managed to properly set up gitolite alongside nginx and git-http-nginx-location-configuration? <loquatdev>I keep receiving the following error: `fatal: git upload-pack: not our ref 0000000000000000000000000000000000000000` which is not very helpful. <loquatdev>I receive this error upon trying to clone my repository. <loquatdev>I thought it had something to do with read permissions, but fcgiwrap is indeed under this `git` group, which my repositories give access to. <loquatdev>I'm only setting `git-root` to `/var/lib/gitolite/repositories`. <ieure>loquatdev, help-guix might be the place for this, as it seems likely you need some fairly deep troubleshooting. <loquatdev>How can I see the command executed by shepherd for a failed service? <ieure>loquatdev, I think it's in the shepherd log. Or you can start it and run `herd status service' a bunch and hope you catch it. <loquatdev>Is there an established way to transform a shepherd service to use a different user/group, or am I better off rewriting it? <ieure>You mean to have the service run as a different user? <loquatdev>Yes. The git-daemon-service-type is hardcoded to use a git-daemon user, which does not have read access to my repositories. <loquatdev>I'm just trying to setup git-daemon to work for me in the meantime while I figure out the issues with git-http-backend on Guix. <ieure>loquatdev, It depends on the service. There's no Shepherd facility for this. Many services let you do that, by specifying the user in the configuration. <ieure>loquatdev, The path forward here is to contribute a patch which allows specifying the user in git-daemon-configuration, and open a PR with it. <ieure>You can, of course, develop that in your own channel, or whatever. <loquatdev>That's what I was thinking. Thank you once again. <ieure>I do that a lot, hack on services in my channel, then PR when I feel they're ready. <matf>Hey there. Just curious, has anyone tried to ressuscitate the old Nix importer for Guix in the recent years? It's been dead for years and I was not touching package definitions when it was still a thing, but would love to have it now. <mange>I'm not aware of anyone doing so, but I've had good success running Nix on a Guix system. What Nix package are you wanting to get into Guix? <matf>I would like to avoid havingnix on my system, this would be an extra store and an extra level of abstraction I'm not ready for I think, I like the simplicity of having everything Guix. But maybe I would think otherwise after getting access to over 100k packages suddenly. <matf>Maybe installing Nix would be a good idea actually if I force myself to use only nix shell and avoid cluttering my disk with permanent installs in a new store. I don't have much space left. <mange>I agree it's nice to have everything in Guix (most of my systems don't have Nix on them), but packaging things can be a pretty significant commitment. I only use Nix via nix-shell, as you mention, and it's pretty nice. <ieure>matf, I was reading about the Mecha Comet the other day, seems pretty interesting. <ieure>matf, Sounds like they have a handle on power management, I've tried some other Linux portables and lack of PM (or lack of *good* PM) has been a major issue. <ieure>Still have my original GPD Pocket, it works, but no sleep. So you close the lid and the battery is dead within a day. Very frustrating. <FuncProgLinux>While I understand that upgrading guix with sudo -E is a bad idea. What's the "correct" way in any case. I use that inside a Makefile based system to "make computer && make computer-sys" <ieure>Have been thinking of reinstalling it with Guix to see how things are now. <FuncProgLinux>for the sys-step I have to run a sudo -E since It's the system packages (as minimal as MATE gets) <mange>FuncProgLinux: Can't you just use `sudo`? My routine is "guix pull" and "sudo guix system reconfigure". <ieure>FuncProgLinux, Standard practice is `guix pull && sudo guix system reconfigure'. The only thing you need root privs for is `guix system reconfigure' and related commands (switch-generation, roll-back, delete-generations, etc). <mange>From memory an issue with "sudo -E" is that you end up with root owned stuff in ~/.cache/guix which then breaks using guix as your user. <FuncProgLinux>mange: Oof I do: guix pull -C <file> -> guix upgrade -> guix home reconfigure -> guix system reconfigure -> guix describe -f channels <mange>Yeah, I'm pretty sure you can just drop the -E and it will still work fine. <ieure>FuncProgLinux, Seems excessive. Why are you mixing per-user and Guix Home profiles. <mange>I assume it's just a single "update my machine" command. It seems reasonable to me. <matf>Ieure: yes it looks quite nice. I already told them I plan on using Guix on it (at least the package manager, system if possible) and would be happy with more than 128GB eMMC for the store, and they replied they will likely offer options (but at stockists prices, since factory prices need a MOQ, and prices are insane so I'll see). Same with RAM. That's pretty cool. <ieure>mange, I guess the `guix pull -C' is a noop if the channels file hasn't changed? <matf>I have many GPD devices running Guix system ieure, including MPC2, Mini and Pocket 3. The sleep issue is annoying indeed. Acceptable when the device is used frequently, but else I often find my devices dead after a few weeks. It's not a GPD thing I know, I have that with other UMPCs. <FuncProgLinux>ieure: I based my config from bits and pieces I found in Codeberg. That one was pretty common :< so yeah. I noticed it does work without the -E but I remember one time Ruther helped me because my $HOME.cache directory was being owned by "root".