<wingo>clearly it was hubris of the fsf to publish an article rating hosting services and giving savannah top marks :-P
<kmicu>GitHub/GitLab is up and Gitorious is read–only but still up :) Savannah is down *again*. There are ethical/political issues with them (though GitLab has C grade on https://www.gnu.org/software/repo-criteria-evaluation.html ), but that’s all beside the point that with *D*VCS we are waiting for a central server to come back to life ( ͡~ ͜ʖ ͡°)
<z0d>you could set up multiple server with the same repo data. or make a cluster
<civodul>my point is just that Gitorious (and Google Code, etc.) disappeared overnight with all its data for business reasons
<cfd>Anyone have a guide for installing Guix without root permissions? Even some starting steps would be helpful! Thanks!
<bavier>cfd: it's not as pleasant of an experience
<bavier>you need to configure with the '--with-store-dir' option to point somewhere writable, preferably with as short a directory name as possible
<bavier>then run the guix-daemon with --disable-chroot
<bavier>you'll have to build everything from source, and there's no guarantee that will work
<bavier>because there's no build environment isolation
<cfd>I'm a bit of a noob. What does "build environment isolation" mean? Thanks for your help!
<bavier>cfd: the guix-daemon normally creates a chroot for builds, where only the files necessary to build a package are visible, the network is inaccessible, etc., in order to precisely control what goes into a package build
<cfd>How does my configure look? I may have added options that are not needed. ./configure --prefix=$HOME --localstatedir=$HOME/var --with-store-dir=$HOME/gnu --disable-daemon
<bavier>cfd: I don't think you want --disable-daemon, unless you have one running already
<cfd>Running this tells me that it needs --with-nix-prefix
<cfd>Do I actually need Nix? I think I'm getting this because of the --disable-daemon option.
<bavier>cfd: you shouldn't get that message if you remove --disable-daemon
<cfd>Gotcha! Thanks! So I'll still need the daemon running as a regular user.
<cfd>Could I do something like the following (I actually do have root access, my goal is to ultimately have Guix running without requiring root though): 1. Install guix using the provided binary under root (typical install). 2. Use guix to install guix using the specified .configure options
<cfd>Unfortunately it will not. Basically there are two identical (at the hardware level) systems and I have root access on one, but don't have root access on the other. I am wondering if I can install guix using the binary on the system that I do have root access on. I will then use guix to build a version of guix configured to run on a system where I do not have root access. I will then port the newly built and properly configured guix over t
<cfd>have root access on. A bit complicated, but I'm trying to make compiling guix as easy as possible given that I've had trouble compiling it from source in the past.
<alezost>efraim: rekado: I still can't use guix repo through ssh. Does it work for you?
<bavier>cfd: ok, thanks for the problem description. You won't be able to use root at all then.
<bavier>If you configure the store directory identically on both system, you should be able to move build products around
<cfd>If you take a look at this link: https://github.com/pjotrp/guix and look for "Installing Guix from Guix", I'm going to try doing something like that. My understanding of the process pjotrp outlines is first download the source code, then run "guix environment guix", then run ./configure <options>, then "make", "make check", and "make install". Do you think approach is a plausible solution? Is my understanding of the approach correct?
<cfd>bavier: I'm going to give it a try. Thanks for your help! I think I've got a decent path forward. We'll see what happens...
***czlowiekdeprecha is now known as ktosiek
<mark_weaver>cfd: there will almost certainly be many packages whose configure scripts pick things up from /bin, /usr/lib, etc, and thus fail to build properly without isolation. be prepared for a *lot* of working fixing things up.
<mark_weaver>honestly, it would probably be better to run Guix within a VM where guix-daemon can run as root, and then make its store available outside of the VM.
<bavier>cfd: to add a datapoint to what mark_weaver said, I know for me the bootstrap gcc fails to build because libstdc++ decides to install itself in lib64, rather than lib
<bavier>cfd: Your custom-store guix-daemon could run with chroot on your rooted machine, and serve substitutes to your unprivileged machine
<cfd>Well, sounds like the Installing Guix from Guix approach isn't really feasible given that I'll have to spend so much time fixing things. How would running the guix client on the unprivileged machine look? guix --look-at-this-host-for-binaries=thehostwithrootaccess.org.pub package -i somepackage ???
<bavier>cfd: I think the Installing Guix from Guix would work
<bavier>you should be able to avoid build issues if you run guix-daemon-with-/home/$user-store-dir as root
<bavier>then on the unprivileged host `guix package --substitute-urls=rooted-host -i foo`
<cfd>bavier: Thanks for the encouragement! So far I was able to build Guix using Guix with the help of "guix environment guix". My current situation (A) running daemon "~/bin/guix-daemon --disable-chroot &" (B) Attempting to build hello "bin/guix package --no-substitutes -i hello"
<bavier>cfd: I'd suggest running the daemon without --disable-chroot if possible
<cfd>I am using --no-substitutes because issues are encountered, I get a wall of: substitute: guix substitute: warning: 'https://hydra.gnu.org' uses different store '/gnu/store'; ignoring it
<bavier>right, that will happen, you can instead start the daemon with --no-substitutes, to avoid passing to every invocation of guix
<cfd>I'll add "--no-substitutes" to the daemon. Thanks for the tip! Trying it without --disable-chroot now...
<cfd>bavier: Trying to run the daemon without --disable-chroot did not work. "~/bin/guix package -i hello" results in error: build failed: cannot change ownership of ‘/home/me/gnu/sxg67mcyfziyd3aq1kds3csrwjjms1af-guile-2.0.11.tar.xz.drv.chroot’: Operation not permitted
<cfd>bavier: I did not, I'm not surprised by the result. I'm trying to run everything that is the Guix project without the use of root.
<bavier>cfd: you should be able to run the daemon as root on the machine you have root on, while maintaining the ability to use the build results on the machine where you do not have root
<cfd>bavier: I follow what you are saying. I'm trying a bit of a different configuration where I run Guix on the non-root system. The system that I have root access on is out of the picture at this moment. The situation you described is my backup plan at the moment.
<cfd>Alright, I'll give that a try. I'm going to wait out this 'hello' package install and see if it works. It's building as we type!!! I'm concerned though about what was said earlier: "there will almost certainly be many packages whose configure scripts pick things up from /bin, /usr/lib, etc, and thus fail to build properly without isolation. be prepared for a *lot* of working fixing things up.:
<cfd>What is meant by "pick things up"? I don't really understand the problem he is pointing out.
<mark_weaver>cfd: configure scripts look around your system for libraries and programs. often they will not look in PATH, but rather look in hardcoded locations like /usr/lib, /usr/bin, /bin, etc.
<mark_weaver>when guix-daemon is run as root, there's no possibility of configure scripts finding anything else from your system, because the builds are done in an isolated container
<mark_weaver>mixing libraries from your host OS with Guix libraries does not work, because they are linked with different versions of the C library.
<mark_weaver>using programs from your host system are not as likely to immediately fail, but might also cause problems.
<mark_weaver>anyway, as far as I know, no one has tried doing this with Guix, and I expect you will run into many problems.
<cfd>mark_weaver: Thanks for the explanation! The importance of isolated build environments is becoming ever more clear. Good to know I'm going where no admin has gone before!