IRC channel logs

2013-12-05.log

back to list of logs

<civodul>Hello Guix!
*civodul notices https://lists.fosdem.org/pipermail/fosdem/2013-December/001891.html
<civodul>i should probably talk there
<jxself>civodul: And at http://www.fsf.org/news/libreplanet-2014-seeks-session-proposals-volunteers-for-annual-free-software-conference
<jxself>Maybe?
<civodul>jxself: would be nice, but it's far away from where i live
<atheia>Hi civodul, just to let you know:
<atheia>Looked at the bug requests yesterday and promptly realised they are sadly beyond my ability.
<atheia>So no help from me for now I'm afraid :-(
<mark_weaver>atheia: another good way to help is to package more software for guix
<mark_weaver>(if you're motivated to do so, of course)
<jxself>civodul: There are these things called airplanes... ;)
<jxself>But I understand.
<atheia>mark_weaver: yeah, probably what I should be focusing on.
<davexunit>as a libreplanet attendee, I would love to see the Guix project have a presence there. :)
<jxself>davexunit: If civodul won't go, maybe you could do something in his place?
<davexunit>jxself: I don't think I have enough knowledge of guix as a whole to be a good representative.
<jxself>There is certainly enough documentation on the website to fix that.
<davexunit>but I would be open to the idea.
<davexunit>mark_weaver is also in the area.
<davexunit>I think he would be better equipped for the task.
<mark_weaver>I also feel that my knowledge of Guix is not sufficient to lead a session on it. I might do something on Guile though.
<mark_weaver>but I wonder if we might convince civodul to come :)
<davexunit>that certainly would be the best option. :)
<davexunit>also a guile session would be great. it does seem that guile isn't as well known as it ought to be.
<civodul>jxself: sure, but it's costly, takes time, etc.; but someone else could represent Guix too :-)
<civodul>a Guile session a LP would be cool as well
<civodul>actually, i think it'd be nice to have a more focused "GuileCon" or even "GuixCon" someday
<civodul>it could be quite informal
<davexunit>that would be great as well.
*civodul heads back home
<mark_weaver>civodul: maybe the FSF would sponsor your travel expenses to LP.
<mark_weaver>it would be good to have a competent presentation on Guix. I suspect that attendees are more likely to be interested in Guix than Guile. Sadly, most hackers minds seem to be closed to Lisp-like languages (or at least its syntax).
<civodul>yes and no: see Clojure
<civodul>anyway, that needs more thought
<civodul>ttyl!
<civodul>howdy!
<a_e>Hello!
<jmd>Yo!
<bavier>hey!
<civodul>nice :-)
<civodul>so, i'm being told PulseAudio needs love
<civodul>let's see
<a_e>civodul: On the other hand, I am giving ffmpeg the love it needs. There is a patch with the bug report.
<civodul>nice!
<civodul>thanks for giving me additional motivation ;-)
<civodul>BTW, i have preliminary Bash completion
<civodul>would someone like to pick it up?
<a_e>civodul: Actually, pulseaudio is an optional input for ffmpeg...
<civodul>heheh
<civodul>i think the problem with volume-test.c is a rounding issue
<a_e>They should use mpfr then!
<civodul>of course! :-)
<civodul>the test converts dB (double) to another unit (uint32) back and forth
<a_e>It is interesting that this gives different values on 32 and 64 bit architectures; it should not.
<a_e>How about just making a bug report and disabling the test for now?
<civodul>yes, i just want to prepare a reasonable bug report
<civodul>and yes, we'll disable tests on i686 for now, i guess
<mark_weaver>I can think of a reason why it would be different
<mark_weaver>on amd64, sse2 can be assumed, and is generally used, which means 64-bit doubles.
<a_e>Chances are the problem lies in the C library.
<mark_weaver>on i686, the older 80-bit extended doubles are used instead
<mark_weaver>so you end up with double rounding in many cases.
<a_e>A casual glance shows only standard maths functions and uint32 and uint64.
<mark_weaver>because first an operation is done at 80-bit precision, and then rounded a second time at 64-bits.
<mark_weaver>(well, it's not quite 80-bit and 64-bit precision; some of those bits are for the exponent and sign, but still...)
<a_e>Interesting, I thought we universally had 53 bit mantissas and 64 bit doubles.
<a_e>Should the 80 bit floating point numbers not be activated in "long double" only?
<mark_weaver>internally, the operations are always done on 80-bit floats (iirc, the mantissas are 64-bits).
<mark_weaver>it was sse that added native 64-bit double ops.
<a_e>I am just reading up on IEEE 754 and C99:
<a_e> https://en.wikipedia.org/wiki/C99#IEEE.C2.A0754_floating_point_support
<mark_weaver>if you use a long double, then it will be *stored* as 80-bits.
<a_e>On x86-64, intermediate computations are by default done with double precision; on x86, with long double precision.
<mark_weaver>if you use double, the operation will be done at 80-bits anyway, and then rounded (a second time) down to 64-bits.
<jmd>Can I suggest that .po files be generated by make, instead of by ./bootstrap ?
<mark_weaver>I think that would add an extra build dependency for tarball releases.
<jmd>It needn't do. They can still be in the tarball.
<jmd>It just means that the "dist" target is a little more complex.
<mark_weaver>this is a question for civodul. I'm not very knowledgable about the gnu build system.
<civodul>wat?
<civodul>.po files are not generated
<civodul> https://bugs.freedesktop.org/show_bug.cgi?id=72374
<civodul>↑ PulseAudio bug report
<civodul>a_e: i pushed that patch that disables PA tests on i686
<a_e>Excellent!
<civodul>Steap: what's up with the eog & co. patch series? :-)
<a_e>civodul: Did you disable the tests on pavucontrol instead of pulseaudio?
<civodul>ouch, indeed!
<civodul>fixing it now
<civodul>a_e: should be better now
<a_e>Good!
<bavier>I packaged fontforge as a dependency for lilypond; when run it says "libz.so: cannot open shared object file: No such file or directory". Any ideas what might be up?
<a_e>bavier: You added zlib as an input?
<bavier>yes
<a_e>And did not include all of the license file? (There is a conflict between the zlib license and the zlib package.)
<bavier>I'm using a symbol prefix on the license module, so yeah, it's getting the package
<a_e>Then I do not know. By the way, it might make sense to add the package to fontutils.scm.
<bavier>I think fontforge dlopen's it's libraries, do I need to set LD_LIBRARY_PATH to include zlib's libdir?
<a_e>Rather, you should explicitly link the binaries (or the libraries) that dlopen with zlib by adding "-lz".
<bavier>and yes, I was thinking about adding it to fontutils.scm
<a_e>Or do something like in icu4c.scm to add zlib to the runpath.
<civodul>bavier: that probably means that libz is missing from the RUNPATH
<civodul>you could try: objdump -x fontforge | grep PATH
<civodul>and see if libz's directory appears there
<civodul>if it doesn't, then it probably means that fontforge's build system omitted "-lz"
<civodul>so you could try building passing LDFLAGS=-lz as a configure flag
<civodul>like a_e wrote, actually :-)
<bavier>no libz in RUNPATH or RPATH
<civodul>yeah, so try adding -lz
<bavier>great, that solved that part of things, thanks
<civodul>cool