IRC channel logs
2013-12-05.log
back to list of logs
<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 <jxself>civodul: There are these things called airplanes... ;) <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>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>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 <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>so, i'm being told PulseAudio needs love <a_e>civodul: On the other hand, I am giving ffmpeg the love it needs. There is a patch with the bug report. <civodul>thanks for giving me additional motivation ;-) <civodul>BTW, i have preliminary Bash completion <a_e>civodul: Actually, pulseaudio is an optional input for ffmpeg... <civodul>i think the problem with volume-test.c is a rounding issue <a_e>They should use mpfr then! <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>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 <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). <a_e>I am just reading up on IEEE 754 and C99: <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>a_e: i pushed that patch that disables PA tests on i686 <civodul>Steap: what's up with the eog & co. patch series? :-) <a_e>civodul: Did you disable the tests on pavucontrol instead of pulseaudio? <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? <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 <bavier>great, that solved that part of things, thanks