IRC channel logs
2025-05-11.log
back to list of logs
<luca>Hi, does anyone have a guix+emacs setup they'd like to share? I've done the naive local-file my .config/emacs map but obviously I can't edit custom.el and other stuff. So I'd like to see what the proper way to do it would be <ieure>luca, Don't have one to share, but I put all my customizations into my use-package declarations, and then (setq custom-file "~/.emacs.d/custom.el") -- I'll pull stuff from there into the declarative configs as needed. <luca>ieure: i see. so custom.el is not in your dotfiles repo? (if that's how you manage your configs) <luca>thanks, I'll do that I suppose <zuki>How do you get xdg-desktop-portal-wlr running? <meaty>anyone got an incantation for viewing info pages from a package that's not installed? <meaty>I can always do "guix build" and specify the store path of the package manual, of course, but there has to be a more elegant way <podiki>probably something like "guix shell info-reader <pkg> -- info <pkg>" <tusharhero>how would you do this in GNU Emacs's info reader? <euouae>Hello all, can I use GNU Guile for low-level bootstrap software? <euouae>I don't know a whole lot about bootstrapping <euouae>Or is it just a subset of GNU Guile (some scheme?) that can be used for bootstrapping? <euouae>and I'm talking in general not just Guix I guess. <euouae>Hm, I should probably ask this in #guile instead <euouae>The docs of GNU mes explain this <hiecaq>luca: I don't use custom.el at all (more closely, not at all for anything permanent), by pointing it to a temporary file every time new Emacs instance starts. All my actual Emacs configurations are in files that are managed by guix home. <sneek>hiecaq, you have 2 messages! <sneek>hiecaq, auk says: relating to what you said about guix pulling source, content-addressed, from SWH -- i think i might have a conceivable exploit scenario <sneek>hiecaq, auk says: 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. <sneek>andreas-e, you have 1 message! <sneek>andreas-e, ieure says: "I sent a clean v2 LibreWolf patch series." <andreas-e>cbaines, thanks for the arm32 fix on armhf. The bane of parentheses! <cbaines>no problem, unfortunately CI has still failed to evaluate core-packages-team, so I'm not sure what the problem is there <cbaines>hopefully the QA data service might finish processing it by this evening <andreas-e>cbaines: How come that the kernel-team branch does not advance instead? <cbaines>bayfront was running a GC overnight, that blocks substituting derivations for new builds <cbaines>looks like builds for the kernel-team branch are now being submitted again <cbaines>kernel-team only includes two package updates currently, and the bluez update to 5.79 looks to fail to build, so I'm not sure how much progress can be made <hiecaq>auk: hmm, isn't that a thing that is useful for any Rust development, even if it's not on Guix? Within Guix I believe we can already do something similar. However I think the Rust community usually just prefers the latest Rust toolchain, and Rust does generally a good job on maintaining syntax compatibility too. <andreas-e>cbaines: Okay, I see. That is unfortunate for kernel-team - the first commit was almost fully built already, and apparently without problems. <mccd>If I have a guile function that I want to make executable, what's a good "guix-y" way to do so? Use home-file-service-type? <identity>mccd: i use program-file + home-files-service-type <cbaines>I want to restart NGinx on bayfront, so I might reboot the machine <cbaines>it's still running shepherd 1.0.3 which I think has the "gets stuck when you restart NGinx" issue <andreas-e>cbaines: Now the question is whether it will get stuck :) <cbaines>ok, bayfront seems to be back up now, and it's running shepherd 1.0.4 <cbaines>I'm not sure why the initial reboot didn't work though <cbaines>indeed! it's not great that it got stuck, but being able to login via the serial console saved the day <andreas-e>The xz-mesboot on core-packages-team looks simply stuck. There is a first failed build without an error message. And on kranji, the CPU load is 0, while the build was started 11 hours ago. <cbaines>we should add log streaming support to the build coordinator, that way we could at least get some information from these builds <andreas-e>I do not even have enough space on my disk for a "guix package -u" ;-) <luca>Hi, can I guix gc a specific package? To try and build it again <andreas-e>So you may have to do a "guix build package-name" first to find the store path. <andreas-e>But I think "guix challenge" could also solve your problem (to check with the manual, I never tried). <luca>Is `guix gc -D /gnu/store/*<pkg-name-here>*` a good idea? <sham1>Well, it won't remove the item from the store if it's still live <luca>yeah, I guess guix build or challenge is safer regardless <luca>Hmmm, `guix build -L . runit --rounds=2` doesn't rebuild it in my case <hako>guix build --rounds=2 --check --no-grafts ... <zuki>I've tried setting up qt6ct and qt5ct, they both have custom themes applied within them and work perfectly on their configuration tools but obs and keepassxc are just using the defualt white qt theme regardless of what I change, even though I have "export QT_QPA_PLATFORMTHEME=qt6ct:qt5ct" before my wm even loads. <luca>Hi, is there a way in guix/guile to get all of a modules' exports? <mccd>I noticed that guile scripts created with #~(begin...) have the flag --no-auto-compile. Aren't the scripts faster with compilation? <lfam>But, it fails to install because it tries to write to /etc and /var <lfam>Did something change in the gnu-build-system packages that would cause this? Or is it more likely an upstream misuse of the autotools? <andreas-e>Hello, lfam! To me it looks like an upstream error, as if they put an absolute path somewhere instead of honouring the install dir. <lfam>ACTION tries the wrong thing (setting DESTDIR) <lfam>Setting PREFIX did not help. I don't really want to be a Makefile surgeon today <lfam>Setting DESTDIR, the installation procedure does the right thing, but then the post-install phase fails <lfam>But, that's more or less expected as it is a custom phase <lfam>I guess this patch was not tested :/ <andreas-e>That is annoying! Actually the branch with only the previous patch had already been built almost completely, we could have pushed it. <dariqq>lfam: maybe overwrite sysconfdir and localstatedir for the install phase only? There are some examples for that (e.g. lightdm) <lfam>andreas-e: Yes, I'm a bit rusty in my "project management" skills and didn't handle this as defensively as I would have in the past <andreas-e>I am looking at the diff between the two Makefile.am. Nothing that sticks out as related to /etc and /var. <lfam>If I can get it working very soon, I think it's worth having the update <lfam>I will try that dariqq. Thank you! <andreas-e>Well, nothing bad has happened so far, QA has done what it is meant to do! <andreas-e>Hm, but the package definition has these two lines: <lfam>Yes, I'm just emabarassed because I told Chris that it should be safe to skip the queue. And then it didn't work <lfam>Good question, I'll remove those <andreas-e>You did not skip the queue, so no problem ;-) <lfam>Those lines were added in 2016 (!) <andreas-e>It would have been interesting to know why... <lfam>Yes, we could ask iyzsong <andreas-e>Interestingly the following lines look "normal": <andreas-e> ;; Install dbus/udev files to the correct location. <andreas-e> (string-append "--with-dbusconfdir=" out "/etc") <lfam>Also interesting to know why it breaks now. And that "--with-dbusconfdir=" line is from the original commit of this package by davexunit <andreas-e>cbaines, civodul: I tried to "./pre-inst-env guix build mpc" for the core-packages-team locally, and it also times out. Interestingly I had a timeout in a different package (something with gcc-mesboot) before. How do you debug that nothing happens? <andreas-e>lfam: I think the previous package did not write anything into /etc and /var (in /etc I see dbus-1/, which corresponds to the davexunit dbus flag, and ld.so.cache, which I suppose is added by us or the build system). <pastor>Hello, has anyone ever seen this error with the gpg-agent home service? <pastor>`2025-05-11 17:35:02 can't connect to the PIN entry module '/gnu/store/01zf6mh1l2sid64dh6p7zcd03fbc9p3p-pinentry-qt-1.3.1/bin/pinentry': End of file`? <andreas-e>lfam: In particular, there is no subdirectory /etc/bluetooth, which the new package tries to create. <pastor>The pinentry module works propperly if gpg agent is started manually like so: `gpgconf --launch gpg-agent' <pastor>There seems to be a bug in `home-gpg-agent-service-type' but I don't understand what it could be. <ruther>lfam: andreas-e: could it be this bluetoothd-fix-permissions makefile target that is supposed to ensure the permission on /etc/bluetooth are corret? <ruther>it was introduced in Feb 2024 in be0e796299b0e7a73bf06c5655b56180588550b0 <ruther>and if so, I think it should just be removed for Guix purposes, it doesn't make sense for Guix <mccd>So it seems that when I add the -L parameter to guix home reconfigure, guix starts building seemingly unrelated packages <mccd>these extra libraries don't really contain anything, just invocations to other programs <lfam>ruther: interesting, I wonder what's the easiest way to disable it <lfam>dariqq: Do you know if these options affect where bluez would look for this data at run-time? I think we'd still want it to look in /etc/bluetooth for configuration, right? <ruther>lfam: but that's written inside the binaries on build, isn't it? So setting on install doesn't matter <dariqq>maybe the bluetooth service needs adjustment as well as it does not create /var/lib/bluetooth and only a /etc/bluetooth/main.con but there is a sample input.conf and network.conf now <mccd>Is there a way to spawn a guix repl, like with run-server in guile? <lfam>That *should* work but maybe it somehow conflicts with something in Guix home <lfam>That patch does seem to assume that you'll have installed a pinentry <lfam>Since there are a variety of pinentry implementations, it's expected that the user will choose one <pastor>lfam: Oh. That is interesting. I thought that the service was enough <lfam>I'm not familiar with the home service pastor. So I don't know if it should provide pinentry on its own. But if you just installed gnupg on its own, you'd also want to install a pinentry <pastor>lfam: I didn't need to install gnupg. I will try anyways, but the pinentry prompt was poping for GPG signing keys. It throws the error for SSH keys. And works propperly if it's started as I staded <pastor>lfam: the thing is that the service provides a field for the pinentry program and sets the absolute path to it (to the store) in the configuration, so it should not need to find it. <lfam>pastor: And to clarify, that path is valid? There is a program there? <lfam>Ah, and it's just for SSH keys? The integration of GnuPG with SSH keys is not something I have experience with <pastor>It seems it's a bug either in GPG or in our service. If I start it manually (not as a daemon) it works propperly <lfam>It could be that this use case just wasn't tested with the home service. I think it's worth reporting it as a bug so we can support this <pastor>I see. Previously I could make it work with other pinentry program so I thought it was a problem of the qt variant. But now it's failing for all <lfam>Hm... it's definitely possible to wedge the gpg-agent and pinentry into a broken state that I fix by just killing them and restarting the gpg-agent <lfam>And the different pinentries have different authors so could have different bugs :) <pastor>Well, restarting does not seem to work for me. May I ask ho do you start the gpg-agent? <lfam>pastor: I don't use any services for GnuPG. I just invoke gpg when I need to use it, and it starts itself as a daemon <lfam>This is not very "Guix-y" but I'm old school <pastor>lfam: like so? `gpg-connect-agent /bye` <lfam>No, like `gpg -d ~/my-secret-file`. It starts the agent automatically <pastor>Started like this I don't any problem <lfam>If I need to kill it, then I use `kill` <lfam>For me, it's a program that doesn't need a service, since it daemonizes itself and usually doesn't need to be killed <dariqq>lfam: Great, I hope the service still works, but I dont use any bluetooth so I cant test <pastor>lfam: it seems that we are using a deprecated feature our service starts it with `--supervised'. Check this out: <pastor>I will try to update the service to see if it gets fixed. I guess we should use `--daemon' instead <andreas-e>lfam: I am mainly doing other things today, so am not very reactive. Indeed I agree with ruther, this bluetoothd-fix-permissions make target looks superfluous; I suppose it will just create empty subdirectories. <pastor>or `--server'... hum I'm not familiar with this. <lfam>pastor: I find the deprecation statement ambiguous. Is it both deprecated and unsupported on Windows, or is it deprecated everywhere, and unsupported on Windows? <civodul>andreas-e: re timeout, i would check the process tree of the package that’s timing out, possibly stracing the test that’s hanging, things like that <andreas-e>lfam: Did you try to drop the --sysconfdir=/etc and --localstatedir=/var configure flags altogether? My guess would be that then everything should work out of the box. It looks like going back and forth to me, making a change and then disabling it again. <pastor>lfam: Oh, could be. Supervised seems to do something different since we use it to listen in different files: <pastor>I'm not sure if this functionality can be replaced if we remove the `--supervised' flag... <lfam>andreas-e: Yes, I did try that and I agree it might be a little funny. However, it seems that many Guix packages set sysconfdir and/or localstatedir, so I figure that it must be okay <andreas-e>civodul: It is worse, it hangs in the build phase! <andreas-e>lfam: Well, it it appears to work by dropping the configure flags and the new phase, I would rather push it like that; otherwise we pile up workarounds that nobody will understand in the end. <lfam>pastor: I think that running processes in the foreground and using a supervisor service is the norm these days. It's kind of old-fashioned that program will daemonize itself. That's partly why I think the statement is ambiguous: because I think it would be weird if this method is deprecated on Linux <lfam>I'd really appreciate if somebody that uses bluetooth could test this <ruther>andreas-e: but then if the configuration out of /etc is not going to be used, that is incorrect behavior <lfam>pastor: To clarify, does changing this option fix your problem? <andreas-e>Whereas I would not be able to say of things "work" - I did not get bluetooth to work on my laptop, and did not need it urgently enough to spend time. So it would indeed be good if someone could test that the package is functional in the end, and not just buildable... <lfam>I'm sure that someone uses Bluetooth on Guix... <lfam>It's basically ubiquitous these days <ruther>I am reasonably certain that after removing --sysconfdir=/etc and --localstatedir=/var the package is not going to be functional in the way users expect - so that the /etc/bluetooth/main.conf etc config is used <ruther>I use guix, but don't understand it enough to be able to tell you if the main.conf is going to be used or not, so I can't test it. <pastor>lfam: starting it like this does `gpg-agent --daemon --enable-ssh-support' <lfam>Does the home service include '--enable-ssh-support'? <pastor>This is the output of `herd status gpg-agent' <pastor>`Command: /gnu/store/2mhj5fzvwsx42407qdk4wdz0h2vfz2yp-gnupg-2.4.7/bin/gpg-agent --supervised --enable-ssh-support` <pastor>lfam: check this out. Here they clarify the deprecation a bit more at the end: <lfam>Well, the gpg home service is probably one of the least active files in our code base. 4 commits total in 2 years! <andreas-e>Concerning the patch, I would find using "let" more elegant than "define". <lfam>I would file a bug and CC the primary authors <pastor>lfam: alright, thanks for the help <lfam>Bonus points if you can include a patch that fixes the bug for you <pastor>lfam: But that requires removing the endpoint sockets. Is that okay? <lfam>pastor: I don't use this service and I've never read its code. So I can't say :) <andreas-e>lfam, ruther: If you drop the configure flags *and* the extra phase, I think things just work as expected. I end up with a bluez package that has a subdirectory $out/etc/bluetooth with the three *.conf files in it. <ruther>andreas-e: 'things work as expected' would have to mean that when user puts /etc/bluetooth/main.conf file in their root etc, it is used. It won't, because sysconfdir is under gnu store, not under /etc <ruther>That is why sysconfdir is set to /etc, to use system config <ruther>this config is then managed by bluetooth-service-type <andreas-e>ruther: You mean that the value of sysconfdir is also used elsewhere in the code, instead of just for creating the package? <dariqq>andreas-e: the bluetooth services writes out the bluetooth conf into /etc/bluetooth so you wont be able to adjust settings with that <ruther>andreas-e: see load_config function in src/main.c. It uses CONFIGDIR, that is set to {sysconfdir}/bluetooth <andreas-e>I have found places, and roughly get your point. <andreas-e>Well, then, I am convinced we need a complicated solution :) <andreas-e>The README suggests to use the configure flags as well. <ruther>anyone knows if there is binutils of version 2.43 or greater packaged somewhere? <ruther>hmm, --with-version=binutils=2.43 compiles fine, so I guess no need for that then. <andreas-e>ruther: The core-packages-team branch has binutils 2.44, but the branch currently does not build... <ruther>andreas-e: thanks, I will take a look (I was expecting to copy the definition for now, so it's fine it doesn't build wholly) <nutcase>to reconfigure my system from a local git clone, do I just issue "sudo ./pre-inst-env guix system reconfigure ..."? <lfam>nutcase: Assuming you've built the Git tree (`./bootstrap && ./configure && make`), that will work. You can also use `guix time-machine --url=/path-to-git-repo --commit=yourcommit` <nutcase>lfam: I get "guix: system: command not found" then :-( <lfam>nutcase: Do it within a Guix development environment. That is, within `guix shell -D guix` <ruther>nutcase: either go to root and do not use sudo, or use -E flag with sudo (but I would rather recommend the first approach) <nutcase>ruther: "go to root" means e.g. "sudo su" <ruther>make sure you're in a pure shell and then you don't have to run 'make'. If you aren't in a pure shell, you're risking your user environment guix modules will get picked up <lfam>Oh yeah, you also have to become an expert on privilege escalation and Unix environments ;) <ruther>nutcase: yes, 'sudo su' or 'su -' <lfam>Good case for `time-machine` <ruther>time-machine is definitely clearer, but will take more time <nutcase>ruther: still I get "guix: system: command not found" <lfam>time-machine can be slow, but it took me about 6 months to really grok environments ;) <ruther>are you in the development shell? <lfam>So, who's to say what's faster? <nutcase>ruther: no I wasn't. in a -D guix shell I get "no code for module (nongnu packages fonts)" <ruther>nutcase: right, if you have other channels, you will have to add them to GUILE_LOAD_PATH environment variable <nutcase>ruther: export GUILE_LOAD_PATH=$GUILE_LOAD_PATH;/path/to/my/channels.scm ? <ruther>nutcase: no, to checkouts of them <ruther>then you will have to make them. Or use the time-machine approach, pointing to your channels.scm and --url set to the local guix checkout <keinflue>Hi, is anyone using android-repo-fetch? First it doesn't immediately work because git-repo doesn't compile with the current Python version and after fixing that, I can't manage to reproduce the same hash for the output. It doesn't completely remove the .repo subdirectory and in particular leaves .repo/manifests.git in there which I do not think is <nutcase>ruther: i have clones now, but probably a malformed GUILE_LOAD_PATH now. can you give me an example of how it should look like? <ruther>export GUILE_LOAD_PATH=/path/to/first/checkout:/path/to/second/checkout <ruther>one more thing. The channels can have modules in subdirectories. If that is the case, the load path should point to that subdirectory <ruther>basically if you look in the .guix-channel file in the checkouts, it would have (directory "modules") for example. Then you would point to modules subdirectory of the checkout <ruther>the default is root of the repository <nutcase>the channels have ../packages/ subdirectories <ruther>yes, what are you trying to say? <nutcase>with pointing to root I get "gnu/packages.scm:578:4: In procedure specification->package+output". my system conf uses specification->package+output <ruther>packages are also inside of modules, what's under ../packages is usually modules. I meant to say 'root of the modules' in my messaages previously <ruther>nutcase: please send the whole error log <ruther>and also that invocation in your system conf <ruther>hm, that's strange. If you instead add -L /home/flake/git/nutguix/ to guix system reconfigure arguments, does that work? <ruther>Hm, I don't know why GUILE_LOAD_PATH doesn't, but at least it works <nutcase>ruther: thanks so far. guix now wants to build (all?) packages (because the inputs changed?). I think I should interrupt this <ruther>nutcase: what were your changes in the checkout? <nutcase>with luck only those packages are built that depend on my modification <nutcase>ruther: it seems like it's "only" this (bluez) + dependents. That has nothing to do with luck, I realize now <lfam>nutcase: Are you using the kernel-team branch? <lfam>Bluez shouldn't have changed on the master branch <nutcase>lfam: I changed it in my local clone to test locally. For now it's just the same patch as in kernel-team <lfam>Okay, phew! I was worried I pushed to the wrong branch <nutcase>I know that I could have modified my channels.scm to use kernel-team branch <lfam>If you wait a while the build farm should offer substitutes, but I don't know how long <nutcase>lfam: however, I can (unsurprisingly) confirm that your bluez patch lets me build bluez locally <nutcase>and I will test the behaviour in my system (if my original issue is fixed with that update) once the substitutes are available. <lfam>Great nutcase. Let us know how it goes! We need help testing <csantosb>Hi ! Any idea of who provides "bin/fuser" ? <csantosb>`guix locate -u fuser` gives nothing for mi <csantosb>How can you know (other than having it installed locally ) ? <ieure>csantosb, I read the man page <ruther>csantosb: in this case it's in the description, so `guix search fuser` will find it. But that's not so common <ieure>It would be very cool if the builders uploaded a list of derivation contents somewhere. <lechner>ieure / I used to run a web site that allowed searches among store paths people submitted. Would that still be useful?