IRC channel logs


back to list of logs

<n1cky>anyone around? I'm interested in running a linux + guix system. Is it stable?
<n1cky>eh, seems GUIX + dmd is not quite production ready.
<n1cky>I wish you guys great luck.
<n1cky>thank you for doing this work. :-)
***kmic is now known as kmicu
<civodul>Hello Guix!
<taylanub>hello :-)
<taylanub>I'm also having the "No variable named ghc in #<interface (gnu packages haskell) 2fec900>" bug, when running the installed guix. works fine with ./pre-inst-env
<civodul>taylanub: aah, good! :-)
<civodul>did you run "make install"?
<taylanub>yeah, and before that I cleaned up everything guix-related I could find in /usr/local (where I install it) except for /usr/local/var/guix
<taylanub>(I sometimes run 'make install' on top of a previous installation, without 'make uninstall' in between, so there can be left-overs)
<civodul>can you run "stat /usr/local/share/guile/site/2.0/gnu/packages/haskell.{scm,go}"?
<civodul>also, could you "strace -f -o log guix package -i emacs" (say) to see which haskell.{scm,go} is used?
<taylanub>stat output:
<civodul>ok, looks good
<civodul>also "stat ~/.cache/guile/ccache/2.0-LE-8-2.0/usr/local/share/guile/site/2.0/gnu/packages/haskell.*"
<taylanub>strace output: (5 MB) not sure which line to look at
<civodul>lines matching "open.*haskell\\.go.*= [0-9]"
<taylanub>Guile cache has nothing for usr/...
<taylanub>22188 open("/usr/local/share/guile/site/2.0/gnu/packages/haskell.go", O_RDONLY|O_CLOEXEC) = 12
<taylanub>(indeed, all others are stat() calls)
<civodul>hmm looks like the right one
<civodul>and if you try to run Guile and access that variable?
<taylanub>I think I need to augment my Guile load path somehow: ",m (gnu packages haskell)" -> "ERROR: no code for module (guix build-system haskell)"
<taylanub>hmm, /usr/local/share/guile/site/2.0/guix/build-system/haskell.* really doesn't exist
<civodul>ah ah!
<civodul>that's the problem
<taylanub>there's no .go for the haskell.scm in the source directory either, so the build system doesn't see it I guess
<civodul>yes, it's not in the makefile
<civodul>i'll add it shortly
<taylanub>I get "warning: arbitrarily choosing /gnu/store/vaw1lnmg4j1mgz6s4qn42j6ids7swhxm-info-dir/share/info/dir" on the share/info/dir clash; this isn't really arbitrary, is it?
<civodul>this is fixed in core-updates, where packages no longer install a 'dir' file
<civodul>the 'dir' file is generated at profile-creation time
<taylanub>ah, ok
<civodul>well the fact that the 'dir' file is generated is not new
<civodul>just the fact that 'dir' is no longer installed
<civodul>taylanub: committed the haskell thing
<civodul>davexunit: i think you forgot to cc the list in your reply in the 'files' discussion
<davexunit>civodul: oops!
<davexunit>sorry about that
<mark_weaver>cmake fails to build on armhf. it segfaults in the check phase :-(
<mark_weaver>starting phase `check'
<mark_weaver>Running tests...
<mark_weaver>Makefile:137: recipe for target 'test' failed
<mark_weaver>make: *** [test] Segmentation fault
<mark_weaver>phase `check' failed after 1 seconds
<mark_weaver>otherwise armhf is looking pretty good so far
<mark_weaver>I see there's a new version, 3.2.1. maybe I should try that before digging into the code.
<mark_weaver>blah. learning more about cmake is not a job that I relish...
<mark_weaver>well, updating to 3.2.1 didn't fix the problem
<mark_weaver>hmm, the segfault is happening in nettle_yarrow256_update (from libnettle) during gnutls_global_init
<mark_weaver>I guess this is related to the gnutls update
<mark_weaver>too bad we have no debug information for gnutls or nettle...
<civodul>CMake depends on GnuTLS? uh
<civodul>could it be that two different libnettle end up being loaded?
<civodul>GnuTLS depends on nettle-2.7 whereas libarchive now depends on nettle-3 IIRC
<mark_weaver>oh, that could be it!
<mark_weaver>yes, this 'ctest' program is linked with new versions of nettle
<mark_weaver> and
<mark_weaver>civodul: any suggestion of how to cope with this?
<civodul>mark_weaver: probably libarchive should move back to nettle-2
<civodul>or, if that's too much rebuild, we can keep a separate variant of libarchive
<mark_weaver>I wonder if GnuTLS 3.4.0 works with nettle-3
<mark_weaver>yes, it does
<mark_weaver>civodul: how about updating gnutls to 3.4.0?
<mark_weaver>I guess it would mean more rebuilding though
<civodul>mark_weaver: we could do that yes
<civodul>i took the conservative choice, but yeah, why not
<mark_weaver>seems like it would be better to have new crypto
<mark_weaver>I'll work on it...
<civodul>cool, thank you!
<mark_weaver>I'll add debug outputs to nettle and gnutls while I'm at it.
<mark_weaver>is that okay?
<mark_weaver>or rather, wdyt?
<civodul>yes, sounds good!
<civodul>in general adding "debug" outputs is fine with me
<civodul>i've shamelessly done that for the packages where i needed it most ;-)
<civodul>(and hopefully others as well)
<mark_weaver>sounds good
*civodul toys with the idea of a self-contained tarball for easy installation
<mark_weaver>civodul: I think it would be great to have a tarball that contains /gnu/store/...-guix-* and its dependencies
<mark_weaver>plus the associated sqlite db
<mark_weaver>and whatever else is needed.
<mark_weaver>so that GuixSD can be bootstrap on older systems more easily
<mark_weaver>is that what you had in mind, or something different?
<civodul>mark_weaver: yes, that's exactly what i'm trying to do
<mark_weaver>sounds great!
<civodul>it's really to install Guix on a non-GuixSD system
<civodul>because for GuixSD we already have to image
<civodul>it's when reading Pjotr's email that i thought we should try it
<mark_weaver>if it could be done in such a way that we can produce such tarballs for mips and arm, even though we have no full system for those, that would be great.
<mark_weaver>we don't have qemu working on mips either. not sure if it works on arm
<mark_weaver>civodul: ^^
<civodul>it's doable :-)
<civodul>i'll post what i have in a minute
<mark_weaver>hmm, so gnutls-3.4.0 adds a new optional dependency on p11-kit, which fails to build on mips.
<mark_weaver>we could pass --without-p11-kit
<mark_weaver>to "disable PKCS #11 support"
<mark_weaver>would this be a regression from our existing gnutls-3.3? does it support PKCS #11?
<civodul>IIRC we don't use pk11kit currently, do we?
<mark_weaver>no, we don't
<civodul>ideally we would use it eventually
<mark_weaver>but I don't know if gnutls-3.3 supported it in some other way
<mark_weaver>yes, certainly
<civodul>not sure if 3.3 supported it
<civodul>i would say yes, but not 100% sure
<mark_weaver>I'm tempted to add --without-p11-kit for now and see if it causes any problems higher up
<civodul>yes, sounds good
<civodul>it wouldn't be a regression anyway
<mark_weaver>gnutls update pushed...
<civodul>mark_weaver: yay, thank you!
<mark_weaver>now cancelling jobs on hydra to make the evaluation happen faster
<mark_weaver>hydra seems very slow right now. I've been waiting for a few minutes to log in via ssh.
<civodul>ouch :-/