<mark_weaver>basically, replace (dhcp-client-service) with (wicd-service) in the OS config, add 'wicd' to 'packages' and to the list passed to 'dbus-service', and add "netdev" to the list of supplementary groups of all users that should be allowed to mess with the network configuration.
<angelic_sedition>Does the GuixSD config file have a setting for console keymap as one would load with loadkeys or put in the vconsole.conf? I didn't see anything in the manual.
<mark_weaver>not yet, but we should probably have something like that.
<angelic_sedition>Thanks, also is there a default password for users specified in the config file when running the vm created with "guix system vm"? I can log in as root, but for a user it asks for a pass.
<mark_weaver>run "passwd <username>" as root if you didn't set the password in the config
<paroneayea>this optional post-environment-setup hook would probably have to be not really as clean and functional as the rest of guix's packaging stuff since it's modifying symlinks in the environment
<davexunit>my first attempt would be: create an environment variable called JS_PATH or something, have configure script search that for absolute paths to JS files and symlink as needed to the directory that assets are served from
<paroneayea>davexunit: maybe it actually belongs in guixops ;)
<paroneayea>davexunit: I think it's unrealistic to expect many projects in the space that are using bower to use configure
<davexunit>there's got to be a way to do what bower does in some not disgusting way
<davexunit>but I think there's a bigger issue present here: web apps are weird. you never actually install them to the root file system or anything. you just bundle all the dependencies in the source tree and run it from there.
<davexunit>it's hard to deal with things that are built to not integrate with the rest of the system
<davexunit>my rule of thumb is "if it's a package manager, then guix can replace it", but bower is indeed tricky.
<taylanub>joolean: it sounds like you didn't run the guix daemon, or you used a --prefix option for the guix you built which doesn't correspond to that of the guix installation whose guix-daemon you're running
<taylanub>joolean: does /var/guix/daemon-socket exist?
<paroneayea>at the very least, the people who hack emulators turn out to be the kind of people we want in free software, as that's a similar skillset to that which allows reverse engineering :)
<cehteh>the part that some free projects aim to clone some non free stuff than beeing innovative and creating something new is what annoys me quite much tough
<taylanub>jmd: I think you need a newer Guile version. (might want to file a bug report so the pkg-config file gets fixed to declared the higher version requirement.) a good way to build guix, if you already have another version installed, is: guix environment guix -E './configure --with-libgcrypt-prefix=/gnu/store/...-libgcrypt-...; make'
<Tsyesika>so i checked and my keyboard does not work at all in guix's SD image
<mark_weaver>cjbarnes18: replace (dhcp-client-service) with (wicd-service) in the OS config, add 'wicd' to 'packages' and to the list passed to 'dbus-service', and add "netdev" to the list of supplementary groups of all users that should be allowed to mess with the network configuration.
<Tsyesika>it does work in trisquel though so it's definitely not reliant on any blobs
<taylanub>when the guix daemon is building things, it will adhere to the package recipes. most package recipes should use parallel building (it's enabled by default and a recipe has to disable it explicitly if it causes issues)
<taylanub>cehteh: Guix is a package manager at core; the distro is mostly built around it