[10:30] <lesshaste> hi all
[10:32] <lesshaste>  hi.. I have a firefox problem where it freezes when uploading files... The strace at http://pastebin.com/f118d9b2e seems to actually imply it's an X server problem as firefox is waiting for something from the server which never arrives. the important part starts at line 1770
[10:39] <tjaalton> lesshaste: do you have /tmp/.X11-unix/X0 or not?
[10:40] <lesshaste> ls -lat /tmp/.X11-unix/X0
[10:40] <lesshaste> srwxrwxrwx 1 root root 0 2009-09-16 08:38 /tmp/.X11-unix/X0
[10:40] <lesshaste> tjaalton: sorry that was meant for you
[10:41] <tseliot> tjaalton: did you investigate what pitti reported about vmmouse?
[10:41] <tjaalton> tseliot: yes, the fix was in git but never uploaded
[10:42] <tseliot> tjaalton: ah, ok. So we shall wait until the freeze is over
[10:42] <tjaalton> lesshaste: ok. can't tell why it fails then
[10:42] <tjaalton> tseliot: yes
[10:42] <tseliot> ok, thanks
[10:43] <lesshaste> tjaalton: disabling all extensions fixed it!
[10:43] <lesshaste> all add-ons I mean
[10:59] <lesshaste> the problem is either the adblock plus or flashblock it seems
[13:43] <loic-m> tjaalton: hi
[13:43] <loic-m> tjaalton: is linuxwacom 0.8.4.1 (stable) definitely off for Karmic?
[13:50] <tjaalton> loic-m: no, been on my todo-list for a while
[13:51] <loic-m> tjaalton: ok, thanks. I can't get my tablt configured in Karmic ;)
[13:51] <loic-m> I had another look at the Debian packaging no I've a bit more experience, and it looks messy
[13:52] <loic-m> Doesn't that causes troubles when upgrading?
[13:52] <tjaalton> yes
[13:53] <tjaalton> upstream is going to fix their release model soonish
[13:53] <tjaalton> and put the driver in git.fd.o
[13:53] <tjaalton> that'll be a day to celebrate
[13:53] <loic-m> Indeed... Did they discuss that on the -devel list?
[13:54] <tjaalton> only briefly
[13:54] <tjaalton> but now there seems to be http://cgit.freedesktop.org/~whot/xf86-input-wacom/
[13:54] <tjaalton> whot is cleaning up the driver
[13:55] <jcristau> whot is awesome :)
[13:55] <tjaalton> yeah, he's like all over the place :)
[13:55] <tseliot> superm1: I uploaded nv to my PPA (I had to sign the source though)
[13:56]  * tseliot would like to see wacom use xinput
[13:57] <tjaalton> it's going to
[13:57] <tseliot> http://cgit.freedesktop.org/~whot/xf86-input-wacom/commit/?id=2e01d5b83ae710c4dccfb5d79c7154c38419b9f3
[13:57] <tseliot> \o/
[13:57] <loic-m> Didn't realise whot=Peter Hutterer
[13:57] <loic-m> yes, sounds awesome
[13:58] <loic-m> What was the problem with lw release tarballs?
[13:59] <tjaalton> the are just that, blobs, and no way to cherry pick newer changes
[14:00] <tjaalton> at least I couldn't make git-svn to work
[14:02] <loic-m> My difficulty is more that the current packaging isn't transparent - i.e. no doc about what was done for the repack, and inline patches even though there's a patch system
[14:05] <tjaalton> because the build system is a mess
[14:05] <tjaalton> ie. the packaging
[14:10] <loic-m> Makes the netry barrier level a tad high
[14:11] <tjaalton> that'll get fixed when the upstream packaging is like the rest of the drivers
[14:11] <loic-m> Is there a good way to learn about drivers packaging?
[14:12] <tjaalton> existing packages I guess
[14:12] <jcristau> it's pretty basic autotools, plus some magic to make sure we get the right abi provides and depends
[14:13] <loic-m> is there differences with applications packaging?
[14:28] <JontheEchidna> I have a bug I need to report, and was wondering if it should be filed against libdrm or xserver-xorg-video-intel. Basically, DRM fails to load and X is forced to resort to the software rasterizer: http://paste.ubuntu.com/272111/
[14:28] <JontheEchidna> This happens on an alpha 5 livecd, too
[14:29] <JontheEchidna> xserver-xorg-video-intel makes performance a bit better, but it still is using the software rasterizer :(
[14:29] <JontheEchidna> *xserver-xorg-video-intel from xorg-edges
[15:01] <tjaalton> loic-m: got a driver for you to test..
[15:01] <loic-m> tjaalton: thanks
[15:02] <tjaalton> 32 or 64bit?
[15:02] <loic-m> 32 please
[15:03] <tjaalton> loic-m: http://users.tkk.fi/~tjaalton/foo/xserver-xorg-input-wacom_0.8.4.1-0ubuntu1_i386.deb
[15:06] <loic-m> tjaalton: no need to test wacom-tools too?
[15:06] <tjaalton> http://users.tkk.fi/~tjaalton/foo/wacom-tools_0.8.4.1-0ubuntu1_i386.deb
[15:07] <loic-m> tjaalton: thanks
[15:23] <loic-m> bbl
[16:25] <loic-m> tjaalton: your 0.8.4.1 wacom packages work well with my Intuos3 6x8. Input-hotplug, pressure in Gimp, and setting the properties with xsetwacom for the pad
[16:26] <loic-m> Inkscape draws completely off base, but that's AFAIK a known bug, also in Jaunty
[16:27] <loic-m> The provided .fdi still doesn't work with wacomcpl, but that was the same in Jaunty too
[16:28] <loic-m> The Cintiq is another story, will probably take longer to set up till I can really say I tested it, because of the dualscreen configuration
[18:27] <tjaalton> loic-m: ok, nice to hear
[18:28] <loic-m> indeed ;)
[18:31] <tjaalton> could you reply to bug 405800, it would help getting it ack'ed
[18:40] <loic-m> Sorry, was away. I'll do that right now
[18:43] <tjaalton> thanks
[18:46] <loic-m> Done,  tell me if you need anything else.
[20:53] <Ng> so with gnome screensaver not quite working on suspend atm, I'm reminded just how beautifully fast X gets video back up after resume :)
[20:53] <Ng> the wrinkle being that input devices
[20:53] <Ng>  take several seconds. I seem to remember someone saying that fedora had some kind of patch for that
[20:56] <Ng> (also from a simple usability/polish point of view I wonder if the fadeout of gnome-screensaver should happen *way* faster so suspend happens almost as fast as it's happening atm
[20:56] <Ng> afaict the fade is about 1s long atm, which subjectively seems like the longest part of the suspend process ;)
[21:03] <jcristau> heh, the suspend process starts when i close the lid, and finishes right about when the laptop is in its bag :)
[21:03] <cdE|Woozy> does the suspend process really wait for gnome-screensaver to finish fading out?
[21:10] <Ng> cdE|Woozy: I was poking at the gnome-session source earlier and it seems that when it wants to blan kthe screen it shells out to gnome-screensaver-command, which afaict doesn't return until the activate/lock has finished fading
[21:10] <Ng> (see "time gnome-screensaver-command --activate")
[21:11] <Ng> I kinda assumed it would be dbus magic, and I can well understand that you wouldn't want the actual suspend to happen mid-fade