[00:00] <RAOF> tjaalton: I'm _fairly_ sure that I don't have to bump shlibs on libdrm-nouveau1, and that the symbols file supercedes that.  Building the DDX against the un-bumped libdrm-nouveau1 picks up a correct versioned dependency of 2.4.11-0ubuntu2, which is what's in the symbols file.
[00:01] <RAOF> Hm.  FSVO "correct" :)
[00:02] <tjaalton> RAOF: don't add the packaging version to the shlibs
[00:02] <tjaalton> hmm
[00:02] <RAOF> But the symbols were added in that Ubuntu revision; they're _not_ in 2.4.11
[00:02] <tjaalton> right
[00:02] <tjaalton> scratch that
[00:14] <RAOF> Ok.  How do I change my committer name & email in git?
[00:36] <RAOF> So, the ubuntu branch in libdrm should be good to go.
[00:58] <Sarvatt> hmm anyone know if radeon HD3300 IGP is supported by fglrx?
[01:03] <Sarvatt> sweet, pciid 9614 so it is
[01:09] <Sarvatt> anyone have a fglrx supported system that could test if this patch works for 2.6.31 support for fglrx-installer? http://sarvatt.com/downloads/900_fglrx_31_compat.patch.txt
[01:09] <Sarvatt> my only ati is a powerpc
[01:10] <Sarvatt> regarding https://bugs.edge.launchpad.net/bugs/394985
[01:10] <ubottu> Ubuntu bug 394985 in fglrx-installer "fglrx: Unknown symbol find_task_by_vpid" [High,Confirmed]
[01:50] <Sarvatt> go figure, xserver 1.6.2 right after i go and make the livecd :D
[01:52] <Sarvatt> ah it wont build today anyway -- i386      456 builds waiting in queue 
[08:27] <tjaalton> RAOF: right, according to the dpkg-shlibdeps manpage, it'll look up the symbols file first if it exists, so just having it should be enough
[09:00] <RAOF> tjaalton: That is the behaviour I saw in my tests, yes.
[09:37] <jcristau> RAOF: git config --global user.name 'foo bar'; git config --global user.email foo.bar@example.com
[10:04] <RAOF> Ta
[10:32] <Ng> hrm, is xserver-xorg-input-synaptics not in the default install?
[10:34] <jcristau> Ng: see scrollback
[10:36] <Ng> ah
[10:36] <Ng> I thought I'd gotten lucky and bought a laptop with an unsupported touchpad
[10:36] <Ng> now I have to go and disable it in the bios ;)
[10:39] <Ng> ahh fantastic, disabling the touchpad via gnome doesn't break the trackpoint's mouse buttons like it used to \o/
[10:41] <popey> hah, never knew there was such an option
[10:41] <popey> just unticked 'Enable touchpad' then realised i didnt have a mouse
[10:41] <popey> spacebar to the rescue
[10:45] <Ng> hehe
[10:46] <Ng> it should really say "erm, I can only see one input device, are you *really* sure?"
[11:54] <levonshe> hello all,  Please help me with the next problem :CHROME(0): [dri] DRIScreenInit failed. I have VIX VX800 graphic card, I see in  dmesg that drm module is loaded succesfully, but /dev/dri/card0 is not created, why ??? ([drm] Initialized drm 1.1.0 20060810), 
[12:02] <tjaalton> levonshe: because the drm module is crap, like I said
[12:02] <tjaalton> and probably doesn't support your card
[12:16] <levonshe> tjaalton, since I do not know much about acceleration, you mean this graphic card does can not do direct rendering, so xvmc is not possible ??
[12:32] <tjaalton> levonshe: what's the pci-id of the card?
[12:34] <tjaalton> levonshe: lspci -nn | grep VGA
[12:36] <tjaalton> I guess it's 1106:1122, in which case it's not supported
[12:37] <tjaalton> and it's a chrome9 chip
[13:50] <levonshe> tjaalton, you was right, it is indeed 1106:1122. Do you have any info if this board is going to be supported in the near future, other chrome9 boards have atleast 2D acceleration?
[14:02] <tjaalton> levonshe: probably not even in 9.10
[14:06] <tjaalton> but AIUI the newttm is now merged in 2.6.31 and that should make it easier to push the new driver upstream
=== crevette__ is now known as crevette
[16:36]  * hyperair grumbles about compiz eating up 2G of GEM memory *instantly* upon startup
[16:36] <hyperair> wtf happened?!
[16:40]  * hyperair pokes Sarvatt 
[16:58] <hyperair> hmmm not mesa, not drm
[16:58] <hyperair> must be xorg-server
[17:07] <hyperair> aha it is xorg-server
[17:53] <tormod> wow, google chrome OS. wow. are they gonna use X on it?
[17:54] <tormod> Steve B must be throwing a lot of chairs today
[17:59] <Sarvatt> http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.6-branch&id=c859b736d1d23c5dc2f53958b1e76660e6d45018
[17:59] <Sarvatt> hmm
[17:59] <Sarvatt> intel not building because of that commit
[18:00] <Sarvatt> http://launchpadlibrarian.net/28792374/buildlog_ubuntu-karmic-i386.xserver-xorg-video-intel_2%3A2.7.99.901%2Bgit20090708.0402f4f3-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
[18:10] <Sarvatt> what a headache to wake up to :D
[18:16] <Sarvatt> hyperair: downgrade xserver if you can
[18:16] <tjaalton> they all should fail to build
[18:27] <Sarvatt> i'm stumped unless i go and revert that commit from xserver
[18:34] <jcristau> i suspect there'll be an 1.6.3 soon :)
[18:40] <Sarvatt> ahhh i should have read the chat log for #xorg-devel, looks like you guys were talking about it already
[18:44] <Sarvatt> yeah i'll revert it for now, then wait the 12 hours for it to build and reupload intel and ati and it'll probably be fixed in server1.6 branch by then. wish you could turn off PPAs so people dont download broken stuff :D
[18:59] <jbarnes> Sarvatt: what did I miss?  the memory eating bug?
[19:01] <Sarvatt> intel ddx not building against xserver 1.6.2 and things being broken using intel compiled against 1.6.1.902, dont upgrade edgers stuff yet if you havent today :D
[19:02] <jbarnes> too late :)
[19:02] <Sarvatt> uploaded the fix for xserver so intel will build but theres a 12 hour queue on launchpad
[19:03]  * Ng wonders why i386 is so backed up
[19:03] <Sarvatt> oh crap
[19:03] <Sarvatt> its 2 pm
[19:03] <Ng> I know a lot of the PPA buildds dropped out in the last couple of days, but that's surprisingly unbalanced
[19:03] <Sarvatt> mozilla/chromium build bots beat me
[19:03] <Sarvatt> so maybe closer to 24 hours
[19:04] <Sarvatt> https://edge.launchpad.net/builders/
[19:04] <Sarvatt> its because theres like 1/4 the normal amount of builders
[19:05] <Ng> yeah they come and go as the hardware is used eleswhere, it just seems odd that i386 is significantly more behind than amd64
[19:05] <Ng> but it could juts be that the i386 hardware pool was depleted more significantly
[19:06] <Sarvatt> it probably got stuck compiling gcc's or something that takes a long time like that, or theres a large amount of generic arch builds queued up since those build on i386 (just guessing here)
[19:07] <Sarvatt> i dont get how amd64's queue got so low with only 3 builders now that you mention it
[19:07] <tjaalton> Ng: aren't you tending those :)
[19:08] <Ng> tjaalton: we're nominally responsible, but the hardware is shared, so if the other users need it there's nothing we can do about it :)
[19:08] <Sarvatt> [Disabled] 	thorium 	AUTO 	(113, 'No route to host')  ?
[19:08] <Sarvatt> thats a new one
[19:09] <tjaalton> Ng: ah, ok :)
[19:09] <Ng> Sarvatt: that happens a fair bit, it means that buildd has been reclaimed for something else and isn't routable on the PPA network anymore
[19:09] <Ng> Sarvatt: oh good point, the arch:all stuff builds on i386 afair
[19:12] <Sarvatt> hopefully its just that there are a ton of things from the translations ppa or that keyring PPA in the queue that'll go by fast or something
[19:52] <Sarvatt> http://lists.x.org/archives/xorg-devel/2009-July/001338.html
[20:01] <bryce> heya
[20:17] <Sarvatt> heyo bryce
[22:00] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/metacity/+bug/389686
[22:00] <ubottu> Ubuntu bug 389686 in metacity "compiz --replace fails to kill metacity, resulting in cpu overload" [High,Triaged]
[22:00]  * Sarvatt cheers
[22:09] <Sarvatt> wow chromium alone takes 1.5 hours per build and is building 12 times? theres only 12 builders, no wonder
[22:27] <superm1> why does it build 12 times?
[22:50] <Sarvatt> 4 seperate distros, 3 arches per distro
[22:58] <superm1> oh yeah trying to build for all supported ubuntu releases; makes sense
[22:58] <superm1> i think it's silly that lpia is still on the PPAs for karmic+
[22:59] <superm1> would much rather see that turned into another couple i386 builders
[22:59] <superm1> oh Sarvatt, regarding that fglrx patch you posted, I highly doubt that would work.  pid is not an integer in pid_task, but a struct
[22:59] <superm1> it might compile an load, but that code path would be broke
[23:50] <Ng> superm1: why is it silly for lpia to be there? it's a supported arch
[23:52] <bryce> jbarnes, hey btw did anyone get to porting the pci quirks over to the kernel?
[23:53] <jbarnes> bryce: some of the quirks are ported
[23:53] <jbarnes> edid and some of the tv & lvds stuff afaik
[23:53] <jbarnes> though our tv detection is better in the kernel I think
[23:53] <bryce> ok