IRC channel logs

2013-11-27.log

back to list of logs

***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
<zacts>=)
<zacts>lo
<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.
<civodul>hello!
<a_e>Last time, my fuloong died before finishing gcc.
<a_e>Yes, hello ;-)
<civodul>aah, right
<civodul>i always forget about slow machines
<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.
<mark_weaver>a_e: what are you seeing?
<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.
<mark_weaver>a_e: what kernel are you running?
<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>No time.
<civodul>ok
<civodul>i could look into it
<a_e>If anyone feels like doing it, please go ahead.
<bavier>I'm working on lilypond, btw
<a_e>bavier: Excellent! This was a programme on my list. It has lots of dependencies, if I remember correctly.
<civodul>a_e: done!
<a_e>civodul: Efficient! You were much faster than I would have been.
<civodul>heh
<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.
<civodul>a_e: yes
<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
<civodul>mips64el-linux
<civodul>a_e: argh
<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?
<civodul>well, they get built :-)
<civodul>what do you mean?
<mark_weaver>I don't want to have to hack the source code of gnu/packages/*.scm for each of those packages.
<civodul>a_e: that shouldn't be necessary
<civodul>aah
<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
<civodul>see what i mean?
<a_e>Why should we settle on a single preferred abi?
<mark_weaver>I'm sorry, but I think that's terrible.
<a_e>With a triplet, the user could choose.
<civodul>mark_weaver: why?
<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>*that* is terrible
<civodul>:-)
<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
<a_e>"gnueabi" and such
<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>ah, okay, good!
<mark_weaver>so yeah, maybe it should be part of the system type after all.
<civodul>well, that's the easy way
<civodul>n32 and n64 use different syscalls, right?
<mark_weaver>yeah
<civodul>same for x32 vs. x86_64?
<mark_weaver>oh wait, I'm not sure
<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>ok
<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>civodul: okay, that makes sense.
<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.
<civodul>yes, that's the ideal thing
<a_e>There is a bug report to get ffmpeg (instead of the libav fork) back into debian:
<a_e> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203
<a_e>Amusing!
<civodul>heh
<mark_weaver>civodul: sorry, I was wrong. the syscalls are different for N32 vs N64.
<mark_weaver>O32, N64, and N32 each have their own syscall number range. http://www.linux-mips.org/wiki/Syscall
<civodul>ok