***slkhbgs is now known as {V}
<mark_weaver>I successfully built pulseaudio on my Yeeloong by increasing the timeout of the thread-test (the same one that intermittently times out on hydra) <mark_weaver>I just pushed fixes for pulseaudio, libtheora, and libmad to the 'loongson' branch, which in turn should enable quite a bit of other stuff to now build successfully. <civodul>damn, the GCC upgrade didn't go smoothly <civodul>jxself: nope, just a failed attempt in the 'core-updates' branch <mark_weaver>civodul: what do you think of freezing the core components of core-updates for a bit before it's merged into master, so that we can generate new bootstrap tarballs of x86_64/i686/mips64el with the same date and versions, and then testing bootstrap from there on core-updates before merging into master? <mark_weaver>I'm not sure if it's worth doing, but it was an idea I had. <civodul>mark_weaver: sounds like a good idea <civodul>it's better to leave some time for building/testing <civodul>the thing is we now have to update the bootstrap tools <civodul>mark_weaver: do you think you could look into the non-determinism issue in Guile? <mark_weaver>it'll probably take about a week (maybe a bit more) on the YeeLoong for me to generate the bootstrap tarballs and the re-bootstrap from there. <civodul>i wonder if the machine of a_e is fater <mark_weaver>I intend to look into the non-determinism thing, but it's not easy. I'm not sure we can plan on doing that before this upcoming freeze/release. Next week is fundraising week at the MIT radio station, and I'm going to have to spend a bunch of time on that. <mark_weaver>anyway, please let me know when you're ready to freeze the core components of core-updates, so I can begin the process of building. <civodul>i think we must first merge "fuloong" into "core-updates", actually <mark_weaver>the problem is that I can't really test any of those patches without first bootstrapping from core-updates. <civodul>and then we should first try to new bootstrap tools on x86_64 <civodul>and if that works you can start building on MIPS <mark_weaver>and I don't want to do that until the core components are essentially frozen (except for my loongson merges) <civodul>mark_weaver: well these were tested in "fuloong", right? *civodul is confused with all these names :-) <mark_weaver>should I be merging things into 'core-updates' without testing them first? <civodul>there's Binutils, libffi, what else? <mark_weaver>it's true, there's a high probability that my patches won't break anything. <civodul>Binutils is the same in both branches, for instance <mark_weaver>there's binutils, libtool (skip one test), libffi, alsalib, pulseaudio, libtheora, mit-krb5, gdb, libmad, so far. <mark_weaver>I think everything else is at higher levels in the stack. <mark_weaver>most of my earlier patches were done in the old patch style, so I'll have to change to the new. that's pretty easy of course, but it's an opportunity to make a mistake, if I can't test it. <mark_weaver>I suppose I could do some sanity testing on my x86_64 box. <mark_weaver>the problem I'm having at the moment is that once again, I can't run ./bootstrap on my fresh checkout of core-updates, because 'git' doesn't work with Github. There's an SSL error. <mark_weaver>I worked around this problem before by copying over the git checkout from my x86_64 box. <mark_weaver>but now that I have almost everything I need in Guix, including 'git', I thought that this would just work. but it doesn't. help appreciated. <a_e>mark_weaver: Did you try to populate .certs and to run c_rehash? <a_e>Here is what I have in my .certs: <a_e>certplus_class2.pem Equifax_Secure_Certificate_Authority.pem thawte_Premium_Server_CA.pem thawte_Primary_Root_CA.pem Verisign-PCA-3.pem <a_e>I think one of them is used for github. <a_e>I can do a "git pull" without problem, using the git from guix master. <mark_weaver>okay, I'll try, although I have an 'strace -f' and it doesn't seem to be looking in that directory at all. but it's worth a try. <civodul>mark_weaver: the patches will be applied on the other arches as well, so we'll notice if there's such a mistake *jxself begins setting up a chroot for Guix to live in <jxself>It makes me feel more comfortable. <mark_weaver>yeah, it only puts things in /nix/store, and all the builds are done in chroots as unprivileged users. <civodul>BTW, i saw Guix in the "Free Software Supporter" <civodul>i wonder if jxself is for something in that ;-) <jxself>Oh, there's no libvpx? Something to add... <civodul>funny to see that there has to be a news item on some external site for the FSF to talk about it ;-) <jxself>It could, but requires libvpx to be present and something like --enable-libvpx or something like that. <mark_weaver>as a side note: when I tried to get video playback working well on the YeeLoong a couple of years ago, I found that the libtheora decoder was a *lot* faster on MIPS than the libvpx one was. the libvpx one was essentially unusable on the YeeLoong. <mark_weaver>hopefully there has been some improvement since I last looked. <jxself>Sure. Theora is far easier to decode. <mark_weaver>it's such a shame that theora has not been more widely used. <jxself>I seem to recall reading about decoder speed improvements in the project blog but I'm not sure if it'll help your or not. <jxself>Or even when they were for that matter, so maybe they were already present in what you tried. <mark_weaver>the version I last built was libvpx-v0.9.7-p1, built on 18 Nov 2011. <mark_weaver>most likely, I just need to sit down and write some assembler stubs for the important decoders that use the Loongson 2F SIMD instructions. <mark_weaver>on Loongson 2F, several of the important SIMD instructions are not standard MIPS. <jxself>But one specifically mentions x86. <mark_weaver>even if it's x86, I should be able to pretty much copy what they did for x86 SIMD and use the Loongson 2F SIMD instead. <jxself>Hmmm.... I was thinking. What about making FFmpeg only encode to unencumbered formats? It could still decode & play everything. <jxself>Something like --disable-encoders --disable-muxers --enable-encoder=ffv1,flac,libtheora,libvorbis,libopus,libvpx_vp8,libvpx_vp9 --enable-muxer=matroska,matroska_audio,ogg,webm <mark_weaver>I dunno. of course I like to discourage people from encoding to patented formats, but I'm not sure if we should deliberately remove that functionality from our ffmpeg package. <civodul>jxself: sounds like a good policy, but OTOH, those patents are inapplicable in some places of the world <civodul>for instance, we have 'lame' in the distro <civodul>clearly we don't want to encourage its use <civodul>yet, it can be legally used in many places <civodul>i don't remember if the FSDG says something about this <jxself>It does talk of patents & leaves it up the distro. <mark_weaver>I vaguely recall reading that googlecode stopped providing download service for tarballs a while back. thus our pysqlite recipe is broken. <jxself>Hmmm. I can't seem to access the pysqlite project on Google Code at all. <mark_weaver>grump. the hash of the file apparently changed, and also wget bails on downloading from this site because the certificate name doesn't match the domain name :-( <mark_weaver>yes, the hash changed, even though the version number wasn't bumped. <jxself>Hmmm. Perhaps this is the reason for the different hash. <mark_weaver>when I try to open it in emacs, it tries to use tar mode but runs into errors. <jxself>What if you just do tar xf and let tar do things by itself <mark_weaver>it always says: tar: This does not look like a tar archive <mark_weaver>so I renamed it, bunzip2'd it, and the result is an apparently corrupted tar file. <mark_weaver>when I download from hydra using wget, it reports a mime type of [application/x-nix-archive] <mark_weaver>civodul: any idea why that file on hydra is apparently corrupt? <wm4><mark_weaver> the new ffmpeg package doesn't support VPx yet <- it should have native vpx decoders *jxself was looking at the encoding side of things <civodul>mark_weaver: it's not corrupt; what made you think so? <mark_weaver>civodul: I downloaded it with 'wget', and I can't untar it. <jxself>wm4: We do need libvpx for this. :) <jxself>mark_weaver: That might be an interesting thing to check out too, to see if it might help with making decoding any faster for you. <mark_weaver>at some point I'll take another close look at getting video decoding working as well as I can on this box. <mark_weaver>I think this little box could probably do okay with videos up to 480p if we could just get the software properly optimized. <mark_weaver>a couple of years ago, I managed to get it to the point of (just barely) playing an 480p H.264/AAC video quite well. and then I recompiled something and things broke and I never got it working properly again. but now at least I know it's possible. <jxself>I suppose H.264 depends on the level (baseline, main, high.) <mark_weaver>yeah, I'll have to look at the details of the file I tried. <a_e>jxself: Feel free to package more video codecs! <jxself>Ah. I've heard that people enjoyed that. I've never seen it. <a_e>As I wrote on the mailing list, for someone new to packaging, I would recommend opus first. <a_e>The oggvorbis packages were all just perfect in adhering to the gnu standards. <civodul>a_e is the head of human resources department, and we're recruiting :-) <mark_weaver>it's pretty well done. my main complaint is that they felt the need to insert a bunch of totally gratuitous nudity and sex that's not in the books. <jxself>Opus & libvpx, although there have been a number of improvements to Theora since the 1.1 release. It might be nice to have one built from a subversion checkout. <antonios>Hi guys, is GUIX a beta version still? I managed to install software but when I try to update/upgrade "guix pull" I get ERROR: In procedure put-bytevector: Wrong type argument in position 2 (expecting bytevector): #f and guix pull: error: failed to download up-to-date source, exiting <a_e>mark_weaver: You confused me. I thought they added sex to the vpx decoders ;-) <civodul>antonios: yes, it's alpha; which version do you use? <civodul>there have been bugs in "guix pull" fixed recently, after the 0.4 release <a_e>jxself: Our general policy is to not package from the cvs. We rely on upstream to make releases when their software changes enough. <a_e>But nothing prevents you from creating a custom recipe in your installation. <a_e>However, it would be better to push them towards a release. <jxself>a_e: But it's stable, quite good (check out Monty's demo pages) and I think most of Xiph's work it spent working in Daala at the moment. <a_e>antonios: If you are comfortable with it, I would recommend to use a git checkout. <jxself>(Yes, 1.2 is been in the oven for a while.) :) <a_e>jxself: Well, if it is stable and much better than before, they should make a release. We have enough work as is, without making releases for upstreams! <antonios>OK thanks. Another thing: I compiled guix on AntiX Libre, if I install a package with guix that also exists in apt and after a few days for example a new version in the apt sources becomes available, if if use apt to update/upgrade will my box freak out (talking about dependencies collisions etc). Cause I wanna move to guix 100%. <a_e>antonios: No collisions are possible. <jxself>a_e: It's just not there yet. Perhaps, once I get everything going, I'll package up an svn version. <antonios>I will give it some time to be more familiar with it a_e and then I'll do that. <jxself>'cause I just can't imagine encoding Theora using 1.1. Ugggh. <a_e>a_e: Guix installs all its files first in /nix/store, and then if they are installed in the user profile under $HOME/.guix-profile. <a_e>If you uninstall a program from guix and install it with apt, it will be chosen from /usr/bin instead. <a_e>(In any case, you will need to add $HOME/.guix-profile/bin to your path.) <antonios>Hhmm, thanks, I'll try it now actually to test it. Thanks a lot ;) <a_e>jxself: Do you have any leverage on pushing them towards a release? 1.1.5 or 1.1.99 would be fine. <a_e>Like: Unless you make a release, the FSF is going to switch to something else. <a_e>jxself: If you have the choice to use vpx... <a_e>For what it is worth, I managed to compile icecat 24. <a_e>Then it failed "make check". <a_e>Because there is no test target... <a_e>I disabled the tests and tried again. <a_e>After 3 hours, it failed. <a_e>Because I had kept the previous build and /tmp was full... <a_e>I will also have to tamper a bit with different configure flags, and as each build takes hours, it will be a while. <a_e>But I am rather optimistic we will soon get there. <a_e>(Well, assuming that the program actually _runs_ and not only _compiles_.) <mark_weaver>IceCat doesn't support MIPS, so until that's fixed we'll also need the parabola version of iceweasel (abrowser? I forget the name), which last I checked was the most modern FSDG-compliant browser that currently runs on YeeLoong. <jxself>It doesn't? That's disappointing. <mark_weaver>civodul: how is the <PROFILE>/share/info/dir file supposed to be handled? currently, based on the messages I'm seeing, it looks like it's arbitrarily choosing one from one of the packages. <a_e>I think we need a field that tells us that a certain package does not compile on a given target. <a_e>The simplest solution would be a list of target triples where the package should be disabled. <a_e>Better, I think, would be a function that takes as input the target triplet and returns a boolean (so we could test whether a target contains "mips", for instance). <civodul>yeah exactly: we need to add hooks to handle things like 'dir' <jxself>"Strapping rockets to a pig" ha. *jxself is listening to Monty's talk of Opus & Daala <civodul>mark_weaver: why would IceCat not work on MIPS when Iceweasel does? <civodul>mark_weaver: it's basically the same code no? <mark_weaver>well, sincer Iceweasel is part of Debian, there are people from all the ports making sure that it works. <mark_weaver>of course, I imagine the same fixes would be applied to icecat, and we should do that. <civodul>aah sure, but then we can steal patches from patch-tracker.debian.org, no? :-) <jxself>Maybe these patches can/should go upstream to GNU Icecat? I wonder if they want them... <civodul>yes, perhaps it's been submitted already <a_e>mark_weaver: Could it not even go upupstream into firefox? <a_e>civodul: On hydra, it complained about not finding mpfr. What does this have to do with c++ headers? <mark_weaver>a_e: sure, if firefox wasn't too far ahead of the version I was using. <civodul>a_e: locally i fixed the MPFR issue (easy), and then stumbled upon the Real Problem <a_e>civodul: Okay. How did you fix the mpfr issue? <civodul>by just removing the MPFR workaround in base.scm, in gcc-cross-boot0 <a_e>civodul: Okay. I was not aware we needed to work around something. <a_e>mark_weaver: Now would be a good time to send patches, I suppose; icecat is at 24, firefox at 25, so maybe the two are not too far apart yet. <mark_weaver>BTW, should GCC be using the bundled copies of GMP/MPFR/MPC? <a_e>Or maybe the problems have even been fixed between icecat 17 and 24. <mark_weaver>a_e: would you like to look into icecat on the yeeloong? I'm swamped. <mark_weaver>speaking of which, how's your Guix MIPS N32 bootstrap coming along? <a_e>mark_weaver: I first need to get it on x86... Where it takes already more than 3 hours. It will be terrible on the loongson... <mark_weaver>texlive is failing to build on my system, because its configure script thinks it's failing to find pixman, cairo, and some others. the reason it thinks it's failing is because the test programs are linking to libgd but not to some other libraries that libgd depends on. <mark_weaver>libgd.so has references to symbols in other libraries (e.g. libjpeg) that are not explicitly on the link line. <a_e>It has been built on hydra: <a_e>Ffmpeg triggers an internal compiler bug on hydra on x86_64. <a_e>(And there was a silly typo on i686.) <civodul>a_e: FFmpeg fails to build on both arches, actually <a_e>Yes, as I wrote: Typo in --disable-3dnow on i686; and the compiler bug on x86_64 (where 3dnow is enabled). <a_e>A problem on hydra? I cannot load the web page any more. <jxself>Neither can I. It's just spinning... <a_e>Now I can connect, and indeed, there is a new error for ffmpeg on i686: <a_e>libavcodec/x86/cabac.h:174:5: error: 'asm' operand has impossible constraints <a_e>And so on in several header (!) files. <a_e>It is a known problem: <civodul>perhaps we could try with 4.8 if that happens too <a_e>If someone feels like following up (they asked for details that the original poster did not provide); otherwise, I will do it in a week. <a_e>civodul: Yes, that would also be an option. <civodul>we just need to add it as an input, and it'll override the other gcc