<malaclyps>So I think I understand now that the way to use shepherd to run per-user services (like, for instance, syncing a directory), is to run it *as* that user on startup, as another instance separate from the system (init) shepherd. My question is: does it make sense to have the init shepherd be in charge of starting this per-user instance? Does anyone do it this way? Or is that crazy?
<poet>Hello #guix. Let's say I want to download gnuastro, but before I do, I'd like to see what dependencies are required, and how large each package is. How command would I use?
<lfam>Finally you can examine the dependency graph with something like this: `guix graph gnuastro | dot -Tsvg > graph.svg`. That requires the dot program from graphviz
<poet>lfam: Those are exactly what I'm looking for, however, it presents another question: 'guix build gnuastro --dry-run' tells me "14.6 MB would be downloaded," but 'guix size gnuastro' tells me 'total: 117.3 MiB'
<lfam>poet: You probably already have most of the gnuastro dependencies, like glibc
<pinoaffe>I'm trying to add support for the faber build system to guix and trying to use it to build boost-python, but when guix tries to run faber it returns an exit code of 127, which doesn't happen when I run it manually - anyone know how I could debug this?
<roptat>I think I can commit to review anything ocaml and coq related
<jonsger>every time I do some review (it's not often), I'm kind of regret it. For me it would be much more fun, too just checkout the patches from a branch and test it then...
<xavierm02[m]>Ok python2-pep8-naming builds. It needed both python2-flake8 and python2-flake8-polyfill to be happy (and now I'm defining the python3 package and using package-with-python2 to get the python2 package)
<civodul>null_radix[m]: i'd ping rekado and nckx who provided initial feedback :-)
<Sisyphe[m]>however I can't really help with "guix import crate" since I'm a scheme beginner, plus Carguix relies heavily on already existing crates so I would expect a lot of work to be done to port it all to scheme
<efraim>civodul: only most of the time, I've been getting more failures than hits recently
<civodul>efraim: like "guix import" would fail altogether, or would provide incomplete dependency info?
<efraim>guix import: error: failed to download meta-data for package 'blake2-rfc'
<Minall>I'm unable to share internet from my laptop to a pc using ethernet, in other distros I have no probmlem... What can I do?
<civodul>hmm that's on a 3.10.0 kernel, isn't that supposed to work efraim?
<Minall>civodul: xf86-video-intel is already installed by default right?, my system has intel, but xorg uses the fallback modules, I don't have problems though, is just, since my system is intel, I assume I should use intel.
<roptat>the plugins retained a reference to out, but that was <out>/lib/groonga/plugins, which doesn't exist... I hope it came from a default value of LIBDIR that also lead the libraries to be installed in out in this round...
<vup>also what would be the recommended way to handle crates where multiple versions are needed? What i did was creating multiple packages and putting the version in the name of the package variable, but that doesn't really feel clean
<nckx>Sisyphe[m]: I really don't know the answer to that, but note that discussion of proprietary sophtwarez are not for #guix (or other GNU project channels).
<nckx>Another use case for package parametrization, then 🙂
<vup>currently all the actual building is done by cargo and it doesn't use any precompiled crates, thats not a problem
<nckx>Do Rust features often conflict in practice? I mean, almost all C libraries support ‘features’ (--with-fizz, -DENABLE_BUZZ), in practice we just enable everything needed/considered sane.
<vup>(as in a rust dependency is not a normal input, but a special `cargo-input`, and then basically included by source into the "toplevel" package that is being built)
<vup>i am actually not sure, if rust features can actually conflict
<PotentialUser-60>Is there a (recommended) way to globally install packages? /etc/config.scm?
<Sisyphe[m]>I got dependency cycle with all default features enabled for all dependencies of a package
*nckx is confused how/why the guix MLs still break DKIM signatures.
<vup>atleast cargo doesn't support conflicting features yet, so conflicts should be rather rare
<Sisyphe[m]>vup: how did you handle "native" dependencies when packaging alacritty ? did you add it as inputs of the top-level package ?
<vup>i think the problem with how version selection is done by cargo is bigger, as for binary applications rust as lock files, which specify the version of every (recursive) dependency. To build these lock files, cargo tries to minimize the number of different versions for each (recursive) dependency, which is great on a individual application level, but leads to the problem, that even if two binary applications depend on the same version of a library, the versions of
<vup>the dependencies of this library could differ between the two binary packages
<vup>Sisyphe[m]: yeah, i just added them as top-level
<xavierm02[m]>why isn't the newest vestion the one that's installed in my profile?
<nckx>xavierm02[m]: I don't understand the question.
<xavierm02[m]>When I run gcc --version, it tells me 5.5.0, so I have an old gcc in my profile for some reason
<nckx>The default GCC for building packages is still gcc-5 (this will be bumped with the next core-updates merge). I don't know what your profile contains (this won't be used when building Guix packages anyway), but ‘guix install gcc-toolchain’ installs 9.1 for me…
<nckx>We package every single major version from 4 to 9.
<raingloom>dumb noob question: how do I get the path of an input during building?