IRC channel logs
2025-12-12.log
back to list of logs
<AndrewJ89>New user here. I've been reading the docs and playing around with guix in a VM, and I want to have my configuration ready to go before I make the switch from debian. Am I correct in understanding that guix home environments can store config files like .emacs/init.rc, .zshrc, and so on? If so, can someone link one or more good examples of this? <a4censord>heya, i wanted to test some things with the guix repl. <a4censord>but now guix repl crashes on startup with "no code for module (ice-9 readline)". i assume something about my env is missing so it isnt finding the installed files <civodul>a4censord: hi! that means that guile-readline and guile-colorized aren’t in GUILE_LOAD_PATH <civodul>perhaps you need to source ~/.guix-profile/etc/profile ? <a4censord>somewhen i disable sourcing of $GUIX_PROFILE/etc/profile for debugging <a4censord>so, i'm writing a guix home configuration rn. <a4censord>this file rn is not in the store and not part of a package (as in, its a existing config file that i wanna move over to guix home without rewriting it) <a4censord>i found gexp local-file already, but that seems only useful if i want to call it from something (e.g. service or a sway config), but i dont want to do that rn <Rutherther>you actually want to do that. Everything that guix home does to your home folder is done through a service. In case you want to make a file at location, you can use "home-files-service-type" and you can give it local-file. See the manual for example usage, it includes an example with local-file <Rutherther>this will then put the file in gnu store and make a symlink from the location you choose to gnu store. In case you for whatever reason needed to actually have the file there, not a symlink. It's also possible, though a bit more complicated <a4censord>so i'd place the file in my repo somewhere next to my home config, and use home-files-service-type with something like ("my location" ,(local-file "the file in the repo") <basicnpc>How do I search for guix commit hashes before going back using timemachine? <basicnpc>1) just usual git logs that I can see 2) easy to narrow down to see when a package/version begins/stops to be. <cbaines>the data service at data.guix.gnu.org can help with this, although the data's still not as accessible as it should be <cbaines>it would be good to try and get this displayed on packages.guix.gnu.org <basicnpc>Would be even nicer if I can see it with `guix time-machine search`.. <basicnpc>after date "2024-12-01", before date "2025-01-01", limit "100" => error "Sorry about that" without extra info 😂 <basicnpc>Hmm.. I did `guix time-machine -q --commit=ce086e31f0f` which has an older `sbcl`. And then `guix install sbcl`, but it says I have sbcl already, so nothing to be done. But I only have the latest sbcl.. <basicnpc>I'm trying to have sbcl@2.5.8 and sbcl@2.5.2 installed at the same time, without packaging them by myself. It'd be nicer if I can have a guix shell that contain both of them. <cbaines>in this hypothetical profile, what would the sbcl binary refer to? <cbaines>more generally, having multiple versions of the same package in a profile is normally problematic <basicnpc>At least they should be in /gnu/store at the same time. <basicnpc>Perhaps `guix time-machine -q --commit=AN_OLD_HASH` didn't bring me back? I also tried `guix install sbcl@oldver(i.e. 2.5.2)`, but it says the package is not found. <cbaines>refer to as in would refer to sbcl from sbcl@2.5.8, or sbcl from sbcl@2.5.2? <cbaines>having them in the store at the same time is easy, but having them in the same profile/shell is more difficult <basicnpc>How do I get them in the store at the same time, using the official guix channel? <cbaines>guix build will ensure something's in the store <cbaines>so run guix time-machine ... -- build sbcl@... <cbaines>as many times as you want for different commits and versions <basicnpc>That works! However, `guix shell sbcl@2.5.2` still doesn't work.. it says it cannot find the version 2.5.2, even though that's installed. <Rutherther>that's normal, the guix you are using doesn't have information about that particular version. Use shell along with time machine, ie. guix time-machine ... -- shell sbcl@2.5.2 <basicnpc>Rutherther: But if I do that.. I cannot have both sbcl@old and lib@new together in a shell easily? <Rutherther>for that you can use inferiors and use manifest to specify both <basicnpc>Ah. No easy, one-liner. Thanks! I will find it out in the manual how that works. <basicnpc>How do I see each step works out step by step, with pauses between steps, and with view to all standard outputs/errors? <Rutherther>To see the stdout/stderr build it on your machine and look in the build log under /var/guix/drvs <csantosb>`guix refresh --list-dependent libpng` returns only "pcsx2@2.4.0", bug or feature ? 🤔 <Rutherther>it matches the libpng-for-pcsx2. This package should've been renamed to libpng-for-pcsx2 when added imo <csantosb>I don't understand how libpng can be a dependency of so many packages, and still, --list-dependent misses them <Rutherther>because the specification has matches libpng-for-pscx2 that has only one dependency <Rutherther>it doesn't 'miss' them, it sees a different package <Rutherther>use "guix refresh --list-dependent libpng@1.6.39" to get the 'correct' libpng <vntsuyo>is there a guide on how to work on packages that use two or more build packages? <basicnpc>Rutherther So I should change the package definition, (build! package) in the guix repl, and check the log. Then add in another step into the package, and (build! new-package) again..? <vntsuyo>i'm packaging something that uses cmake and go, in particular <csantosb>vntsuyo: I don't think there is a guide, but you may get inspiration from existing packages <basicnpc>Rutherther: I want to see what each gexp entails.. directly from stdout/err.. <Rutherther>also I don't really understand what you mean by what gexp entails' <basicnpc>I add each step one at a time, and build, and manually diff the log. <vntsuyo>csantosb: can you give me some examples? <vntsuyo>or a way to search for them, that would be better <Rutherther>basicnpc: do 1. step, 2. do print, 3. do another step... I don't really understand what's not clear about that <basicnpc>Rutherther The only workflow I know now is to have a package definition and feed that to guix builder.. <Rutherther>basicnpc: right and the package definition defines the step that happen <csantosb>vntsuyo: Search for packages with #:imported-modules or #:modules in its arguments <basicnpc>I don't know how to break them down to steps.. The only dumb way I can think of is to modify the pkg def bit by bit, and see how their effects differ. <Rutherther>basicnpc: including all the prints. Ie. the gnu build system prints when it starts a phase and when a phase is finished <basicnpc>I'd also like to Ctrl-Z to pause one step, and hop into that build container to see what happens at that moment.. <basicnpc>How can I debug a GNU Guix package build interactively by: (1) Viewing the stdout/stderr output in real-time. (2) Interrupting the build process (e.g., using Ctrl-Z or equivalent). (3) Inspecting the current state of the build environment (file system) within the container. (4) Resuming the build process from the interrupted point (fg or similar)? <basicnpc>If any of these steps are not possible, what can I do to approximate them? <Rutherther>the only possible step is 1, where you execute guix build and you see the log in real time <Rutherther>the rest can be approximated by making a phase that will fail the build, along with --keep-failed and then executing the steps manually in a shell <basicnpc>Wouldn't it be nice to have (2)(3)(4) in guix-daemon ;)? Or is it fundamentally impossible to have it? <basicnpc>Theoretically it's possible, right. It's just a contained process, and one just need to figure out a way to hop into a 'repl of guix daemon'. <yelninei>the problem is once you can inject arbitrary commands into a build the derivation is no longer reproducible <basicnpc>yelninei: Then let it be. Just mark it as a dirty gix store object. <basicnpc>Anyway, it may be an interesting yet difficult project to work on.. to 'expose a repl of guix daemon to the user'. <basicnpc>Any standard API in the guix repl that lets me build? some thing like GUILE> (build! my/package)? <Rutherther>there is a command "build" in (gnu) or (guix), not sure which one. So ",build package" after using the module that has it <Rutherther>sneek: later tell basicnpc, I don't think incorporating repl to guix-daemon is necessary, maybe even not desirable. Rather a tool could be set up, making the same environment as the daemon and running the commands from .drv file <Rutherther>yes, it had to be force pushed because of a commit that didn't authenticate unfortunately <jas>Rutherther: thanks for clarification -- i already e-mailed guix-devel about it. maybe there is some policy improvement that could be considered? could the git server refuse push if guix authenticate fail? <ieure>jas, Git can't do that server-side. We have hooks set up in the clones which are supposed to enforce it, but it's not a 100% thing. <Rutherther>git can do that server-side, it's "pre-receive" hook that does that <Rutherther>also it already does check the commits are signed by the keys one has in their codeberg profile. It's just that the commit signature was fine in this case, it was just keyring branch set up that was wrong here. So that's why codeberg accepted it <hapsterr>Hi guix o/ Anyone here attending FOSDEM (and Guix Days) next Jan/Feb and staying in ICAB starting from Friday? If you do, please DM me. <Rutherther>and as for why locally my "guix git authenticate" passed, it was my fault, I have been playing with keyring branch recently and left my key there on a proper location, so "guix git authenticate" succeeded for me locally. In guix upstream the keyring branch had the key file at wrong location, so guix authentication failed <Rutherther>Forgejo supports arbitrary git hooks when DISABLE_GIT_HOOKS is set to false, but codeberg didn't do so; It's not surprising, because it's a very dangerous feature. So I don't think there is anything better that we can than 1. pre-push hook that runs guix git authenticate, 2. codeberg checking the signature matches one in user's profile. Both are already done <jas>maybe the pre-push hook could be improved to actually check against the remote keyring branch, instead of the local one? <meatoid>does anyone here "know" CMake, and if so, how did you learn it? I'd say my biggest bottleneck in packaging has been not really knowing how to patch cmake scripts <ieure>meatoid, No idea how CMake works. Every time I turn around, there's five more weirdware build systems, who has the time? <untrusem>ieure, do you use xmpp/jabber or matrix? <ieure>untrusem, I use Matrix, but I don't really like it. <untrusem>ohh then we can make a irc channel to discuss the librewolf packaging <ieure>Sure, uh #guix-librewolf, I guess? <untrusem>yeah, I am using irc through xmpp, so won't be able to make a channel, can you do it <ieure>Huh. "The #guix namespace is registered to the guix project, so only authorized contacts may register new channels." <ieure>untrusem, Registration != creation, the channel exists. <untrusem>though I channel name should be guix-browsers <ieure>untrusem, I just won't be considered its chanop by Libera. <untrusem>what build system I use for packages that are only shell scripts <untrusem>its just a single shell script with tests and a manpage <RavenJoad>This is definitely an obvious thing, but I am just not finding it in the manual right now. I want to create a package variant with a custom patch added to the list of patches. Is there something easier than package/inherit? I found options->transformation, but is that the "right way"? <ieure>RavenJoad, inherit is the usual way to do that, what difficulty are you encountering? <ieure>At least, it's the usual way I do that. <RavenJoad>ieure: No real issues. My first attempt has some syntax error, about an invalid field specifier. If inherit is the way to do it, then cool. <ieure>RavenJoad, If I'm remembering, the patch is part of the origin, so you'll want to (package (inherit parent-package) (source (origin (inherit (package-origin parent-package) (patches '("your-stuff-here.diff")))))) <ieure>Otherwise you have to duplicate the whole origin. <RavenJoad>Yeah. I'm just working it out right now. I'm using package/inherit right now. I just have to work out the incantation. <ieure>RavenJoad, It does look like you can use a transformation to add a patch. I just personally haven't messed with that. But I think either approach is fine, so use whatever you prefer. <ieure>Seems like this would be close: (define my-variant ((options->transformations '((with-patch . "path/to/patch"))) parent-package)) <RavenJoad>package-origin does not exist, so I think I would have to write out the whole origin. <ieure>RavenJoad, package-source, or whatever the name of the field is. <RavenJoad>I pretty much have that with options->transformation, but use 'with-patches instead. <ieure>I think source is the package record field name, origin is the type that goes in the field. Wish they were named the same. <RavenJoad>It makes sense that they aren't since origin's are technically packages. <RavenJoad>I just have to figure out why my options->transformation does not error, and just returns the original package. <RavenJoad>Oh fun! I just found an undocumented Guix-provided function that will do exactly what I want. The package-with-extra-patches procedure form (guix packages). <ieure>Nice. Lots of those in the repo. <RavenJoad>Now I just parameterize the %patch-path and I can search in my own patches directory. <RavenJoad>Agreed. It would be really cool if the Function Index were generated from Guix's scheme itself to avoid this problem. <postroutine>Hello. I'm writing a package and Guix tell me that "%standard-phases" variable don't exist. In which module this variable is defined ? I search on the documentation but cannot found anything. <ieure>postroutine, Share your package definition using a pastebin service, please. <Rutherther>it's in multiple modules, depending on the build system, ie. in "(guix build gnu-build-system)". But that error message likely signals something is very wrong with your package definition. You aren't really supposed to need to import this module yourself <Rutherther>yes so the error here is that you didn't somehow quote your phases, ideally by using a gexp, ie. "#~(modify-phases ...)" <ieure>postroutine, Your arguments list needs to be a gexp. <ieure>Or at least the modify-phases part. <postroutine>I took inspiration from the ant package, who didn't do it. <RavenJoad>Like others have said above, you need to gexp your modify-phases. %standard-phases is not defined by the (guix build-system ...) modules (which is host/build derivation side). They are defined by the (guix build ...) modules, which run inside the builder. <ieure>postroutine, I'm looking at the ant package and it says #:phases #~(modify-phases ...) <ieure>postroutine, Yes, the non-Java 8 Ant package uses the old style package definition which existed before gexps. <Rutherther>postroutine: look up few lines above and you will see it's quoted <ieure>It's the older version. ant/java8 is the current package, what you get if you `guix install ant' <postroutine>I'm very new to all of it, and sometimes even after reading the manual, I get the feeling that I have missed a lot of things. <Rutherther>because it's not modify-phases that should be gexped, it's the arguments in general. The arguments are sent to the daemon. <postroutine>In the manual, the package reference tell to the "arguments" field is a list. <Rutherther>yes, but a list of what... of quoted/gexped arguments:) <postroutine>I'm completely lost about the g-exp. When to use them, how to use them, what the would have access to, etc. <postroutine>I have g-exp thing the value passed to `#:phases`, but I get the error `erreur : gexp : variable non liée`. <Rutherther>did you by chance forget to use (guix gexp) module? <RavenJoad>I've been using gexps for quite some time, and I still occasionally struggle to get the right gexp and un-gexp incantations. <postroutine>> yes, but a list of what... of quoted/gexped arguments:) <postroutine>I've checked the manual about it, but it did not say to set a list of gexp argument. I also checked the cookbook. Maybe I've missed it, but it seems an important information is missing in the manual and cookbook. <RavenJoad>postroutine: The exact contents of package-arguments depends on the build-system that has been selected. Every build-system has #:phases, most have #:tests? defined, some have specialty things (#:import-path for go-build-system). <RavenJoad>You can see the ones you explicitly need by looking at the builder-side code for your build-system in (guix build ...), since the builder uses what you provide in package-arguments to the functions arguments that do the actual building. <untrusem>is there a way to remove unused imports from a file <Rutherther>postroutine: dcoumentation for package explicitely shows gexps in an example. Also it mentions that previously regular quoting has been used <postroutine>Rutherther: I hade missed it, because it was only on an example and implicite in a compatibility note. <postroutine>When I write a package for the first time, I have a high chance of not reading a compatibility notes. As I do not already mantain a package that would require compatibility. <postroutine>And I read too quickly the example and missed the #~. As I'm not familiar with it. <ieure>postroutine, It gets easier. <FuncProgLinux>hello, anyone else using MATE or XFCE that got their desktops broken by latest updates? :/ <FuncProgLinux>MATE doesn't start the settings daemon properly, it dies with "Failure loading - matecc.menu". Tried falling back to XFCE but I wasn't aware that apparently it's not made for dual-monitor setups or something <ieure>FuncProgLinux, `guix shell arandr -- arandr' should let you set up your monitors if the DE doesn't support it. You can also roll back the update and continue using the working MATE. <FuncProgLinux>ieure: It kind of supports it, but if you reboot on a dual-monitor setup, you get a corrupted primary screen. The Working MATE I have it's like two weeks old :/ and there's no info about the "Failure loading - matecc.menu" error. <FuncProgLinux>Literally only the usual .deb based trick of apt-ing things and an Arch Linux thread that unsuprisingly got no answers. I nuked ~/.config/ from my home dir and dconf resetted everything but to no avail :( <bdunahu>maybe you could guix pull a specific commit that is newer than two weeks? Then you might also narrow down which commit broke it. <FuncProgLinux>Idk what could have broken those things. XFCE also has issues with defaults. Not a single keybind is loaded even when you "restore defaults" <FuncProgLinux>arandr seems to fix the XFCE issue but it leaves the desktop suuuuuuper slow <Rutherther>if it's wayland, that's likely the issue. arandr is for xorg <FuncProgLinux>Rutherther: It's Xorg, AFAIK XFCE is still very green on the wayland stuff <FuncProgLinux>I also noted someting funny. I recently got a second monitor (same vendor) and the XFCE screen configuration shows the same string for both monitors even same settings. <FuncProgLinux>Both are "primary". However, arandr is giving much better details and knows which one is the "true active" monitor <Rutherther>FuncProgLinux: have you tried starting the compositor after you make the changes through arandr? maybe it's just that there are changes it doesn't expect <FuncProgLinux>I'm digging on the web browser but I've found no particular useful information about this. Some say it could be the drivers but Nouveau works fine on my old card, I wouldn't want to use the proprietary driver :/ <FuncProgLinux>I don't wanna sound rude but is there a DE in good shape rn in Guix? :/ even Enlightenment has some issues like two sessions installed on lightdm and random freezing 😶 <FuncProgLinux>The MATE issue seems to be related to XDG but idk if that received an update recently :/ <bdunahu>I don't know if there's an easy way to bisect commits with `guix pull` to find the cause for something like that quickly, but I would be interested in knowing as well. <bdunahu>Knowing if there is a good method for bisecting and testing, that is <ieure>bdunahu, You can use `git bisect' and `guix time-machine' to do that, but it's quite slow. <ieure>FuncProgLinux, I daily drive EXWM and use Gnome fairly often, Gnome is in fine shape. <FuncProgLinux>I mean I could reboot into a previous generation with MATE but it seemed so random that particular breakage <ieure>Will also say that I have never once had any luck running a compositor under Xorg, every one I've tried has been so buggy I wonder if I'm the first person to use them at all. <ieure>I ran one only because the Intel Xorg driver got deprecated, and the KMS one didn't (doesn't?) do anything to prevent tearing. <FuncProgLinux>In XFCE and MATE both come with a built-in compositor. I don't understand though why the MATE one has 0 issues and the XFCE one doesn't like dual monitors <ieure>But it was always a bug-ridden hassle, have to screw around in all the settings to find the one that actually worked, many of them either don't fix the tearing or don't work at all, the right setting varies based on hardware, would screw up if the monitor configuration changed at all. Just awful. <vhns>I run GNOME, XFCE and others just fine in Guix, if that's of any value. <vhns>I am on a laptop with a somewhat old integrated Intel graphics card. <FuncProgLinux>I'm using an Nvidia Quadro 100 card on an old Dell Precision Tower <FuncProgLinux>It's a bit of a shame that things break this way though 😪 I've been here all morning trying to solve this issue. I tried booting into a previous generation now but MATE is still broken for some reason <FuncProgLinux>Rutherther: Not yet. I have a "mirror" config in my laptop, I'm updating it to see if it's a MATE issue or a user side issue <FuncProgLinux>My .xsession-errors reads Failed to lookup menu file for mate-applications.menu