IRC channel logs

<civodul>Hello Guix!

<sriharsha>Hello!

<civodul>hey!

<civodul>so apparently the daemon update broke the substituter

<viric>hello civodul

<viric>how do you say daemon in French?

<civodul>hey viric

<civodul>démon ? :-)

<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>oh hmm

<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>s/need/are

<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'

<sriharsha>oh

<sriharsha>ok, thanks!

<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>guix download https://gnunet.org/sites/default/files/gnurl-7.34.0.tar.bz2

<sriharsha>starting download of `guix-file.f95wNL' from `https://gnunet.org/sites/default/files/gnurl-7.34.0.tar.bz2'...

<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>failed to download "guix-file.f95wNL" from "https://gnunet.org/sites/default/files/gnurl-7.34.0.tar.bz2"

<sriharsha>guix download: error: https://gnunet.org/sites/default/files/gnurl-7.34.0.tar.bz2: download failed

<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

<sriharsha> http://pastebin.com/2JWf0mAA

<civodul>sriharsha: and you're sure the 'guile' binary is /nix/store/fnwlciqm2qy0b3kc1f949s7n73d6rysc-guile-2.0.9/bin/guile?

<sriharsha>yes,

<sriharsha>totakura@nautophone:~/.guix-profile/lib$ which guile

<sriharsha>/home/totakura/.guix-profile/bin/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: is 'guix' using that 'guile' ?

<sriharsha>how can I know?

<mark_weaver>sriharsha: what is the output of: head -1 $(which guix)

<sriharsha>#!/usr/local/bin/guile

<sriharsha>looks like its not

<sriharsha>I shall try recompiling guix

<mark_weaver>okay, that's the 'guile' that was available when guix was configured.

<sriharsha>yes,

<mark_weaver>you'll have to rerun configure

<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>Steap: for which URL?

<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

<mark_weaver>sriharsha: it's defined in guix/m4/guix.m4

<sriharsha>oooh, custom m4.. wow!

<mark_weaver>:)

<mark_weaver>well, that's how autoconf tests are written: in m4

<mark_weaver>autoconf manual has a lot to say about that.

<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

<mark_weaver> http://www.gnu.org/s/autoconf-archive/

<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.

<mark_weaver>s/https/http/

<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>"wget https://pypi.python.org/packages/source/p/pysqlite/pysqlite-2.6.3.tar.gz" fails for me.

<Steap>oh

<Steap>let me try

<Steap>it works

<Steap>what's the error for you ?

<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

<elly>maybe upgrade openssl

*elly ->

<mark_weaver>okay, the 'wget' from Guix works. I'm not sure whether to be troubled by this.

<mark_weaver>elly: ah, okay. thanks. hmm.

<mark_weaver>fair enough, I stand corrected.

<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

<mark_weaver>you're welcome!

<elly>it may also not be using SNI, hard to tell :P

<civodul>folks: TLS problem solves: http://bugs.gnu.org/14884 :-)

<civodul>*solved, even

<civodul>well, the message is not there yet

<civodul> http://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0&id=802a25b1ed5c738aa5f9d3d01f33eb89b22afd1b

<civodul>before that patch, we would end up attempting to read more than Content-Length

<mark_weaver>oh! I didn't realize that fixed this TLS problem.

<mark_weaver>nice!

<civodul>yeah i just realized as we were discussing it

<civodul>funny

<mark_weaver>any idea when core-updates will be merged?

<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>yeah, maybe :-)

<mark_weaver>heh :)

<civodul>in 1.9 days we released a new version every month

<civodul>fearless

<civodul>well, it was an unstable series

<mark_weaver>well, those were preleases though.

<civodul>but still

<civodul>yeah

<mark_weaver>prereleases, even :)

<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

<civodul>but heh

<civodul>urgh, esr strikes again

<davexunit>hmm?

<mark_weaver>eric raymond, you mean?

<davexunit>that's what I'm assuming.

<civodul>yes

<mark_weaver>what this time? :)

<davexunit>and by "strikes again" do you mean "posts to the emacs mailing list"?

<civodul> http://gcc.gnu.org/ml/gcc/2014-01/msg00176.html

*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.

<mark_weaver>yes, he was right about that.

<civodul>yes

<civodul>apparently he's targeting Texinfo too

<civodul>woow

<mark_weaver>but his goals are fundamentally different than mine, or RMS, or the FSF.

<davexunit>yes.

<davexunit>he is one of the leaders of the Open Source movement.

<civodul>yeah, that's clear from this gcc post

<mark_weaver>civodul: link to his texinfo post?

<civodul>mentioned at http://esr.ibiblio.org/?p=5211#more-5211

<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 :)

<mark_weaver>I should have anticipated that.

<davexunit>what's his issue with texinfo?

<civodul>it's not "modern"

<civodul>JSON and HTML5 FTW!

<davexunit>what's modern to him? markdown?

<civodul>dunno

<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.

<civodul>good! :-)

<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>mark_weaver: okay. :)

<mark_weaver>I'm going push off datum-labels and R7RS.

<mark_weaver>*going to

<davexunit>alright, time to head home before this snow storm.

<mark_weaver>good idea :)

<davexunit>later, civodul and mark_weaver

<mark_weaver>later!

<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>although that flaw does make me embarrassed.

<mark_weaver>(not that I'm responsible for it :)

<mark_weaver>I can guess what ESR would say about GNU Guile, heh.

<civodul>heh

<civodul>:-)

<mark_weaver>"Shoot it in the head. Long live Python!"

<bu^>python is already hasbeen

<bu^>go for rust !

<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^>FOO ?

<mark_weaver>placeholder for arbitrary language choice :)

<bu^>hum :|

<bu^>forgot this

<bu^>seems so strange for me

<bu^>^^

<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.

<mark_weaver>it's much harder to optimize Scheme than C.

<bu^>is suppose so, and with human like compilation times moreover ^^

<bu^>I suppose*

<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>human like compilation times?

*mark_weaver goes afk for a bit ...

<bu^>not like a few hours for simple source files

IRC channel logs

2014-01-21.log