IRC channel logs


back to list of 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 '': 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 '': 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.