Unexpected EOF reading a line (from guix pull)

dian_cecht wrote on 12 Oct 2016 00:34

Recipients:(address . bug-guix@gnu.org)

Message-ID:20161011223407.GA31313@khaalida

Hello,
Someone in IRC asked me to email these errors here as a bug report, so Ishall.
I was just trying to install Guix on a Gentoo machine via theyoubroketheinternet overlay (installed via layman). During the initial 'guixpull;guix package -i hello', I ended up with a weird error at the very end ofguix pull (as root);
Found valid signature for/gnu/store/7nfjg3f2c4s0jpz3vqh3iqdn9j1c3prq-perl-5.22.1Fromhttps://mirror.hydra.gnu.org/nar/7nfjg3f2c4s0jpz3vqh3iqdn9j1c3prq-perl-5.22.1Downloading 7nfjg3…-perl-5.22.1 (49.7MiB installed)... perl-5.22.1 3.7MiB/s 00:04 | 15.2MiB transferredguix 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 authorizedhydra 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.drvbuilding 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 samecommand 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 inputfrom me, just make sure to email me a copy. Thanks.

ng0 wrote on 12 Oct 2016 01:07

Recipients:

Message-ID: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 theonly 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 - aGentoo problem - I'll send in details tomorrow on how a very minimal(gentoo) system looks/behaves with the guix from the gentoo-overlayinstalled.
But if this is a problem with Guix, someone else could help independentfrom 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.>

ng0 wrote on 13 Oct 2016 10:09

Re: bug#24670: Unexpected EOF reading a line (from guix pull) [forward]

Recipients:

Message-ID:87y41s8ybd.fsf@we.make.ritual.n0.is

The following message has been forwarded to this bug again. There aresome details removed which will not be useful to anyone but me - I don'tthink many people are running Gentoo here so I was told to remove theoutput of "emerge --info" as this is only useful to recreate a somewhatsimilar system.
To reply to your bug (as I wrote before), just reply to the initial infomessage or.. If this doesn't get sorted out use$bugid@debbugs.gnu.org. More on this can be found here:https://debbugs.gnu.org/Developer.htmlwhich took me long enoughmyself. The debbugs team of gnu should really document this morevisible.
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).

Ricardo Wurmus wrote on 13 Oct 2016 13:25

Recipients:(name . ng0)(address . ng0@we.make.ritual.n0.is)

Message-ID: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” isrun. This happens reliably for me on Fedora, CentOS, and on GuixSD. Ifthis 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 thispage for the tarballs and the install instructions:
https://www.gnu.org/software/guix/download/

~~ Ricardo

ng0 wrote on 13 Oct 2016 14:44

Recipients:(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)

Message-ID: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); guixpackage -i hello
I can confirm once I have time to log into the VM again, state has notbeen altered. Like I wrote offlist, for me in an vanilla x86_64 VM itworked. I'll debug this at some point with the info I got offlist, ifdebugging 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 workswell in the Gentoo structure of doing things. But of course it iscurrently masked for being experimental.. anyone using Gentoo shouldknow 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.

ng0 wrote on 14 Oct 2016 02:10

Recipients:(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)

Message-ID: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 isvery likely caused by /gnu/store being on a separate partition. I wasnot able to get information if the store has been moved therepost-install in addition (my ebuild certainly doesn't do that as can beseen in its file at gnunet.org/git/)
My tests only include a system where most things are on / (root), takingthe examples of gentoo handbook as an orientation of the general systemlayout of users who might happen to use my ebuilds.So I've read issues about the /gnu/store in the past, and I've seensolutions I think, but the answer to this should be something open topeople who run this in practice - I don't do this and have no ownexperience to share.
-- ♥Ⓐ  ng0

dian_cecht wrote on 14 Oct 2016 02:21

Re: bug #24670: Unexpected EOF reading a line (from guix pull)

Recipients:(address . 24670@debbugs.gnu.org)

Message-ID:20161014002114.GA28542@khaalida

Hello,
I hope this is going to land in the right place. Anyways, I emailed ng0this and he suggested I send it to the bug report since it could make adifference.
When I was looking to try and figure out what was going wrong, I didn't eventhink about the fact I have /gnu mounted as a seperate parition, since I'minstalling Guix on Gentoo system and my root partition is rather close to fullfor 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.

Ricardo Wurmus wrote on 14 Oct 2016 12:06

Re: bug#24670: bug #24670: Unexpected EOF reading a line (from guix pull)

Recipients:(address . dian_cecht@zoho.com)(address . 24670@debbugs.gnu.org)

Message-ID: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’mdoing the same on our HPC cluster at work (/gnu is on NFS).
Have you tried to install Guix using the binary installation method?
~~ Ricardo

Ricardo Wurmus wrote on 14 Oct 2016 12:08

Re: bug#24670: Unexpected EOF reading a line (from guix pull) [forward]

Recipients:(name . ng0)(address . ng0@we.make.ritual.n0.is)

Message-ID: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 fileserverwith guix-daemon running on a separate server.
~~ Ricardo

ng0 wrote on 14 Oct 2016 13:22

Recipients:(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)

Message-ID: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 Istarted summarizing it.'Very likely' was not my own finding. This is a case of Gentoo/Guix Ican not debug. For vanilla amd64_x86 systems my guix ebuild works. Ihaven't tried the guix-binary ebuild yet (lynX did some finishingtouches) 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>

Ricardo Wurmus wrote on 14 Oct 2016 13:53

Recipients:(name . ng0)(address . ng0@we.make.ritual.n0.is)

Message-ID: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. Hasthis behaviour been reproduced on another machine?
As Guix has no problems with a store on a different partition I don’tknow if it makes sense to keep this bug report open. I cannot reproducethis on my machines.
~~ Ricardo

ng0 wrote on 14 Oct 2016 14:21

Recipients:(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)

Message-ID: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 VMto ~roughly~ reproduce this, I am busy with some upcoming personalevents. The bug ended up here, I offered bugs.gentoo.org (as far as Iknow gentoo-overlays can use this shared infrastructure), my personalemail and our debbugs, so it makes sense to treat it as unsolved as longas 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 wasused? "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 specificuse-flags set and just copy more or less what the emerge --info spitout.. but this will take time (going from stage3 to that particularstage4...). Otherwise I would accept a stage4 of the system, but I don'tknow how much developing on Gentoo experience dian_cecht has. Creatingyour own stage4 is documented but it still requires uploading thisstage4 somewhere.Furthermore, dian_cecht could you give me the exact chain of commandsyou made up to the point of failure (or where you are right now)starting from emerge guix? This would really help to reproduce theproblem. If you are not able to reconstruct this, please try to recallwhat you did and describe it. All I've got so far is feedback on what'sbroken not how it got to be broken.
Thanks,ng0

Ricardo Wurmus wrote on 14 Oct 2016 15:17

Recipients:(name . ng0)(address . ng0@we.make.ritual.n0.is)

Message-ID: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 canreproduce systems with relative ease :)
Which is why I suggest trying the official installation method. If theuser can reproduce this with the official release we could actuallyinvestigate this better. If this is specific to a third-party packageof Guix it doesn’t really belong here, in my opinion.
~~ Ricardo

ng0 wrote on 14 Oct 2016 16:21

Recipients:(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)

Message-ID: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 Gentooworks. Yet I still maintain for Gentoo... and possibly will becomeGentoo 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 meto work on checking for a potential bug.Beyond that I agree that the official installation method should betried when the third party installation offered by my ebuild fails.

ng0 wrote on 14 Oct 2016 16:33

Recipients:(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)

Message-ID:87y41rvw3p.fsf@we.make.ritual.n0.is

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

Toggle quote (8 lines)

Food for thought: right now, yes. But what happens when more peoplestart to use Guix, with modified versions of packages or even versionsof packages which are no longer in master? Do we simply ignore therequest for support with "sorry, this is not in master we can notreproduce it"?The systems following master go towards being reproducible, but customsystems (and that's what Gentoo is) will appear and they will make thisharder, a new challenge to face maybe.

Ricardo Wurmus wrote on 14 Oct 2016 16:37

Recipients:(name . ng0)(address . ng0@we.make.ritual.n0.is)

Message-ID: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 werebroken in old versions and have already been fixed in master.
~~ Ricardo

dian_cecht wrote on 16 Oct 2016 06:57

Re: bug#24670: bug #24670: Unexpected EOF reading a line (from guix pull)

Recipients:

Message-ID: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'vemanaged 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.

Ricardo Wurmus wrote on 16 Oct 2016 12:23

Recipients:(address . dian_cecht@zoho.com)(address . 24670@debbugs.gnu.org)

Message-ID: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

Ludovic Courtès wrote on 17 Oct 2016 15:29

control message for bug #24670

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87bmyjayu2.fsf@gnu.org

tags 24670 notabugclose 24670

Your comment

This issue is archived.

To comment on this conversation send email to 24670@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date