<kraji>hello :) I'm trying to configure my synaptics touchpad in guixsd. usually i should add a configuration file to the directory /etc/X11/Xorg.conf.d/ . How is this done in guixsd?
<iyzsong>kraji: by default it's using 'libinput', which two-fingers scroll works but edge-scroll doesn't. to switch to the more configurable 'synaptics' driver, I think you have to custom the 'startx' command of 'slim-service'.
<civodul>iyzsong: should we add the synaptics driver by default?
<civodul>better yet, we should make the driver list more easily configurable
<iyzsong>its there, but a device can only use a drive at a time. and i think libinput is enough in most cases :)
<LnL>what does the "substitute: updating list of substitutes ..." do exactly, seems to happen before every build
<Remjey>Hello, I’m installing GuixSD right now and was surprised to not find any vi-like editor on the installation disk. I can accomodate nano for the few files that must be edited for install, but if the installation disk was to be used as a rescue system, it would be nice to have at least a minimalist vi for people like me who heavily use vim and will insert vi commands everywhere in text files while using other editors
<efraim>i have guix's gnupg installed, so I call gpg2 normally, pretty sure debian's gpg is symlinked to the gpg v1 binary
<lfam>I sent an email about including the tar update in core-updates, but I read the logs and saw others are working on it :)
<lfam>I wasn't able to build it when I tried yesterday, but I guess you figured it out :)
<lfam>There is a security patch for gd, but one of the hunks in the git diff is a new binary file (input for the test added to guard against regressions). `patch` can't apply binary diffs from git. How should I handle this? Should I disable the test and push the rest of the update?
<civodul>davexunit: how much is missing for a typical RoR environment?
<davexunit>many rails dependencies. rails has a pretty massive dependency graph.
<davexunit>and if we want to support all the major versions of rails in common usage (3, 4, and 5), there's a lot more stuff.
<davexunit>civodul: ^ the above was for you, but I forgot to highlight you. :)
<davexunit>I think we could use something like bundnix or whatever it's called that can convert a project's Bundler (the terrible dependency manager all Ruby people use) configuration into the relevant Guix package expressions
<davexunit>only on my workstation. production systems have no guix at all.
<davexunit>which turns out to be a pain because I write terrible Chef scripts that Guix could do better if it were just given a chance.
<davexunit>I literally spent all of yesterday writing Chef scripts to compile special versions of boost, jsoncpp, kaldi, openfst, and more for the speech recognition component of my company's software.
<jlicht>davexunit: ouch. AFAIK, the Powers That Be at my day-job would not be comfortable using any <1.0 software, so I will be stuck in a similar position for the forseeable future
<davexunit>and in doing so all sorts of questions come up: how can I figure out if this software needs to be (re)compiled and skip it when nothing has changed?
<davexunit>how do I isolate build environments? (you don't)
<davexunit>what installation prefix should I use for this custom stuff?
<civodul>davexunit: which package provides 'bundle'?
<jlicht>hurray for Node then :/. But wrappers for setting this run-time load path, referring to store items, would not necessarily be a problem, as they do not ever change. You know, because of the whole guix thing ;-). Am I understanding this correctly?
<civodul>to answer that, i would first need to be sure i understand correctly ;-)
<civodul>Guix sortof assumes that there can be only one package of a given name in a profile
<jlicht>_that_ is a good thing to know. If I really need different configurations/versions of the same package available in the same profile, I need to package them multiple times?
<davexunit>some decent comments here, though, along with the usual anti-GNU bashing.
<davexunit>comment I liked: "Although Guix have arguably passed Nix in terms of features already, with a much better command-line tool, a linter, importers for several external package registries and grafting which is a real pain point in Nix."
<lfam>libreoffice is affected, but that seems to *always* be the case
<lfam>I know decided whether or not to graft depends (to some degree) on which packages are affected. but ignoring that factor, what do you think is the number that requires a graft versus a normal rebuild?
<kyamashita>What does grafting do? Is it just an update of one package and reassigning symlinks?
<bavier>kyamashita: grafting does rewrites of package dependencies starting from an existing package