IRC channel logs

2015-03-12.log

back to list of logs

<nully>nope, major network issue
<nully>after hours i convinced them that its somewhere on the route out of the datacenter
<nully>their techs are looking at it
<nully>i'll keep everyone posted
***kiwnix- is now known as kiwnix
<rekado>yay, the author of MISO changes the license from MIT to GPLv2: https://github.com/yarden/MISO/issues/72#issuecomment-78385209
<rekado>now I can move the miso package from my private bioinformatics-nonfree module to upstream bioinformatics.
<rekado>the problem was that MISO included GPL'd code. Luckily they took it from R, so it was relatively easy to convince them to change the license of the combined work.
<civodul>Hello Guix!
<iyzsong>Hi!
<civodul>any updates regarding hydra.gnu.org and friends?
<civodul> https://pumprock.net/fsfstatus doesn't have anything new
<Sleep_Walker>it seems I was really tired - taskwarrior patch contains description of msmtp - sorry
<iyzsong>I always get depressed easily, unproductive all the days >.<
<iyzsong>Well, maybe that is the way I growing.
<civodul>iyzsong: there are days like this
<Sleep_Walker>I sometimes get depressed as well, but it is interesting that those days I have more free time than usual
<Sleep_Walker>so it can't happen for a while with Guix ;b
<Sleep_Walker>Guixotherapy
<Sleep_Walker>have anyone tried GNU Gnash? is it worth of packaging?
<civodul>it's probably worth packaging, yes
<civodul>i haven't tried
<civodul>i would rate it "medium difficulty"
<civodul>way easier than IcedTea, LO, or LilyPond
<Sleep_Walker>$ curl 'http://www.google.com'
<Sleep_Walker>curl: (4) A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision.
<civodul>weird
<Sleep_Walker>argh
<Sleep_Walker>$ /Devel/git/guix/pre-inst-env guix package -i gnash
<Sleep_Walker>guix: package: command not found
<Sleep_Walker>and how can I possibly debug this?
<Sleep_Walker>#:use-module (gnu packages qt)
<Sleep_Walker>wow
<rekado_>Sleep_Walker: in these cases I check the output of "git diff" and see if the problem remains after "git stash"
<Sleep_Walker>I isolated the change already
<Sleep_Walker>but I haven't understand it yet
<Sleep_Walker>civodul: http://paste.opensuse.org/view/raw/33197708
<Sleep_Walker>this is minimal change leading to:
<Sleep_Walker>$ guix package -s gnash
<Sleep_Walker>guix: package: command not found
<civodul>Sleep_Walker: that's one of those dreaded circular deps
<civodul>can you try: ./pre-inst-env guile -l gnu/packages/web.scm ?
<civodul>it should give you a backtrace
<Sleep_Walker>civodul: it does not http://paste.opensuse.org/view/raw/49149533
<Sleep_Walker>that is one of the dreadest circular deps consequences I ever met
<Sleep_Walker>hm, as workaround I can put it into separate file
<civodul>Sleep_Walker: http://paste.lisp.org/+34TM appears to solve the problem
<civodul>i can't completely test it because my store lacks too many things, my disk doesn't have much space left, and hydra is down :-/
<civodul>so your feedback is welcome!
<davexunit>the problems at MIT are really awful. still working with MIT colo people to get things back up.
<davexunit>:(
<civodul>bah
<civodul>i was about to ask you ;-)
<civodul>is the source of the problem identified?
<chil>I watched the fosdem talk (emacs distros). Pretty cool :)
<civodul>glad you liked it!
<civodul>now you need to see what it's like in practice ;-)
<davexunit>civodul: there seems to be some debate between the MIT colo staff and us about who's hardware is failing.
<davexunit>so I really don't know what the deal is right now until one of our sysadmins sends an update
<chil>I really want to try :)
<civodul>davexunit: ok, we'll see
<civodul>davexunit: BTW, in the meantime you should get back hacking on 'guix publish'
<davexunit>we're of course not happy at all with this absurdly long downtime.
<civodul>tell your employer that it'd put less pressure on the sysadmins ;-)
<davexunit>civodul: this would have been a good time to have it.
<davexunit>hahaha
<davexunit>I want to finish it up. besides the corrupt nar issue, I need to rewrite the (un)compressed port procedures to use the relevant shared libraries instead of subprocesses.
<civodul>as a first step you could go with uncompressed data
<davexunit>yes, that's what I'm doing.
<civodul>nice
<davexunit>I need to better debug the nar issue
<davexunit>that's been the discouraging part that's blocked me for so long.
<civodul>yeah, i can imagine
<civodul>we need to get past that one
<davexunit>yeah. it requires 2 machines as well, which makes doing stuff more complicated.
<civodul>it's possible to simulate things by using 'guix substitute-binary --substitute' directly, and having it unpack the nar in a place other than /gnu/store
<davexunit>I can do that with my own store?
<davexunit>cool
<davexunit>oh, I guess because substitute-binary doesn't check the store?
<davexunit>it just does the thing.
<civodul>exactly
<davexunit>thanks
<civodul>one can do things like: guix substitute-binary --substitute /gnu/store/... /tmp/foobar
<civodul>and the result gets written to /tmp/foobar
<davexunit>awesome
<davexunit>I will do that
<davexunit>thanks
<civodul>np
<Sleep_Walker>civodul: I will test it (now I'm preparing env for gnash so I'd rather not change sources in the meantime)
<civodul>iyzsong: we seem to have a problem with shell init files: "ssh localhost cat foobar" fails with "Command not founud"
<civodul>*found
<civodul>(when using lshd)
<civodul>it seems that lshd uses a non-login shell here
<civodul>so /etc/profile is not sourced, and thus PATH is unset
<Sleep_Walker>yes
<Sleep_Walker>I already noticed that as well :)
<civodul>i'm not sure where the problem is
<civodul>lshd does set $SSH_CLIENT it its child process
<civodul>which should lead Bash to source ~/.bashrc
<civodul>davexunit: note for later: https://github.com/rotty/spells/blob/master/spells/gzip.sls
<davexunit>civodul: can that do all of the types of compression that we support?
<civodul>it does only zlib (i.e., gzip without the gzip header)
<civodul>but libbz2 has the same API
<civodul>so it does most of the job
<nully>on the way backup
<davexunit>okay, cool.
<nully>'sorry about the long delay :/
<davexunit>nully: I just noticed that :)
<nully>k
<davexunit>go nully!
<nully>leaving the site, going to get more details and then leave
<civodul>nully: great, thank you and everyone involved!
*civodul had just set up offloading to a more powerful machine :-)
<civodul>i guess it'll still prove useful one of these days
<nully>yep
<nully>i think we were going to build one w/ mark_weaver
<nully>and install it in one of our colos
<civodul>you mean a new machine?
*civodul attempts to restart the services on hydra
<civodul>things should be back up now
<civodul>load is already at 8, SNAFU
<davexunit>damn
<civodul>thing is, i started substituting thing, which causes the front-end to regenerated the bzip2-compressed nars
<civodul>which is CPU-intensive, of course
<civodul>then this will be in the nginx cache, so hopefully it'll calm down
<civodul>but still...
<Sleep_Walker>dbus-system service is quite fragile
<Sleep_Walker>it refused to start ('Respawning too fast') because of old pid file present
<davexunit>I think I've noticed that
<davexunit>was this on reboot?
<davexunit>mark has been working on cleaning up stuff like that on boot
<Sleep_Walker>yes
<Sleep_Walker>I compiled locally Qt5 and after ~40mins of non-responsivity I rebooted through SysRq
<Sleep_Walker>after reboot I couldn't start the service again
<Sleep_Walker>davexunit: can you debug dmd?
<Sleep_Walker>or trace
<Sleep_Walker>I have hard times figuring what exactly is the action doing
<Sleep_Walker>it doesn't seem that anyone thought about that in design phase
<davexunit>it's not that no one thought about it
<davexunit>it's that it hasn't been written yet
<davexunit>(potentially)
<davexunit>I don't actually know in this case
<davexunit>dmd needs more hackers
<Sleep_Walker>yup
<davexunit>feel free to hack on it.
<Sleep_Walker>I didn't meant to be offensive, I just checked the code when I was trying to figure out how to do that
<_`_>how does dmd do supervision? does it daemonize and use pid files?
<Sleep_Walker>civodul: I can confirm, that the patch resolves the issue
<Sleep_Walker>moment
<civodul>Sleep_Walker: i've just committed it after some testing
<Sleep_Walker>I just met some strange backtrace, which I haven't seen before
<civodul>_`_: it has several mechanism: one of them is fork + monitor SIGCHLD; the other is to just rely on PID files
<civodul>it's not even dmd actually, it's done in Guix, but in code that runs in dmd
<civodul>no borders ;-)
<Sleep_Walker>civodul: your patch leads to next backtrace
<Sleep_Walker> http://paste.opensuse.org/view/raw/90115288
<Sleep_Walker>try `guix package -s sdl'
<Sleep_Walker>I reverted the patch and the problem was gone
<a_e>The old ffmpeg-2.2.13 currently fails its tests on x86_64 (which means that vlc is not built either):
<a_e>ld: libavfilter/libavfilter.a(af_ladspa.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
<a_e>What does this mean?
<Sleep_Walker>it is linker issue
<Sleep_Walker>it expects symbol, but can't find it
<Sleep_Walker>I'd check path
<Sleep_Walker>hm
<Sleep_Walker>a_e: it's not the failing immediately after start, right?
<a_e>It does it in "make check".
<Sleep_Walker>oh
<a_e>The source code includes a call to "dlopen".
<a_e>But I do not understand why the symbol name contains a glibc version.
<a_e>Well, dlopen should not be relevant here. But the source file libavfilter/af_ladspa.c also contains a call to dlclose.
<Sleep_Walker>it's probably versioning of API
<Sleep_Walker>I heard the explanation years ago but I forgot
<Sleep_Walker>it's not the problem here
<civodul>Sleep_Walker: i can't reproduce the sdl problem with 8c9653b; do you have changes on top of that?
<civodul>a_e: that's GNU symbol versioning
<Sleep_Walker>I'm at 46ffff90245de835e72a756a6801e11e05161b87 now
<Sleep_Walker>I'll update and recheck
<a_e>civodul: From where does this version appear?
<civodul>normally ld adds it automatically to the libc-using package
<civodul>but here it seems to be hardcoded
*civodul fetches the ffmpeg code
<a_e>Actually, I think I know how to update vlc, see the mailing list; so we may be able to drop this old ffmpeg package anyway.
<civodul>a_e: wait, actually it's just a matter of missing -ldl
<civodul>i bet LDFLAGS=-ldl would fix it, no?
<civodul>but yes, ok
<Sleep_Walker>sounds about right
<Sleep_Walker>FTR - for tig I was trying to follow http://jonas.nitro.dk/tig/ page
<Sleep_Walker>but your version is better so lets use that
<Sleep_Walker>about capital letter in synopsis - I didn't want to alter name of ncurses to Ncurses
<civodul>that's fine IMO
<civodul>i've seen it before
<civodul>no big deal anyway
<Sleep_Walker>please, ignore taskwarrior for now - I forgot to update its description and synopsis
<Sleep_Walker>and I'm aware of that
<taylanub>can I get the unpacked source of a package as an input? I'm thinking of fishing out headers from mesa without using a package at all.
<civodul>unpacked, no
<civodul>well, you'd have to write a package or something that unpacks it
<Sleep_Walker>monadic function!
<Sleep_Walker>(sorry, I must read it somewhere :D )
<Sleep_Walker>*must have
<civodul>:-)
<taylanub>so this worked fine http://sprunge.us/jTKL
<a_e>taylanub: Nice! I think you should use "copy-recursively" instead of "system* cp -r ...".
<civodul>taylanub: you could call it "mesa_headers"
<civodul>and yes, copy-recursively + modify-phases :-)
<a_e>I just wanted to enquire about modify-phases!
<a_e>I wondered why its author would not use it!
<rekado>commit 9e91418b105ad92b259be7588a6f927bb915da9e broke the build of libgnomeprint.
<a_e>Ah, freetype! Its layout for the include files changed.
<rekado>libgnomeprint fails with "#include <freetype/ftoutln.h>"
<taylanub>oh, I kind of missed that we can use modify-phases already
<civodul>libgnomeprint is deprected, so perhaps we could keep the old freetype just for it?
<rekado>can't we just symlink the include directory?
<civodul>no because it's in $builddir
<rekado>I don't understand. Symlinking was done before that commit.
<taylanub>civodul: underscore instead of dash?
<civodul>oh we must be talking about different things, sorry
<a_e>Just replace "freetype/ftoutln.h" by "freetype2/ftoutln.h".
<civodul>taylanub: yes, "mesa-headers", sorry
<rekado>a_e: you mean I should patch libgnomeprint's sources?
<a_e>Or maybe any "freetype/" by "freetype2/".
<taylanub>ok
<a_e>rekado: Yes. See python2-pil.
<civodul>another issue with this freetype commit is that it introduces a phase called 'set-paths', but there's already one with that name
<civodul>well it's probably fine in this case
<a_e>civodul: Ah okay. It could be easily renamed.
<a_e>Actually, I reported the bug upstream, they tried to fix it without success, and now they ask if I could provide a patch...
<civodul>heh, fun
<Sleep_Walker>I proposed with grub fix that we can save a lot of trouble by providing the symlink :b
<Sleep_Walker>ln -s freetype2 freetype
<a_e>civodul: LDFLAGS=-ldl seems to work for ffmpeg.
<a_e>But I do not see a simple way to add it just to the old and not to the current version.
<civodul>hmm, ok
*civodul -> zZz
<civodul>good night/day!
<a_e>Good night!
<rekado>I think libgnomeprint's output is also wrong: /gnu/store/4i73haiifvb4w1gn6qs2abr4im1rcf8a-libgnomeprint-2.8.2/include/libgnomeprint-2.2/libgnomeprint/
<rekado>why do we have libgnomeprint-2.2 and then again libgnomeprint?
<rekado>the python bindings look for libgnomeprint/some-header.h
<davexunit>does anyone know of a good way to deal with test suites that play sounds?
<davexunit>test suites that create x windows can use xfvb, is there something similar for sound?
<davexunit>I might just disable the test.