Unexpected EOF reading a line (from guix pull)

  • Done
  • quality assurance status badge
Details
5 participants
  • dian_cecht
  • Ludovic Courtès
  • ng0
  • Ricardo Wurmus
  • Ricardo Wurmus
Owner
unassigned
Submitted by
dian_cecht
Severity
normal

Debbugs page

D
D
dian_cecht wrote on 11 Oct 2016 15:34
(address . bug-guix@gnu.org)
20161011223407.GA31313@khaalida
Hello,

Someone in IRC asked me to email these errors here as a bug report, so I
shall.

I was just trying to install Guix on a Gentoo machine via the
youbroketheinternet overlay (installed via layman). During the initial 'guix
pull;guix package -i hello', I ended up with a weird error at the very end of
guix pull (as root);

Found valid signature for
/gnu/store/7nfjg3f2c4s0jpz3vqh3iqdn9j1c3prq-perl-5.22.1
From
Downloading 7nfjg3…-perl-5.22.1 (49.7MiB installed)...
perl-5.22.1 3.7MiB/s 00:04 | 15.2MiB transferred
guix package: error: build failed: unexpected EOF reading a line

then, when trying to run guix pull as a user, I got this (I havn't authorized
hydra as the user, but I did as root);

unpacking '/gnu/store/1wrar9kq9pnyg4mw0yg1qx5a5xrr4y5v-guix-latest.tar.gz'...
The following derivation will be built:
/gnu/store/xrhj8sj7gdk74vmyqi8cg07zbhdxfbw6-guix-latest.drv
building path(s) '/gnu/store/9mm7kqkdsmj67byll1k4vq65622gsrr0-guix-latest'
guix pull: error: build failed: unexpected EOF reading a line

I'm not sure what the problem is, but that is multiple EOF errors from the same
command from different users, so someone should probably take a look at it.

PS. I'm not sure if I'm subscribed to this mailing list, so if you need input
from me, just make sure to email me a copy. Thanks.
N
N
ng0 wrote on 11 Oct 2016 16:07
8760oycwno.fsf@we.make.ritual.n0.is
Hi,

thanks for the bugreport, and thanks for using the gentoo-overlay :)

dian_cecht@zoho.com writes:

Toggle quote (10 lines)
> Hello,
>
> Someone in IRC asked me to email these errors here as a bug report, so I
> shall.
>
> I was just trying to install Guix on a Gentoo machine via the
> youbroketheinternet overlay (installed via layman). During the initial 'guix
> pull;guix package -i hello', I ended up with a weird error at the very end of
> guix pull (as root);

For others to add: One of the federated sources of this overlay and the
only source with webview is at https://gnunet.org/git/
In the youbroketheinternet-overlay repository Guix is located in sys-apps/guix/

Toggle quote (20 lines)
> Found valid signature for
> /gnu/store/7nfjg3f2c4s0jpz3vqh3iqdn9j1c3prq-perl-5.22.1
> From
> https://mirror.hydra.gnu.org/nar/7nfjg3f2c4s0jpz3vqh3iqdn9j1c3prq-perl-5.22.1
> Downloading 7nfjg3…-perl-5.22.1 (49.7MiB installed)...
> perl-5.22.1 3.7MiB/s 00:04 | 15.2MiB transferred
> guix package: error: build failed: unexpected EOF reading a line
>
> then, when trying to run guix pull as a user, I got this (I havn't authorized
> hydra as the user, but I did as root);
>
> unpacking '/gnu/store/1wrar9kq9pnyg4mw0yg1qx5a5xrr4y5v-guix-latest.tar.gz'...
> The following derivation will be built:
> /gnu/store/xrhj8sj7gdk74vmyqi8cg07zbhdxfbw6-guix-latest.drv
> building path(s) '/gnu/store/9mm7kqkdsmj67byll1k4vq65622gsrr0-guix-latest'
> guix pull: error: build failed: unexpected EOF reading a line
>
> I'm not sure what the problem is, but that is multiple EOF errors from the same
> command from different users, so someone should probably take a look at it.

As debugging can be difficult on Gentoo, and it could be just that - a
Gentoo problem - I'll send in details tomorrow on how a very minimal
(gentoo) system looks/behaves with the guix from the gentoo-overlay
installed.

But if this is a problem with Guix, someone else could help independent
from what I'll contribute.

Toggle quote (3 lines)
> PS. I'm not sure if I'm subscribed to this mailing list, so if you need input
> from me, just make sure to email me a copy. Thanks.
>
N
N
ng0 wrote on 13 Oct 2016 01:09
Re: bug#24670: Unexpected EOF reading a line (from guix pull) [forward]
87y41s8ybd.fsf@we.make.ritual.n0.is
The following message has been forwarded to this bug again. There are
some details removed which will not be useful to anyone but me - I don't
think many people are running Gentoo here so I was told to remove the
output of "emerge --info" as this is only useful to recreate a somewhat
similar system.

To reply to your bug (as I wrote before), just reply to the initial info
message or.. If this doesn't get sorted out use
$bugid@debbugs.gnu.org. More on this can be found here:
myself. The debbugs team of gnu should really document this more
visible.

dian_cecht@zoho.com writes:

Toggle quote (36 lines)
> 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. I've
> even tried to track down where a profile might exist within /gnu/store, but
> "ls /gnu/store/*profile*" responds with:
>
> ls -1 /gnu/store/*profile*
> 4.0K /gnu/store/ba2bkragdwyb1yhlsqq8idvz7ps4bnqk-profile-builder
> 4.0K /gnu/store/ccbgqxinaimvy0nxi7b9gy1000z533yg-profile-builder
> 4.0K /gnu/store/giplwz9pldknh5v1zmjjxmqcxy2qscai-profile.drv
> 4.0K /gnu/store/h2l6kjwdbdfv4k47ibmgc270p9mbf9d8-profile.drv
> 8.0K /gnu/store/lzmyqhnccl8rppjwiih08xh2wamqg9x3-profiles.scm
> 4.0K /gnu/store/mrj87096jj84x5asicyqmkicfbx0zxwm-profile.drv
> 4.0K /gnu/store/xavk99lizyl83qwqnpirjr9ck68b2wnf-profile-builder
>
> and when I look at what I get from the binary tarball from the website, the
> profile symlinks seem to do as follows (note I extracted this as a normal user
> into $HOME, so dirs might not be exactly the same):
>
> var/guix/profiles/per-user/root/guix-profile -> /var/guix/profiles/per-user/root/guix-profile-1-link
> var/guix/profiles/per-user/root/guix-profile-1-link -> /gnu/store/6wz49d3pxf1dqc0rzmigsp6yr9abbz1x-profile
>
> Note the lack of any suffix on the last line; this simply isn't created via guix
> pull nor by the ebuild, and if guix is simply sourcing these files, this /might/
> explain why this error keeps coming up. It also means that Guix is slightly
> broken because it doesn't handle this file missing in any reasonable manner (I'd
> consider "sane" to be spitting out an error message or, preferably, generating a
> reasonable symlink and related file tree, explaining that it did so and why,
> then proceeding (or giving the user the option to proceed).
R
R
Ricardo Wurmus wrote on 13 Oct 2016 04:25
(name . ng0)(address . ng0@we.make.ritual.n0.is)
idjbmyoxzgx.fsf@bimsb-sys02.mdc-berlin.net
Toggle quote (14 lines)
> dian_cecht@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).

Toggle quote (4 lines)
>> 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:



~~ Ricardo
N
N
ng0 wrote on 13 Oct 2016 05:44
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)
87vawwquzt.fsf@we.make.ritual.n0.is
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

Toggle quote (19 lines)
>> dian_cecht@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).

As far as I know what I did on my personal testing VM was:
emerge guix; <autorize hydra, start daemon>; guix pull (as user); guix
package -i hello

I can confirm once I have time to log into the VM again, state has not
been altered. Like I wrote offlist, for me in an vanilla x86_64 VM it
worked. I'll debug this at some point with the info I got offlist, if
debugging is needed at Gentoo side.

Toggle quote (16 lines)
>>> 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
>

The guix package in gentoo is my attempt to create something which works
well in the Gentoo structure of doing things. But of course it is
currently masked for being experimental.. anyone using Gentoo should
know that there might be risks attached. Actually I should drop
'guix-binary' as I don't work on that version of the package anymore,
this is just from the source.
N
N
ng0 wrote on 13 Oct 2016 17:10
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)
87k2dbvlhd.fsf@we.make.ritual.n0.is
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

Toggle quote (35 lines)
>> dian_cecht@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
D
D
dian_cecht wrote on 13 Oct 2016 17:21
Re: bug #24670: Unexpected EOF reading a line (from guix pull)
(address . 24670@debbugs.gnu.org)
20161014002114.GA28542@khaalida
Hello,

I hope this is going to land in the right place. Anyways, I emailed ng0
this and he suggested I send it to the bug report since it could make a
difference.

When I was looking to try and figure out what was going wrong, I didn't even
think about the fact I have /gnu mounted as a seperate parition, since I'm
installing Guix on Gentoo system and my root partition is rather close to full
for my liking. The perms for the mounted dir is:

4.0K drwxr-xr-x 2 root root 4.0K Oct 13 07:57 gnu/

Hope that helps us figure this out.
R
R
Ricardo Wurmus wrote on 14 Oct 2016 03:06
Re: bug#24670: bug #24670: Unexpected EOF reading a line (from guix pull)
(address . dian_cecht@zoho.com)(address . 24670@debbugs.gnu.org)
idj4m4fxn0u.fsf@bimsb-sys02.mdc-berlin.net
dian_cecht@zoho.com writes:

Toggle quote (7 lines)
> When I was looking to try and figure out what was going wrong, I didn't even
> think about the fact I have /gnu mounted as a seperate parition, since I'm
> installing Guix on Gentoo system and my root partition is rather close to full
> for my liking. The perms for the mounted dir is:
>
> 4.0K drwxr-xr-x 2 root root 4.0K Oct 13 07:57 gnu/

There’s nothing wrong with having /gnu on a separate partition. I’m
doing the same on our HPC cluster at work (/gnu is on NFS).

Have you tried to install Guix using the binary installation method?

~~ Ricardo
R
R
Ricardo Wurmus wrote on 14 Oct 2016 03:08
Re: bug#24670: Unexpected EOF reading a line (from guix pull) [forward]
(name . ng0)(address . ng0@we.make.ritual.n0.is)
idj37jzxmxf.fsf@bimsb-sys02.mdc-berlin.net
ng0 <ng0@we.make.ritual.n0.is> writes:

Toggle quote (3 lines)
> 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.

What makes you say this is “very likely” the cause?

I have no problems having /gnu on an NFS share on a remote fileserver
with guix-daemon running on a separate server.

~~ Ricardo
N
N
ng0 wrote on 14 Oct 2016 04:22
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)
87twcfp44d.fsf@we.make.ritual.n0.is
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

Toggle quote (7 lines)
> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>> 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.
>
> What makes you say this is “very likely” the cause?

I summarized the email I got offlist, I should've written this before I
started summarizing it.
'Very likely' was not my own finding. This is a case of Gentoo/Guix I
can not debug. For vanilla amd64_x86 systems my guix ebuild works. I
haven't tried the guix-binary ebuild yet (lynX did some finishing
touches) but this should behave the same.

Toggle quote (5 lines)
> I have no problems having /gnu on an NFS share on a remote fileserver
> with guix-daemon running on a separate server.
>
> ~~ Ricardo
>
R
R
Ricardo Wurmus wrote on 14 Oct 2016 04:53
(name . ng0)(address . ng0@we.make.ritual.n0.is)
idjzim7w3i3.fsf@bimsb-sys02.mdc-berlin.net
ng0 <ng0@we.make.ritual.n0.is> writes:

Toggle quote (14 lines)
> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
>
>> ng0 <ng0@we.make.ritual.n0.is> writes:
>>
>>> 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.
>>
>> What makes you say this is “very likely” the cause?
>
> I summarized the email I got offlist, I should've written this before I
> started summarizing it.
> 'Very likely' was not my own finding. This is a case of Gentoo/Guix I
> can not debug.

That’s okay, but I’d like to know what makes this the likely cause. Has
this behaviour been reproduced on another machine?

As Guix has no problems with a store on a different partition I don’t
know if it makes sense to keep this bug report open. I cannot reproduce
this on my machines.

~~ Ricardo
N
N
ng0 wrote on 14 Oct 2016 05:21
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)
87r37jp1dj.fsf@we.make.ritual.n0.is
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

Toggle quote (26 lines)
> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
>>
>>> ng0 <ng0@we.make.ritual.n0.is> writes:
>>>
>>>> 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.
>>>
>>> What makes you say this is “very likely” the cause?
>>
>> I summarized the email I got offlist, I should've written this before I
>> started summarizing it.
>> 'Very likely' was not my own finding. This is a case of Gentoo/Guix I
>> can not debug.
>
> That’s okay, but I’d like to know what makes this the likely cause. Has
> this behaviour been reproduced on another machine?
>
> As Guix has no problems with a store on a different partition I don’t
> know if it makes sense to keep this bug report open. I cannot reproduce
> this on my machines.
>
> ~~ Ricardo
>

I'd like to keep it open. Right now I don't have the time to create a VM
to ~roughly~ reproduce this, I am busy with some upcoming personal
events. The bug ended up here, I offered bugs.gentoo.org (as far as I
know gentoo-overlays can use this shared infrastructure), my personal
email and our debbugs, so it makes sense to treat it as unsolved as long
as I wasn't able to reproduce it. However in addition to the "emerge
--info" I already got, I might need further info. Which guix ebuild was
used? "guix-bin" or "guix"?

It is impossible to reproduce exactly the system which caused the bug,
but I will try to reproduce it as good as you can with Gentoo.
I will assume (the unlikely case) that there are no package specific
use-flags set and just copy more or less what the emerge --info spit
out.. but this will take time (going from stage3 to that particular
stage4...). Otherwise I would accept a stage4 of the system, but I don't
know how much developing on Gentoo experience dian_cecht has. Creating
your own stage4 is documented but it still requires uploading this
stage4 somewhere.
Furthermore, dian_cecht could you give me the exact chain of commands
you made up to the point of failure (or where you are right now)
starting from emerge guix? This would really help to reproduce the
problem. If you are not able to reconstruct this, please try to recall
what you did and describe it. All I've got so far is feedback on what's
broken not how it got to be broken.

Thanks,
ng0
R
R
Ricardo Wurmus wrote on 14 Oct 2016 06:17
(name . ng0)(address . ng0@we.make.ritual.n0.is)
idjwphbvzmd.fsf@bimsb-sys02.mdc-berlin.net
ng0 <ng0@we.make.ritual.n0.is> writes:

Toggle quote (3 lines)
> It is impossible to reproduce exactly the system which caused the bug,
> but I will try to reproduce it as good as you can with Gentoo.

I chuckled a little. It’s ironic because with Guix we actually can
reproduce systems with relative ease :)

Which is why I suggest trying the official installation method. If the
user can reproduce this with the official release we could actually
investigate this better. If this is specific to a third-party package
of Guix it doesn’t really belong here, in my opinion.

~~ Ricardo
N
N
ng0 wrote on 14 Oct 2016 07:21
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)
871szjxb8p.fsf@we.make.ritual.n0.is
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

Toggle quote (8 lines)
> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>> It is impossible to reproduce exactly the system which caused the bug,
>> but I will try to reproduce it as good as you can with Gentoo.
>
> I chuckled a little. It’s ironic because with Guix we actually can
> reproduce systems with relative ease :)

Yeah… you know one of the reasons why I prefer Guix work over my Gentoo
works. Yet I still maintain for Gentoo... and possibly will become
Gentoo developer next year so that GNUnet packages can be in portage.

Toggle quote (8 lines)
> Which is why I suggest trying the official installation method. If the
> user can reproduce this with the official release we could actually
> investigate this better. If this is specific to a third-party package
> of Guix it doesn’t really belong here, in my opinion.
>
> ~~ Ricardo
>

I'd still like to get the information I asked for, that's enough for me
to work on checking for a potential bug.
Beyond that I agree that the official installation method should be
tried when the third party installation offered by my ebuild fails.
N
N
ng0 wrote on 14 Oct 2016 07:33
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)
87y41rvw3p.fsf@we.make.ritual.n0.is
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

Toggle quote (8 lines)
> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>> It is impossible to reproduce exactly the system which caused the bug,
>> but I will try to reproduce it as good as you can with Gentoo.
>
> I chuckled a little. It’s ironic because with Guix we actually can
> reproduce systems with relative ease :)

Food for thought: right now, yes. But what happens when more people
start to use Guix, with modified versions of packages or even versions
of packages which are no longer in master? Do we simply ignore the
request for support with "sorry, this is not in master we can not
reproduce it"?
The systems following master go towards being reproducible, but custom
systems (and that's what Gentoo is) will appear and they will make this
harder, a new challenge to face maybe.
R
R
Ricardo Wurmus wrote on 14 Oct 2016 07:37
(name . ng0)(address . ng0@we.make.ritual.n0.is)
idjshrzvvxk.fsf@bimsb-sys02.mdc-berlin.net
ng0 <ng0@we.make.ritual.n0.is> writes:

Toggle quote (16 lines)
> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
>
>> ng0 <ng0@we.make.ritual.n0.is> writes:
>>
>>> It is impossible to reproduce exactly the system which caused the bug,
>>> but I will try to reproduce it as good as you can with Gentoo.
>>
>> I chuckled a little. It’s ironic because with Guix we actually can
>> reproduce systems with relative ease :)
>
> Food for thought: right now, yes. But what happens when more people
> start to use Guix, with modified versions of packages or even versions
> of packages which are no longer in master? Do we simply ignore the
> request for support with "sorry, this is not in master we can not
> reproduce it"?

Given the Guix git hash (and provided the software builds reproducibly)
even older systems can be reproduced.

But it would be unreasonable to expect support for things that were
broken in old versions and have already been fixed in master.

~~ Ricardo
D
D
dian_cecht wrote on 15 Oct 2016 21:57
Re: bug#24670: bug #24670: Unexpected EOF reading a line (from guix pull)
20161016045701.GA17581@khaalida
On Fri, Oct 14, 2016 at 12:06:41PM +0200, Ricardo Wurmus wrote:
Toggle quote (8 lines)
>
> There’s nothing wrong with having /gnu on a separate partition. I’m
> doing the same on our HPC cluster at work (/gnu is on NFS).
>
> Have you tried to install Guix using the binary installation method?
>
> ~~ Ricardo

I just got the binary version to install and seems to be working properly. I've
managed to install hello via guix package -i hello.

$ which hello
/var/guix/profiles/per-user/user/guix-profile/bin/hello

So I think it is all fine and the problem is likely with the ebuild.
R
R
Ricardo Wurmus wrote on 16 Oct 2016 03:23
(address . dian_cecht@zoho.com)(address . 24670@debbugs.gnu.org)
87inssh9sv.fsf@elephly.net
dian_cecht@zoho.com writes:

Toggle quote (17 lines)
> On Fri, Oct 14, 2016 at 12:06:41PM +0200, Ricardo Wurmus wrote:
>>
>> There’s nothing wrong with having /gnu on a separate partition. I’m
>> doing the same on our HPC cluster at work (/gnu is on NFS).
>>
>> Have you tried to install Guix using the binary installation method?
>>
>> ~~ Ricardo
>
> I just got the binary version to install and seems to be working properly. I've
> managed to install hello via guix package -i hello.
>
> $ which hello
> /var/guix/profiles/per-user/user/guix-profile/bin/hello
>
> So I think it is all fine and the problem is likely with the ebuild.

Thank you for giving this a try!

~~ Ricardo
L
L
Ludovic Courtès wrote on 17 Oct 2016 06:29
control message for bug #24670
(address . control@debbugs.gnu.org)
87bmyjayu2.fsf@gnu.org
tags 24670 notabug
close 24670
?
Your comment

This issue is archived.

To comment on this conversation send an email to 24670@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 24670
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch