<ruffni>hmm.. do you use gnome desktop? i'm on i3 right now <ruffni>is it possible to (simple-service 'add-autostart-file user-homes (lambda _ _)) ? where is user-homes defined? <civodul>ruffni: the "user-homes" Shepherd service is defined in (gnu system shadow) <podiki[m]>I don't use gnome, I run xinitrc directly from gdm currently (awesome and exwm are installed) <ruffni>civodul: i even found that but for some reason i get "error: user-homes: unbound variable" ***srk_ is now known as srk
<yjftsjthsd>Is there any way to run guix without the daemon? I'm thinking of using it in ex. a gitlab CI job to build from source to binary <yjftsjthsd>That looks like an alternative to guix with a feature that lets it avoid the daemon? Can guix do that? <jgart>not sure, maybe someone else knows <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? <muradm>lfam: any idea on marionette-type? <lfam>No, I've never use it directly <lfam>It gets used in the system tests, I thin <lfam>I mean, that's what the marionette stuff is for <muradm>yes, i'm trying to write some test <lfam>I would also ask in #guile, since you had a question about escaping and that might be general to Guile <muradm>also (marionette-type "env > env.out" marionette) eats first "e" <lfam>Which branch are you using / writing your tests for? <lfam>I can try to reproduce it if you give me instructions <muradm>fails with "file does not show up" <muradm>on screencapture command is there, but $ and _ chars are missing <muradm>it is like does not want to type chars out of some range may be <muradm>in previous expected value is wrong, but that is not very important <lfam>Alright, I queued it up to try to reproduce it. The server is collecting garbage right now <muradm>but may be $ and _ are not in the map <muradm>yeah it seems like require shift-- and shitf-4 for _ and $ respectively <lfam>I see that things have been adding to the list of keystrokes. So you should suggest adding these. I don't really understand the purpose of that code <the_tubular>how can I start my own "list" in shceme, to replace "%base-package" ? <muradm>(services (list (service-type ... ) (service-type ...) ...)) ? <muradm>(define my-services (list (service-type ...) (service-type ...) ...)) <muradm>then use it as (services my-services) <muradm>the_tubular: you are asking about packages, sorry services in my head, but similar thing <iskarian>Hmmm, perhaps a native-propagated-inputs would be the solution for go & rust <the_tubular>Is there a way to "import" that list to another project ? <the_tubular>Basically I want write a list, and a few guixsd machine would be reading from that list <the_tubular>Basically a manifest file, that I would be able to call from a config.scm file, from anywhere <the_tubular>Well just like how you can call %base-package file from anywhere <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 <drakonis>however the guix daemon remains due to a dependency on the nix daemon fork <drakonis>its just that the work hasnt been high priority yet <drakonis>being able to eliminate the nix daemon from the equation by moving its functionality into the guix code base would be a boon <drakonis>as that bit of code could be made available on a daemon for specific contexts or tasks <yjftsjthsd>But for the time being, at least, the best bet is to just start guix, run the build, and stop guix, it sounds like. I can live with that. <yjftsjthsd>(I'm not a good enough dev to modify guix itself, and "port the core nix bits into guix" is *way* over my head) <the_tubular> I wish there was a module on w3 shcool or something <yjftsjthsd>I mean, yes; part of the idea is for me to learn guile and guix, certainly with an eye to add packages <yjftsjthsd>but I want to start with a *gentle* introduction, ideally keeping a lot of my existing workflows <yjftsjthsd>(hence "how can I use this in existing CI systems?") <jgart>can anybody recommend some high level async library for guile 3.0? <yjftsjthsd>"rewrite core code" is not my idea of a gentle intro;) <jgart>something that doesn't require creating sockets at a lower level <jgart>is there such a thing currently for guile 3.0? <jgart>oops, wrong channel. That was meant for #guile <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. <wonko>my config has stopped working after a pull, a match-error in my setuid setup: <wonko> #~(string-append #$wireshark "/bin/dumpcap") <wonko> #~(string-append #$xscreensaver "/bin/xscreensaver") <aadcg>I'm new to guix and I have some questions regarding hacking it with geiser <aadcg>how can I load everything I need into the REPL? <civodul>wonko: hi! could you send the error you get to a paste site? <civodul>there has been a change in this area, but what you show is supposed to still work <civodul>in the meantime, you can also look at the new 'setuid-program' construct <wonko>got it working with the new construct 👍 <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" <wonko>it failed after 2+ hours of installing & building things <bricewge>leoprikler, civodul I made this patch because I wasn't able to add a user to a group only when a specific service is enabled. <civodul>wonko: yes; you have #~(file-append ...) instead of (file-append wireshark "/bin/xyz") <bricewge>In guix user accounts have a list of groups for which they are members, but on the filsystem, that's the other way around <civodul>bricewge: correct, a service cannot make users part of a group <bricewge>/etc/group contains reference to user accounts <civodul>for example, cups cannot make users part of "lp" <civodul>but that's OK: it's a decision for the sysadmin to make, and i'd prefer to explitly add "lp" for those accounts that i know are supposed to be able to use CUPS <bricewge>As "lp" is a default group on Guix that's kind of ok <bricewge>But for groups not in the default groups, for exemple "libvirt" the service (which create the group) need to be present on the OS and the sysadmins need to be members of the group <bricewge>But I then I can't reuse my list of user on an other OS, which doesn't has a libvirt service <bricewge>And guix would error out because "libvirt" group isn't defined <civodul>but you could do: (map add-to-libvirt-group my-users) <civodul>assuming you want to add all your users to the group <bricewge>For a single group it's fine to have the logic to add users to some groups conditionally but with more groups with a lot of service it's difficult to keep track of all of them <bricewge>I had a look into guix-maintenance's (sysadmin people) too, but It wasn't satisfying since it only define a single role for users <civodul>you need to define a way to determine which user goes to "libvirt" and which one doesn't, though <bricewge>I would want to have several users roles, such as `sysadmin`, `user`, `developper` and have some accounts with several roles such as a `sysadmin` `developper` <bricewge>A role being a set of groups for example <civodul>so i guess you need a structure different from <user-account> for that, something higher-level <civodul>and then you could have, say, person->user-account that would take such a thing and return the corresponding user account <civodul>but yeah, you then need to have it add "libvirt" only to developers, say <civodul>hmm, that's an interesting puzzle :-) <bricewge>I'll try another implementation, but without modifying already instantiated object <bricewge>I got such error when playing with the initramfs <bricewge>Did you try to boot with the --repl kernel argument? <bricewge>I find it difficult to debug this part of the system <bricewge>Yes, bo I don't really know how to debug from there on <bricewge>Then it's probably a faulty shepherd service <lost42>hi there, I just installed guix on top of ubuntu 20.04, installed glibc-utf8-locales and added export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" to my <lost42>.zshrc, yet, everytime I call guix, I still get the same notice: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and ... <lost42>even though the variable is defined in my running shell <lost42>what am I missing here? thank you <roptat>lost42, did you use the installation script? <roptat>is GUIX_LOCPATH currently defined in your shell? <roptat>does $HOME/.guix-profile/lib/locale contain a directory with a version number? which number is it? <lost42>but it all belongs to root, not sure if this is a problem <lost42>maybe guix cannot be called from a zsh shell? <lost42>nope, running it from a bash shell gives the same, even though it too has the GUIX_LOCPATH <roptat>you can also get the exact same message from the daemon, but the installation script is supposed to take care of that already <roptat>could you check the systemd service file? It should define GUIX_LOCPATH too, and that should point to a similar directory <roptat>it should be /etc/systemd/system/guix-daemon.service <lost42>ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild <roptat>you should have a line with Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' <lost42>Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8 <roptat>looks ok, maybe rename LC_ALL to en_US.UTF-8, but I don't think it will change anything <roptat>does /var/guix/profiles/per-user/root/guix-profile/lib/locale also contain that 2.31 directory with locales? <lost42>that dir does not exist :thinking: <roptat>so, as root, install glibc-utf8-locales, not sure why it's not there... <roptat>oh wait, it's not the same directory <roptat>do you have /root/.guix-profile, and is that a symlink to /var/guix/profiles/per-user/root/guix-profile <lost42>my /root only has the snap directory <roptat>hm, ah, you used sudo? I think that just installed for your user, but with root privileges, I think you have to use sudo -i guix install glibc-utf8-locales <lost42>it didn't say there was nothing to install, but no new directories <lost42>but I do have the /var/guix/profiles/per-user/root/guix-profile/lib/locale now with 2.31 <roptat>alright, so that should work now? <lost42>still get the warnings though :/ <lost42>maybe a bug in the new 1.3.0 release? <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 help-guix@gnu.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) <lfam>sneek: later tell muradm: That test you wrote fails for me too. But I don't know how to check the output of the test to confirm the failure mode <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 <civodul>(geoclue is started on demand by D-Bus) <podiki[m]>so for those need to use things like dbus-monitor to see <podiki[m]>(and I guess in the systemd world it wraps the dbus services as well) <roptat>a system service is not necessarily a shepherd service <podiki[m]>is the plan for that to remain that way or will shepherd wrap other services in some way? <roptat>I don't think there's any plan to change that <podiki[m]>I was finally learning my way around systemd on previous computers :-) <leoprikler>even though they both start with s and end with d <sneek>muradm, lfam says: That test you wrote fails for me too. But I don't know how to check the output of the test to confirm the failure mode <muradm>sneek: never mind, i found workaround <muradm>lfam: oh man, you are not sneek :))) <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>do you mean the app don't open? do you get any output on the console? <zorpheus>The app won't open yeah. Trying to run any given X11 app just results in some variation of 'no protocol specificed, Make sure $DISPLAY is properly set' <zorpheus>For context, I'm running awesomewm in an xsession already, then trying to run a program installed through guix. AwesomeWM and X11 were installed by the openSUSE package manager <roptat>mh... I never had a problem like that <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 help-guix@gnu.org (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 <roptat>oh, cool, glad you found a solution :) <zorpheus>Yep, easy to forget X11 technically is still a networked system haha <muradm>(system-test (name "some-test-1") ...) is valid test name? <muradm>make check-system TESTS="some-test-1" seems like not working <JorgeTern[m]1>Saludos,como puedo y debo empaquetar un software para Guix ? <jackhill>dongcarl: interesting, thanks for sharing! <jackhill>It would be cool to have a Guix talk, but I'm not sure I'm the right person to give it. <jackhill>A Nix person is one of the organizers :) <dongcarl>Ah! I'm sure they'd love a Guix talk then <jackhill>Maybe I should pick something that I want to finally learn and give a talk about that to push me through the learning process :) <jackhill>but I'm open to other ideas as well, or maybe we can do a group presentation <jackhill>I am slightly worried that participating in the conference may require the use of non-free software thought <civodul>dongcarl, jackhill: i submitted a talk about what it is that we're after as package management tool devs <civodul>like, "pip install" that ships random binaries vs. Guix/Debian-style curation, unbundling, repro builds, etc. <civodul>but it'd be great to have more technical Guix talks too! <civodul>they explicitly told me they're interested in such things <civodul>and i think the Nix folks want to make sure functional deployment is well represented :-) <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 <lispmacs[work]>for example, `guix environment --ad-hoc gcc-toolchain` adds gcc compiler, etc. to your current shell environment