IRC channel logs
2024-08-14.log
back to list of logs
<lispmacs[work]>hi, do we have any packages that do url shortening? like, that tie into tinyurl or bitly or something? <nikolar>lispmacs[work]: do you want to host a shortener? <shokara>Hey all. How would I know why a service is failing to start (specifically wpa-supplicant)? Is there some kind of logs I can view? <shokara>strangely enough, it started after a reboot. but it'd still be nice to know how to troubleshoot a failing service <shokara>nevermind I forgot that /var/log existed <rynn>No idea, I haven't even tried doing anything with Shepard yet. <jonsger>ACTION had a meeting with a colocation provider in Stuttgart, Germany where we talked about hosting build servers for Guix. I will soon receive an offer with pricing and other details :) <Rutherther>Anyone knows whats the current state of parameterized packages? I found some blog posts from Sarthak Shah, and the code for them. But I cannot find anything open in development / patches of guix and it doesnt seem its merged yet <weary-traveler>rebasing sarthak's code to ensure it build, and submitting a v0 patch would be a start. though before one starts on that it would help to see if the code already satisfactorily addresses some of the comments that had come up in the mailing list <sepeth>Hi Guix, I am running `guix refresh -u kwin` but getting 'gpg: failed to create temporary file ... No such file or directory' and one below 'gpg: connecting dirmngr at /run/... failed: No such file or directory'. Any idea what's going on and how I can solve this? <civodul>sepeth: hi! ‘guix refresh -u’ uses gpg to authenticate source tarballs, and it would seem that the gpg installatio here is non-functional for some reason <sepeth>Hi civodul, thanks, I haven't done anything with it, does it require any init before accepting a key? <civodul>sepeth: maybe run ‘gpg-agent --daemon’ first? <civodul>unrelated; with current Magit, ‘magit-branch’ fails with: transient-setup: Symbol’s function definition is void: transient-prefix-object <nikolar>packages.guix.gnu.org is really flaky <dariqq>is there a good way to test (a patched) shepherd that does not involve reconfiguring my home/system all the time? <sepeth>civodul: yay, thank you, that worked \o/ <civodul>Rutherther: ok, thanks for the heads-up; i’ll monitor that issue :-) <civodul>dariqq: depends! if you want to test a different PID 1, either you reboot, or you run a VM, or if applicable you dynamically load the new code in the running shepherd <civodul>(with ‘herd load root file.scm’ or ‘herd eval root …’) <dariqq>civodul: well i was looking to make the --silent option actually do something. Is there a reason why it is not implemented yet (and also missing from the manual)? <dariqq>i think i have it somewhat working by making the --silent case set the shepherd output port to the void. But feels a bit hacky idk <triangle`>Slightly off-topic: I posted a question to help-guix (the mailing list) which I would like to now reply to (since I solved the problem). How ... do I reply to my own post? (I didn't get a copy emailed to me; I did get a daily digest). <guestinator>Rutherther: you can use package-input-rewriting like so (assuming my-elisp-packages is a list of the elisp packages in your profile) to native compile all your packages https://0x0.st/X48p.txt <guestinator>if you just want to fix magit without native compiling everything, you can use package-input-rewriting too, it will recursively native compile transient for you without having to delve into the definition like in your paste <lilyp>note, this is a solution to get everythin compiling natively easier – it's not a solution for the emacs bundling thing <guestinator>well, for magit native compilation alone does solve the bundling thing, since it declares transient as a propagated input <guestinator>but yeah, for cases like embark-org, it would still be broken <guestinator>I discussed it a bit in that comment ^ not sure how to solve that generally though <Rutherther>shouldn't that be solved by putting correct inputs to packages? if the version expects higher version dependency, it should be provided with deps, not taken out of emacs itself which has older <guestinator>sometimes a package does not require a higher version dependency by API, but there is an ABI breakage <guestinator>so consistently native compiling external packages solves it <guestinator>so in that case, should you declare the newer external version as a dep? magit does, and it makes sense there because transient is a hard dependency <guestinator>IMO the easiest solution is to just always propagate the newer external deps, and document rewriting for native comp better. the handful of people who really don’t want the newer external deps can override their packages as desired <Rutherther>ah, I didn't get there could be ABI breakage like this, as I am not that familiar with Emacs native compilation specifics <Rutherther>so the problem with embark will arise only if you include org newer version in your emacs packages, right? <rbrins>I currently don't have sound on my guix system, is it as adding the (service alsa-service-type) to the %deskop-services list within the system config.scm? I haven't figured out the guix-home config yet to add it theree <Rutherther>desktop services include pulseaudio service. If you wanted you could setup pipewire instead via guix home <weary-traveler>it seems when a package $foo depends on a package $bar where $bar is both included within emacs, but also exists outside of emacs special care needs to be taken <rbrins>Rutherther: the pulseaudio service doesn't seem to be available in that case (in herd status, herd enable pulseaudio, or herd start pulseaudio). I'm not sure what pipewire is but I was just looking for simple audio playback. <ieure>rbrins, Pipewire is a replacement for PulseAudio. <ieure>Most Linux distros have switched to PipeWire, which has a PulseAudio compatibility thing. <Rutherther>rbrins: as far as I know there shouldn't be a shepherd service for pulseaudio. The daemon is started automatically by first client when autospawn in client.conf is yes, which is the default <lh_>Rutherther: correct. if you don’t include newer, separate Org (and nothing else propagates it!) compiled embark-org will work fine <lh_>if you do include newer Org, you need to override embark-org <lh_>to include emacs-org as an input so it is used during compilation <spanko>is there a way to enter the password only one time at boot ? <Deltafire>it possible, but i think it involves having the key in cleartext on your encrypted boot partition <weary-traveler>recent versions of grub2-efi in tumbleweed seem to only ask for password once now <weary-traveler>iiuc, it doesn't require for the key to be in the initrd or elsewhere <stikonas>Deltafire: but I've heard that this is not possible with guix automation (though yes, in other distros this is possible) <Deltafire>oh, i'm not sure about that. i decided it was easier to type the password in twice instead <Deltafire>it's a laptop, so is mostly in standby mode anyway <stikonas>I think the problem is that initramfs must also be in /gnu/store <Deltafire>you could mount /gnu/store on an unencypted drive <Deltafire>there shouldn't be anything confidential in there(?) <spanko>> I think the problem is that initramfs must also be in /gnu/store <spanko>are there plans to have an initramfs outside of the store ? <spanko>> it possible, but i think it involves having the key in cleartext on your encrypted boot partition <spanko>there's also a few other limitations <Rutherther>I am using guix home with pipewire. I have a bluetooth headset. When I log in through gdm into Gnome, headset is working fine. But when I skip gdm+gnome and go to a wayland compositor from tty, the headset doesn't have any audio profiles... what could be the reason? When I first log into gnome, and then go to compositor out of different tty, it's fine <jackhill>Rutherther: is GDM still hanging onto the device for some reason until it starts a session? <spanko>afaict you can't remote unlock grub, and you can't use argon2 as a key derivation function either <Rutherther>onto what device you mean? bluetooth adapter? I don't think so, as I can connect to the device. It's just that there are no audio profiles <jackhill>Rutherther: yeah, that's what I was thinking, but really I don't really know, just trying to brainstorm. Sounds like it's not that <Rutherther>it seems to me that pipewire / bluetooth is differently initialized from Gnome than from startup in a tty (the first login shepherd script runs with gui when gdm+gnome, but in tty in the other scenario) <Rutherther>maybe I need to update the dbus environment and possibly also restart pipewire 🤔 <Rutherther>ah, alright, so it was as simple as updating the dbus environment, probably with WAYLAND_DISPLAY... I wouldn't expect that to matter for pipewire. <Rutherther>speaking about environment... is it possible to import some env vars to shepherd? from systemd I am used to the possibility of graphical programs, like waybar, started from systemd. This is done by exporting WAYLAND_DISPLAY to systemd so the service knows the display to start on <jackhill>Rutherther: interesting, thanks for testing and confirming <Rutherther>but where does it obtain DISPLAY? DISPLAY is populated only after you open a window manager. The shepherd service was forked off when I logged in, prior to wm starting. So it cannot have it <Rutherther>I see the service you sent depends on x11-display. But if I start the wm manually out of tty, what can I do then? <jaft_r>Rutherther: Ahh; fair point. I'm not entirely certain how well it'd work but, potentially, setting the variable in your .bash_profile? I set XDG_CURRENT_DESKTOP, currently, that way. <Rutherther>WAYLAND_DISPLAY is populated by the wm. waybar process needs this variable. I don't understand what you mean to set in .bash_profile regarding this. It seems impossible to me, as the wm is not started then, so WAYLAND_DISPLAY is not known. The way you do this in systemd is with "systemd import-environment --user WAYLAND_DISPLAY". This will set the environment variable inside of systemd to value from environment it was executed in. <Rutherther>I've gone through more how the shepherd DISPLAY works, and it's quite interesting. It sets the environment variable in shepherd's process by looking through the xorg display sockets. This could be done with wayland as well! So maybe that solves my issue after all. No imports from environment, but shepherd observing what's going on by itself. Now that I am thinking about it it could even be made to communicate with shepherd with a contents inside of a... <Rutherther>... file. Maybe there is a better way to communicate with it though... <Rutherther>ah, I think I have a better idea. It could be a parameter to a service. Something like "wayland-services", other services that need the env var woud depend on it, and I would start it under the wm with "herd start wayland-services $WAYLAND_DISPLAY" <graywolf>Hello :) I decided to try guix-for-channels, but during deploy I am getting warning like: "hint: File `./manifest.scm' should probably start with:". The deploy still suceeds, but I would like to understand what is going on. Anyone has ideas? <lispmacs[work]>hi, what adjustments would I need to make to bare-bones.tmpl to be able to build it (and run it) as a qemu VM image?