IRC channel logs
2026-03-13.log
back to list of logs
<apteryx>is it possible to install Guix System on a powerpc64le system? <ieure>apteryx, I don't know too much about PPC hardware, but I'm not sure the question makes sense. I think PPC64 is natively big-endian, but has a little-endian mode you can enable. <apteryx>to clarify, the question is: can I run 'guix system init' on such a system <apteryx>or are there things that would need to be adjusted/added to make this a possibility. I'm thinking perhaps boot support (can it boot using GRUB?) <apteryx>ACTION ponders why building grub-pc pulls clang in <apteryx>about grub-pc pulling clang, it's not its doing, that's probably qemu's doing <apteryx>(which grub-pc uses for its test suite) <apteryx>OK, for powerpc64le, apparently one can use grub-ieee1275, from what I'm reading <apteryx>I'm sure things looks a bit different now <efraim>apteryx: when we (it was me!) refactored some of the grub packages we didn't create a generic "grub" that Does The Right Thing™ per-architecture, so that's why we still have issues with grub-pc on non-*86 architectures <efraim>also I see you found the commit about clang and grub, that was a fun project :) <yarl>I think of making a git-annex-assistant-home-service and I wonder if I should make a git-home-service before that. <yarl>git-home-service purpose would be to clone repositories. <futurile>yarl: what's the situation when you want it, why a service rather than run the command? - something that's regularly cloned? <yarl>futurile: Well, that's only for the declarative situation. <efraim>IIRC there's a git command that installs a user systemd timer to regularly fetch a repository in the background so there's less to pull from the network the next time you return to that repository <yarl>I follow a handful of repositories and that's only to declare a home configuration with those in it. Then I got the same on the two computers I'm using. <yarl>efraim: That's not exactly for the pull thing. <yarl>And then there's git-annex-assistant. <futurile>so it's "set-up all my machines/environments with repos I use" <yarl>Either I configure the git/git-annex folders by hand, adding remotes, num copies, preferred content, etc. Then git-annex-assistant-home-service only runs git-annex-assistant on configured folders and runs git-annex-fsck regularly. <yarl>Or There's a git-home-service that clones-if-not-there and may setup remotes and other options and a git-annex-assistant that does what's above plus setting options (numcopies, preferred content, etc) <yarl>But I might be wrong in how I (think I sould) use guix, wdyt? <yarl>Another possibility would be that git-annex-assistant-home-service clones by itself, does configuration etc without a git-home-service. <futurile>I find with a lot of configuration systems the question is whether the ongoing effort of maintaining the configuration is worth it, compared to "just run the commands". <futurile>It's a lot of effort managing configuration in some ways - particularly if you have a slow cycle time - which we do in Guix - because you can't quickly experiment. <futurile>OTOH if it's something important/rare then it's worthwhile - backup is a classic for me - it's worthwhile keeping my configuration in a file because it's important and I'm worried about mistakes <futurile>so I guess the Q is - is this important enough that you'd be willing to edit a file and keep it "maintained" <yarl>futurile: The minimal service (only running git-annex-assistant + git-annex-fsck regularly) is "vital". I should start with this. <yarl>futurile: Also, what do you mean bu "slow cycle time"? <futurile>futurile: I mean generally doing things in a declarative system and Guix specifically is slow. Compare the time it takes to "vim .bashrc; <do something>; source bashrc" compared to "vim home-service; do something; run home service reconfigure". This is even more true of other parts of the system - some of it is endemic to configuration management system compared to "just do it", and some of it is <futurile>advocates for declarative and configuration systems always say they're better - and they definitely are - but there's an ongoing "tax" to this kind of maintenance. <yarl>interesting blog post btw <PotentialUser-50>The other day, while updating packages I noticed that Guix was running guile 3.0.11. But when I run `guile --version` I get 3.0.9. <PotentialUser-50>I understand Guix might have its own prefix but why wasn't my guile updated (even if it was not explicitly installed)? <civodul>hi PotentialUser-50! where does your ‘guile’ binary come from? <civodul>if you do ‘guix shell guile’ or ‘guix install guile’ now, you’ll get 3.0.11 <ekaitz>hi! since my last update some GTK apps don't show with dark background, how should I fix that? <PotentialUser-50>civodul Indeed, the `guix shell guile` does provide 3.0.11. `which guile` yields `/run/current-system/profile/bin/guile`. Hmm... I'm a bit confused now. <gabber>how can i tell a cargo build to **not** try to download a crate during build? the source *is* downloaded and lands in the store during build but the build phase still tries to fetch it (which of course fails) <civodul>PotentialUser-50: maybe you need to ‘guix system configure’ with current Guix? <civodul>‘%base-packages’ refers to ‘guile-3.0-latest’ (3.0.11) <trev>ekaitz: you try gsettings set org.gnome.desktop.interface.gtk-theme "'adw-gtk3-dark'" (need to install that theme) or org.gnome.desktop.interface.color-scheme "'prefer-dark'" ? <gabber>are the guix yasnippets in our main repo somewhere? <trev>gabber: etc/snippets/yas <ekaitz>it only worked while our GTK version was lower than 4.11 <gabber>civodul: i know, i use them a lot! but they are outdated (i think) <PotentialUser-50>civodul Or maybe I haven't rebooted since I last ran the system upgrade. It might be that. <PotentialUser-50>That reminds me: when I last did a `guix system reconfigure` I saw kernel 6.19 available, but it went with 6.18. What could explain that choice? <futurile>Q: does adding a trailer to a commit actually close the PR on Codeberg? I'm using "Closes: guix/guix#4985" <Rutherther>futurile: no, it just serves tracking purposes for PRs. It closes only issues <futurile>Rutherther: ack, thanks (writes in notes) <Rutherther>futurile: also an unimportant technicality, PRs are meant to be referenced as !number, while issues as #number, though both work <futurile>oh really, ah ok, haven't seen anyone doing that <Kabouik>I have firefox-esr in my config.scm and it's taking forever to build. If it's not available as a substitute, I suppose firefox-esr no longer is the recommended firefox package? Should I just use `firefox`? I don't remember why I used the `-esr` variant but at some point I needed it. <futurile>it's ironic to me how easy working with Ruby Gems is compared to Rust Crates. And that the supply chain security of Gems is just better than Crates - super simple to check the SHA256 checksums <Rutherther>futurile: how does checksum check enforce supply chain security? And how are rust crates different in this? - there is also sha256 checksum of the source <futurile>Rutherther: it verifies one step, that what the maintainer uploaded is what I'm getting <futurile>Rutherther: doesn't verify lots of other parts (e.g maintainer is bad) <futurile>Rutherther: there's no checksum on Crates.io afaik <Rutherther>futurile: okay, so you mean that you compare the checksum against ruby gems website page? But if the attacker got hold of the account, they can also change the checksum, can't they? I still fail to see difference against the crates in this regard <futurile>Rutherther: there's a clear difference - you're arguing that it's not sufficient - there's no way for a crate author to tell me what they intended to upload - sure it's not sufficient (I agree!) - but it's clearly a step back with crates.io <futurile>Rutherther: and note that perl has this, lots of the other package repos have it - Github just introduced it on their releases (though it doesn't checksum the original source) ... <Rutherther>futurile: no, I am not arguing that. I do not really see the difference compared to crates.io, so I am trying to understand it. The crates are downloaded from crates.io directly, so even if there was a checksum, I fail to see what it would be giving you since if there was an attack, why would the checksum not match the contents <Rutherther>or what kind of attacks is this really meant as? I can imagine kind of attack where the files served by crates.io would be different from the checksum on their website if they used different servers to serve these which they could. So then if we're talking about something malicious being on one of the servers of crates.io, but not on the others, then okay <Rutherther>but I always thought most supply chain attacks are based on the maintainers accounts being compromised <trev>the checksum would only be useful if there is a MitM attack between crates.io and the user, i thought <Rutherther>trev: I don't think so. It would be only if it's between crates.io and the packager. The users are protected since we use the checksums of the source always. At least if we're talking about guix packaging here. But the checksums are obtained when importing. So at this point there could be issues. <trev>ah i was thinking without guix packaging <Rutherther>but yes, I also think so, only sort of MitM/when crates.io is compromised. But at these points I would be really surprised if only one part of the system was attacked, the one serving the files, but the one serving the checksums wouldn't... seems to me like very special circumstances <trev>also Cargo.lock files have checksums that will be checked when downloading from crates.io. Maybe that can "save" someone from downloading a newly compromised crate <trev>i think most high-security projects moved on from crates.io though <trev>private registries / vendoring crates internally <futurile>Rutherther: there are definitely significant concerns around supply chain security and the major distros. Packagers and infrastructure have a lot of measures. Also, as the major distros supply to governments you get a fine toothcomb put over your security practises. But, I think you're right the upstream side with so many projects is an easier target (e.g. xv last year) <csantosb>I'm looking at `guix size ciel`, a little cli app which takes 600 MB, almost nothing by itself, most of its weight is the depts it carries with it <csantosb>And this is only a little cli app; see for example #7098, try to add first column to understand my concern <futurile>there's not good tools for snipping the graph, or maybe howto's - like that shows gdbm, git-minimal, xv are they all strictly necessary? <csantosb>Installing guix and doing a `guix install ciel` will download the addition of first column (~13 GB) ? <csantosb>Ciel is just a little python app, by the way <Rutherther>it could since the profile hooks and propagations are used then, while guix size runs on the package, not at full profile that you obtain when you guix install. You could try with expression to see the full profile closure. But I wouldn't expect it grow so much. Especially since it doesn't propagated <jakef>a team for reducing closures could be neat <yarl>What are the limitations for shepherd service canonical name? <civodul>yarl: none, it just needs to be a valid Scheme symbol <civodul>janneke, ekaitz: do you have insight as to why gcc-mesboot1 takes so long to build? perhaps even ideas on how to improve on it? :-) <civodul>we were discussing it with pastor and wondering whether you had tips and tricks <yarl>civodul: I would like to construct such a name from a path. e.g. `(string-append "git-annex-assistant" (string-replace-substring PATH "/" "-"))` <yarl>But this is probably not enough <yarl>Well actually / is valid <yarl>(string-append "git-annex-assistant-" PATH) then <yarl>does PATH might containt invalid characters for symbol? <civodul>yarl: it should be fine; any string can actually be turned into a symbol with ‘string->symbol’ <civodul>even if it has whitespace for instance <yarl>I'll be possible to call herd status on those too? e.g. herd status \#\{foo bar\}\# ? <yarl>(or any herd command...) <yarl>missed a \ for the space I guess <yarl>well herd status "#{foo bar}#" ... <ekaitz>civodul: it's because it also supports c++ <ekaitz>i have a very interesting poltergeist here <evilsetg>Anybody knows why a guix system reconfigure prints indexing objects? I thought guix pull pulls the git repo and guix reconfigure uses that. But receiving/indexing objects is for when a git repo is pulled, right? <ekaitz>riscv binaries segfault when called directly via binfmt and when called with qemu-riscv64 they just work <civodul>ekaitz: but it’s also that it takes ages, sometimes to the point that you hit the 1h max-silent-time <ekaitz_>civodul: it might also be because we don't bootstrap flex and bison <ekaitz_>and we might be building from scratch over and over again idk <charlesroelli>Is there a declarative way to set a Guix system's FQDN? The command "hostname --fqdn" outputs "localhost" here <bjc>put the whole thing in 'host-name' <ieure>charlesroelli, You have some assumptions in your question. The hostname is typically just the host, and comes from /etc/hostname. The FQDN uses name lookups, so its result will be dependent on ex. your local DNS. <ieure>bjc, Probably the hosts-service-type with a FQDN entry will solve your problem. <ieure>The localhost is coming from /etc/hosts <bjc>some stuff, like idmapper, tries to extract domains from the fqdn, so i find it's justeasier to set it there <bjc>name search order is handled in resolv.conf normally <charlesroelli>Oh right, I found the documentation on hosts-service-type just now. Thanks, that seems like the way to go. <bjc>i mean domain lookup order. the "search" field of /etc/resolv.conf <charlesroelli>So I set hosts-service-type config to (list (host "127.0.0.1" "myserver.example.com") (host "::1" "myserver.example.com")), and "hostname --fqdn" returned "myserver" instead of "localhost". Halfway there! I then had to add a line "search example.com" in /etc/resolv.conf, and "hostname --fqdn" returns "myserver.example.com" as expected. <ekaitz>I need help with this qemu setup: I have the binfmt service active and the binary segfaults when running with it, but it doesn't when I run it manually through qemu <ekaitz>how can I know wich version of qemu binfmt is using? <ekaitz>well i think i found which one via htop <ekaitz>it's the -static vs non static qemu problem! <test202020>hello/ gnome users have accountservice in config? <ieure>test202020, Are you asking if gnome-desktop-service-type includes accountservice? <test202020>i try to solve problem with gdm login. latest master branch not solve that. i think maybe i lose some service <ieure>test202020, It doesn't appear to me that gnome-desktop-service-type includes accountservice. And I have no accountservice items in my /gnu/store on a machine with GNOME. <test202020>i have many Gjs-CRITICAL messages in /var/log/gdm/greeter.log <ieure>test202020, I see, accountsservice, not accountservice. <ieure>test202020, I was just going to suggest that you look for GDM error logs. <yelninei>bootstrapping a selfhosted compiler sucks. I now have 4 versions of the same patchset <test202020>ieure: i cannot find solusion for that... why another not have similar errors? <ieure>test202020, I don't know. If you add a second user, does it have the same problems? <test202020>anyway, that fail with login make gdm is broken. <bjc>i've got nixos and guix booting off the same partition courtesy of tmpfs roots <ieure>test202020, Okay, something is broken with your configuration. Try logging into a text console and renaming your $HOME/.config directory. <ieure>test202020, That ought to let you log in. <test202020>ieure: no, that not help. i try to remove .cache too <ieure>test202020, You will want to restore .cache/guix before you pull next. <ieure>test202020, That's not relevant. <ieure>test202020, I don't know; those are the two most obvious. <PotentialUser-8>Could somebody help me with my OpenSSH configuration? (My first message may not have gotten through.) <roptat>PotentialUser-8, it should disable password login. Did you restart the service? <PotentialUser-8>roptat: Perhaps not. I only `sudo guix system reconfigure`ed my config file; no explicit restart. <roptat>or is it "sudo herd restart ssh"? <ieure>PotentialUser-8, Reconfiguring doesn't restart services, because doing so can kill the session being used for the reconfigure. <ieure>So you have to restart things manually; or reboot. <ieure>I believe it will start newly added services and stop removed ones, but doesn't restart changed ones. But not 100% sure it works like that. <roptat>it will start services if they're not running (even if not new) <ieure>gabber, Hard to say, bisect from the last working commit to find what changed to break it? <gabber>still strange, though, since the package had not been touched in a while? <csantosb>Its dependencies have changed, probably ? <ieure>Guix rebuilds any time the derivation changes. <csantosb>By the way, another lonely soul in its own homeless module <ieure>And the derivation changes any time anything in the input graph changes. <gabber>csantosb: i thought it, too (: this needs fixing <gabber>don't we have a file-sharing module? <gabber>guess i need to upstream seafile finally just to create that module <ieure>gabber, I am also an occasional user of nicotine+. <gabber>i'm up for that. either we lack some good jokes or i don't get them (yet) <gabber>it brings some awesome y2k file-sharing vibes to my home <gabber>has anyone of you tried theesm's derivation diffing tool yet? <csantosb>There is a weird error during the check phase in nicotine+, related to a missing DRI3 device, but it builds <theesm>gabber: always appreciate feedback on the tool & suggestions if something's missing! (will also do a maintenance/cleanup release within the next weeks, it's my first somewhat bigger guile tool and it's been lots of trial and error, learning and exploring and all) <gabber>theesm: for that i'd have to try it first... but this nicotine+ issue seems like a nice opportunity... now how do i compare the last working build with the one that wouldn't (just before my fix)? <gabber>i guess a failed build does not end up in my store as a derivation, right? <theesm>it should, if a build fails the error message should say build of /gnu/store/$thing.drv failed and the .drv path could be passed to my diff tool <Rutherther>the drv is not a result of a build, it is there prior to the build <ieure>Correct, it's (more or less) a compiled version of the Guix package definition which the daemon uses to perform the build; the package is the result of doing that. <redacted>There are some store items in my store that don't seem like they should be there. How can I figure out which roots reference them? <redacted>I've also tried using `find $HOME -lname /var/guix/profiles/per-user/$USER/profiles/[hash]' to find references to some of my user profiles, but I'm not finding references to them. <redacted>Oh, looks like --referrers does mention the profile <redacted>Next mystery is why some of these profiles are hanging around. <redacted>Looks like I have system generations that `sudo guix gc -d 1w' isn't deleting. <ieure>redacted, `guix gc -d' only deletes home and guix generations, not system. <ieure>Also, you shouldn't run it as root. <ieure>Actually maybe only user profile and home generations. <redacted>Yeah, just noticed that while reading the docs. <ieure>Anyway, `sudo guix system delete-generations' is what you need. <redacted>ok I just freed 700 GiB of space. It's been gathering junk profiles for so long I forgot this drive was a terrabyte. <redacted>Well, I'm a little skeptical of 700 GiB since the store was only 450 GiB, but it'll be a lot. <redacted>Ah, right, maybe 700 GiB is without accounting for hardlinking <bjc>where's the guix installer code?