<grantixx>Sorry, attempted to go to restroom on this ankle... never has it taken longer for me to move 10 feet and back.
<mark_weaver>akamch: the installation system runs within a ramdisk. it sounds like you are filling it up.
<mark_weaver>the two most likely causes are (1) that you didn't run the 'cow-store' command, or (2) that the last argument to 'guix system init' is a directory that is not actually mounted from the hard disk, but rather just a directory in the ramdisk.
<ewemoa>is there a way to execute phases one by one manually and sort of examine results along the way?
<mark_weaver>ewemoa: 'guix environment' is similar to nix-shell, I guess.
<mark_weaver>(although I confess I know almost nothing about nix-shell except what I just gathered from a quick web search)
<rekado_>mark_weaver: thanks for fixing gitorious downloads. I'll try again tonight and prepare a new patch soon.
<ewemoa>mark_weaver: yes, i noticed 'guix environment' in the ml archives but didn't quite manage to figure out how to run phases indidivually -- w/ nix-shell, one might invoke it to get a shell w/ build inputs prepared, then one can execute the phases individually from the shell
<mark_weaver>vanila: that indicates that there was a problem with the transfer. unfortunately our build farm is currently overloaded, and sometimes that happens. the error message could use improvement of course. so much to do.
<mark_weaver>phant0mas: okay, then please push the updated branch. since it's a rebase, you'll need to delete the old branch on savannah first, by running "git push origin :wip-hurd" (note the ':' in there)
<mark_weaver>after that, push the branch as usual, which will recreate it on savannah.
<taylanub>hm, nginx put its config right to <out>/config so it ends up in ~/.guix-profile/config. that should be changed I suppose?
<taylanub>oh, it's a directory. still not good I suppose.
<taylanub>there's also the directories 'html' and 'logs'. the former should probably be changed; the latter is empty and will probably never be written to (i.e. files created in it) but I guess it's still not good that it's there...
***Pastaf is now known as ignucius
***ignucius is now known as Pastaf
<mark_weaver>taylanub: thanks for the exim package, but I wonder if you have 'native-inputs' and 'inputs' reversed.
<mark_weaver>maybe the top-level Makefile is recursively calling 'make' in subdirectories without propagating those arguments.
<mark_weaver>taylanub: do you understand the meaning of 'native-inputs' and 'inputs' ?>
<taylanub>my mind is still not clear on inputs vs. native inputs :\\ the libraries need to be on the build machine for their headers, but since headers are just source information for the compiler, they needn't be native, right?
<taylanub>whereas gzip and perl are actually executed, so they have to be native
<mark_weaver>taylanub: headers for normal 'inputs' will be available at build time.
<mark_weaver>taylanub: when cross-compiling, the distinction is import. suppose you are cross-compiling for ARM on an i686 box.
<mark_weaver>then the 'native-inputs' will be built for i686 and 'inputs' will be built for ARM.
<mark_weaver>since, in this example, exim would need to run on ARM, it needs normal 'inputs' for any libraries it links to, or programs that it needs to use when it is run after installation.
<mark_weaver>and additionally, if it's needed at run-time, you probably have to patch the place in the source code where it is launched, to refer to the absolute path, and make sure to get the one from the normal 'input'.
<taylanub>mark_weaver: updated patch sent. BTW I happened to notice 'exigrep' referencing the commands zcat/bzcat/xzcat/lzma, so I added bzip2 and xz as inputs as well and made all references absolute. (it's kind of worrying how easily such things can go unnoticed though; this was pure luck)