***yang_ is now known as yang
<xd1le>alezost, efraim: thanks. i expect to use the address for the indefinite future. <civodul>ACTION writes a recutils database of the machines we have <civodul>mark_weaver: thoughts on having it stored in guix-maintenance.git? <civodul>there are host names and contact email addresses <efraim>can someone take a look? https://pastee.org/zcphc I know I have to fix the arguments, but I keep on getting the error "warning: source expression failed to match any pattern" against the second line <rekado>I'm confused by define-record-type* and the accessors. <rekado>in gnu/services/base.scm I'm trying to add a pam-entry to a pam-service created by unix-pam-service <rekado>I thought I could just do '(pam-service (inherit s) ...)' and override a field. <rekado>I want to add a pam-entry to an existing field, not completely override it. <rekado>but I cannot use "pam-service-session" as a getter. <civodul>rekado: oh i see that the accessors are not exported <rekado>I added pam-service-session to the list of exports but I get an error: <rekado>Wrong type to apply: #<syntax-transformer pam-service-session> <civodul>that's because the module that uses it was compiled before the change <rekado>(I find define-record-type* hard to understand) <civodul>it's because accessors are inlined, and inlining is done by making them a macro <civodul>what do you find hard to understand? <civodul>well, it's quite brute-force i must say ;-) <rekado>could you recommend any resource that might help in getting more comfortable with advanced macrology? <civodul>maybe R6 has an intro to syntax-case <civodul>yes, r6rs-lib, starting from page 50 <rekado>civodul: thanks! I'll add it to my reading list. <civodul>mark_weaver: could you look into the guile-wisp patch? (i'm asking because you started already :-)) <mark_weaver>civodul, paroneayea: yes, sorry for the delay. I guess the one last thing I wasn't sure about was the use of 'use-modules' within one of the phase procedures. is that suboptimal compared with adding #:modules to arguments? <civodul>mark_weaver: yes i prefer #:modules instead of a nested 'use-modules' form <mark_weaver>paroneayea: would you like me to make that change (^^) myself and push your patch, or would you prefer to do it? <codemac>I'm trying to package alsa-plugins.. but it seems most packages think alsa plugins are installed in the same library folder as the alsa libs. And to change it's location alsa needs to know where alsa plugins are.. it's a bit of a circular dependency. Ideas of how to package this? <civodul>codemac: no idea, but it may be worth looking at how Nixpkgs handles that <mark_weaver>codemac: does alsa support the use of an environment variable to specify the location of plugins? if so, that would be best. otherwise, it might make sense to patch 'alsa' to support such an environment variable. we've done that in a few other cases. <codemac>mark_weaver: no, right now it's a build time configuration for alsa where the alsa plugins will be.. but I don't know that yet until I build them.. and they of course depend on alsa's location, which I don't know yet! lol <codemac>This will happen with any program that has "plugins" or other optional runtime dependencies. Is the current pattern environment variables for where they are? <mark_weaver>codemac: our usual approach is to have an environment variable set to some subdirectory in ~/.guix-profile (and maybe also in /run/current-system/profile), and then the user can install more plugins later. <mark_weaver>if we're stuck with a compile-time fixed location, then our options are (1) have a fixed set of plugins that cannot be extended later without recompiling alsa and everything that depends on alsa, or (2) make the fixed directory in /run/current-system/profile/... in which case it only works on GuixSD and the plugins have to be installed system-wide. <mark_weaver>so, I think we should patch alsa to add support for an environment variable. <codemac>I nede to understand how alsa works better to see if it's ever possible to propagate <codemac>on some level you have to tie it to a *profile* not a directory, as it's optional as it relates to what the user has chosen to install. <codemac>hm. seems nix does someting with 'ALSA_PLUGIN_DIRS' but I see no evidence that they have successfully patched alsa