IRC channel logs
2013-11-29.log
back to list of logs
<jmd>It seems that gtksourceview's "make check" stage requires a running X server. Is there any way I can get guix to start xvfb before running make check ? <a_e>guix package -A icecat <jmd>make check gives me 11 failures <a_e>jmd: Just adding xorg-server as input is not enough? <jmd>It would seem not. The server has to be started. <jmd>And obviously the DISPLAY variable set accordingly. <a_e>You could add a phase before configure that does that, using "system*", and "setenv".. <a_e>Or, in the worst case, patch out the offending tests... <jmd>ok, I'll look into it. <jmd>It really should be done after configure. <jmd>between "make" and "make check" <a_e>Sorry, yes, I meant before check. <gzg>a_e: On latest git patch? <gzg>a_e: Or, do you have a sample expression and/or patch to send me? <a_e>gzg: On git HEAD, of course. <gzg> a_e: I don't see it? <a_e>Or is it not? Let me check. <gzg>a_e: What's the source file the expression should be in? <a_e>gnu/packages/gnuzilla.scm <a_e>I added it on November 11, there is an entry in the git log. <a_e>Did you do a "make install; guix package -A icecat", or a "./pre-inst-env guix package -A icecat"? <gzg>a_e: Ah, weird. Not sure why my actual install didn't find it... but yeah, my pre-inst-env works. <gzg>Cool, might package conkeror then! <mark_weaver>gzg: if you've done 'guix pull' at some point, that would override whatever was last "make install"d. <mark_weaver>./pre-inst-env avoids looking at whatever was last 'guix pull'd. <mark_weaver>(the 'guix pull' stuff is in ~/.config/guix/latest/, so you might want to just blow away that directory) <mark_weaver>(well, if XDG_CONFIG_HOME is set, then it'll be in $XDG_CONFIG_HOME/guix/latest) <gzg>mark_weaver: I know that, I'm saying I have a recent build actually installed on my system (as in less than a week ago) and it didn't find it. :^P <mark_weaver>gzg: I'm saying that when you use guix without ./pre-inst-env, it's always going to use what's in ~/.config/guix/latest/ if it exists, and ignore anything else you've installed since then. <mark_weaver>"guix pull" is what populates ~/.config/guix/latest/ <a_e>I actuallly never use "guix pull". When one is on the development version, one might as well "git pull". <mark_weaver>agreed. for guix developers, I recommend just using ./pre-inst-env all the time. <mark_weaver>I did "make uninstall" to get rid of the installed version of guix, and I put a 'guix' shell script in my private ~/bin directory that does: exec $HOME/guix/pre-inst-env guix "$@" <gzg>"guix pull" still never works for me. :^P <civodul>gzg: actually "guix pull" cannot handle the last core-updates transition :-/ <civodul>that's because of the guile bootstrap tarball update <mark_weaver>The Loongson 3A has completed its attempts to build (almost) every package in guix (recent core updates) <mark_weaver>it mostly looks good, almost as good as before the core-updates merge. <mark_weaver>I can't successfully download the source for icecat, ImageMagick, or pysqlite <civodul>is that because they vanished or something? <mark_weaver>ImageMagick has a bad distribution policy where the older versions are somewhere else <mark_weaver>hmm, maybe it's just aborting the icecat download because pysqlite fails to download. <civodul>maybe it's going to a broken mirror? <mark_weaver>ah right, and now I remember why I didn't simply update the URL for pysqlite before: the hash has changed even though the filename is the same. I wanted to find a copy of the older file to see what changed. <mark_weaver>civodul: how do I obtain it from hydra? last time you gave me a URL that yields a .nar file, but I wasn't sure what to do with it. <civodul>the nar file can be extracted using the tools in (guix nar) <civodul>but otherwise you could temporarily enable subsitutes, and run "guix build -S pysqlite" <mark_weaver>pysqlite-2.6.3.tar.gz is only 77k. would someone be willing to mail it to me? (their copy of /nix/store/*-pysqlite-2.6.3.tar.gz) <mark_weaver>well, I guess it doesn't matter since I can check the hash <mark_weaver>blech. the diff is 15 kilobytes of non-trivial code changes. <mark_weaver>without changing the version number or filename in any way. <mark_weaver>and that 15k doesn't include the two new *.css files <mark_weaver>btw, I really like the fact that Guix alerts us to these hidden changes when they occur :) <mark_weaver>so, what version number should I assign to the _new_ pysqlite-2.6.3 ? <mark_weaver>I guess I should get on their mailing list and educate them as politely as I can. <civodul>like you did before, although Manuel nicely ignored the message... <civodul>i would stick to the upstream version number in Guix *civodul prepares dmd 0.1 <gzg>civodul: Should we compile a 0.5 "desired packages" list for the Demo image? <gzg>a_e: Well so far we got xorg, slim, ratpoison, emacs, icecat. <civodul>i'd like to release 0.5 within a couple of weeks at most <civodul>so i'm not sure we can get too many things in the image until then <gzg>Which is pretty usable thus far, I suspect -- for those wanting to try out such an "early image". <gzg>I'm still hoping by the 1.0 demo, that we'll get "rattrap" or something to the effect of Stumpwm/Ratpoison via Guile Wm. <civodul>the last Guile-WM release didn't build actually, or needed quite a few workarounds <civodul>but i hope there'll be other ones soon <gzg>civodul: 0.1, or from master? <civodul>it was guile-xcb 1.1 that was problematic, IIRC <gzg>civodul: I built from master and it works, the release depended on "guile 2.2" I believe, but I'm not sure if there were an; other problems. <civodul>yeah, the "2.2" issue was easily patched <civodul>but then i think there was something else <mark_weaver>fixes were needed for both guile-xcb and guile-wm, but afaik he hasn't made a release since then. <civodul>yeah, no commit since August apparently <civodul>would be great if you could ping him <civodul>tell him there's a whole bunch of fans waiting for the continuation ;-) <Steap>Best joke I've read in a long time. <Steap>But a real vim user would use ':x' *gzg is excited by the prospect of the implementation of a widget system and/or graphical toolkit in guile-wm, to get Emacs going in it. <gzg>With GuilEmacs and Guile-wm, we really aren't that far form effectively having a solid basis for a pseudo-LispM OS. <TaylanUB>gzg: We have GTK bindings for Guile (don't know if up to date though), I'm not sure if a new graphics toolkit in Guile would be useful. <Steap>mark_weaver: did not know about this one :) <mark_weaver>I also sometimes think a toolkit in Guile would be interesting, but I'm not sure it should be based on the X protocol at this point. <TaylanUB>Rather, I'd imagine something like having the GTK-front-end code rewritten in Guile, in Guile Emacs. <TaylanUB>(Did I miss anything ? My ISP just force-reconnected me.) <civodul>systemd maybe? (does it do graphics yet?) <mark_weaver>modern stuff seems to be based on OpenGL and related APIs, though I must claim almost total ignorance of them. <mark_weaver>but them seem much better suited to modern graphics work. <mark_weaver>well, all of this pales in comparison to nalaginrut's lisp machine project :) *TaylanUB doesn't see what makes MonaOS special ? <gzg>TaylanUB: To my understanding the guile-wm method would be fairly generic, seeing there will be the attempted wayland support. <civodul>TaylanUB: nothing, except that it's written from scratch by a couple of people (?) <TaylanUB>civodul: Ah, that's something too I guess. :D <gzg>TaylanUB: Also "guile-gtk" is deprecated as far as I know, "guile-gnome" is more up to date, but still behind. <TaylanUB>gzg: Some kind of "direct Wayland front-end" (akin to toolkit-less Xlib front-end) could be written from scratch in Guile I guess. <mark_weaver>guile-gnome includes everything that was in guile-gtk <mark_weaver>and yeah, none of it has been updated to gtk/gnome 2 <mark_weaver>civodul: nalaginrut wants to build a new lisp machine (based on a new CPU and OS) from scratch. <mark_weaver>it sounds like he already has some friends who are hardware hackers choosing components and such. <gzg>mark_weaver: Was there ever a page uploaded with the project info? <gzg>It'd surely be something fun to play around with, in lieu of the more practical Emacs+Guile-wm route. <mark_weaver>I confess I'm prone to such grandiose thinking from time to time, but it's not long before I come to my senses :) <gzg>mark_weaver: Probably better than the manic-like states I get to occasionally in-terms of grandiose modes of thought. :^P <gzg>I suppose it's good to have that centering factor in-place, to keep one grounded though.