IRC channel logs

<zacts>phant0m4s: so what specifically are you working on?

<zacts>I know something guix + hurd, but don't know specifically what your project is. :-)

<phant0mas>zacts: to port guix to hurd

<civodul>Hello Guix!

<phant0m4s>hello civodul

<phant0m4s>what happened with gsoc? :)

<civodul>hey phant0m4s!

<civodul>lemme see, i need to catch with email first :-)

<phant0m4s>civodul: ok , but I think we lost the slot...

<civodul>really?!

<viric>maybe that's why LWN on #gnunet wrote there asking for gsoc guix attention

<civodul>wtf, seriously

<viric>I simply reechoed the message here

<viric>I didn't know what it was about

<civodul>grrr

*civodul is very pissed off by this whole GSoC thing

<phant0m4s>:'(

<viric>they also can't give money to cuban students, or from other USA-banned places

<phant0m4s>viric: I am from Greece so that's not the problem

<viric>ok

*civodul builds GCC 4.9.0

<dsfdsf>civodul: guix prefetch is nearly ready; thinking of a reliable way to test it; any ideas?

<dsfdsf>it could look like this: we check that the derivation inputs are not present in the store before running prefetch, run prefetch, check again.

<dsfdsf>but there is a problem; if we use 'hello' there aren't many inputs, and most of them are essential (users wouldn't be happy if we remove something like glibc from the store). do you see a workaround?

<dsfdsf>I assume we could create a bogus derivation, for testing purposes. wdyt?

<dsfdsf>but if it works for a simple DAG, it doesn't mean it works for a complicated one. not sure how to address this.

<mark_weaver>you could build a new guix with a different --prefix and store directory, so you start from scratch, and see what happens when you prefetch to build hello.

<dsfdsf>mark_weaver: hey!

<dsfdsf>mark_weaver: I've been thinking of a way to integrate the above into our testsuite.

<dsfdsf>but, perhaps, it's too much.

<mark_weaver>hmm, yes, testing would be nice. not sure how best to do that though.

<mark_weaver>for that matter, you shouldn't assume that you have net access.

<dsfdsf>oh.

<mark_weaver>I wouldn't let this block you.

<dsfdsf>Yeah, I intend to test on a different machine with a fresh Guix installation, then send the code to the list.

<dsfdsf>thanks for your comments, mark.

<mark_weaver>np!

*dsfdsf is working on bumping gnutls

<civodul>hey dsfdsf!

<civodul>hmm

<dsfdsf>civodul: hey!

<civodul>if there's a procedure like 'derivations-to-prefetch', it can be tested without actually building/downloading anything

<civodul>as a unit test

<civodul>so that's one way to do it

<dsfdsf>civodul: what's the fingerprint of nmav's key?

<dsfdsf>I'm pretty sure it's in your keyring.

<civodul>i have:

<civodul>pub 3104R/96865171 2008-05-04 Nikos Mavrogiannopoulos <nmav@gnutls.org>

<civodul> Primary key fingerprint: 1F42 4189 05D8 206A A754 CCDC 29EE 58B9 9686 5171

<civodul>but i never signed it, i think

<mark_weaver>that's what I have too.

<civodul>we met once, though

<dsfdsf>civodul: okay, I see the same on the keyserver and in the announce message.

<dsfdsf>thanks

<phant0mas>civodul: sent the glibc/hurd-headers patch

<civodul>cool, thanks

<dsfdsf>phant0mas: thanks for working on it despite the GSoC thing.

<phant0mas>dsfdsf: I really like guix and I really want to help :-). The only difference will be that I won't be able to work full time on it :-/

<dsfdsf>understood. but note that noone is working on it fulltime anyway, though some are pretty close if you count the commits.

<civodul>i'm still waiting for a definite answer on the GSoC thing, but there's little hope :-/

<dsfdsf>let's hope for the best!

<civodul>yeah

<phant0mas>dsfdsf: I know :-) mark doesn't sleep to work on it :P

<dsfdsf>he he

<phant0mas>let's hope for the best

<phant0mas>and I am always looking at the bright side, I will still be able to brag about porting guix to hurd to girls :P

<phant0mas>at least to the ones that know what that is :-(

<phant0mas>hahaha

<civodul>it's already allowed us to notice that GNU/Hurd doesn't build :-)

<phant0mas>yeah , still wondering how they could not notice that :P

<dsfdsf>gnutls-3.3.1 fails with: "core.c: In function 'scm_init_gnutls': core.c:3369:3: error: 'gnutls_secure_malloc' undeclared [...] gnutls_secure_malloc = scm_malloc;" That's in 'gnutls-3.3.1/guile/src', ideas?

<civodul>pffff

<civodul>he'll never test with Guile support...

<civodul>no idea though

<civodul>i suppose gnutls_secure_malloc was deprecated or similar?

<civodul>does NEWS say anything?

<dsfdsf>trying to find something relevant

<dsfdsf>NEWS doesn't mention any API changes.

<dsfdsf>oh, we're upgrading from 3.2.12

<dsfdsf>looking deeper.

<dsfdsf>NEWS doesn't mention this function, should I report on the gnutls list?

<dsfdsf>civodul: there's a relevant entry in ChangeLog: "gnutls_secure_malloc() is no longer part of the API (though it remains in the ABI)."

<dsfdsf>civodul: https://gitorious.org/gnutls/gnutls/commit/f42e825d96b06f7069e4e9e8011a3ea8b93b4382 https://gitorious.org/gnutls/gnutls/commit/4932e4acb6e0d7aae9bf9c0bce6d69fe041ac62c

<civodul>ok

<civodul>i think your best bet is to remove the faulty line from core.c

<dsfdsf>will try

<civodul>and to complain loudly on the ML

<dsfdsf>okay

<civodul>and to demand releases to be tested with Guile support :-)

<dsfdsf>civodul: should I use a patch to remove the said line or substitute*?

<dsfdsf>(I'm asking since the same patch could be sent upstream.)

<civodul>dsfdsf: a patch, i think

<dsfdsf>civodul: May I attribute the patch to you since you suggested it?

<dsfdsf>It's a one line change, but giving credit is important.

<civodul>haha, either way is fine

<mark_weaver>if the code bothered to set gnutls_secure_malloc to scm_malloc, maybe it was needed.

<mark_weaver>maybe something else is needed in its place.

<mark_weaver>or maybe not, dunno :)

<civodul>it was just a way to let GnuTLS use Guile's allocator

<civodul>so that Guile's GC knew how much memory pressure there is

<civodul>(which in hindsight was not too great, for the _secure variant...)

<mark_weaver>okay

<mark_weaver>if gnutls is getting upgraded anyway, I wonder if we should also enable the system-wide trust store while we're at it. wdyt?

<dsfdsf>I'll post to the gnutls list and wait for feedback.

<civodul>mark_weaver: definitely!

<civodul>regardless of whether it's updated, even

<mark_weaver>civodul: I posted the patch back in February, subject "[PATCH] gnu: gnutls: Configure location of system-wide trust store", and Andreas wasn't in favor of it, but I didn't get the impression that he was blocking it exactly.

*mark_weaver reads the thread again.

<civodul>i don't think he was really blocking

<civodul>more like discussing etc.

<mark_weaver>okay, that was also my impression.

<civodul>progress needs to be made on that topic anyway :-)

<mark_weaver>indeed.

<mark_weaver>civodul: do you think I should just push the patch, or post again about it?

<dsfdsf>civodul: The gnutls change seems to force a full rebuild, so it should go into core-updates, right?

<dsfdsf>wait

<dsfdsf>nevermind the above

<mark_weaver>no, not a full rebuild, although it is a moderate amount of stuff that needs to be rebuilt, hence my desire to push these two patches for it around the same time.

<civodul>mark_weaver: perhaps push and reply to that thread saying that you did it

<mark_weaver>civodul: okay

<dsfdsf>mark_weaver: I'm quite sleepy and thought of Guile's auto-compile messages as it was rebuilding everything.

<civodul>ah no, these are just there to annoy the user :-)

<dsfdsf>hehe

<mark_weaver>dsfdsf: did removing the line, as civodul suggested, fix the build? if so, I think we should just go with that upgrade.

<dsfdsf>mark_weaver: currently it's compiling .scm files. Things take time on YeeLoong.

<mark_weaver>hehe, I know that all too well :)

<dsfdsf>actually, I'm pretty happy with it.

<dsfdsf>I thought it would be much more painful.

<mark_weaver>yeah, I just leave it building in the background all the time :)

IRC channel logs

2014-04-22.log