GNU bug report logs - #24670
Unexpected EOF reading a line (from guix pull)

Previous Next

Full log

Message #20 received at 24670 <at> debbugs.gnu.org (full text, mbox):

From: ng0 <ng0 <at> we.make.ritual.n0.is>
To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
Cc: 24670 <at> debbugs.gnu.org, dian_cecht <at> zoho.com
Subject: Re: bug#24670: Unexpected EOF reading a line (from guix pull)
 [forward]
Date: Fri, 14 Oct 2016 00:10:38 +0000

Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> writes:

>> dian_cecht <at> zoho.com writes:
>>
>>> I'm just sending this to you since I think I might have figured out what is
>>> happening, and I don't know how to respond to bugs via the mailing list.
>>> Instruction on replying to bugs via the mailing list would be quite a help.
>>>
>>> Basically, /var/lib/guix/profiles/per-user/$USER/guix-profile doesn't exist. For
>>> example, on the root account on my machine (I've run guix pull multiple times as
>>> root, and even tried to install icecat as a normal user, plus running guix pull
>>> several times as a normal user) $HOME/.guix-profile points to a nonexistent
>>> file/directory, and where it points to
>>> (/var/lib/guix/profiles/per-user/root/guix-profile) simply doesn't
>>> exist.
>
> The profile is created automatically the first time “guix package -i” is
> run.  This happens reliably for me on Fedora, CentOS, and on GuixSD.  If
> this doesn’t happen Gentoo I suspect the Gentoo package to be defective
> (e.g. setting invalid permissions on certain directories).
>
>>> I've
>>> even tried to track down where a profile might exist within /gnu/store, but
>>> "ls /gnu/store/*profile*" responds with:
>
> This is not important.  Anything Guix creates will be in the store.
> This includes all profile generations.
>
> I suggest installing Guix using the official binary package.  See this
> page for the tarballs and the install instructions:
>
>     https://www.gnu.org/software/guix/download/
>
>
> ~~ Ricardo
>

Without adding all of the off-ticket/list email I got: the failure is
very likely caused by /gnu/store being on a separate partition. I was
not able to get information if the store has been moved there
post-install in addition (my ebuild certainly doesn't do that as can be
seen in its file at gnunet.org/git/)

My tests only include a system where most things are on / (root), taking
the examples of gentoo handbook as an orientation of the general system
layout of users who might happen to use my ebuilds.
So I've read issues about the /gnu/store in the past, and I've seen
solutions I think, but the answer to this should be something open to
people who run this in practice - I don't do this and have no own
experience to share.

-- 
♥Ⓐ  ng0

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.