IRC channel logs

*gzg wonders how/if he could build an expression and then install it to his profile, without rebuilding Guix.

<mark_weaver>gzg: in practice, you should just be able to create the new *.scm file in gnu/packages and run ./pre-inst-env guix package -i ...

<mark_weaver>compiling *.scm is optional

<mark_weaver>it improves performance a bit, but for package files it doesn't make much difference.

<mark_weaver>it's not as though the package recipes are doing a lot of computation

<gzg>mark_weaver: You know what ... I haven't even tried that. :^I

<mark_weaver>btw, you don't actually have to be in the guix build directory when you do that.

<mark_weaver>I created a 'guix' script in my private ~/bin directory (which comes first in my PATH) that does this: $HOME/guix/pre-inst-env guix "$@"

<mark_weaver>that effectively make 'guix' from any directory always use whatever's in my local guix build dir.

<mark_weaver>I highly recommend it :)

*Infiltrator dons flame-suit and asks: "why isn't there a Debian package for guix?"

<mark_weaver>well, it wasn't ready in time.

<mark_weaver>debian stable only has stuff from long ago.

<mark_weaver>I guess we should try to get into sid though

<Infiltrator>Would you put in just guix itself or some sort of self-contained demo?

<mark_weaver>I think I'd just include guix itself.

<mark_weaver>the demos are available as images online, or can be built from guix.

<mark_weaver>and "guix pull" takes care of getting the latest and greatest once you have a basic guix install.

<Infiltrator>Makes sense.

<Infiltrator>Is the demo a guix package, by any chance?

<gzg>Would/do they even allow alternative package-managers in the repos?

<Infiltrator>There is a package for yum.

<Infiltrator>So I would say: yes.

<gzg>Also, fyi to anyone around to hear and pass around to answer if someone is questioning (or checking the backlog), starting tomorrow -- I'll likely be MIA for a solid week. Have to go back t my parents and get some stuff I've been worried about, done. After that though, I should actually be proactive and productive with patches... ! :^)

<gzg>to my parents'*

<gzg>Infiltrator: That'd be really nice to have such a low-barrier entry field, which in-turn carries all the land Debian entails, where one could more-or-less "naturally" segway into using the Upstream GNU disro.

<mark_weaver>On my home-grown YeeLoong system, 'git' isn't able to run Guix's ./bootstrap script. I get an SSL error, apparently because the CA that signed the certificate is not in my trusted CA certificate store.

<mark_weaver>now I have a 'git' that was built by Guix itself, and I tried using that one. it still doesn't work.

<mark_weaver>can someone let me know how this is supposed to work on Guix (or Nix)?

<mark_weaver>I see this: fatal: unable to access 'http://github.com/NixOS/nix.git/': server certificate verification failed. CAfile: none CRLfile: none

<mark_weaver>I guess I'm not actually sure that it's because of a missing CA cert in my trusted store. I don't know why it's happening.

<mark_weaver>civodul: how does guix/nix deal with the trusted CA certificate store?

<mark_weaver>to my surprise, 'git' from Guix also fails to clone from github, and thus Guix' ./bootstrap script still fails even when my PATH contains only things built within Guix itself.

<mark_weaver>(and my other environment variables are set appropriately, based on what 'guix package' told me)

<mark_weaver>any ideas?

<mark_weaver>I see this: fatal: unable to access 'http://github.com/NixOS/nix.git/': server certificate verification failed. CAfile: none CRLfile: none

<mark_weaver>(as you may recall, I had this same problem when trying to run ./bootstrap using the home-grown system I built on my YeeLoong.

<civodul>mark_weaver: that vaguely rings a bell, but i don't know the answer

<civodul>i could look it up in NixOS/Nixpkgs, or viric probably knows

<civodul>gotta go now, ttyl!

<a_e>mark_weaver: I had similar problems with mutt from guix when using it with secure smtp.

<a_e>I think it all boils down to the use of openssl.

<a_e>We do not distribute certificates.

<a_e>You need to download .pem files from the certification authorities and put them into $HOME/.certs .

<a_e>And then run "c_rehash $HOME/.certs" .

<a_e>This creates symbolic links inside the .certs directory, with name a hash, to the .pem files.

<mark_weaver>a_e: interesting. I did an 'strace -f' on the failed git clone, and 'cert' is nowhere to be found in the trace.

<mark_weaver>which makes me suspect that it didn't even look in $HOME/.certs

<mark_weaver>is there an environment variable I have to set also?

<mark_weaver>well, thanks for that info though. now at least I know how it's supposed to work :)

<mark_weaver>will gnutls look in the same place ($HOME/.certs) ?

<a_e>mark_weaver: I have no answers to your questions, I just discovered these openssl details when trying to make smtp work over ssl.

<mark_weaver>okay, thanks anyway for telling me what you found. it's a start.

<a_e>mark_weaver: Did you see my question on guix-devel concerning simd instructions for qt? The same question poses itself for ffmpeg.

<mark_weaver>yes, I did. what I know is this: both sse and sse2 are both definitely included in all x86_64 processors. I'm not sure about the other two, but I think they are unimportant anyway if you have sse and sse2.

<mark_weaver>as for loongson, I need to look into it.

<a_e>Okay, that is what I thought for sse. Thanks!

<mark_weaver>but for ffmpeg, last I checked there were unofficial patches for loongson that made things a lot faster, so I'll probably need to tweak that package later anyway.

<mark_weaver>np!

IRC channel logs

2013-10-31.log