IRC channel logs


back to list of logs

<civodul>Hello Guix!
<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
<civodul>yes, will do!
<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 ?
<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
<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
<davexunit>civodul: awesome :)
<civodul>effa: BTW, could you look at the numpy build failure?
<rekado_>python-pillow does not seem to work properly. I get this error on "from PIL import Image" (python3): ImportError: 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.
<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>bavier: i had tried to remove the patch-rpath phase and apply that instead:
<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>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 ;-)
<davexunit>because you can represent HTML with sexps, too :)
<civodul>there's an (htmlprag) module in guile-library
<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>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.
<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
<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_>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.
<rekado_>also, the download is usually very slow, but it seems much faster when downloaded with wget.
<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>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>about "delegation" vs. ACLs
<civodul>RUNPATH challenges of the day: webkitgtk and avidemux
<civodul>difficulty: easy to medium
<rekado->a patch for webkitgtk has already been sent to the ML.
<civodul>oh nice
<civodul>M-x gnus
<davexunit>civodul: the 'guix environment' changes look good, btw.
<civodul>davexunit: ok, thanks