***Infiltra1or is now known as Infiltrator
<zacts>I've decided to move and go to a creative art school for comp sci. My current school is m$ centric and teaches mainly java. <zacts>I would love to work on guix one day for GSoC, once I change schools, maybe. <zacts>I like creative free hacking / art / creative environments.. <zacts>I'm getting through 'Scheme and the Art of Programming' and I hope to do some patches soon importing packages.. <zacts>I'll paste my debian build failures when I get a chance <zacts>the scheme and art of programming book is a good intro for SICP, and teaches more than I would learn for my entire 4 year degree at my current school. <zacts>this new school I want to go to will let me use 100% free software for my projects, and it's much more creative. I think it is project based, and you do internships. <zacts>and it's a fully accredited school <jmd>Does anyone else have problems with the substitutor crashing or is it just me? <bavier>jmd: I was having trouble the other day too <bavier>have you looked at commit de67926? <jmd>Almost got octave packaged ... <a_e>jmd: The binary substituter also "died unexpectedly" for me from time to time; I thought it was just a network problem or so. On the second try, it then worked. <a_e>Hooray for octave! Only today did I think of it as we now have gfortran. <a_e>civodul: Your fix for mit-krb5 is a very mixed blessing, since it forces us to compile gcc-4.7 also, which takes quite a long time on weak machines. <a_e>Last time, my fuloong died before finishing gcc. <civodul>well, i didn't want to spend more time investigating, i confess <a_e>mark_weaver: So I might have kernel issues on my fuloong as you predicted. <civodul>a_e: the substituter "died unexpectedly" issue was fixed yesterday, i think <a_e>It just falls out of the network. As there is no monitor attached, I cannot see anything. Might there be any log files? <a_e>Or maybe I should just keep my ssh window open instead of detaching it into a screen session. <a_e>civodul: Maybe just a bug report could help. <a_e>There are more problems. luit in xorg.scm, for instance. I investigated and found a patch, which I hope to apply at some point in time. <a_e>"more problems with gcc-4.8", I mean. <a_e>mark_weaver: 3.2.0-4-loongson-2f from debian wheezy. <a_e>civodul: It was not a big deal, anyway. <civodul>a_e: did you have a chance to look at the CMake thing? <civodul>i stumbled upon a package that needs it <a_e>If anyone feels like doing it, please go ahead. <a_e>bavier: Excellent! This was a programme on my list. It has lots of dependencies, if I remember correctly. <a_e>civodul: Efficient! You were much faster than I would have been. <civodul>that's was mostly copy/pasting, and i knew what to copy/paste ;-) <a_e>I know, still, it would have taken me more time. <bavier>a_e: yes, quite a few dependencies in lilypond, but I think I got them all together <a_e>Very nice! How about submitting them one after the other to the mailing list? <bavier>there are some issues yet in the build that I need to take care of first <a_e>civodul: Now that we have mips as an working architecture, do we still need the mips64el-* packages? <a_e>Those that fail on i686? <mark_weaver>what's the plan for supporting multiple APIs on a given architecture? I'd like to experiment with the MIPS N64 ABI for a few packages. <mark_weaver>I suppose I could accomplish this by creating a branch of guix that uses the N64 ABI, and then bootstrapping it, and installing those packages in a different profile than my N32 packages, etc. but clearly that's suboptimal. <civodul>a_e: we want to make sure we can still cross-bootstrap to the supported architectures <civodul>hence "make assert-binaries-available" <civodul>mark_weaver: in theory we shouldn't need a different system type string, right? <civodul>on n32 you could build a toolchain that supports n64, and use it wherever needed <mark_weaver>civodul: I don't know how to answer that, because I don't know what the requirements of the guix system type string. <a_e>Bad news for ffmpeg: The new 2.1.1 also fails on i686. I will have to make a bug report. <mark_weaver>the GNU triplet is different for different ABIs, and I guess that's important. <civodul>mark_weaver: i know, but i was talking of the Nix/Guix "system type" tuplet <a_e>civodul: Maybe we should have a triplet instead? <mark_weaver>civodul: if I simply build another toolchain that supports n64, how awkward would it then be to build any arbitrary Guix package, along with all of its inputs, transitively? <civodul>you could use package-with-explicit-inputs or similar <civodul>at least for experimentation purposes <civodul>then of course, we should settle one a single preferred ABI per system type <mark_weaver>civodul: but what happens when there are dozens of packages that need to built? <mark_weaver>I don't want to have to hack the source code of gnu/packages/*.scm for each of those packages. <a_e>So one could decide for one abi all through. <civodul>well, you can have a helper that "converts" a package to n64 <civodul>you write a procedure, pretty much like package-with-explicit-inputs and such likes <civodul>that takes the package and does whatever it takes to make it n64 <a_e>Why should we settle on a single preferred abi? <a_e>With a triplet, the user could choose. <mark_weaver>it would be far easier for me to just have a separate branch of guix, on which MIPS N64 is used. <mark_weaver>and then use that branch when I want to install N64 packages. <civodul>but then you're bound to have two irreconcilable branches, for ever and ever <civodul>a_e: yes, but that's more than needed <mark_weaver>well, I agree it's also bad. but there should be a better solution to supporting multiple ABIs. <a_e>They could be in one branch if we used triplets to distinguish, no? <civodul>i agree it should be easy to choose, though <mark_weaver>IMO, there should be an optional argument to "guix build" and "guix package" that selects the ABI. <civodul>well, OTOH, i686-linux is pretty much another ABI for x86_64-linux <civodul>so that would be an argument in favor of using the system type for ABIs <civodul>mark_weaver: agreed, but the question is how do we handle this at the API level? <mark_weaver>I should also say that I'd want N64 compiles to be done natively, not requiring cross-compilation. <a_e>civodul: I think on arm the third part of the triplet is meaningful in selecting the abi. <civodul>currently on my x86_64 box i can do "guix package -i foo -s i686-linux", and it just works <mark_weaver>because (I guess) cross-compilation means that autoconf tests can no longer be done properly. <civodul>mark_weaver: in the example above, everything is done natively, using the Linux personality(2) <mark_weaver>so yeah, maybe it should be part of the system type after all. <civodul>n32 and n64 use different syscalls, right? <mark_weaver>I'm sorry, I think I was mistaken. I think N32 and N64 use the same syscalls, which are different than O32. <civodul>to me the guideline should be: if it's purely userland, leave the system type unchanged <mark_weaver>btw, how does "guix package -i foo -s <system>" work if the build system can't run <system> binaries? <civodul>for instance, we don't use GNU triplet in the system type, because which libc is used is a userland concern <civodul>mark_weaver: i tries to invoke the "build hook"; there's currently none in Guix, but in Nix that's a Perl script that offloads the build to a known machine of that type <mark_weaver>well, my only real concern is that it should be as convenient to build N64 packages as to build N32 packages. <a_e>So what would be the system types for n32 and n64? <a_e>So far, we only have mips64el-linux for either of them. <mark_weaver>if it's possible to say "guix build --abi=n64 guile" and "guix package --abi=n64 -i guile" or something to that effect, and that the builds are all done natively on my own machine, then I'll be satisfied. <a_e>There is a bug report to get ffmpeg (instead of the libav fork) back into debian: <mark_weaver>civodul: sorry, I was wrong. the syscalls are different for N32 vs N64.