IRC channel logs

<zacts>there is also conkeror

<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>gzg: Try

<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>But it is there!

<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/

<gzg>mark_weaver: Ah.

<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>Hello Guix!

<mark_weaver>hi civodul!

<civodul>gzg: actually "guix pull" cannot handle the last core-updates transition :-/

<civodul>i should send a note

<civodul>that's because of the guile bootstrap tarball update

<civodul>hey mark_weaver

<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>oh, ok

<mark_weaver>(the latter two I already knew about)

<civodul>is that because they vanished or something?

<mark_weaver>pysqlite has moved

<civodul>ok

<mark_weaver>ImageMagick has a bad distribution policy where the older versions are somewhere else

<mark_weaver>(and apparently don't even have the same filename)

<mark_weaver>(at least not in this case)

<mark_weaver>I'm not sure what's going wrong with icecat.

<mark_weaver>all I see in the build log is: starting download of `...' from `http://ftpmirror.gnu.org/...'..., and then "following redirection to 'http://...'... and that's it.

<civodul>i get redirected to http://ftp.igh.cnrs.fr/pub/gnu/gnuzilla/24/icecat-24.0.tar.gz and then it works

<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?

<civodul>ah, ok

<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.

<civodul>it can be obtained from hydra

<mark_weaver>also, the new URL http://pypi.python.org/packages/source/p/pysqlite/pysqlite-2.6.3.tar.gz helpfully redirects me to the https address, which has a bad SSL cert (certificate common name "*.a.ssl.fastly.net" doesn't match requested host name "pypi.python.org".

<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"

<civodul>*substitutes

<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)

<civodul>ok, lemme check

<mark_weaver>preferably signed by you

<mark_weaver>well, I guess it doesn't matter since I can check the hash

<civodul>done!

<mark_weaver>thanks!

<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>(one of which is 5k)

<mark_weaver>here's the diff: http://paste.lisp.org/+3093

<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>yes :-)

<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?

<a_e>icecat ;-)

<gzg>a_e: Well so far we got xorg, slim, ratpoison, emacs, icecat.

<civodul>gzg: yep if you want :-)

<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

<civodul>but we can try!

<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>yeah, definitely

<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

<civodul>which is needed by guile-wm

<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

<civodul> http://lists.gnu.org/archive/html/guile-user/2013-08/msg00098.html

<mark_weaver>civodul: yeah, there were other problems.

<mark_weaver>fixes were needed for both guile-xcb and guile-wm, but afaik he hasn't made a release since then.

<mark_weaver>I'll ping him.

<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 ;-)

<mark_weaver>xb

<mark_weaver>(oops)

<civodul>:wq

<civodul>(just kidding)

<mark_weaver>haha, we all know you're an emacs man :)

<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.

<gzg>:^)

<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.

<mark_weaver>when I use vi or vim, I usually do ZZ

<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.)

<mark_weaver>especially with plans to switch to wayland

<civodul>Mir!

<TaylanUB>Northwhateveritsnamewas!

<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.

<TaylanUB>hehe

<mark_weaver>but them seem much better suited to modern graphics work.

<civodul>i was looking at http://monaos.org/ thinking: "we're not really adventurous"

<mark_weaver>wow

<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.

<gzg>Probably.

<civodul>TaylanUB: nothing, except that it's written from scratch by a couple of people (?)

<civodul>mark_weaver: what's his project?

<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>s/2/3

<mark_weaver>(it's on 2, not 3)

<mark_weaver>though there are also clutter bindings

<civodul>would be great to have it packaged

<civodul>never got around to doing it

<mark_weaver>civodul: nalaginrut wants to build a new lisp machine (based on a new CPU and OS) from scratch.

<mark_weaver>iirc, he wants to develop the new CPU using FPGAs

<mark_weaver>it sounds like he already has some friends who are hardware hackers choosing components and such.

<mark_weaver> https://gnunet.org/bot/log/guile/2013-10-30#T267370

<mark_weaver>and https://gnunet.org/bot/log/guile/2013-10-30#T267423

<gzg>mark_weaver: Was there ever a page uploaded with the project info?

<civodul>woow

<gzg>It'd surely be something fun to play around with, in lieu of the more practical Emacs+Guile-wm route.

<mark_weaver>civodul: he's certainly ambitious, eh? :)

<civodul>indeed :-)

<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 :)

<civodul>:-)

<mark_weaver>(usually I just have to sober up :)

<mark_weaver>ah yes, I've heard of that.

<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.

<mark_weaver>heh :)

IRC channel logs

2013-11-29.log