IRC channel logs

<rekado_>Hello civodul!

<phant0mas>civodul: I posted the backtrace with the patch so you can have a look

<phant0mas>and good morning :P

<civodul>hey, phant0mas

<Phlogistique>do you know if people are using Guix without GuixSD to install X server + graphical environments? (e.g. XFCE, if you have that in Guix)

<rekado_>Is there a nicer interface to hydra (e.g an Emacs mode) and/or a way to restrict the list of failing builds to only one architecture and only to direct failures (not propagated failures from dependencies)?

<rekado_>Phlogistique: on the cluster I installed graphical tools (e.g. Thunar) for a user, but not all of XFCE.

<rekado_>Phlogistique: on my main laptop I use Guix on top of Fedora but still use the GNOME shell; I have installed XFCE there, but haven't had the time to actually try it yet.

<Phlogistique>rekado_: alright, thanks

<iyzsong>Phlogistique: the X server won't work

<iyzsong>it build a service for dmd, and need root permission

<rekado_>iyzsong: dmd can be run in addition to the existing init, even as root, to manage the required service, no?

<rekado_>(although that's getting eerily close to running the system distribution)

<iyzsong>rekado_: yes, but I wonder who will do that ;-)

<paroneayea>hello, *

<rekado_>I wonder if it would be possible to create packages on the fly for Emacs packages from ELPA.

<rekado_>It seems like a lot of work to duplicate the package database ina different format.

<rekado_>I would really like to guixify all of my Emacs stuff, because none of the package management methods available for Emacs are really satisfying.

<rekado_>guix package --from=elpa --install god-mode geiser ido-vertical-mode ...

<paroneayea>rekado_: it's an interesting idea to have on-the-fly-generated packages

<paroneayea>esp when polled from other sources

<paroneayea>since you can build package objects, I don't see why not

<paroneayea>I wonder what civodul thinks about that route?

<rekado_>I guess the biggest hurdle is that there are no published hashes for elpa packages afaics.

<rekado_>I would really like to use something like on-the-fly packages for R packages as well.

<jmd>From whence comes the data for column 0 in the table at http://www.gnu.org/software/guix/package-list.html ?

<rekado_>a guess only: from the "mirror://gnu..." line?

<jmd>rekado_: Could be ... It would explain why it thinks that gnome and R are not part of Gnu.

<civodul>paroneayea: the initial idea was to have 'guix import' produce <package> objects instead of sexps, so that one could run, say, "guix import pypi foo --build"

<civodul>or what rekado_ writes, indeed

<civodul>rekado_: yes, interesting idea

<civodul>jmd: http://git.savannah.gnu.org/cgit/guix.git/tree/guix/gnu-maintenance.scm#n173

<paroneayea>civodul: cool

<civodul>we could have mirror-type return 'gnu for mirror://cran, but that wouldn't be accurate for non-GNU packages available on CRAN

<jmd>What about mirror://gnome ?

<jmd>Or better still, just import /gd/gnuorg/maintainers.bypkg from fencepost

<effa>Hi rekado_, re on-the-fly generated packages: I guess the first step would be to write an ELPA importer.

<civodul>jmd: i've just fixed these two cases :-)

<civodul>fencepost is not publicly accessible so it's not an option

<civodul>effa: right

<civodul>the problem is that importers currently don't do much with dependency information

<civodul>they just import a single package and try to guess the variable name for dependencies

<civodul>something more sophisticated would be needed for general on-the-fly generation

<effa>Some repositories provide a full list of dependencies (e.g. hackage). So, if the name mapping is consistent, then it should work.

<effa>Personally I'm not entusiastic about on-the-fly package generation because it makes things non reproducible.

<effa>I prefer importers toghether with a way to refresh things.

<civodul>effa: yes, good point

*davexunit also prefers an importer to on-the-fly generation.

<davexunit>it's just a matter of getting people to maintain these packages.

<jmd>civodul: gnumeric should also be in that list?

<rekado_>I was thinking about the case when a user would like to have software managed by guix (--> rollbacks), but is not comfortable enough or willing to hack on package definitions.

<rekado_>to have guix build and install stuff is still better than using some external means.

<rekado_>(obviously, for the project it makes more sense to have more packages and have them maintained, but maintining packages isn't for everyone.)

<davexunit>I suppose.

<davexunit>I'm not particular enthused about that direction, but if someone makes it work, that's cool.

<civodul>jmd: yes, works fine for gnumeric

<civodul>iyzsong: BTW, there's some Bash syntax in our /etc/profile and with environment-variable-definition in (guix search-paths) i'm about to introduce some more

<civodul>i guess zsh actually understands that syntax though

<civodul>iyzsong: WDYT?

<civodul>davexunit: i've just pushed changes to 'guix environment' to consolidate search path handling

<civodul>comments welcome :-)

<iyzsong>civodul: yeah, /etc/profile should work for both bash and zsh, and we could make another file for fish :-)

<civodul>iyzsong: so apparently "export foo=bar" works for zsh, right?

<iyzsong>yes, export works for dash too

<civodul>hmm not sure for dash

<davexunit>civodul: oh good, I remember making a not-so-great patch for that awhile ago.

<davexunit>yours is surely better. :)

<civodul>iyzsong: doesn't it need "FOO=bar; export FOO"?

<civodul>davexunit: it's just that search paths are in cache now for me, so everything looked clearer today :-)

<civodul>iyzsong: also, does zsh support "${FOO:+bar}"?

<iyzsong>civodul: yes, it works

<civodul>good

<davexunit>civodul: awesome :)

<civodul>effa: BTW, could you look at the numpy build failure? http://hydra.gnu.org/job/gnu/master/python-numpy-1.9.1.x86_64-linux

<rekado_>python-pillow does not seem to work properly. I get this error on "from PIL import Image" (python3): ImportError: libopenjp2.so.7: cannot open shared object file: No such file or directory

<effa>civodul: AFAIU hydra never managed to build numpy because of the CPU dependent ATLAS. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19805

<effa>However, the package builds fine locally.

<rekado_>effa: would it be possible to uild to build numpy against openblas?

<rekado_>s/to uild //

<civodul>effa`: oh, i thought it did build on Hydra at some point

<civodul>i must be mistaken

<phant0mas>civodul: when bootstraping and a package origin has a non-empty 'patches' field it uses %bootstrap-patch-inputs from bootstrap.scm to patch them, right?

<bavier>civodul: I looked a bit at the hop build, I think the currect failure is due to a change in the way that bigloo 4.1a handles rpath embedding in executables

<civodul>bavier: i looked at it a bit, and i think bigloo just doesn't try to deal with rpath

<civodul>i tried to have it pass -Wl,-rpath to gcc, but failed

<civodul>but i can give it a try again

<civodul>phant0mas: yes

<civodul>i'll try out your patch

<bavier>civodul: yeah, so the current patch-rpath phase I think needs to move from making substitutions in the current rpath to adding libdir to the rpath

<civodul>yes, prolly

<bavier>I can try it

<civodul>ok

<civodul>bavier: i had tried to remove the patch-rpath phase and apply that instead: http://paste.lisp.org/+3636

<civodul>that doesn't work for some reason

<civodul>maybe what you suggest will work better

<rekado_>building texlive-texmf without substitutes and with very big timeout and max-silent-time values takes an incredibly long time :-(

<rekado_>downloading the substitute doesn't work for me because of corruption.

<rekado_>I wished we could split this huge package.

<rekado_>I'm now stuck at "phase `texmf-config' succeeded after 64 seconds" since several hours.

<civodul>uh, is that normal?

<civodul>and why do you get that corruption when i don't? :-)

<civodul>would anyone be willing to help with the html->sxml conversion of the new web site?

<civodul>it would be great to put it on-line quickly, before the release

<davexunit>civodul: how do I get involved?

<effa`>rekado_: I never used OpenBLAS. I picked ATLAS because that's what is mentioned in the numpy build instructions that I did follow.

<effa`>I'm not against chaning that, but hopefully not at the expenses of performance :-)

<civodul>davexunit: just clone the guix/guix-artwork.git repo, manually do html->xhtml, and then run xml->sxml on that, pretty-print, and voilà :-)

<civodul>from there we can gradually factorize/improve things

<davexunit>civodul: guile needs a html->sxml :)

<davexunit>I wrote sxml->html

<davexunit> http://dthompson.us/rendering-html-with-sxml-and-gnu-guile.html

<civodul>right

<davexunit>but yeah, I can try to squeeze some time in for this conversion.

<civodul>but i think we can use utf-8 all the way and not worry about escapes no?

<davexunit>civodul: I was told that by someone else, too.

<civodul>ok, thanks in advance, then :-)

<davexunit>I had no idea.

<davexunit>need to try it.

<civodul>as long as the page's content-type is utf-8 and the server's HTTP content-type is utf-8 too (which it is), we're fine

<davexunit>I'm just not sure what to change :)

<effa`>civodul: hydra does build Numpy for i686, but fails for x86_64

<davexunit>civodul: hmm, okay, but writing a general procedure that assumes utf-8 seems risky.

<civodul>davexunit: nothing :-) the html pages already have charset=utf-8

<civodul>in general yes, but here we can safely assume utf-8

<davexunit>civodul: okay

*civodul advocates best practices ;-)

<davexunit>I'm still worried about the general case, because I think Guile core's SXML modules should handle HTML, too. :)

<civodul>but html is not xml, AIUI

<civodul>so i'm not surprised xml->sxml doesn't handle html

<davexunit>I think a separate procedure should, though.

<civodul>but then again, i'm not the html expert here ;-)

<civodul>yes

<davexunit>because you can represent HTML with sexps, too :)

<civodul>there's an (htmlprag) module in guile-library

<civodul>right

<davexunit>hmm, didn't know about that

<civodul>"pragmatic html parser"

<civodul>meaning it tries to deal with hand-written, broken html from the 90's

<davexunit>that's good for web scrapers and stuff

<civodul>yes, definitely

<davexunit>I had a friend very recently wishing he could do this with guile

<civodul>that's what web browsers do also

<davexunit>yup

<davexunit>horrible!

<davexunit>what a bad format!

<davexunit>it's so easy to make mistakes that web browsers have to put lots of effort in working around it.

<civodul>yeah

<rekado_>civodul: I don't know if it is normal. But the corruption is something I get every time I need to install texlive :(

<effa`>I also got corrupted TeXLive. Now I usually do not substitute

<effa`>it

<rekado_>I'm dreading core update merges, because this usually means I have to mess with texlive building again (because that's needed for numpy)

<civodul>what guile version are you using?

<civodul>i don't think we have an open bug report for that, do we?

<rekado_>2.0.9

<civodul>okay

<rekado_>I'm not sure if it's a network/firewall issue.

<rekado_>I only run into this problem with texlive-texmf-2014.

<civodul>i would have thought that, but if effa` is having the same issue...

<rekado_>probably because it's massive.

<civodul>yeah

<rekado_>also, the download is usually very slow, but it seems much faster when downloaded with wget.

<civodul>ooh

<civodul>could you just file the backtrace/error that you get with whatever details are relevant?

<civodul>and regarding speed, it would be nice to check that

<bavier>I've noticed the speed difference with wget as well

<civodul>long ago there was this kind of problem because Guile was setting an wrongfully small input buffer on the socket

<civodul>bavier: could you report it, stating the Guile version, Guix commit, etc.?

<taylanub>when some sources are patched, guix downloads the patched version from hydra (as a substitute) instead of downloading the raw sources and patching them locally, right? so maybe it downloads slower than with-wget/from-upstream because hydra is slower

<bavier>taylanub: yes, but we don't patch texlive

<taylanub>hm, indeed

<civodul>guix always downloads sources from hydra when substitutes are enabled

<civodul>even unpatched

<civodul>the test would be to compare 'guix download foo' with 'wget foo'

<taylanub>oh, ok

<civodul>they should be equally fast

<rekado_>I was referring to downloading the binary substitute, the nar file.

<rekado_>fetching it with wget is faster. (I'll try to reproduce this.)

<rekado_>another thing I find odd is that even when the daemon runs with --debug there is no output for a long time (> 1min) after printing the list of files that will be downloaded.

<rekado_>I have no idea what Guix is doing at this point and why it takes so long.

<rekado_>it's actually considerably longer than 1 min.

<rekado_>strace shows me that "guix build" is waiting for input: "read(10, "

<civodul>ouch

<civodul>another bug to file :-)

<civodul>when the daemon runs with --debug, it prints tons of stuff

<civodul>so i'm not surprised that makes it slower, but still

*civodul has to go

<bavier>ohh, effa left...

<bavier>I just got some atlas/openblas performance data to share

<davexunit>interestng article from the sandstorm folks

<davexunit> https://blog.sandstorm.io/news/2015-05-05-delegation-is-the-cornerstone-of-civilization.html