IRC channel logs
2014-04-23.log
back to list of logs
<mark_weaver>dsfdsf: actually, can you also apply my "system-wide trust store" commit to your tree, and then push the two commits together after testing them together? <mark_weaver>that should save both hydra and all of us some rebuilding. <dsfdsf>for instance, I discovered that if you run a command with verbose output in a buffer, the cursor freezes from time to time in the other buffers. but switching to a different terminal helps. <mark_weaver>dsfdsf: either that, or you can send me your commit and I'll do the testing and pushing. <dsfdsf>mark_weaver: I'll send the commit because I really need to sleep. <dsfdsf>You were talking about building userland applications with Guix. I've started to do the same, so I'm also eating my own dog food now. <dsfdsf>I believe the change solved the issue. <dsfdsf>Waiting for the build to finish. <mark_weaver>dsfdsf: you might as well send me the commit now, because I'm going to want to test it with my system-wide-trust-store change before pushing it anyway. <mark_weaver>(since I want to push the two commits simultaneously) <mark_weaver>civodul: is the "missing gcc.info" problem fixed in core updates? <dsfdsf>mark_weaver: I think I'll wait. It has just finished with the tests. <dsfdsf>Oh, there is yet another testsuite. I hope the tests will succeed because I'm building without your fix for the tests in 'guile/tests'. <mark_weaver>do you mean the "CPPFLAGS=-DENABLE_RSA_EXPORT" thing? yeah, that should no longer be needed. <dsfdsf>damn, 1 test failed in tests/cert-tests <dsfdsf>Should I report the core.c thing now or wait until we fix it completely? <civodul>the core.c thing seems to be independent no? <phant0mas>is it possible to use the procedure file-touch in guix? I found it in the mit-scheme manual but when I try to use it says it's an ubound var <civodul>phant0mas: Guile doesn't have that procedure <civodul>instead you can do something like (close-port (open-output-file "foo")) <davexunit>Would that be useful to have in Guile? phant0mas could perhaps submit a patch :) <civodul>i'm not sure it's commonly useful, dunno <phant0mas>file-touch ,though not commonly useful , would be a more straight-forward way of creating a file, I think <phant0mas>maybe I should really submit a patch to Guile about it :-D <davexunit>you'd want to make sure that touch works as the user would expect. if the file exists, the contents remain unchanged but the modified timestamp changes. <civodul>mark_weaver: thanks for confirming that you received the message <civodul>sometimes you start wondering "what did i do wrong with my mailer" <mark_weaver>I run my own mail server, and am very careful about the spam filtering methods I use. in particular, I avoid all "learning" filters. <civodul>it could be that it was received but not acted upon, and then forgotten... <mark_weaver>unfortunately, spam is designed to corrupt the learning filters, to make them less effective. <civodul>i've been using Bogofilter locally, and it seems to work quite well <mark_weaver>I use greylisting, sender callout verification, and spamassassin with the bayesian stuff disabled. works well enough for me. <mark_weaver>what does the "G" stand for? what are gexps to be used for? <civodul>gexps are just sexps with a special unquote that makes it easy to refer to package/derivation outputs <civodul>as in (gexp (system* (string-append (ungexp coreutils) "/bin/ls"))) <civodul>and the 'g' has the advantage of being different from 's', essentially :-) <civodul>it'd be ideal to write it ~(system* (string-append $coreutils)), hop style <civodul>dedicated to Fulax who knows that all too well ;-) <mark_weaver>fwiw, that example you gave (gexp (system* (string-append (ungexp coreutils) "/bin/ls"))) doesn't look very appealing to me. <mark_weaver>I'd rather see a macro that expands to an input, e.g. (input coreutils) <mark_weaver>but basically it would convert its operand into a string and look it up in the inputs. there could be one for the outputs as well. <civodul>but i'll start a thread for discussion <mark_weaver>perhaps not a macro, but rather a simple procedure (input "coreutils) <mark_weaver>it would be nice if the inputs were treated more like variable bindings somehow. <mark_weaver>i.e. that when declaring an input, you also gave a variable name that would be bound to its path within the code snippets. <mark_weaver>and if it looked like some kind of binding construct in the package definition, so much the better. <civodul>that's sort of the idea i had, actually