<LnL>I have the same issue, is there some stable channel I can pull from? <Steap>fatal: Could not read from remote repository. <Steap>is there an issue with git://git.savannah.gnu.org/guix.git ? <mark_weaver>accessing savannah git via ssh works though, so people with savannah accounts can access it. <Steap>has anyone reached out to the sysadmins? <mark_weaver>I'm doing so now, just in case they don't already know. <mark_weaver>Steap: regarding 'git', it also seems that cloning via the 'http' protocol works, or at least I'm doing it now successfully... <efraim>is git fetch working for other people? <efraim>I saw it was working ~9 hours ago for some people <z0d>GNU git was down for me yesterday and still is <z0d>but maybe it was working in between <mark_weaver>for me, savannah git works via ssh and http but not via the git protocol <z0d>indeed. I only checked git <z0d>HTTP works for me too <z0d>I know. thanks anyway <efraim>ah, thanks for the help with http <rekado>savannah git still doesn't work for me via ssh, but this may be a local network problem. <civodul>"git pull --rebase" works for me over ssh <civodul>but git:// fails with "fatal: Could not read from remote repository." <rekado>I get Timeout, server git.sv.gnu.org not responding. <rekado>fatal: The remote end hung up unexpectedly <rekado>my remote url is rekado@git.sv.gnu.org:/srv/git/guix.git <efraim>same error as rekado over git://, `time` lists it as 16.5 minutes <civodul>anyone remembers the GNU social account of the FSF sysadmins? <kmicu>FWIW I also cannot fetch any updates from git://git.sv.gnu.org/{guix,emacs}.git which is quite ‘funny’ if you consider that *D* in DVCS when centralized Savannah is inoperative. <civodul>well these days what's really funny is the GitHubs, the Gitorious, the GitLabs <civodul>these ones can (and do) really disappear <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 <civodul>that's unlikely to happen with Savannah <civodul>but yeah, regardless, right now we're waiting for it to be back up :-) <kmicu>Where ‘overnight’ for Gitorious/Google Code equals ‘months’. There is no need to bend the facts — vendor lock–in always ends badly. <civodul>for Gitorious it was 3 weeks IIRC, but yeah :-) <bavier>It can't be that hard to set up a mirror of the git repo somewhere, right? <bavier>I don't want to assume savannah issues in perpetuity, but it couldn't hurt to have a fallback in place <bavier>mark_weaver: thanks for the cleanup commit for (gnu packages documentation); I forgot to check the build after a `make clean` <GNUtoo-irssi>And also thanks to the presentation on it at libreplanet <GNUtoo-irssi>If it's in parabola, it's just a matter of compiling the packcages, right? <davexunit>but each new platform must go through a porting process <efraim>I think the mailinglist is mostly down too <GNUtoo-irssi>I've been looking how to achieve what guix is doing (extreme configurability, defining machines with one file, etc) and didn't found good tools for that <GNUtoo-irssi>I also want reproducible builds, and given arch status, i'd have to wait a long time <bavier>GNUtoo-irssi: we're working pretty hard on the reproducible builds front; we'd love your help if it's something you're interested in <GNUtoo-irssi>do I need to do something special to use the binary packages (package cache?) <bavier>GNUtoo-irssi: you need to enable substitutes <wingo>binary distributions should surely enable substitutes by default. you're trusting the binary distribution anyway <GNUtoo-irssi>(I'll probably change it in 2 hours due to some wiki editing issues with tor) <GNUtoo-irssi>(there is some ban that will be removed in about 2 hours for 127.0.0.1) <GNUtoo-irssi>Anyway, part of the files can be downloaded, but the rest has to be built <wingo> 90 files changed, 4447 insertions(+), 4554 deletions(-) <wingo>that includes documentation additions and a couple new scheme modules tho <GNUtoo-irssi>I took the default commandline config(.scm), removed ssh, admin and so on, only grub, %base-files and %base-packages is left <GNUtoo-irssi>and when I do: "guix system init /mnt/etc/config.scm /mnt" it downloads sources <bavier>GNUtoo-irssi: are you sure it's downloading sources rather than binary substitutes? <GNUtoo-irssi>bavier: maybe I should wait until there are some more packages then <bavier>GNUtoo-irssi: could you run the command with --dry-run to see what would be downloaded? <GNUtoo-irssi>guix package -i hello --dry-run: 5 downloaded files, the rest is built (more than 20) <GNUtoo-irssi>like the equivalent of aptitude update && aptitude upgrade (or pacman -Syu) ***jgay_ is now known as jgay
<janneke>halteaugrabuge: can you post your config.scm, how did you configure/install your system? <halteaugrabuge>i can't, it was not in a VM. I just followed the installation guide. But i will re-install guixSD in a VM until i have a working distro' : ) <janneke>halteaugrabuge: if you have someething like (users (cons* (user-account (name "janneke") (home-directory "/home/janneke")) %base-user-accounts)), that should work <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>Is the second step possible? <cfd>bavier: Thanks for your help! Much needed and appreciated. <cfd>Once I have compiled the properly configured guix binary I can port it to another system with the same architecture? <bavier>cfd: once installed, guix allows you do do normal package management as a user <bavier>so, if you do have root, I'd recommend following the normal installation instructions, which require root only for starting the daemon <bavier>cfd: would guix's binary distribution work for you? <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>Thanks for the links! <cfd>I may try one of the approaches you listed, but I think the "Installing Guix from Guix" approach is the most promising solution I've come across. <bavier>cfd: yes, you can install guix on your root machine to bootstrap an unprivileged guix ***ktosiek is now known as czlowiek_deprech
***czlowiek_deprech is now known as czlowiekdeprecha
<cfd>alezost: Thanks for the correction. <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 <bavier>cfd: did you start the daemon as root? <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>Is there an easy/quick to build package besides 'hello' that doesn't require me to compile half of the world's source code. I'm just looking for a quick test. <bavier>cfd: maybe `guix build --dry-run foo` and then try building one of the '*-boo0' packages <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!