[00:11] <cj> Amaranth: that happens when you poke at opengl sometimes :)
[00:12] <Amaranth> cj: nah, was xulrunner fail, reinstall fixed it
[02:10] <Six66Mike> so no help here eh? waited 30 mins in #ubuntu with no love
[08:31] <mvo> asac: have you seen http://paste.ubuntu.com/104758/ ? this happend to me on a intrepid->jaunty upgrade
[08:38] <didrocks> morning o/
[08:45] <huats> morning everyone
[09:02] <mvo> asac: together with http://paste.ubuntu.com/104760/
[09:05] <mvo> asac: I think this is a side effect of dropping the 81_sonames.patch ?
[09:06] <mvo> asac: anyway, it seems to have made my upgrade unhappy :)
[09:08] <seb128> asac: bug #316941
[09:09] <seb128> asac: you should have changed the binary name or conflicted on everything using the library that needs to be upgraded
[09:10] <huats> hello asac and seb128
[09:10] <seb128> lut huats
[09:11] <huats> how are you seb128 ?
[09:11] <seb128> huats: good thanks, how are you?
[09:11] <huats> great too!
[09:17] <huats> seb128: any idea where should I look to try to fix the issue I am facing with python-gtk2-dbg, that is blocking for the deskbar-applet ?
[09:18] <huats> (a missing symbol in the -dbg)
[09:18] <seb128> huats: the pygtk rules?
[09:18] <seb128> huats: it's likely that the non-dbg version gets installed as dbg for some reason
[09:18] <huats> seb128: I'll have a look in that way
[09:19] <seb128> you can try to ping lool pochu or slomo about it maybe, we synced pygtk on debian this cycle so the bug is likely there too
[09:20] <huats> ok
[09:21] <lool> huats: Check your build log to see whether an automatic autoreconf is triggered; if that's the case you want the fixes we have in Debian SVN
[09:22] <lool> huats: Actually I see a typo now
[09:22] <lool>         PYTHON=/usr/bin/python$* $(MAKE) -C dbg-build-$*
[09:22] <lool> Fortunately it escaped hardy-updates
[09:24] <huats> lool: hello btw ;)
[09:26] <huats> lool: I'm  testing it, to see if it works with that
[09:26] <lool> huats: Just committed the fix in Debian's SVN
[09:26] <lool> Don't know whether that was your issue
[09:26] <huats> ok
[09:27] <huats> an missing symbol
[09:27] <huats> I can get you the steps to reproduce
[09:27] <huats> (easy..)
[09:31] <seb128> lool: python-dbg -c "import gtk" doesn't work
[09:31] <seb128> lool: the version installed as dbg seems to be the non dbg one
[09:33] <huats> seb128: the dbg .so and the non dbg one, at least differs (using to check diff)
[09:33] <lool> I'm a bit busy to say the least; would you mind trying the version in the Debian experimental *SVN* and see if that helps?
[09:33] <lool> This python dbg stuff keeps breaking every 2 months and takes me 2 days to fix
[09:33] <asac> seb128: the idea is that there is a link
[09:34] <seb128> asac: ok so it seems to not work correctly? could you look at this bug and maybe ask whatever you need to debug the issue?
[09:36] <asac> seb128: have you upgraded to latest nss?
[09:36] <seb128> asac: no, jaunty moves to quickly for me ;-)
[09:36] <seb128> I'll try to upgrade now
[09:36] <asac> do you have this link?
[09:36] <asac> asac@hector:~$ ls -l /usr/lib/libnss3.so.1d
[09:36] <asac> lrwxrwxrwx 1 root root 10 2009-01-11 21:41 /usr/lib/libnss3.so.1d -> libnss3.so
[09:38] <seb128> asac: yes, that is working here
[09:39] <asac> see ... all fine. damn
[09:39] <asac> whats the problem for this guy
[09:40] <seb128> not sure, maybe ask the version he's running and if the symlink is there
[09:40] <asac> i dont even know what to ask for ... now asked for upgrade temr.log
[09:40] <seb128> asac: where do you do the symlinking?
[09:40] <asac> seb128: so ... the tricky thing here is that the link was flipped.
[09:40] <huats> lool: sure
[09:41] <asac> in previous version it was libnss3.so -> libnss3.so.1d ... and now we have libnss3.so.1d -> libnss3.so
[09:41] <asac> so i move the files away in preinst
[09:41] <huats> lool: to ease stuffs, I'm trying the newer in jaunty with that fix you just mentionned
[09:41] <asac> so that the unpack doesnt do the wrong thing
[09:41] <asac> i tested various upgrades and downgrades here, but nothing
[09:41] <huats> but after that I'll have a look at the debian experimental for sure...
[09:42] <seb128> asac: that doesn't rely on a -dev to be installed right?
[09:42] <asac> seb128: no. its really ugly i know. but thats where it comes from:
[09:42] <asac> we took package with soname version patch from debian:
[09:42] <asac> normal package has libnss3.so.1d
[09:43] <asac> and -dev has link libnss3.so -> libnss3.so.1d
[09:43] <lool> huats: The changes include autoreconf patches and changing PYTHON in a bunch of places
[09:43] <asac> then complains came that upstream binaries dont work here
[09:43] <huats> lool: ok
[09:43] <asac> debian and ubuntu moved the link to the "normal" package
[09:43] <huats> lool: so I will take right now the debian one
[09:44] <asac> then upstream complained the binaries built in ubuntu are not compatible with upstream nss
[09:44] <asac> i discussed this for a while and we found that the soname version was indeed senseless
[09:45] <asac> so we ended up in this link flip
[09:45] <asac> respin of all rdepends would fix this for sure
[09:45] <asac> (and we could drop the link)
[09:45] <asac> heh
[09:45] <seb128> asac: I see
[09:46] <asac> yeah but well.
[09:46] <asac> lets see what he answers
[09:48] <mvo> asac: just reproduce the failure here, stock intrepid->jaunty
[09:49] <asac> mvo: ok so when you upgrade from intrepid?
[09:49] <mvo> asac: yes
[09:50] <mvo> asac: it looks like dpkg is screweing up for some reason during the upgrade - the symlinks from the new package are not there
[09:50] <asac> mvo: yes i even looked at ldconfig output
[09:50] <mvo> asac: but when I manually install the same version again (dpkg -i /var/cache/apt ..) it works
[09:50] <asac> which is a bit scary in fact as ldconfig seems to remove links (so it could be)
[09:50] <asac> mvo: my current bet is that ldconfig is messing stuff up
[09:50] <mvo> asac: yeah, I suspect that its really ldconfig doing this
[09:51] <asac> however, i looked at the code and when it spits out the "is not a symbolic link"
[09:51] <asac> it sets no_remove=1
[09:51] <mvo> asac: I file a bug and target it for alpha-3?
[09:51] <asac> so the bug is 316452
[09:51] <mvo> asac: aha, thanks
[09:51] <asac> mvo: not sure if its the best to target for alpha-3
[09:52] <asac> i mean, I still dont understand where the issue happens
[09:52] <asac> (if its not the ldconfig thing)
[09:52] <mvo> asac: I can reprodcue it here reliably, I will poke it a bit
[09:53] <asac> mvo: how do you reproduce it post upgrade?
[09:54] <mvo> asac: I can not, I let the upgrade tester run, wait for the bug to appear and log into the system
[09:54] <asac> mvo: cool
[09:55] <asac> let me get the ldconfig code ... which definitly does link shuffline
[09:57] <mvo> bug #316452
[09:57] <asac> ok see you milestoned it ;)
[09:58] <asac> mvo: also nominating ;) woujld make this official?
[09:58] <mvo> asac: high or criticial (high should be enough, right?)
[09:58] <asac> high is gok
[09:58] <asac> ok
[09:58] <asac> mvo: so: /usr/lib/xulrunner-1.9.0.5/xulrunner-bin: ... output
[09:59] <asac> is already a consequence of the missing link
[09:59] <asac> thtas in xulrunner postinst
[09:59] <asac> it runs xulrunner-1.9 --version
[09:59] <asac> (probably a bad idea)
[10:00] <mvo> well, this way at least we know that its broken :)
[10:00] <asac> what i do in preinst of nss/nspr is to move the link and the old binary to a backup name
[10:00] <asac> and in cased upgrade fails move it back
[10:00] <asac> if it works remove the backup files in postinst
[10:00] <asac> could be that there is a bug too
[10:04] <asac> http://paste.ubuntu.com/104781/ ... thats ldconfig code
[10:05] <asac> the error is printed in line 465
[10:05] <asac> err 468
[10:06] <asac> and a "unlink" in 485
[10:06] <asac> but if the error happens do_remove = 0 ... so it shouldnt do the unlink
[10:08] <mvo> asac: I haven't looked at the code yet (ldconfig) but is it maybe doing something silly when e.g. trying to cleanup all existing symlinks that are releated to the lib?
[10:09] <asac> not sure ... i thought so, but i cannot se it ... at least not directly related to the error mesage
[10:09] <asac> but probably that message is a red herring
[10:16] <asac> mvo: how could it happen on upgrade from intrepid, but not from jaunty?
[10:16] <asac> well ... assuming that it doesnt happen when you come from jaunty
[10:16] <asac> as seb didnt see it; i didnt see it and fta didnt see it either
[10:17] <asac> probably not much a technical difference, right?
[10:17] <seb128> asac: you could ask this user if he upgraded jaunty or intrepid
[10:17] <asac> hmm
[10:17] <asac> Hello! I'm running an (almost) up-to-date Jaunty here.
[10:17] <mvo> asac: just more churn
[10:17] <asac> Earlier today I did an "aptitude safe-upgrade"
[10:18] <asac> thats what the initial reporter says
[10:18] <huats> lool: the current debian-svn is not fixing it
[10:18] <huats> I mean the one in experimental
[10:19] <huats> lool: I file a but on LP ?
[10:19] <huats> s/but/bug/
[10:19] <seb128> huats: do you want me to look at the issue?
[10:20] <asac> fta: can you fix pastebinit in universe ;)?
[10:20] <huats> seb128: sure
[10:20] <asac> fta: your package works fine now that i installed it. any reason that didnt go to universe?
[10:21] <mvo> asac: I just checked the preinst/postinst, that looks all right
[10:21] <asac> mvo: can you try to upgrade without the xulrunner-1.9 package installed? (so we can pin down that message as either the cause or the result)
[10:21] <asac> i guess its result
[10:21] <asac> but who knows if its the result-cause ;)
[10:21] <asac> due to some rollback
[10:22] <huats> seb128: just tell me if I can do anything...
[10:23] <seb128> huats: ok, I'll tell you if required
[10:23] <seb128> huats: you could try to debug it but apparently you already tried that ;-)
[10:24] <huats> seb128:  :)
[10:25] <lool> huats: Is there an autoreconf running during the build? (grep for recheck)  does pygobject have the issue?
[10:26] <huats> lool: let me check
[10:26] <lool> huats: pygobject has the same bug actually *sigh*
[10:26] <lool> Committed
[10:27] <huats> seb128: and lool : at the end of the build, the is that :
[10:27] <huats> dpkg-shlibdeps: warning: symbol Py_InitModule4 used by debian/python-gtk2-dbg/usr/lib/python-support/python-gtk2-dbg/python2.5/gtk-2.0/pangocairo_d.so found in none of the libraries.
[10:27] <huats> (and many others, but it is the missing symbol)
[10:27] <lool> That's ok in itself
[10:27] <seb128> huats: the symbol is the non debug one
[10:28] <asac> mvo: another idea would be to make ldconfig a no-opt script before upgrading ... but i guess its the new ldconfig which we would have to make a noopt
[10:28] <lool> I only get the issue in pygtk; not pygobject
[10:28] <seb128> it should be Py_InitModule4TraceRefs rather
[10:28] <lool> Now that doesn't mean pygobject is actually correctly built
[10:28] <seb128> lool:
[10:28] <seb128> $ python-dbg -c "import gobject"
[10:28] <seb128> [12115 refs]
[10:28] <seb128> I would say it is
[10:29] <lool> seb128: Consider that _glib.so or unix.so or _gio.so can do some different ABI calls
[10:31] <lool> seb128: Ok, I checked all of them it's fine
[10:31] <lool> And it's not for pygtk-dbg
[10:35] <huats> lool:  I don't find the autoreconf, but I might be wrong
[10:39] <lool> Ok, then no idea
[10:39] <mvo> asac: hm, right now (upgrade sitll running) I have libplc4.so.0d -> libplc4.so.0d.new-migration
[10:40] <asac> hmm
[10:40] <asac> thats not intended
[10:40] <mvo> and there is code in ldconfig
[10:40] <mvo> that remove stale symlinks
[10:41] <mvo> (everything with ".so." in them and and target for the link
[10:41] <mvo> asac: lets wait until ldconfig gets trigger here during the upgrade to confirm my theory
[10:42] <asac> i do mv /usr/lib/$f.0d /usr/lib/$f.0d.new-migration in preinst
[10:42] <asac> (nspr)
[10:42] <mvo> asac: most mysterious, a upgrade in a pbuilder chroot with just xulrunner-1.9 results in the correct behaviour
[10:44] <asac> too bad. the only intrepid setup i have here already has the new package :/
[10:44] <asac> ok. so lets think ;)
[10:45] <asac> when we start libplc4.so is a symlink to libplc4.so.0d .... now in preinst i mv libplc4.so libplc4.so.new-migration and libplc4.so.0d to libplc4.so.0d.new-migration
[10:45] <asac> i dont really see how we can end up with libplc4.so.0d -> libplc4.so.0d.new-migration
[10:46] <asac> so probably that link is already produced by ldconfig?
[10:51] <mvo> asac: I guess that makese sense
[10:51] <asac> mvo: so i probably have to move that link to mktemp -d?
[10:52] <asac> i mean instead of keeping it in a place where ldconfig finds the .new-migration file?
[10:53] <asac> mvo: or maybe chmod 000 ;)
[10:56] <mvo> asac: maybe mktemp, I can try that here
[10:56] <asac> mvo: oh i look at ldconfig
[10:56] <mvo> asac: or you give me a debdiff and I build the package
[10:56] <asac> if (((strncmp (direntry->d_name, "lib", 3) != 0
[10:56] <asac> 	    && strncmp (direntry->d_name, "ld-", 3) != 0)
[10:56] <asac> 	   || strstr (direntry->d_name, ".so") == NULL)
[10:56] <asac> so maybe we can just prefix it
[10:57] <asac> e.g. Xlibns
[10:57] <asac> let us try that
[10:58] <mvo> asac: ok
[10:59] <mvo> asac: the auto upgrade tester can test based on a local repo (or a PPA), if you push it to your jaunty PPA I can test the change
[11:11] <asac> mvo: ok uploaded to ~asac/+archive
[11:12] <asac> http://pastebin.com/f6f29dc1a
[11:12] <asac> http://pastebin.com/f6dc57bfe
[11:12] <asac> mvo: ^^
[11:12] <asac> thats what i did ;)
[11:15] <asac> https://edge.launchpad.net/~asac/+archive
[11:15] <asac> all builds waiting for cycles :/
[11:16] <asac> mvo: which arch are you testing (so i can give you heads up when stuff is there)
[11:16] <asac> i386?
[11:18] <seb128> huats, lool: ok, I found the pygtk dbg issue
[11:18] <huats> seb128: great !
[11:18] <mvo> asac: the auto upgrade tester can test based on a local repo (or a PPA), if you push it to your jaunty PPA I can test the change (not sure if you got that before I disconnected)
[11:19] <seb128> huats, lool: the patch on http://bugzilla.gnome.org/show_bug.cgi?id=556130 was in the intrepid version and has been dropped apparently
[11:19] <asac> mvo: i got that ;) but i talked to you afterwards ;)
[11:19] <mvo> asac: I did not get the stuff afterwards
[11:19] <asac> mvo: http://paste.ubuntu.com/104801/
[11:20] <mvo> asac: thanks. I test on i386
[11:20] <asac> mvo: i will let you know ;)
[11:20] <mvo> asac: I can build local package too if it take too long
[11:21] <mvo> but I need to deal with fglrx/nvidia upgrades too
[11:21] <asac> mvo: i think that would be better
[11:21] <mvo> ok
[11:21] <huats> seb128: pfff
[11:21] <asac> ppa takes about 30 minutes to make .debs available
[11:21] <asac> after the build has finished
[11:21] <huats> I misread the patch... I have looked at it, and thought it was a  + (not a -)....
[11:22] <huats> and I figure out it was included upstream
[11:22] <huats> I could have save you time :(
[11:22] <asac> mvo: can you take the patches from the pastebin or shall i poast them in pure form?
[11:23] <mvo> asac: I can take the .dsc from the ppa, no?
[11:23] <asac> mvo: if they are available yet, then yes
[11:23] <asac> mvo: otherwise its: http://people.ubuntu.com/~asac/tmp/nspr1.diff
[11:23] <asac> http://people.ubuntu.com/~asac/tmp/nss1.diff
[11:24] <mvo> asac: it seems to be publish already?
[11:24] <mvo> including the debs :)
[11:25] <mvo> eh, no. build, but not published yet
[11:26] <asac> mvo: after build has finished it takes 20-40 minutes to get published
[11:27] <asac> which is sad ;)
[11:27] <asac> before it took 20-40 minutes to start build, but close to zero publishing time
[11:27] <asac> now its zero time till build starts and 20-40 minutes afterwards ;)
[11:27] <asac> mvo: but well. maybe do something else
[11:27] <asac> you hav eprobably other stuff to do
[11:27] <asac> i currently feel positive that we have nailed this!
[11:28] <mvo> asac: thanks, I do the xorg stuff in the meantime
[11:45] <mvo> asac: the upgrade test with your ppa is now running, it will take ~30min to compelte, I think I go for lunch now
[11:46] <asac> ok ...
[11:46]  * asac crosses fingers
[11:46] <asac> mvo: enjoy. tausend dank!
[11:46] <mvo> asac: thanks :)
[11:50]  * asac really hopes that this is the last time he has to do something nasty like a lib-link-flip in /usr/lib/ ;)
[12:03] <mvo> asac: so far it looks *much* happerier (also not finished yet :)
[12:04] <mvo> asac: what does plds actually stands for?
[12:11] <asac> heh ... really good question
[12:12] <mvo> 93% done and still going strong *go jaunty go*
[12:13] <asac> hehe
[12:15] <asac> mvo: nspr netscape portable runtime ... so PL could stand for "portable library" ;)
[12:15] <asac> mvo: and the ds lib comes from the lib/ds/ tree ... might be something like "data structures" ;)
[12:15] <asac> so in a README i found: character prefix, "PL_" (Portable Library). Internal function names
[12:16] <asac> so first theory is true ;)
[12:17] <asac> so we have nsprpub/lib/ds and nsprpub/lib/libc ... matching plds and plc ;)
[12:23] <mvo> asac: worked fine, please upload
[12:25] <asac> thanks!
[12:32] <asac> mvo: ok uploaded. i replaced the prefix with something more sensible ... lets hope that my sed-fu is good enough ;)
[13:24] <huats> seb128: ok you fixed the bug :)
[13:25] <huats> thanks :)
[13:25] <seb128> huats: you're welcome ;-)
[13:26] <huats> seb128: so I return working on the deskbar update
[13:26] <seb128> good ;-)
[13:26] <huats> sorry deskbar-applet
[15:00] <hggdh> seb128, srag stated he forgot to update e-e Makefile.in to require 2.24.3
[15:01] <seb128> hggdh: right, that was expected, the question is rather the other way around
[15:02] <seb128> hggdh: why e-e 2.24.2 crashes evo 2.24.3
[15:02] <hggdh> seb128, heh. I am still sleeping, sorry
[15:02] <seb128> hggdh: no problem, I did update e-e to 2.24.3 today but it needs to get accepted now
[15:03] <seb128> still they broke binary compatibility in some way or e-e 2.24.2 should still be working
[15:03]  * hggdh agrres... I asked about that yesterday, but did not get a full answer
[15:03] <huats> seb128: I have put the deskbar-applet update on LP
[15:03] <seb128> huats: thanks
[15:03] <huats> I will look again at the xchat-gnome now
[15:04] <seb128> huats: that one should be easier ;-)
[15:04] <huats> (but the last time I checked there was something weird...)
[15:04] <huats> not sure :)
[15:05] <huats> seb128: I will start to think that didrocks asked you to give me some updates with issues ;)
[15:05] <seb128> ah ah
[15:15] <hggdh> seb128, correct dependency is on e-d-s 2.24.3
[15:15] <hggdh> so ABI did change
[15:15] <seb128> in a stable version update...
[15:29] <didrocks> (seb128: don't tell him, please) :)
[15:30] <seb128> didrocks: ok I won't ;-)
[15:30] <didrocks> hehe
[15:32]  * didrocks is eager to have an update with an ABI break to have a look at librairies issues :p
[15:49] <seb128> didrocks: want some challenges? I've some tricky updates on my list ;-)
[15:49] <seb128> one of those being called GTK 2.15 ;-)
[15:50]  * seb128 kicks directfb
[15:58] <didrocks> seb128: hum, GTK 2.15, seems fun :)
[15:59] <didrocks> seb128: I won't be able to do them tonight (my company "celebration"), but tomorrow, why not having a deep look
[15:59] <didrocks> after having played with gnome-games :)
[15:59] <seb128> didrocks: do gnome-games it's already non trivial, they started using clutter apparently
[16:00] <dobey> i thought the clutter dep was optional though?
[16:00] <dobey> seb128: there's a game that uses seed now as well
[16:00] <seb128> could be, I didn't try
[16:06] <crevette> didrocks, do you mean you work on ubuntu at work !!!!
[16:06]  * crevette calls didrocks' boss
[16:07] <seb128> lol
[16:07] <seb128> crevette: no, that's huats ;-)
[16:07] <didrocks> seb128: thanks I will enjoy gnome-games so \o/
[16:08] <didrocks> crevette: and no. I am really working now. You have to call huats' one :)
[16:13] <huats> :)
[16:14] <anakron> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/315156
[16:14] <anakron> hi all
[16:14] <anakron> someone can say me if is rith to take it out or not
[17:02] <crevette> mvo, hello
[17:03] <crevette> mvo, I updated my metacity branch to update changelog with the one dholbach uploaded, perhaps you're interested to pick it up ?
[17:04] <mvo> crevette: yes, thanks
[17:05] <mvo> crevette: he was quicker than me with the sponsoring
[17:05] <crevette> :)
[17:05] <mvo> crevette: what is the branch name again?
[17:05] <crevette> ah sorry
[17:06] <crevette> lp:~bmillemathias/metacity/ubuntu
[17:07] <mvo> crevette: thanks, merged
[17:07] <crevette> mvo, thanks
[17:08] <crevette> mvo, I have a dumb question, is it possible to have apt-get pick up latest revision when we get apt-get source metacity for instance and update debian/
[17:08] <crevette> I don't know if it have so sense or not
[17:09] <crevette> s/it have so sense/it has some sense/
[17:10] <cj> maybe svn-buildpackage will help?
[17:10] <mvo> crevette: that was discussed in the past, if there is a vcs-bzr header, just use lp to get it
[17:10] <mvo> I think its a good idea
[17:10] <mvo> it just needs to get implemented :) (should not be too hard though)
[17:11] <crevette> mvo, so actually the line "Vcs-Bzr: http://code.launchpad.net/~ubuntu-core-dev/metacity/ubuntu" in control.in is not used at the time bieng
[17:11] <crevette> except to print a message
[17:16] <mvo> crevette: yes, just as a guide for the package maintainers, not to get the latest source
[17:26] <jcastro> anyone finding the new volume control stuff frustrating?
[17:29]  * cj <3 lvm
[17:29] <cj> oh, you mean audio volume, don't you?
[17:30] <pochu> crevette: I think you can use `debcheckout $package` to get the source from the Vcs-* header
[17:34] <cj> debcheckout is in devscripts
[17:35] <crevette> pochu, I need to run that in the package source ?
[17:36] <crevette> seems rather simple :)
[17:36] <pochu> crevette: not necessarily, you can run it anywhere :)
[17:37] <crevette> yeah but I think this is more convenient
[17:37] <crevette> :)
[22:10] <tretle> macslow?
[22:26] <MacSlow> tretle, what's up?
[22:26] <tretle> hey
[22:26] <tretle> long time no blog :D lol
[22:27] <tretle> Yeah, I was wondering whether you could tell me whether any work has been done on the gdm side to implement clutter ui support?
[22:27] <MacSlow> tretle, some ... but not fully done
[22:28] <MacSlow> first thing is to put gdm 2.24.x in
[22:29] <tretle> is that not in jaunty yet?
[22:31] <tretle> also was your work on sparkle done in pigment, I was thinking of reusing some of the widgets to create a globe for the ubuntu live cd installer time zone selection.
[22:31] <MacSlow> tretle, gdm 2.24.x is planned for jaunty afaik
[22:31] <MacSlow> tretle, no ... sparkle is all plain OpenGL
[22:32] <tretle> ah nice
[22:32] <tretle> :D
[22:33] <tretle> so after gdm gets pushed into jaunty what pieces to the puzzel will be missing to integrate a clutter based ui?
[22:36] <tretle> hmmm.... seems 2.20.8 is currently being used in jaunty
[22:37] <cj> MacSlow: are you that slow guy from linpeople?
[22:41] <tretle> ?
[22:42] <MacSlow> cj, no idea
[22:42] <MacSlow> tretle, a new greeter
[22:44] <tretle> so the new greater hasnt been started yet? is there any blueprints up or project page that I could keep up to date with?
[22:44] <MacSlow> there's one on wiki.ubuntu.com
[22:45] <MacSlow> tretle, https://wiki.ubuntu.com/DesktopTeam/Specs/GdmFaceBrowser
[22:47] <tretle> how much work will need to be done on creating a new greater?
[22:48] <MacSlow> tretle, lots
[22:50] <tretle> would it be the gdm guys working on it or you?
[22:53] <cj> MacSlow: if you haven't been on 'freenode' since before '96 then it's probably not you :)
[22:57] <MacSlow> cj, hm I've been called MacSlow for as long as I can remember
[22:57] <MacSlow> '96 could be
[22:58] <cj> MacSlow: your name sounds familiar :)
[22:59] <cj> http://web.archive.org/web/19961109144913/http://www.linpeople.org/
[23:33] <cody-somerville> Hardy's gnome-icon-themes no longer builds from source in Hardy
[23:33] <cody-somerville> icon-naming-utils (>= 0.8.7) but it is not installable
[23:34] <cody-somerville> Hardy only has 0.8.6
[23:34] <cody-somerville> How it ever got compiled is a mystery to me
[23:40] <cody-somerville> checking for intltool >= 0.40.0... 0.37.1 found
[23:40] <cody-somerville> wtf
[23:46] <cody-somerville> I'm a moron :P
[23:46] <cody-somerville> nvm :)
[23:46]  * cody-somerville was trying to compile the intrepid version under hardy.
[23:59] <cj> haha