IRC channel logs
2025-05-21.log
back to list of logs
<ekaitz>gnu website is down...? or only for me? <apteryx>ACTION just realized using gdbserver to start an application being debug is convenient when working with 'guix shell --container --network' and debugging via Emacs <cnx>really obscure, but core dumping behavior of the host system is not is not isolated by guix build environment <bacs>linked from the header of other pages <cnx>the manual is built from the guix repository, so bug-guix@gnu.org seems like the right list for it <bacs>cnx: thanks - will try there <bacs>cnx was trying to get some links for the bug report but all the pages seem to be giving a 404 now <bacs>not so much a bug as an infrastructure issue methinkst <efraim>I'm playing with dist-package and it turns out I might need to figure out out-of-source builds <efraim>I take back the last part, I'm going to have to figure out how to disable it for make distcheck, I'm not ready to work on that part of the code yet <efraim>futurile: apparently make distcheck automatically tries to do an out-of-tree build but ada-ed doesn't support it currently <futurile>love the checking that it uninstalls with make uninstall - long time since I've done taht <csantosb>Ey Guix ! TIL it is possible to call sr.ht, guix based ci, from codeberg repos, see codeberg.org/emersion/yojo <efraim>does sr.ht have non-x86 CI machines? <csantosb>See "The "native" column is checked if these builds run on native hardware for that architecture, if unchecked the builds are run on emulated hardware and may suffer from poor performance." <efraim>I see emulated arm64 support on debian/sid. <csantosb>If there is interest, support for other architectures might be explored, they're rather open, provided one takes care of it <efraim>I wonder if it would be possible to re-use the x86_64 image to also do i686, but I don't think I want to encourage people to use it <efraim>and there's always the --system=i686-linux option <efraim>I was wondering about testing other OSes mostly, I have most of the Guix architectures locally <yelninei>efraim: hello, is it intentional that diffutils-boot0 no longer inherits the arguments from the normal diffutils? I am a bit annoyed having to rebuild the hurd stuff again <efraim>yelninei: not intentional. I didn't test to see if it would change the derivation on the hurd <yelninei>efraim: just adding back a ,@(package-arguments diffutils) fixes it. These are nondefault for hurd, but only relevant for skipping/xfailing some tests which are not being run anyways <efraim>I'm guessing findutils-boot0 and file-boot0 are both ok <apteryx>ieure: any idea why we have nss/fixed, which is not used anywhere? <apteryx>usually these /fixed variants are used for grafts <apteryx>efraim: re curl, I think I didn't retest QA much with that version I posted (I refreshed after guix lint found there was a newer version avaiable). Seems the cmake issue was already fixed upstream, and we have a cmake 4.x version already, maybe I can unify these. <efraim>apteryx: sounds good. I figured we just needed a newer version. I think we also have 3.30 or something <PotentialUser63>Is there a way to specify a mirror url in a channels.scm? I'm trying to avoid the recent DDoS attacks on savannah by specifying a mirror as a fallback. <identity>PotentialUser63: you can just replace the normal repo url with the one of the mirror <PotentialUser63>Can that be specified in the channels.scm, so savannah is the "primary" or "main" url and if it doesn't a response it falls back to the codeberg url? <identity>PotentialUser63: i do not think you can do that, no. <sham1>Having some sort of a fallback thing would be nice, but yeah, I don't think that's a thing <PotentialUser63>Ok good to know. Last question, for substitutes it looks like those can be mirrored by adding URLs substitute-urls, where would that be on a foreign distro? <ruther>if someone could tell me what it is that is actually throwing 502, I would fix it <ruther>but I am too lazy to debug someone else's failing 'site' <PotentialUser63>ruther: Were you receiving some sort of error message when trying to use that code? When I modify my channels.scm to use those functions you provided (like so https://paste.debian.net/hidden/b47454c0/) guix seems to pull down the channel just fine when I do "guix time-machine -C channels.scm -- shell -m manifest.scm -c 0", but those display <PotentialUser63>functions never execute so I don't know which channel it pulled from. <ruther>PotentialUser63: hmm, I am getting output of display functions when executing the command you sent <ruther>but you can always just do guix describe with the new guix you obtained. Although I am afraid it won't be possible to do time-machine with decribe & shell <ruther>you would have to either use pull with -p to put the profile somewhere you prefer and then you can profile/bin/guix, or do two invocations where you risk the second one is going to use different uri (and also it will be slower) <PotentialUser63>I don't exactly care which mirror is being used, I'm just trying to avoid a failure when using "guix time-machine -C channels.scm -- shell -m manifest.scm". My team is starting to use guix for managing some of our projects and so far time-machine and shell are really the extent of what we're using. I'm just trying to limit the confusion for someone <PotentialUser63>who knows nothing about guix and just needs to run commands from a README to get a dev environment up and running. <ruther>PotentialUser63: I see, but then I don't really understand what you were asking about <ruther>you meant about my previous comment that it didn't actually work for me? <PotentialUser63>Oh and actually I do see the display functions printing, it was just formatted oddly in my terminal <PotentialUser63>No, I think your comment makes sense and I'm seeing the same failure where savannah is selected but the 502 is coming from elsewhere. <ruther>Yeah :( one easy workaround would be to provide two urls with the checkouts, one to check for !200 and the other to actually put to channel url, and for savannah cgit could be used <identity>PotentialUser63: you probably just want to use the codeberg mirror and be done with it <ruther>But as for the proper fix, I don't know because I don't know what url is " Git error: unexpected http status code: 502" this complaining about <ruther>civodul: yeah, but what url specifically? <ruther>because it is not the git url itself <ruther>and I can even download some of the files under it from browser <ruther>identity: yes, but guix pull has no idea about cgit <ruther>it uses the url I provided, something under it that starts throwing 502 <PotentialUser63>For what it's worth, cgit is not currently throwing a 502 for me, at least when accessing through a browser <platoxia>What exactly do hash mismatches resulting from the command 'guix gc --verify=contents' mean? How concerned should I be about modified files in /gnu/store with hash mismatches? <identity>platoxia: it might be a symptom of file corruption <identity>you should be able to fix the substitutable ones with "--verify=contents,repair" <platoxia>Could the mismatches be a result of failed system reconfigurations? <ruther>platoxia: by failed you mean you got an error with stacktrace from guile? Then no <ruther>platoxia: files are written to store only after build properly finishes. And they should never be modified. Having a mismatch means something went very wrong. <ruther>file corruptions are likely if something or someone force shutdowns your computer. If that hasn't happened, then I would suggest to use a tool to check if your disk is fine <ruther>If it happens to be alright, then it could be a bug in Guix System when the store(usually root) filesystem is not unmounted properly. There was such a bug, but it should be fixed now. <ieure>Yes, been meaning to follow up on that, but have had more limited time recently. <ieure>The issue has gone away for me. <ruther>ieure: Great, I actually think there were two issues <ruther>ieure: because I initially was able to get corruptions in VM consistently, then after shepherd update that was gone, but there was still the e2fsck issue <ruther>but I dunno, it's hard to be sure without a reproducer in a VM for the, presumably, 'second' issue <ruther>as far as I know the person who came up with the fix debugged it on their hardware directly <demindiro>How do I package a project that uses Conda (or pywrap)? An example package would be useful <demindiro>I just realized there's a CMakeLists.txt, guess I'll try cmake <platoxia>Thanks for the info guys, in my case it could be both hard shutdown and old hdd issues. I'm running the guix "gc --verify=contents,repair" now and it seems to be doing a lot of work. Probably time for a new hdd. <civodul>cbaines: hey, would you happen to have a black belt in serial port twiddling? <civodul>we need to hard-reboot bayfront via the serial, but serial input is not working as expected (some of the input is swallowed) <ruther>why can't they reboot it locally? <civodul>there’s nobody locally, it’s a data center <ruther>oh, I thought people were supposed to go in there today because of that <civodul>people went there yesterday, but then a bug brought us back to square one <ruther>civodul: I see, thanks for the info <vagrantc>civodul: two gettings rrunning on a single port ... tends to be a problem i have ... <civodul>vagrantc: yeah, turns out ‘%base-services’ provides one by default <vagrantc>i think it only does if you specify console= on the kernel commandline <vagrantc>or the kernel is otherwise configured for that <vagrantc>you can also specify console= multiple times, fwiw ... although usually only the last one gets all the kernel messages sent to console (but getty's and whatnot still may show up on all of them) <Lord_Devi>Hello. I am having trouble finding a solution on Google or in the standard Guix dox on how to switch the URL for my main guix channel from savannah to the codeberg mirror. Currently I am just running Guix on top of Fedora, and am working my way through the process of learning Guix so I can ultimately install the distribution. <Lord_Devi>I can manually pull from codeberg buy using "guix --pull CODEBERG_URL", but I want to make this the default for the main guix channel. Can someone direct me towards the solution if possible? <vagrantc>that way i can easily switch between them <vagrantc>i have remotes for both savannah and codeberg in my local checkout ... and then just need to update the master and keyring branches periodically <Lord_Devi>Thank you Civodul. I hadn't found that document page. Also thanks Vagrant. I actually did the clone from codeberg and was thinking about trying to use that across my network instead of codeberg directly. I think I will go that route. <Lord_Devi>Very excited to be diving into this finally. =) <vagrantc>yeah, i also then can pull once and then push to a bunch of local machines and save a bit of network bandwidth that way :) <vagrantc>especially useful for machines i update rarely <Lord_Devi>What about the pre-built binaries for packages? Are the defaults typically fairly fast, or do they tend to have some slow down / connection issues the same way the savannath guix git does? <vagrantc>there are occasional hiccups there too :/ <Lord_Devi>Yeah I tend to play around with a lot of containers and VMs, and would love to be able to push updates to those eventually too. <meaty>anyone have experience with packages that have lua/luarocks dependencies? <meaty>I'm trying to package mudlet <Lord_Devi>Is there a decent way to solve for the pre-builts? If there is a more reliable location, and way to set that up, it would be really nice. Eventually I'd like to make my own local mirror of that too. <Lord_Devi>Interesting. Caching proxy, hadn't thought of that. <vagrantc>there's also guix publish ... e.g. you can update whatever you want on your local machine and then share those substitutes to other machines <Lord_Devi>Mudlet, I spend way too much time in that program. lol. <Lord_Devi>vagrantc: Guix has so many neat little tools to explore. That 'publish' sounds worth exploring too. <vagrantc>you can even run guix publish but use the signatures from the "official" substitute servers, but download the actual substitutes locally ... <vagrantc>thanks to reproducible builds ... which is what got me into guix initially :) <Lord_Devi>Yeah. I've been a long time enjoyer of Davis over at Systemcrafters. He is the one who first got me interested in Guix long ago. BUt I was really invested into Fedora. All my servers, all my containers, everything was Fedora after years of effort. I've decided to move on though, and am trying to immerse myself into Guix, LISP, and get away from Systemd. <vagrantc>ACTION came to guix after decades of debian <vagrantc>though i still primarily use debina and guix is just a fun side project :) <Lord_Devi>The reproducable builds would have prevented many problems I just ran into with Fedora too. Virt-Manager expecting different version of python3 libs that Fedora installed, or installing KDE breaking much of my setup... Would have not had to suffer through these problems if I was using Guix. <Lord_Devi>You probably think about moving away from Debian to Guix 100% from time to time. May I ask why you have not yet? <vagrantc>it's pretty rough around the edges, even though it has lots of amazing features ... most of my machines run debian stable, which only gets minimal changes over the course of 2+ years <vagrantc>i do not think i have ever seriously considered switching 100% <Lord_Devi>Yeah. I think I can sense some of this roughness already. But so far, it is mainly related to savannah or the pre-build binaries downloading slowly or getting 502 gateway errors when looking at links from the documentation. <Lord_Devi>No? Ok, fair enough. Certainly Debian is a solid solution one can generally rely on. <vagrantc>just a few days ago, guix pull was broken for some hours, for example ... <vagrantc>i also maintain the guix package inside debian :) <vagrantc>although guix apparently releases less often than debian these days :/ :) <Tadhgmister>ok but when your system is rolling release does the version number bumps mean very much? <vagrantc>there is a whole discussion addressing the lack of releases that touches on a handful of reasons where it matters <Lord_Devi>I DO tend to like up to date packages, but depending on the package, it may not be super important. <Lord_Devi>But, as Tadhgmister suggests, that does not matter too much. So long as the tooling is getting updated / fixed / and package maintainers do a fair job of keeping external tools up to date. <Lord_Devi>I watch some interviews from Guix developers, people who helped build things like shephard and stuff, and some of those people aren't with Guix anymore. Jobs or other things. I think that likely has something to do with the release scheduling. <Tadhgmister>idk what getting cutting edge package versions in Debian or Fedora looks like but running `guix refresh` and then possibly submitting a patch if the package runs fine is a nice option when there are those few packages you do want to stay on the cutting edge of <vagrantc>yeah, i love some of the tooling around updating packages in guix ... <vagrantc>although not being too guile savvy, sometimes the smallest things take forever to resolve <Lord_Devi>My hope is that after enough immersion that problem will get less and less. *crosses fingers* <vagrantc>spent three days trying to figure out some "wrong number of arguments" error ... but it neglected to tell me how many arguments it expected, what arguments it received, and what was even being called with the wrong number of arumgnets ... that was maddening and i almost gave up on guix <Tadhgmister>yeah the guile error messages could be a lot better, I do wonder how much of that is the syntax transformations and data structure re-arranging that happens as part of function declarations and how much of it is just backtraces were not implemented well <vagrantc>but yeah, being a rolling release decreases the pressure on making releases to a large extent, perhaps almost to a fault <identity>Lord_Devi: it is in the %default-channels variable