<drakonis>perhaps someone else could give a better answer
<lfam>yjftsjthsd: The daemon is really the core of building things in Guix
<muradm>(marionette-type "echo $XDG_VTNR > XDG_VTNR\n" marionette) this eats _ why? any escape sequence for that?
<lfam>A Guix that didn't use it would be a totally different thing
<drakonis>lfam: there's space for some pretty interesting thing
<drakonis>if the functionality that lives in the daemon was to be moved into guile and then the daemon can be repurposed for handling other tasks
<lfam>Is the point to avoid a daemon? Or something else? In either case you have to run a program to perform the build
<lfam>There has been work to move functionality of the guix-daemon codebase (which is an old fork of nix-daemon) and rewrite it in Guile, mainly because Guix tends to attract Scheme developers, not C++ developers :)
<drakonis>the point would be to use the daemon for other tasks
<lfam>On the one hand, it's an implementation detail, which is why the task of rewriting it in Guile is rather slow-going compared to Guix development overall. On the other hand, it's the core of how Guix works
<lfam>Does it not fit into how Gitlab's CI is supposed to work?
<yjftsjthsd>Sorry, was AFK. So I guess I'm not... 100% opposed to the daemon, but it doesn't seem like it makes sense unless you're actually running it as your OS, or *maybe* persistently on a system. So take CI, assuming I'm not going full hydra - gitlab doesn't really *do* persistent services. It can *tolerate* them, by starting the service, running the job,
<yjftsjthsd>and killing the service, but fundamentally what I want is not a service per se, but "take this blob of guile and spit out binaries", and it feels like that no more needs a daemon than a compiler chain does
<rekado>yjftsjthsd: don’t think of the daemon as a persistent service.
<rekado>thanks to the coarse permissions model implemented in Linux we need parts of the code to run as root (primarily to use chroot and switch to unprivileged users).
<rekado>it’s not so terrible to start the daemon, build, and stop the daemon.
<rekado>yjftsjthsd: there has been a project to move more and more bits of the daemon from C++ to Guile, because we already have quite a few of the features needed for the daemon in various Guile modules (e.g. those needed for “guix environment” or “guix system”).
<rekado>but there’s really no rush because the current situation is quite acceptable.
<civodul>wonko: good! you were faster than me, but it's coming...
<civodul>there's another annoyance with the deprecation warning i wanted to fix
*bricewge is looking at the fresh changes related to setuid-programs
<bricewge>civodul: I struggle to understand the issue with the patch about <group-membership>
<bricewge>Is it that you don't want any `user-service` to impact an `<operating-system>` field?
<bricewge>Would it be better if it a <group-membership> could only append groups to users defined through a service and not the one defined in an OS field?
<leoprikler>Tbf I don't find <group-membership> itself very helpful. Why manipulate existing users rather than using a declarative approach to their generation?
<civodul>bricewge: hi! the two issues as i see it: (1) i'm not sure when one would use it, and (2) it makes it harder to reason about the system since any service anywhere could add supplementary groups to existing accounts
<leoprikler>if you need <group-membership> to manipulate users generated through a service, it means that a) you shouldn't be allowed to do that or b) that service should itself offer an account configuration
<wonko>I pulled this morning to try to update my system, it failed with "ice-9/boot-9.scm:1685:16: In procedure raise-exception: error: file-append: unbound variable"
<roptat>it's not so new, I think we would have received more reports of this issue...
<roptat>anyway, need to go, sorry I couldn't help. If nobody here can help you, you might get more luck sending a message to firstname.lastname@example.org (note that your first message to the list will be moderated, so it can take up to a day to reach the list, your following messages will not have to wait)
<podiki[m]>where can I read more about using herd and service management (beyond defining services in the guix manual)?
<podiki[m]>I'm a bit confused of things I'd expect: for example, %desktop-services includes geoclue-service, but `sudo herd status` doesn't show it, nor anything i've tried with putting `sudo herd status geoclue` etc.
<civodul>podiki[m]: hi! the thing is that "services" in the Guix sense, such as geoclue, do not necessarily map to Shepherd services
<civodul>in this case, it's a D-Bus service and not a Shepherd service
<muradm>lfam: i check the output like, after running test it says "build of /gnu/store/.....drv failed", the first "out" of that "drv" contains the basic.log file, which shows test results, if needed there is also "screencapture" test which puts tty1.ppm in the same drv out
<zorpheus>hey all, i just installed guix onto a fresh install of opensuse leap and I can't seem to get graphical applications installed through guix to see my xsession
<roptat>in fact I'm using hexchat from guix on a fedora machine right now
<zorpheus>Hmm, maybe I have a bad permission somewhere. Is there something I'm supposed to do before running guix as a user? I initially installed it as root and I see in my /home/zorpheus/.guix_profile/bin everything is owned by root
<roptat>I don't know how to help you, and if no one else here knows, then you might get more luck sending an email to email@example.com (or was it guix-help?). You first message will be moderated, which can take up to a day, but your following messages will not be delayed
<zorpheus>I appreciate your help but actually, I just figured it out. For some reason I think guix-installed programs were seeing a different hostname then distro installed. Resetting my hostname seems to have cleared the issue
<jackhill>civodul: thanks for the encouragement, I'll do it!
<nirnam>Hi this question maybe stupid because I just start looking into guix, and was looking to hop to it from gentoo, after few youtube video I'm concern about building thing like dwm and st, how do build thing from source with guix directories struture?
<lispmacs[work]>nirnam: are you talking about building your own packages from source, or building Guix packages from source, or modify Guix packages and building them from source?
<nirnam>lispmacs[work]: building from my own source files
<lispmacs[work]>nirnam: you'll want to become familiar with the guix environment command. it sets up your environment variables to point to the paths you have exposed in a particular environment