<habs>I think there is something gravely wrong with my GuixSD installation. Is there any way to do a more thorough check than 'guix gc --verify=contents'? Any new packages I install always segfault unless I run them with sudo, and I get several hundred "collision encountered" warnings when installing any package.
<alezost>habs: I think you installed different packages in different times which may lead to multiple collisions, try to upgrade your profile: "guix package -u"
<alezost>btw how many packages are in your profile?
<efraim>i wonder if we should add an option to git-fetch for '--depth=1 --shallow-submodules'
<efraim>it always seemed faster for me on my netbook to not have to compute all the tags
<efraim>is lgpl2.1+ and openssl is ok? or should I switch openssl for gnutls
<ng0>Hi. Some of us are at reddit, right? What do you think about doing an "Ask Me Anything I'm a Guix Developer" or something like that? I don't use reddit, but depending on the topic those are good to get some questions solved and to get answers out there which aren't already obvious, and I think there's some percentage of reddit users which are hackernews users...
<efraim>we could try it, i'm not too sure how well I know some of the internals
<ng0>it's not a one person operation, so I assume the "I" could be extended to "we are" and more than just one person answers? I'm not sure how this AmA thing usually works
<efraim>#fsf says lgpl and openssl are incompatable
<efraim>i'm running find on /gnu/store now for pdflatex
<ng0>The optional dependency is there, it can beadded, i already do so on another system. I'm not sure though if it would require texlive or texlive-minimal or something entirely different, and I know many people here are protective about adding texlive to something
<ng0>ACTION runs e-file to check where pdflatex actually is
<efraim>so far i've found it in texlive and texlive-bin
<snape>it does not rebuild the kernel if none of its inputs are updated, but since I'm debugging the kernel, the source of the kernel is updated, and the build-initrd scm function will trigger a whole kernel rebuilding
<habs>I tried running 'guix package -u' and it succeeded but now things are much worse as even the guix binary segfaults when run without sudo. Also I have 120 packages in my profile (GuixSD on a Thinkpad) @alezost. What can be done to further debug / fix this?
<efraim>well, with efl gobbling up all the other enlightenment libraries it's time to add another patch making efl the sole enlightenment input on a couple packages
<habs>This is a quick example when I run /run/current-system/profile/bin/ls or any other newly-updated binary: http://sprunge.us/VZjB Can anyone help debug why they segfault? Is it a problem with my library paths?
<iyzsong>habs: did you set LD_LIBRARY_PATH? it shouldn't load libcap from ~/.guix-profile
<habs>iyzsong: My LD_LIBRARY_PATH is "/home/habs/.guix-profile/lib:/lib:/lib64"
<muck>how would you guys log stdout on tty1 within qemu when debugging a wm build ? the wm doesn't start and clearly produces lua related errors (awesome-wm) but i can't read it fast enough thanks to slim restarting and no related logs being in /var/log
<efraim>elementary is now part of efl, same commit to remove the now superfluous elementary or new commit?
<bavier>it might be nice for 'guix build' if one could specify the packages output, e.g. glibc:out, to optimize the case where substitutes are used
<lfam>bavier: You mean, only build the specified outputs?
<lfam>paroneayea: Maybe you were watching the installation process of some other package, which uses the `install` command from coreutils? That prints the store path of coreutils. I've been alarmed by seeing that in the past, until I realized what was happening.
<sankey>but it's not a tablet, didn't know those existed
<ngz>Hello. I'm currently struggling with a package definition (at http://paste.lisp.org/+6Y49), which throws the following error: ice-9/eval.scm:386:9: Throw to key `match-error' with args `("match" "no matching pattern" ())'. Any help is appreciated, since the package is otherwise finished.
<bavier>ngz: idk about the match error, but the cmake-build-system already builds within a separate "build" directory