IRC channel logs


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.
<mark_weaver>(of course, you would remain author of your commit)
<dsfdsf>mark_weaver: I'll send the commit because I really need to sleep.
<mark_weaver>dsfdsf: okay, sounds good.
<mark_weaver>thanks for working on it :)
<civodul>yup, thanks!
<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.
<mark_weaver>that's good!
<civodul>very good :-)
<dsfdsf>building the files under lib.
<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" problem fixed in core updates?
<zacts>lo #guix
<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
<civodul>mark_weaver: yes
<dsfdsf>I'll send the diff to the list.
<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?
<civodul>so i think it can be reported
<dsfdsf>yes, it's independent.
<dsfdsf>okay, I'll report it.
*civodul goes to bed
<dsfdsf>sleep well
<civodul>tty tomorrow!
<mark_weaver>good night!
<dsfdsf>mark_weaver: check the list
<civodul>Hello Guix!
<phant0mas>hello civodul
<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>np! we should find out where it got lost.
<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
<civodul>but it's slow
<mark_weaver>I use greylisting, sender callout verification, and spamassassin with the bayesian stuff disabled. works well enough for me.
<civodul>"G expressions", or "gexps"
<civodul>that's what it'll be called
<civodul>how does that sound? :-)
<mark_weaver>what does the "G" stand for? what are gexps to be used for?
<mark_weaver>ah, right, makes sense
<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>maybe #~ and #$
<Steap>"hop style"
<Steap>you work too much
<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>maybe 'input' is not the best name for it though.
<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>i'm not quite convinced
<civodul>but i'll start a thread for discussion
<mark_weaver>perhaps not a macro, but rather a simple procedure (input "coreutils)
<mark_weaver>(input "coreutils")
<mark_weaver>dunno, I haven't thought much about it.
<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
<civodul>lemme just sum that up in a message