IRC channel logs
2026-11-09.log
back to list of logs
<jlicht>I see some weird host-side gexp wizardry in the guile-osc package; could it be that it expands at the "wrong" time when doing the "(effective-version)" thing? <Cubi1>Something i'm trying to package has a cmakelist that tries to import another git source (and well, fails, because I assume its not allowed to do that) <Cubi1>the repo has a tar with the source I need, is there a way to import that into the build along with the normal URI like using snippets or something? <Cubi1>Well, if anyones willing to help please. <bdunahu>Cubi1: is it using CPM or FetchContent? <bdunahu>usually what we do, if you're going to contribute the package, is slightly modify the build script to use the guix vendored version of the thing being downloaded <bdunahu>otherwise snippet would probably work depending on what they're using in the script to download <Cubi1>bdunahu: its using git to try to pull in the package <bdunahu>can you show the link to the line in the build script? <Cubi1>monado's source is also supplied as a tar file in the releases for this program, and its what gentoo uses to build it. <bdunahu>so this monado source looks like it's being patched so we can't simply use the guix vendored version <bdunahu>pass in the location of that checkout to your configure args, the SOURCE_DIR_MONADO variable <Cubi1>sorry, did you link to the right thing? <Cubi1>nvm i think I know what you mean <bdunahu>the example in the games file is how you'd tell guix to download a monado checkout and make it available in the build process <bdunahu>but you might be able to even just add (package-source "monado") to your inputs for WiVRn because we already package monado <bdunahu>it depends if WiVRn's custom patches will apply to the version of monado we carry <Cubi1>alright sweet, yeah I get you know, either way I could prob apply the patches manually through snippets then if the cmake stuff doesnt work <bdunahu>oh yeah one other thing, if you set FETCHCONTENT_SOURCE_DIR_MORADO=#$(this-package-input "morado"), WiVRn might not be able to apply the patches since the build user isn't allowed to modify files in gnu/store, so you might have to copy the morado files somewhere out of the store path into the build dir with a snippet and then point fetchcontent there <Cubi1>alright I get ya, thank you regardless im still new and this is like.. my second guix package ive been working on and yeah. <jlicht>sneek: later tell civodul: I don't really understand how, but the suspicious change I've seen recently is that we clear the "object cache"(?) due to the transformations <jlicht>sneek: later tell civodul: could it be that it was always broken, but clearing the cache allows us to (sometimes) see the breakage? <adanska>Hi Guix! Would anyone with commiter rights be able to take a look at this one? (https://codeberg.org/guix/guix/pulls/10708) It adds fprintd support to gdm and PAM. I've been using it on my machine for a while and it's been working a treat. Would be super keen to see this merged. :)) <untrusem>the commit message would need to be adapted to chanelog format we use it guix <adanska>untrusem, I have forwarded the feedback to the patch author. Thanks for taking a look :) <untrusem>I guess very few uses fingerprint in their laptops <nutcase>Hi. With "guix home list-generations", I get "guix home: error: stat: No such file or directory: "/var/guix/profiles/per-user/flake/guix-home-322-link"". What is the cause, and how do I fix that? <sham1>What do you have in the /var/guix/profiles/per-user/flake directory? <sham1>Because if the `guix-home-322-link` exists, then the underlying profile probably doesn't <sham1>And they have been gone for over 2 hours at that point <sham1>sneek: later tell nutcase that you should check what the /var/guix/profiles/per-user/flake directory contains, and from there we could have an idea what's going on here <meaty>i am trying to reconf my system, but doing so requires a second download of guix for some reason <meaty>which is problematic because i have a slow connection and the download keeps failing during "receiving objects" with "guix time-machine: errer: Git error: SSL error: syscall failure:" <meaty>i have put the command in a bash "until" loop and it ran all night with no success, sometimes getting to 90+ percent before failing <meaty>this is annoying especially since i already did this (somehow) while building the system, i just wasn't using sudo <untrusem>getting, the used bootloader is grub-efi is an efi bootloader , it requires gpt partitioning <Icy-Thought>I am giving up on mixtapes... to complicated for my current guix knowledge <untrusem>Icy-Thought: create an issue with label kind/wishlist and help-needed with all your current definations and such and the errors <ampinga>Hello, community! Is it normal that, after running guix gc --delete-generations=1m, I have to download packages that I already have installed? For example, when I run guix home reconfigure ..., it downloads libreoffice-25.8.7.3, even though that exact version is already installed. I’ve checked that the versions match and that the package isn’t broken. <ieure>ampinga, Yes, the presence of grafts causes this. <untrusem>haha I had this exact frustrations when I first encountered it <untrusem>generally one would expect that they won't need to download everything again if they do "1m" or some other time frame <bjc>is that an automatic property of grafts or is that something we could optimize away? <bjc>i can't think of why it would be *necessary* to redownload anything, but i can see why we do it because coding it is tough <ieure>bjc, I don't believe it's fixable, aside from Guix more aggressively ungrafting. <untrusem>getting, "the used bootloader is grub-efi is an efi bootloader , it requires gpt partitioning" while sysem reconfiguring <bjc>are you on gpt and efi already? <bjc>wasn't someone else having trouble with grub-efi lately? ieure? <untrusem>I don't think I have changed my bootloader config since inceptions iioc <ieure>bjc, Wasn't me, but I was talking to someone else having the issue. <bjc>untrusem: do you have a ‘/sys/firmware/efi’ directory? <bjc>can you run ‘parted -l’ as root and see what the ‘Partition Table’ entry says? <bjc>i think the guix package is just ‘parted’ <untrusem>offtopic - bjc does your client supports "typing notifications" <untrusem>I am connected from a xmpp client and I could see that <bjc>i think, i see others typing in it. it's clatter.el <ampinga>So, I should give up for not having to redownload anything again after freeing space in the store? untrusem you're right... frustration... haha <ieure>ampinga, Your options are pretty much "don't `guix gc'" or contribute patches to ungraft. <untrusem>bjc: sharing output of parted -l in a pastebin <bjc>yeah, there's your problem <bjc>you are, in fact, using mbr <bjc>i think there's an efi-compat or something version of grub that supports this config <untrusem>wait, how did it happen, I have never changed anything in my config related to this <untrusem>ACTION is remembering he had some bios issue, and he had to reset his cmos and other things <bjc>i dunno. maybe guix changed something recently to use the efi-only grub instead of the compat version for ‘grub-efi-bootmanager’ <ampinga>ieure, what should I do then? I almost run out of free space and find " `guix gc" the only way to free space :') . <bjc>have you successfully reconfigured since then? <bjc>i can really only guess here, but the “right” way for efi is to have it on gpt partitions, but some bioses support a mixed mode with mbr disks <untrusem>ampinga: maybe time-machine? but it isn't a solution for your problem <ieure>ampinga, Get a larger SSD or keep substitutes on another machine on your local network. The nature of Guix is that it needs more storage than a traditional Linux (otherwise generations don't work), this is another manifestation of that. <bjc>even with just one generation, it requires a lot more for dependency management <ieure>Adding, I don't think any of the options I'm giving are *good*. But they're the places you have some leverage. Like I said, not ideal. <bjc>untrusem: do you host your own xmpp server and irc gateway? and if so, which gateway are you using? <bjc>ejabberd used to ship with one, but i don't think they do anymore <untrusem>lets take this to guix-offtopic, shall we? <sneek>stampede_, you have 1 message! <sneek>stampede_, avalenn says: I managed to make my transformation work, the order of with-commit and with-git-url is meaningful and counter-intuitive (could be improved in docs). My problem with json-c will be solved by https://codeberg.org/guix/guix/pulls/12277, no need for another PR. <ampinga>Thank you very much all for the answers. <ampinga>Speaking of "Grafts", is there more documentation than the blog post? I'm curious to understand how grafts work in depth. Maybe I can find a solution to my previous issue. I hope so. <lispmacs[work]>hi, I think I've asked this question before, but what is the best way, using guix tools, if you need to run specific commits of an Emacs branch, including local patches of your own <ieure>avalenn, It's making HEAD requests for NARs to see if that substitute server holds the files it needs. <ieure>How long it takes depends on how many substitutes you need to resolve and the health of the server. <ieure>And your connection speed, though the requests are very lightweight. <bjc>ampinga: don't quote me on this, but i think grafts work via rewriting the dynamic library section in the elf headers <lechner>avalenn: Due to different peering agreements around the world, access speeds to the substitute servers vary widely. For ci.guix.gnu.org, which I think is hosted in Berlin, some people report 20 MB/s while I struggle to get 100 KB/s. <avalenn>ieure: thanks, my problem is that the slow server seems th first to be interrogated <avalenn>and there is no parallelism between the various one, it tries them one after another <avalenn>and I do not know if I can change the order <bjc>the binaries we run on guix are in the ‘elf’ format (executable and linking format, iirc), and it contains a number of sections, one of which is used to resolve dynamic libraries at run time by ld.so <bjc>you can rewrite that section to use different libraries <bjc>i believe that's the facility used by graft, but i'm not sure enough on that to be quoted <ampinga>bjc: I understand now. It's okay. I was just wondering if there's more articles or documents explaining the deepth mechanics of grafts. It could, maybe, give credit to your statement. <bjc>ah, ok. i'm not sure about articles on it. i can't remember running across them <bjc>grafting is unique to guix, right? not inherited from nix? <Rutherther>nix already has the concept in nixpkgs for long time, they just do not use it, and no cli for it which is not that big of an issue, you do not typically use grafts on cli anyway <gkoebel-ext>avalenn: I think channels are queried in order they appear in channels.scm so following the exampels in the manual it would query user defined channels and then %default-channels which would be bordeaux <bjc>are we talking about channels or substitutes? <bjc>i'm confused by seeing bordeaux in reference to channels, but maybe i'm missing something <gkoebel-ext>bjc: they had mentioned that they think the problem is their connection to the server is slow and as its checked first takes a while and that they do not know how to change the order. bordeaux is the server my install queries for the default guix channel iirc which is also where my substitutes come from. <bjc>ah, ok. i've never really understood how it decides which to pick. it struck me as random <ieure>I believe substitute servers are queried in the same order the servers appear in the Guix configuration. Substitutes are independent of channels, Guix has no idea which substitute servers are likely to have what NARs. <gkoebel-ext>I don't know how it picks the server. But having two channels configured mine always seems to hit guix second <ieure>You can provide --substitute-urls="..." on the CLI to change the order or use different servers (assuming they use one of your trusted keys). <gkoebel-ext>ieure: does Guix not track where the package came from originally? <ieure>gkoebel-ext, No, there is no ability for it to. <untrusem>to see the current default order of your guix substitutes <bjc>it shouldn't matter, since all the packages should have the same hash <ieure>It's not an oversight, it's a deliberate design. <bjc>what advantage would it bring? <gkoebel-ext>SUPER_SLOW_SERVER_FOR_ONE_PACKAGE could conveivably take over the query time for SUPER_FAST_SERVER_WITH_EVERYTHING_ELSE <ieure>bjc, You can scale/add substitute servers independently of channels, deploy local ones, etc. <bjc>ieure: yeah, i do that for hurd, i just don't know how it picks when substitutes are available in multiple places <gkoebel-ext>I don't get why you wouldn't want to track package origin because its not exactly uncommon for people to have a repo for one thing thats niche, to have that get hit for every update is interesting <ieure>bjc, I believe (though I do not know with 100% certainty) that it's a waterfall type approach, it looks for all the substitutes it needs on the first server, then any that it didn't have on the next, and so on. <bjc>if the target is only available in one place, that place will be used <gkoebel-ext>Out of a hat, thinking of how Mozilla had/has their own repo for firefox. <bjc>and since, in theory, the substitute is just what you (or anyone else) would get by compiling, its origin shouldn't matter <gkoebel-ext>so then all the thousands of packages would query the Mozilla channel first? strange <ieure>If you put it first in your substitute server list, yes. <gkoebel-ext>bjc: I think that line only works if we assume that each channel is hosting the same software. I wouldn't want a system to waste cycles querying the wrong place when it would be trivial to record where I got the thing the first time <ieure>But the advantage here is that you can do things like run your own Cuirass and put that first, then your first stop for any substitutes is your own network. <bjc>ieure: ok. i could have sworn sometimes i see stuff come from ci, other times it seems to prefer bordeaux, but i guess that could be due to a lot of things <ieure>Or you can use *only* your server, to ensure that you have complete control over the supply chain. <ieure>Or you can set up local substitute sharing. <gkoebel-ext>ieure: all those things still work with origin tracking <ieure>All those get hugely more complicated if you can only download substitues from a channel-source-blessed server. <ieure>gkoebel-ext, I guess I'm not sure what you mean by "origin tracking." <bjc>i think the suggestion is to *prefer* the original download source <gkoebel-ext>I didn't say Only. Sane design would dictate a fallback if the original source channel did not have the substitute <ieure>gkoebel-ext, Channels don't have substitutes, at all. <ieure>Channels know *nothing* about substitutes. <gkoebel-ext>ieure: but when a user runs an update. From their perspective there is no differnce <gkoebel-ext>and the server attached to that channel does know what substitutes it has <ieure>bjc, That is not what that does. <bjc>and oh man i am so annoyed that the 1.5.0 url is *still* preferred by search engines <ieure>gkoebel-ext, Whatever perception is, the system doesn't work like that. <gkoebel-ext>ieure: the semantics don't really matter at this stage. When a user updates their system the system does 100% query each channel and it does 100% by default check the servers attached to those channels for substitutes <bjc>i mean, it's saying “this goes in channels.scm”, and it puts the channel and substitute together in one form. it's a bit confusing <bjc>i'm not sure how i would rewrite it to be less confusing, though <ieure>gkoebel-ext, What I am telling you again, is that the servers are not "attached" to those channels in any way other than convention / what you have in your config. <gkoebel-ext>ieure: and I am telling you that the distinction does not matter <bjc>other than speed, what's the advantage of preferring one server over another? <bjc>actually, if we had a mechanism to weight substitute servers arbitrarily, would that satisfy your requirements? <gkoebel-ext>it is a fact full stop that by default Guix will fetch substitutes from the default channel should the responding server have them. That alone is sufficient for it to be possible to track where a package came from and query that server first in future. <untrusem>ieure, btw I remember you not being satisfied with the new transformations procedure we got for home and systems, am I right? <ieure>gkoebel-ext, Well, it does matter, since you can't do what you want in its absence. <untrusem>I ask this as I believe you to be a heavy transformation user <gkoebel-ext>there is literally a built-in command to query for available substitutes <bjc>what's being said is that it's incorrect to say that guix fetches substitutes from a channel <bjc>those things aren't related <gkoebel-ext>bjc: I'm intentionally not arguing the exact technical semantics. I'm arguing the functionality <bjc>guix has channels, which is where you get code for guix itself, and it has substitutes, where you can download pre-built binaries <bjc>ok, but the technicalities matter in this case because otherwise its confusing <gkoebel-ext>Where does a user on a fresh install of Guix have to specify where they get substitutes from? <ieure>gkoebel-ext, You get asked during installation if you want to use substitutes. <bjc>you have many places you can specify the substitute servers, and guix does ship with defaults that can be overridden <bjc>i think i've lost the plot <gkoebel-ext>Like I have a nonguix substitute explicitly configured. I don't see anything for the default channel unless it appears in some other config besides config.scm <ieure>gkoebel-ext, But you are also dismissing when people here try to correct your understanding by saying it doesn't matter. So I don't know what outcome you want here. <ieure>gkoebel-ext, The default substitute servers are in the default configuration. <ieure>You can add your own, as you have, or remove them, or use different ones. <gkoebel-ext>ieure: I was saying "channels don't contain substitutes" doesn't matter since to the user they are effectively the same thing <ieure>gkoebel-ext, Perception doesn't make them actually the same thing, is what I keep saying. <gkoebel-ext>I will concede that I forgot you do need to configure that for any channel besides the default <ieure>Perhaps you could outline how you think the system should work in a guix-devel post or codeberg issue? <gkoebel-ext>that however does not change any of my other points at how trivial it would be to track this information <ieure>I agree that there's room for improvement. <bjc>i can't find the docs for it, but if you can, try looking for ‘guix-service-type’ which should have a list of substitute servers <ieure>I honestly believe it is not trivial without trading off some other desired functionality. <bjc>you can override that in your configuration to do whatever you want <untrusem>I can share snippet from my config too :p <gkoebel-ext>bjc: I don't have any need for assistance here. I'm just surprised Guix doesn't already do this <gkoebel-ext>ieure: I don't see how. This is entirely machine side, you simply record where the package came from the last time it was installed successfully whether that be from source or substitute <untrusem>well that it will be more beneficial to raise this in guix-devel it seems <bjc>i don't particularly see a value in tracking it, since the hash gives me what i need for provenance guarantees. for issues of speed/load, i think there are better ways to solve that problem than tagging the download with a source <bjc>but yeah, the mailing list with a proposal would be good <gkoebel-ext>bjc: the issue was not just speed. I was thinking of how if you have several channels that are large thats a lot of wasted queries <ieure>gkoebel-ext, As I mentioned, the setup allows you to set up local substitute servers. If it tracks where it last found, say, coreutils, it won't ever opt to fetch it from my local machine when it has a new substitue. This is the kind of tradeoff I'm talking about. <gkoebel-ext>ieure: you could still get it from your local server. Just put the local server first <ieure>gkoebel-ext, That doesn't help when my substitute server only builds/obtains the substitute after it's been fetched from, say, bordeaux. It won't recheck, since that defeats your proposed origin tracking. <gkoebel-ext>perhaps an extension to package version pinning would also be needed. idk this is about the end of the time I can dedicate to this line fo thought. <gkoebel-ext>ieure: I think you can think of several ways to make that work properly. <gkoebel-ext>if I have time I'll put something to the devel lists/issue tracker. I doubt I will though <ieure>The thing that other distros do materially differently here is provide a list of *every* package they have, ex. Debian's Packages.gz file. Something like that could help here, you'd refresh all the substitutes at once, then only download them from a place where they're already known to exist. <gkoebel-ext>ieure: assuming I have the free time I'll think more on the technical side. For this discussion I've been entirely detached from the source <gkoebel-ext>I think I could make this work without changing the requirements for channels nor substitute servers <untrusem>smartin: can you share the contents of your channel file and also tell us where it is located? <untrusem>this is the whole content in your file? if yes? you need to add some bits thn <attila_lendvai>i want to add a /etc/qemu/bridge.conf but /etc/qemu is a symlink. an extra-special-file fails because of a read-only fs. what am i missing? <attila_lendvai>the solution is to use etc-service-type. the cookbook is bitrotten, i'll open a pr <ieure>untrusem, Saw you force-pushed my MPD PR's branch? <untrusem>ieure, ohh yess, I was going to merge it <ieure>Okay. Just surprised you even could. <untrusem>ieure, was it not available for your time? <ieure>untrusem, I'm not sure what you're asking. <untrusem>I mean the option in forgejo ui when you was a committer? <ieure>untrusem, There's no force push control in the UI, that wouldn't make sense. But since the PR came from my fork, you'd need write access to it to push there, is my expectation. <untrusem>ohh I see this option in many pr so this might be something new <untrusem>no, `rebase with master` I am forgetting the exact words <smartin>untrusem: I've just fixed my `guix pull` issue by creating a temporary channel file from `guix describe -f channels > /tmp/fix-ch.scm` and inject it like this `guix pull -C /tmp/fix-ch.scm` <untrusem>so somethings is messy in you channels.scm then <untrusem>you could just overwrite it with your tempfile <smartin>I've tried to overwrite it but I'm getting `bash: /home/john/.config/guix/channels.scm: Read-only file system` <smartin>it's linked from `/gnu/store/j6nkgzhcrq2wm8xr0sz2cw4m4ab2b47h-channels.scm` <ieure>smartin, Sounds like you use Guix Home and have your channels configured there. <avalenn>untrusem: I modified the order to put ci.guix.gnu.org first, then other servers for custom substitutes and last bordeaux <smartin>ieure: you right I forgot I've made some experiments with it now it's all clear thx <avalenn>how can I serve substitues completely statically from files without a guix daemon or any dynamic server <ieure>avalenn, Interesting question! Maybe you can give a file:// URI? I'm not sure this will work. <ieure>avalenn, Well, the question of "where do you get the files in the first place" is I think separate from "how do you serve those files once you have them." <avalenn>ieure: without having the files at first, thinking about serving them is not very useful :-)