<rekado_>thomasd: if it's icons in the panel: I think there's a bug report about xfce embedding store paths in some configuration files. These paths are not protected from GC.
<efraim>i've been thinking even more about my glibc and kernel-headers problem, now I'm leaning toward adding to glibc-bootstrap-system.patch to remove the dependancy on the kernel headers, with a note to the upstream commit
<Walakea>are there any that are exceptionally easy?
<rekado_>Walakea: Guix has package expressions that describe package objects. These values are "compiled" to derivations, which contain little Guile programmes that are then executed by Guile as part of a build.
<rekado_>Walakea: package expressions themselves are no programmes, though.
<Walakea>is the point f flatpaks, snappys, appimages only to bundle everything together in a binary format, so that evryone can run it, but they are not concerned about making the build procedure more universal?
<rekado_>Walakea: I don't speak for other package managers, but I think one of their goals is to make it easier to deploy proprietary software.
<rekado_>Walakea: it's not about improving the build procedures.
<rekado_>Walakea: one of their explicit goals is to specify a reduced set of common "runtimes" on top of which binaries can be deployed. This is not very useful in the case where you have sources and can build a binary from scratch.
<rekado_>Guix doesn't require a common runtime, because packages span a graph that includes *all* dependencies, all the way down to a handful of bootstrap binaries.
<Sleep_Walker>that is moment where weaker dependency like 'recommends' would come handy
<mekeor>the package for the 'surf' browser (from suckless) has a similar issue: if you only install surf, you can't open a new URL within the browser because that requires the xprop package. what do you think about that case?
<paroneayea>right, the example you started with was for contributing a package to guix *itself*, like the main repository
<paroneayea>and you might want a module, if you build up your own collection of modules, or if you're going to contribute to guix itself! but if you're just packaging some local-workflow applications to play around with, you don't need to do that
<mildred>nice, so what I probably wanted is 'guix package -f' and not 'build -f'
<paroneayea>mildred: build just builds it, it doesn't install it in your profile
<paroneayea>still useful, maybe you want to make sure your build works right before you install it or whatever, but probably not what you wanted
<paroneayea>mildred: (ps if you don't want to clutter up your profile / if you're doing a local environment where you just need some local packages to hack on, you might want to check out "guix environment", which is awesome :))
<mildred>what I want to do, in fact, is construct an environment with couchdb and its dependencies, and only them...
<paroneayea>ng0: I'm taking the lazy middle ground fyi, leaving scsh as scsh in shell.scm, since it distinctively *can* be run as an executable (it starts up scheme48 with things preloaded), but renaming rx to scheme48-rx
<paroneayea>sound reasonable? or am I only half committing to an approach :)
<ng0>speaking of sloths.. I underestimated what it takes to create a really featureful and usable live-system. with beyond the basics, I'm looking at work until at least winter 2018. Most of what I want is already at the magical 80% where the last 20% will take forever. I will probably take some time, write up something about the system, issues, reasons, etc and see if I can get more than just myself to work on