IRC channel logs

2015-01-09.log

back to list of logs

*jxself thinks davexunit is awesome for making srt2vtt
<davexunit>jxself: re pump.io: so ffmpeg can do the conversion now?
<jxself>I don't know if it'll convert them but at least once they're in the right format you can add them.
<jxself>I've not tried to see if it can convert or not.
<davexunit>oh okay.
<davexunit>so my work might be useful after all, for now. ;)
<jxself>Yes. :)
<jxself>I've not been putting subtitles into my videos... until now. :)
<davexunit>oh you've used it and it worked?
<davexunit>perhaps I'll make a quick project page for it, make a release tarball, and package it for guix.
<jxself>I've not used srt2vtt yet, no. But I assume it does and so now I'll be able to convert the subtitles into the proper format and start doing so.
<davexunit>let me know if you run into problems. I only tested with 2 SRT files that volunteers made for the FSF user liberation video.
<jxself>But of the subtitles I work with come in a different format (images, from DVD.) They first need to be OCRed into SRT.
<civodul>mark_weaver: ouch, i'll have to debug it locally
<jxself>And now I can concert the SRT, thanks to you. :)
<jxself>er convert
<davexunit>cool, I hope it doesn't blow up. :)
<davexunit>thankfully SRT is a simple format, so any parsing issues should be easy to fix.
<jxself>I'll certainly report if I find any. It'd be even better if DVD subtitles were text to begin with so you don't have to spend time looking for and correcting OCR errors but the DVD specification was created years ago and that ship has sailed.
<davexunit>jxself: cool, if it works decently enough for you, I'll 'make distcheck' it and release to the world.
<zacts>hi hackers
<civodul>Hello Guix!
<civodul>news item! https://savannah.gnu.org/forum/forum.php?forum_id=8175
<civodul>spread the words on the reddits and HNs ;-)
<grasshopprWhoppr>civodul, did you mean "Mark H Weaver and John Darrington"?
<mark_weaver>civodul: I've seen this error a few times, both on Hydra and on the armhf bootstrap since rebasing on current core-updates: "libtoolize: error: One of these is required: gm4 gnum4 m4 / libtoolize: error: Please install GNU M4, or 'export M4=/path/to/gnu/m4'."
<mark_weaver>nice guix progress report, btw!
<mark_weaver>e.g. here: http://hydra.gnu.org/build/189427/nixlog/7/tail-reload
<mark_weaver>strangely, that particular package 'libuninameslist' hits that libtool/m4 problem on x86_64, but not on armhf.
<mark_weaver>but I've run into the problem on armhf as well, on libpsl.
<mark_weaver>something's wrong with cgit on savannah.
<mark_weaver>nevermind, seems to be fixed now
<mark_weaver>(or maybe it was just on my end to begin with :)
<civodul>grasshopprWhoppr: yes, that's what i wrote no?
<civodul>hmm
<civodul>bavier: yay for 'guix import cpan'!
<svetlana>sorry i am giggling
<svetlana>hehe.. cpan is adorable..
<davexunit>guix on the front page of HN, featuring an appearance by civodul. https://news.ycombinator.com/item?id=8861657
<civodul>:-)
<civodul>mark_weaver: re libuninameslist, i've reproduced it on x86_64, and i guess it's just a matter of propagating m4 from libtool since libtool requires it
<civodul>or requires it at least in some cases
<civodul>(perhaps there's a timestamp issue explaining why the problem did not always manifest?)
<bavier>civodul: thanks for the patch reviews
<someHuman>Hi!
<davexunit>heyllo someHuman
<davexunit>hello, even.
<mark_weaver>civodul: what is http://hydra.gnu.org/project/guix supposed to be doing? I don't remember ever seeing it working.
<civodul>mark_weaver: it could/should be used for continuous integration of guix itself
<civodul>i.e., make && make check
<civodul>it didn't work before because of an issue with the git submodule
<civodul>but now, it should actually be possible to make it work
<mark_weaver>civodul: doesn't that happen as part of the 'guix' package in the gnu project?
<mark_weaver>regarding libtoolize failing to find m4: I wonder if we should be patching our libtoolize to know where to find m4?
<civodul>the 'guix' package there is a snapshot, it's the 'guix-devel' package thing
<civodul>re libtoolize, i patched it (not pushed yet) to use propagated-inputs
<civodul>but what you suggests would work as well
<civodul>might be better
<civodul>WDYT?
<mark_weaver>yeah, I think my plan is better, but then I'm biased :)
<civodul>ah ah :-)
<civodul>yeah you're right
<civodul>hmm do you want to do it? :-)
<mark_weaver>obviously we have to be careful not to patch anything that is _produced_ by libtoolize.
<mark_weaver>okay, I'll take a look
<civodul>yes
<civodul>ok, thanks
<mark_weaver>np!
<civodul>i'm now looking at the cross-compilation/libltdl issue
<mark_weaver>I've successfully rebuilt everything I had built on ARM with the new core-updates, except for 'wget' since that depends on libpsl which suffers from the libtool/m4 issue.
<civodul>good!
<civodul>oh, patch-usr-bin-file only patches the top-level 'configure'
<civodul>so libltdl's 'configure' has a bunch of "Command not found" for /usr/bin/file
<civodul>and then:
<civodul>checking whether the mips64el-linux-gnu-gcc linker (/gnu/store/0bscpzfwxkw98mydr0cmivisnps6g65w-gcc-cross-mips64el-linux-gnu-4.8.4/libexec/gcc/mips64el-linux-gnu/ld -m elf) supports shared libraries... /gnu/store/0bscpzfwxkw98mydr0cmivisnps6g65w-gcc-cross-mips64el-linux-gnu-4.8.4/libexec/gcc/mips64el-linux-gnu/ld: unrecognised emulation mode: elf
<mark_weaver>ah, okay
<civodul>so it ends up cross-building only the shared library
<civodul>and then boom
<mark_weaver>you had suggested changing patch-usr-bin-file to scan for all configure files, but I never got around to doing that.
<civodul>yeah, me neither
<civodul>i think we'll have to fix patch-usr-bin-file, which means full rebuild :-/
<civodul>WDYT?
<mark_weaver>I'm okay with it
<civodul>ok, let me try that
<mark_weaver>after you commit the change, please cancel all pending builds on the older evaluations of core-updates
<mark_weaver>civodul: btw, in case you didn't notice it, we did have a perfect (100% successful) evaluation of core-updates on new years eve. (evaluation 102152)
<mark_weaver>I expect that some of the evaluations after that would have been perfect also, if I hadn't cancelled the builds or deliberately avoided restarting spurious failures.
<mark_weaver>civodul: also, when you update 'patch-usr-bin-file', you can also remove the manual /usr/bin/file patching of extension/configure done in our 'gawk' package.
<sirgazil>Does anyone know how to display graphics in console like this https://en.wikipedia.org/wiki/GNU#mediaviewer/File:HURD_Live_CD.png ?
<civodul>mark_weaver: ok for canceling the old evals
<civodul>and yes for updating gawk, thanks for reminding it
<mark_weaver>sirgazil: some programs are able to display graphics on the framebuffer console device. https://packages.debian.org/fbi comes to mind. I also remember that some of the fancier mostly-text-mode web browsers are able to do it. (links? w3m?)
<mark_weaver>but nowadays I mostly use X, so I don't remember the details
*mark_weaver goes afk
<sirgazil>Thanks, mark.
<civodul>sirgazil: in the Hurd console screenshot, it's not actually an "image"
<civodul>it's a much funnier hack
<civodul>here's the file being displayed: http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/console/motd.UTF8
<civodul>what happens is that the Hurd's console client rebinds 4 Unicode code points to the different parts of the gnu we see on the screenshot :-)
<sirgazil>Ah! I see. Thanks :)
<civodul>mark_weaver: the patch-all-the-configure-scripts fix is probably needed anyway because gcc is full of 'configure' scripts
<civodul>so perhaps some of the runtime libs would have been miscompiled (on mips) or something