IRC channel logs


back to list of logs

***Infiltra1or is now known as Infiltrator
<manolis1>mark_weaver: phant0mas here just from another computer
<manolis1>mach recipe works when I build it with system i686
<manolis1>so for not I will continue with glibc
<mark_weaver>sounds great!
<manolis1>tiill I find ludo and ask him
<manolis1>I still don't like that I have to use 32 bit enviroment to build it
<manolis1>I should make it build from a 64 bit as well
<manolis1>where is ludo? vacations?
<mark_weaver>I don't know where.
<davexunit>manolis1: yeah he's on vacation for a few days.
<mark_weaver>but you should realize that what we're doing here is preparing for cross-compilation.
<manolis1>that's why I have to make it to build regardless of the system
<manolis1>even though if we have a hurd guix machine it will be on 32 bits so it will work no problem
<mark_weaver>I haven't researched this issue properly, but my impression is that in this case we were able to basically avoid cross-compilation by doing native compilation from a 32-bit user environment.
<manolis1>that is great
<mark_weaver>so if not for --system=i686-linux, there would have to be something else that might have been even less convenient.
<mark_weaver>but we shouldn't be worrying too much about the convenience of these cross-compilation steps.
<mark_weaver>because this is something that we'll have to do just once. users won't have to do these steps after we've built bootstrap tarballs for hurd.
<manolis1>moving onto glibc then
<mark_weaver>this part will be a bit tricky.
<manolis1>I will first try to build it the normal way
<manolis1>find any special treatment it needs
<manolis1>and then when I am sure what I am doing, I will start doing the same on guix
<mark_weaver>you'll have to modify the existing glibc recipe in base.scm, but only when the target system is hurd.
<manolis1>so what should I do?
<mark_weaver>okay, that sounds good. I would rather that civodul help you with this part anyway.
<mark_weaver>for now, just build in the normal way.
<mark_weaver>going afk for a bit. happy hacking!
<fdsfssd>mark_weaver: You might be interested to know that I'm making some progress on supporting signed NAR info files. I intend to post a rough version tonight and would be glad to hear some feedback.
<dfsdfsd>mark_weaver: around?
<dfsdfsd>are you familiar with libgcrypt's gcry_pk_genkey function?
<dfsdfsd>What does 4 mean in 'nbits 4:2048'?
<dfsdfsd>"The argument is a string with a number in C-notation. The value should be a multiple of 8."
<dfsdfsd>Are you familiar with the mentioned notation?
<mark_weaver>hmm, I don't know, sorry.
<mark_weaver>I suppose I would do some web searches, and failing that, look in the source code.
<dfsdfsd>No worries, I'll find out.
<dfsdfsd>(I need it to test the 'parse-signature' function that I wrote.)
<mark_weaver>dfsdfsd: that 4 is the length of the string that follows the colon. It's called "length-prefixed 'verbatim' encoding". See
<mark_weaver>search for "3:abc" in that document.
<dfsdfsd>mark_weaver: I've just found out on #gnupg.
<mark_weaver>and "Verbatim representation"
<dfsdfsd>Thanks anyway!
<dfsdfsd>mark_weaver: I'm trying to use 'test-error' from SRFI-64 but keep getting syntax errors even though 'test-assert' works. Any idea?
<dfsdfsd>Basically, I do (in REPL): (test-begin "foo"), then (test-error (error "foo")). After that I get a syntax error.
<dfsdfsd>I've also tried the relevant example from this page: It failed too.
*mark_weaver looks
<mark_weaver>works for me.
<mark_weaver>can you show me the exact error you get?
<dfsdfsd>In a second.
<dfsdfsd>unknown file:3:0: source expression failed to match any pattern in form (%test-error #t (error "foo"))
<dfsdfsd>That's for (test-error (error "foo"))
<mark_weaver>are you using srfi-64 as included in guile git?
<mark_weaver>or did you take it from the site?
<dfsdfsd>I didn't take it from It probably comes from guix (see srfi in the tree); but how can I check?
<mark_weaver>srfi-64 is not in guix
<mark_weaver>guix has guile-2.0.9, which does not include srfi-64
<mark_weaver>it will be in guile 2.0.10.
<dfsdfsd>I have srfi/srfi-64.scm in the tree.
<dfsdfsd>There's also srfi-64.upstream.scm.
<mark_weaver>sounds like you got it from somewhere else. that's not the version I made.
<dfsdfsd>When I said guix, I meant the source tree of the project.
<mark_weaver>oh, indeed!
<mark_weaver>I'll update that to my latest version.
<dfsdfsd>Could you do so right now?
<mark_weaver>I recently ported SRFI-64 to guile and made many fixes to it for guile-2.
<mark_weaver>okay, I'll do it in a few minutes.
<dfsdfsd>Thank you!
<mark_weaver>dfsdfsd: almost done, just waiting for 'make check' to complete on my Yeeloong.
<mark_weaver>tests/builders.scm takes a long time on this machine...
<dfsdfsd>Everything takes a long time on YeeLoong.
<mark_weaver>hmm, is this thing doing a full bootstrap from source in test-tmp?
<mark_weaver>I guess I shouldn't have removed that directory a while ago :-(
<dfsdfsd>Which things are you referring to?
<mark_weaver>well, I see a lot of stuff in guix/test-tmp/store/
<mark_weaver>it looks like it's doing a full bootstrap in there.
<dfsdfsd>Frankly, I have no idea. But there are a lot of files in that directory, indeed.
<mark_weaver>well, I went ahead and bravely pushed the SRFI-64 update to master. hopefully I didn't break anything :)
<dfsdfsd>Hehe, let's find out!
<mark_weaver>if you could run a 'make check' to verify that things still work, I'd be grateful.
<dfsdfsd>Will do shortly.
<dfsdfsd>mark_weaver: All the tests passed.
<dfsdfsd>Indeed, 'test-error' now works as it should.
<mark_weaver>that's good!
<dfsdfsd>mark_weaver: How do I catch a specific error?
<dfsdfsd>(test-error "two" "expected" (error "real")) doesn't seem to do the right thing.
<mark_weaver>checking for a specific error is not currently implemented in srfi-64 for guile.
<mark_weaver>but you could do it by using guile-specific constructs.
<dfsdfsd>Are you referring to 'catch'?
<mark_weaver>I have to go offline now though. good luck!