IRC channel logs
2025-05-09.log
back to list of logs
<PotentialUser-24>Hi. So uh i recently installed the GuixSD and my "$HOME/.cache" is owned by root for some reason, is that normal? I would guess not because i cant run "guix pull" due to not being able to create "$HOME/.cache/guix" I assume the fix would be changing the perms of .cache but i wanted to confirm whether thats intentional or not <vagrantc>PotentialUser-24: definitely not how it should be, but thre are a few ways that that could happen ... <vagrantc>PotentialUser-24: should be able to just delete it <vagrantc>PotentialUser-24: a fresh Guix System installation? <PotentialUser-24>vagrantc aight, guessed as much, just wanted to be sure it wouldnt mess up some guix assumption or something. <PotentialUser-24>And yeah, a fresh installation. I think the only thing i did different that could have caused this is modifying desktop-services to not have a display manager and xorg socket services <vagrantc>main likely thing would be running "sudo -E guix pull" or something <PotentialUser-24>vagrantc well the only thing i ran like that is a system reconfigure but i doubt thats it, but the fix was simple enough. Now to discover why i boot directly without a grub menu "grub-efi-removable-bootloader" *should* have the menu right? or is it only the non-removable option <vagrantc>sudo -E guix system reconfigure might trigger it as well <JodiJodington>trying to run guix gc and it gives me multiple "cannot read potential root '/var/guix/gcroots/auto/*' errors and then exits with exit code 1. I tried rebooting and that didn't help <apteryx>Rutherther: hi! I'm not sure if you saw it, but I sent the etc-profile-d-service-type and etc-bashrc-d-service-type patches for review <meaty>Are there any good guides out there on creating a hetzner VPS running on guix? There's a manual entry for "guix deploy" but that seems to assume guix is already installed on the server <sturm>I suspect that I had issues migrating my Guix System to the unpriviledged daemon some weeks back. Should I have a "guix-daemon" user in /etc/passwd and who owns /etc/guix on a correctly configured system? Mine is showing "sshd" as the owner. <sturm>(I've been looking at the "Migrating to the Unprivileged Daemon", docs but mine switch should have been automatic as I'm using Guix System) <apteryx>meaty: there's now a machine-type for hetzner, that should automate provisioning from scratch <sturm>meaty: I did try deploying with the hetzner machine-type after it was released but had some problems I couldn't get past <sturm>meaty: sorry was months back - I can't remember the details. Issues might be resolved now <orahcio>Hi, does someone have a config example of openvpn-client-service-type? <sturm>meaty: just tried hetzner deploy again and it appears to be working. Issue may have been related to permissions accessing the "ssh-public-key" which was inside ~/.ssh/. <sturm>hmm, just failed part-way through the install while building bash-minimal. Might be because I specified an ARM system <sturm>anyone using the "privileged?" config on their Guix System? I'd like to double-check some permission settings with you <lfam>I wonder how often or reliably the codeberg mirror of our Git repo is updated? Does anyone have a sense of this? <lfam>I'd like to set my Git remote's fetch URL to codeberg, since it fetches more reliably, but keep the push URL as Savannah. But this won't be productive if they are often out of sync <lfam>I know this will be moot soon enough <lfam>sturm: I don't know about the privileged? option, but I saw your message in the logs about ath9k. Is that still a problem for you? <sturm>lfam: thanks, yes still an issue, though I noticed a message in help-guix which put me on the trail of "privileged?". You're not using "privileged? #f" I take it? <lfam>Tbh I don't remember what that is. Can you point me to its documentation? <sturm>See "11.10.1 Base Services" and "guix-configuration" which describes "privileged?". Unprivileged guix daemon was recently added and announcement suggested that #f might become the default eventually. <sturm>I preemptively switched over in my system config, but I think something's not right with ownership of /gnu/store /var/guix and /etc/guix now <sturm>it looks as though the user-ids have been shuffled because I'm getting the "sshd" user owning files in /etc/guix for example. <lfam>Anyways, that sounds like a bug in updating the manual <lfam>I think it's likely that something broke wrt to your firmware <lfam>Did you test this hypothesis by using the exact same system, but only changing the 'privileged?' option? <sturm>lfam: I've tried reconfiguring with and without this option and doesn't seem to help. The issue feels "stateful" in some way, as though my system is stuck in a bad state, hence my suspicions about permissions. Not something I'd ordinarily consider in Guix. <lfam>The system has some statefulness unfortunately <lfam>What are the permissions of the directories you mentioned above? <sturm>Files under /gnu/store are r--r--r <sturm>sorry, owned by user "971", group "sshd" <lfam>I wonder if this is related <lfam>I'm surprised that only the wifi is broken, tbh <sturm>oh, there are some files there owned by root:root. I wonder if I need to just `chown -R root:root` on /gnu/store /etc/guix and /var/guix. <apteryx>looks like it's getting 502 from our Savannah git repo <apteryx>Git error: unexpected http status code: 502 <apteryx>maybe I can reconfigure to point to our codeberg mirror <nomike>I'm regularly getting a 502 from the git repo. Usually works after 1-2 retries. <lfam>It's hardly unexpected at this point <lfam>sturm: You could try it, I might try it if it was me. I can't guarantee that it's the right thing <lfam>If you're able to snapshot the filesystems first, I'd recommend that <lfam>How does one join the Guix group on Codeberg? <lfam>sturm: I know the new unprivileged daemon uses some special Linux features to access these files, so it might be the file modes (r--r--r for example) are somehow not what they seem <lfam>I don't really understand it yet <sturm>much appreciated, thanks lfam <nomike>There is basic-shell-tools.scm which adds "zsh" to the config. basic-workstation.scm uses that. In the very similar developer-workstation.scm the use of basic-shell-tools is commented out. <nomike>home-config.scm is the entry point and it uses both basic-workstation and developer-workstation. <sturm>meaty: my guix deploy to x86 Hetzner worked beautifully - I'm now running Guix System on a remote VM. Only issue is Hetzner doesn't have datacentres in Australia :( <nomike>The code as it is now works. But once I uncomment the use of basic-shell-tools in developer.workstation.scm:2, `guix home reconfigure -L '.' home-config.scm` fails with "error: basic-shell-tools-packages: unbound variable¨. <nomike>Any ideas of what I might be doing wrong? <apteryx>sturm: neat! I wonder if we could add a machine-type for OVH <lfam>I'm not a strong Schemer, but it is okay to use append like this? Without actually appending to anything? <nomike>I guess so. Additionally, if I comment out the use-above, it works again. Without changing anything in the append. So that pretty much rules that out. <nomike>And, judging from other languages with whom I'm much more familiar, it makes sense to be able to (append a b) without checking first whether b could maybe be empty. <lfam>It's a nice minimal example, thanks for distilling it down like this <lfam>I don't use `guix home` so I can't test it myself <lfam>What happens if you append to (specifications->packages (list "zsh")) in home-config.scm? Instead of importing and appending to developer-workstation-packages? <lfam>You could also ask this in #guile <apteryx>OK, the manual is not not building because of a recent change in the source code of Guix: 2025-05-09 04:16:04 error: texlive-local-tree: unbound variable <apteryx>the guix package used by the doc/build.scm to create the manifest needs an update <sham1>Using append with an empty list is very much valid, since append is specified in such a way that the final argument is the tail of the returned list <sham1>Hell, the final argument doesn't even need to be a proper list because of this <sturm>just an update - I was able to fix my wifi by adjusting the ownership of /gnu/store /etc/gnu /var/guix etc. to root:root, similar to "Migrating to the Unprivileged Daemon" in the manual. After this, I restarted NetworkManager and wifi is working again - phew! <sturm>I'm currently not using "privileged? #f" in my system config <sturm>see also the "I broke NetworkManager" thread on help-guix list <halloy4450>When I use `./pre-inst-env guix refresh --list-updaters` what does the coverage percentage mean? Ex `- github: Updater for GitHub packages (30.9% coverage)` can't mean 30% of all of github, so what is this a percentage of? <mange>I assume 30.9% of packages in Guix. <meaty>sturm: if you're still there, i'm having nooby problems getting my hetzner deployment working <meaty>I'm getting "SSH connection to ... failed: Connection refused"s, then eventually guile error messages saying "SSH authentication failed ... Failed to read private key..." <meaty>I have checked, the `ssh-key` I provided has all read bits on, and its containing dir also has its read and execute bits on <meaty>I assume that means the guix deploy process on my system is trying to read the ssh-key provided to infer ssh-public-key, as the docs say... <meaty>but manually specifying `ssh-public-key` in `hetzner-configuration` results in the same exact series of errors <meaty>This is with just using the base %hetzner-os-x86 operating-system, to eliminate other sources of error <meaty>does it matter that the keys on my system are id_ed25519 instead of the id_rsa keys used in the example in the manual? <meaty>well, it isn't a permissions issue; I tried again with my home, .ssh, etc. dirs all set to 755, still the same error sequence <ruther>meaty: private ssh keys shouldn't have all read bits, only the owner should have read bit. Otherwise ssh will refuse to work because of too open permissions <meaty>ruther: I'll try again with the permissions set back to what they should be then <yelninei>sneek later tell janneke hello, do you remember what the issues were with a crossbuilt mach? I would like to avoid bootstrapping both the 32bit and 64bit toolchains on core-packages-team <engblom>Would guix be good for this use case: <engblom>I would want to install a bunch of computers for libraries. Those computers will be used by the customers. <engblom>They should be more or less deploy and forget computers, meaning they take care of updating themselves. <engblom>They need an updated web browser, libreoffice, printing and scanning support. <engblom>And each time someone logs out, or whenever the system is booted, the home directory should be restored so no personal information can be found by the next user. <engblom>I have never used guix, but atomic updates would be great, as it reduces the risk of something going wrong during the updates. <engblom>Would it be possible to build a system that more or less for ever works (until the hardware breaks) without me doing manual maintaining? <engblom>Currently I am running Ubuntu, but many times unattended-upgrade fails on Ubuntu, and then I need to manually do release upgrades. I truly want a deploy and forget system, as far as it is possible. Of course I am prepared that I might have to fix something in the future... <engblom>So I would want to create a new and better system for the libraries. <csantosb>engblom: by updating themselves you mean an automated cronjob running `guix pull && guix system reconfigure` at 3 a.m., for example ? <engblom>csantosb: I have not used guix, so I do not know if those are the needed commands to keep the system updated for ever, but yes, a cronjob would be enough, or something in the shutdown scripts. <futurile>engblom: that's going to be a hard lift if you've never used Guix/Nix before. Are you up for having to learn how to deploy and manage a system through a completely different approach? And what's your time-line for doing it? <engblom>Does guix have "releases" and if it does have releases, would those commands update it to the next release? <engblom>futurile: I am able to learn. That I am sure of. As long as I know if guix would be the right tool for the task. <engblom>futurile: I would build a test system during the summer... and during the fall deploy them. <futurile>engblom: it's a rolling-release model, so no "xxx LTS" etc. You role the system forward, and advantage of the "declarative" model is that if something goes wrong you can easily roll back to the previous version - that's the big advantage <futurile>engblom: also note that mainline Guix _only_ contains free software, so that's fine for libreoffice etc, but for a browser you will probably need to use nonguix which is a channel (think of it as a debian repository similar to Ubuntu's nonfree) <engblom>I want a rolling-release and I want roll back in case something goes wrong, and I want to reduce the risk of something going wrong by having atomic updates. <futurile>engblom: it's generally nice property. I would say the declarative approach is good for managing multiple systems. It does mean a bit of overhead getting the configuration right, but then deploying to multiple systems is good because you have a "known good". <futurile>engblom: Nix has regular releases and it's a bigger community. Obviously you're in the Guix channel so we think Guix rocks ;-) <engblom>futurile: I am OK with using non-free in this case. The users will need recent versions of Chrome (or Chromium) and Firefox, as otherwise there might be too many sites not working. <futurile>engblom: yeah figured you'd need that - the majority of users also use nonguix for the browser at least <futurile>engblom: well the manual is very good, also on youtube check out systemcrafters where David has done some good videos <futurile>engblom: I think there's probably something to note in that. If you enjoy configuring systems then you can think of Guix as being like ArchLinux, so updating Chromium and sending a patch to Nonguix or building a version of a package yourself that meets your needs. If you're more into 'consuming' what the distribution gives you, then honestly Ubuntu is the best option, or maybe Nix. <futurile>engblom: I suspect with Guix you'd spend more time on building a config, less time debugging why an update/upgrade went wrong (which is where I think you are with Ubuntu). But you do get a lot of polish "for free" with Ubuntu that you don't get with Guix or Nix. <sturm>presumably that's because guix daemon doesn't have permission to see it in ~/.ssh/ <unwox>hi guix. does qtpositioning@6.7.2 build for anyone? i can't update my qutebrowser package because of qtpositioning build error. it started happening since i did guix pull yesterday <csantosb>I just `./pre-inst-env guix build qtpositioning`, which gives me "/gnu/store/mlihvginyj29ysymx55gfiwkqgzz6b2f-qtpositioning-6.7.2" <janneke>yelninei: sorry i don't remember the specifics of how using a cross-built mach breaks, just that cross-building produces a non-functional mach; possibly civodul remembers. why? <sneek>Welcome back janneke, you have 1 message! <sneek>janneke, yelninei says: hello, do you remember what the issues were with a crossbuilt mach? I would like to avoid bootstrapping both the 32bit and 64bit toolchains on core-packages-team <yelninei>janneke: I tried a cross built one for my test system on core-packages-team and have not noticed anything weird yet, it boots and I can offload as before. <futurile>Just put out GCD005 Regular and efficient releases for discussion on guix-devel - look forward to everyone's thoughts! <yelninei>same with the mach on master, i think the workaround might be no longer neccesary (at least for the 32bit version) <attila_lendvai>if i have created a channel, and duplicated the gnome-xyz.scm with a single package, and i cannot find it in `guix search gpaste` after a `guix pull`... then how can i debug this? <ieure>Yeah, you need to change the define-module to be (your-channel packages gnome-xyz) <attila_lendvai>but why don't i get any errors anywhere?! error handling in guix badly needs a cleanup... <ieure>attila_lendvai, What's the path to your file in your channel? It's likely not even loaded because it's put in the wrong place; hard to detect those kinds of errors. <ieure>attila_lendvai, The vast majority of bad error reporting experienced in Guix is because of Guile. Never really used Guile before Guix, and I found its error reporting to be shockingly unhelpful. <attila_lendvai>ieure, i've mirrored the guix repo as-is. i.e. there are two (gnu packages gnome-xyz). except that i've made a mistake and deleted the deifne-package, too. so it's a single toplevel define-public <attila_lendvai>ieure, guile's backtraces are indeed the main issue, but there's a lot of quietly swallowing exceptions in guix itself... <attila_lendvai>search for 'guard' and 'CALL-WITH-ERROR-HANDLING' to see the relevant commits <hako>attila_lendvai: there won't be two (gnu packages gnome-xyz) <hako>guix combines files from channels in the build process <attila_lendvai>hako, yeah, that was a thinko. but short of any errors i came here asking. <meaty>sturm was right, `guix deploy` requires that the SSH private key be outside of ~/.ssh . Isn't this a security risk? <lfam>I'm shepherding my first team branch through QA (kernel-team). Just two changes: an update to kexec-tools and bluez. Please test! <lfam>I can test kexec-tools easily, since we offer kexec reboot now. But I don't have a bluetooth workflow for my Guix machines <attila_lendvai>meaty, not sure what you mean. i'm using guix deploy on a machine, and i didn't change anything regarding ssh. i'm using dropbear instead of openssh, though. <lechner>Hi, how may I find a 'gcc-toolchain' input. This does not work (assoc-ref inputs "gcc-toolchain") perhaps because it needs to be versioned? <lechner>meaty / like attila_lendvai i'm not sure I follow <attila_lendvai>lechner, i think now you are supposed to use the search-input-file method instead (why isn't that called find-input-file, though?) <meaty>lechner, attila_lendvai: now i'm confused, lol. What else could be happening then? <attila_lendvai>meaty, sturm, oh, wait! my server is not pulled post the non-root daemon changes. so, ignore my feedback. <meaty>lechner: quoting my message last night: I'm getting "SSH connection to ... failed: Connection refused"s, then eventually guile error messages saying "SSH authentication failed ... Failed to read private key..." <meaty>lechner: these errors persisted until I generated a new key pair in a different directory and used that, then it worked fine <ruther>lechner: no, it's because gcc-toolchain is not in inputs <meaty>sturm had the same situation <lechner>meaty / thank I just found it. looks like a local error <attila_lendvai>IIRC there's some bug/discussion somewhere that the non-root daemon cannot read the .ssh/ files due to an unsafe permission error <lechner>ruther / and why wouldn't it be in inputs after I added it? <ruther>lechner: wait, sorry, the gcc is actually in inputs, I got confused by build-inputs, but build-inputs is actually passed to #:inputs. It's just that there is no gcc-toolchain. There is just gcc, libc, binutils. <ruther>that doesn't have anything to do with the daemon reading a key <auk>does this channel have a bot to leave messages for others? <auk>sneek, later tell hiecaq: relating to what you said about guix pulling source, content-addressed, from SWH -- i think i might have a conceivable exploit scenario <auk>The basic situation is this: select a few hundred midsize projects, create git mirrors of them (they can clearly identify themselves as mirrors -- no need to try to masquerade as the official repo), introduce malicious commits, and wait <auk>To move things along, once could conceivably post on forums with links to your mirror and/or referencing malicious commit hashes <auk>the exploit is, eventually someone may end up putting a malicious commit hash into a guix package <ruther>okay? How does that relate to SWH? <auk>this is what hiecaq said earlier: "TIL that if I incorrectly use a git ref that doesn't belong to the repo of the package, Guix will download the repo it actually belongs to from software heritage. A little bit scary tbh ..." <auk>for example, a guix package may define (repo_url, version_tag, commit_hash) -- but if the hash is not at repo_url, guix will pull it from SWH <auk>I think this is a useful feature, but it could cause problems when creating packages because (afaik?) the tooling will never alert the packager to the fact that the commit_hash is not at repo_url <auk>so the package definition gives the impression that it is pulling from repo_url, but in fact it isn't, and never was <identity>so it requires putting a commit to SWH and sorta kinda hoping a package maintainer stumbles? and then possibly going through a review where nobody notices that, until it gets into a channel? <auk>yep, exactly. But done at scale, it could be effective. And the tooling doesn't provide clear alerts to reviewers <ruther>auk: doesn't really seem like a new problem to me. It's very similar to stuff like the upstream repo being taken over by a malicious actor. The packager should be checking stuff like that. <auk>the only alert you get is what hiecaq experienced -- "huh, why did this pull from SWH"? <identity>pretty sure it says "fetching from SWH" in the build logs <dariqq>and you would also need to match the hash the FOD is expecting or am i missing something? <auk>ruther, my point is that the tooling doesn't facilitate the packager noticing their error <ruther>dariqq: auk is talking about creating a new commit, not replacing a current one <auk>i don't think people generally triple-check commit hashes the way they triple-check PGP fingerprints <ruther>auk: yes, that is the same with the repo being taken over by a malicious actor <identity>auk: you are being very generous about people checking PGP fingerprints <auk>because people generally think of commit hashes as paired with a repo URL. They don't generally treat commit hashes as a single-factor security pin. But guix does <auk>ruther, my point is that this does not require compromise of the original repo <auk>honestly this attack is very boring, but i think it's quite doable at scale <ruther>auk: I understand what your point is, what I don't understand is why it's relevant <auk>not sure what type of relevance you are talking about? my point is that the guix tooling treats commit hashes in an unconventional way, and i think there is a conceivable exploit scenario <auk>I think it would be solved completely by turning off content-addressed pulling during sensitive operations like writing/updating a package <auk>i don't mean to go in circles, just not sure which part to explain more <ruther>auk: did you know GitHub actually 'merges' all forked repositories, so that when you try to fetch a commit on the main repository that is available only in forked one, not the main one, you will get that commit? <auk>yeah i'm aware of that, and it's not great <ruther>auk: content addressed means addressed by the content hash, not by commit hash <auk>commit hash is a type of content hash, isn't it? unless i'm misunderstanding something <auk>mitigations suggested are apparently: (1) sign stuff and check signatures, (2) GH displays a warning banner on the web UI: "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." <auk>of course guix can't rely on sigs. Basically i'm saying the guix tooling should implement a warning banner like the GH one <ruther>auk: in guix content addressed means using the hash of the output contents. (doesn't have to be directly the hash) Commit isn't content hash. I don't know what terminology others are using. <identity>auk: so, "tldr: when fetching from SWH be loud"? <auk>i think this idea is also applicable to fetching source archives by file hash <auk>identity, tldr: provide config modes, sometimes fetch from SWH quietly; other times do not fetch from SWH at all (just error out) <vagrantc>yeah, given the number of times i see people say "just put the wrong hash in your packaging, run guix build, and then guix will tell you the right hash to use" in this community, i have very little faith in checking signatures and hashes :( <auk>it's probably also a generic QC/QA benefit for the tooling to alert packagers when a hash is not at any of the urls they listed <ruther>vagrantc: that is because the point of the content hash is not security, it's reproducibility <janneke>sneek: later tell yelninei: that's good news, chances are good that the 64bit then also works <mccd>Hey, I ran guix home reconfigure X and I'm noticing that it's building everything from source, like ffmpeg and more. Any clue why this is happening? It looked for substitute servers including https://ci.guix.gnu.org <identity>mccd: you need to give more information about your configuration to diagnose that. start with posting your home-config.scm and the output of guix describe to a pastebin <mccd>My suspicion is the codeberg mirror <ruther>mirror has no effects on substitutes <ruther>mccd: what is the full guix home reconfigure invocation you use? <mccd>guix home reconfigure ~/dev/guix-redux/home-configuration.scm -L ~/dev/guix-redux/ <mccd>Oh... I have a script that I was working on that I kept there just to have it in the same repo <mccd>And I moved it and now it's building way fewer packages <vagrantc>ruther: you don't get security without reproducibility ... so i cannot agree that it is *not* about security <auk>sneek, later tell hiecaq: also, different topic, i noticed you code with rust. I've been thinking about the idea of a `rust-toolchain.lock` with hashes as a lockfile for rust-toolchain.toml (analogous to Cargo.toml/Cargo.lock). Looking for others who might be interested in this idea, to discuss with.