On Thu, May 2, 2019 at 4:50 PM Ricardo Wurmus <rekado@elephly.net> wrote:

>
> rohit yadav <rohityadav@utexas.edu> writes:
>
> >> Do you want to build everything from source on your system or do you
> >> prefer to use binaries from the Guix project’s build farms?  Do you have
> >> access to user namespaces / can you use “unshare” for file system
> >> shenanigans?
> >>
> > I need to build guix for non-root location because at several places its
> > hard to convince to use such system. However, I need several packages
> which
> > are not usually available or outdated. The guix projects allows me to do
> > so. To accomplish that I need truly non-root permission oriented method
> to
> > bootstrap and install whatever I deem necessary for my use case.
>
> I see.  Unfortunately you will end up having to compile everything from
> source, C library, GCC,… — all of it.  When using a different store
> location it is impossible to use pre-built binaries, unfortunately.
>
Yes, I am fine with this. Its actually not so bad. Most of the time its
only the beginning that little time (few days) needs to be invested but
returns are totally worth it. Also, this way I am able to find out the
broken packages as well which usually do not get reflected till a binary
exists in the store.

>
> >> …you would need to take care of providing the appropriate Guile
> >> environment all by yourself whereas “guix pull” does all of this for
> >> you.  This error tells you that guile-gcrypt is not available in the
> >> environment in which the daemon runs.
> >>
> >
> > This is the place where I am struggling. I am not sure what more do I
> need
> > to do then described in pjotrp notes. I could not find anything specific
> in
> > the guix documentation as well to accomplish this.
>
> There are two ways I can think of: the first is to use the slow
> proot-style Guix to run “guix environment guix”; from within that
> environment you will have all you need to build Guix.  You can use that
> to compile Guix with a different store prefix and later use *that* Guix
> to run “guix environment guix”.  Eventually, you could drop the
> proot-style Guix.
>
> I’m not sure it’s worth doing.  It seems like a lot of work and you will
> never be able to benefit from pre-built binaries :-/
>
> The other way is to manually build “guile-gcrypt”, using your system
> compiler toolchain.  The sources are available here:
> https://notabug.org/cwebber/guile-gcrypt
>
> …
>
> I just thought of another way: how about running the Guix daemon in a
> virtual machine (you can download a ready-made VM image from the project
> website) and telling Guix to talk to the VM over the network?  Running
> the installed software unfortunately would have to go through the VM,
> but this might be another option depending on your circumstances.
>
> I am not sure about this option. At the end of the day I need packages
compiled for a specific kernel version to a non-root location. So having a
VM with guix installed would not be so useful. I am just stuck at the older
glibc. I will manage with whatever I have using Nix 17.03 release which
seems to still work but for my home machine I will continue to explore
guix.

Thanks again for quick response. I now understand where I stand what are
the actual problems. We can close this thread now.

> --
> Ricardo
>

--Rohit
--Rohit