<marusich>civodul, have you noticed any emails go missing from the archives for help-guix before? I seem to have emails in my inbox with help-guix in the CC list, but they don't show up in the archive.
<ArneBab_>I know that it would lose protections that way
<ArneBab_>but it could provide graceful degradation
<ArneBab_>(I don’t mean if someone would do that for me, but rather whether that would be something I could hack when I have some time)
<civodul>the (half-)solution to that would be user name spaces in the daemon
<OriansJ>civodul: There is also the potential problem that some people don't want to ever build any packages and thus desire a minimized version of guix that simply provides the end user facing features via say ~/.guix or something similiar
<civodul>OriansJ: that'd be nice, but since binaries are not relocatable, i don't see any easy way to achieve this
<civodul>0install does that, but it relies on the ability to make packages relocatable, IIRC
<rekado>is it necessary to use the full path to dependencies in the RUNPATH?
<rekado>could this be relative to the current location of the package instead?
<rekado>or would it be an option to have a separate lookup table, implementing some sort of ld cache?
<rekado>wouldn't this give us an easily relocatable store?
<roelj>rekado: Do you mean the path that is embedded in a binary?
<civodul>rekado: relative to the current package location wouldn't help
<civodul>but anyway, the main issue is that build systems and software would need tweaking all around
<civodul>for instance, it is commonplace to embed installation file names in binaries
<civodul>so RUNPATH is just one instance of the problem
<avoine>hi daviid! yeah, there was too much rules but I need the "/bin/sh" substitution because I get this error otherwise : configure: error: cannot run /bin/sh build-aux/config.sub
<avoine>now I have the module in ...-1.9.15/guile-g-wrap/share/guile/site/g-wrap/ but it's still not showing up when I do: guile -c "(display %load-path) (newline)"
<avoine>I mean /gnu/store/zvgdd2d0318di8x98p3mm29az46rf42x-guile-gwrap-1.9.15/share/guile/site/
<daviid>avoine: I don't understand that sh bug, it does not happen here [without guix]. then the location is not 'standard' [not sure this is imposed by guix], it should be installed in guile's subtree
<daviid>avoine it should be installed here: guile -c "(display (%global-site-dir)) (newline)"
<daviid>if you change that, you have to read note (3) [of the g-wrap website]
<daviid>"G-Wrap's modules will be installed in $prefix/share/guile/site. If it differs from Guile's global site directory, then this path must be aded to Guile's load paths before to use G-Wrap and compile Guile-Gnome or Guile-Clutter"
<daviid>but that's guix, I mean some deps are not satisfied maybe? here [debian] the tarball pass the autool danse: ./autogen.sh --prefix=/opt [using the source, or ./configure --prefix=/opt if you start using the tarball ]; make; make install
<daviid>avoine: ^ of course the --prefix=/opt is optional I just use this one so it's a bit automatic for me to write the configure call this way...