IRC channel logs
2025-11-24.log
back to list of logs
<ham5urg>I try to get Guix onto a laptop. After I installed sof-firmware I still get "SOF firmware and/or topology file not found". I did append to the kernel arguments: "snd-intel-dspcfg.dsp_driver=3" "modprobe.blacklist=snd_hda_intel,snd_soc_skl_hda_dsp" "firmware_path=/gnu/store/*-linux-firmware*/share/firmware" but to no avail. <amano>I'm frustrated by gentoo maintainers. They were extremely slow to even consider the equivalent of a new guix build system, and they refused a perfectly valid patch because I pointed out that OpenRC user services are not ready for production. <amano>I basically can't contribute to gentoo linux. <amano>I'm tired of dealing with tired maintainers who refuse patches on whims or are too slow to even consider any contribution. Unless you are already a core maintainer who has write access, in most cases, don't even bother. <amano>I think guix system can grow a lot if the maintainers develop a cultuer or a process that accelerates external contributions and aren't making contributors avoid hair triggers. <amano>The problem isn't lack of manpower. Manpower will flood in if you let it. <pomel0>happy because my first patch updating a package on guix got approved :D <pomel0>it's the first time I officially help mantain anything on any distro <pomel0>next on my list is updating reaper <bhoot>Hello! I am trying to execute a configuration for gdm user through gsettings. This works: <bhoot>sudo --preserve-env=XDG_DATA_DIRS -u gdm gsettings list-schemas <bhoot>where XDG_DATA_DIRS has a path that points to current gsettings-desktop-schemas/share. <bhoot>I assume I should also be able to run: sudo --preserve-env=XDG_DATA_DIRS -u gdm gsettings set org.gnome.login-screen enable-fingerprint-authentication false <bhoot>but I want to persist this setting in my os.scm. So is there an idiomatic way of exposing XDG_DATA_DIRS to gdm user and then turning off fingerprint auth for it? <Rutherther>mrvdb: good morning. Unfortunately powerpc64le is not really 'popular' architecture, so I wouldn't count on it soon, unless you wanted to do the work. :) Anyway if the error is the tests themselves and not actual issue in the package (and that I am not sure is the case here), you can try turning the tests off. It might be a bit hard to get it right - you would need to replace every mesa package in your system, but it's possible <mrvdb>Rutherther yeah, i have been doing that, but it gets messy (at least for me). <mrvdb>ah, that will be helpful indeed, thanks <sneek>kestrelwx, you have 1 message! <sneek>kestrelwx, daviid says: DBus requires proper GVariant support, which g-golf is missing - I won't be able to work on this before early next year, fwiw, being fully busy devel a g-golf based app for an ong ... <kestrelwx>apteryx: Are outdated PGP signatures not a problem then? I thought the builds would fail. <nckx>kestrelwx: I can't find context in the logs but if this is about the guix.git 'keyring' branch: no (Guix doesn't look at expiry) and if it's about previously imported packages: also no (Guix doesn't bother verifying signatures at build time because it's redundant). <kestrelwx>I'm trying to package some missing GNU projects for Guix, but wasn't sure how to proceed with expired keys. <nckx>Guix has no way of adding package signatures so you're safe. It's up to the packager to do some due diligence (check the latest key on Savannah for revocation, make sure you're syncing with the kool keyserver du jour, etc.) <nckx>Are there package managers that start to fail builds if a key expires? I'd question their judgment & threat model TBH. <rrobin>if you mean the e.g. distro key used to check packages - then yes there are pkg managers that fail <rrobin>although more commonly happens because you are using the wrong key for wrong packages - e.g. different keys for different fedora major versions and you mess up your process by using key for v42 with v44 <Rutherther>rrobin: just to check. Are you sure you're talking about the package sources themselves and not the distro's repositories / mirrors of such repositories with built packages? <rrobin>i am talking about the distro repos - for the package signed sources is anyone using the developer openpgp keys in pkg builds? <rrobin>i don't think guix supports this in (origin) and afaik no other distro does it right? <rrobin>also i am not sure how it would work in practice - we can not simply trust a remote .sig file - we would need to embed the signature in the origin object - but the additional info is only really useful when updating the pkg? <Librebooter>Hello there! I am having trouble with guix syntax, I'm new to lisp <civodul>i noticed the email for Saturday’s release meeting just today :-) <Librebooter>Sorry for the rejoins my irc client is being annoying <Librebooter>I'm having trouble with a field specifier error in my guix config <efraim>next meeting is currently scheduled for next Saturday <Rutherther>civodul: hi. Yeah, it came quite late also because of the gnu outage on Friday. <efraim>Rutherther: have you run into problems building doc/images/bootstrap-graph.pdf with make release? <Rutherther>Not at all, the only problem I came to is that when I do not make a new tag, the --label argument is longer than 32 chars and seems FAT doesn't support such long labels (although I think the intention was to put the label to root partition in the first place, it was just implemented with wrong assumptions) <efraim>I have some fairly messy code right now but I'm pretty close to running the debian-install test on aarch64 <Librebooter>Hello, I need help with a guix syntax error, it's like a field specifier error or something <Rutherther>I think even that update-guix-package.scm has succeeded for me once, but I have removed it because without the commit it doesn't seem so important. And to get the commit I would have to turn off authentication everywhere which seemed like a lot of a hustle <civodul>Rutherther: yup, pity; i wonder if we should start thinking about a backup plan for mailing lists <Rutherther>btw it wasn't possible to use guix-install.sh during that time due to downloads of keys from sv.gnu.org. Well also the ftpmirror.gnu.org didn't run, so definitely wasn't possible to install 1.4.0, I was trying to install new guix-binary that I had locally <Rutherther>I have opened an issue about the keys, but forgot to think about the ftpmirror till now. Maybe we should code at least one or two fallbacks even for the ftpmirror.gnu.org <civodul>Rutherther: we could add alternate URLs for ftp.gnu.org to guix-install.sh, that should be easy <civodul>for the keyring, i’m not sure, maybe we could host a copy elsewhere <civodul>maybe for now just set up a Shepherd timer on the web site that downloads it from Savannah and serves it as guix.gnu.org/keyring.asc for instance <Rutherther>any idea why --recv-keys with the trusted sites where committers upload their keys hasn't been used instead of sv.gnu.org? <efraim>it's probably just never been updated, and savannah was the source of truth for so long <civodul>Rutherther: OpenPGP key servers became very unreliable a few years ago <civodul>major key servers like sks disappeared <civodul>keys.openpgp.org came up with its own policy of not including user IDs unless key owners explicitly consent to it <civodul>which is good, but gpg cannot import keys without a user ID packet <civodul>and downloading from Savannah became more reliable <civodul>of course today, that’s no longer the case :-) <efraim>Rutherther: I'd check to see if the tests were written by different people or more than a year apart. is one of them failing? <Rutherther>I actually haven't ran them yet, I will. I am looking into making a system test for reproducing unclean unmounts. So I was looking at what we have <efraim>I'm not sure commit d33965908dc8e21e9c9834ce1061cdcc664295ab is correct, I'm trying to run system tests manually with --system and it keeps on giving me the architecture of my current machine instead <Rutherther>and I expect that marionette-eval halt to not block until shutdown, so it seems to me the halt test is not actually waiting for a shutdown. But I might be missing something <efraim>no i take it back, I think #:system isn't being passed to system-qemu-image/shared-store-script <Rutherther>I am also thinking if it could be that something parameterizes current-system further so that --system might not have effect <efraim>I think I might want to add a system field to virtual-machine in (gnu system vm) <civodul>Rutherther: ‘system*’ does fork + waitpid; but when invoking ‘halt’, changes are that ‘halt’ will be terminated before it’s had a chance to get a reply from shepherd <civodul>Rutherther: ‘root-unmount‘ was meant to catch unclean unmounts, and i think it does that well, but it only checks for a bare-bones kind of OS config <Rutherther>civodul: and does halt block until shutdown? I thought not, because I sometimes get a ps1 in shell when I execute halt, iirc, I can check once more <Rutherther>civodul: I know, but the current unmount is linked to the shepherd service upgrade as well, so I would need to make a test that uses a proper config, does reconfigure and then halts. Or even running upgrade shepherd services by itself triggers the bug for me. I could send you a qcow2 that shows the bug if you were interested. I am of course trying to make it more minimal and a goal for me would be to make a system test, but I am not sure if I will be... <Rutherther>did you see my messages on codeberg regarding this? I had a question for you how it's possible that I see a system-error from root-file-system's stop logged by shepherd. From that it sort of seems to imply that the guard in it has no effect and it never stops? <efraim>I can use 'guix system vm' to run a VM for a different architecture, right? <cbaines>efraim, last time I tried this for aarch64-linux, it didn't work <efraim>cbaines: do you remember what part? some mix of x86_64 and aarch64 in the VM or it tried to use the x86_64 kernel to boot? <efraim>well that sounds familiar, I'm currently trying to work around gnu/bootloader/grub and gnu/system/vm with pieces that assume x86_64 or only the local machine's architecture <efraim>install-grub-disk is x86 specific in the end, I added code to default to u-boot-arm64-qemu also <efraim>I'll see about using grub-efi later, it wasn't worth fighting with just yet <fmarl>Hey! Currently I'm having problems building niri. The install-phase of cargo-build-system doesn't seem to work (there is no /bin/niri) and there are some warnings about deprecated behavior. Anyone else already encountered this? <fmarl>Hmm alright. I don't find any issue about it (probably my bad), do we have any hints what the problem is? I would try to look into it <Rutherther>it's the first issue I see when I search for "niri" <fmarl>Oh there is already a workaround and the reason for the regression. So thanks for the help :) <flurando>I have successfully installed Guix on Racknerd, with scripts suitable for any full root vps. A writeup is coming out.:) <flurando>for those impatient, well, I tweaked and used bin456789's reinstallation script from GitHub. <flurando>However, there are still many pitfalls in the path, so I would like to share the experience once the writeup is finished. <NaN23>Hello on 3rd of December Bost and me give a session on Guix in Tuebingen (Southern Germany). Please post/boost if you like or show up if you are around :) <flurando>NaN23: Not possible, as I am in GuangDong, China. <gabber>i am suddenly unable to use my scanner (i just did a system reconfiguration): #4439. (how) can i find out whether an upstream kernel change removed the driver(s) needed? <flurando>gabber: you have to first know the name of the driver blob <flurando>gabber: it is unlikely for upstream removing a driver, if they had added one before <flurando>gabber: try git diff the two versions of guix or any other channel, to see what they changed <gabber>flurando: that's what i thought. it used to "just work" but all of a sudden it doesn't. i tried simple-scan with time-machine versions from half a year ago but i get the same error message :( <flurando>gabber: so do you have the last known channel commit that works with your scanner? <gabber>flurando: the package has not changed in quite some time <gabber>no, i don't. at least not with my current system <gabber>that's why i suspect something else to have changed (not the package itself) <nckx>Linux doesn't really have scanner drivers beyond ‘you talk to USB thing now’, nor does simple-scan. Those are provided by sane (previously sane-backends). I see that sane was updated 2 months ago. <gabber>i also see that the backends for these packages have changed with 54a91b7a back in june <gabber>but i'm like 40% sure that i have used my scanner since then <nckx>If you mean the rename, that was just a Guix package name change. <nckx>Not a different package. <nckx>gabber: Yeah, I didn't check the sane release notes, but it's the *most likely* place to start testing. <nckx>Although it's also possible that Guix unintentionally broke some backend :) <nckx>gabber: What's your scanner? <gabber>kestrelwx: didn't notice anything but haven't used it exhaustively today <gabber>ACTION wonders if adding the "kind: bug" label to the issue had merged it a bit sooner <civodul>Rutherther: so you have the reconfigure-then-halt problem where root is not cleanly unmouted? i think that bug was eventually closed and i don’t think i have this problem, but it’s never been totally clear to me what the situation is <gabber>Deltafire: you can't add the label? <gabber>i did it for you (i guess it could be a permission problem) <gabber>Deltafire: with your patch checked out, a simple `./pre-inst-env guix shell simple-scan -- simple-scan` does not trigger a rebuild <gabber>and neither xsane nor simple scan "see" my scanner <Rutherther>civodul: my line of thinking is currently that we never got rid of that bug, it just 'hid' - I think it's possible it is inconsistent what systems will have the bug, ie. the order of services could matter, what filesystems you have and such stuff. <gabber>but i guess i am doing it wrong? <nckx>Wouldn't you want to affect sane-service-type, i.e., reconfigure? <nckx>Reconfiguring with ./pre-inst-env is safe although you'll have to allow ‘downgrades’ and disable authentication if you're not a committer. <gabber>this is the first time i hear from sane-service-type <Rutherther>I don't think you need to allow downgrades, the provision is unknown for pre-inst-env <gabber>which might explain why it doesn't work but makes my wonder why it ever worked <nckx>Well, sane is just a collection of user-space ‘drivers’, not privileged, so it's not strictly required. Perhaps it's possible to omit the service entirely if you don't care about udev rules &c. but I've honestly never tried. <gabber>or it's just part of %desktop-services... <gabber>how do i mix ./pre-inst-env and sudo? <gabber>do i need a -E, i.e. `./pre-inst-env sudo -E guix system reconfigure`? <gabber>i don't understand. `./pre-inst-env guix shell --pure guix -- bash -c './pre-inst-env guix system reconfigure ~/config.scm`? <Rutherther>I am not sure what you are used to for running pre-inst-env, if a pure shell or a container. Container wouldn't work for this ofc. So that's why I am mentioning it <Rutherther>and running pre-inst-env outside of pure/container shell is not reliable - you will get your regular guix instead of the checkout <Rutherther>*might get, specifically in case you didn't compile everything <gabber>well... i guessed my setups and workflows are not really up to date. i more often than not do a `guix shell -D guix -- make -j $(nproc)` in my checkout. then i build with `./pre-inst-env guix build FOO` <gabber>Rutherther: unfortunately sudo does not work in that pure shell :( <Rutherther>right, just use the full path - /run/privileged/bin/sudo <gabber>this doesn't work: "no code for module (nongnu packages linux)" <kestrelwx>I think I get reconfigure+reboot on Btrfs without LUKS, unless I'm seeing the Btrfs file system check at startup for some other reason. <Rutherther>yeah, you need to add all other channels with -L for pre inst env <gabber>should i just merge the already approved patch? not sure i'm up for jumping the hoops right now just to test whether it works on my machine <Rutherther>note that you can also always just pull out of the checkout / fork <NaN23>flurando: Then maybe someday at an online event :) <nckx>gabber <merge the already approved patch>: OK from me. <nckx>But you should get comfortable with reconfiguring from git (either by guix pull'ing from your local checkout, which I recommend, or by more hacky means) regardless, it will come in handy when you want to contribute and/or test system stuff. <gabber>nckx: it's on my list. but for now i /just/ want to scan that document while fixing some legacy php code base for $dayjob (: <gabber>after pulling and reconfiguring, do i have to log-out and back in, reboot or something totally different to check whether it works now? just invoking a shell gives me the same error as before <identity>gabber: depends, usually you can just restart some service and/or relog <nmeum>I still haven't fully grapsed how I best deploy additional non-configuration files with Guix. For example consider a set of TLS client certificates, required by nginx. Would I deploy those via a custom etc-service-type (and make the nginx service dependend on that new service)? or: do I use a custom package for this and have the nginx-configuration depend on that package? <nmeum>hmhm, I guess I could also just use a local-file gexp directly in my nginx-configuration <Rutherther>civodul: I think I have understood cause of the unmount bug <flurando>if you could not use certbot -- aka you have manually kept a cert, in which case you can just extend activation-service-type <flurando>don't make a custom package for static certs, just make a custom service which extend activation-service-type. Run mantainese script in the service. <Rutherther>civodul: file-system-/run/user is a dependency of root-file-system-service and thus it is stopped when calling stop-service with root-file-system-service. file-system-/run/user failed. This failed the whole stop of root-file-system-type. What's the correct resolution here though?... <aargoli>I am lost in the docs and old mailing list threads, if I want to set a /etc/hosts config, what is the recommended way? use "(operating-system (hosts-file" ? <aargoli>I mean on GuixSD, ofc, not on a foreign distro <gabber>aargoli: i use (simple-service 'some-name hosts-service-type ...) <aargoli>tyvm, both of you! First time using etc-service-type. <gabber>btw, the name "GuixSD" is *very* vintage by now (: <gabber>i think you meant Guix System (: <gabber>apparently there was some talk about dubbing it the GNU System <JodiJodington>What would be the easiest way to wrap an existing package in a script? I basically want to spawn `qbitorrent` in it's own network namespace and have it start my VPN. The reason for this is that I don't want any other apps to use my VPN, that's why it needs to be in it's own network namespace that's specific to qbittorrent's environment if that makes sense. <gabber>JodiJodington: WDYM by "wrapping an existing package ina script"? have a script call a program of that package? <JodiJodington>yeah, similar to how many programs are really a small shell script that sets environment variables and then calls `*-real`, but the existing tools for this (i.e `wrap-program`) only seem to support setting environment variables <JodiJodington>I think what I'll do is just make a qbittorrent-wrapper package that pulls qbittorrent as an input <gabber>JodiJodington: does "just" write a script not work for you? <gabber>ah, you need to run it as a service? <JodiJodington>just writing a script would work and probably be easier, but I just want it to replace the existing qbittorrent package so it's the default. i.e running qbittorrent from my desktop environment will run my script instead <gabber>if you *really* want to go down that route, i'd suggest to first write the script, then package that script with your desired inputs and then include *that* package in your configuration <gabber>but i'm not sure packaging that is worth the effort <JodiJodington>yeah that's the plan, although I'm thinking a shell script would just be easier now yeah. <JodiJodington>maybe ill save packaging it for another day, it'd be a fun thing to learn how to do but it seems like it would be a bit tedious <rogerfarrell>Very basic question: guix describe should match the commits of the last guix pull, right? <gabber>rogerfarrell: `guix describe` describes the checkouts of the profile guix is invoked in <gabber>is there an unexpected mismatch? <rogerfarrell>I assume it is an issue with my understanding of guix profiles, but yes. I have defined channels in my system and home configs. They are describing to desired commits. However, I cannot get a plain guix pull to change commits. Currently, my guix system/home match. plain guix pull is stuck at an old checkout. <gabber>we had an issue some time ago where when you pulled to the wrong commit you got stuck there <gabber>rogerfarrell: i think `guix time-machine -- pull` or something along the lines resolved the issue... let me check <Rutherther>rogerfarrell: what does "type -p guix" tell you? It should point to "~/.config/guix/current/bin/guix". Also do you see in the guix pull output that you are updating commits or are you staying on the same ones? <ieure>rogerfarrell, Yeah, build is broken for that package on your commit. <rogerfarrell>Ah. Wow. As a total noob, I thought for sure the problem was me. <mwette>Rutherther: 4ipai22sy68bklv8vcg2r20i6f1r89-coreutils-minimal-8.32.drv <Rutherther>mwette: how exactly did you 'describe' commits in system and home configs? <rogerfarrell>I am definitely stuck on a single commit. I will try time-machine. <mwette>Rutherther: There are no configs, I think. It's been a while since I played w/ guix. I installed the binary, started up guix-daemon, then ran 'guix pull'. <mwette>I set up all buildgroup and users etc also. <Rutherther>mwette: so this is 1.4.0? or what commit are you on ... "guix describe"? <Rutherther>yeah that seems like 1.4.0, hmm. That's a pity. Not sure if there is anything you can do about that other than using a newer guix <mwette>Rutherther: It's nice to have you around! <Rutherther>mwette: in case you don't have substitutes enabled you might also try that, because sometimes your machine might not be powerful enough (and the test can have timeout) / there might be reproducibility issue. I am not sure about this particular derivation <rogerfarrell>Rutherther, gabber, "guix time-machine -- pull" seems to have done the trick. Thanks very much for the help! You can imagine what confusion this would cause for a hobbyist like myself who is just starting to believe he understands guix fundamentals. I was re-reading the docs frantically trying to figure out where I went wrong. <gabber>rogerfarrell: would you mind telling us what exact commit you were when you got stuck? <Rutherther>"guix time-machine -- pull" wouldn't solve the bug gabber had in mind <Rutherther>that's a commit from a few days ago. That one is not buggy <rogerfarrell>Hm. "guix pull" was stuck on that commit. "guix time-machine -- pull" did get it to update. <gabber>if you persisted commit hashes in your channels file, then i think i know why pulling didn't update the profiles <aargoli>(simple-service 'hosts etc-service-type (list `(("hosts" ,(local-file "hosts"))))) <aargoli>I am a newb at guile, but shouldn't this have worked and read the config from a hosts file in the same directory? <Rutherther>aargoli: you would have to disable the hosts-service-type if you used that <aargoli>uhm, I don't have it enabled, so I guess you mean it is enabled by default and I need to disable it? <Rutherther>you can also instead use hosts-file field of operating-system, though it is deprecated <rogerfarrell>gabber, I have not pinned a commit for the default guix channel. <aargoli>Rutherther: what would you recommend best? <aargoli>I want to list a few servers that are accessible only via my vpn, so I don't have to type IPs... <Rutherther>aargoli: depends on what's your goal. If you do not need to use a file, extend the hosts-service-type. If you really must, I would probably use the hosts-file for now and switch to removing hosts-service-type after it gets removed (that might still take a lot of time) <aargoli>if I were accessing them only via ssh, .ssh/config would do, but they have web interfaces that I rather just use a name to access.. <Rutherther>aargoli: you're aware that hosts-service-type creates the /etc/hosts, right? So if you used it you would still have the servers accessible through dns <aargoli>reading on it. the docs are kind of useless (or I just cannot find the right page) regarding hosts-service-type <aargoli>yeah, this makes a lot more sense, great! <aargoli>it worked, thank you so much. I was inadvertently looking at 1.4.0 docs, and this feature was documented only on devel <zeropoint>hi guix, is there a way to force a guix deployed system to have the same version of guix that the deployer has? <ieure>I guess I haven't used `guix deploy', but I sort of figured it had to work like that already. <Rutherther>zeropoint: depends on what you mean by that specifically. You can set guix field of guix-configuration in the guix-service-type to (current-guix) and then you will get the same guix in /run/current-system/profile/bin/guix <zeropoint>my guix describe on the target machine is old and I find myself wanting to use guix shell on the target machine every now and again <graywolf>Hi :) Is anyone here using Guix for producing container images? How you go about creating home, setting environment variables and such? <ieure>graywolf, Have you found the manual section covering `guix system image'? I think the typical usecase is to spawn Shepherd services inside the container, using the normal Guix System service facility. <graywolf>ieure: I did not look at that, but from your description that does not seem like it would mesh with Kubernetes very well... <graywolf>I can probably just do this in two phases (guix pack -f docker, podman build from that image), but was curious if there is more native way <ygrek>how to update local "guix index" without doing actually updating packages? ie i want `guix search` to search what is currently available without updating everything as `guix pull` does <ygrek>or in apt words how to do `apt update` and not `apt upgrade` <Rutherther>pastor: I believe even git crates are handled by the new guix import. Or are they not? <ygrek>nckx, guix pulls builds derivations and it takes a lot of time after actual fetch from git repos is done <Rutherther>guix pull does build derivations, specifically the dependencies of guix and dependencies to build profiles etc. But it is the most close to apt update <nckx>There's no separate command to query the git repository sources as if they were a database. <ygrek>what if i do `guix pull -n` ? will the search use updated "package index" after that <pastor>Rutherther: The thing is that I'm making a package which specifies some dependencies in the parent Cargo.toml and in a workspace they specify them like I've show. The build fails because, althoug the 'guix-vendor' directory is properly populated, it seems Cargo does not resolve those dependencies localy. <ygrek>or if i ctrl-c during building derivations <Rutherther>ygrek: no, as I said the build of derivations is to build guix itself. You need to build guix to know what packages are in it <Rutherther>pastor: oh so they are workspace dependencies? Those are indeed handled specially and it's described in the cookbook <nckx>Building the ‘package index’ implies building most of Guix anyway, and there's currently no option that I know of to skip the remaining minority. <ygrek>so "build guix" is not like "build guix binary" but also like "build package index" <Rutherther>there is no guix binary, it's a wrapper for loading compiled scheme files. Those compiled scheme files include the available packages <nckx>Guix is a programme (or library so you will), not a database. <ygrek>another qn, i see there is no python 3.12 or 3.13 in guix or gcc 16, is there some place where to track when they will be available / why <ygrek>Rutherther, thanks, this makes sense now <nckx>There's no separate index you can download. The ‘index’ is generated by partially building & running the programme. <ygrek>nckx, understood now, thanks <Rutherther>there is python 3.12, named python-next. But no python-* packages for it. Not sure where to track for an update <ygrek>why is it called -next and not regular python@ version? <pastor>Rutherther: I don't find that section of the cookbook to be particularly informative <nckx>ygrek: Because it's not ‘the python’ for the distribution at the moment, the Python that everything is built against by default. <nckx>There's no technical reason it couldn't be named python but it's a social convention to make the CLI experience a bit more clear. Otherwise ‘python’ on the CLI would always default to a newer python than the distro default. <nckx>I.e. ‘guix shell python python-foobar’ → very unintuitive version clash. <pastor>Yes, this is what I've read but I find it confusing <Rutherther>what part is not clear then? or where are you stuck? <pastor>In that line you will see that there is a dependency of the `vm-bindings' workspace defined through the URL mechanism. <ygrek>nckx, i hoped i can have mutliple versions of python and use them to build different venvs with non-guix managed deps. from your comment i understand it is necessary to have kind of "system" python so that all the other python-* packages work with it - makes sense. <Rutherther>pastor: yes the "git =" that should be replaced with empty string according to the cookbook page <pastor>Rutherther: where did you find that part? <Rutherther>in the niri package use-guix-vendored-dependencies phase <Rutherther>the rev might have to be replaced with a version, but I am just guessing that <pastor>That phase seem to do it at the top level lockfile <Rutherther>so for this specific case it should be replaced with "cc = { version = "*" }" <pastor>Ah, yes, I meant that. But then, I should do that for the workspace member toml file <pastor>Rutherther: Alrgith, thanks! I will try that :) <Rutherther>yes, in this case seems so. Niri specifies dependencies on top level. Maybe it would be worth it if the cook book covered various examples and not just one <pastor>Rutherther: Seems you are right, now I need to repeat for the gazillion dependencies, how I hate build systems that allow to fetch from URLs :') <Rutherther>it's not the urls here, it's just workspaces. import of git = deps should work for standalone libraries <pastor>Rutherther: do you mean that those are picked for the lockfile by the importer? <pastor>Yes, I've noticed that. At least there is that <nckx>ygrek: I'm not sure that's what I meant. We don't *need* a single blessed system python, but there *is* one for maintenance sanity. The -next is a naming convention to prevent surprises in the common case. I don't know how venvs work, but you could create different independent Guix profiles (e.g., ‘guix shell’) with a different python version inside of each. <rogerfarrell>Am I correct in supposing that "sudo guix pull" sources from /root/.config/guix/channels.scm? <Rutherther>yes and fallbacks to /etc/channels.scm as for any user <rogerfarrell>Thanks for confirming. Why might "sudo guix describe" yield different channels from "sudo guix pull -l"? <Rutherther>sudo guix describe still uses your user's guix, sudo passes PATH <Rutherther>you would have to log in as root through login shell or do "sudo -i" <rogerfarrell>Is there any reason why I would need to keep my root guix package updated? All commands run from my user will default to using that guix instance, right? <Rutherther>rogerfarrell: are you talking about foreign system or guix system? <Rutherther>rogerfarrell: then no, if you run everything as your user, root's guix is never used <rogerfarrell>I was under the impression that the guix daemon was built using /etc/guix/channels.scm and was separate from the root instance? <Rutherther>no, not at all /etc/guix/channels.scm is for guix pull, it's the default 'system' location guix pull uses. That's the only thing /etc/guix/channels.scm is for <Rutherther>guix-daemon version is based on the guix field of guix-configuration of the guix-service-type <rogerfarrell>Aha. I have configured "(guix (guix-for-channels %rf-base-channels)". So, is there any point in doing a "sudo guix pull"? <Rutherther>that uses the guix you are using for the build, so your user's guix if you are reconfiguring as user <rogerfarrell>I am. So, at this point, my user guix + user channels is being used to generate my system, which generates the system-wide guix daemon. Is that right? <nckx>rogerfarrell: That is right. The average user need never to guix pull as root, ever. Even unaverage ones, probably. <nckx>Guix's sudo keeping your user's PATH is the secret sauce here. <ieure>I pulled as root last week, and was unhappy about it. It was a new machine which I somehow managed to install without a user account, and ended up pulling as root to reconfigure to add my actual user. <ieure>Agree that it should basically never happen. <nckx>I've previously argued that it Guix should warn (and maybe require some form of confirmation) when new users run their first mistaken ’sudo guix pull’ but that is perhaps extreme. <nckx>But with muscle memory from other distroes it's inevitable. <nckx>I think the worst permission-based gotcha was fixed instead. <nckx>(Users being stuck because part of their guix is now root-owned. I don't remember. Long ago.) <rogerfarrell>nckx, That makes a lot of sense. It seems way more ergonomic. The docs are great, but I was really struggling to get the big picture here. Thanks everyone for setting me straight.