IRC channel logs
2025-09-25.log
back to list of logs
<Serentty>Has anyone here got PowerShell working on Guix System? I know .NET is not packaged yet because of bootstrapping, but there is a version available with a bundled framework that I might be able to get working. The issue is I would probably need to run that in an FHS container, which limits its utility as a shell. <apteryx>ACTION wishes codeberg was less click-driven <apteryx>Serentty: I think Mono was re-added "recently", so you may give this a shot (I'd have little hope though, since Mono is always trailing behind latest C#) <sneek>apteryx, you have 1 message! <sneek>apteryx, csantosb says: regarding this thing, colognechip.com/downloads/gatemate-timings-latest.tar.gz, would it be enough to include a license file along with it ? <Serentty>apteryx: The Mono that was added is Legacy Mono though, right? Not the Mono that is one of two runtimes supported by modern .NET? If so I don’t have that much hope that it will run. <apteryx>Serentty: mono in guix is at version 6.12.0.206 <Serentty>From what I understand Legacy Mono is essentially an open source implementation of the old, proprietary .NET Framework, which is different from .NET Core/.NET 5+ (now just called .NET). <apteryx>looks like what we have is the current stable version, not a legacy version <Serentty>I am not talking about the version. What I mean by “legacy Mono” is the one that tries to be compatible with .NET Framework (as opposed to .NET Core). There are essentially two different things called Mono now. It’s confusing. <Serentty>It looks like the current repo for old-style Mono, maintained by WineHQ, has renamed it to “Framework Mono,” which is thankfully slightly less confusing. <apteryx>ACTION would be hard pressed to be excited about C# stuff <Serentty>Anyway, I am pretty sure that new-style Mono, which is essentially a backend for .NET Core, is not packaged in Guix, although I could be wrong. <apteryx>The whole Mono thing looks like having been abandoned by Microsoft, so at this point it must lag behind their .NET implementation (to be fair it always lagged behind it). <Serentty>What happened was they essentially folded Mono into the Microsoft .NET Runtime as a second backend. They still maintain that backend, and from what I gather it is still pretty healthy and active. But the rest of Mono, which includes the Mono implementation of the standard library, and the Mono C# compiler, are all essentially abandoned, I think. <Serentty>Well, not ENTIRELY abandoned, because it is now maintained by the Wine Project. <Serentty>But the Wine Project is just interested in using it to run stuff for the old, proprietary .NET Framework. <Serentty>So if you are talking about modern .NET, there are two implementations of the bottom parts of the stack (one of which is Mono), but the higher-up parts of the stack, including the standard library, only have one implementation now. <Serentty>Anyway, I was mostly just interested in seeing if I could get PowerShell running because I like the structured, piped data, and it is free software. But meh, maybe I can spend some time working on Scheme instead. <Serentty>I’ve never been the biggest Bash fan, and Scheme certainly also seems like it could be good for automation. <loquatdev>Hello, all. I was here a couple days ago asking a similar question. I did a little bit of digging, and I was able to clarify the issue. I am building a package on my primary machine and attempting to substitute the same package on my secondary machine. The secondary machine detects the substitute server on my primary machine and begins to <loquatdev>substitute the package from it. However, once it downloads, I get a hash mismatch error. I initially assumed this was an issue with the disk / network, but I tested it on multiple machines that I own and the same expected and actual hashes were shown in the error. Any ideas? <loquatdev>To test this, I built the package without substitutes on my secondary machine. It took a few hours, but it still built the package with the exact same hash. <mange>Can you put the error message in a paste? I'm not familiar with a hash mismatch error during substitution. I've only really seen them when fetching sources. <loquatdev>This is the command / output on my secondary machine: <loquatdev>All machines are pinned to the same channels / commits, in case that's important. <mange>Looking at guix/scripts/substitute.scm, that means the narinfo file said a different hash for the store item (looking at line 616). <mange>I'm not sure how that could happen. Is this a nondeterministic build where you somehow re-ran the build between when a narinfo got cached, or something? <mange>To be clear, this isn't the hash in the store name (i.e. /gnu/store/XXXXXXXXXXXX-...), but rather the hash of the contents of that store path. Thus, building the package on another machine might have the same hash in the store name, but nonetheless have a different hash for the contents. <loquatdev>Right. I have no idea how it could happen either. I don't imagine that would be the case, since I installed upgraded to a new SSD and reinstalled Guix since the last time I tried this on my main machine. Both machines were made using the same build / commit of the installation ISO, actually. <loquatdev>Is there some way I could recalculate or update the hash? <mange>How are you running your substitute server? Is it just "guix publish" on your main machine? <mange>Hmm. The manual says that if you don't provide a -c/--cache argument then "guix publish" calculates narinfo on the fly, so it shouldn't be able to be stale. <loquatdev>It's very simple. I have no idea what I might have done that could have caused this. <mange>Yeah, I'm confused about that, then. I assume you've tried restarting "guix publish"? I don't expect it to help, but it seems silly not to try it. <loquatdev>Yep, tried that twice already. No difference, unfortunately. <loquatdev>Perhaps it might have something to do with grafting? There package gets grafted after building, but it goes into a new store location so I have no idea how that would affect anything. <loquatdev>Just tried it a third time. Actual and expected hashes are still the exact same. <mange>Grafting shouldn't affect this, because I believe substitution happens on the level of store items, whereas grafting is on the level of packages. <mange>Can you try rebuilding the package on your main machine? You can run "guix gc -D /gnu/store/..." with the output path to remove it if there's nothing else keeping it alive. <mange>Again, I don't expect that to actually help, but it feels foolish not to try (assuming it's not too expensive to rebuild on your main machine). <loquatdev>I've done that a couple times as well. Same hashes still. I can give it another shot though - it doesn't hurt to try. <mange>If you've already done it then there's no point, though. It clearly didn't work. <loquatdev>Is there perhaps a way I can manually calculate these hashes on each machine to test it? <mange>Hmm. Random thought: are the filesystems the stores are running on mounted with any options that would affect things? Like, noexec or anything? <mange>I guess maybe "guix hash" on the store output might do it? I'm not sure exactly how the narinfo hash is calculated. Let me see if I can find the code for it. <loquatdev>They're both SSDs. The one I'm building on is an NVME M.2 SSD, and the other two machines I've tested on both use SATA. But I don't think that would change hashes or anything <mange>No, it shouldn't. Also, looking at the hash code I think it's hashing the bytes that it receives (after decompression), rather than the files on disk, so the filesystems actually shouldn't affect it. <mange>Or, another way of saying that is that it's hashing the content of the nar. Which makes it all the more confusing that it would have an incorrect hash. <loquatdev>That's... odd. So it wouldn't be something to do with the package definition then, would it. <loquatdev>The only other thing I could think of that might change hashes would be the fact that I perform a substitution on the source code after the checkout phase... but if it's done on the fly after the fact, that shouldn't change anything. <loquatdev>What's even stranger is that it's consistently the same wrong hashes on both ends... <loquatdev>I'm going to double check the hashes on a few more machines, because if it's the exact same thing on every machine in my network, then there's definitely something wrong with the build machine. <loquatdev>Wait, after I rebuilt the package again, the "actual hash" in the error message is different. <mange>This whole process happens after packages. Conceptually Guix has a "build" function (packagedefinition -> output). The location of the output (/gnu/store/...) is decided by taking a hash of the package definition (including its inputs). Substitution is the process of taking a /gnu/store/... and saying "can we download it instead of building it?" So the package definition should be irrelevant as long as the /gnu/stor <loquatdev>Right, I figured. I suppose I'm grasping at straws here, then. <mange>The problem here is that the hash is being calculated differently at both ends: "guix publish" and "guix substitute" disagree on what the hash of the nar is. <mange>This means either (a) the contents of the nar differ on each side somehow, or (b) the hash is being done incorrectly on one, or both, sides. <loquatdev>I'll try to manually check the nar on both sides and see what I get. <mange>You could try "guix substitute --query /gnu/store/llwsyignqi0q969yb2mss934fdi9jddm-prismlauncher-9.4" to see what it says? I've never used that command. <mange>Or you could see what "guix substitute --substitute /gnu/store/llwsyignqi0q969yb2mss934fdi9jddm-prismlauncher-9.4 /tmp/prismlauncher.nar" gives you in /tmp/prismlauncher.nar. I don't know what you could do with that nar file to check it, though. <loquatdev>I'm getting an "unrecognized options" error running that command on both machines. <mange>I guess I should have taken "internal tool" more seriously in the guix substitute help text. :P <loquatdev>Whoops, pasted the wrong bit there. But you see what I mean. <mange>I think those you should probably just hash with a sha256sum. <mange>But you might also need to decompress them before hashing. <mange>Also from your earlier output you're pulling the zstd one, not the lzip one. <mange>Although you could compare the zstd and lzip ones after decompression, as well. <loquatdev>Are the archives in tar format? I extracted it using zstd but I don't know how to handle the file from there because it's still got gibberish and what looks like multiple files in there. Tar says it's not a tar archive. Bear with me, I'm unfamiliar with this. <mange>They're in nar format (which is a Nix ARchive, I believe), but that's all I know about their structure. <mange>Is the gibberish hashing the same after decompression, on both sides and with both forms of compression? <loquatdev>Oh. I probably should have figured that out from the URL '=D <loquatdev>mange, I finally figured it out. It matches the hash from "actual hash" in the error when manually calculating it from the server. I'm going to calculate it from the store itself now. <mange>I think you can also use "guix archive" to construct a nar for your store path. (The manual for guix archive also says that nar stands for "normalized archive", so I was wrong about that one. <loquatdev>"guix archive" is what I'm using, yeah. It's producing a totally different hash, though. Which is odd. It appears to be including the signature at the end, though, which is not in the nar I got from the publish server. <mange>Looks like --extract avoids that? <loquatdev>--extract just takes the files from the nar and puts it into a directory, in my understand. I mean that the nar file from the server contains does not contain signature information on the end of it, while the one I manually generated does. <mange>Oh, yeah, whoops. You're right. I misread the manual. <loquatdev>Okay, this is really weird. I manually download the narinfo file from the server and it has the same hash as the "actual hash". <mange>Okay! That's interesting! That probably means that the issue is on the client side, then. <loquatdev>I have no idea what the "expected hash" is supposed to be, then. Is it not being pulled from the narinfo, then? <mange>Do you want to try deleting everything in /var/guix/substitute/cache? Maybe an old narinfo was cached with a wrong hash (somehow). <mange>There might be a proper way to do it, but I'm hoping those files might be enough. <mange>Yeah, on the machine that's pulling the substitute. <loquatdev>Alright, I removed the cache folder and I'm attempting to substitute again. <mange>Maybe also ~/.cache/guix/substitute <mange>I don't know which caches are used for what, I'm just looking for anything that says "substitute" in its name. :P <loquatdev>That dir in the home folder is empty, save for "last-expiry-cleanup" <mange>I imagine it's used for "guix weather" or something, rather than the actual substitution. <loquatdev>AHA! It... worked??? It substituted just fine... I am at a loss for words. I suppose it was a rogue cache issue, then. <mange>Sorry it took so long to find! I hadn't considered a cache on the secondary machine, but in hindsight we should have checked that much earlier. <loquatdev>It's strange that it happened on multiple machines. Maybe there was a minor issue in an older guix version, and pulling caused some issue with the cache. <mange>Mmm, I'm not sure. But I'm going to go have lunch now. :) <loquatdev>My other thought is that I've had substitutes from the regular guix channel pulled from my build machine before I properly added the build machine's signing key. Maybe that messed something up. <loquatdev>Either way, thank you very much, mange. I really appreciate your time and help. God bless you! Enjoy your lunch. <loquatdev>The error disappeared on my third device as well, so I suppose this issue is completely solved. <Serentty>I tried installing the guile-emacs package just now, and when it tried to build guile-for-guile-emacs, the compiler errors out with an implicit function definition error. This should happen for everyone, right, because of build sandboxing? Has anyone else tried to install this package recently? <mange>It doesn't build for me. You might be able to check CI to see when it last built? <Serentty>When I try to check the build status on the package website, I get a 500 error. <Serentty>The “see build status” link on this page. <janneke>sneek: later tell Serentty: guile-for-guile-emacs failed for me too, i've pushed a fix to master, thanks for the report! <csantosb>Great ! We have now a cuirass bot building pr, see pulls/2909. <civodul>hugohugo: there was an upgrade yesterday related to issues.guix.gnu.org <futurile>I have some many virtual screens and windows open that all I do is wander between screens clicking trying to find the tab I want <futurile>and then Firefox messes me up by moving an X window to a different window when it gets a high priority alert heh <futurile><.. goes to look for the guix issues tab> <futurile>civodul or anyone: what's the summary of what we have at Aquilenet? (or how do I find this out) <futurile>I'm working on content for the fund raising and want to summarise what money is spent on <cbaines>I can't upgrade packages because gtk+ fails to build ( /gnu/store/rmcpw6xkaxcj4nyj09gc0xj8dpsmszj8-gtk+-3.24.49 ), but I have no idea where this output/derivation comes from or why it's being built? <ColdSideOfPillow>What kind of message should I expect with --rounds for a deterministic build? <futurile>ColdSideOfPillow: it will blow up if it's non-deterministic with --check <futurile>ColdSideOfPillow: if it works I think it just shows 'green' for the two derivations it's build - and presumably the command exits $? with 0 <cbaines>well upgrading my packages hasn't fixed audio output in Icecat, but it has broken my keyboard layout in Gnome <admin`>Hello, 'guix archive --export util-linux > hold' is giving me 'guix archive: error: corrupt input while restoring archive from #<closed: file 7fc0622a1a10>'. Any clues? <jbnote>Would it be considered bad behaviour to open WIP pull requests a bit before they're actually ready, just to be able to benefit from the Cuirass builds? <jakef>if cuirass bot is like the ones on guix-science, they don't build WIP PRs <jakef>python-team branch was merged wohoo <janneke>civodul: how do i run something like `sudo guix time-macine .. -- system reconfigure' without getting things in ~/.cache/guix/{checkouts?} owned by root; what am i missing? <janneke>err, sudo -E, of course, my root has no guix <Rutherther>You run it without -E. It doesnt matter that root doesnt have guix. Sudo uses the one you have in PATH. <Rutherther>For the default configuration of sudo on guix system that is. Not saying that on any system that would happen. <futurile>ColdSideOfPillow: no clue, maybe cut-n-paste the last part of the build output into https://paste.debian.net - and do `echo $?` to check if the build thinks it was successful <ColdSideOfPillow>I was trying to see if a "build-reproducibly" phase in mpv was needed anymore, the comment about the phase linked an issue which had been closed and related PR seemed to be merged <civodul>Rutherther: great to have you on the release team! <Rutherther>civodul: thanks! Hopefully will be useful and not mess something up :D <gabber>Rutherther: if there is any way i can help <gabber>to include the team-audio branch with the next release: please let me know (: <gabber>also: thanks for your initiative <nbgeiklearner01>I want to boot a guix system inside a Incus container, i need to specify this environment variable in lxc.init.cmd 'nd need to edit each time I reboot the instance after guix system reconfigure <nbgeiklearner01>so I am wondering if there is a robust way to determine it at boot time <gabber>nbgeiklearner01: i am sure there is. doesn't `guix system reconfigure` spit the relevant data out in the end? <nbgeiklearner01>it does, but for incus contanier, it needs to know where to retrieve this infomation at boot time otherwise aI need to manually specify it to the container's lxc.init.cmd, which is troublesome and prone to errors <futurile>I think they want 'cloud init', there's a couple of implementations floating around but nothing in guix yet. Roman worked on one recently, the PR's around somewhere <cbaines>civodul, with the pulls.ci.guix.gnu.org thing setup, are you open to disabling the Forgejo integration on data.qa.guix.gnu.org? I think it's caused /var/lib/guix-data-service/.cache/guix/checkouts to grow to 54GiB, which is exasserbating the space issues on hydra-guix-130. <jbnote>civodul: I have AMD HIP support working in addition to OpenCL for RoCM. Would you be open to having it in Guix, or is this considered non-free software? <untrusem>anyone having problem with virt-mangaer's connection to qemu <untrusem>how will I use it in my channels, I get I can redefine a package to use the patch but what about the ` <untrusem>gnu/packages/patches/libvirt-add-install-prefix.patch` <ieure>untrusem, Copy it into patches/ in the root of your channel repo. <ieure>And the package definition will find it. <untrusem>I can use my custom channel right, or are you talking about my guix fork <ieure>I didn't know you had a Guix fork, you asked about your channel, that's how you use it in a channel. <ieure>obvs if you've just forked guix, cherry-pick the commits or do whatever you do to pull code in. <untrusem>I think I need to do the same to python-libvirt <untrusem>wait, that patch change two package at the same time will I need to do something specific for each package or can I use the same patch for both of them <ieure>What do you man, it changes two packages at the same time? <ieure>Are you talking about the PR, which updates both libvirt and python-libvirt? Or the patch file the PR updates? <ieure>If you don't need the python package, just omit it from your channel. The definitions you pasted will not work how you expect, python-libvirt will refer to the libvirt package in Guix, not your libvirt/awth13. <ieure>You'd need to modify-inputs to replace the upstream libvirt with your fork in your python-libvirt. <untrusem>here is my dir structure, the virtualization file have libvirt <ieure>untrusem, You have .scm files in the root of your channel repo? <ieure>untrusem, The patches directory must be at the root of your channel, not alongside the package .scm files. <ieure>It's different for the Guix repo vs. others, I'm not sure why, it stinks IMO. <untrusem>if you take a look at the pr, the patches directory is inside `gnu/packages` so I just did the equivalent for my channel <ieure>untrusem, As I said, the location is different for the Guix channel vs. any others. What you have will not work. <untrusem>so I need to have patches alongside the `modules` directory in my channel <ieure>untrusem, Again, the patches directory needs to be at the top level of your channel repo. <futurile>How do I query a service of "activation-service-type", It doesn't show up when I do "herd status" and "herd doc <service>" isn't finding it <futurile>I can see it when I do: ./pre-inst-env guix system extension-graph <config file> | guix shell xdot -- xdot - <futurile>but I don't kow if it's being activated properly <ColdSideOfPillow>Why does (memv "quiet" %default-kernel-arguments) return #f (at least for me)? <ieure>futurile, activation-service-type isn't a shepherd service. <futurile>God I hate services, they are so overloaded and make no sense <futurile>OK, I guess I'll ask the person who wrote it how it works :-)) <ieure>Naming could be improved, but I like the mechanism a lot. <ieure>futurile, activation-service-type lets your services hook into the activation of a system generation, ex. to drop config files in /etc for things that need them. <futurile>ieure: yeah, I'd say the manual _kinda_ explains that. But, then how do I know if it actually ran? Is there an interface to it? (oddly they've defined a doc string, so it implies I can somehow query it to get the doc string back) <ieure>futurile, They run if declared. If they fail/error in some way, the activation of the system generation fails. <ieure>futurile, What's problem are you having? <futurile>ieure: OK. So no real point it having a 'name or a "Description" <futurile>ieure: I'm not good with services, but there were no docs for this PR, so I thought I could quickly fix the docs and push it. But I want to make sure it's actually run. So my problem is "how do I know if this service has run in my test vm" :-) <ieure>futurile, There's no place to put a name or description for an activation procedure. <ieure>futurile, service-types should have names and descriptions. The service-type is not the activation, an activation is something a service-type may add. <ieure>futurile, I'm not sure this service will work how its author expects. But since you can see that the activation is writing to a file in /sys, checking its state before/after the generation is activated will tell you if it's run. <ieure>This service will likely have issues with sleep/wake, which likes to reset a lot of these values. Since it only runs during activation, and you'll likely have sleep/wake cycles in between those. <ieure>I activation hooks run when the system generation is changed (ex `guix system reconfigure', `guix system switch-generation', `guix system roll-back'). And I believe they also run when the machine is booted. <futurile>oh <sigh> should _not_ have picked this up <futurile>I'm testing on a VM, so actually all those values are disabled anyway, I didn't want to mess with my machien. <ieure>While the actual WoL functionality is unlikely to work in a VM, the /sys manipulation ought to. <apteryx>podiki has issues with their IRC; but they meant to write:the mesa branch has been rebased on master, and people are welcome to test it to see if anything is broken <kestrelwx>Do you have the package definitions as in the paste above? <untrusem>I just used the package defination of the pull req <Hamled>I've configured my channels to use the codeberg git URL rather than the default, and that has worked well since the project moved to codeberg. But now when I do `guix pull` it isn't updating to the latest commit from master branch: https://paste.debian.net/1398113/ <ieure>untrusem, In what way does the patch fail? <Hamled>Do I just need to delete the cache, or is something else going on <ieure>untrusem, Did you copy the changes to the patch from that PR also? <ieure>Not sure then. Does the PR build? <untrusem>I will need to pull their fork, will take too much time and space <ieure>untrusem, You can add the source repo of the PR as a remote to your own clone. <ieure>And it won't consume 2x the space. <ieure>(Sorry, am in a meeting and can't help too much) <PotentialUser-85>Hey I'm trying to build my rust app, but it needs `cargo` version `>=1.85`, but I can't find a `cargo` package to "force" a higher version (I'm using `guix shell -D rust` for a development shell). Any hints on what keywords to look up would help me a lot! <kestrelwx>You would use `guix shell -D rust` if you were planning to build rust itself. <ColdSideOfPillow>-D is a flag that is used to add necessary/convenient packages for development <ColdSideOfPillow>so, for example, `guix shell -D guix man-db` will only add the extra packages for developing on guix, not packages for developing on man-db <kestrelwx>You want 'guix shell rust:cargo' in your case. <PotentialUser-85>I know that there are higher rust version availible (I've seen & used 1.88), but you have to opt in to them - the default is 1.85. with cargo, it stays at 1.84 no matter the rust version <kestrelwx>I'm getting cargo version matching the rust one. <PotentialUser-85>I wanted to check if there was a higher cargo version that is just not the default like in the rust case, but I couldn't even find where cargo was defined so I'm lost haha <PotentialUser-85>oh I see, if I do `guix shell -D rust` I get 1.84, but `guix shell -D rust:cargo` "works" <identity>PotentialUser-85: ‘--development rust’ is used to build the rust package, so it would use the previous rust version. again, you want ‘guix shell rust’ instead <Deltafire>what does the success rate on CI need to be before a branch can be merged? <futurile>after it's built everything the branch should not have regressed the archive... <Deltafire>success rate for master is 53%? that seems low, but is that for riscv64 only? it's a bit unclear <Deltafire>just clicked on a random red blob on mesa-updates, and it's failing to build because of the libxml2 update <Rutherther>are you going to look at it? If not, can you send the url? <Deltafire>i was just wondering how i'd go about building just the one package, without having to spend hours compiling <Deltafire>building dependencies? not sure.. i'll switch branches and see what happens <Rutherther>ci building this package implies it had to build all the dependencies already, so they can be substituted <PotentialUser-86>how do I make a local package definition available to guix commands, such as `guix package -i`? <identity>PotentialUser-86: see (info "(guix) Channels") <Rutherther>PotentialUser-86: you need to put it to a module and put folder with your modules to a load path, ie. with -L option <PotentialUser-86>Rutherther: I have it in a module, and I've made sure to add my configuration files to the load path, yet I can't seem to install it through guix commands (well, at least without using options like `--install-from-expression` or `--install-from-file` ) <Rutherther>'made sure to add my configuration files to the load path' <Rutherther>is the package exported then? Are you sure there are no issues with the module (did you try running guix repl with that module as argument) <PotentialUser-86>Rutherther: to clarify, there is no issue with the package: it is syntactically and (probably) semantically correct. I just want to e.g. see it appear in `guix search` or be able to install using package specifications, but I don't know how to. <Rutherther>for guix search you would need to add it to a channel. For being able to install it from what you said, you're already at the right track, but there is something wrong somewhere, that is why I am asking those questions. <PotentialUser-86>Rutherther: I tried creating a channel with just the `name` and `url` fields, but I got an error: `guix pull: error: Git error: could not find appropriate mechanism for credentials` <Rutherther>although no, even for guix search it suffices to put the module root to GUILE_LOAD_PATH and GUIX_PACKAGE_PATH env vars <Rutherther>wdym you're using sha256? where? like for commit hashes? this error comes much earlier than that. What url are you using? <jbnote>Hi, would anyone be able to provide help for cmake? Some find_packages() calls are failing during build, when the package and its cmake files are present. I don't really understand why after looking at the cmake files. <civodul>wtf: no code for module (gnu packages fcitx) <yelninei>jbnote: It might be because the cmake file needs another dependency but hard to tell without the full log <Rutherther>oof. It seems package from it hasn't actually been used, it's just that the module was still referenced somewhere <jbnote>yelninei: thanks! It's for package fmt (C++ library), cmake tells me "cmake file found but fmt_FOUND set to FALSE" and the tracing shows that indeed, this is set to false in the loop iterating over the depencies. <jbnote>yelninei: however, I can't seem to find anywhere where the cmake variable fmt_FIND_COMPONENT would be set. I just can't find it. <jbnote>yelninei: would you know where these variables are set? <Deltafire>successfully built /gnu/store/yvizb37jwj00dvrqdc93qdxgcin7rcqa-sane-airscan-0.99.36.drv - yay, success <cluelessguixer>Just did a guix pull and got "no code for module (gnu packages fcitx)". <yelninei>jbnote: My guess is that fmt discovered that something is missing for it and disabled itself. I am not sure what that is, debugging cmake scripts can be really annoying <Deltafire>updated to latest version and added a new dependency <jbnote>yelninei: yeah, I came to the same conclusion, but I'm completely stuck as I don't know, at all, how to trace the missing dependency. <cluelessguixer>abbe: Had a feeling that would be known, but didn't see anything reported at a glance. "opened last month", huh. <abbe>well, committer deleted without making sure files are not referenced :/ <abbe>if you've a codeberg user, you can subscribe to get notified <abbe>looks like fixed, let's check <aidan>Hi, I was wondering is there a Go package with cgo enabled? I get the following error sadly "Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work." <cluelessguixer>I was only lazily hoping that updating today would maybe fix libvirtd if nothing else. <jbnote>yelninei: ultimately the find_package call had two arguments inverted in the cmake file (on a path which was probably never tested). Thanks for your help! <yelninei>jbnote: I just found the issue as well. cmake can be a nightmare if things go wrong <untrusem>> I was only lazily hoping that updating today would maybe fix libvirtd if nothing else. <cluelessguixer>untrusem: Thanks for the update! I've had my HAOS image moved to my router for now, which isn't as up to date. <vagrantc>i am guessing some big python related branch was recently merged? <vagrantc>seems python-iterable-io and python-noiseprotocol no longer build... <aidan>could be related to the libxml2 issues that I know have also effected python <aidan>and started around last week <vagrantc>been updating almost daily and today is the first i noticed the problem <vagrantc>after seen 780 commits, mostly python related... <Rutherther>aidan: seems unlikely to me as libxml2 hasn't been updated in many places, mostly grafted. So it doesn't break builds, it breaks runtime <vagrantc>see conversations regarding tags or merge commits :) <Deltafire>do i need to disable the pre-push hook when pushing a PR to codeberg? It's failing because my commit isn't authenticated <Rutherther>no, not really. That means you have old pre-push hook. Remove it and remake it <dale>When I run 'guix archive --export util-linux > hold', I get 'guix <dale> archive: error: corrupt input while restoring archive from #<closed: <dale> file 7fc0622a1a10>'. Any clues? <Deltafire>filesystem corruption? try guix gc --verify=contents <Deltafire>or --verify=contents,repair to fix any issues it finds <dale>Tum te tum... would be good if there was a progress bar... <ieure>dale, `guix archive --export util-linux | guix shell pv -- pv > hold' <ieure>Or just `| pv > hold' if you have it in your profile. <ieure>pv(1) is a very, very good tool. <dale>pv doesn't tell me anything <dale>Oh, I see, you mixed my messages up. I meant that guix gc --verify would be good if it had a progress bar. <ieure>Yeah, can't help with that. But is excellent any time you're shoving bytes through a pipe. <dale>The guix gc --verify has finished. It came back clean. <kordel>dale: what is your 'guix describe' ? <dale>Generation 89 Sep 25 2025 12:14:44 (current) <dale> commit: e5d2f0bd4bd330328e75ea39794a1b1f8b0929fb <dale>Guix is a recent pull. I think my problem may be with keys, but I have generated new ones, and authorized the public key. <ColdSideOfPillow>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (channel)) (value #f)) <dale>What is in your $HOME/.config/guix/channels file? <hugohugo>vagrantc: thanks, I'll have a look at python-noiseprotocol now <dale>Perhaps guixnest needs an introduction? <ColdSideOfPillow>dale: As far as I've understood, introductions are optional (but recommended). <ColdSideOfPillow>Also, the error seems to show that the problem is that `channel' is somehow unbound. <Rutherther>ColdSideOfPillow: exactly, your channel includes a file env/channels.scm. This file uses channels, but it doesn't use-modules. Details matter! Why didn't you say the error is when building guixnest.drv. <Rutherther>moreover no module in your channel is at a proper place to be properly loaded <simendsjo>I cannot authorize a new key in my channel. `commit xyz not signed by an authorized key: THE KEY`, but I have an earlier commit adding the key to .guix-authorizations and have the key in the keyring. What's happening here? <ColdSideOfPillow>Rutherther: I did say 'I added the "guixnest" channel to cause this error'. <Rutherther>yes, but you didn't say where the error occurs. That it is during build of the channel - that means the error is inside the channel itself. Not inside the channels.scm file you're building <Rutherther>though in this case it also actually happens to be the channels.scm you're using to pull that is the culprit, but that's just a coincidence <simendsjo>Oh, I found the channel authorization issue. I added a new list at the end of the authorizations list instead of a new pair. Obviously no strict validation of the file, so it just ignored this extra element in the list. <vagrantc>hugohugo: heh. magic-wormhole is exactly what triggered the issue for me :) <vagrantc>hugohugo: will test the pull request, thanks! :) <hugohugo>and it is also often an interesting puzzle, "why doesn't this package build?"; sometimes it is 15 minutes of work, sometimes 2 hours <simendsjo>People always ask me why I use Guix when it takes so much time to configure and package stuff. I say it's because things "Just Work", which I know sounds exactly the opposite. I guess what I mean is that my system never breaks completely and rots, and that I can spin up a new device really easy. But I have spent *a lot* of time packaging and configuring stuff I need. <hugohugo>and the anticipatory fear (does that have a word?), "1) oh python-iterator-io doesn't run its tests properly, easy fix, just add python-pytest. 2) oh it still fails because it actually has no tests at all in the PyPI package, easy fix, just fetch from git, but this means the tests have never ever been run, so who knows whether they actually pass?!?! dum-dum-dum, 3) Yes they pass!" <ColdSideOfPillow>Rutherther: I still didn't exactly understand how I could fix my issue... <vagrantc>mpv has not a lot of dependents, but they are not the fastest builds... <hugohugo>Yes exactly simendsjo! The first time I fixed my system by using an inferior to include an older package it took me hours. But I knew it was possible, and I knew I could always go back a generation, so the "oh my, I should never have ran that upgrade" fear never arises <ieure>I do wish Guix was more efficient, but being extremely hard to break / having the safety net of rollbacks is very, very goo. <ColdSideOfPillow>Rutherther: Ah, thanks. I initially WAS going to point it to src/, but I realized that I would have to rename all my modules for Guix to correctly find them, but felt lazy :') <Rutherther>you don't have the module names correctly either way, you are assuming they are in guixnest folder, but they aren't <Rutherther>you would have to create a guixnest folder inside of your channel <simendsjo>hugohugo: Btw, magic-wormhole is nice. I use it when I set up a new computer to transfer secrets required to fetch the configuration on the new device. I guess I could use it more though, but I often share through other means with my coworkers. <ColdSideOfPillow>vagrantc: Oh, I didn't realize you were the same person who commented on my pull request related to mpv! <ieure>ColdSideOfPillow, Imagine my surprise when I ran into vagrantc in person the other week. <vagrantc>ColdSideOfPillow: yup. your patch seems to work ... just checking the highly unlikely chance it breaks something else <vagrantc>i have been known to manifest into the physical world from time to time <vagrantc>i think i ran librewolf for the first time testing one of ieure's updates :) <vagrantc>was a good excuse, i had been meaning to look at it anyways <ColdSideOfPillow>How's your build journey going? It doesn't seem like it is the quickest of tasks haha <ColdSideOfPillow>It is at times like these (waiting eons for a package build) that I wonder if interpreters really are the way to go... <vagrantc>ColdSideOfPillow: stuck on plasmatube and vtk for a while now ... it's busy, hopefully with good results <vagrantc>some of the dependents for mpv didn't build on master anyways ... so *shrug* <ColdSideOfPillow>ieure, vagrantc: tbh if I met someone who I know online I'd just freeze up and be so socially awkward... <ieure>ColdSideOfPillow, You get used to it. <Rutherther>ColdSideOfPillow: and here I thought everyone meets you at night <vagrantc>met several guix folks before i had ever seriously tried guix (felt like they had crashed out reproducible builds event to do this bootstrappable thing ... which i much later got really excited about!) <ieure>ColdSideOfPillow, When I was in my 20s, I had to meet another Debian developer to get my key signed, that was some awkward nerdy times. <attila_lendvai>i need to reconfigure, and it's failing, even with some older commit that i have picked last time <Deltafire>should be good once mesa-updates is merged, it's not far off now <Deltafire>i've pinned to 7f86f1e which seems to be working okay <Deltafire>it'll fail due to trying to inherit a linux-libre kernel version that doesn't exist <vagrantc>python-mpv does not appear to be building on master either... not sure if that is before or after the python related changes recently <vagrantc>also python-pyqtwebengine@5.15 (@6 builds fine) <vagrantc>ColdSideOfPillow: i think opencv is the last build i am testing regards to mpv