IRC channel logs
2025-05-31.log
back to list of logs
<meaty>can it be trusted that each build phase will start with the pwd at #$output? or any other location <ieure>meaty, I don't think there's any guarantee other than the early phases start in the unpacked source tree/clone. <ieure>meaty, ex. you can (chdir "whatever") in a build phase, and subsequent phases will retain that $PWD. <ieure>Probably the 'unpack phase is what cd's into the source tree, but I don't know for sure. <ieure>$ git push -f origin librewolf-updates <ieure>To codeberg.org:guix/guix.git <ieure> 0e808bb6f4..2daf76bb52 librewolf-updates -> master <apteryx>you just need to register; it doesn't share auth with codeberg.org <podiki>apteryx: do you know why berlin isn't picking up mesa-updates changes? i did a rebase (on codeberg only of course) and then changed the spec git url to the generic one <podiki>but that was some hours ago and it hasn't checked repo even with another new commit <apteryx>hello! I can check the logs, perhaps there's a hint <apteryx>2025-05-30 21:17:29 updating spec of jobset 'mesa-updates' <apteryx>that's the lats occurrence in /var/log/cuirass.log on berlin <podiki>must have been when i changed the spec via web <podiki>not sure what triggers a watch/pull of the git url though <apteryx>it's probably stuck after crashing with error: uncaught '%exception' exception: (#<&compound-exception components: (#<&formatted-message format: "channel '~a' lacks an introduction and cannot be authenticated <apteryx>I'll report this to guix-sysadmin and restart cuirass <podiki>there were also lots of failed evaluations of master, not sure what the logs were saying though (wasn't helpful last i looked quickly) <apteryx>it's been restarted, I hope it helps <apteryx>berlin failure modes are pretty obscure to me <dckc>guix --version says c31662f7294b194663bc521358b01c3a7d7e4e27 ; what's the corresponding date? where's the git repo? let's see... <hako>dckc: Try `guix describe` <hako>if you're not specifying it manually, no <dckc>that will happen automatically somehow? <hako>yes, in your next `guix pull` generation <dckc>is there a blog item on the migration? ah... yes... May 11, 2025 <dckc>hm. I did a `guix pull` and `guix describe` still says savannah.gnu.org <hako>What does `echo '(format #t "~a~%" (@ (guix channels) %default-guix-channel))' | guix repl -t machine` say? Maybe next pull, this one updates the channel and you have the updated variable now? <hako>Then it's the next pull. This generation uses default channels from the previous generation. <dckc>what is @ ? ,describe @ says Syntax error <dckc>I'm having a heck of a time figuring out how to navigate scheme stuff. <hako>info "(guile) Using Guile Modules" <dckc>ah... kinda like open in ocaml. thanks. <dckc>is there any way to "follow your nose" to look up @ ? or do you just have to know where to look in that case? <hako>`i` in info can lookup index <hako>programming interfaces are usually indexed <dckc>bingo again! -- syntax: @ module-name binding-name <dckc>is there a way to ask the repl about it? <dckc>is there a rendered version of GCD 002 handy somewhere? <arvid>Can somebody help me with some confusion regarding inputs? In the new input style we just enter a list of file-like-objects (mostly packages), right? How do we control the names of the inputs so they don't shadow each other for example in case of using a package with multiple outputs? <csantosb>Hi Guix ! I'm thinking about emacs packages, does it makes sense to send patches to master, before emacs-team branch merges ? <csantosb>Between the day the merge is requested, and the day the queue executes there might be months ... how it goes exactly ? the whole branch is rebased on top of master after ? what if there are conflicts ? <futurile>csantosb: that's exactly the problem, and it's happened a few times. I believe that branches should be short-lived, focused and consequently there's no chance that a patch goes to two places by mistake <futurile>csantosb: at a miniumum with long-lived branches we have to merge master into them multiple times to avoid conflicts. <csantosb>futurile: sure, we merge master into branches to check nothing breaks, but, once the merge requests is launched ? day 0 everything builds, months later, when the merge is accepted in the queue, is it build against original or current master ? <csantosb>Then, building emacs stuff takes a few hours, does it makes sense to wait for months ? <ruther>csantosb: the branches are usually rebased against current master, aren't they? <ruther>I think Andreas-e was doing that, recently at least <csantosb>ruther: sure, for as much as I know; but once they enter the queue, they're frozen, nothing else is accepted neither in the branch, nor in master, right ? <yelninei>just tried out the agit way, could be very convenient for small/simple changes <ruther>csantosb: I don't know how emacs-team is doing it, but for example podiki merged a change to mesa-updates yesterday... <ruther>and mesa-updates is in the queue <ruther>freezing it when it is in the queue seems just wrong to me <csantosb>ruther: ok, nothing is frozen, mesa-updates is 3rd in the queue; what happens when it comes the time to build ? <csantosb>does it build against current guix ? or agains guix when the merge request was launched ? they might be different <ruther>csantosb: neither, it builds against the branch <ruther>which would mean then it depends on whether someone rebased it or not <ruther>and I am pretty sure there is no other way it could be doing it as the issues with requests to merge do not contain any patches. So where would it get patches to apply... <csantosb>... so when the branch is eventually built, there might be conflicts with master, right ? <ruther>but that would be true for either of those cases. ie. even if current guix is used at day X, at day X + 5 when the QA succeeds someone could've merged in conflicting change during those 5 days <csantosb>what happens in this case ? the merge is accepted anyway ? <ruther>csantosb: what do you mean 'accepted', accepted by who? <ruther>according to my understanding there are no rules about that, the person doing the merge would decide at that point <ruther>but maybe there are rules besides what I've seen... <csantosb>the point on requesting a merge, and building the branch agains current master, is to check that it builds, right ? <ruther>csantosb: I think there are two points - check that it is fine and build substitutes so that people do not have to wait for days before getting substitutes <csantosb>All in all, during the queue period, two conflicting versions of a same package may exists <csantosb>The one in the branch, the other in master <ruther>I think that is true generally with multiple branches, not just during queue period <mra>back to the pull request mines lol <csantosb>ruther: thing is that submitting patches to a branch guarantees that the patch won't be available in master before a very long time, I'm afraid <csantosb>submitting to master is way faster, I mean <ruther>csantosb: I don't think so, it depends on what the current state of the branch is. So it doesn't guarantee that it won't be available for a very long time <csantosb>well, just the time it takes the queue to run is a long time to me; plus the time until the merge is requested <ruther>csantosb: I meant mostly that currently if you submit to for example mesa-updates, I would expect that to be in master in like two weeks, maybe less. <ruther>because it is currently third in the queue <csantosb>Since #78257, one month ago, until the branch eventually builds, there might be months <ruther>? I see core packages, c++ and mesa right after them <ruther>I would expect emacs-team also 2 - 3 weeks <csantosb>2-3 weeks to build the branch, you mean ? <ruther>assuming people will work faster after QA has built on all of the branches before that <ruther>csantosb: yes, to get to it & build it - as in the c++ and core branches have to be merged in less than two weeks <csantosb>I mean, how do you estimate the time it will take to build c++ branch, for example ? <ruther>just an optimistic guess assuming there will not be problems <csantosb>ok, thanks; I understand much better how things go on <cricri_>hello, in a tiny scheme module in the root directory of my repository I am using this line in order get the full path no matter on what system I am: <cricri_>(define %dot-home-folder (dirname (current-filename))) <cricri_>For some time this worked well, but yesterday I was troubled with 'unbound variables' errors when using 'guix system image'. <cricri_>After a lot of debugging, I found out that this line is somehow breaking the modules search path mechanism of guile... <cricri_>Is there a safer way to refer to absolute path of my repository? <ruther>cricri_: what variables is it complaining about? <cricri_>Variables that are defined after a call %dot-home-folder. <sham1>Could you post the code in a pastebin so we could take a look <cricri_>the %dot-home-folder definition is on line 75 <cricri_>like this, guix system -L /private/home/myGuix/dotfiles image /private/home/myGuix/dotfiles/config/systems/planet0.scm <cricri_>will fail with: "error: %os-planet0: unbound variable" <ruther>cricri_: have you tried guix repl on your config file? <ruther>that is usually a sign of an error in the file that exports the variable. Guile doesn't print errors about loading modules in load path very well <ruther>so guix repl can help finding out where the issue is <cricri_>Oh wow, I have tried just now: In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f <cricri_>As you said the error is refering to the file where %dot-home-folder is exported. <muaddibb>how do I fix my system's time? tried `hurd restart ntpd` and it didn't work :( <cricri_>so must be a problem with the guile setup/configuration... <ruther>cricri_: so you did `guix repl ./dot-home.scm`? <ruther>cricri_: hm. Doesn't happen for me <cricri_>Oh no sorry, I use -L with the path to the dotfile <guix-newbie>When running `guix shell --container --link-profile` in a project repo, is it possible to mix in my editor setup? <ruther>guix-newbie: sure, just --expose it <guix-newbie>So I have a safe environment to develop in, but also my familiar editor. <ruther>cricri_: so how is the full command you use? <cricri_>yeah true without -L there is no error. <guix-newbie>rutger: i was thinking more of pointing it to a home config to use alongside the projects guix.scm <ruther>guix-newbie: guix shell doesn't support activating guix home <guix-newbie>also, somehow it would be great if it would store the list of used files in a project-specific way <ruther>you would need to activate it manually <ruther>guix-newbie: that means running the activation script <ruther>guix-newbie: that is what happens when you reconfigure. ~/.guix-home/activate is ran. <guix-newbie>so run `guix shell` with expose and running a nested `guix shell` for the editor setup? <ruther>I don't know how will nested shell help with editor setup <guix-newbie>Adding my specific editor preferences into a shared project does not seem the way to go. <ruther>guix-newbie: I thought that is why you used link-profile, to pass your editor through... <guix-newbie>I think I'll experiment a bit to mix in project specific settings, so the home profile can be mostly empty and I refer to a specific profile to mix with the contents of the project's guix.scm <muaddibb>ultimately rebooting and setting the date in the bios fixed my problem <cricri_>ruther: thanks for your advice! I have to leave now and will continue my error search another time. Have a good weekend! <apteryx>was there a guix package for forgejo floating around? not the binary package stuff: I want to run 'guix shell -D' to hack on forgejo and thus needs a package specifying all needed inputs. <apteryx>haha, I had forgotten that our Go packages are useless for Go development. All I need is 'go' itself, and that go.mod file from which it'll fetch and build everything needed, ala cargo. <csantosb>Dumb question of the day: regarding guix system, when doing a 'guix pull' and rebooting, is it still necessary a 'guix reconfigure' ? <Lumie>csantosb: after a guix pull, you don't need to reboot, only after reconfigure <Lumie>Depending on the updates, sometimes not even then it's necessary <Lumie>I reboot after every reconfigure though <ruther>csantosb: guix pull will only update guix itself. Use guix system reconfigure when you actually want to update your system with the new guix version <muaddibb>csantosb: if I understand correctly, if you do 'guix pull' but don't 'guix reconfigure' your system will not be updated, only the packages <the_tubular>Is this even still needed ? I though guix switched to new kernel now with kexec live on the fly <Lumie>YEah, what muaddibb said, the system doesn't get updated when simply pulling <ruther>muaddibb: guix pull doesn't update packages, it updates only guix itself <csantosb>Sorry, should have stated that I'm rebooting anyway, so my question about if `guix reconfigure` is necessary <ruther>why would it be 'necessary'? nothing is necessary until you want to actually update something... <csantosb>I do want to update things, and I'm rebooting. Do I need to reconfigure ? <csantosb>This is the guix image in sourcehut; just noticed that the image pulls, but doesn't reconfigure <ruther>csantosb: as I mentioned already, guix pull updates only guix, so if you want to update the system, yes, you need to system reconfigure <ruther>csantosb: but why would it reconfigure? it just creates a guix system image <ruther>csantosb: why would the build system need a system update? <csantosb>Exactly; not even pulling is necessary, in this case <ruther>csantosb: whether pulling is necessary depends on what version of guix you want to be used <csantosb>The image is built from previous everyday <ruther>csantosb: if you want latest and the image is built from previous, you need to pull <csantosb>The sequence is: launch image, pull, build new image, git in, pull again, close <ruther>csantosb: if the system.scm is the one you launch and pull in, then that one will have outdated guix as well, since it doesn't change the guix used in guix-service-type. So pulling is still necessary <ruther>csantosb: to make pulling unnecessary the guix-service-type's value would have to have guix-configuration-guix set to something like (current-guix), or (guix-for-channels %default-channels) <ruther>csantosb: the advantage would be that the checkout doesn't have to be redownloaded and reauthenticated twice, so it will speed up the process <csantosb>So pulling is necessary; what about reconfigure in this context ? <ruther>csantosb: reconfigure updates system. Do you want to update the system? <ruther>csantosb: then it is necessary. I don't understand why you would want to update the system though. <csantosb>But my doubt if if rebooting reconfigures it anyway <ruther>csantosb: no, reboot does not change system in any way. The same generation is used <apteryx>hm, while attempting to run the forgejo test suite in a guix shell (containerized or not), I get errors like: /tmp/go-build3571568827/b1305/codeformat.test: error while loading shared libraries: libgcc_s.so.1 <apteryx>ah, Go from Guix fetched Go from the internet, so I guess it's looking for stuff at odd FHS places. <apteryx>although even when I use --emulate-fhs in a container the error perists <ruther>apteryx: so you have /lib/libgcc_s.so.1 in the container? <apteryx>this being Go, it needs to fetch half of the internet to get going <ruther>apteryx: and from google proxy by default <apteryx>funny: guix shell -CNF -m manifest.scm -> go --version # outputs: go: downloading go1.24.3 (linux/amd64) <apteryx>I just ask the version and it starts downloading itself. hm. <hako>apteryx: Remove the toolchain line from go.mod <apteryx>that's why I was attempting the --emulate-fhs trick. there's no way I'm going to package tens of Go packages and NPM stuff tonight, so I thought let's go with it. forgejo builds successfully but the test suite throws errors about libgcc_s.so.1 not being found. <apteryx>hako: thanks! now at least go is the one from guix <muaddibb>not something I like to do, but asking ChatGPT I found out that you can use `date --set=...' to set your system's date <muaddibb>searching the web all I found was about systemd's timedatectl <apteryx>hako: someone pointed me that I can use more simply: GOTOOLCHAIN=local <luca>I've tried the cargo lock importer and it was crazy quick. Can't wait to see it in master <guix-newbie>I'm using two channels: guix master branch and the rust-team branch. How can I choose from which channel to get a package? Is there a way to specify this with `use-module` in an scm file? <ruther>guix-newbie: it is impossible to use two channels with same modules, so you can't use two instances of a channel in one guix instance <ruther>guix-newbie: the alternatives are inferiors for declarative-first approaches and time-machine for other usecases <guix-newbie>It is possible in the sense that guix does not complain about it when I do it. It uses the packages from the first channel that has the module. <futurile>I sometimes have the impression that GNU programs are intentionally not supposed to be used. I'm looking at the mailutils package and do _any_ of the utils have an actual example of usage ... no they do not ... so now I'm trawling the test directory! seriously! <guix-newbie>starting with documentation and then implementing might help with that. I often start with code too, so not without blame. <guix-newbie>ok, i see now that with inferiors, packages can be overridden from other channels. I would this on my work server farm where sometimes we're stuck on old versions of packages. This farm is on Nix atm, where we solve it with flake inputs for multiple versions of nixpkgs. <guix-newbie>I think my exercise tonight is to port a project from flake.nix + flake.lock to guix.scm + channels.scm <guix-newbie>does guix have something like nix.buildmachines where derivations can be create on a different machine? <ieure>Yes, works pretty good. I wish there was a way to default to not offloading and have --offload do it, instead of the other way around. <drewverlee>ruther: Thats the same link, does the wget command on it work for you? <ruther>drewverlee: it is not the same link <ruther>the link from the page I sent works for me. The one from the one you sent doesn't <drewverlee>ah. well thats confusing, searching "install guix system" brought me to that first, everything past that was systemcrafters. hmm. <ruther>use the devel manual for everything... except for the initial install when you're using the release (1.4.0) <drewverlee>ruther: I understand the instructions, but can you elborate a bit on why their are two nearly identical manuals? My newbie intuition is that a77e25c is a specific guix commit and 1.4.0 is a, what, guix tag? and you always install a tagged version? Please correct any terms i used wrong. <ruther>drewverlee: the complete manuals are not nearly identical. Some pages are because those parts haven't changed <ruther>drewverlee: 1.4.0 is release (the latest one) and there is a commit tagged with that, yes. <ruther>drewverlee: guix offers isos only for the releases on the ftp. I don't know why there is the commit hash in there. Seems to me like a mistake <guix-newbie>well, that's exotic: guix offload: error: implementation cannot deal with > 32-bit integers <Yappaholic>podiki: Thank you for updating xkeyboard-config to 2.44! Hope this will get merged into master soon <sneek>Welcome back Yappaholic, you have 2 messages! <sneek>Yappaholic, podiki says: i did a local update to xkeyboard-config which builds fine without changes, but haven't tested any dependents <sneek>Yappaholic, podiki says: I went ahead and pushed the xkeyboard-config update to mesa-updates, hopefully substitutes will build soon with that and newer mesa i pushed before