IRC channel logs


back to list of 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.)
<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:
<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:
<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>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 :)
<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 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 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.
<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
<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/ 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/
<mark_weaver>did you run 'ldconfig' after installing libgc-7.2d?
<a_e>Instead of /usr/local/lib/
<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>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>I'll try and compile qt
<Steap>if it works, I'll just push
<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>it takes a long time on my machine
<Steap>But I've just seen that the .tar.gz is huge