IRC channel logs
2025-02-15.log
back to list of logs
<jakef>would it be possible to let a guix container use your gpg-agent? <dcunit3d>i haven't done it, but it's likely accomplished in the same way as one would allow a docker container to access your gpg agent. <dcunit3d>ensure the UID/GID is consistent for processes & file systems running inside the container. run `gpgconf --list-dirs` and ensure the socketfiles you need are passed through as volumes. ensure consistent file ownership inside and outside the container. <dcunit3d>that's the basic overview, though i haven't done it <dcunit3d>however if you want to use a yubikey (via scdaemon with gpg-agent), then things may get dicey, esp if you force CCID on scdaemon <jakef>ah yep, exposing the socket would help <dcunit3d>it's possible that there's a simpler way to get what you need by forwarding sockets. the `gpgconf --list-dirs` command contains sockets for that. however, this is more of a gnupg question, so the guys on #gnupg may be able to provide better guidance for general questions <jakef>i use home-gpg-agent-service-type, would be good if there was a 'let this service in' capability <dcunit3d>the Guix containers are just a implementation of the generalized container concept. though i don't fully understand it, basically the access to various features provided by the kernel is isolated in specific types of namespaces <dcunit3d>are you wanting to start a Guix container as a shepherd service? while configuring it through Guix Home? <dcunit3d>this is possible, though you're likely to run into things i wouldn't anticipate without having done it myself <jakef>nah for my use case, i don't even need to gpg-agent; just to be able to decrypt a .gpg file in a container <dcunit3d>it's important to consider the security implications of forwarding sockets/devices to containres <dcunit3d>but you don't want the unencrypted file to be written to disk? <dcunit3d>once the decrypted file content is consumed by a process, do you need it for anything else? <dcunit3d>i'm not sure what the best way to resolve this is. i would generally try to use SOPS and either gpg-agent or age. <dcunit3d>there are other ways to deal with it, including file descriptors (though i believe that wouldn't be a great way to do it) <jakef>with --expose the .gpg file and giving it packages gnupg and pinentry, when i gpg --decryp it errors with 'problem with agent, no pinentry' <dcunit3d>ok well it's trying to connect via the agent socket, but the agent socket can't talk to the pinentry, which ultimately does reside on a pty <dcunit3d>so the agent socket that the container is talking to is trying to connect to a tty device outside the container that doesn't exist in the container's file system <jakef>so expose or share /run/user/1000/gnupg/S.gpg-agent? <dcunit3d>also, there are some peculiarities with docker containers and TTY's, which is what the "-t Allocate a pseudo-TTY" option handles <dcunit3d>so it's possible that something analagous needs to be set in order for that functionality to work properly with Guix Containers <dcunit3d>yes you'll need to expose that socket file <dcunit3d>but when the processes are communicated over the socket file, they may communicate about things like file descripters and names of sockets, which must exist in both the container file/system and the host file/system in order to function <dcunit3d>when the processes are communicating** via the socket file <dcunit3d>if your process inside the container is successfully communicating with the S.gpg-agent socket, then running a debug agent on the host system may help <dcunit3d>in order to debug pinentry, you'll need one of the latter two that are commented out. <dcunit3d>you need to fully kill the gpg-agent in order to start these, i think. <jakef>after sharing the /run/user/1000/gnupg i get a new problem with the agent: permission denied <dcunit3d>you may need alternative settings for GPG_TTY. it's possible that you need to explicitly set this, which can be a PITA. <dcunit3d>is this a file permission that is denied? <jakef>i don't think so, it's 'gpg: problem with the agent: Permission denied' <dcunit3d>try starting it in one of the debug modes. just keep GPG_TTY set to however you normally set it, until you really want/need to test that aspect. <jakef>i'll keep trying different things, thanks for the tips dcunit3d <dcunit3d>i don't think you can change GPG_TTY once it's set (i can't remember) <dcunit3d>no problem. passing through devices/sockets can be difficult btw. <jakef>haha, after passing in GPG_TTY=$(tty), new problem from the agent is: 'Screen or window too small' xD <dcunit3d>do `man terminfo` to get more information to set the terminal parameters. this is usually interpreted by the terminal application though <dcunit3d>so when GPG_TTY is passed to gpg-agent and when you're using pinentry-tty or pinentry-curses, GPG is expecting you to enter the PIN in that same pinentry <dcunit3d>so if i use ctrl-alt-f3 to pop to that tty, then specify GPG_TTY and start gpg-agent there, i need to also set GPG_TTY to the same value in calls to `gpg -r $me -d $file -o $out` in other vty's <dcunit3d>so if i start a shell using the terminator in VTY 7 after logging into my window manager, then make a call to gpg for decryption, that call talks to gpg-agent over the socket which starts the pinentry-tty process on GPG_TTY (where gpg-agent was launched) <dcunit3d>so you'd have to pop over to that VTY to test it <jakef>i got it working! i had to invoke gpg --decrypt with --pinentry-mode=loopback <dcunit3d>or, to make this simpler: , you can set GPG_TTY=$(tty) when you launch the gpg-agent inside of a terminator tab. then open another tab, set GPG_TTY=/dev/pts/$tty to the value of the other terminal. then make a call to decrypt/sign <dcunit3d>i just didn't trust X11 keyboard handling, so i've really gone down this rabbit hole. <dcunit3d>did you invoke that `gpg --decrypt --pinentry-mode=loopback` inside of the container? <jakef>i've got it down to just GPG_TTY=$(tty) guix shell -C --preserve=GPG_TTY --expose=test.gpg gnupg <jakef>not even exposing the socket <dcunit3d>but if you do `tree /run/user/1000/gnupg` inside of the container, what does it show? <jakef>i guess that's because i'm not needing the agent to remember the password <dcunit3d>because if it's truly containerized, it shouldn't have those files unless you explicitly provide access to the container <jakef>error opening dir, 0 dirs, 0 files <dcunit3d>hmmm... and if you do `ls -al $(tty)` or `ls -al $(dirname $GPG_TTY)` <dcunit3d>for the second one, does it show all of the /dev/pts/$n device files that are available on the host system? <jakef>passing in GPG_TTY isn't even required. loopback was really all it took <dcunit3d>because if it can't see the socket files in /run then it shouldn't be able to see the $GPG_TTY file <dcunit3d>i guess i don't fully understand the loopback mode for gpg-agent <dcunit3d>thanks, this has been helpful for me too. i'm glad you got it working <dcunit3d>you may want to doublecheck some of the container security details with some of the other users on #guix <marmar>is there extra configuration needed for torsocks? if I run `torsocks w3m html.duckduckgo.com` it errors out with `PERROR torsocks[5049]: socks5 libc connect: Connection refused (in socks5_connect() at socks5.c:202)` <homo>hi, I wonder what's the barrier to upgrading gnome and its circle apps <ekaitz>why does the bot say hi every day? he likes me specially or what? <homo>ekaitz to me it looks like not every day, but every time you join this channel, because timestamp is simultaneous <homo>that's surely begging for legalizing marriage between people and AI :) <ekaitz>homo: yeah... but it didn't do that before <yelninei>managed to get a working gcc-final but some coreutils tests segfault. Currently rebuilding gcc but the ~4h it takes makes it a very boring loading screen <Rutherther>is there an idiomatic way to make an executable that's been wrapped into a privileged-program? making a program in c that will execute the wrapper script feels more like a hack <jlicht>(Dutch pronunciation of sneek is close to English snake) <Rutherther>ekaitz: I think you've given him too many snacks, so he greets you now <jlicht>Is it possible to have e.g. a configured ssh-server that is not auto-started using guix? Because I often like ssh'ing into my desktop at home, but I'd prefer only manually enabling it when needed <jlicht>ISTR this wasn't possible around 5 years ago, but perhaps things have changed since then <Rutherther>jlicht: in the end it's possible to do this with every service, though it might be moroe tricky. With ssh it's easier as there is a hidden argument in openssh-configuration called %auto-start?, so just set it to #f <jlicht>Rutherther: tyvm, exactly what I was looking for :-) <Rutherther>anyway getting wireshark to work root-less on guix is a painful process, but I managed to do it afterall <h4>LANG=US file /gnu/store/chm6qhg4knlxrmv0wps6zywc4a91aj87-parameters && LANG=US file /var/guix/profiles/system-64-link.new/parameters && LANG=US guix system list-generations | grep Generation\n/gnu/store/chm6qhg4knlxrmv0wps6zywc4a91aj87-parameters: ASCII text, with very long lines (519), with no line terminators\n/var/guix/profiles/system-64-link.new/parameters: symbolic link to /gnu/store/chm6qhg4knlxrm <h4>v0wps6zywc4a91aj87-parameters\nGeneration 63 Aug 29 2024 11:04:11 (current)\nguix system: error: open-file: No such file or directory: "/var/guix/profiles/system-64-link/parameters" <h4>If Guix is unable to list it, will it be able to boot on it, as is? <jlicht>is anyone using a usb-hub connected keyboard to type in their LUKS password before grub? I’m guessing I need to customise my initrd, but don’t really know where to start <GNUtoo>jlicht: if you lack modules, you can list the ones you use with 'lsmod' and try to include them inside the system definition <GNUtoo>I had (initrd-modules (append (list "dw_mmc-rockchip" [...] "xhci_plat_hcd") %base-initrd-modules)) in one of the computers I use (it's an ARM computer though). <GNUtoo>btw, does someone know how to boot Guix on an USB key on a Macbook Pro 8,1 ? <GNUtoo>(it's for testing some GRUB patches for Guix) <Rutherther>GNUtoo: but initrd-modules are for initrd, that comes after grub <jlicht>can confirm that the usb-hub connected keyboard works after grub to type in the luks password <GNUtoo>ok I just didn't understand the question correctly, grub has modules too indeed <GNUtoo>I'm unsure how Guix handles them though, I didn't look into that yet <GNUtoo>You can still use the Guix packages to build your own GRUB images though, but I'm mainly familiar with grub-coreboot and not grub-bios or UEFI <GNUtoo>In my case I use grub-mkstandalone to generate a grub image <GNUtoo>you can pass --modules= / install-modules= when doing that <GNUtoo>you also need to pass it a configuration if I recall well <GNUtoo>(either your grub.cfg or some hand made configuration with the commands to load your grub.cfg) <jlicht>I’m a bit out of my depth here. I ‘simply’ guix system reconfigure my stuff, no manual grub voodoo. Should I disable guix’ grub-install machinery if I start doing manual things like this? <GNUtoo>No, I'd advise to keep both separate <GNUtoo>What I'm suggesting is error-prone <GNUtoo>so you would need to go through trial and errors to make it work somehow <jlicht>will dig into it, thanks for the advice GNUtoo <GNUtoo>jlicht: there might also be easier ways that I don't know of, I didn't look at the manual yet <GNUtoo>ACTION didn't find a way to add custom thing in the grub config from guix <GNUtoo>but maybe it's possible to override some of the things guix does inside the system configuration, but I'd need to be more familiar with the code that installs the bootloaders to be able to suggest something with that <GNUtoo>ACTION managed to boot Guix on the backbook I was talking about <GNUtoo>I used mbr-hybrid-raw and the Tails installation documentation that explains how to boot on a Macbook if we select "MacOS", on the documentation. <GNUtoo>jlicht: once you manage to produce something that work, you could look into the "bootx64" trick, where you can put the generated file in a given location, and it will take precedence over the rest. <GNUtoo>(the Guix official documentation explains it in the part about ‘grub-efi-removable-bootloader’) <h4>LANG=US file /gnu/store/chm6qhg4knlxrmv0wps6zywc4a91aj87-parameters && LANG=US file /var/guix/profiles/system-64-link.new/parameters && LANG=US guix system list-generations | grep Generation\n/gnu/store/chm6qhg4knlxrmv0wps6zywc4a91aj87-parameters: ASCII text, with very long lines (519), with no line terminators\n/var/guix/profiles/system-64-link.new/parameters: symbolic link to /gnu/store/chm6qhg4knlxrm <h4>v0wps6zywc4a91aj87-parameters\nGeneration 63 Aug 29 2024 11:04:11 (current)\nguix system: error: open-file: No such file or directory: "/var/guix/profiles/system-64-link/parameters" <h4>If Guix is unable to list it, will it be able to boot on it, as is? <apteryx>lilyp: is it still time to merge the udev change to gnome-team? I haven't heard your thoughts on my last message; it seems we're a bit circling around :-) <lilyp>yeah, sorry, I find it hard personally to reach a good conclusion on that matter <lilyp>gnome-online-accounts appears broken currently, so I don't think there will be a merge this weekend <apteryx>it seems to be the pluses of preserving our custom env var mechanism is a bit in the abstract; and could always be reinstated if we find out it was satisfying someone's need. <apteryx>we could also leave the patch alone currently instead of simplifying it out, but it'd be akin to dead code to me (not used by the udev-service-type or anything else in Guix). <apteryx>ready to cause friction on the next update (sometimes patches need rebasing) <barreljill>Guix, it is time again to promise I'll read the manual. <barreljill>My next question, however, is how I should go about learning the documentation for the configuration and service types that are included with guix. <mirai>just skim through it and see what interests you <mirai>and use others system configs for examples (if available) <barreljill>Are they also listed in the general manual, or are they individually documented in the git repo structure somewhere <mirai>its (almost) all in the manual afaik <yelninei>ACTION has a gcc again, but some gnulib tests are failing <apteryx>lilyp: looks like the dark style is not working in one gnome-team branch <apteryx>it boots and works at least though, so it's polish at this point <lilyp>what about the background? I think you asked me that earlier <apteryx>ACTION was trying to use the qemu vm with '-display spice-app', which works if you have virt-viewer installed, but oddly the copy-paste sharing doesn't seem to work <ieure>I'm inclined to rebase and push it unless someone has feedback on it or tells me not to do that. <mirai>ieure: (quickly skimming through that patch) I think your shepherd-service 'modules' field is incomplete <mirai>you might want to cons* your additions to that list <mirai>also, I'm not sure about your use of make-kill-destructor when your 'start' doesn't use make-fork+exec nor returns a pid/integer <ieure>mirai, Hmm, okay, I'll take a pass through it. Thank you for the feedback. <mirai>at least in the case it fails, I seem to recall that start can return #f and not be "failed" but I might be wrong <mirai>fork+exec returns a pid/integer so that case is ok <mirai>and is the cons'ing of DISPLAY really necessary? is it not already present in (default-environment-variables) with the right value? <ieure>mirai, Looking at existing stuff in gnu/home/services, no services that specify modules cons onto %default-modules, they just specify what they need. <ieure>mirai, And this service works without doing that, I've been running it from my personal channel since before I send the patch. <Rutherther>mirai: no, DISPLAY is not present in default-environment-variables <Rutherther>mirai: it does return the pid, it returns #f only if XDG_CONFIG_HOME/jellyfin-mpv-shim/cred.json doesn't exist <mirai>sure, though I can't shake the feeling that there's got to be some reason modules has %default-modules as its default <Rutherther>ieure: I would suggest falling back to $HOME/.config if $XDG_CONFIG_HOME is not defined <ieure>Rutherther, Makes sense, I can do that. <ieure>If the (fork+exec-command) doesn't run for whatever reason, the service doesn't go into a started state, so the stuff in the stop form doesn't matter. <Rutherther>ieure: also I think it would be better if the documentation mentioned, at least in parentheses what the actual decision is rather than saying you need to launch it to obtain credentials. At least I assume there are some options to change path it will save the credentials to, so it might be confusing to users that wouldn't choose this default path <mirai>ok, then disregard my comment on fork+exec <aure84>Hello. Is there any way to allow a superbuild (i.e., the underlying build system downloading dependencies) on a `guix build`? <ieure>Rutherther, There's no option to change where the credentials get saved. <ieure>Rutherther, There's some discussion about this in debbugs. If you launch it without having added a Jellyfin server and entered the credentials, it starts up and asks you for them. This is a bad first-run experience after having added the service IMO, so the service doesn't launch automatically unless you've run it manually at least once and aded your JF server(s). <ieure>I could be persuaded to change this, but having run it for a year or more, I believe it works well. <PotentialUser-36>Hello. I am having some trouble running PDF viewer zathura. It errors with a strange message that makes me thing there is some problem with the package? <PotentialUser-36>Could someone please take a look? I think I have the plugins it mentions installed, it simply does not look for them at the right place. Or is something wrong on my system? <hapst3r>podiki: hi. you happen to be here? I am just browsing the public logs to find out if someone got the debbugs/emacs workflow just right and saw you wrote about it. Have you ever managed to get it working the way you want it to? I am particularly interested in opening a new issue :D <hapst3r>PotentialUser-36: are you in the same command line you used to install the program with? If so, have you re-sourced the profile? <PotentialUser-36>Wait... yes, I tried in the same and in the other. But I tried re-sourcing the profile and it works now. <hapst3r>what I am trying to say: when you install a new package, you are asked to execute two lines in the command line which look a bit like "GUIX_PROFILE/..... $NEWLINE . $GUIX_PROFILE" <hapst3r>the CL tells you when it is required <hapst3r>I don't know all the cases, but if you install a new executable program, you will have to do it <hapst3r>Whenever you install a program, you create a new profile generation <hapst3r>However, in the command line, you are still using the current profile generation, which does not yet include the new binary <hapst3r>normally, you should not have this problem when you open a new shell session, because this would already have loaded the new profile generation <lfam>Actually, you don't need to re-source your profile every time you install a new package. <PotentialUser-36>Hmm... I see. It can be a bit annoying. I'll try to learn to live with it. <lfam>hapst3r: If you find that you have to do that, then something is set up incorrectly <PotentialUser-36>lfam I think hapst3r said it was some times, when installing a new executable. <hapst3r>lfam: this is certainly possible, however I noticed that rather often -- though not always -- I am asked to re-source the (new) profile <lfam>Yes, but there's no case where it is necessary, as far as I know. And I've been using Guix for a very long time <lfam>I'm trying to install those zathura packages now to see what happens <lfam>PotentialUser-36: Are you using Guix System? Or Guix on another distro? <lfam>Okay. Have you installed any other packages yet, for the user you are currently working as? <lfam>I'm testing your zathura thing now <PotentialUser-36>I installed zathura and it complained it needed another plugin for PDF reading. Then I installed one plugin, it did not work, then I installed another. <lfam>I have to actually install the packages first ;) <lfam>While they install, I'll say that the only case I know where you have to source your profile is after the first time you install a package for your user. Before that, your user's profile doesn't exist, and you have to either source it "by hand" or open a new login shell, for example with `bash --login`. <PotentialUser-36>But sourcing the new profile made it work for me. But some times I do not get that message. I was trying to learn why. <lfam>I do think that something special is going on with Zathura and its plugin system, because it looks up its plugins "in the environment" using the $ZATHURA_PLUGINS_PATH environment variable <lfam>So, in this special case, having to source the profile or open a new login shell would be expected <lfam>But, it should only be necessary the very first time <lfam>And definitely not necessary when installing a new package <lfam>Does that make any sense at all? :) <PotentialUser-36>Oh! So the package sets a new environment variable. Okay. Yes, it makes sense. <PotentialUser-36>But, by opening a new shell window, would it not load this new profile, with the new variable? <lfam>The PATH variable and the ZATHURA_PLUGINS_PATH variable are not especially different. Both are set via the same mechanisms, which is your 'profile' file. Either ~/.bash_profile, ~/.zprofile, or even ~/.profile in some cases. This is sourced by login shells, not interactive shells. In Guix the difference between these is actually salient. <lfam>You can experiment with the difference by doing things like `bash` and then `env`, compared to `bash --login` and then `env` <lfam>If Zathura worked for you after sourcing your profile or logging in again, then I won't actually test it here :) Is that okay? <PotentialUser-36>I do have some more questions, if I may. For example, I understand there is a reboot --kexec. <PotentialUser-36>When I run it, the screen turns off, any external media is unmounted and power off... but nothing else happens. No reboot. I have to do Ctrl_Alt-Del to return the machine to a usable state. Is that an incompatibility issue or am I expecting the wrong thing? <lfam>In order to properly set this ZATHURA_PLUGINS_PATH environment variable throughout your session (for example, your graphical login), you'll either have to log out fully or log back in, or maybe your graphical environment can re-login "live". Annoying but that's Unix! <lfam>PotentialUser-36: That's not expected. It's supposed to reboot properly, just a little faster than normal <lfam>What does Ctrl Alt Del do for you? I've never used it on Linux <lilyp>I haven't tried Ctrl-Alt-Del yet, but I do get that reboot --kexec is stuck sometimes <lilyp>It probably has to do with swap space, given that it only happens when excessive amounts of RAM are in use <lfam>I have no idea how it works <lfam>(Don't need to know now) <PotentialUser-36>lfam OK, that is a good question. Right now I am a bit afraid to use it since I have to verify and send my PDF. But /maybe/ I'm not on Linux anymore. Maybe I am at BIOS land (do we still have BIOS? EFI or UEFI land, then). It takes just a second for the start-up screen to display. I think the current OS powered down and tried to start the new <lfam>Well, does the regular `reboot` work consistently for you? <PotentialUser-36>lfam The regular reboot works wonderfully well. I was just thinking if I should write a bug report or something. <lfam>Maybe the hint can get smarter, I don't know <PotentialUser-36>Where should I post it to? And what log file should I look at, to collect more information? <dariqq>PotentialUser-36: In my case after a kexec i am at a black screen for the LUKS prompt and after typing my pw into the void i have to manually adjust the screen brightness to wake up the display <lilyp>bug-guix, look at kernel stuff <PotentialUser-36>dariqq Oh! Yeah. I have an encrypted disk! Maybe it is prompting for the password and I cannot see it. Good one! I shall investigate it. Thank you. <PotentialUser-36>Here is another issue (yes, I have been collecting them all for some days ;-)) <PotentialUser-36>1. open a terminal window. Make it narrow (less than 80 columns -- not sure what the magic number is) <PotentialUser-36>3. check the first line of that output. On my system, it says the version number, not the name of the package. <PotentialUser-36>4. scroll down one line and scroll up one line: the name of the package now shows up at the top and the version number (second line) is gone <PotentialUser-36>I don't recall `less` giving me trouble with lines wider than the terminal, but I think there is something on the output of `guix package` that makes it lose track (the colors?) <lfam>But yeah, could be something wrong with our terminal formatting. Another bug report is worthwhile <PotentialUser-36>lfam Oh, I did not think it was so long. I did not expect it to be blocked. Thank you for the notice. I was unaware it had been blocked. <lfam>Yeah, the server detects repeated messages and silences the user momentarily. To help prevent smap <lfam>Your last message that was delivered began with "I don't recall `less`" <dariqq>lfam: I have had this issue open for a while #72119 not sure if you saw it. A pinned v6 header would be great to avoid pointless rebuilds <lfam>Is there a patch for that yet? <dariqq>Not that I know of. I would be in favour of bumping the default headers but that rebuilds litterally every package <PotentialUser-36>I am aware that kernel 6.13 is available on Guix System. My `guix pull` and `guix system reconfigure` do not pull it. Is there something I should do? <lfam>Yes, and it can be pretty disruptive. It may be better as part of a 'core-packages' team branch, dariqq. It's from the kernel, but it's so low-level that it really is core, if I remember correctly <lfam>PotentialUser-36: 6.12 is currently the default package named 'linux-libre'. If you want to use 6.13, you can use 'linux-libre-6.13' <lfam>We usually delay these updates a bit to give the new release series a chance to find bugs <dariqq>lfam: agree, the other solution would be to add a second (or i guess now third) pinned header package resp update the 5.19.17 ones such that it works for libbpf (and whenever gnome-team is merged also mutter) <hapst3r>I accidentally opened two issues. Is the correct way to deal with this to send a control message to close the issue which is not needed? <lfam>dariqq: I don't understand the "resp" abbreviation <hapst3r>but will it take some time to display in debbugs? Because it currently seems like both issues are open, even though the "closed" issue is displayed as closed when I "enter" it (display it in the GNUS group buffer) <hapst3r>(seems that way in the *Guix-Patches Bugs* buffer), because the State is "normal,patch" <dariqq>lfma: I meant "or" but somehting got wrong when i restructured my message <lfam>That's the canonical reference for this information <civodul>*and* i can add current committers as “collaborators” there, so they can do it as well <civodul>the goal being to allow folks to try out Codeberg <ekaitz>civodul: we should make a pr to forgejo so they support org in READMEs <ieure> ekaitz, It's supported, but like most of these things, it's not great support. <ekaitz>ieure: oh so it's probably that it doesn't detect emacs hints (what are they called?). Our readme doesn't have an extension! <ieure>ekaitz, File variables, if you mean there's `-*- mode: org -*-' on the first line. <ieure>Yeah. Not surprised they don't support that. I wonder if they'll omit the TOC if I put `#+OPTIONS: toc:nil' in my README.org header <PotentialUser-36>civodul So I could create a pull request at your codeberg repository and you then merge it with the official repository, instead of sending a patch to the official repository directly? <hakayova>Hi there, I am trying to execute `guix system reconfigure` command using the system.scm file recommended by systemcrafters.net. However, I get a git error: Unsupported url protocol. Any ideas on how to fix this? <luca>got a link to that system.scm file? <hakayova>luca: I could not see a channels.scm file there. There is only linux.scm file which contains firmware. <luca>there's a readme which is quite important <luca>welp, that's all my guix knowledge out the window. Hopefully someone who knows more can chime in <ieure>hakayova, Can you please paste the full output you're seeing when you `guix system reconfigure'? <ieure>civodul, Interesting, my PR didn't close when you pushed the changes. And Forgejo thinks the "#2" in f9b1e548c95a115e2bb143d0f4b1632a600f32da references it. <ieure>hakayova, Thanks. Your channel definitions are extremely messed up. <ieure>"Updating channel 'guix' from Git repository at '/home/ludo/src/guix/+version-1.4.0/'..." <ieure>hakayova, Could you also paste the output of `guix system describe'? <civodul>ieure: yeah, i had to click (!) on “Rebase” so that it would notice that it had been manually merged <hakayova>This is a VM from the official qcow2 image. All I did was `guix pull` after the VM launched up. Please see the output of `guix system describe`: <hakayova>Generation 1 Dec 18 2022 20:42:59 (current) <hakayova> file name: /var/guix/profiles/system-1-link <hakayova> canonical file name: /gnu/store/9yjn29li3pdgqw10dxq8ww99drg4lv72-system <hakayova> root device: UUID: 38af4c98-f6b1-2062-c253-499138af4c98 <hakayova> kernel: /gnu/store/3qdad0k7wvwl09wah246q7fvsb1hbr0x-linux-libre-6.0.10/bzImage <hakayova> configuration file: /gnu/store/9n1vby8zb8kbjy5rfckaqifhdvlgy0i2-configuration.scm <ieure>hakayova, Please use a pastebin, you'll get kicked if you flood the channel. <ieure>civodul, The PR will close automatically if the commit ID lands in the target branch, but it ended up there as 70a827931fa2e82fc9f4c22aa2830f179e625068 and ace32091e11b612318111f8d87251d6dc5fe9831 in my PR. <graywolf>Hello Guix, I have an interesting problem. I have this simple shepherd service: https://paste.debian.net/1350148/ . However when I try to reboot, I see "respawning apcupsd" in the log as part of the shutdown, and than the shutdown just hangs, becaues there are still running processes. <graywolf>Any ideas how to even debug what is going on? <ieure>hakayova, Strange. Best option here is to run `guix pull -C channels.scm' (replace "channels.scm" to the path of whatever contains https://pastebin.com/TP6mRSqu on your disk). <civodul>ieure: yes, but that’s always going to be that way due to signatures and signed-off-by <ieure>civodul, Unfortunate. That can be sidestepped with fast-forward merges, but the pace of development is likely too high for that to work. <hakayova>ieure: Thank you, it seems to be working! <ieure>civodul, I saw that you can configure a signing key for merges in Forgejo now, is it feasible to mint a key for that and use merge commits to ease things? <ieure>I personally dislike merge commits, but it might be a reasonable path. <luca>It's a read only mirror afaik <ieure>luca, The goal is for it not to be. <luca>in that case wouldn't a rebase merge be better? (I assume forgejo supports those at least) <ieure>luca, Yes, it would. I'm not sure what happens to the commits when Forgejo rewrites them. <ieure>hakayova, Great, glad to hear it's working. <ieure>luca, It's a fast-forward, not a rebase. <luca>The branch from where the PR is made does not have the same commit ID of course. But that's the same as email flow <ieure>luca, You'd have to commit to the target branch of the PR after opening it, then rebase. <luca>I did, the "dawg" commit doesn't exist in the branch from where the PR comes from <ieure>Which will break `guix pull'. <luca>ah, that's what you meant. You are right <ieure>So, that means we cannot use any of the built-in merge stuff unless Forgejo support in this area improves. <luca>yeah, same type of support as github I suppose <ieure>I don't know what GH has for this these days, they are dead to me. :) <luca>Just comparing to another git forge. I am not familiar with any forge that lets you push gpg keys for merges <craigbro>This is a chronic problem with forges that synthesize commits <ieure>It's solvable if we selfhost, since it is configurable at the instance level. <graywolf>If we selfhost, we could even get the emails working (Forgejo supports it, codeberg has it off) <craigbro>but that's leaving code signing keys on a public accesible server, and asking devs to trust it <craigbro>it's a degradation of current code signing properties <craigbro>unless I'm totally missing that there is already some kind of automation that has it's own code signing key in guix infra <hakayova>luca: `guix pull -C channels.scm` completed. There was a minor error message at the end stating /root/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/etc/news.scm:40:1: error: invalid channel news entry <hakayova>However, after it finished, executing the `guix system reconfigure config.scm` resulted in the same error as before :(. <hakayova>ieure: Please see above messages I accidentally tagged luca. <hakayova>I have to leave now. Thank you for your help. It is very frustrating, I spent more than 2 hours today for this and wasn't even able get it work. I appreciate your time and willingness. <ieure>hakayova, Remember to run `hash guix' or `hash -r' or log out/back in for your account to see the guix you just pulled <ieure>craigbro, I don't think Guix has any kind of signing infra. I'd wager that most committers' keys are not well-secured, so IMO the risk is more from being a larger / easier to access target than anything else. <ieure>Not me, of course, my key's on a hardware token. :) 
