IRC channel logs
2026-03-01.log
back to list of logs
<ozzloy_>i'm installing guix on top of arch and it's going well! <amano>If I move from gentoo linux to guix system, will I be freed from system update nightmares? Is guix system a well-designed OS? <bdunahu>amano: if you mean updating and then the system not booting, I ran into that with parabola multiple times, but never guix in two years <amano>I was talking about gentoo refusing to update my system or erroring out during compilation. <mange>Probably not. Sometimes packages fail to build due to changes in other packages, or whatever. Guix's atomic system upgrades and roll-backs make it tolerable, but you do sometimes get stuck. <amano>mange: Is guix system a well-designed OS? At least, is it less painful than gentoo? Or, is it just another OS with trade-offs? <mange>I haven't used Gentoo, but all software is tradeoffs. I like Guix a lot, but I wouldn't recommend it to everyone. <amano>It is easier to update arch and void, but they are fragile after updates. <amano>Gentoo linux tends to be solid after update goes through. <amano>I think guix can be potentially simpler to deal with than gentoo because gentoo has USE flags and various other complexities.... <amano>On guix, a package just depend on other specific packages. <amano>If there is anything simple and solid, I will use it. <amano>I guess reproducibility is going to make maintenance easy once you get the hang of guix, but guix has steep initial learning curve. <amano>So, guix definitely has trade-offs. <futurile>janneke: nice - great seeing the progress from everyones hard work! <yarl>janneke: impressive (even if I don't understand much). So hurd uses NetBSD's rumpkernel for some of its drivers? <yarl>Makes me sad when I see their fundraising progress bar at netbsd.org <janneke>yarl: yes, that's right; the linux-2.6 kernel drivers are finally being updated :) <mange>yarl: About your call-with-downloaded-file thing yesterday: moving the proc outside the catch means that the error-thunk has a different meaning. It used to replace the return value of proc, but your switch will turn it into an *input* of proc instead. <sneek>Welcome back mange, you have 1 message! <mange>Oh, hey, lilyp's response is pointing out what I said. :) Hence my more involved solution. <mange>(Response on your PR, that is.) <rrq>I just installed guix to learn... though maybe someone can tall me how I turn off the colouring in the "guix search" output. <rrq>.. or on all guix' output <efraim>you might be able by setting NO_COLOR=1 <rrq>hmm "info guix" is in Spanish(!?)... <rrq>I guess it that available in Enlgish <rrq>I guess it's available in Enlgish? <rrq>(otherwise it'll be a bit of a learning curve for me) <janneke>rrq: it's available in 31 languages (at least partially) with english as the primary language <rrq>hmm I got Spanish when I installed <janneke>ACTION is puzzled that if you don't use LANG=es_ES or somesuch, you'd get spanish, though :) <janneke>if setting LANG* C_LACC doesn't help; just try plain: info <janneke>and G TAB, selecting the english version <janneke>possibly it's a thing to be reported/asked to the packager? <rrq>LANG=C LANGUAGE=C info ... gives "Administraci\303\263n del sistema" <rrq>right; I installed with "apt guix" (on Devuan excalibur) <rrq>so this is rather an "info" issue? <janneke>rrq; you can always do something like: info /usr/share/info/guix.info.gz (which should be the english manual, rather than /usr/share/inf/guix.es.info.gz, which should be the spanish one) <janneke>texinfo is the source, which compiles to info/html/pdf <rrq>ok.. though I wonder why info thinks this is Spanish :) <rrq>alphabetically guix.de would be first... maybe the logic trips on the e* ... as there is no "en" <rrq>yeah devuan wouldn't know since texinfo and guix are straight from debian <janneke>rrq: you never know...i've got all languages intalled and `info guix' shows the english manual for me, so yeah... <rrq>seems to use /usr/share/texinfo/lib/libintl-perl/lib/Locale <rrq>was installed with guix ... seems to default to Mexican Spansih <rrq>(not sure about defaulting) <janneke>interesting...when you say "installed with guix" do you mean: "installed by apt as a dependency of guix?" <janneke>in guix, thet packages is called perl-libintl-perl <rrq>the libintl-perl files belong to texinfo <rrq>hmm I had that installed from before <rrq>but it looks like only guix offers multiple languages <rrq>and guix-cookbook, which has dr fr ko and sk plus guix-cookbook.info.gz <janneke>possibly you can [re]configure info and set the preferred language <rrq>(presents in English) <rrq>hmm there was file /usr/share/info/dir in Spanish, and when I removed that I'm getting guix in English <janneke>rrq: yay -- so "who" installed that file? <rrq>good question :) .. it was dated "Mar 1 22:56" local time... about an hour ago <rrq>about when I installed guix + dependencies, with apt-get <rrq>it's not owned by any package... I'm checking backlog <jungy>I notice there's a difference in how the guix manual vs the shepherd manual recommend creating shepherd services. Should you be defining them with the service or shepherd-service function? <rrq>janneke: .. would be at very end: "Processing triggers for install-info" <janneke>rrq: so, that might be the packager of the guix package -- [and/or possibly some setting somewhere on your system?] <rrq>I'll try purging and reinstalling to see if I can capture it <rrq>happens in the "update-info-dir" script from package install-info <rrq>hmm actually the install-info binary <rrq>possibly that the /etc/default/locale settings are note exported <rrq>janneke: nope; I purge and reinstalled, and got Spanish back. with or without export <rrq>hmmm "find /usr/share/info -name guix.*info.gz" lists es.info.gz first <bjc>janneke: i'm looking for the kernel-arguments option for hurd-vm-configuration, and i don't see it <bjc>(probably easier to do this here than fedi 😉) <bjc>i guess id have to do it in the 'os' field? <janneke> (inherit %hurd-vm-operating-system) <bjc>thanks. i was racking my brain to try and remember how to do that <janneke>bjc: i've just updated the blog post but it will take some time for it to become online <janneke>bjc: thanks for the report; i've been using this for ages in my configuration, so didn't notice it :) <bjc>yeah, i figured it was something like that =) <janneke>the blog post looked a lot smoother without this, but it's better to have it being correct; oh well <bjc>agreed, but next time it'll be smooth =) <janneke>bjc: very happy with you trying it, and reporting back! <bjc>i've long been excited for the hurd. recent developments not withstanding <bjc>i first booted it back in the 90s =) <janneke>yeah, in the 90s it was "pretty easy" to install and run on actual hardware... <bjc>so, further bad news: operating-system isn't a field specifier for hurd-vm-service-type, though os is. but i can't figure out how to pass kernel-arguments in to os <janneke>bjc: ah oops, sorry; yes the field is "os" <bjc>sorry, not hurd-vm-service-type, but hurd-vm-configuration <janneke> (inherit %hurd-vm-operating-system) <bjc>i was trying to use (os (inherit …)) <janneke>i made this mistake editing the blog post initially, fixed it later, but got the problematic snippet still in my kill ring :-( <bjc>i haven't really messed much with guix for a while, so i'm super rusty <jungy>Just pinging once more, how do you define a service, is it service or shepherd-service? <janneke> (inherit %hurd-vm-operating-system) <bjc>ok, it's booted, but now i don't know the root password 😆 <bjc>ssh won't take an empty password <bjc>and, indeed, doesn't work from the console either <bjc>ah, so you're passing keys in. ok <bjc>it's interesting, because if i use the bare-hurd64.tmpl it just uses my password <janneke>possibly you can use (permit-root-login #T) (allow-empty-passwords? #t) (password-authentication? #t) like gnu/system/examples/bare-hurd.tmpl has <bjc>i have no idea how it gets it <bjc>i'll poke at it more in a bit. i may be misinterpreting something. might just take any old password <janneke>in any case, unless you cotnfigured something else explicitly, /etc/childhurd/etc/ssh/ should be initialized and added to the childhuld <janneke>so you'd be able to login using those credetentials that are used for offloading <bjc>ah, ok. didn't know about that <bjc>is /etc/childhurd/etc/ssh mounted inside the vm, or is it copied when the vm is created? <bjc>the permit-empty-passwords stuff didn't work, because a password is being set, i just don't know what <bjc>and all i see in that directory is an offload public key. but i dunno where the private key that matches that is <janneke>bjc: it's being copied in via the "secret-servic" <bjc>well, i got a login finally, and can confirm root has a locked password by default (! in /etc/shadow) <bjc>but my config is… not small to make this happen <bjc>after that, i can ssh guix@childhurd <janneke>it's not really the one-liner i wanted to show off...hehe <bjc>the permit-root-login can be ditched, since its locked anyway <bjc>might be worth integrating some of it directly into the vm config so the one-liner can return <bjc>i'm not thrilled about creating a passwordless guix account by default, but i'm not sure what else to do <bjc>hmm. why is showtrans /servers/socket/2 not showing anything, but ifconfig -a does? <janneke>bjc: oops, out of my depth, maybe ask in #hurd? <bjc>this is a guix thing, i'm pretty sure. on my debian hurd tests it works as expected <bjc>i'll see if i can figure it out. maybe it's a dhcp thing <bjc>hrm. seems guix/hurd doesnt like getting 8g of ram from qemu <bjc>nevermind. it just hung for some other reason on that boot <janneke>hmm, it seems footnotes are not really supported at all, oh well... <janneke>maybe i'm missing something, i'd like to have org instead of markdown for our blog posts anyway :) <bjc>i can only assume md was chosen for popularity reasons <bjc>or maybe to grant cover: "see we're not all emacs nerds!!" <janneke>i don't want to give the impression to complain, i'm very grateful for haunt <bjc>guix pull still hanging at 1% on the hurd <bjc>might just be slow. i can see it using 8% of a cpu core <bjc>but it's been like 10m at 1%, so i'm not sanguine about its prospects <tschilp>I'm still wondering, how I'd need to write it properly to apply right within the services-section... <bjc>you can just put modify-services into the services section <Rutherther>tschilp: fields can have just one value. You were trying to assign two values to it in the first case. You need to put it all inside of append <bjc>if you have services defined outside of modify-services (completely normal) then you'll need to use cons* or append to put them all together <Rutherther>tschilp: as for the second case, you need to remove the second %desktop-services. You had %desktop-services twice in your config. modify-services takes a list of services, modifies it and puts it back. <bjc>like: (services (cons* (foo-service) (modify-services %desktop-services …))) <sneek>I last saw yelninei in #guix 5 days ago, saying: there are currently still a lot of test failures for 64bit so dont expect to much. <tschilp>Rutherther, bjc: thanks, I will give this a shot right away! <janneke>civodul: i believe upgrading gnumach (which needs a mig upgrade, which needs fresh bootstrap binaries) helps with some of the hangs... <janneke>...but the relation with the /servers/crash is not entirely clear to me -- there was a fix in hurd for that, i believe -- c809367c * crash: Fix hang on x86_64 core generation <tschilp>Rutherther, bjc: decent, thanks a lot for your input. I went for the ~put it into append~ way, and it works just fine (and my config is lean again...)! <civodul>janneke: in theory, if the crash server crashes, it’s fine <civodul>(that’s the whole point, right? :-)) <civodul>but yeah, we should try upgrading Mach <civodul>i think yelninei has a pull request for that? <civodul>janneke: oh BTW, congrats on the blog post!! (and all the work that led to it) <janneke>civodul: good, yeah i gues yelninei was stuck updating the actual binaries, so i added a patch for that to hurd-team on top of their pull request <janneke>however, i'm building yet a newer set of binaries after updating gnumach and hurd to latest greatest, haven't heard of yelninei just yet; we'll see tomorrow <janneke>civodul: and yeah thanks, very please with the blog post and the enthousiasm it generates! <csantosb>Ey Guix, is it possible to remove an argument keyword from an inherited package ? The descendant uses cmake, instead of qt, so no #:qtbase <ieure>csantosb, `delkw' in (guix utils), but it's not exported. <ieure>csantosb, I don't think `substitute-keyword-arguments' can delete them. `delkw' is called by `ensure-keyword-arguments', but I don't that doesn't let you delete, either. <csantosb>I have a qt-build-system package using #:qtbase flag, then, a (cli) descendant which inherits from the former, this time using cmake-build-system <andreas-e>I have never heard about a similar case! But as I see it, the arguments are just a list with an even number of entries; it should be possible to get rid of the "#:qtbase qtbase" part. Is there no ready-made macro or function to remove these keyword arguments? <csantosb>I'm thinking something similar (get-rid-of! #:qtbase (substitute-keyword-arguments ...)) <ieure>csantosb, Use `delkw', it does exactly what you want. (delkw (package-arguments inherited-package) #:qtbase). <ieure>Use (define delkw (@@ (guix utils) delkw)) to access it, even though it's not exported. Or give it a better name and export it. <csantosb>By the way, qtwayland is implicit by qt-build-system ? <csantosb>I see we add it by hand per package, which is weird <graywolf>I did not really notice any /etc related errors in /var/log/messages nor during a deploy. Any ideas how to debug further? <graywolf>Also there seems to be a bunch of dead symlinks (/etc/static leads to non-existant file in a store, and e.g. /etc/pulse leads to /etc/static) <Rutherther>non-existent files just happen, it's normal, nothing can prune them when they're no longer referenced <Rutherther>try running /run/current-system/activate as root. Do you get an error? <graywolf>#<&compound-exception components: (#<&external-error> #<&origin origin: "symlink"> #<&message message: "~A"> #<&irritants irritants: ("File exists")> #<&exception-with-kind-and-args kind: system-error args: ("symlink" "~A" ("File exists") (17))>)> <graywolf>Does not really tell me what file, but it is a start <graywolf>So looks like I am running > month old /etc, probably since c4298638ca27717be4a83cb033dcbfecdea88093 . Welp. Is the /activate in general safe to run? So I can just try again and again with strace? <Rutherther>it is fine to run activate of current system from current system generally. Unless there is a wrongly behaving service <graywolf>It is weird no one else noticed in the mean time <Rutherther>graywolf: I recommend to search for EISDIR in the strace <Rutherther>graywolf: no one else noticed... why would they? This won't happen to everyone, it is highly dependent on your system <graywolf>Aah I see now, /etc/containers is a directory in the /etc, but a symlink in /gnu/store/...-etc <graywolf>The fact that guix deploy shows no error what so ever is not great neither <graywolf>yeey I have /etc/screenrc now. Thanks a lot for the help, now I am off to repeat the same on the remaining 4 machines :( <graywolf>no, it was /etc/pulse; like, I get that " highly dependent on your system" might be true, but using pulseaudio-service-type with pulseaudio-configuration does not seem like that unsual <graywolf>No, I configure podman manually, so that one is on me, but the other I had to delete was /etc/pulse, which I would expect to be common <Rutherther>that is not what I meant highly dependent on your system. Are you sure you have not added pulseaudio recently? <graywolf>No, nothing here changed. I am pretty sure it broke once I upgraded to Guix containing " creation of /etc. <graywolf>"build/activation: Simplify the creation of /etc." <graywolf>Though the system still mostly works, my keyboard broke (now I see why, /etc/udev did not work), but that was solved by adding myself to input group. <graywolf>I would not notice if I did not try to add new file to /etc/ via etc-files-services <Rutherther>that has been added 3 months ago, so it does not match that you would be getting files from a month ago in /etc <graywolf>well it works now, and I am unlikely to reconstruct the exact steps to break it again; if it is just me, it does not really matter ¯\_(ツ)_/¯ <Rutherther>I do not know if it's just you, but for me /etc/pulse definitely did not break with that change <graywolf>Right, so it broke on only on one of my machines. Ok, no idea what happened. <Rutherther>yes, as I was saying, highly dependent on the system. On specific conditions before and after... <RavenJoad>I figured out why texdoc is not working for me. The texlive-(scheme|full)-* packages do not install the "doc" output of their constituent packages. Is there a way to make that happen? Do I need a transformation on the inputs transitive closure to select the doc output? Is there a way to filter out non-texlive packages from that closure? <redacted>Does guix weather check for substitutes for may architecture, or could the substitute on bordeaux not be built for x86_64? <redacted>ah, looks like --list-systems tells me it *does* default to the right arch <redacted>Ok I'm unsure why my local machine is trying to build <RavenJoad>redacted: It could depend on what Guix commit you are on. <redacted>I was using guix time-machine to run guix weather on the latest commit. <redacted>And I'm trying to reconfigure after running guix pull <redacted>which I'm assuming means I should be on the same commit when running guix weather and guix reconfigure. <redacted>I get the same result when running guix weather without guix time-machine, so I think I didn't need time-machine <Rutherther>redacted: so what is the full output of the weather, can you send it through a paste site? <Rutherther>redacted: also if you do "guix build torbrowser --dry-run", what does it tell you, is it going to substitute or build? <redacted>guix build torbrowser --dry-run tells me it'll build a derivation <redacted>--no-grafts means it won't build, but download the substitute <redacted>I think I've not understood what grafts are. <Rutherther>okay, so all is fine with that. And with guix system reconfigure it starts building the actual torbrowser, not substituting it? <FuncProgLinux>Is there any section in the manual that shows how to integrate guix on a foreign system to the desktop? Things are way different on common distros :( <Rutherther>redacted: then I would guess it's because you are using a different torbrowser in your system config somehow. How do you reference torbrowser in your config? <redacted>I import (gnu packages tor-browsers) and add the torbrowser package to the package list in my home environment. <untrusem>Rutherther, redacted: torbrowser doesn't have substitutes for more than a week <Rutherther>why wouldn't it have substitutes if guix weather is saying it has them? the only way that would happen is if torbrowser itself would be grafted, which doesn't make any sense <redacted>Well, running guix reconfigure with --no-grafts means that I don't have to build torbrowser locally <Rutherther>redacted: just to make sure... could you confirm that prior to that you were really building it, not just the graft itself? <redacted>Not sure how to tell the difference, since I'm not sure what a graft is. <redacted>building /gnu/store/0bi8zs3yk71bhckng5w030370wvfk1ma-torbrowser-15.0.drv... <Rutherther>redacted: okay, that's an actual build. That confirms it <untrusem>Rutherther: it is trying to build torbrowser <Rutherther>redacted: this is strange then. It shouldn't happen. The only case it should happen is if torbrowser itself was grafted, which it isn't (and it wouldn't ever make sense to graft a leaf package) <redacted>Ok, I'm not going to go ahead with the reconfigure then, since I don't know what's up. <untrusem>I though it might be due to nss-rapid vesion bump but its been happening before that as well <darthlukan>I'm confused about substitutes and grafts - Are grafts the locally built portions of a package that get "grafted onto" the package? Or are grafts the things I was able to download from the "substitutes" server so that I don't have to build locally? <darthlukan>If there's a direct link to something in the manual that describes this, I'll happily read up on it <Rutherther>darthlukan: grafts are applied locally. The packages necessary for the grafting are typically substituted, though. So only the application of the grafts is local - the replacement of paths in the packages <darthlukan>Rutherther: So then, if I see "Applying n grafts to $PACKAGE" then $PACKAGE was substituted (more often than not)? <Rutherther>darthlukan: yes, both the package itself and the replacements of the packages that are being replaced by the graft are built on bordeaux / ci <Rutherther>that is the point of the grafts in the first place, to not cause many rebuilds. The only package rebuilt is the replacement, that is made on ci / bordeaux <darthlukan>Rutherther: Gotcha - That makes much more sense to me now, thank you! <Wurt>How can I set a label in a Codeberg pull request? I know that it must have a patch-upgrade label, but I don't know how to do it. <gabber>which service would i extend to execute some "echo 0 > /sys/class/foo" before the login prompt? <gabber>my pinebook pro boots with NumLock enabled for some reason <Rutherther>gabber: that's commonly configurable in the "bios" setup <Rutherther>gabber: if you wanted to execute it before login service, you would extend the shepherd root service type with a one shot service that executes it on start and then change the agetty-service-type in your %desktop-services, adding shepherd-requirement on your service to its agetty-configuration <Rutherther>gabber: anyway I wouldn't really think that's a good way. Either the setup or just making a one shot shepherd service without making sure it starts before the login service, because... it will likely start before it or close with it <gabber>BIOS as in U-Boot compiled in option?