IRC channel logs

*ggrant is trying hi hand at packaging sshfs, since fuse is now packaged.

*ggrant wonders if it should be it's own module, or part of ssh.scm

<Steap_>I'd be fine with ssh.scm

<ggrant>I'll bugger with it more tommorow, right now I have it complaning that it's an unknown package already ... hopefully it's a trival syntax error I can fix, when rested.

<Steap_>ggrant: "make" should complain :)

<jmd>So I have a package "foo" with outputs "out" "bar" and "wiz". How do I use (say) "foo:wiz" as the input to another package?

<jmd>Where has that civodul creature got to today?

<adasda>mark_weaver: have you used weinholt's industria?

<mark_weaver>not yet, but weinholt seems very smart and I'd use industria the next time I have a reason to.

<mark_weaver>looks like great stuff.

<adasda>someone suggested (ludo?) to use it for base64 decoding/encoding

*adasda is currently changing substitute-binary to support the signature field

<mark_weaver>excellent!

*mark_weaver goes afk for a bit...

<jmd>So. How do I include the output of one package as the input of another?

<adasda>jmd: No idea. grep -r ":out" gnu doesn't show anything relevant too.

<mark_weaver>jmd: looking at the code, I guess that you include a 3-element in inputs/native-inputs/propagated-inputs. something like: ("libtool-bin" ,libtool "bin")

<mark_weaver>I haven't tested this though

<jmd>I'll try it.

<jmd>("libtool:bin" ,libtool) ran without error. But did not generate the correct environment.

<mark_weaver>that first string is only a handle to refer to it within the same derivation.

<mark_weaver>you can choose whatever name you want, it doesn't have to match the package name.

<mark_weaver>(it's just the key for use in things like (assoc-ref inputs <key>)

<mark_weaver>jmd: ah yes, see line 229 of ssh.scm for an example usage of this.

<mark_weaver>in that case, they just used "libtool" as a key, because they only needed one subdrv from that package.

<mark_weaver>but if you need more than one, then you must give them distinct keys.

<jmd>mark_weaver: Yep. Seems to work. Thanks.

<mark_weaver>jmd: you're welcome!

<adasda>civodul: I've managed to change substitute-binary to parse the signature field.

<adasda>That's wasn't too hard, though.

<civodul>hello!

<civodul>adasda: sounds cool!

<civodul>note that you can push to a temporary wip-signature branch if you want

<adasda>When do you plan to release the current version

<adasda>?

<civodul>that's a good question!

<civodul>by the end of the month, i think

<adasda>OK, I think I should make it before the release.

<civodul>would be cool

<civodul>let's see how it works out

<civodul>from #nixos: Guix in the tabloid: http://www.phoronix.com/scan.php?page=news_item&px=MTYwMjA

<davexunit>haha tabloid.

<davexunit>I guess that is an accurate description of phoronix

<adasda>civodul: I'd like to reuse the base64 encoding/decoding procedures from Weinholt's Industria. What's the best way to bundle them with Guix? I've been told to put (weinholt text base64) into (guix base64), and rename accordingly. May I do so?

<mark_weaver>(that was my suggestion, but maybe it belongs somewhere else, dunno)

<adasda>Also, should I replace (library ...) with (define-module ...)?

<mark_weaver>it's self-contained, which is good.

<mark_weaver>adasda: no, leave it as 'library'.

<adasda>OK.

<adasda>civodul: Does such a trivial modification require me to mark the version as modified?

<mark_weaver>I suppose we could leave the module name the same, but then it would conflict with possibly newer versions that come from weinholt. I'm not sure what's best here. what do you think, civodul?

<adasda>hahaha

<civodul>adasda: ideally, if it doesn't need to be modified, you can do something like srfi/srfi-64.scm

<civodul>that is, you use 'include' to include the unmodified thing

<civodul>though here you would need to nullify the 'library' form

<mark_weaver>civodul: well, the file that srfi-64 includes doesn't define a module. it's just a raw file.

<civodul>right

<civodul>oh right, and 'library' is supposed to work here

<civodul>yeah so maybe it's easier to just change the module name and be done with it

<adasda>civodul: Would that require to adjust the license header?

<civodul>i think you can leave it intact (it's BSD-style, right?

<adasda>I'd like to use 1-3, which is GPLv3+.

<adasda>On a sidenote, is it correct to pass the output of 'openssl rsautl -sign -inkey <key> -in <hash-file>' (which is not ASCII armored) to base64-decode?

<civodul>even better then

<civodul>i think so

<civodul>why not?

<mark_weaver>civodul: btw, those bash patches are bug fixes, not enhancements. I don't know about you, but I definitely want them on my system.

<civodul>base64-decode returns a bytevector, right?

<mark_weaver>well, I'll use the ML. sorry :)

<civodul>:-)

<adasda>civodul: It seems. (I've used M-x base64-decode-region for now.)

<mark_weaver>civodul: yes, it returns a bytevector.

<adasda>civodul: Again, is it necessary to mark the renamed module as modified?

<adasda>civodul: Or is it considered too trivial?

<adasda>(The perfect bikeshedding topic.)

<civodul>adasda: just a one-line command saying that you changed the module name

<adasda>s/command/comment/?

<civodul>right, sorry :-)

<adasda>civodul: Is "The module name was changed from foo to bar by firstname lastname." OK?

<civodul>perfect!

<adasda>civodul, mark_weaver: Thanks for your suggestions!

<mark_weaver>you're welcome!

<civodul>yep

<adasda>civodul: where's bytevector->string defined?

<adasda>civodul: (Not the one from (ice-9 iconv).)

<mark_weaver>adasda: what do you want it for? (I suspect you're making a mistake)

<adasda>maybe

<adasda>I want (bytevector->string (base64-decode str) (native-transcoder)) or something like that.

<adasda>IOW, I'd like to get the encoded string back.

<mark_weaver>decoded thing is a signature, right?

<mark_weaver>so it's not a string. it's binary data.

<adasda>I'm just playing around the library.

<mark_weaver>what are you going to do with this binary data?

<adasda>with*

<adasda>I ran (base64-encode "foo") and want to get "foo" back.

<adasda>Since 'base64-decode' returns a bytevectors, I'm looking for a way to convert it into a string.

<adasda>But I got your point wrt to the signature.

<mark_weaver>I don't see how (base64-encode "foo") can work. base64-encode wants a bytevector, not a string.

<mark_weaver>if you assume utf-8 encoding, then you can use utf8->string and string->utf8

<mark_weaver>but that's just playing around, don't use it the real code.

<mark_weaver>those procedures are in (rnrs bytevectors)

<adasda>mark_weaver: Argh! You're right. I encoded the string using Emacs, not 'base64-encode'.

<mark_weaver>please don't say you ran something if you didn't. it makes more work for us to be working with incorrect information.

<adasda>Oh, but I was entirely sure that I used 'base64-encode'. I should get some sleep.

<adasda>Sorry for the mess.

<mark_weaver>heh, I can sympathize with that :)

<mark_weaver>np

<adasda>Later!

<mark_weaver>thanks for working on it.

<mark_weaver>later!

<civodul>night adasda!

<Steap_>civodul: is it ok to push this http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16569 on top of master (after performing the change you mentionned) ?

<Steap_>for some readon, I wrote the patch in my core-updates branch, but I think it could go to master

<civodul>Steap_: actually, given that hydra is very loaded, it might be better to push it on core-updates

<civodul>because changing Python is likely to trigger a big rebuild in master

<Steap_>ok

<Steap_>That's starting to be an issue, if we can't push important changes :)

<civodul>yeah

<civodul>or just push it to master anyway

<civodul>we were supposed to get a machine at chapters.gnu.org

<Steap_>don't we have some sort of CI on core-updates ?

<civodul>i sent my SSH key etc.

<civodul>we do, but on a small subset of packages

<Steap_>hm