<rekado_>when sharing a read-only store from a central NFS share among different machines is it enough to mount /gnu/store or would the localstatedir also have to be mounted by all users?
<rekado_>I want to make the store and the profiles available on cluster nodes. The store and the profiles are managed on a separate machine, the only one to have write permissions on /gnu/store
<rekado_>the daemon is only running on that management machine, not on any cluster node.
<rekado_>to install new software into user profiles we would use the management machine only.
<rekado_>are there any obvious problems with this approach?
<rekado_>Is anyone here familiar with Sphinx? I have python2-sphinx as an input to a library and one test fails because of an error in using sphinx.
<rekado_>says: "ImportError: No module named sphinx_rtd_theme"
<rekado_>(it's the penultimate test of 140 tests after a very lengthy build process of a couple of hours on my machine)
<iyzsong>civodul: I'll look into xfce (alrealy works IMO) again when I finish the sawfish session. And the xfce meta package have to be contained in 'packages' field to make SLiM session work. Is this acceptable?
<mark_weaver>fchmmr: our armhf port should work on the BBB, but we don't yet have any build slaves for our build farm, so no pre-compiled binaries yet, and the BBB probably doesn't have enough RAM to bootstrap our system from scratch from sources.
<fchmmr>mark_weaver, core system is probably fine. All I really need is flashrom, and I can build that and its dependencies from source.
<fchmmr>mark_weaver, so with limited RAM, I guess the only option is to cross-compile.
<DusXMT>But it's not that difficult to package them. For example, I use nvi to edit text, Abiword to edit documents, mupdf to view PDFs, and none of that was packages when I came; I just tried my best at packaging them, submitted patches, and they're now in, so I'd say: If you're up for doing some work for yourself, it can be pretty neat
<mark_weaver>davexunit: yep, fchmmr brought it to our attention in the last hour or so
<davexunit>mark_weaver: ah, I didn't read the backlog well enough.
<mark_weaver>although getting an improved build system upstream would be welcome
<jgay>mark_weaver, oh no problem, the Guix stuff took very little time because I basically just skimmed over things to make sure that stuff was in order and assumed I could just trust a GNU project to DTRT :-)
***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | 0.8.1 is out! | http://www.fsf.org/news/fsf-adds-guix-system-distribution-to-list-of-endorsed-distributions | This channel is logged, see <https://gnunet.org/bot/log/guix>.'
<mark_weaver>rigelk: the 'guix' and 'gnutls' built from within guix works out of the box.
<mark_weaver>but if you build guix within another distro, it depends on the guile bindings in gnutls being set up, and GUILE_LOAD_PATH pointing to them.
<mark_weaver>rigelk: python-dbus uses the expat license, not gpl2
<rigelk>it does. I was just bumping on the default error for a missing python input (as using autotools rather than setup.py). the default calls for python 2… ^^'
<rigelk>mark_weaver, I have forgotten to change the license, thanks !
<rekado>mark_weaver: yeah, I was very surprised to see so fast a response and resolution.
<mark_weaver>rigelk: we should have versions for both python 2 and python 3. normally we do this by making the default package for python 3 (named python-dbus in this case), and then use 'package-with-python2' to automatically make a variant for python 2.
<rigelk>now that the input of python is properly stated, I bump into the following : configure: error: The pkg-config script could not be found or is too old.
<mark_weaver>rigelk: you should put this in python.scm instead of a new file