IRC channel logs


back to list of 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...
<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 is very pissed off by this whole GSoC thing
<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
*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.
<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.
*dsfdsf is working on bumping gnutls
<civodul>hey dsfdsf!
<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 <>
<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.
<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!
<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 :-(
<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>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)."
<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
<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>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>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>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 :-)
<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 :)