<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
<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.