IRC channel logs
2014-01-21.log
back to list of logs
<civodul>so apparently the daemon update broke the substituter <viric>how do you say daemon in French? <civodul>of course that sounds a bit weird, but it sounds just as weird in English <viric>I think we have to distinguish daemon and demon. <viric>In catalan, I'd say daemon=esperit, demon=dimoni, in catalan <civodul>dunno if there's such a distinction in French <civodul>that's vocabulary i don't normally use ;-) <sriharsha>are the sources for guix considered as dependencies for derivations? <sriharsha>I ask this because, if I change the sources in guix/build/gnu-build-system.scm and then try to install a package a lot of derivations need to be built locally <sriharsha>if I revert my changes to guix/build/gnu-build-system.scm then those derivations are being substituted with those from hydra <civodul>sriharsha: yes, anything that is an input to the build process is considered a dependency <civodul>that includes things like gnu/build/*.scm <civodul>because these files are helpers used on the build side <sriharsha>civodul, any reason to do this? This requires me to rebuild most of the things everytime I make some changes there.. <civodul>sriharsha: that's a consequence of the whole purely functional approach <civodul>a build process is regarded as a pure function <civodul>so all its inputs are taken into account <civodul>but note that usually you don't need to change anything in gnu-build-system.scm <civodul>when we do need it, we do it in a separate branch ("core-updates"), to avoid triggering rebuilds on 'master' <civodul>the grail of reproducible builds, you know ;-) <sriharsha>I installed gnutls with guix and have set the $GUILE_LOAD_PATH to get the guile binding for gnutls, but now I get this <sriharsha>;;; Failed to autoload make-session in (gnutls): <sriharsha>;;; ERROR: In procedure dynamic-link: file: "/nix/store/r64154hy14lzdxgp8gy8kk99kh4mw7hf-gnutls-3.2.4/lib/guile/2.0/guile-gnutls-v-2", message: "file not found" <sriharsha>ERROR: In procedure module-lookup: Unbound variable: make-session <sriharsha>the file guile-gnutls-v-2.so is present in the directory; is guile searching for the wrong file 'guile-gnutls-v-2' instead of 'guile-gnutls-v-2.so'? <civodul>sriharsha: could you check whether guile-gnutls-v-2.so is linked against the same libguile? <civodul>"file not found" is misleading, but that's what ltdl gives us... <sriharsha>civodul, it seems to be linked to the correct libguile <civodul>sriharsha: and you're sure the 'guile' binary is /nix/store/fnwlciqm2qy0b3kc1f949s7n73d6rysc-guile-2.0.9/bin/guile? <sriharsha>totakura@nautophone:~/.guix-profile/lib$ which guile <sriharsha>ls -l /home/totakura/.guix-profile/bin/guile <sriharsha>lrwxrwxrwx 1 guix-builder1 guix-builder 65 Jan 1 1970 /home/totakura/.guix-profile/bin/guile -> /nix/store/fnwlciqm2qy0b3kc1f949s7n73d6rysc-guile-2.0.9/bin/guile <civodul>could you run: strace guile -c '(use-modules (gnutls))' ? <civodul>to see where it's looking for guile-gnutls-v-2.so <sriharsha>but I am using guix which is installed in /usr/local/ <mark_weaver>sriharsha: what is the output of: head -1 $(which guix) <mark_weaver>okay, that's the 'guile' that was available when guix was configured. <Steap>Has anyone found a workaround for "#<gnutls-error-enum The TLS connection was non-properly terminated.> fill_session_record_port_input" which denotes a server-side error when downloading tarballs ? <civodul>i think there's an open bug for that <civodul>it only manifests with certain servers <Steap>civodul: I get the error when building python-setuptools <Steap>Isn't it even possible to ignore the error ? <mark_weaver>well, the error happens within low-level IO routines, while trying to fill an input buffer. <mark_weaver>afaik, there's no way to ignore it at the scheme level. something probably needs to be changed in the C code. <mark_weaver>for now, you can use 'wget' to download from the bad server and then use 'guix download file:...' to put it in the store, no? <mark_weaver>The server really is misbehaving, and it's probably good that GnuTLS is strict about such things by default. The only reason we can safely ignore it is because we really don't need the protection of TLS anyway, since we later check the hash. <sriharsha>How the macro 'GUIX_ASSERT_LIBGCRYPT_USABLE' from configure.ac work? I have never seen anything like that before in autoconf <Steap>mark_weaver: I think this will happen for all download on pypi.python.org <mark_weaver>it uses GUILE_CHECK, which is defined in guile.m4 (normally installed in $PREFIX/share/aclocal/guile.m4) <Steap>Is there a way to show this error so that a bug report can be submitted to the people at PyPI ? <sriharsha>mark_weaver, true; I allmost forgot we can do custom m4; the ones from autoconf were sufficient, until now :) <mark_weaver>Steap: pypi.python.org is extremely broken. even 'wget' won't download from it, at least not on my system, because the certificate common name ("*.a.ssl.fastly.net") doesn't match the host name. that's just totally broken. <mark_weaver>I have to completely disable all certificate checks to download from that site at all. <mark_weaver>sriharsha: custom autoconf tests are needed fairly regularly, in practice. in fact, there's a whole project "autoconf-archive" aimed toward helping with that. <Steap>mark_weaver: that's gonna be an issue for most Python packages, though <Steap>either they have to fix the website, or we have to use a workaround <mark_weaver>Steap: what makes it even worse is that if you try to download with https, it *redirects* to you to the totally broken TLS site. <Steap>mark_weaver: do you think I can easily trigger the error using wget or something similar ? <mark_weaver>Steap: it would be good if they would fix their site. <Steap>I don't feel like writing a Scheme program to explain them the issue <mark_weaver>"ERROR: certificate common name “*.a.ssl.fastly.net” doesn’t match requested host name “pypi.python.org”." <mark_weaver>hmm. admittedly, this is my homebuilt system from 3 years ago, but that error message sounds pretty damning. <mark_weaver>I suppose everyone is just ignoring most TLS errors these days :-( <mark_weaver>to the point of "fixing" the software to ignore such errors. *sriharsha thanks civodul for GUIX_ASSERT_LIBCRYPT_USABLE (it saves a lot of trouble when you have multiple guile/libgcrypt/gnutls installs) <elly>mark_weaver: no, your client is (incorrectly) ignoring that the served cert for that domain has pypi.python.org in its SANs <mark_weaver>okay, the 'wget' from Guix works. I'm not sure whether to be troubled by this. <Steap>Andreas wrote the definition of setuptools, so I guess I'll ask him <sriharsha>mark_weaver, thanks for the autoconf-archive hint; I now know where to look at the next time I want to write a test <elly>it may also not be using SNI, hard to tell :P <civodul>before that patch, we would end up attempting to read more than Content-Length <civodul>yeah i just realized as we were discussing it <mark_weaver>the reason I ask is that maybe we can release Guile 2.0.10 in time, so the patch won't be needed. <mark_weaver>the only thing is, I'm aware of a bunch of problems that I'd like to fix before 2.0.10, and some features I'd like to get in, so it's taking much longer than I originally thought. <civodul>yeah, dunno, we can arrange either way :-) <civodul>i was always hoping to make the Guile release process more lightweight <mark_weaver>(I'm hoping to get R7RS and SRFI-38 into 2.0.10, plus thread-safe module autoloading, davexunit's coop-repl-server, mvars, and maybe a few other things, but maybe I'm overdoing it :) <civodul>but i failed to do that, for some reason <civodul>in 1.9 days we released a new version every month <mark_weaver>we've definitely waited far too long between .9 and .10, that's for sure. but now that I have some key bugs and features in my sights, I don't know when to stop :) <civodul>mark_weaver: i would stop just because it's too late <civodul>i know there was this regexp-exec locking issue that i wanted to sort out too <davexunit>and by "strikes again" do you mean "posts to the emacs mailing list"? *civodul feels like he's advertising his views <civodul>for the record, GCC has had plug-ins for 3-4 years <civodul>not that it's prefect, but the FSF hasn't had an "anti-plugin" policy for at least this long <davexunit>my feelings for esr are mixed. I enjoyed reading catb. <davexunit>and I think his suggestion to migrate the emacs repo to git (which is a job that was mostly done to begin with, iirc) was a good one. <civodul>apparently he's targeting Texinfo too <mark_weaver>but his goals are fundamentally different than mine, or RMS, or the FSF. <davexunit>he is one of the leaders of the Open Source movement. <civodul>yeah, that's clear from this gcc post <mark_weaver>davexunit: btw, I just pushed a patch to stable-2.0 that changes repl/server.scm a bit. it doesn't directly affect your coop-repl, but it's probably close enough to cause a merge conflict. <mark_weaver>ah, of course. shoot texinfo in the head. sounds like something esr would say, since he's also into guns :) <davexunit>mark_weaver: okay. I will rebase later and resolve conflicts. <bu^>"go with a more modern, Web-friendly master format. Oh, and time to abolish info entirely in favor of HTML." seriously... don't i like info pages <mark_weaver>civodul: btw, I agree that we should release 2.0.10 soon. I'll pare down my list of things for .10 substantially, and put off the rest until .11. <davexunit>mark_weaver: should my patch wait for .11? let me know if I have a deadline. <mark_weaver>davexunit: nah, it's so close, that should get into .10. <davexunit>alright, time to head home before this snow storm. <mark_weaver>I guess I'll probably have to push off thread-safe module autoloading as well. <mark_weaver>it's just too hard to get that right. too much potential for disastrous new bugs. <mark_weaver>I can guess what ESR would say about GNU Guile, heh. <bu^>python is already hasbeen <bu^>(i'm not enough to date with the latest languages) <mark_weaver>I don't think of Rust as a competitor of Guile, but rather of C++. <mark_weaver>If asked to choose between FOO and C++, I'd probably pick FOO sight unseen :) <bu^>seems so strange for me <bu^>but once guile has native compilation, it will become a competitor to every existing language, you're a threat ! <mark_weaver>nah, plenty of high-level language implementations have native compilation, but it's still hard to reach C's efficiency in a language like Scheme. <bu^>is suppose so, and with human like compilation times moreover ^^ <bu^>I don't see how you could get C speed with guile flexibility <bu^>but that's not that much an issue if you end being 3 times slower for "general" tasks but find a way to go almost as fast as C for heavy numerical treatment this would already be a big win *mark_weaver goes afk for a bit ... <bu^>not like a few hours for simple source files