IRC channel logs
2026-02-16.log
back to list of logs
<ekaitz>sneek: later tell janneke the commit you were running (53733436015) also works for me and it doesn't even complain about the locales like `bootstrap-team` does <old>I fail to do a guix-pull for the past weeks now <old>I get something along <old>hint: This usually indicates a bug in one of the channels you are pulling from, or some incompatibility among them. You can <old>In the build log I get: <old>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (python-packaging)) (value #f)) <old>seems to be coming from guix-hpc <csantosb>apteryx: fj.el for emacs people is slighly faster and scriptable <csantosb>But nothing beats the email based workflow <apteryx>or does it feel like trying to retrofit matrix into emacs (poor user experience) <csantosb>It's bare bones, but way better than a web gui; rather slow server side <janneke>sneek: later tell ekaitz: check; also the M1 problem was fixed in mes: 461b48f35f49126f5831aa1af3a89f42286ec70f <sneek>janneke, you have 1 message! <sneek>janneke, ekaitz says: the commit you were running (53733436015) also works for me and it doesn't even complain about the locales like `bootstrap-team` does <efraim>I seem to have gotten stuck at tcc-boot0 on riscv64, I think I'll let qemu finish building that package and then continue <sneek>Welcome back efraim, you have 1 message! <sneek>efraim, ekaitz says: idk what to do with the make-mesboot0's configure scripts failing with gash <efraim>sneek: later tell ekaitz I'm not sure what to do about make-mesboot0 either. I'll see when I get to it. Maybe downgrade it back to 3.80? <janneke>efraim: i reverted the recent stage0 bump for now, because it has the obnoxious: M1 failed, OK problem; hope that's OK <janneke>ACTION should release a mes 0.27.2 some time soon so that we can upgrade <efraim>not an issue. I figured I'd just bump it while working on all the other bits <janneke>ACTION is trying qemu-riscv again to see if the config.status gash hang in make-mesboot0 can be bisected <efraim>the last WIP commit to use the musl path for hello-mesboot0 is pretty ugly but I was working it so I could revert it easily without checking the git log <futurile>Morning all - massive blizzard here - other half has just gone off for a quick pre-work ski, and I'm left hopping around the flat :-(( <efraim>we're in the mid 20s here in Israel <futurile>heh heh heh - it's been warm here all winter - we don't get the minus 20's we did a few years ago - now it hovers around 0 <futurile>sounds like winter in Israel is the only time I could stand the temperature :-) <efraim>summer is basically all of april through october and can be brutal <identity>at least you do not need vitamin D supplements <identity>aaavigatori: (info "(guile) Status") has the explanation for the name <futurile>identity: do you take vitamin D in winter, does it work? <efraim>dariqq: I think something about rust-ring-0.17 somehow pointing to rust-ring-0.17.14 instead of 0.17.8 caused a bunch of rebuilds <dariqq>maybe its 6a386b23c228b1ec3f8c1e95c56a080ac7c7ec1d which changed the rust-ring-0.17.14 symbol? Why is such a big rebuild going straight to master? <efraim>oh yeah, or that one is more likely <identity>futurile: i mean, as far as i know i do not have any respiratory problems, though i am seemingly immune to diseases anyway <efraim>janneke: back to gcc-muslboot0 on i686, time to see if I can get it to build <sneek>Welcome back ekaitz, you have 2 messages! <sneek>ekaitz, janneke says: check; also the M1 problem was fixed in mes: 461b48f35f49126f5831aa1af3a89f42286ec70f <sneek>ekaitz, efraim says: I'm not sure what to do about make-mesboot0 either. I'll see when I get to it. Maybe downgrade it back to 3.80? <futurile>... it's a great example of why I think we should push to a 'branch' and either have the tooling, or just merge into master once a week - it would give subsitutes time to catch up <futurile>even if you're super careful ... sooner or later there's an accidental big rebuild and users have no substitutes so we burn a 1000 laptops down heh <ekaitz>okay so in qemu I can only build mes with the old commit <ekaitz>but in the real hardware I can with the new one <ekaitz>and! there are tons of locale errors <efraim>so I have to admit to somehow ignoring the locale errors, are they there on i686 also? <efraim>same error on i686 for gcc-muslboot0 <dariqq>and my pc just oomed building webkitgtk <ekaitz>efraim: there are locale errors in x86 too <janneke>ACTION only ever seems to get locale warnings... <dariqq>futurile: the bigger issue is that there is a lot of bureaucracy for e.g. the lua patches which fixes a 10year old bug with lua search pathes with 900 rebuilds but something with 5k+ rebuilds gets straight to master <ekaitz>the diff between wip-riscv-bootstrap and bootstrap-team is not that big to have this problems... <ekaitz>i think i see what's going on here <futurile>dariqq: they're part of the same thing - no-one wants to do anything 'big' so big changes either go to a team branch or they rot. If you want to push a 'big change' and there's no team branch you have to create a new branch in CI. There's just too much friction overall. <futurile>dariqq: and the team branches are a bit of a mixed blessing, they now run for months, which means when they merge into master they cause a lot of change. There's a risk to that. <andreas-e>futurile: Team branches are currently very fast. go-team has taken a week from opening the issue to merging. <sneek>Welcome back andreas-e, you have 1 message! <sneek>andreas-e, ekaitz says: it was the fonts!!!! <andreas-e>That holds when the branch just needs to build and no new problems are discovered, and when the branch is not too large. <futurile>andreas-e: there is no lua team though right, so "someone" has to create a new branch/CI and then check it doesn't break anything. <futurile>andreas-e: and anyway the general point still holds - if you push to 'master' users may land-up with no substitutes available - it's just the nature of the thing <janneke>successfully built /gnu/store/z996bq6aim0p187iii8plxcbjsyg4ykm-mes-boot-0.27.1.drv <andreas-e>Indeed big changes without a team are a problem. <andreas-e>Things that go to a team branch and QA are immediately available, since the bordeaux build farm stores the branch builds. It used to be the same when QA handled pull requests from debbugs. <janneke>that's current bootstrap-team with qemu-10.1.0 for riscv <futurile>andreas-e: so what I was trying to suggest on guix-devel was that we have a branch (could be time-based) that we push to, and this is then merged to master (weekly?). Basically, we could do that for *everything* - somewhat like your 'large builds' experiment but going further - "if it's not a team branch push to XX". That would be built by CI and then we'd have substitutes for users. <futurile>it would be nice to have a tool taht guaranteed substitute availability for users, but without that Cayetano's suggestion of using 'itme' seems reasonable to me <andreas-e>The problem with the approach is that it would need to have a fast turn-over and merge very often. Doing a world-rebuild in a week could be challenging. And what do we do when there is a real problem? <andreas-e>I am bitten by the past "core-updates" branch. This turned into a dump where people would throw their commits, then something broke, and it would be impossible to disentangle due to which commit. Nobody was really responsible. <theesm>isn't guix weather supposed to be that tool regarding substitute availability for users? <andreas-e>If I remember well it then took months to sort it out. <andreas-e>This is where the team idea came in: A group of people that take responsibility for a certain area they are competent in. If python-team has a problem, it does not get merged; so Python people are forced to sort out their own mess ;-) And they are enabled, because rust, gnome, core and so on do not pull the rugs under their feet by breaking more stuff in the common branch. <csantosb>futurile, andreas-e, One week delay improves current situation in the sense that maybe we don't have the time to build everything, but we do with a percentage higher than 0%, as it is now <Rutherther>theesm: yes, but 1. you need to first download guix so there is no easy way to look through multiple commits, you would wait for eternity, 2. there is a 'policy' in place that developers cannot push changes that would cause high substitute unavailability, like changing a package with many dependents. This prevents master from having a lot of substitutes unavailable now <theesm>Rutherther: agree, esp. 1. is pretty unergonomic for a use-case (scouting multiple commits for availability) that, at least for me, occurs pretty often-ish <theesm>andreas-e: OT to the discussion, but think i'll try to fix the build failure of ruby-puma today so we can merge #6393 (won't put more time in upgrading vagrant in #6390 though as i don't have stakes in that package other than fixing its build status for now) <scv>is it possible to use GNU Guix in a way such that zero binaries are used and every single package is compiled from source with CFLAGS of my choosing? <thanosapollo>scv: you could disable substitute servers to build everything from source and write your own package recipes. <Rutherther>scv: why do you want to get zero binaries? if it's just because you want to change the CFLAGS, just do that and do not disable anything, no need to disable substitutes for that <Rutherther>you will still probably not want to actually do that for ALL packages, because if you did you would have to build from bootstrap. And you would have to also build everything for building guix itself on guix pull... which I expect is not what you really want/care about <identity>scv: doing that is inadvisable because of frequent rebuilds. if you just want to have some packages tuned for your architecture, like SIMD and stuff, see (info "(guix) Package Transformation Options") on --tune <scv>Rutherther: for fun mostly :) <identity>and, yeah, do you *really* want to sit through 8 hours (or however long that takes, guessing) of bootstrapping <Rutherther>scv: if you really wanted to go from the ground with the full bootstrap chain as well, not downloading the tarballs, note that unfortunately you will need the guile binary for that :D <scv>identity: i come from gentoo land, im used to it haha :D was wondering how feasible it was to get reproducability but compiling from source at same time throughout the system <futurile-afk-phy>andreas-e: I understand the "burned by core-updates" part. I don't have a solution to devs "dumping" things, that's a mixture of tooling so people know there's a problem and a social one where the group needs to push back. <janneke>tcc-boot0 didn't build for me with qemu-10.0.1 <janneke>error: in phase 'build': uncaught exception: <janneke>%exception #<&invoke-error program: "sh" arguments: ("bootstrap.sh") exit-status: 1 term-signal: #f stop-signal: #f> <janneke>ACTION has a stupid question for you guix'ers -- is there any reason to re-try that failing build, or do we trust it will fail again? <ekaitz>janneke: i have found cases where the retry worked, like those gash issues i'm trying to reproduce <ekaitz>janneke: is the fix by stikonas you pointed me to included in 0.27.1? <ekaitz>because that might be the reason why I cannot build bootstrap-team in my device <aidans>Hi my home reconfigures are failing because its trying to build librewolf from source instead of downloading from substitute servers(everything else seems to download from substitutes fine). I'm on x86_64. Any ideas? <ekaitz>janneke: a very poor thing to say as a maintainer but idk which version of mes do we have now <janneke>let's make sure to document it in #799 <janneke>well, yeah but there's so many aspects flying around all the time <cbaines>aidans, could a substitute for librewolf not be available yet? <cbaines>I saw earlier on IRC some sizable changes landed directly on master, so that could be holding things up <aidans>I thought maybe but checking ci.guix.gnu.org a build completed 15 hours ago, and none others for x86 are queued <cbaines>I still don't see /gnu/store/8y6k2cg463c61xcdqdrgps6n9qx4p3ik-librewolf-147.0.3-2 as being available, guix publish says "We're baking it" <cbaines>so maybe it's been built, but the substitute isn't available yet <aidans>Oh I see, and only the latest version is kept on master so I'd not have a way to use a previous substitute(at least while staying on the latest commit of the channel) if I understand properly right? <Rutherther>cbaines: that doesn't usually happen for 16 hours though. Seems to me something has gone somewhere. I expect restarting the build ought to fix it <Rutherther>aidans: you can use time-machine for imperative(cli) or inferiors for declarative(guile) <cbaines>Rutherther, it shouldn't need to be rebuilt <Rutherther>cbaines: restarting the build will not rebuild it if it's available though. I did not expect it would atually do a full rebuild <cbaines>having Cuirass built it again won't change that <aidans>Rutherther: good idea with inferiors, thanks both of you <Rutherther>cbaines: I expected it's not in store on berlin tbh. I expected it did not copy. If it's in the store, I am not sure what's wrong then <cbaines>something to do with guix publish specifically I would guess <Rutherther>comment in code says "should be available within 5m" for the case "We're baking it" <cbaines>there's nothing obvious in the guix publish logs though <cbaines>the guix publish process on berlin has used 1y164d of CPU time if I'm reading htop correctly <cbaines>I don't know how long it's been running for, but that seems like a lot, I'm not sure I've seen a process get to the 1y mark <cbaines>looks like it's been running for 138 days, which is not bad. The Guile things I look after would have segfaulted at least once in that time... <Rutherther>but I am even surprised that the uptime of the server is so large, I would expect occasional reboots for kernel updates <cbaines>I've restarted guix-publish on berlin now <Rutherther>random thought, could it be something is running out of space somewhere, preventing narinfo from being saved to the disk? <Rutherther>(doesn't seem to have effect, unless it's actually going to appear in 5 minutes now) <yelninei>janneke: Running current hello with the "wrong" libc: hello on system with the new mig: error while loading shared libraries: libgcc_s.so.1: cannot stat shared object: Error 18446744073709551316 <yelninei>similarly the bootstrap-guile just exits after a io_stat_request <Rutherther>cbaines: have you tried looking at what "(valid-path? (open-connection) "/gnu/store/8y6k2cg463c61xcdqdrgps6n9qx4p3ik-librewolf-147.0.3-2")" produces? <yelninei>similarly the bootstrap bash does not find anything in PATH because all the lookups fail. <cbaines>it's unclear whether things were just slow, or whether restarting was necessary to fix something stuck <Rutherther>me too, yeah. So it must've gotten stuck somehow previously and now it really 'baked' it in the five-ish minutes <Rutherther>cbaines: right, but to me it seems very unlikely there would be no people hitting this narinfo path in the past 16 hours, so I am rather betting on the restart fixing it <yelninei>janneke: How much work is it to rebuild the bootstrap files with a fixed mig? I think only for x86_64 <look>speaking of ci, a lot of builds seem stuck rn, builds straight up failing in logs but cuirass status just hanging <aidans>wow, the more I use guix the more it feels like a house of cards constantly being blown over but being built back up by even more dedicated people as soon as it falls. o7 <Rutherther>look: what do you mean by cuirass status? and failing in what way? <Rutherther>I see "note: build failure may have been caused by lack of free disk space" <Rutherther>look: this has been finished already, though. Seems like similar issue as with librewolf, the path exists, but isn't substitutable (yet) <Rutherther>look: yeah seems like something is going on that shouldn't be going on <cbaines>unfortunately I've got other exciting things like the washing up and moving furniture to do today, so I can't spend more time investigating ci.guix.gnu.org issues <Rutherther>look: have you messaged guix-sysadmin mailing list already? <look>im just patiently waiting for qtbase substitutes for about 2 days and went investigating a bit <look>if we're lacking people, i can volunteer to periodically monitor and manually poke some stuck ci jobs <futurile>aidans: the reality of smallish/volunteer FOSS projects is often how dependent they are on a small number of 'heroes' in my experience heh <janneke>yelninei: not much work, just a long wait? :-P <janneke>sorry, i don't have anything useful to say about that, except than maybe: let's fix mig <yelninei>if we accept that there will be an abi break (which the mig change is) then i think it would be better to move to the new thing sooner than later, especially if it fixes things <rustyguix>Anyone has useful pointers on how to best handle git dependencies for rust packaging? <yelninei>janneke: i tried to build the bootstrap tarballs but guile-static is failing <andreas-e>Does anybody know how to typseset cyrillic with texlive? I am getting "Encoding file `ot2enc.def' not found." and am looking for the missing texlive package. <Kabouik>Rutherther I see that you have been trying to use pantalaimon (issue #171) for Ement.el but were not able to verify it and hence use it for encrypted rooms. Did you eventually manage? I am facing the same issue. <Rutherther>Kabouik: hey, this isn't related to guix... and no, I did not manage to do it. Pantalaimon just doesn't work with other servers than Synapse <Kabouik>Yup sorry, I should have just PMed you, I just recognized your nick and know you from #guix only. Thanks, too bad. I was secretely hoping the issue was Guix-related and there was a secret recipe to make it work. <podiki>i see we have gnome and rust team branches next, but wasn't clear from the merge issues how close there are, does anyone know? <futurile>FuncProgLinux: not too much happening this end; it's snowing like crazy here; I did push a load of updates to obs so we now have a working video recording set-up <FuncProgLinux>futurile: Hey that's niced, I used OBS a lot back in college <futurile>podiki: there was an exchange from andreas-e saying that rust will go next (as gtk is blocked I think) - uh it was on the ticket somewhere <podiki>thanks, did see that convo though wasn't sure if that mean rust was pretty much ready to go <FuncProgLinux>I have to patch both pluma and eom. And then ask the gnome-team if we can have libwnck-next <futurile>FuncProgLinux: I'm hoping to do some more 'guix videos', and I want to use it for video backgounds on my work zoom calls etc <andreas-e>Yes, podiki and futurile, in principle both were ready; but there is a non-debugged issue with gnome-team, which is not evaluated by the data service. <futurile>podiki: that I don't know - maybe we can summon efraim to say if hey are ready <FuncProgLinux>futurile: I follow your blog and learned to package with it but I didn't knew you did guix videos :O <andreas-e>The next two branches (lua-team and guile-team) are ready as well as far as I know. <futurile>FuncProgLinux: well I did one - but it took ages, and I spent some time doing editing on the guix social stuff - so figured I might try again <efraim>rust should be ready. when I saw the other branches merge quickly I made sure it was ready NOW and not in a month <efraim>I test built rust-manifest.scm on x86_64 and no problems <podiki>do we have any grafts right now? i don't think i saw any active replacement fields in my quick git grep <andreas-e>csantosb: Speaking of branches, you might wish to submit a request for merging to debbugs concerning hpc-team if it is ready. <efraim>on gnome-team while reading commits I found a duplicate rust crate, but I haven't checked the output of make yet <andreas-e>Hm, I would not expect duplicate rust crates to cause problems. But who knows. <efraim>I'd expect a warning about one shadowing the other, but it shouldn't be a problem <untrusem>I am glad rust branch is ready to be merged <andreas-e>In the worst case, we will have to do a "git bisect" with pushing the branches and waiting for the data service to succeed or to fail. <andreas-e>Yes, there is a warning in the data service logs. <podiki>if the current queue is all about ready to go and will be merged "soon", that's great <efraim>could a non-registered patch cause it? <podiki>i'll probably have a graft pushed in the next few days and will do an ungraft immediately on mesa-updates then <podiki>(not mesa-related but easy since that branch has a ci job already) <andreas-e>As I understand it, it would be a failure of "guix build --derivations some-package"; so if the patch is not registered, but in git, it should not make a difference. I think unregistered patches only play a role for "make dist". <efraim>I also see the gnome team has some cross module deprecations, that could possibly be it <efraim>I bet running some of the linters will find it <andreas-e>I need to leave now, looking forward to news :) <andreas-e>efraim: You could push the upower commit to gnome-team, it should not break anything. (famous last words?) <andreas-e>Well, the branch moved, and your upower fix apparently is in there. But can it be evaluated now? <efraim>spdk already has its error on master <efraim>nothing obvious from ./pre-inst-env guix lint -c profile-collisions <efraim>podiki: I have it open as a tab, I'll try to take a look <podiki>efraim: thanks! i haven't had a chance to try out the patch locally yet, but it is on my list for this week. and to bring mesa up another version since we missed the last series entirely at this point. <PotentialUser-70>I just got gentoo linux up and running when I heard that they are going to a subscription-based model. In light of this, I am (heavily) considering switching to GUIX! <PotentialUser-70>I just wonder if (and which) window managers are supported by GUIX? Maybe this is a silly question I don't know <untrusem>PotentialUser-70, Guix is a linux distro, so every wm on linux is supported <PotentialUser-70>um I wrote the usb and when I started the installation it told me that my AMD gpu and CPU were not FOSS and thus not usable. Is there any way to get around this? <theesm>PotentialUser-70: most likely yes, that question is better suited for the #nonguix channel though <janneke>ekaitz, efraim: tcc-boot0 also doesn't build with qemu-9.1.3, same error <ekaitz>janneke: are you in `bootstrap-team`? <efraim>I'm still in mes-boot on riscv64 <ekaitz>my mes-boot in qemu doesn't build <janneke>qemu builds are, relatively, *very* fast <ekaitz>janneke: are you 100% sure that you are not getting "mescc: fail:..." <ekaitz>and the gnu-make-mesboot0 doesn't hang for you? <janneke>ekaitz: ah, i reverted the stage0 bump <ekaitz>meanwhile, i'm still trying to reproduce the gash hang <ekaitz>could that be because the riscv machine is just slower? <janneke>it would be lovely to bisect that into a bug report <janneke>are you sure that hang isn't fixed by the recent gash work? <janneke>ekaitz: if there's a race somewhere, who knows... <ekaitz>i'm not 100% sure, but bootstrap-team already has most of the changes that are related with process management <ekaitz>there's even a comment about it in gash <ekaitz>it is true that the changes actually do affect <ekaitz>before (2 years ago) the failure happened in a different location <janneke>ekaitz: i'm hoping such problems get a new test together with the fix <ekaitz>yeah... it's a hard catch, samplet had a good stacktrace <ekaitz>but I didn't talk with him in a while <efraim>while `guix lint -c derivation` on gnome-team: guix lint: warning: importing module (ice-9 ftw) from the host <efraim>unfortunately it doesn't say which package it is <ekaitz>janneke: with your revert mes builds <yelninei>janneke: the warnings come from a guix patch, guile{-3.0-}-linux-syscalls.patch. Wouldnt it be better to adjust the patches to include "liguile/bytevectors.h"? <janneke>yelninei: i thought i tried that...but i misunderstood <janneke>possibly you're right, i'll give that a try <yelninei>the include is already there but inside a #ifdef __linux__ maybe just make it available to all? <yelninei>as taht would also fix the 32bit version <janneke>yelninei: that's what i'm trying now <podiki>neither "info 'guix' build systems'" or "programming interface" get to an info node <janneke>i tried changing #ifdef __linux__ to #if defined (__linux__) || __GNU__ <janneke>but that failed, after first re-building x86_64-linux... <podiki>seems a combo of spacing and capitalizing is needed to be correct exactly <podiki>(despite in info that page being "(guix)Build Systems" no space after guix) <yelninei>janneke: yeah because that one is actually linux specific but was thinking of just moving the bytevectors.h out <janneke>the bootstrap phase of guile takes so terribly long...and you first need to (re)build the native version before getting to what you're actually testing <janneke>yelninei: i don't understand why this patch wasn't presented to guile upstream <janneke>ACTION has added a notice about that in this patch <yelninei>janneke: Note that 2 versuins of the patch, one for guile 2 and one for guiel 3 <janneke>ACTION is hoping they used the right one <janneke> BOOTSTRAP(stage0) GUILEC ice-9/psyntax-pp.go <ekaitz>non inclusive language in the spanish translation of the docs was a very unexpected surprise for me <ekaitz>more of a shame than a surprise, also but... <janneke>let's hope it can be fixed with a simple patch/email <janneke> BOOTSTRAP(stage0) GUILEC ice-9/psyntax-pp.go <janneke>we're very close to supporting aarch64 in mes! <ekaitz>i have found a new poltergeist in my new evaluator now you mention mes <janneke>ekaitz: when tired -> go home and sleep <ekaitz>janneke: i was going to make a judgement about why we allowed that language to get to the docs, but I decided to pass <ekaitz>everybody thinks they live in the center of the world I guess <janneke>the planets and stars revolve inside me <yelninei>janneke: On the positive side the i586-gnu bootstrap seems fine with the mig change. I guess because all the RPCs there dont have 64bit members and did not change and. So only x86_64 is affected <janneke>yelninei: i think it's a good thing we're keeping i586-gnu for a bit <janneke>i'm happy with dropping it in a year or two, when "everything" works in x86_64-gnu, wdyt? <yvesbode>hello everyone, is it possible to disable home configuration for a user? as in, after I've already created a home configuration I want to disable it altogether as if that user had never had a home configuration before. the reason I'm asking is that I've migrated my home configuration into the system configuration, but the stand alone config I had <yvesbode>before and the new config that lives in the system seem to be conflicting with each other now and causing some weird behaviour. I want to see if disabiling it and reconfiguring the system activates the new one instead. I can't seem to find anything in the manual regarding disabling the home configuration, only rolling back to previous generations. <acidbong>on Rust packaging: why does Guix need declaration of origins instead of fetching them Nixpkgs-style — solely from Cargo.lock? or is Guix currently not capable of fetching stuff this way? <yelninei>janneke: I created a wip pr . Some of the cflags workarounds can probably be removed as well now and i hope some of the test workarounds but this would need to be checked <acidbong>yvesbode: one thing i have in mind is 1. strip down your home config to, say, only `glibc-locales` in package list and nothing else, 2. switch to that configuration (so that all symlinks get deleted) and 3. remove .guix-home and open a new shell <yelninei>acidbong: My guess is to remove vendored or prebuild libraries or rebuild generated sources <Rutherther>acidbong: of course it's perfectly capable of that. It's abut the philosophy mostly. This way you can easily check everything is built from source, replace something in case there is a (security) bug or an attack <acidbong>ah, so to collect more eggs in one basket, got it <Rutherther>if you rely on cargo there is not much control and in case you dediced to replace library X accross the code, there is no easy way to do it <llazo>hi, what could it be that after a guix pull i do a guix system reconfigure with a non root user gives a message saying cant open /var/guix/utmpx permission denied? <hugohugo>sha256 hash mismatch for /gnu/store/h7qamyvs37an30c0klngqqjzm4m9q97r-icecat-140.7.0-gnu1.tar.zst: <hugohugo>when downloading the substitute, isn't that strange? <Rutherther>llazo: guix system reconfigure is changing the system you need to execute it as root, ie. with sudo <yvesbode>acidbong: thank you that helped me understand what was happening a bit better, turns out the system home config does take precedence over the stand alone home config, however when I invoke 'guix home list-generations' it still lists the generations of the old config, even though it isn't doing anything anymore. <Rutherther>yvesbode: just remove the generations - /var/guix/profiles/per-user/$USER/guix-home* <yvesbode>another question, I have a `channels.scm` file on my system configuration, this system configuration also defines the same channels for the `operating-system` and described in the manual `Customizing the System-Wide Guix`. I don't want to maintain both of these channel definitions, is there a way to import `channels.scm` as if it where a module? <Rutherther>you can (load ...) it. But why don't you just make it an actual module and export it as a symbol? <yvesbode>will commands like `guix time-machine -C channels.scm` be able to make use of the file if I convert it to a module? I though it had to be and expression that evaluates to a list of channels <Rutherther>that is correct. But a module can be such expression. Just return it at the end of the module, ie. "%my-channels" as last line in the module <yvesbode>brilliant, will try that. the only problem is that issuing `guix describe -f channels > channels.scm` won't just work anymore to bump the system channels, but I think I can just manage that a bit more manually <janneke>yelninei: including bytevectors.h doesnt' help <yelninei>janneke: maybe also libguile/foreign.h for scm_to_pointer and scm_bytevector_to_pointer? <yelninei>janneke: i can try to look into it tomorrow if this is still not enough