IRC channel logs
2025-07-28.log
back to list of logs
<nomike>Deltafire, you should try PythonSCAD then. Same thing (direkt fork) but a few more features and you could use Python as a native language to write your designs. Sooo much more convenient. <Deltafire>will give it a go when your PR is accepted :) <apteryx>lilyp: gstreamer yes, libwaita needs librsvg 2.60.0 fixing (I'm trying to do this) <apteryx>2.60.0 is part of the core GNOME 48 packages <apteryx>I need to push a couple fixes I fixed yesterday <apteryx>I'll push what I have so far, including a WIP commit for librsvg <apteryx>done; commit c429ed96ead is the current state of things <apteryx>I guess I need to inport each crates' Cargo.lock individually, and specify the included packages via cargo-package-crates <apteryx>hm, attempted to rebuild librsvg 2.60.0 with rust 1.85, same error about edition2024, rust 1.82? I'm lost. <apteryx>perhaps that's because of the --locked argument; which used to be removed from Makefile.am in a phase that I had simplified out. <apteryx>ACTION tries doing with current 2.58.5. <Noisytoot>How do I modify rt_tables in guix? Just writing to /etc/iproute2/rt_tables doesn't work. It seems to be located in /gnu/store/sa13v5bq6crm3fiv1kvbvhqna7cpx2v9-iproute2-6.4.0/etc/rt_tables, which I obviously can't write to. <Noisytoot>Otherwise I have to refer to routing tables by number (since I can't give them a name), which is quite inconvenient <Kolev>Anyone run Nextcloud on Guix System? <Noisytoot>Also does guix seriously not include an IPv6 traceroute implementation by default? <Noisytoot>It includes GNU inetutils traceroute which seems to only work for IPv4, and also isn't setuid by default so doesn't work for non-root users <lilyp>apteryx: I'm p sure I built libadwaita successfully with an earlier librsvg… we should still update it, but there might be something else wrong <apteryx>I was told glycin requires librsvg 2.60, but as we don't have a package for that yet <lilyp>ahh, yes, we do need glycin down the road <apteryx>flipping-icons.ui and gtk-icontheme-sizing.ui tests consistently fail <apteryx>trying with 2 patches from fedora but have little hope <lilyp>did a dependency change? might be gdk-pixbuf… <apteryx>lilyp: just reverting its version bump to 3.24.43, it passes <apteryx>so it's something with the new 3.24.49 <lilyp>can we bisect gtk versions and use the latest that builds? <hako>apteryx: I'll take a look on rust-team <apteryx>I'll be interested to hear what you found, if anything :-) <apteryx>lilyp: I just force-pushed to gnome-team branch with latest fixes and cleanups. current failure is on libnotify <apteryx>nice! I had regenerated the lockfile here as well <apteryx>lilyp: disabling libnotify test suite to move on <apteryx>I tried to run it with dbus-run and an xserver, but it'd still complain about failing to send notifications <apteryx>can I replace tracker with localsearch for GTK 4 ? <apteryx>hako: thanks for taking a look! do you have further insights about that rsvg doc failure? <apteryx>lilyp: I suspect something's off on gnome-team branch at the moment because even tinysparql doesn't pass its test suite, while it's fine on master. <apteryx>one gnome-team the tinysparql test suite fails with errors like: gi.repository.GLib.GError: gi-invoke-error-quark: Could not locate tracker_sparql_connection_new: (null) (1) <hako>apteryx: looking through doc/meson.build, it uses gidocgen but we have gi-docgen, might be this. <deedend>Hi, I am trying to convert the HTML version of the Guix manual to epub, using pandoc (I've downloaded the html from the guix website). The problem is that, although it generates the ebook file, it always groups all the chapters together. I've tried to even split the html in sub-files (one for each chapter) but it still merge everything together as <deedend>a single file (no chapters). Any idea where the issue can be? <hako>apteryx: It's related to the fontconfig warning <PotentialUser-53>All I did is add `(service sddm-service-type (sddm-configuration (display-server "wayland)))` to my configuration <PotentialUser-53>It builds successfully, but upon reboot, I'm greeted with a blank TTY screen with a rapidly-blinking cursor in the corner, as if the screen is constantly refreshing <apteryx>haha, libnotify on master: No tests defined. <apteryx>so it's just that new tests were added. <deedend>Ok, so nobody I assume need/have an epub version of the manual... 😢 <PotentialUser-53>deedend: You can obtain a PDF version of the manual with `guix shell calibre -- ebook-convert guix.pdf guix.epub` <PotentialUser-53>(there's probably a more lightweight package to convert PDF to EPUB than Calibre, but this is the only way I know) <deedend>I am using pandoc, but it doesn't export the chapters. I shall try starting from a PDF, then calibre <deedend>ah dang, pandoc doesn't convert from PDF <Kabouik>I don't understand this propagated input error: https://0x0.st/85nt.txt My packages are up to date and I checked the package definitions: zathura propagates girara, which propagates gtk+, but gtk+ doesn't specify libxbcommon@1.6.0, just libxkbcommon, so it's not clear to me why there's a version conflict when I try to install libxkbcommon. <apteryx>lilyp: neat, we now have tinysparql and tracker fixed on gnome-team <charlesroelli>deedend: guix's documentation is written in texinfo, which can output directly to epub <charlesroelli>deedend: `texi2any --epub3 --output=guix.epub doc/guix.texi` should get you started <Kabouik>You should be able to select an older system generation from the GRUB menu <Kolev>This locale issue is making it hard to run a system reconfigure in tmux. <Kolev>Even manually setting the env vars doesn't work. <simendsjo>Kabouik: Due to guix gc cleaning up all but the latest generation, I cannot do this (even though I booted into an older generation to run the cleanup). chroot encounters the same issue as I mounted everything. So I need to somehow get around the fact that the running system is corrupt. <Kabouik>This probably goes far beyond my expertise then simendsjo, provided that I even have some expertise in Guix (spoiler alert: I don't). <gabber>after pulling and reconfiguring (post core-packages merge) i rebooted, logged in and now my shepherd is spinning up at 100% and not returning simple `herd status` calls (neither unprivileged, nor sudo). is it bad? what can be done? services seem to have spun up correctly and are working AFAICT <simendsjo>Kabouik: :) Thanks anyway. I'm thinking maybe I can do an guix system init from an installation media without loosing everything on disk, but I have to look into what that command does. <jlicht>skip the nick, the greetings are for everyone :) <gabber>oh no, it seems the guix daemon blocks and i can't even strace the issue <Rutherther>Kabouik: but gtk+ specifies libxkbcommon 1.6.0. The libxkbcommon guile symbol is bound to 1.6.0. guix install libxkbcommon matches the latest version of libxkcommon, being 1.8. This then leads to the conflict. <Rutherther>Kabouik: but gtk+ specifies libxkbcommon 1.6.0. The libxkbcommon guile symbol is bound to 1.6.0. guix install libxkbcommon matches the latest version of libxkcommon, being 1.8. This then leads to the conflict. <Kabouik>What I didn't get when I tried to investigate that Rutherther was why "libxkbcommon" in a package definition would lead to 1.6.0 (because (define-public libxkbcommon …) with that name is in version 1.6.0) while `guix install libxkbcommon` would default to a more recent version even if its pacakge is defined as `libxkbcommon-something`. This was not intuitive to me but I guess this is normal. In any case it leads to a conflict while the user is just <Kabouik>trying to install packages without restricting any versions on purpose so it might be misleading. <Rutherther>Kabouik: because youre comparing two things: guile symbols and specifications. By guix install X youre using spefication X that says: find package named X, and choose latest that matches <Kabouik>I understand better now but then I find it counterintuitive when a guile symbol actually points to an older version; at least it's not clear from the `guix install` conflict error what a user should do. The error says to upgrade both packages but clearly this will not solve this issue; it should instead tell that only the version pointed by the guile symbol (and ideally name that version) can be installed <Rutherther>but it is clearly already installed, so you do not need to guix install anythign <Rutherther>the guile symbols are usually made up so that the one without version specified is the one used the most <Kabouik>Hum, but yet before I installed `libxkbcommon@1.6.0`, I was getting an error related to `libxkbcommon.so.0` missing when I was trying to run the Emacs EAF install script (a Python script that supports guix package manager), and that error vanished after I installed it… Even if Zathura (and therefore girara and gtk+) were already in my profile. <Rutherther>Kabouik: seems very unlikely to me that it is the guix install that fixed it <Kabouik>You're probably right, let me retry without libxkbcommon@1.6.0 installed on its own. I just was catching up on an old Github issue after someone replied to it, but one month has passed so admittedly other things may have changed in my system. <kkremitzki>Hi all, I'm investigating the recent CVEs, and while I previously reproduced it using the announcement blog example (guix repl -- abstract-socket-vuln-check.scm) on a Guix System laptop, I'm now seeing it report 'closed', using the 1.4.0 QEMU image, the binary installer in a Debian VM, and trying all sorts of invocations/guix time-machine, etc.. <kkremitzki>Not sure what's going on, any troubleshooting suggestions? <bavier>vagrantc: I hadn't heard of it till now. In-person only, looks like? <lilyp>apteryx: yes, all packages that currently use tracker/tracker-miners should be moved to tinysparql/localesearch <PotentialUser-76>`guix system: error: while setting up the child process: in phase mountIntoChroot: getting attributes of path `/gnu/store/q5q9k574lpw8y2c4rjnzravciax879cn-upgrade-shepherd-services.scm-builder': No such file or directory` <PotentialUser-76>I've made literally no changes to my configuration (except some minor reformatting, mostly of whitespace) <cdegroot>Kabouik: a bit late to respond, but while it is reasonable advice to try and make .envrcs not too slow, for code projects I usually don't care. I cd into them which may install a ton of stuff (I mean, when else do you do it?) and then Emacs does the same but everything is already there so it's quicker. Then I start coding and stay in the project's file structure so direnv doesn't kick in. <Kolev>What code is required for Radicale? Just (service radicale-service-type)? <Kolev>Or does a config need to be passed to it? <csantosb>Wow. Trealla. What a release/commit pace. <umanwizard>Hello, how does one build and install a new version of the store? Is it enough to just change the .cc files, then guix pull from my checkout, then guix system reconfigure ? <Rutherther>what does installing a new version of the store even mean? <Rutherther>okay. What daemon is used is determined by guix-service-configuration guix field. It refers to guix package by default - in (gnu packages package-management). So you need to either change that package or the value of that field. Changing cc files only will not work as the guix package is always pinned to a commit <Rutherther>something like setting the guix field to "(guix-for-channels (here specification of channels where the url is pointed to your checkout))". Or, if you first pull from your checkout, you can just set it to (current-guix). Note that if you aren't a committer, you will need to drop the channel introduction since your commit isn't authorized <umanwizard>is this the easiest way to quickly test a daemon change? Do I really have to re-pull etc., or is there a way I can just temporarily reconfigure my guix-daemon herd service to point at some locally built binary? <Rutherther>sorry, it's guix-configuration, not guix-service-configuration <Rutherther>why do you want to use shepherd in the first place? <umanwizard>well, shepherd is currently the thing causing guix-daemon to run on my system <umanwizard>I suppose I could just kill that service and run guix-daemon by hand in a terminal <umanwizard>right, that's what I meant. "kill" in the broad sense, not specifically using the posix "kill" command. Imprecise language again :) <Rutherther>make sure to check out the arguments provided to it before you stop it with herd status to start it with the same arguments to get the same behavior <umanwizard>error: failed to run download program '/bin/guix': No such file or directory <umanwizard>(this is with the guix-daemon running as root in another terminal, with the same CLI args as it was running in shepherd) <Rutherther>and this happens even with guix-daemon from guix package? ("guix build guix") <umanwizard>nope, with the guix-daemon from guix package, it works. <umanwizard>the one it didn't work with was built using make <Rutherther>okay, so it seems to me you either built the daemon wrongly somehow, or made changes that cause this issue <umanwizard>"built the daemon wrongly somehow"... should this work? guix shell -D guix -- sh -c './bootstrap && ./configure && make -j16' <meaty>is icedove completely "implemented" in guix? <meaty>I can't find where any patches are hosted <Rutherther>umanwizard: the location where guix is taken from is determined by NIX_BIN_DIR definition. And this is set to bindir of the environment. Not sure why it's not working with make. Anyway you can just override it with an environment variable NIX_BIN_DIR, pointing to bin path providing guix binary you want to use. I think the only time it's used is for performing the download, but not completely sure <Deltafire>meaty: there's a bit more to it than that, but not much <namewillforget>I installed Nyxt on my decently new system by adding it to my system config, but when I start it I get https://pastebin.com/nsCzdRYX . Is this a bug? Should I report it? To be sure I followed the profile-setting instructions in "Getting Started" again and also tried to install Nyxt from my home profile and start it again. <ieure>nameiwil`, I think it's just buggy and broken. <ieure>namewillforget, Probably file a Guix bug and someone can figure out if it's Guix-specific or an upstream issue. <ieure>namewillforget, Also FYI, you generally don't want to install user packages in your system config, they belong in user profiles, manifests, or Guix Home configs. <namewillforget>It's a shame because the idea of a Lisp-based browser sounds almost too good to be true <identity>namewillforget: i am guessing updating the package might solve the issue <namewillforget>identity: I did an update with `guix pull` and a reconfiguration of both my system and home config to be sure, but it still threw the same error <identity>namewillforget: i meant updating the package definition to build a newer version of nyxt, i think it is a little outdated <namewillforget>identity: Oh, I see. I haven't done that yet, but I think I understand in principle how I am supposed to do it. <nomike>I'm running Guix on Ubuntu 25.04 foreign distro and graphical applications don't show the app-icon properly in the window overview in Gnome. So when I run emacs for example and hit Super it will show this icon for emacs and all other programs installed via guix: https://shorturl.at/exmzE <nomike>I guess I'm missing some path in some environment variable. Does this sound familiar to someone? <nomike>Or should I better ask the folks over at #gnome? <luca>You're sourcing "$HOME/.config/guix/current/etc/profile" and "$HOME/.guix-profile/etc/profile" in your .profile? And have logged out / restarted since adding those lines there? <nomike>luca, yes, that's most likely the issue. Startup files are a mess nowadays. I was used to using ~/.zshrc for this, but Gnome doesn't load this. You used to be able to use ~/.xprofile or ~/.xinitrc, but Wayland no longer does this. I believe it reads the system user environment file though. <nomike>OK, it doesn't seem to be Wayland which is doing this, but gdm. <nomike>I think I will need to do some experiments here for which i need to sign out and in again... <nomike>Ah...yes. I forgot that some time ago I tried to deal with a similar issue already and did some work on this. <nomike>So, there are two ways of setting environment variables: There is ~/.pam_environment and there is ~/.config/environment.d/envvars.conf. Both only support "key=value" style assignments. I can not source a shell script in there.