IRC channel logs

<Infiltrator>What are the problems with the latest linux-libre?

<mark_weaver>Infiltrator: On the Lemote YeeLoong 8101B, there

<mark_weaver>there's a problem with the wireless driver.

<mark_weaver>I strongly suspect that on more mainstream platforms, the latest linux-libre works just fine.

<mark_weaver>also, it should be mentioned that I'm not talking about the pristine linux-libre, but rather the heavily patched version for YeeLoong.

<Infiltrator>Fair enough.

<Infiltrator>I wasn't sure whether you mean technical problems or policy problems. (If it were the latter, I would be quite curious.)

<Infiltrator>s/mean/meant/

<mark_weaver>AFAIK, the pristine linux-libre is quite solid.

<Infiltrator>That's what I too heard.

<a_e>Hello, Guix!

<mark_weaver>hi a_e!

<mark_weaver>I just reported the libffi bug and patch upstream: http://article.gmane.org/gmane.comp.lib.ffi.general/1004

<davexunit>wow. impressive bug hunting mark_weaver.

<mark_weaver>thanks :)

<a_e>Yes indeed. Lots of work, congratulations!

<mark_weaver>I compiled a whole load of stuff on MIPS N32 so far.

<mark_weaver>this is what I've built so far: http://paste.lisp.org/display/139586

<a_e>Me, almost nothing; even with a fresh checkout, the code from nix compiles, but the guile compilation fails with

<mark_weaver>there is some duplication in there, because I had to rebuild lots of stuff after fixing libffi.

<a_e> http://paste.lisp.org/display/139587

<a_e>Quite a lot indeed, including X, perl and python.

<a_e>I am using guile-2.0.5 from debian wheezy.

<mark_weaver>a_e: hmm, I have a vague recollection of seeing that, and perhaps it was fixed with a "make clean" ?

<mark_weaver>a_e: you're using the 'loongson' branch I assume?

<a_e>Yes, the loongson branch.

<a_e>I would be surprised if "make clean" helped, as it happens on a pristine checkout.

<a_e>Trying again, nevertheless, just in case.

<mark_weaver>a_e: I'm using guile-2.0.9. You might try upgrading. I seem to recall that there are still some lingering prblems with 2.0.5.

<Steap>a_e: do you also own a loongson machine ?

<a_e>Steap: viric sent me one.

<mark_weaver>a_e: I'm also using libgc-7.2d, which is highly recommended. a simple "./configure && make && make check && sudo make install" of the upstream libgc source worked well for me on wheezy.

<mark_weaver>sneek: libgc?

<mark_weaver>oops, wrong channel for that :)

<mark_weaver> http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.2d.tar.gz

<a_e>Hm, how about simply updating to debian testing? Would that not be the easiest solution?

<mark_weaver>I'd recommend "apt-get build-dep guile-2.0", and then install libgc-7.2d from upstream source, and then install guile-2.0.9 from upstream source.

<mark_weaver>a_e: yeah, I suppose that might work also, but I never tried jessie on the Yeeloong.

<mark_weaver>it sounds risky.

<a_e>Maybe I am naive. But I would have argued that if version n works, then so does version n+1 ;-)

<mark_weaver>well, that tends to be the case with more popular hardware, but the Yeeloong doesn't really fall under that category.

<mark_weaver>fwiw, the newer linux-libre 3.10.15 kernel (with loongson patches) I've been playing with has some problems on the YeeLoong, whereas linux-libre 2.6.39.1 works flawlessly.

<Steap>mark_weaver: gonna be a hell of a 'git bisect'

<mark_weaver>specifically: 3.10.15 locks up hard if I try to use the built-in wireless, and even if I avoid it, it sometimes locks up, whereas 2.6.39.1 is rock solid.

<mark_weaver>Steap: heh, yeah, that would take a *long* time.

<a_e>mark_weaver: "make clean" did not help. I will compile libgc and guile.

<mark_weaver>a_e: sounds good.

<a_e>mark_weaver: In debian, I am using 3.2.0-4-loongson-2f. It does not lock up, but I do not have a wireless card either.

<mark_weaver>a_e: okay, thanks! maybe I'll try something close to that.

<a_e>These slow machines are very relaxing. You watch the lines "checking..." flow by on the screen...

<a_e>How long does guile take to compile on the fuloong?

<mark_weaver>I haven't timed it, but a few hours as I recall.

<a_e>Oh!

<mark_weaver>if you like, you can copy the .go files from a faster box, as long as it has the same pointer size and endianness.

<mark_weaver>but if you do that, make sure you copy from a pristine build of upstream guile-2.0.9.

<mark_weaver>(or more generally, from the same source code)

<a_e>It is probably safer to compile natively (and I have only one machine anyway).

<mark_weaver>btw, the GUILEC jobs will get much faster later on. the early ones are slow because the compiler itself has not yet been compiled, so the compiler is being interpreted.

<a_e>So far, it is SNARFing files ending on .x. What is this?

<mark_weaver>a_e: see http://www.gnu.org/software/guile/manual/html_node/Function-Snarfing.html

<mark_weaver>a_e: after you've compiled the C code, then it has to compile the .scm files to .go files. the first couple of them take a *long* time, so long that you might think it's hung. Be patient. after the first few it gets gradually faster, as more and more components of the compiler are compiled.

<mark_weaver>those compilations are shown as GUILEC in the make output.

<mark_weaver>for the first few, what's actually happening is this: a very limited (unoptimized) Scheme interpreter written in C is used to interpret a better interpreter written in Scheme (also unoptimized), which is used to interpret the compiler.

<mark_weaver>bootstrapping a language written mostly in itself is tricky :)

<mark_weaver>but at least we don't punt and require that you have a binary executable of Guile to compile itself, like many other projects do.

<mark_weaver>it is awfully slow though

<mark_weaver>fortunately, if you track Guile using git, then you almost never have to go through that process.

<a_e>I have heard about compilers compiling compilers, but interpreters interpreting interpreters...

<a_e>Well, it fails:

<a_e>GEN guile-procedures.texi

<a_e>/home/privat/guile-2.0.9/libguile/.libs/lt-guile: symbol lookup error: /home/privat/guile-2.0.9/libguile/.libs/libguile-2.0.so.22: undefined symbol: GC_set_all_interior_pointers

<mark_weaver>a_e: it sounds like you need to re-run configure. did you run configure before installing libgc?

<mark_weaver>after installing the new libgc-7.2d, that is.

<a_e>Yes, I did. Still, the library links to /usr/lib/libgc.so.1

<mark_weaver>did you run 'ldconfig' after installing libgc-7.2d?

<a_e>Instead of /usr/local/lib/libgc.so

<a_e>mark_weaver: Thanks, that was it!

<mark_weaver>a_e: you'll probably need to re-run configure, since the autoconf tests probably linked with the old libgc and made measurements based on that.

<a_e>Okay. Just to be on the safe side!

<mark_weaver>you'll need to run 'ldconfig' after installing guile too, btw.

<a_e>I will try to think of it tomorrow...

<mark_weaver>hehe

<mark_weaver>hmm. Guix compiled 'cairo', and then 'poppler', and now its recompiling 'cairo' again.

<a_e>This is normal; look at poppler in pdf.scm.

<a_e>Poppler depends on cairo and vice versa.

<a_e>So we first compile a cairo without poppler input as an input to poppler.

<a_e>And then cairo with this poppler input.

<mark_weaver>okay, thanks!

<a_e>After running "ldconfig", I am now entering the GUILEC phase.

<mark_weaver>a_e: excellent!

<mark_weaver>okay, I've built the final cairo, harfbuzz, and pango. currently building gtk+

<mark_weaver>and after that, it should build emacs, which was my goal for the moment :)

<a_e>So you can write your patches on the machine ;-)

<mark_weaver>oh, this is already my only local machine. outside of guix I have my home-built N32 system based on CLFS.

<mark_weaver>my thinkpad, which I was previously using, developed a backlight problem shortly after I got my new YeeLoong.

<mark_weaver>(I can still ssh into it though)

<Steap>a_e: do you think it's fine to update cmake in the master branch ?

<a_e>Steap: Why not? You should give it a try and check if Qt still compiles/

<Steap>a_e: yeah, that's why I'm wondering whether it should go in core-updates

<Steap>I think bumping to the latest version might solve Nikita's issue with Lapack

<Steap>And I think there are probably no huge regression in cmake

<a_e>No, it would need to go into core-updates if it triggered a rebuild of nearly everything.

<a_e>If it is only about a few packages, master is fine.

<Steap>k

<Steap>I'll try and compile qt

<Steap>if it works, I'll just push

<a_e>Okay.

<a_e>Good luck!

<Steap>a_e: Qt fails on Hydra

<Steap>For 4.8.5, the URL seems to be wrong; 'single' should not be in it, could you take a look at it ?

<a_e>Right, thanks for spotting this! I just pushed a fix.

<a_e>It might still not compile, because it needs pulseaudio, which also fails on hydra.

<a_e>But it did compile on my local machine.

<Steap>damn

<Steap>it takes a long time on my machine

<Steap>But I've just seen that the .tar.gz is huge

<Steap>230MB

IRC channel logs

2013-10-23.log