<marusich>I'm having trouble using geiser to find the place where certain procedures (or anything, really) are defined. For example, in $guix_git_repository_root/gnu/packages.scm, it seems that a procedure named "define-record-type*" is used to, I imagine, define records; however, I cannot for the life of me convince geiser to tell me where that is defined. How do I do that?
<rekado>lfam: you can attach strace to the pid of the daemon with "-p"; as it forks you should also use "-f".
<efraim>after running for 5:45, gccgo-5 failed at validate-runpath :(
<lfam>I know about (package-with-python2). I'm curious about what setting (#:python ,python-2) does. Does that only affect the python interpreter, or does it also change everything like (package-with-python2)?
<rekado>lfam: it makes the build system use python-2.
<rekado>for waf-build-system that's sometimes needed because the wscript is written with python2 syntax.
<civodul>xd1le: another thing that can be done is to export the bits of the profile (sledgehammer approach)
<davexunit>civodul's latest talk gives some good insight into why docker is ultimately unsatisfying.
<mark_weaver>that was in response to a question about the feasibility of importing .deb binary packages directly and using patchelf to fix them up, supposedly because "it might be easier than building from source".
<mark_weaver>(although I suspect his real motivation was to import non-free software)
<davexunit>ah, yes, well we certainly wouldn't do that.
<davexunit>now, taking a deb *source* package and attempting to generate a guix package expression based on it... that might bear some fruit.
<fps>i agree that that would be even better :) and in some cases simpler and in others harder..
<fps>oh, here's another take on the issue that might even bare more fruit and would improve packaging adoption: scheme is the simpler language to process
<fps>how about making a scm -> source deb compiler
<fps>then people might package for guix instead and debs would fall out
<rekado>arch people prefer their PKGBUILD files, RPM people already have their spec files (with macros upon macros) and the tools to build their RPMs; Guix package variables are not very useful if they are just used to refer to dependencies by name.
<davexunit>people ask us frequently "why don't you just use the packages from debian, npm, rubygems, etc.?"
<rekado>Guix package variables are powerful because they don't just *name* dependencies.
<mark_weaver>speaking of security updates, the mit-krb5 security updates are taking longer to build out than I expected. "guix refresh -l mit-krb5" estimated 179 dependent packages, but then it required over 2300 rebuilds.
<civodul>mark_weaver: yes, i was thinking of the wpa_supplicant patch specifically, which is "minimal" in this sense
<taylan>are the donation links and such up yet by the way?
<fps>ok, a more productive question: i'm on guixsd and wanted to add the package to gnu/packages/audio.scm. so i cloned the guix repo, hacked the file, and used guix package -L /path/to/guix/clone -i swh-plugins-lv2
<fps>but that didn't work. do i have to build the guix checkout?
<fps>ah right, i suppose so, so i can use pre-inst-env
<mark_weaver>I think probably the right answer is to package a lot of R packages, and if possible, make a "guix import" command for R packages
<rekado>we have a guix import command for R stuff (the CRAN importer)
<rekado>but unfortunately lots of users also get R packages from bioconductor.
<rekado>I'm planning to write an importer for bioconductor as well.
<mark_weaver>I would say that "install.packages" should be rigged to automatically operate in an environment where 'gcc-toolchain' is available (with PATH, CPATH, and LIBRARY_PATH set appropriately), but it occurs to me that in general, you'll also need other packages available, e.g. libxml2 in this case? so I don't know a good answer other than to package things up.
<rekado>one obvious solution is for users to install the dependencies they need (e.g. libxml2) into their guix profile, in addition to the compilers, and only then run install.packages().
<rekado>it's almost simpler to just package the R packages directly.
<rekado>we still have some problems with our GCC variants. One issue is that gcc-toolchain gives us GCC 5.x, but gfortran is only at 4.9.3. Another is that installing gfortran along with gcc-toolchain results in uncountable conflicts of header files.
<efraim>/gnu/store/za0b1cw7i7sr5mipjqj5w5g4rj2yyasw-gccgo-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/cgo: error: depends on 'libgo.so.7', which cannot be found in RUNPATH ("/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib")
<efraim>validating RUNPATH of 11 binaries in "/gnu/store/za0b1cw7i7sr5mipjqj5w5g4rj2yyasw-gccgo-5.2.0/bin"...
<efraim>/gnu/store/za0b1cw7i7sr5mipjqj5w5g4rj2yyasw-gccgo-5.2.0/bin/go: error: depends on 'libgo.so.7', which cannot be found in RUNPATH ("/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib")
<efraim>/gnu/store/za0b1cw7i7sr5mipjqj5w5g4rj2yyasw-gccgo-5.2.0/bin/gofmt: error: depends on 'libgo.so.7', which cannot be found in RUNPATH ("/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib")
<fps>maybe i underestimate pretty-printers though and they would make the tree structure apparent enough as well
<mark_weaver>I don't think close parens on their own lines are the least bit helpful in seeing the tree structure. if the code is indented properly (which can be done by an auto-indenter or pretty-printer), then you can see where a block ends easily based on the indentation.
<mark_weaver>I can understand why some people like to see the open paren and close paren lined up with each other in the same column, but that's just an aesthetic preference.
<mark_weaver>if you the close paren that would have been alone is at the end of the previous line instead, then you just look for the first line that's indented less than the opening.
<davexunit>The reproducible-builds.org twitter account shared civodul's "reproducible builds: a means to an end" post.
<mark_weaver>and there are far fewer useless lines, leading to more compact code.
<roelj>I installed a new font package in Guix. Now, how can I set the font in Emacs to a font installed by that package? (Emacs cannot find the font).
<mark_weaver>roelj: you might need to run "fc-cache -f", and you might need to restart emacs, dunno.