IRC channel logs
2026-06-03.log
back to list of logs
<k00s2>ieure: Okay, thanks for your kind guidance! Nice to know that it worked for you, hopefully this route can also work for me <ieure>k00s2, You're welcome to open a draft WIP and request review from me. <noxi>Bumping mpd to 0.24.12, because 0.24.11 is buggy and there was no QA :( <k00s2>ieure: Okay, what would that entail? I have not contributed to guix yet, my packages have been local so far. Is the proces then just forking guix on codeberg and making the pull request (as draft) from there? <k00s2>Ah, I found the Contributing guide which seems to answer more than all my questions for now. Thanks again ieure, I'll keep your offer for reviewing in mind :) got to go now <AliceAnD>there is something on the website and in the manual <stephen0>Ah, yes, in the info pages -- Okay, I had seen this. <apteryx>is there a point to have our Makefile.am target POSIX Make instead of GNU Make? <efraim>it would be Better™, but in the past we've explicitly targeted GNU programs and libraries (and glibc) as a way to define the scope of support <efraim>my only real concern though would be if it made the file hard(er) to read and/or greatly increased the size due <sneek>Welcome back yelninei, you have 1 message! <sneek>yelninei, janneke says: an 11y old bug, is it that hard to fix or did it get so little attention? where does it hurt us exactly? <yelninei>sneek later tell janneke: Anything cross compiled using popen/system/.. invokes a shell that is not cross compiled which obviously fails. Fixing it would mean to create an intermediate cross glibc to first build a static bash <yelninei>sneek later tell janneke: I found it while trying to use x11 forwarding in a cross compiled openssh. I am actually surprised that not more is broken. You can easily test with using system from a cross compiled guile <janneke>yelninei: ouch, yes i was surprised too and wondered why this only seemed to hurt the hurd <sneek>janneke, you have 2 messages! <sneek>janneke, yelninei says: Anything cross compiled using popen/system/.. invokes a shell that is not cross compiled which obviously fails. Fixing it would mean to create an intermediate cross glibc to first build a static bash <sneek>janneke, yelninei says: I found it while trying to use x11 forwarding in a cross compiled openssh. I am actually surprised that not more is broken. You can easily test with using system from a cross compiled guile <janneke>but now it makes sense, we probabably never cross-compiled x11 for linux <yelninei>it affects everyone, it is just that hurd is probably one of the bigger users of cross compilation <yelninei>an alternative would be to not override the shell path when cross compiling and just use /bin/sh but that would require changing glibc itself and is not very guixy <yelninei>or massively rework cross-base to add a static bash (does that work for mingw?) <apteryx>lilyp, noe: there's an error on current gnome-team: ice-9/eval.scm:293:34: error: rust-glycin-3.0.7: unbound variable <efraim>It's possible it's one of the crates I removed when I did the purge recently <apteryx>I think it's one we're updating on gnome-team <apteryx>I guess it forgot to remove the variable <apteryx>or rather, replace it with rust-glycin-3.1.0 <efraim>I wonder if I can set the home-directory of a user to a gexp <efraim>it might be easier to create a home-config->skeleton converter <resica>How long does guix keep older packages around for? Such as qt5? <identity>resica: what do you mean by that, exactly? <identity>how long do the files stay in the store or how long do the package definitions stay in the channel? <resica>Whichever one applies to precompiled binaries. I was hoping I could use guix as a time machine to forever keep a program around. <identity>again, do you mean how long the files stay on your machine, or how long do the substitutes stay available on the build servers? <resica>Oh, sorry, I misunderstood what you were asking. I meant the build servers. How long I can pull from guix directly without having to build myself. I hope I'm getting the terminology right. <identity>resica: i am still not sure i understand for what you are asking. if you are asking for how long the binary substitutes stay on the build servers, the answer is a few years, but disk space is finite, so the older ones get deleted eventually, so if you are planning to go back ~10 years from the current commit, you will probably have to build everything from source, and hit a few rocks, because some packages might fa <identity>il to build because of e.g. tests depending on the time the machine reports, though there are mitigations in place, of course <trev>> how long the binary substitutes stay on the build servers <trev>this is most definitely what is being asked <yelninei>cannot find -lc: No such file or directory, oh god <csantosb>I have quite a few build errors due to incompatibilities 😥 <psycotica0>I am not resica, but their question made we wonder my own question: <psycotica0>If I wanted to mirror / cache the substitutes server for my own uses, like how they wanted a qt binary to stick around, but I didn't want to mirror the whole thing, is there an equivalent to "fetch me the prebuilts for this package and all its dependencies" such that I could put that on my own substitute server? But only for the few packages I maybe want to care about? <identity>psycotica0: well, ‹guix build package› builds/substitutes the package and all its dependencies; you could pack that into a tarball (or some other container), or just share your own store afterwards <identity>see (info "(guix) Invoking guix pack") and (info "(guix) Invoking guix publish"), respectively <yelninei>csantosb: the build system does not do anything special for that. It is supported by gcc-14. As long as the configure script correctly sets c++20 youll get c++20 <yelninei>manually cross compiling a static-bash sucks <yelninei>it should just work . What error do you get? <yelninei>csantosb: Maybe something with the ancient clang? <yelninei>csantosb: yosys seems to set clang as the c compiler. the default for that is clang-13 <csantosb>Oh, you mean our clang13 is a bit too old; I think this is the problem, yes. <ieure>Guest33, I don't know the solution to your problem, but the thing you're doing won't work. The configuration you pasted expresses will add D-Bus services in the flatpak package, but it doesn't have any. <Guest33>ieure so i have to specify a flatpak then? <ieure>Guest33, As I said, I don't know the solution to your problem. <ieure>Guest33, I neither use nor like flatpak, but the likely issue is that programs run under it can't see the ^DBUS.* environment variables and/or don't have access to the paths they point to. <Guest33>ieure i see. well ill be here in case someone wants to take a stab at it <ieure>Guest33, You're better off posting to the guix-help mailing list. <Guest33>ieure i tried posting to the help list before. they took a week to get one of my issues posted. <ieure>Guest33, The first email to the list has to be manually approved, if it posted, there won't be a delay. Has to be like this, otherwise it'd be inundated with spam. <yelninei>janneke: I created a WIP PR which theoretically should fix the problem. It still needs some fiddling as the packages are not actually built using gnu-cross-build which creates some fun challenges with Header include order etc <Guest33>ieure i understand that but by the time they posted my issue i had already solved the issue i was having. <ieure>whereiseveryone, a Guix wiki would be very good... though it might have to be unofficial, since some of the most popular questions are going to be around firmware. <stephen0>I recall looking for one and was briefly confused because there was a guix section in the gnu wiki that I though was a guix wiki... <stephen0>It points out that the manual and cookbook as better resources for guix documentation. <argp>How do teams handle upgrades of default language versions? <argp>what is the process? and how to propose the change? <[>something is causing shepherd to lock up (use 100% CPU on my server) and it's making it completely unusable (can't log in on ttys or over SSH or use sudo) <[>what could be causing this? <ieure>[, Change services recently? <ieure>I assume it didn't break out of nowhere, with no changes made. <[>ieure: my server's hardware died earlier today (I think it was the PSU) and I moved the drive to another computer to bring it back. I'm noticing this behaviour with the generation from May 31 (commit 6e09c50eaf2f15d3bff061895019b10293209fcf, Linux-libre 6.18.31) which previously seemed to be running fine (I would've noticed if SSH logins started failing), and with a newer generation from today <[>(commit 8067c6b69eeaf64510a69a97c9f22daabd7cfa5b, Linux-libre 7.0.11), but not with an older generation from April 30 (commit 4ee924eff75e7bf35a7708c0a887977ff6afae3e, Linux-libre 6.18.16). It's not filesystem corruption because btrfs scrub passes <[>In the latest generation I changed the bootloader configuration (since the new hardware has libreboot and no longer needs an UEFI bootloader installed) and removed the copy-fail mitigation, but I don't think it's that <[>actually never mind I booted the April 30 generation and it happened again <[>could some read/write file that shepherd uses have been corrupted in a way that btrfs checksumming wouldn't detect? <[>so the only thing that changed was the hardware and possibly issues caused by the previous hardware suddenly failing (but no actual filesystem corruption) <vagrantc>hrmpf. seems like my downloading of linux upstream tarballs consistently is failing at 99.9% <vagrantc>guix substitute: error: corrupt input while restoring '/gnu/store/r9g5rrkjdh1qrbfqh78z45vbcksarvd6-linux-5.10.258.tar.xz' from #<input:hash-input ffffaf5b2820> <[>is it normal for shepherd to listen on port 22 and start sshd on demand, repeatedly? <vagrantc>whoah, 5.10.258 built successfully on x86_64-linux for the first time in over a month... <vagrantc>given that nobody complained ... i am guessing there are no users of linux-libre@5.10 <argp>guix makes me realise what a dependency hell "modern" software is and languages like go enable this. <[>ok, I think I figured something out: fd 62 is /proc/kmsg <[>so it is hanging waiting for more data from /proc/kmsg <vagrantc>there is something massively fscked with my guix-daemon <[>it doesn't reliably happen and I'm not sure what's triggering it <vagrantc>i can guix download the same thing successfully, and it works fine, and then when i go to build the package with that hash, it works fine ... but guix-daemon is not able to download linux source tarballs <vagrantc>maybe there's a bunk kernel.org mirror it is using or something ... <mlxdy>Why there's no any electron app in gnu guix repository/ <ieure>mlxdy, Probably bootstrapping issues. <mlxdy>Is it not because properiatery codecs in chromium? <ieure>mlxdy, I'm not super familiar with this domain, but I believe it is not. We already have ungoogled-chromium, and I believe there's some electron stuff in nonguix which uses it for the electron programs in that channel. <ieure>They have stuff like element-desktop, this is Free Software, but my understanding is that bootstrapping it from source is difficult. <vagrantc>then there's also the "nobody got around to it yet" <ieure>That's at the bottom of the majority of "why"s for any "why doesn't Guix do X" type questions. <mlxdy>I started to using Guix as my daily driver. <vagrantc>well, there's one way to find out why it isn't packaged yet ... try to package it :) <ieure>vagrantc, "This isn't packaged because I'm a dumbass" <mlxdy>But there's a lot of troubles, I had to sign up on mailing list because I'm not able to fix all these problems by myself. <ieure>mlxdy, I ran Guix on a secondary laptop for around a year until I had things working how I wanted (and understood the system) before switching over my daily driver. <mlxdy>I'm looking for challanges on my daily driver. <mlxdy>When I do emulate sh -c ‘. /etc/profile’ in Zsh sudo start to works. But when I execute next command from .zprofile emulate sh -c ‘. ~/.profile’ it stops to work <ieure>mlxdy, I think the support for fish is less mature than bash or zsh. The immediate problem is that you're running the wrong sudo, it needs to be (I think, away from a Good Computer) /run/setuid-programs/sudo <ieure>I have the same issue with nmtui needing sudo, I think it's either a polkit thing or some group my user doesn't have. Gnome's widget works fine. <mlxdy>But problem exist in all shells. But for bash and zsh I have temporary fix. <mlxdy>Guix is cool project, but it's still inmature and it need a lot of improvements. <mlxdy>Also question - where I should install most of my programs? Globally or home? <mlxdy>I couldn't make my fonts working on my user when installed globally. <Ghil>I am a very new user, but I believe it should be home. <mlxdy>Yeah, I think that when there's no need to install globally then it should stay in home. <Ghil>At least that's what I'm doing, I have very few things that are scoped into the system, a bit like how I do it in NixOS <ieure>mlxdy, Things needed for the operation of the system as a whole need to be in the system profile, everything else should be in a user profile of some sort. <stephen0>I'm new too, but my rule is, if it needs setuid I put it in system, if it doesn't, I put it in my user config. <mlxdy>I installed shells and wm in system.scm <ieure>setuid programs, services, programs for using those specific services. If I have a podman service in the operating-system, I also stick the podman packages in there. <Ghil>Yeah, only thing I have too is Mango in system, that's pretty much all. <mlxdy>Also can I move my guix-home-config to other directory, for example .config/guix ? <ieure>mlxdy, I wouldn't put it in ~/.config/guix, but it can live anywhere. Mine is ~/projects/dotfiles. <ieure>mlxdy, ~/.config holds state, feels weird to put the declarative configuration for what (some of) that state should be in the place the config causes the state to be placed. <Ghil>Everything is in system.org, located in ~/.dots, it unpacks in that directory as well. <Ghil>Then use guix home reconfigure -L ~/.dots/modules ~/.dots/home.scm, same for system. <cdegroot>Mine is ~/dotfiles/guix-home/config.scm. <stephen0>mlxdy: your sudo issue - looks like maybe you put sudo into your home config somehow <stephen0>the network manager issue can be fixed with a polkit rule -- I'm not on the system where I used someone else's snippet to make it work <mlxdy>stephen0: But how to fix it? <mlxdy>guix remove: error: package 'sudo' not found in profile <stephen0>were you in the profile when you ran that? (ie in the environment that gave the error and showed that weird path for the sudo binary)? <stephen0>in your forum post you didn't share the home configuration, just some snippets, did you put the sudo package in your config directly? <mlxdy>It could happen as I'm learning this system, but I don't have sudo in my home conf right now. I'll try to reconfigure home. <cdegroot>w.r.t. nm-applet: that's an issue when you have two Guix installs, effectively, and polkit thinks that they are different. power management is another one. I install the tools that I use and have these issues on the system level rather than the user level (for me that's thunar's volume daemon and xfce4's power management stuff).