IRC channel logs
2025-03-13.log
back to list of logs
<graywolf>I am trying to configure kerberos, would anyone know what the following error could be: Wrong type to apply: #<syntax-transformer krb5-realm?> <lilyp>are you using this as a function in a map or similar? <lilyp>if so, write (lambda (x) (krb5-realm? x)) <graywolf>The realm-list? procedure in gnu/services/kerberos.scm has this part: (and-map (lambda (x) (krb5-realm? x)) val) <graywolf>I need to move the procedure below the define-configuration. <graywolf>I wonder whether this actually works for anyone. <graywolf>Thanks for the tip, you have pushed me in the right direction :) <lfam>sneek: later tell eikcaz: I was just editing the text you gave for a Guix news entry. Here's what I have: <https://paste.debian.net/1362776/>. Then I saw your message in the logs about simplifying it. Tell me what you think about my proposed text (I'm unsure about the paragraph beginning "Note that..." because it doesn't seem to resolve) <sneek>Welcome back lfam, you have 2 messages! <sneek>lfam, eikcaz says: I think I figured out the path with the least friction: if someone sets `config-file' then the service will just do (approxiately) "mv ~/.config/syncthing/config.xml ~/.config/syncthing/config.xml.bak", then the news entry can just explain that their device ID might change and how to get it back (and maybe a similar note in the docs for users that used ~/.config for unrelated reasons). <sneek>lfam, eikcaz says: Thinking about it more, I think it's more important to get the current version of the patch through, and worry about the .1% after the new bindings are pushed to master <theotherone>Hello, I am trying to change/add a desktop entry here: /run/current-system/profile/share/wayland-sessions. What is the preferred method of doing this? Thanks for any help :) <Rutherther>theotherone: the preferred and only way is to make a package that has the session under share/wayland-sessions, and then you put it either to your packages or make a service for it that will extend the profile-service-type. Most compositors already have that so just putting them to packages is fine <theotherone>Ah, okay. My issue is that the hyprland package has a desktop entry that calls the Hyprland executable directly instead of wrapping it with dbus-run-session. For now I've changed the folder where sddm looks for the desktop files and created a custom desktop file there. Thanks for the help! <Rutherther>theotherone: yeah, you will have to replace your current hyprland package with a new one that will change that desktop file <hako>theothornhill: Try to use home-dbus-service-type. <rekado>I'm using sway and screen sharing in the browser has stopped working at some point. I have installed xdg-desktop-portal, xdg-desktop-portal-gtk, xdg-desktop-portal-gnome, and xdg-desktop-portal-wlr in the system profile. <rekado>I also have a file ~/.config/xdg-desktop-portal/sway-portals.conf, which sets org.freedesktop.impl.portal.ScreenCast=wlr and org.freedesktop.impl.portal.Screenshot=wlr <Rutherther>rekado: For debugging this particular issue if it worked already, I would start xdg-desktop-portal with -rv flags, it will replace the running session. It's located under libexec folder of your profile since you have it installed. You could see what's wrong like that. It should give you an idea what is being used under your session <Rutherther>rekado: For debugging this particular issue if it worked already, I would start xdg-desktop-portal with -rv flags, it will replace the running session. It's located under libexec folder of your profile since you have it installed. You could see what's wrong like that. It should give you an idea what is being used under your session <Rutherther>rekado: note that it is possible it will actually start working right away if you start it manually in case you forgot to import your environment to dbus. <rekado>Rutherther: thanks for the help! The verbose output showed that the portals could not be found (127). Turns out that I must start sway with "dbus-run-session sway". <Rutherther>rekado: yeah, either that or guix-home's dbus service that will start it automatically when session starts <rekado>huh, I do have home-dbus-service-type in my home services. <rekado>(perhaps this is related to my failing auto-login via mingetty-service-type.) <Rutherther>rekado: then something must be wrong there. You shouldn't have to use dbus-run-session (and shouldn't even, you won't be able to communicate with home services that use dbus properly, since you are in a different session than they are) <jA_cOp>rekado: not sure if we had the same problem, but, I ended up solving it with this in my sway config: exec dbus-update-activation-environment WAYLAND_DISPLAY=$WAYLAND_DISPLAY <jA_cOp>I don't run sway with dbus-run-session, I use home-dbus-service-type <jA_cOp>also I think home-dbus-service-type logs to ~/.local/state/shepherd/dbus.log <Rutherther>you should also import your XDG_CURRENT_DESKTOP to dbus activation env if you want portals to work properly <Rutherther>(and that should be set to sway if running sway session) <mange>Anyone around who does Ruby development on a Guix system? I've been working on https://sr.ht/~czan/guix-ruby/ lately, which ingests a Gemfile{.lock} file and produces a Guix manifest to match (vaguely like bundix in the Nix world). I'd love to get some feedback on whether it works for people beyond the cases I've tested. <rekado>I have this in my startup programs: dbus-update-activation-environment DISPLAY SWAYSOCK WAYLAND_DISPLAY XDG_CURRENT_DESKTOP=sway <bjoli>I have a channel for a package I want to install already at guix system reconfigure. Do I add this channel to the root users channels or is there a directory in /etc? <Rutherther>bjoli: if you do sudo guix system reconfigure, your user's guix is used. You don't need to add this channel to the root user channels nor to the global /etc/guix/channels.scm one. Just add it to your own user <bjoli>Is there a risk that /etc/channels.scm is overritten? Otherwise that seems like the place. <Rutherther>it is /etc/guix/channels.scm. Yes, there is that 'risk' if you configure your system to place the file there instead. But it is not relevant file for your particular use case. <Rutherther>it is /etc/guix/channels.scm. Yes, there is that 'risk' if you configure your system to place the file there instead. But it is not relevant file for your particular use case. <bjoli>Is that how folks do it? It feels icky to have system stuff in my home dir... <bjoli>I might just be old fashioned <Rutherther>bjoli: what do you mean to have system stuff in your home dir? <bjoli>Separations of concerns I guess. My package is used in the system install. The channel should be used in the system channels. <apteryx>rekado: w.r.t. gum_test.html screen capture, I get: "NotAllowedError: The request is not allowed by the user agent or the platform in the current context." <Rutherther>bjoli: the channels are depicted inside the guix instance itself, whatever instance you use for guix system reconfigure determines the channels used. If you want them separated you of course can do that, but it won't be in the way you are trying. The channels.scm files are only instructions on how to build a guix instance, not the channels used per se. So you will still need to obtain the channels, ie with guix pull under root or just guix... <Rutherther>... time-machine -C path/to/channels.scm as any user. So you can store the channels wherever, /etc/guix/channels.scm is irrelevant. That one is used mainly to sync the channels obtained from guix pull across mutiple users, not to separate channels between users. <hako>apteryx: Re: tmpfs /run: Found out it's just mkdir-p/perms that doesn't support symbolic link (/var/run), no need to change file-system-mapping at all. <apteryx>what happens when /var/run gets via file-system-mapping for least-authority-wrapper? <apteryx>does that end up exposing both /var/run and /run? I wouldn't have expected so <hako>hmm only need to change file-system-mapping source when it's "/var/run" I think <apteryx>I had changed dbus to use /run, and replaced all /var/run to /run in the jami services/its test, and the jami-dbus-session was now running but something was still failing. <hako>dbus is using /run already I think? <hako>looking at (gnu services dbus) <janneke>guix home container keeps giving me: error: mkdir: Read-only file system: "/tmp/guix-directory.k8Vsz6/real-root" <janneke>i'm even using --share=/tmp --share=/ <hako>apteryx: mkdir -p {/run,/mnt}/test && mount /tmp /run/test && mount /var/run/test /mnt/test <janneke>ah, those --share's seem to be the problem instead of the fix <apteryx>hako from what I can see it was still using /var/run/dbus but that was made a symlink to /run/dubs <apteryx>/run/dbus, which could now be simplified output <janneke>--share=/home/janneke --expose=/gnu work much better <apteryx>see commit 6c2a6033b4bd5f74463cb0121e15b9cb4fc5ff6d <apteryx>hako ah you already did clean that symlink <hako>The minimal solution is changing `(mkdir-p/perms "/var/run...)` to `(mkdir-p/perms "/run...) <hako>yes, that's the reason I want to unify them <apoorv569>not very clear what I am doing wrong? do I have to gexp/ungexp something in file-append here? <apoorv569>`#~(file-append #$config "/" config-file)` doesn't work either.. <Rutherther>apoorv569:what is the full error and trace for the second thing you sent now? How are you using this procedure you sent in the service? <Rutherther>apoorv569: actually should be string-append in this second case, not file append <apoorv569>string-append? but how would that add the config file to the store? <apoorv569>does the computed-file it self does that? if so then why wireguard service does file-append? <Rutherther>apoorv569: It is the ungexping that adds it to the store <apoorv569>just ungexping something adds it to the store? <Rutherther>apoorv569: #$(file-append a-computed-file "XYZ") is the same as (string-append #$a-computed-file "XYZ") <Rutherther>apoorv569 not quite, it has to be evaluated all the way upwards, but it is what is triggering the build kind of. <Rutherther>apoorv569: I am not completely sure, but it could be. Please send alao how you are using it in the service. Also, is there a particular reason you are making a folder instead of just having it a file at #$output directly? Seems to just add unneeded complexity <apoorv569>now I get unbound variable ungexp is doesn't make sense I have am imported (guix gexp), its something else for sure.. <apoorv569>Rutherther: I was following wireguard-service as it stores the config in the store, if I store in the `#$output` would mean where coturn will be installed? <Rutherther>apoorv569: it makes sense you have ungexp inside ungexp <apoorv569>removed both #$ except the one before #$(file-apend.. still getting same error.. <apoorv569>OK it was in another file seems to be fixed now.. <dthompson>does anyone that does go packaging know what to make of the build error "build constraints exclude all Go files in ___"? <apoorv569>I was doing in another service I'm testing along with coturn in a vm.. was doing same ungex inside ungexp in the shepherd service <dthompson>I am very close to having a build of forgejo-runner, something that might be of interest to many <dthompson>but since I'm not a Go programmer this error has me confused <ieure>dthompson, I am a Go programmer and I have no idea what that error means. <ieure>dthompson, Guessing some of the dependency bounds or go.mod / go.sum stuff is misaligned. <dthompson>the full error line is: imports github.com/docker/cli/cli/compose/types: build constraints exclude all Go files in /tmp/guix-build-forgejo-runner-6.2.2.drv-0/src/github.com/docker/cli/cli/compose/types <dthompson>docker-cli is not a proper Go module. doesn't have a go.mod file or anything. so I'm guessing something needs tweaking but I'm not sure what. <dthompson>I'm 25 packages deep into this little project lol <jA_cOp>Is there a convenient function to prepend a shebang line to a script that doesn't have one that I could use in a build phase? Maybe some clever use of substitute*? <dthompson>yeah, the docker bits have been the most annoying part of this project <jA_cOp>I ended up with just a patch file to add a generic shebang line that then gets patched by the standard phase <hanker>Why's farstream crashing on test phase? <rekado>I've disabled auto-login and now everything works fine without dbus-run-session. <rekado>I'd like to give the new gnome a try, but after login on gdm it fails to start the gnome session <Rutherther>apoorv569: I will take a look in like 2 hours, but I think the issue is with the string append nested in the file append. Imo its completely unnecessary as you can just use the store path itself, no need to make a folder and put the script to it <fnat>Hi, I've installed fprintd with '(service fprintd-service-type)' and reconfigured. What puzzles me though, is that I don't seem to find mention of the service if I do 'herd status' (as root). <hako>It doesn't contain a Shepherd service <hako>$ guix system search fprintd <hako>It extends dbus and polkit <fnat>hako: Brilliant, thanks. And I install the client separately, I guess? I mean I'll need a client to register fingerprints for example. <fnat>Yep, so it seems, fprintd. <avalenn>I have external disk with a great part of /gnu/store I need. Is there any way to use it and avoid redownloading ? <Rutherther>avalenn: only if it also has the database (so /var/guix folder). And even then I dont think guix has a built in way to copy from one store to another from one machine, so you will have to use two and do guix copy / offload build / use it as substitute. Maybe could be done on one machine with a container / vm that will behave as second machine with the store mounted <avalenn>Rutherther: ok, so not really simple. I will re-download this time. Studying this perhaps an other day. <Rutherther>avalenn I am afraid not. Guix is coded to work with one store I am afraid. While technically possible, it will involve copying over both the paths and correct db rows <aure84>Hello. Does anybody know how would I go about adding a new fetch method locally for a specifi package? <Rutherther>apoorv569: your make-forkexec-constructor has everything inside file-append, 1. file-append accepts only one file-like argument, 2. it doesn't make sense here to append everything, you need to provide element in the list for every argument <ieure>aure84, Not sure what you mean, what are you trying to do? <aure84>ieure: git-fetch will get rid of the repo index. I need it :) <aure84>I'm creating a package for a CMake superbuild. The CMake infrastructrue is expected to pull dependencies online. Instead, I can direct the repo url to file:// insteado of https://. The project allows to define build variables that override the repo url <aure84>but to clone a repo, it needs to be a repository, it is not enough with the data content <ieure>This is a very inefficient way to do it, is there no way to point CMake at the result of the clone? <aure84>not without heavy upstream changes, which I would avoid. <ieure>You have limited options, fixing upstream is really the right thing to do here. <aure84>I have tried to define my own git-fetch-src method and pass it to (origin (method, but it is not enough, the methods seem to be registered and there is a check <aure84>ieure: even if we come with something hacky, it's better than fixing upstream. Upstream is not really made for a non-superbuild building process and the only offline option is to point to a local repo to do the cloning <ieure>aure84, I'm not sure. If that's the case, you'll have to fork all of Guix. A Git download method which works how you describe likely wouldn't get accepted, since it'd break reproducability. <aure84>can I not override some key definitions locally, just for that package? <podiki>ah i can't find it but there were some procedures in a patch series to automate this for cmake <ieure>aure84, If the issue is that either origin or package don't recognize arbitrary download methods, no, you cannot fix that in a package. <podiki>either in mesa or hyprland patches i thought, but can't find it <ieure>aure84, And even if you could, your package wouldn't be reproduceable, so unlikely to ever make it into Guix itself. <aure84>as an alternative. could I just override some of the phases to do a git-init? <ieure>I guess "wouldn't be reproduceable" is too strong. It would have an exposed mechanism to allow for unreproduceable builds, because with the whole repo cloned, the build could build something different than what the origin specifies. <ieure>aure84, Sure, I guess you could clone a repo, init, add everything, commit it, and copy that to the output. This is, again, unlikely to get accepted into Guix, if that's a goal you have. <ieure>And it'll use like 3x the disk space. <podiki>aure84: also look at other packages we have, plenty of cmake projects that unbundle a bit manually <podiki>sorry i can't give you a specific example, gotta run in a minute <ieure>I will just say that when you're using systems in the way they're intended, things have a certain kind of flow, a feel to them. If you find yourself fighting to do what you want, that's a good sign that you're not using the system in the way it's intended. And coloring outside the lines like that is often a source of long-term hassle. <aure84>ieure: yes, I get the point. I just try to make difficult things possible :) <Rutherther>apoorv569: you will need to ungexp the config-file <apoorv569>Rutherther: this `"-c" #$config-file "--pidfile=")` right? <Rutherther>apoorv569: remove is from srfi srfi-1, you will have to add it to use modules (inside that gexp body of course) <aure84>as I'm not that seasoned in guile scheme...if I go for the `git init` option. A draft of the src-package would be something like (build-system copy-build-system)...(modify-phases (replace 'build (invoke #~(file-append git "/bin/git") "init")). Would something like that cut it? <apoorv569>Rutherther: Works now.. I add `(use-modules (srfi srfi-1))` inside the `(begin` of the computed-file <ieure>aure84, No. Like I said, you also have to `git add' and `git commit', otherwise you're creating an empty repo. And you have to copy the whole tree to the package output. <aure84>Well, you can also git commit, right? <ieure>aure84, Yes, but your snippet doesn't do that, so it won't work. <ieure>aure84, You might also need to configure Git so it knows who the author is. <pastor>Hello, is anyone managing SSH with gnupg? <ieure>aure84, This is also assuming the thing you actually want to build doesn't do any signature verification, checksumming, or pinning to a specific commit. If it does any of that, this won't work, because none of that will match. <aure84>ieure: thanks a lot for the help. I'll play with it and see what I get <apoorv569>Umm.. I don't see the `coturn` service in the `herd status` output.. <ieure>aure84, Good luck, but, I will reiterate that what you're doing is deeply inadvisable. <ieure>pastor, Sort of, I have my SSH private key on a Yubikey and use it via gpg-agent. <anticomputer>hrmm looks like the new gnome-keyring version on guix no longer includes ssh agent functionality? my SSH_AUTH_SOCKET no longer exists, I read some crud about it being moved out of gnome-keyring into gcr-4, what's the preferred turnkey ssh agent for Guix users? <pastor>I see. I'm having some issues with pinentry under the latest gnome update 46 <ieure>pastor, Sounds like you and anticomputer might have the same issue. I don't use the Gnome stuff. <pastor>anticomputer: yeah, the latest update seems to have broken our Guix services <apoorv569>Rutherther: I extended the shepherd-root-service-type <pastor>I is what I have now: `SSH_AUTH_SOCK:/run/user/1003/gnupg/S.gpg-agent.ssh' <pastor>This is what our home `home-gpg-agent-configuration' sets up <pastor>The problem is that the program `pinentry-gnome3' is broken, I think <Rutherther>apoorv569: are you executing herd with sudo then? <apoorv569>Rutherther: I'm testing in a guix system vm and I logged in as root user only. <apoorv569>coturn-config/turnserver.conf file is in the store inside vm <pastor>Using the users home service has the disadvantage that you loose the keyring unloking upon login <pastor>I get this error if I try to run `pinentry-gnome3': <pastor>Failed to get d-bus reply for org.gnome.ScreenSaver.GetActive (2): GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.Shell.ScreenShield was not provided by any .service files <pastor>Could anyone else try if this is a bug that we should report? <pastor>This was definitely not happening in gnome 44 <Rutherther>apoorv569: okay. I don't see any issue then, maybe if you send the full service and system config I will spot something. But not sure really, seems strange. Even more so if you're using the config only inside the shepherd service. Because that means this shepherd service has definitely been evaluated then <pastor>Rutherther: sadly my user config is quite involved. I woudn't want to waste your time trying to find something there. If you have Gnome installed it would help me if you could run `pinentry-gnome3' and tell me if you see the dbus error <Rutherther>pastor: my reply was to apoorv569 btw, I didn't respond to you <janneke>i'm kinda puzzled by guix system container <janneke>for example, there is no /var/log/messages <janneke>and herd status <service> says stopped, while herd status says the service started <janneke>ACTION resumes using guix system vm for now <Rutherther>janneke: I see stopped at both places in your output <Rutherther>janneke: I see stopped at both places in your output <janneke>Rutherther: ah you're right, thanks! <janneke>the stopped list is much larger than i anticipated, that solves already one of my puzzles <Rutherther>pastor: is that error message really a copy of the error? does it really say ScreenShield in the service name? <Rutherther>pastor: is that error message really a copy of the error? does it really say ScreenShield in the service name? <janneke>hmm, maybe i need to give networking access to the container <anticomputer>pastor: so I just added `exec ssh-agent "$@"` for the standard openssh agent to my .xsession and removed the ssh component from my gnome-keyring-daemon explicitly for backwards config compatibility and that works fine as well <pastor>anticomputer: my problem is not really on how are the agents started, the issue I think is that the pinentry popup does not appear <pastor>The cool thing about using the gnome kyring is that you unlock it upon login, no wore passwords needed <pastor>The thing is that the kde counter part works, so this is surely a gnome issue <apoorv569>the coturn user and group is created successfully, the config is in the store, but for some reason the service doesn't show up in the herd status <Rutherther>pastor: interesting. I really can't find where this service is supposed to come from neither why it's required here. But yeah, gnome-shell definitely doesn't have it, so it seems either missing a package to be installed or the gnome shell is missing some options to add this service when compiling. <anticomputer>pastor: ah gotcha, but if you're now using gpg agent, can't you just set a different pinentry program in its config? or you're still using keyring for other secrets? <anticomputer>pastor: i.e. I guess I'm confused why you would still get a pinentry-gnome3 popup if you're not managing secrets out of the gnome-keyring (or unless you've configured gpg-agent.conf to use the gnome pinentry and that's not working), but maybe I'm not understanding the problem <pastor>anticomputer: Yeah, I've configured gpg-agent.conf to use the `pinentry-gnome3' since I'm using the keyring for other secrets <pastor>So I need the popup to check the box of save the password on the keyring <anticomputer>pastor: fwiw I still run my protonmail-bridge secrets out of gnome-keyring and the gnome pinentry popup for that works fine, and seems to be dbus driven (I run it out of a --emulate-fhs container so had to specifically pass through all the dbus crud for it to work) <pastor>anticomputer: hmmm. And what happens if you rung `pinentry-gnome3' in the terminal? What's the output? <anticomputer>pastor: that's just the thing, I dont even have pinentry-gnome3, it's all just gnome-keyring doing dbus crud to grab the passphrase, but hangon I'll guix shell it in <pastor>I mean. I see in the source code of `pinentry-gnome3' that they are trying to call that dbus service. <anticomputer>pastor: just sits there waiting for io like any other pinentry after blurting its hello, and 'GETPIN' pops up the dialog fine <Rutherther>apoorv569: btw you have typo in destructor, but it's not the cause of this issue <gnucode>apparently more work is being done on getting guix system to work on the MNT reform. That's pretty swell. <anticomputer>pastor: it's a pinentry protocol command that instructs the program to fetch a PIN input from the user <anticomputer>pastor: i.e. a good way to test basic functionality at the terminak <pastor>anticomputer: from which package does it come from? <Rutherther>apoorv569: the error can bee seen when you start shepherd manually, I am not really sure how to find it for a container, it's an error that happens very early in the boot. The issue is that config-file is unbound variable. In your string-append in coturn-configuration-file you didn't ungexp it <anticomputer>pastor: just type 'GETPIN' at the pinentry "Hello bla bla" prompt when it's sitting there waiting for io <apoorv569>Rutherther: config-file? the let binding? isn't it just a string? why I need to ungexp it? <pastor>anticomputer: oh. That works. Even with the error <Rutherther>apoorv569: #~(something) means put literally (something) to the output file. #~(#$something) means get what something evaluates to, and put that in the output file. You need to evaluate it to the string. You're passing through a symbol <pastor>anticomputer: so maybe it's a matter of getting gnome to start an SSH session... Like it was doing prior to the GRC changes <anticomputer>pastor: my bounce doesn't have current backlog, what was your error? <pastor>anticomputer: `Failed to get d-bus reply for org.gnome.ScreenSaver.GetActive (2): GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.Shell.ScreenShield was not provided by any .service files' <apoorv569>Rutherther: I thought with gexp you only ungexp a gexp? but I guess it like ungexp everything inside a gexp? <Rutherther>apoorv569: no you don't ungexp a gexp. You ungexp to capture state outside the gexp. Gexp is just quoting, just better. It's like if you did 'something, that is a symbol, as opposed to `,something where you are evaluating something. <anticomputer>pastor: that seems entirely unrelated to anything to do with keyring dbus? what's the expected behavior? i.e. what kind of secret related functionality isn't working for you currently? <apoorv569>It works BTW this.. the service fails to start though.. the log file is empty.. <anticomputer>pastor: on first ssh you should get a popup for your passphrase through gpg agent invoking pinentry-gnome3, on second ssh it should be the agent providing the secret, that works yea? what other secret scenario isn't working? <pastor>anticomputer: `git pull' keeps asking for passphrase since the `SSH_AUTH_SOCK' variable now is not initialized by the `gnome-keyring-service-type' <pastor>anticomputer: noup, that was not working neither <anticomputer>pastor: oh so SSH_AUTH_SOCK is just missing from your env entirely? <pastor>no no, `SSH_AUTH_SOCK=/run/user/1003/gnupg/S.gpg-agent.ssh` this is the value <Rutherther>apoorv569: really running, not starting? can you send /var/log/messages then and output of herd status? <Rutherther>for me the networking service never started running inside a container <anticomputer>pastor: that's what should be managing your ssh passphrases now, not gnome-keyring anything <apoorv569>Rutherther: I am testing using guix system vm.. I can't ssh to the vm even though I used --network. <Rutherther>apoorv569: oh, I just have to pass --network to get the networking service, my bad <pastor>that on one hand. Previously that was managed by `gnome-keyring' which was the one starting the SSH agent <pastor>I would prefer to use the gnome-keyring SSH agent if possible but I guess it's not possible with Guix's `gnome-keyring-service-type' <pastor>Since that one, no longer provides the SSH agent <anticomputer>pastor: yeah I'm tracking, but right now nothing gnome related, except for your pinentry fetch (which works) is using gnome-keyring for ssh secrets, it is entirely gpg agent, so something is broken in your gpg agent config <apoorv569>Yes but the vm gets some weird subnet 10.0.2.15 which I can't access.. <anticomputer>pastor: and it smells like the pinentry program is not properly set for your gpg-agent <pastor>This is the value `pinentry-program /gnu/store/vra4a37jmhv17jvchn2ncxm77gxvsnl5-pinentry-gnome3-1.3.1/bin/pinentry-gnome3` <pastor>It's configured by the guix home gpg service, so it should work <Rutherther>apoorv569: that is the normal qemu slirp user network mode. The default one used with qemu <Rutherther>apoorv569: you need to forward a port for it to be accessible <pastor> (pinentry-program (file-append pinentry-gnome3 <Rutherther>apoorv569: but don't worry about it, I will get the log myself. I asked only because for me it didn't even start running, but that was because of the missing --network switch <anticomputer>pastor: did you set ssh-support? to #t it is #f by default <pastor>anticomputer: The thing is that for the GPG singing key works, so I guess it's really due to the latest changes on the package <anticomputer>pastor: dumb question but, you did do 'ssh-add' for the ssh key yea? <Rutherther>apoorv569: I suppose you forgot about appending "/bin/coturn" in that file-append. It's visible in shepherd's log: "exec of "/gnu/store/hpb0wdzdacj6c61j3x5fhs03hzf3wchz-coturn-4.6.2" failed: Permission denied " <pastor>anticomputer: no, why do I need to? <Rutherther>apoorv569: or not coturn, that binary doesn't exist under coturn. Maybe turnserver? dunno, I don't really know what these binaries do, but just one of the existing ones... <anticomputer>pastor: because you're outside of gnome-keyring passphrase management land now, you're going straight to the ssh agent, so you need to ssh-add it to the agent once and then it will stop prompting <pastor>anticomputer: not so dumb the question then xD <pastor>Alright, with that it seems to work :) <anticomputer>pastor: i.e. it's not the ssh agent prompting you currently, its just ssh because the auth socket did not have a secret cached available for it <apoorv569>Rutherther: Ah! I see.. let me check the binary name. <anticomputer>pastor: that'll teach me not to skip over the small questions haha, cool <pastor>anticomputer: that makes sense. Dammit, you cannot imagine how much I hate agents :'( <anticomputer>pastor: yeah I also preferred having the single agent managing all my secrets, but c'est la vie I suppose <apoorv569>Rutherther: the binary is called turnserver. <pastor>anticomputer: it seems. Would be nice to be able to unlock the passphrases with the loging keyring... <apoorv569>BTW How can I change the network with guix system vm? <pastor>I guess I will have to look into what we should do with the new `gnome-keyring' package <pastor>anticomputer: In any case, I would like to thank your for your patience, you've been very helpful 🙏🏼 <Rutherther>apoorv569: "$(guix system vm ./config.scm -L modules) -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::2222-:22" is a way to get network with portforwarding, so then "ssh user@localhost -p 2222" will give you access to the machine from host <apoorv569>Rutherther: I see. I have virt-manager and a default network created for my VMs can I somehow specify it to use that network? <janneke>ACTION got a lot further using --network --share=/dev --share=/proc --expose=/boot <janneke>the services still don't start, but at least i can start the progrlam <Rutherther>apoorv569: you should be able to, but I cannot tell you how exactly, I know only basic usage of qemu, since slirp does everything I needed <Rutherther>janneke: btw I tried looking into /var/log/messages for a simple system container. I get that file with log messages. So something must be behaving strangely on your side you are not getting that file inside the container <apoorv569>Oh! I always used virt-manager don't know any qemu commands or stuff.. <attila_lendvai>janneke, re "guix home container keeps giving me: error: mkdir: Read-only file system: "/tmp/guix-directory.k8Vsz6/real-root"", did you find out anything about that? i'm getting the same when i try to use guix shell in a shepherd service <attila_lendvai>janneke, more specifically, guix share --container --emulate-fhs <janneke>attila_lendvai: yes, i'm using: --network --share=/dev --share=/proc --expose=/boot <janneke>ACTION quotes from the wrong makefile <janneke>attila_lendvai: I'm using: --network --share=/home/janneke --expose=/gnu --expose=/run/current-system <attila_lendvai>janneke, and that eliminates the mkdir error in /tmp? i don't see how, but i'll experiment. thanks! <janneke>Rutherther: thanks, i'm using my full system config, that's probably a mistake <Rutherther>janneke: still I don't see why you wouldn't get /var/log/messages at all <janneke>attila_lendvai: i believe because before i shared or exposed /, which doesn't play nice <attila_lendvai>janneke, but i'm not exposing /. this is what i do in a shepherd service: guix shell --manifest=manifest.scm --container --emulate-fhs --network --share=/srv/hass=/srv/hass --share=/var/log=/var/log -- bash -c "cd /srv/hass && source bin/activate && LD_LIBRARY_PATH=/lib:/lib64 hass" <attila_lendvai>that error might be a race condition, calling mkdir without -p, or something about changing uid maybe <Rutherther>attila_lendvai: speaking of race conditions, do you have guix as requirement of your service? <Rutherther>attila_lendvai: speaking of race conditions, do you have guix as requirement of your service? <attila_lendvai>Rutherther, guix? the package? i thought that if i reference it in the gexp then it expands into a full store path. that part seems to work, because the previous version references the bash binary from the bash package the same way, and it works <Rutherther>attila_lendvai: no. The guix daemon. It's provision is actually called guix-daemon, I thought it is guix as that is the name in "guix-service-type". <attila_lendvai_>...but it fails when i restart it, not only at boot, so i don't think that's the problem <Rutherther>attila_lendvai_: yeah definitely not the issue then. Still, definitely should be a requirement as your service cannot work without guix-daemon <Rutherther>apoorv569: when ungexping lists, you need to somehow make sure they are actually lists. Currently what you're passing with gexp is "("ip address here")", which means to guile to apply ""ip address here"" with the rest of the arguments. You need "'("ip address here")", so either "'#$ips" or "(list #$@ips)" <Rutherther>apoorv569: that is completely irrelevant. But as a matter of fact it "doesn't make it so", no. It can only be used to check if it really is a list of strings, but it doesn't make it anything. The type is fine, it is a list of strings, the issue is how the ungexping works <apoorv569>do symbols need something extra as well? they are complaing unbound variable THE_SYMBOL <anticomputer>nice, have protonmail-bridge working nicely on Guix and seems my ancient emacs gnus+mu4e config still works swimmingly as well, great <anticomputer>the --emulate-fhs container option really sparks joy when having to quickly hack in outside components <Rutherther>anticomputer: I am using heisenbrige. Is syncing with protonmail-bridge also quite slow for you? ...compared to 'regular' imap servers <anticomputer>Rutherther: not that I've noticed, but I'm syncing through mbsync, it handled 20K+ messages breezingly <anticomputer>Rutherther: regular update sync takes ~0.26s (just timed) <Rutherther>anticomputer: okay, so it's similar, thanks. The thing is that regular imap takes like 2 seconds, but proton ~30 seconds. I guess it makes sense given the nature of it, but it's still quite unfortunate as if I get like a 2fa code, it can take up considerable amount of time <anticomputer>Rutherther: oh I meant like, less than a second, I'm not noticing any real delays <Rutherther>anticomputer: oh sorry I missed the 0., silly me <Rutherther>apoorv569: it's again the same issue, by #$verbose you're actually getting an unquoted symbol. So one fix would be '#$verbose. But I think here you can get away even ungexping the whole cond as you're just checking the value of the verbose from outside environment <Rutherther>anticomputer: that's interesting then. I am not sure where can the delay be coming from for me. I will try the protonmail-bridge at one point instead, maybe heisenbridge is weird somehow <anticomputer>Rutherther: hangon I'll share my hacky container setup in case you just want to try it real quick <anticomputer>Rutherther: note s/gnome-keyring/password-store/g if you want protonmail-bridge to use pass instead <jA_cOp>I've had good luck in the past with hydroxide instead of the official protonmail bridge, maybe a good alternative. It is packaged in Guix <anticomputer>jA_cOp: ah nice, I was looking for a packaged alternative but didn't find one included, will take a look <anticomputer>although I guess could just package the actual bridge since it's OSS Go iirc <anticomputer>not sure about the license status, probably incompatible <apoorv569>OK, I got the coturn service to work.. haven't tested like calling or anything but the service is running without errors and is reading the config correctly.. <apoorv569>I added service extension of account-service-type so the turnserver runs as turnserver user.. how do I confirm if shepherd is running coturn service as turnserver user? <ieure>apoorv569, Well there you go. <jA_cOp>anticomputer: I'm certainly no expert but, the only thing I'd wonder about is if the included icons are trademarked? not sure how Guix deals with that <ekaitz>hi! i'm doing guix gc but then I go to a folder, run guix shell and it just jumps to the env. Shouldn't it need to install things? Is it caching stuff? <Rutherther>ekaitz: so not even the profile is being created? could mean you are already running instance of this shell as that is a gc root <ekaitz>i tried to guix gc -D the paths that are not being reloaded but it says they are in use and i don't understand what is going on <Rutherther>ekaitz: the paths meaning the profile created by the shell? <ekaitz>i just saw a notification when I hit reboot, was it you Rutherther ? <ieure>ekaitz, Of course it didn't help, rebooting doesn't remove stuff from the store. <ekaitz>ieure: sure, but it closes shells that might be hidden somewhere <ieure>Right, none of which is removing stuff from the store. <ieure>Which is where `guix shell' looks for stuff first. <ekaitz>yep, but if i guix gc right after the reboot, it might help <ieure>ekaitz, Anyway, if you're running `guix shell blah' and it's not downloading, it's in the store. You can figure out the store path and `guix gc -D /gnu/store/...' and it'll tell you what's referencing it. <Rutherther>ekaitz: yes, me. I was asking if by 'the paths' you mean the profile the shell created <ieure>ekaitz, Is this a problem, or a curiosity thing? I'd think that you want to use whatever local copy you have instead of downloading another. <ekaitz>well I changed the guix.scm file and when I guix shell into the env, i still have the same packages <ieure>In what way did you change them? <ekaitz>changed the version, the name and the hash <anticomputer>ekaitz: maybe use --pure and see you're not pulling in from some system wide profile? <ekaitz>anticomputer: it's not pulling it from the system, but i'll try <ekaitz>maybe the issue is that he guix.scm file is loading other file and it's autocompiling it and using the cached guile module? <Rutherther>ekaitz: if that is the case, gc'ing them is not going to fix it. What specific changes have you made? <ieure>I suspect it's something simpler than that. <ekaitz>ieure: probably something very stupid, because I am very stupid <ekaitz>Rutherther: version, name, hash, source... <ieure>ekaitz, Can you paste the guix.scm before & after changes? <Rutherther>ekaitz: if you've changed version and name, the paths in store should've definitely changed. So you're saying if you enter the shell and look into $GUIX_ENVIRONMENT to check where the profile files are symlinks to, there are paths to the previous versions? <ekaitz>i whereis'ed the file and it's still the old one <ieure>ekaitz, And how are you running this? <ieure>Just `guix shell' in the same dir as the guix.scm? <ekaitz>it was the --rebuild-cache, aaaargh!! <ekaitz>i just whereis-ed and it's loading the proper m2-planet-mine, instead of the older <anticomputer>shouldn't that cache be invalidated when you change the guix.scm file? <ekaitz>anticomputer: that's what I always thought but it looks like it's not <janneke>caching is great, it saves a lot of time... <ekaitz>cache invalidation is one of the most difficult problems in programming, right? <apoorv569>but inside the vm nginx server fails to run with this error, `nginx: [emerg] unexpected "}" in /gnu/store/a9i530dmpyl06syz0vqbgain57l02gs6-nginx.conf:23` <meati>why does (and #t #t) -> #t but (apply and '(#t #t)) -> "Syntax error: unknown location: source expression failed to match any pattern in form and" <meati>lilyp: how can I do what I'm trying to do then? <apoorv569>Rutherther: where? I am not adding lines manually here except the `nginx-server-configuration` record fields. <Rutherther>apoorv569: exactly there, your proxy-pass line should have semilocon at the end <apoorv569>oh wow really.. I thought this would be covered by the serializer.. <meati>i.e. process a list according to a predicate (or a list of predicates) and return #t if all are true <apoorv569>well I'm adding body manually here.. nevermind <lilyp>meati: ((@ (srfi srfi-1) every) identity (list #t #t)) <lilyp>if you already have srfi 1, then it's just (every identity <your list>) <attila_lendvai_>any committer around for a quick fix? gpaste doesn't build, but all it needs is to be bumped to 45.2 (this works: guix build --with-commit=gpaste=v45.2 gpaste) <jA_cOp>Any recommendations for invoking Guix from Emacs? Is emacs-guix aka guix.el the go-to? I noticed it hasn't had any activity in four years, but maybe that's fine! <ieure>jA_cOp, emacs-guix is the thing, yes, it's not perfect but works fairly well. <apoorv569>The postgres service worked in guix sytem vm, but when I deploy it using guix deploy to a local vm my self, I get this error, `pg_ctl: could not open PID file "/var/lib/postgresql/data/postmaster.pid": Permission denied` <supesdupes>I dunno, I'm on the fence about guix. A ton of packages are really outdated in the sense there's version mixture of GNOME packages for instance. Some on 46, others on 43 or 44. So how often does guix maintainers update packages? <dthompson>it will take a lot of cleaning up to upstream all the additional go packages, but I have a build of forgejo-runner finally. need to do more testing to know if everything works but omg this was not easy <dthompson>the go package ecosystem is a nightmare. what a darn mess. <old>dthompson: been there. I don't know why people enjoy Go. To me it's just the Google version of Java <jA_cOp>In Go's defense, the integration of I/O and coroutines in the runtime/stdlib makes for a really ergonomic experience writing programs with lots of concurrent I/O (Go is not the first or the only language with this, but it's one of the simpler ones)