IRC channel logs
2025-10-15.log
back to list of logs
<RavenJoad>Inside of the Guix repository, how can I take a package definition and add extra #:configure-flags most succinctly/ergonomically? options->transformation does not seem to be what I want. <ekaitz>RavenJoad: substitute-keyword-arguments maybe? <ekaitz>or maybe i didn't understand the question? <RavenJoad>ekaitz: It looks like that's what I want, yep! Some background: I'm updating telegram-desktop and need another library for some reason (tde2e), which is provided by tdlib (which is in Guix), but is not built by default. I need to add an entry to #:configure-flags to tdlib to make it build tde2e. <ekaitz>but in that case I would just overwrite the package <ekaitz>substitute-keyword-arguments makes more sense when inheriting <RavenJoad>For sure. I am going to mark it as a hidden-package anyways. I just need to see if tde2e from tdlib is actually what I need. Or if CMake is breaking in other mysterious ways. <cluelessguixer>I finally figured out why I didn't get graphical console on one of my Guix servers! <chipb>cluelessguixer: woah. how did you figure that out, and why the heck would it be in the critical path for graphical console? D-: <RavenJoad>I moved the cppgir-for-telegram-desktop specialty package definition from (gnu packages glib) to (gnu packages telegram), but now the telegram module says cppgir is an unknown variable, despite #:use-module (gnu packages glib) being present at the top. Why might that be? cppgir is only used by the cppgir-for-telegram-desktop package throughout the entire Guix repo (checked with `grep -nr "cppgir" *`). <cluelessguixer>chipb: Running virt-viewer on the host finally revealed it. Showed nc command not found in the output. With hindsight I could have saved a lot of time trying to install some packages that only the working Guix server had. <RavenJoad>Is there a way for me to get an unpacked version of another package's source? #$(package-source (this-package-input "fcitx5-qt")) is a tarball. <bavier>RavenJoad: I think you need to literally untar that result. I'm pretty sure there are some examples in existing packages (don't know of one off-hand). <RavenJoad>bavier: After tinkering, yeah, that's what I think I have to do. I mostly just copied the unpack phase from gnu-build-system. <aua>Hello, I was configuring my config.scm as part of a manual installation, and I want to use wayland for my system defaults. I almost have it right, but there's an error with my window manager package, labwc, as follows: <aua>error labwc unbound variable hint: did you forget a 'use-modules' form? <aua> I can share my config <aua>i tried guix pull to the codeberg URL as well <aua>to ensure that labwc would be included <efraim>kestrelwx: it does give "Oh noes!" in qutebrowser <efraim>I haven't tried anything yet with nouveau <kestrelwx>Hi! Yeah, I figured, since it worked for me elsewhere. <gabber>sneek: later tell ElephantErgo: it worked just fine (resize the partition, then the fs) <flypaper`>Hey guix, when is it justified to add a new build system? I've been working on packaging dictionaries for apertium, and they all have a similar layout, all need to have a specific phase added and all share a set of dependencies. Right now i have 5 such packages, of which 2 are 'leaf' packages, but the list of potential packages is pretty large: https://wiki.apertium.org/wiki/List_of_language_pairs. So I could either go the 'plain <flypaper`>way', inheritance of a 'prototype package', or a build-system, whats the proper way to go here? <ekaitz>flypaper`: you may want to make a build system in that case <ekaitz>flypaper`: propose it in a pr and we'll see what people says about it <flypaper`>build system would feel nicer and make it easier to add things in the future. <flypaper`>okay! I'll do that. Hadn't written the build-system yet, but i think i know how to get started, looking at r's and luanti's build system source, because its just the gnu build system with some minor modifications. <ekaitz>flypaper`: that's what most of them are LOL <adanska>made PR #3554 with my mutter fixes. There's still one test failing, and it seems important enough that i dont think we should disable it to get the suite to pass. any help troubleshooting this would be really appreciated! <tesseract>wow. icecat got update really fast. it beat debian's firefox release time <sneek>andreas-e, you have 1 message! <sneek>andreas-e, csantosb says: pushing to world-rebuild is still valid ? <andreas-e>csantosb: It may have been a while since you asked the question. No, world-rebuild is not a permanent branch, it was just an experiment. We could open such a branch again, but I would wait until after the release now. <mra>out of curiosity, how does guix actually interact with the daemon? my understanding is that guix adds derivations to the store, and that the daemon is responsible for actually building the derivations in the store <mra>but is the daemon just constantly watching the store for changes to detect when Guix adds a derivation to the store, or does Guix send some kind of signal to the daemon? <andreas-e>mra: I do not know the details, but store handling is done through the daemon, including adding derivations. <bdju>I've installed id3lib and eyed3 but I can't find the binary that can actually list and change tags for either of them. <mra>oh, interesting! i assumed that since guix itself has an internal representation of derivations via the <derivation> struct, that it serializes those derivations to disk itself <mra>i'm juts kind of curious about how the guile code of guix actually interfaces with the C++ code of the daemon <ekaitz>mra: what I know is how the daemon calls the phases and all that <ekaitz>mra: but i'm missing the other part, how guix triggers the daemon <mra>ekaitz: what do you mean by how the daemon calls the phases? <identity>mra: iiuc the daemon does not run until something opens a connection to it (socket activation); then, the daemon gets the instructions on what to build, including the derivations <bdju>Okay, found the binaries with `ls $(guix build id3lib)/bin` and similar for eyed3. Interestingly for eyed3 the binary uses a capital D, eyeD3. There's no man page for eyeD3 but it has a --help output. id3tag and id3info also don't have man pages but have --help output. A bit troublesome. <mra>identity: ah, so guix binds to the daemon's socket and sends it commands that way? <mra>and then there's some kind of IPC protocol for communication with the daemon, i s'pose <mra>that makes more sense <ekaitz>mra: i meant how does actually the daemon call the guile code to build the packages <mra>identity: oh, i totally should have looked at that earlier. thanks! <mra>i'm very interested in understanding the daemon a bit more deeply. this seems like a good starting point <ekaitz>identity, mra: "this section is currently incomplete"? so sad <mra>ekaitz: the source code for `build-derivations` seems like a decent place to start looking though <ekaitz>mra: If you feel very motivated and you want to improve the docs, I'll review & commit <ekaitz>oh! still C++ we need to do something about it <ekaitz>the Guile migration is still blocked? <identity>iirc it was blocked on «something more important to do» and not «we need to do this before we can beguile the daemon» <ekaitz>that's good news but also bad news <mra>seems like a ton of work, which i assume is part of what's holding it up <mra>i'm also not sure how well-understood the internals of the daemon actually are? <cmack>mornin! I'm trying to experiment with a nintendo switch pro controller via usb, evdev, and libinput but it seems to not be detected. Specifically it doesn't seem to get the ENV{ID_INPUT_JOYSTICK} ="1" in the udev rules. is there a simple flag for this in e.g. udev-service-configuration or do I need to write a full udev rule? Or has anyone fixed this before? <ekaitz>mra: well, the code is there, and it's not that much I believe <ekaitz>we should join some nix dev like picnoir and make the port <mra>ekaitz: yeah, the daemon isn't huge iirc. i will have a lot of free time starting in 2026... <mra>maybe something to look at <ekaitz>csantosb: OOHHH acabo de ver!!! vamoooos! <mra>given how much i like guix, i should really start actually using it lol <ekaitz>mra: that's a good way to find parts to contribute to <meaty`>kudos to whoever packaged miniflux and wrote a service for it <mra>ekaitz: kinda how i started working on ZFS stuff. lack of ZFS support is what keeps me from using Guix System on my personal devices <ekaitz>mra: add support for it! (see? I have solutions for everything!) <mra>ekaitz: been working on it on and off since february or so. unfortunately the problems are more legal than technical <mra>it's a copyright violation to distribute an initrd with the zfs kernel module baked in, so we need to make it possible to include the zfs kernel module in the initrd <mra>while also ensuring that such an initrd cannot be substituted <mra>ekaitz: welcome to my torment :) <mra>and implementing this for the existing #:substitutable? parameter would break things very badly <mra>it's a pretty interesting problem, even if it only exists for silly reasons <meatoid>is there a way to run "system" services from the unpriviledged user shepherd or vice versa? <gabber>meatoid: not sure if i understand correctly, but i don't think so <gabber>what exactly are you trying to do? <meatoid>just an idle thought. I remember seeing a "for-home" adapter function for service configurations <meatoid>aha, yes, that's where I remember it from <gabber>where can i check how some package is built on other distros (like debian or nix)? <gabber>how shall we handle an application trying to read a non-existent /etc/gnutls/config file during startup? <meatoid>are you packaging something or is something broken? <gabber>and crafting a seafile-server service (not sure about the naming though ;) <meatoid>in that case the general strategy would be to figure out what package or service provides that file, then amend the 'wanting' package/service to look there <meatoid>I would start with 'guix build gnutls' then hunt through the resulting dir for your file <gabber>flypaper`: i packaged the applet, too (but never upstreamed my work) <flypaper`>also includes seadrive-fuse, which might be useful. but cool that you're doing the server <meatoid>then, you can patch the package to search in the appropriate location <gabber>meatoid: i think the config file is what "mainstream" distros install by default (for whatever reason) <gabber>i'll try just serving an empty file <meatoid>maybe there is a service in guix that provides it? <meatoid>i want to play the new ring racers release candidate, but i have to package it first... <meatoid>i wonder if anyone uses the package i sent in for the first version <gabber>flypaper`: i'll gladly take up, review and eventually merge your PR once i get to it (: <gabber>would you mind creating a PR on codeberg and assigning me? that way we could close the old issue and raise chances i will not forget and actually do it (: <gabber>btw QA seems down (or having troubles... <flypaper`>gabber: sure! don't think i can tonight, would you want me to also refresh? <PotentialUser-31>hey for some reason PS1 is not changing in .bashrc but the other variables are changing. I have this is in my home config (environment-variables '(("PS1" . "\\[\\e[1;32m\\]\\u \\[\\e[1;34m\\]\\w \\[\\e[0m\\]λ ") <Rutherther>PotentialUser-31: how does your .bashrc look like currently? <meatoid>PotentialUser-31: have you tried using the dedicated shell configuration service? <Rutherther>also, did you relog after making this change? Environment variables are sourced only on logging in. And this is omitting the fact that PS1 shouldn't be an env var in the first place <Rutherther>yeah, so it is being overriden by .bashrc, environment variables are sourced prior to .bashrc <Rutherther>so you won't be able to change it through session-environment-variables service <meatoid>PotentialUser-31: there is a service for configuring bashrc <Rutherther>use the bashrc field of home-bash-service-type to add the PS1 <meatoid>PotentialUser-31: no, Rutherther got it right. look thru the info manual index <meatoid>btw, has anyone else got a chance to use the niri home service yet? I've found that it works right logging in from tty but the session doesn't start when logging in from the gnome greeter (i forget what it's called) <meatoid>probbably because the greeter tries to start its own session but can't because niri is already running <meatoid>Rutherther: I'll check when I get home <meatoid>I'd suspect it's not that the service fails to start, but that the service runs, and thus the session that the greeter tries to start fails <Rutherther>sure, but the log should contain also the errors of a session it tries to start <meatoid>I want to write a parser module for KDL so that the service can configure niri instead of running it, like the sway service does <meatoid>Eventually we should decide/make a standard way of doing window managers/compositors so the behavior is consistent. I remember discussing on guix-devel a while ago about how we would get services to play nice with greeters, but until then the sway service seems to have the right idea <meatoid>There is already a kdl parser for commonlisp that uses the packrat algo, so rn I'm reading up on that until I get home. it seems simple enough to translate since there is already a guile-packrat module <mra>do builders for derivations "compile down to" shell scripts in the store, so to speak? <mra>continuing to waste time trying to understand the daemon better <Rutherther>the builders aren't related to the daemon. The daemon can run whatever as the builders. Guix uses Guile. Nixpkgs uses bash for example <mra>Rutherther: ah, yep, that makes sense. i was just wondering if it uses bash because nix does <mra>but it actually uses guile. neat! <Rutherther>if you look into a derivation, like what "guix build --derivations hello" produces, you will find the whole invocation with arguments. The daemon doesn't care what it executes <mra>also, glad to see you joining core! :) <mra>Rutherther: i don't actually use guix, so my access to just poke around inside of guix derivations is somewhat limited <ekaitz>mra: think a little bit about the difference between build-system/ and build/ folders <mra>ekaitz: sorry, but i'm not familiar with the build-system and build directories <ekaitz>take a look to them, they deserve it <mra>ekaitz: oh, i assumed that you meant that these are directories on a Guix system. i see them now in the repo. i'll take a look! <ieure>russell`, What's the exact command you're running? <ekaitz>the other manual is the "release" one, and is very old <russell`>ieure: "guix install texlive-base" and "guix shell texlive-base" <russell`>ekaitz: I had no idea another manual existed, thank you <ekaitz>russell`: that happens a lot, we should do it more obvious <ekaitz>the one that should always work for you is the one you have installed with your guix <russell`>thanks, that got me started with some basic pdflatex! <ieure>Looks like GNU DNS servers are broken. <mra>ieure: GNU servers are broken? what is it, a day ending in -y? <ieure>mra, The DNS servers haven't been unreliable, because the people behind the LLM DDOS on the whole Internet don't care about scraping DNS. <ieure>And DNS is a simple protocol that requires hardly any resources. <mra>ieure: wonder what took them down then... <ieure>mra, Network issues, memory leaks, zero monitoring or alerting. The usual, I'd guess.