IRC channel logs
2026-03-12.log
back to list of logs
<nix33>Hello is dbus service a part of %desktop-services ? Or do I need to add dbus ? <ieure>nix33, It's in %desktop-services. <nix33>hmm so i have niri installed and tried to call waybar and it gives me an error [2026-03-11 19:25:23.728] [error] Cannot autolaunch D-Bus without X11 $DISPLAY <ieure>Isn't that telling you that you have no $DISPLAY, not that you have no D-Bus? <nix33>but niri is running in wayland ? <ieure>nix33, Well, that's probably why you have no $DISPLAY than. <ieure>I know nothing about waybar or niri. `sudo herd status dbus-system' will tell you if D-Bus is running or not. <czan>I can't explain that, but Niri can run X stuff if you have xwayland-satellite installed. That feels like the wrong solution to your problem, though. <nix33>maybe xwayland satellite doesn't get installed with the niri package ? <ieure>nix33, Is waybar giving you the error? Or something else? <ieure>ACTION is still happily ignoring wayland <ieure>nix33, It seems unlikely that waybar itself would need $DISPLAY. Is it possible it's launching something else which does? <nix33>doesn't look like xwayland-satellite is installed <czan>Presumably we could add xwayland-satellite to Niri in some way to make this sort of thing just work.\ <rebel1725>still suffering from the Guix System installation problem <trevdev>I somehow made the mistake of watching the codeberg repository and got slammed with 200 emails about all kinds of things <trevdev>I'm not mad about it though. I love that people are this engaged <rebel1725>still suffering from the Guix System installation problem <apteryx>lilyp: weird, gnome-music is currently broken, but changing tracker to tinysparql and tracker-miners to localsearch appears to fix it, though these should be the same packages (albeit deprecated variants) <apteryx>one small thing I saw after the GNOME upgrade is the 'Console' application having a distorted default font (supposedly inherited from the system) <apteryx>it looked like some monospace but spaced way too much :-) <apteryx>lilyp: from the release notes: "GNOME has a new interface font in version 48, as well as a new monospace font. Named Adwaita Sans and Adwaita Mono"; maybe we're missing these fonts in our default GNOME config? <lilyp>indeed, we should add font-adwaita to the same meta package that currently has cantarell, perhaps replacing it there <lilyp>(I'd say "add" for now, possibly removing cantarell for 50) <ekaitz>efraim: any idea for the rv bootstrapping? <ekaitz>i'm stuck on gcc-muslboot-4.6.4's libstdc++-v3 <ekaitz>and I think we have specific patches for it <ekaitz>also, it looks like the configure script is not able to link something <efraim>I think we should try switching back to the git checkout and a good-enough bison/flex to see if that's what's breaking things <ekaitz>because it does compile the a.out but then says: configure: error: cannot run C compiled programs. <ekaitz>efraim: is there a way that I can tell the configure script not to clean temporary files? <ekaitz>i want to be able to run that a.out and see what it tries to do <efraim>easiest might be to stop the build before 'configure and mangle the configure script to stop there <ekaitz>good idea with flex and bison btw <ekaitz>i don't know what live-bootstrap uses for that <ekaitz>but it might worth taking a look <efraim>I think they have a nice chain of rebuilding them, but for testing it out we can plop in one that hasn't been fully rebuilt <cbaines> /srv/documentation-center/ doesn't exist on guix-hetzner-2 <cbaines>the update-documentation-center timer has been failing since late Tuesday <cbaines>I've restarted the timer, but it's failed again <cbaines>civodul, is this something you're aware of? <efraim>can it be run by hand once to populate the directory? <rebel1725>still suffering from the Guix System installation problem <cbaines>efraim, I think it's broken, I'm not sure why that's caused the data from the previous run to be lost <futurile>rebel1725: hi - I suggest you email the guix-help list, see if someone else has run into your problem before. <futurile>rebel1725: I'd suggest you add some context to the problem, probably what you're trying to achieve and what you've tried <efraim>hmm, I have a package I'm reviewing, in bioinformatics, that demands at least avx2 <efraim>I can compile it without, and I can enable tuning, but does anyone know if it's possible to adjust flags in arguments based on if the package is tuned or not? <rebel1725>futurile: What I want to achieve is obvious - get my Guix System boot and working. <rebel1725>What I have tried is already stated in the text. <rebel1725>And about the mailing list - thank you, I will do it later. <civodul>ACTION will look into this doc.guix.gnu.org issue after lunch <allana>Hi #guix! Little question here. Is it possible to lookup an inferor package with a different output? For example I am trying to use packages->manifest with a list of inferior packages. One of those pacakges is "podman", it has an optional output "podman:docker". <allana>lookup-inferior-packages seems to optionally allow specifying a version, but no choice on outputs <allana>I think maybe there is something with inferior-package->manifest-entry, and I have been tinkering with this <ekaitz>efraim: is it normal that `environment-variables` is just a list of them without the values? is this new? or am I breaking the package build process too early? <efraim>I normally try to wait as late as possible so everything is setup for me. the values should mostly be set <ekaitz>but is it normal that they are just listed? <efraim>there's some code in the gnu-build-system to dump them out at the end of every phase <ekaitz>efraim: after configure step they are still unset? <efraim>they should probably be set by then <cdegroot>are there instructions somewhere on how to run a public mirror and what the expectations are in terms of storage/bandwidth? I've been severely hampered by lack of bandwidth to the existing mirrors so thinking of setting up something closer to home :) <cdegroot>But also "behind a wireless ISP", that may not help :-) <cdegroot>cbaines: you run the US mirror, not? How much bandwidth and storage are we talking about? <civodul>cbaines: weird thing is that /srv/documentation-center should always exist: if the timer fails, it won’t be updated, but it’s never supposed to be deleted <civodul>any idea if something might have deleted it? <civodul>or maybe it did exist but was a dangling link? <cbaines>civodul, I think I maybe tried ls, and that gave an error, but I was assuming it was a directory <cdegroot>cbaines: not as well as I'd like. Probably because of said wireless ISP. 2-4MiB/sec. Usually, no biggie, but I manage to nuke two systems I use for work the day before yesterday and rebuilding has been.... painful :-) <cbaines>cdegroot, running a mirror probably isn't going to help if you're limited by your ISP speeds <cdegroot>well, I can run a public mirror in Toronto and sync to a separate box locally as a "private mirror", is my idea. <civodul>cbaines: at Guix Days, we +/- agreed to make Collin’s service “official”; did you hear from them since? <civodul>cdegroot: you might want to give it a try, it’s in North America <cbaines>cdegroot, bandwidth depends on usage, and I don't believe the mirrors I'm running are used much. As for storage, you need at least 50GiB, and can add as much as you want <cbaines>if you want to mirror all the nars (which you should probably not attempt), that's 34TiB and growing <cdegroot>That would almost fit on my media server ;-) <cdegroot>Storage-wise, that's much less than I'd expected. Probably time to give it a look. All the nars would be doable on S3's intelligent tiering, $4/TB/month, but, yeah, not planning that. <cdegroot>(as soon as I have my spare loaner box back which I think has 2TB NVMe in it) <fred93>hi, the iso signature verification step in the guix system manual seems to be out of date <fred93>it tells you to import ludovigs signature, but the iso seems to be signed by efraim instead <efraim>fred93: yeah, we have to fix the manual for the release to ask for my signature <graywolf>Hello :) What is the earliest commit one can time travel to? <civodul>efraim: re signatures, could you open an issue and ping @guix/release? sounds like an important thing to fix <ekaitz>efraim: tcc-boot0 doesn't build in qemu :( (riscv64) <gabber>first time trying to package a rust application. i follow the instructions in the cookbook. i get "error: failed to get `f128` as a dependency of package". so i try to package the missing package, recursively. how can i tell one package to depend on another rust package? i tried to (cons* ) them together with the (cargo-inputs ) but that does not seem to do the trick <ieure>gabber, The new Rust packaging system doesn't use packaged dependencies. <ieure>I'm not sure if the cookbook stuff is current with that. <gabber>the cookbook is referenced from the blog post <futurile>gabber: you did the step where you got hold of the Cargo.lock and imported that into rust-crates.scm right <futurile>gabber: that can sometimes be the tricky step, because the upstreams change their dependencies a lot, I've messed up a couple of times when I've got the wrong version of the Cargo.loc <gabber>but let me retrace my steps and try again <futurile>gabber: I would double check that 'blah-app (whatever is in your main definition) has "f128" in it's list in rust-crates.scm <futurile>gabber: so the importer uses whatever is in Cargo.lock, so if the upsteam's repo still has it, then it is used. <gabber>and also available through crates.io <futurile>and is it showing in the list for "surfer" (or whatever you called it) in rust-crates.scm <futurile>ok, I would guess you grabbed the wrong Cargo.lock file (e.g. not the one for the version you're trying to use) or for some reason it didn't insert it properly. You could try again - that's what I've been doing - and I've messed it up every conceivable way in the last 5 days <gabber>futurile: thanks! i'll get there, eventually (: <gabber>it looks so good at first (it starts to build) but still fails to "load source for dependency `f128`"... hrmpf <gabber>so i add f128 manually, it looks just SO good, but then fails (again) for libsurfer <efraim>gabber: did you clone the repo recursively? <gabber>i think that's what i'm missing! <gabber>if i had a penny for every time i tried something (like pulling the package sources recursively) without changing the hash and being puzzled about nothing changing i had a couple of hundred pennies <gabber>futurile, efraim: thank you for your input! <allana>I feel silly, I really need to get better with the repl. I asked a question a little while ago about using inferior packages with outputs in manifests, and it took my a little longer than I should have. In short it's something that can probably be figured out easily in the guix repl, but I had a bit of a trial and error to get there. My struggle was with the difference between what goes in a manifest list vs a list for <ieure>allana, The dynamic typing struggle. <vagrantc>hrm. my guix system with btrfs root seems to be unable to make symlinks with a no space left on device error, but copying files works fine ... this is, obviously, a big problem for guix :( <ieure>vagrantc, brtfs copies share the same underlying storage, right? So I think it only has to allocate an inode. A symlink has content, to it has to allocate an inode and storage. <vagrantc>i didn't think btrfs created reflinked copies by default... <ieure>I've seen the opposite plenty of times (lots of data space, but ran out of inodes). Used to use it as an interview question. <kestrelwx>I've seen a lot of people run out of inodes on ext4 when first installing Guix. <vagrantc>i do not even know how to see the inodes on btrfs <ieure>vagrantc, `df -i' doesn't work? <ieure>vagrantc, Maybe you need to balance the FS? I don't run btrfs, but I believe that's a thing. <vagrantc>i can apparently create new files (e.g. cat somefile >> newfile) which should avoid sharing the blocks, i think... <vagrantc>ieure: could be ... i am fairly new to btrfs <ieure>vagrantc, What does `dd if=/dev/random bs=1M of=newfile' do? <vagrantc>dd if=/dev/random bs=1M of=newfile count=100 ... worked just fine <vagrantc>so i can create regular files like no tomorrow, but symlinks, no dice. <kestrelwx>I was fortunate enough to not have to think about the filesystem once in the 2 years on a btrfs install. <rovanion>There's no way to pack a package without its dependencies, right? For `guix pack -f rpm -R -S /usr/bin/hello=bin/hello hello` to also not pack in gcc and glibc? <kestrelwx>I think the admin tools for it are in `btrfs-progs`. <rovanion>ieure: Thanks. Back to writing a spec-file then I guess. <ieure>rovanion, The Guix built binary is not usable anywhere else, its ELF header points to the specific store items it was linked against, which definitely won't exist on anything not running Guix System, and might only exist on accident on Guix System. <futurile>vagrantc: maybe you have a lot of snapshots? or you could try rebalancing after checking whether there's a problem there I guess: sudo btrfs filesystem usage / <vagrantc>futurile: no snapshots as far as i know... <futurile>ack, I have a lot of notes on btrfs but not much insight. Mostly where I've had problems it's been due to running out of space it reserves for metadata (whatever the technical term is) and a rebalance helped <futurile>snapshots are worth it to me, but yeah I live slightly in fear of it <bjc>is it safe to mount /gnu nosuid,nodev,noexec? <ieure>bjc, I think everything will break horribly if you use noexec. <bjc>hmm, yeah, noexec won't fly <bjc>but nosuid and nodev <ieure>nodev for sure. I think suid stuff doesn't end up in the store. <bjc>yeah, there's the privileged-programs area for that <bjc>i'll flip it on and see if anything breaks <vagrantc>futurile: yeah, ran out of space for metadata <vagrantc>well, grew the partition and resized and now i get to learn about btrfs balance :) <civodul>ACTION wishes they didn’t know about ‘btrfs balance’ <vagrantc>i forget how long ago i switched this system over to btrfs ... i think maybe at least a year before i had to learn about any of this fancy stuff <bjc>i've been using it for longer than that and still know nothing =) <vagrantc>so ... where was i with those kernel updates... <vagrantc>i typically avoid guix gc until i really need it ... and usually after building a kernel update where i have a bunch of stuff in the store i do not want "guix gc" to collect but ... in order to move forward i have to clear some space so <vagrantc>and then i aggressively remove a bunch of stuff and wait for the cycle to repeat <rovanion>ieure: Thank you for the explanation. I thought they perhaps could be built to use a normal "interpreter" or ld.so. <ieure>rovanion, Not within the Guix build system. And if you're not using that, or are substantially subverting how it works, then IMO there's no point in using Guix vs. hand rolling a container or something. <csantosb>Hi ! I'm surprised to see how `guix weather nextpnr` returns no results; binaries where built 3 hours ago <vagrantc>it took something like 2-3 days for the substitutes from the last kernel-updates branch to become available ... e.g. CI built them ... and 2-3 days later the substitutes were available :/ <vagrantc>i guess i exadgerate ... the were built ~42 hours ago, and as of ~12 hours ago they were not yet available as substitutes (though they are now) <vagrantc>still ... long time between successful build and substitute availability... <csantosb>Ok, I guess there is a good reason for that. Not unusual, then. <csantosb>No idea: I know nothing about Guix backend. I was just expecting substitute availability to be instantaneous, I guess it takes time moving data around, periodic syncing, db upgrading, this kind of things. <vagrantc>csantosb: well, not sure there is a *good* reason ... <vagrantc>i do not recall this used to be the case ... i used to see substitutes be available quite soon after the build completed (sometimes within minutes) <csantosb>This was my impression, but I didn't check for a long time until today <csantosb>For the context, I just needed to check the upgrade, in case #4619 is fixed once for ever <philippe>Hi guix! I am running into a strage error with package refresh. <csantosb>See "22.2 Building from Git", in the doc <ekaitz>efraim: in qemu tccboot-0 fails when using binfmt but when running qemu directly doesnt... something weird is going on here <rogerfarrell>How are you guys managing secrets? I am looking for a declarative solution, but everything I have encountered so far feels ad-hoc. (SOPS-Guix is a notable exception.) <ekaitz>any idea of why I cannot guix pull anymore saying it can't produce the output path? <ekaitz>log says > (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (guix)) (value #f)) <ieure>ekaitz, Can you paste the full error? <ieure>ekaitz, Might want to include the output of `guix describe' and `which guix'. <ekaitz>paste debian doesn't let me paste :) <ekaitz>i'll ping you back ieure after trying a reconfigure (thank you <3) <ekaitz>this might explain the qemu issue <ieure>ekaitz, Something in your channel is referencing a `guix' variable which isn't bound. <ieure>This can happen when the guix channel changes things, and the package deprecation GCD is relevant. But same basic cause as ex. nonguix breaking because a linux-libre version was removed. <ekaitz>so maybe something has been moved to another place? <ekaitz>how do you debug this in the easiest way? <ieure>ekaitz, Couple approaches. Most reliable (but kind of annoying/slow) is to `guix pull' without the offending channel, then launch a `guix repl' and load any files from your channel mentioning a `guix' symbol into it, until you get an error. Then debug. <ieure>ekaitz, Or if there aren't many places the symbol is referenced, you can use grep and logic. <ekaitz>i don't use guix much in my channel <ieure>Easier with a less common symbol than "guix" though. <ekaitz>i mean, i use it only for use-modules <ieure>Ah, maybe one was renamed? I'd think that is very uncommon, though. <ekaitz>ieure: i got this! error: guix: unbound variable <ekaitz>hint: Did you forget `(use-modules (gnu packages package-management))' or `#:use-module (gnu packages package-management)'? <ekaitz>but I don't know in which file lol <ieure>ekaitz, Can't be that many places in your channel where `guix' gets used as a package? <dajole>I'm currently using stow to manage my dotfiles in a version controlled directory. The Guix manual describes a way to integrate that with guix home, using home-dotfiles-service-type. However, it also makes it sound like it's not the recommended way. E.g. what is the benefit of using home-xdg-configuration-files-service-type over just pointing guix home to my stow directory? Just trying to wrap my mind around all this. <futurile>dajole: if you're happy with Stow you don't need to do that. <futurile>dajole: I think the manual is trying to explain it from the perspective of there being two different "systems" you can use to store the dotfiles (flat or hierarchical), so that's why it's talking about Stow <futurile>dajole: you could always skip doing that and not use the service, use other parts of Guix Home and come back to it later <dajole>Btw, I have come across your blog posts a bunch of time and found them helpful, so thank you for those, too!