<iyzsong>mark_weaver: oh, I mis-pushed to my github repo, is now ok? <iyzsong>mark_weaver: thanks, I feel myself silly >.< <mark_weaver>heh, I think anyone who is honest admits to feeling silly sometimes :) <grantixx>Well, might work on some Stumpwm a bit tomorrow ... I sprung, to popped my ankle out of place. Not going anywhere. ***think is now known as RISCi_ATOM
<grantixx>Should we have asdf in some capacity for CL? <grantixx>Ah man, Git Annex requires so much Haskell. <mark_weaver>grantixx: it may be that we should have an asdf-build-system for CL, dunno. I know very little about it. <mark_weaver>if there's some standard set of commands to build asdf packages, then I guess it would make sense. <ph4nt0mas>hey mark_weaver good morning have you checked the updated patch? should I push the rebased wip-hurd branch? <akamch>Recent 0.8.1 installation failed while installing linux headers with "No space left" error <grantixx>akamch: Are you on GuixSD or a host distro, running Guix? <akamch>unionfs (1.3G) was 100% full after kernel's 'unpack' phase <grantixx>akamch: Did you allocate the whole drive to GuixSD, or a partition? <grantixx>akamch: Hm, can you run parted, fdisk, or similar to see how much of the drive is being used? <akamch>Partition scheme is simple: /dev/sda1 460G as /root, 6G swap <akamch>So mnt (sda1) is all good, only 1% used. The only alarming thing is unionfs' size (first line in df's output). It's all being used up while installing the kernel. <mark_weaver>akamch: did you run the "deco start cow-store <mount-point>" command? <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: no, it's all done within a restricted build environment. <mark_weaver>but if you build with the -K option, you can abort the build in the middle and then examine /tmp/nix-build-* <ewemoa>mark_weaver: yes, i am familiar w/ that route as a user of nix :) <ewemoa>was thinking there might be something like nix-shell <mark_weaver>I suppose you could insert some kind of dummy phase that loops waiting for a file to appear <ewemoa>mark_weaver: ah, dummy phases interleaved with existing phases? <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>ewemoa: it can be done but we could make it a lot easier. wouldn't be too hard. ***Morgawr_ is now known as Morgawr
<rekado_>I'm having a problem building Julia. <rekado_>llvm-config --version says "3.5.0svn" <rekado_>this is used by the Julia build to create the linker flag "-lLLVM-3.5.0svn", but this fails: <rekado_>---> ld: cannot find -lLLVM-3.5.0svn <rekado_>I suspect this flag should have a different name. <taylanub>rekado_: what's the llvm .so called? Julia seems to assume that in this case it would be called libLLVM-3.5.0svn.so <rekado_>odd, the llvm output only contains three .so files: libLTO.so, LLVMHello.so, BugpointPasses.so <rekado_>the julia build procedure gets the ldflags and everything by running llvm-config <rekado_>could also be that the problem is that I'm passing USE_LLVM_SHLIB=1, which is looking for a shared library for LLVM, which seems not to exist in our LLVM package. <rekado_>proceeding without this flag for now. <rekado_>Oh, this looks like a problem: FILE *ldc = popen("/sbin/ldconfig -p", "r"); <rekado_>the goal is to read so names and collect them in a map. <rekado_>I see that nix just replaces "ldconfig" with "true" in their julia package, so I'll do the same. <rekado_>hmm, that's not going to help here. This breaks loading of libpcre (and possibly others). <vanila>(dhclient eth0 is telling me no such device) <davexunit>vanila: the device likely has a different name <vanila>The weird thing is when I run ifconfig, I get no output! <vanila>so im not sure what to make of that <vanila>now I'm just reading about how to use parted :) <davexunit>yes, it is. just rough around the edges right now. :) *vanila tries running i again, hopefully it fixes itself <davexunit>it's possible that the installation image doesn't have the module for your ethernet device <vanila>dhclient did, but the installation itself failed <vanila>it printed out loads of numbersand said something about bzip2 errors <bavier`>oh, sorry, didn't read the full backlog ;) <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. <vanila>so should i run deco start cow-store /mnt again? <mark_weaver>we plan to upgrade our server, and that's currently blocking on me, I confess. alas, I am overloaded as well. <vanila>oh well don't worry about it, im just playing around :) <vanila>guix sounded really great so I'm just checking it out <vanila>im a fan of scheme so that's is a bonus to <vanila>oh that explains all the 'server is somewhat slow' messages <vanila>it seems to be working now (still running though) <akamch>mark_weaver, you didn't sleep too much :) thank you and grantixx for suggestions! Re my earlier "no space left" problems with GSD install: <akamch>yeah, I ran 'deco start cow-store /mnt' before 'guix system init'. <akamch>I reinstalled GSD several times today on two machines, with config.scm close to default and with a minimal config from <mark_weaver>akamch: that was fixed ages ago. it couldn't have been the problem you're seeing. <mark_weaver>akamch: and /mnt was mounted to a large hard disk partition before you ran the "deco start cow-store /mnt" and "guix system init <config> /mnt" commands? <vanila>hrm well it seems to have all installed but I can't actually boot it :( <vanila>it goes into PXE mode, trying to boot off the network <vanila>I think it did the GRUB part correctly though <akamch>Yes. One thing that differentiates unsuccessful install from successful is that massive build from source which caused out of space error. <akamch>vanila: have you checked boot device priority section in BIOS? <mark_weaver>we certainly don't have anything related to PXE in Guix. <vanila>yeah it's just what happens when it can't find anything bootable <mark_weaver>vanila: can it boot from a traditional MSDOS partition map? or does it need an EFI partition? <vanila>I'm don't know enough to answer that, sorry. I think that it's just BIOS, no EFI <mark_weaver>vanila: in the 'grub-configuration' section of your OS config, what device name did you put into (device ??) ? <vanila>it's saved on the computer, I can boot it up to double check <mark_weaver>because if you put /dev/sda1 instead (or some other number), that would explain it. <akamch>btw, could it be legacy vs native SATA mode? <mark_weaver>akamch: are you guessing at your own problem, or vanila's ? <phant0mas>mark_weaver have you checked the updated patch? should I push the rebased wip-hurd branch? <mark_weaver>akamch: to debug your own problem, by best suggestion is to find out where the files are that are filling up your ramdisk. <phant0mas>yeah where is he? haven't seen him online for sometime now <mark_weaver>phant0mas: he announced on guix-devel that he would be away for a week. <mark_weaver>phant0mas: the new patch #1 looks good, although since you list me a co-author, you should probably also add 2015 to my copyright line in that file. <mark_weaver>phant0mas: are the other three patches the same as the ones on the current wip-hurd branch? <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. <mark_weaver>vanila: hmm, that "error: symlink: File exists" could be a problem. was /mnt empty before you ran the command? <vanila>mnt was initally empty but ive run the install command a few times since <mark_weaver>actually, it might be expected that 'cow-store' put something in there. I confess I don't know off-hand. <mark_weaver>vanila: which top-level directories are present in /nmt ? <vanila>things like /boot /usr /etc and so on <vanila>ill boot the computer and do ls and upload the result <vanila>I just realiezd i can plug it in here too <mark_weaver>vanila: If civodul were here, he could surely help more efficiently with this problem, but in his stead: I would recommend reformatting /mnt and starting the installation from scratch. <vanila>oh wait, that's the USB not /dev/sda1 <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>I guess that perl should probably be a native-input. <mark_weaver>not sure about the others, but I suspect they are all reversed. <mark_weaver>taylanub: also, I suspect that all of those substitutions of Makefile variables can be done with #:make-flags instead. <mark_weaver>when you pass FOO=bar to make on the command-line, it overrides any normal variable definitions for FOO in the Makefile. <taylanub>the problem with that was the flags not being passed to other makefiles. is there a better way to solve that? <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>'native-inputs' are for programs that need to be run during the compilation process. <mark_weaver>so, I know that pcre and gnutls are libraries linked with exim, needed at run-time after installation. so those need to be normal 'inputs'. <mark_weaver>I suspect that 'gzip' and 'perl' are used during compilation, am I right? if so, they need to be native-inputs. <mark_weaver>I guess that libxt and libxaw are linked with some kind of utility that comes with exim? if so, they need to be normal inputs. <mark_weaver>np. thanks so much for all the packages! you're on quite a run :) <taylanub>gzip might be used at run-time, I'll look into it <mark_weaver>if it's needed at both run-time and build-time, then you need to add it to both 'native-inputs' and normal 'inputs'. <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)