[00:35] <Sarvatt> how about uh.. http://sarvatt.com/downloads/patches/0001-Add-Gallium-support-via-an-xorg.conf-option-enabled-.patch
[00:37] <RAOF> Looks like it'll work, although it won't fall back, will it?
[00:42] <Sarvatt> yeah really stumped on the fallback, it'll fallback to swrast though I think? wish i had one to test all this junk out :)
[00:42] <RAOF> Heh.
[00:44] <RAOF> In RADEONPreInit_kms you could simply stat() /usr/lib/dri/radeong_dri.so, right?
[00:44] <RAOF> If it doesn't exist, set useGallium to false.
[02:19] <bjsnider> people are sending me angry emails asking why the lucid nvidia updates have to be in the x-updates ppa
[02:23] <RAOF> Do they offer to field any angry emails we get when nvidia updates in the main repositories break for users? :)
[02:24] <Sarvatt> bjsnider: what lucid nvidia updates?
[02:25] <bjsnider> drivers
[02:25] <Sarvatt> the newest released driver is in lucid already I thought?
[02:25] <bjsnider> no, the 256 line
[02:25] <Sarvatt> non-beta
[02:25] <bjsnider> they want the sexy 256 line
[02:25] <bjsnider> RAOF, no, they mean in that ppa and not my ppa
[02:26] <bjsnider> you pretty much have to run dozens of ppas if you want cutting edge stuff these days
[02:26] <bjsnider> there isn't one ppa you can go to for every little thing is what i've been telling them
[02:27] <Sarvatt> wow only 6 patches didn't apply to xorg-server_1.8.99.0+git20100606.f03be727-0ubuntu0sarvatt.
[02:28] <Sarvatt> was expecting it to be more like 29
[02:28] <Sarvatt> err 20
[02:38] <RAOF> ARGH!  The back button is not your friend when editing bugs.
[02:42] <Sarvatt> checking host system type... Invalid configuration `technical': machine `technical' not recognized
[02:42] <Sarvatt> kay!
[02:44] <Sarvatt> doesn't like bryce's change :)
[02:52] <RAOF> Oh, that's no fun at all.  It looks like a guest user can bring down my system.
[02:54] <Sarvatt> yeah bryce's change doesn't work even on the straight ubuntu branch
[02:55] <Sarvatt> configure: WARNING: you should use --build, --host, --target
[02:55] <Sarvatt> configure: WARNING: invalid host type: http://www.ubuntu.com/support)
[02:56] <RAOF> There probably needs to be some quoting.  I'll look at it.
[03:01] <Sarvatt> its just too much quoting
[03:01] <Sarvatt> --with-builderstring="xorg-server 2:1.8.1.901-1ubuntu1 ("For technical support please see http://www.ubuntu.com/support")"
[03:04] <bryceh> sheesh
[03:08] <RAOF> Yeah, just unquoting fixes that.
[03:09] <bryceh> right, let me push an updated commit
[03:10] <bryceh> hmm, git's refusing to let me push
[03:10] <bryceh> probably quite wise of it
[03:10] <RAOF> There are probably changes up there.
[03:11] <Sarvatt> lol i was editing it in one tree and test building changes in another, doh
[03:13] <Sarvatt> i bet googling for bryce brings up hundreds of pastebins now :)
[03:14] <bryceh> :-/
[03:18] <bryceh> I literally just got scolded by my wife for working on the weekend ;-)
[03:19] <Sarvatt> doh sorry bryce! we coulda fixed that, i was referring to you as bryce so it wouldn't ping you :)
[03:21] <RAOF> It's got to be pretty late for you there too, right?  Go have some fun!
[03:21] <bryceh> it's only 7:20pm
[03:22] <bryceh> been out in the shop most of the day
[03:23]  * RAOF understands “shop” to be short for “workshop” aka shed.
[03:23] <bryceh> yep
[03:24] <bryceh> technically it's part of my garage
[03:25] <RAOF> Cool.  I managed to prune half a rosebush inbetween showers last weekend.  It's now somewhat less totally, unnecessarily huge and convoluted.
[03:27] <bryceh> pushed
[03:27] <bryceh> I was out there to paint some shelves for my game closet, but ended up starting a medium sized reorganization project
[03:29] <Amaranth> Sarvatt: If we get compiz 0.9 we won't need any max texture size checks
[03:30] <RAOF> Amaranth: Is that magical future compiz _likely_ to be in Maverick?
[03:30] <Amaranth> RAOF: They've put out a call for testing, it should be feature complete at this point
[03:33] <Amaranth> RAOF: I was working on packaging it but seb128 says we need to get the package back to syncing from Debian or small changes from Debian
[03:34] <RAOF> Seems reasonable.
[03:34] <Amaranth> But Debian still has compiz-gtk, a completely nonsensical package as it depends on most of GNOME
[03:34] <Sarvatt> is this really the cycle to do that with things being held up by squeeze?
[03:35] <Amaranth> And we'll waste a bunch of time trying to coordinate on the new naming and packaging scheme considering there is no compiz-fusion anymore
[03:35] <Amaranth> Sarvatt: He was willing to stick to just keeping the plugins packaged synced from Debian but that is the part most likely to need a major change (get rid of the fusion name)
[03:36] <Amaranth> I was trying to coordinate on at least naming with the person I think is the Debian maintainer (he was going to be working on 0.9 packages for testing, anyway)
[03:36] <Amaranth> But I haven't heard from him in a few weeks
[03:41] <Sarvatt> i guess we'll be on this same old 0.8.4 thats already over 8 months old in MM then? :D
[03:41] <Amaranth> Sarvatt: possibly
[03:42] <Sarvatt> i tried packaging the new one up but man I hate cmake
[03:42] <Amaranth> I don't have much interest in working on 0.9 packages if the debian maintainer is eventually going to be his own set and we need to use his
[03:42] <Sarvatt> couldn't find any good examples of other things using cmake
[03:42] <Amaranth> https://code.edge.launchpad.net/~amaranth/compiz/0.9 https://code.edge.launchpad.net/~amaranth/libcompizconfig/0.9
[03:42] <Amaranth> here have some packages :)
[03:43] <Sarvatt> \o/
[03:44] <Amaranth> Sarvatt: I stopped there because I went to ask seb128 if I could use multiple tarball support to roll the plugins-main and plugins-extra sets in to the compiz package so we could easily split the plugins in to what we use and what we don't
[03:45] <Amaranth> Without a gst-plugins-bad, gst-plugins-bad-multiverse, etc kind of split
[03:51] <Sarvatt> who did you contact about it?
[03:54] <Amaranth> Sarvatt: sean finney
[03:59] <Sarvatt> nice, you got bzr-builddeb set up for it too??
[04:01] <Sarvatt> i'm not really sure what all the move to .9 entails package renaming wise, maybe you could send an email to debian-x with the problems since it looks like its on life support at the moment in debian?
[04:03] <Sarvatt> like is it just transitioning the plugins to compiz-plugins-foo instead of compiz-fusion-plugins-foo?
[04:03] <Sarvatt> i know the whole build system got an overhaul
[04:05] <Amaranth> Sarvatt: Yeah, and rewriting the rules file for the build system
[04:05] <Amaranth> Sarvatt: But sean was interested in doing the plugins as a part of compiz as well but using git submodules for some reason
[04:05] <Amaranth> Sarvatt: So we'd really need to nail that down
[04:06] <Sarvatt> no bzr-builddeb if you do that :(
[04:06] <Amaranth> eh
[04:06] <Amaranth> I can't use it so long as I'm doing git snapshots anyway
[04:06] <Amaranth> brb, reboot
[04:07] <Amaranth> well, if I can get it to give me the option...
[04:07] <RAOF> You could totally use it for git snapshots; just install bzr-git and pull as normal.
[04:08] <Amaranth> I don't use put the source in bzr
[04:08] <Sarvatt> or a get-orig-source target?
[06:04] <RAOF> Sarvatt: Were you merging xserver-xorg-video-nv?
[06:05] <Sarvatt> i think mvo was? we could just sync it, just one fedora patch that wasnt a bugfix
[06:07] <RAOF> And the crazy probe logic.
[06:25] <Sarvatt> yeah even superm1 agreed that should be dropped though
[07:09] <Sarvatt> xserver master actually turned my machine off for me, how thoughtful! :D
[07:10] <Sarvatt> just trying it out because it looks like the last of the abi breaks went in earlier so it'll probably branch soon
[07:13] <RAOF> Sarvatt: That was really X, and wasn't the kernel doing it's panic→shutdown dance?
[07:19] <Sarvatt> i did a startx, launched gnome-terminal and it was all white, and 10 seconds later my machine was completely off :)
[07:20] <Sarvatt> time to grab a core dump to play with
[07:21] <RAOF> I wonder if launchpad will accept my 255MiB vmcore this time…
[07:21] <Sarvatt> aren't you an aussie?? thats like 1/10th your monthly bandwidth limit!
[07:22] <RAOF> Uploads don't count.
[07:24] <Sarvatt> weird the selinux stuff is showing up in the log now, it wasn't like a week ago - http://sarvatt.com/downloads/xorg.txt
[07:24] <RAOF> At least on my ISP, as long as you don't have fiber.
[07:27] <RAOF> So, watcom.  Where are we at there?
[07:27] <RAOF> Is anyone currently merging it?
[07:28] <Sarvatt> thats the one i'm worried about
[07:28] <RAOF> Difficult merge?
[07:28] <RAOF> Also, no hardware to test?
[07:28] <Sarvatt> not sure what all these ubuntu changes were, we kind of forked it..
[07:29] <RAOF> Bah.
[07:29] <Sarvatt> do we have the history in bzr?
[07:29] <Sarvatt> somewhere
[07:29] <Sarvatt> i've been meaning to look for that, the changelog doesn't help much
[07:30] <Sarvatt> if you do upload it remember to autoreconf, lol
[07:30] <Sarvatt> been hit by that so many times
[07:30] <RAOF> It doesn't autoreconf during build?
[07:30] <Sarvatt> nope
[07:31] <RAOF> Well, that's silly.
[07:32] <RAOF> Hm.  When it's cold I kind of wish this x200s had a touchpad as well as a nub.
[07:34] <Sarvatt> tjaalton was going to put it on pkg-xorg and redo the packaging some but he disappeared, think he's in the last few weeks of college now
[07:34] <Sarvatt> https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/maverick/xf86-input-wacom/maverick yay found it
[07:35] <RAOF> Yup.  lp:ubuntu/xf86-input-wacom
[07:35] <RAOF> Only 9 revisions, though.
[07:36] <Sarvatt> i dont think any of this applies if we sync..
[07:37] <Sarvatt> still looking though
[07:38] <Sarvatt> hmm bryce brought in xsfbs to it
[07:38] <Sarvatt> so just the n-trig patch, i doubt thats upstream but have to check
[07:42] <RAOF> Hm.  That may well be upstream.
[07:47] <Sarvatt> its not and it doesn't apply anymore
[07:47] <Sarvatt> http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=blob;f=src/wcmUSB.c;h=249a7bfb3e96454df82b0ca9e67cfdcb5e7aefa4;hb=HEAD
[07:48] <Sarvatt> and http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/xf86-input-wacom/maverick/revision/5#debian/patches/100_ntrig_2010_02_03.patch
[07:48] <Sarvatt> doesn't look hard to refresh, they just made it more generic for waltop tablets
[07:50] <Sarvatt> hmm does it work without the patch now even?
[07:50] <Sarvatt> looks like it does
[07:51] <Sarvatt> except it doesn't get those custom dimensions 
[07:52] <Sarvatt> defaults to 1016x1016 for unknown devices and that patch was setting it to 1122,  934 if i'm not mistaken, but could do that in a snippet.. i think bryce has one of the devices, gotta bug him tomorrow :)
[07:53] <RAOF> :)
[07:56] <RAOF> Yes, he does.  I saw it at UDS.
[07:56] <RAOF> It's pretty fun.
[07:59] <Sarvatt> darn, was going to suggest a git checkout but it requires util-macros 1.8 now which isnt released in debian :)
[10:05] <seb128> hi there
[10:06] <seb128> is there known issue with the matrox videocards on lucid?
[10:06] <seb128> seems that we received quite some bugs from users getting invisble gnome-panel when compiz is on
[10:14] <jcristau> the mga drivers are abandoned, and nobody tests them, so i wouldn't be surprised.
[10:14] <jcristau> (well other than server stuff where you don't want to run compiz anyway)
[10:16] <seb128> do you think it's worth trying to get those fixed or should we rather turn compiz off on those cards?
[10:38] <Sarvatt> seb128: got any links to any of them with good info? xsession-errors would probably say why the panel died. mga hasn't really been touched in mesa in at least 3 years though :(
[10:39] <seb128> Sarvatt, the issue is a graphical refresh one it seems ot visual corruption with compiz
[10:39] <seb128> compiz was not enabled on matrox before according to mvo
[10:39] <seb128> the wrapper used to filter matrox out because they though it didn't work with it
[10:39] <seb128> the new compiz in lucid dropped the wrapper and filter out on pci ids though
[10:39] <seb128> it doesn't filter out those matrox cards it seems
[10:40] <seb128> I'm wondering if we should do that again or try to figure what is wrong with the matrox driver
[10:40] <Sarvatt> i'll see if i can dig up anything
[10:41] <jcristau> probably wouldn't be extremely hard for someone with the hw and interest
[10:41] <Sarvatt> yeah looks like it was blacklisted back in 07..
[10:41]  * jcristau has neither
[10:47] <Sarvatt> yeah for sure it looks like an oversight that the blacklist got dropped
[10:48] <Sarvatt> same problem even back in gutsy
[10:48] <seb128> well the thing is that it's somewhat working
[10:49] <seb128> so we can decide either to try to fix or filter it out again as it was
[10:52] <Sarvatt> hmm need to look at what the default dri settings are for mga, not sure why its even allowing this by default - /usr/bin/compiz (core) - Warn: Exceeded max texture size
[10:56] <Sarvatt> all this time i didnt know about xdriinfo :D
[10:57] <Sarvatt> darn why do these gnome-panel bugs have to have no useful info on them
[10:58] <Sarvatt> maybe theres one filed against x-x-v-mga
[10:58] <jcristau> i didn't even know mga had tfp
[10:59] <keffie_jayx> hello all, I al here because I am interested in helping out with this bug. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/301958. To be honest it is a big beyond my expertice but I can try spliting the 1.6 patch into smaller ones and see. This is an issue that should be resolved if a patch were sent upstream. 
[10:59] <ubot4> Launchpad bug 301958 in xserver-xorg-video-sis (Ubuntu) (and 1 other project) "[needs-packaging] no working driver for sis 671/771 video cards (affects: 40) (dups: 14) (heat: 256)" [Wishlist,Triaged]
[11:00] <jcristau> it'd also be fixed by getting better hw
[11:06] <Sarvatt> it's very doable, just need a lot of time
[11:17] <Sarvatt> if you ignore parts of it like the acceleration code thats wildly different you can port chunks of it over to sis pretty easy though, the resolution settings code would be a good start since it has a ton more modes than sis
[11:18] <Sarvatt> have you checked if mandriva updated it?
[11:19] <Sarvatt> shouldn't be *that* much needed to go from 1.6 to 1.7, take a look at xf86-video-sis in git and see the changes they did and apply it there too
[11:25] <keffie_jayx> Sarvatt: let me see what I can do :)
[11:26] <Sarvatt> not a single person in that bug posted logs with stock ubuntu drivers.. sheesh
[11:27] <Sarvatt> keffie_jayx: what is your problem with SIS? does it not load at all?
[11:27] <Sarvatt> or is it just that you dont get the right resolution?
[11:27] <keffie_jayx> Sarvatt: recently I just get the vesa driver with 800x600
[11:28] <keffie_jayx> in karmic I would get no video at all
[11:28] <Sarvatt> on mine I get SIS at 800x600, but what I do is unblacklist sisfb and set the resolution through that
[11:28] <keffie_jayx> sorry no X at all
[11:31] <keffie_jayx> Sarvatt: my idea is to get this to a state of parity with some distros
[11:31] <keffie_jayx> it works in fedora and in mandriva, and sme success in open suse
[11:31] <Sarvatt> well they aren't shipping that sisimedia driver, so why does it work there and not here?
[11:32] <keffie_jayx> you suggest that I get the resolution settings code sorted out and see
[11:32] <keffie_jayx> Sarvatt: black magic, unshared btw
[11:32] <Sarvatt> fedora's sis is stock upstream with no patches
[11:32] <Sarvatt> mandriva was using the sisimedia but last i looked they stopped after they updated to xserver 1.7
[11:33] <Sarvatt> yeah fedora 10-13 are all just stock upstream releases at least
[11:33] <Sarvatt> is it possible they aren't blacklisting sisfb?
[11:37] <Sarvatt> huh, fedora kernel has CONFIG_DRM_MRST=n?
[11:38] <Sarvatt> yeah fedora doesn't even build sisfb so it isn't that, all I can think of is the autoconfiguration stuff was screwed up in the past releases.. checking the pci id now
[11:45] <Sarvatt> keffie_jayx: if you could get an xorg.0.log from both a broken ubuntu livecd and a working fedora livecd that would help a ton to figure out where the problem is
[11:47] <keffie_jayx> Sarvatt: rigth, I am on it then, can i ping you when I have it?
[11:47] <Sarvatt> yeah, please do, thank you for that
[11:48] <Sarvatt> it should be pretty obvious from the logs whats going wrong
[12:56] <Sarvatt> oh man, today's the save the crappy gpu day or something, i'm actually working on merging this sis671
[13:17] <Sarvatt> this is surprisingly less hard than i thought it'd be, just imported it into git and am working my way through the commits in reverse
[13:23] <seb128> Sarvatt, oh btw bug #572550
[13:23] <ubot4> Launchpad bug 572550 in xserver-xorg-video-mga (Ubuntu Lucid) (and 3 other projects) "Panel utilities not shown on startup using Matrox gfx with compiz (affects: 15) (dups: 6) (heat: 115)" [Low,New] https://launchpad.net/bugs/572550
[13:24] <seb128> Sarvatt, that's the bug about the matrox compiz issue
[13:25] <Sarvatt> yay one of the dupes actually has some logs on it
[13:25] <seb128> Sarvatt, do you think we should make compiz not run on those?
[13:27] <Sarvatt> for sure
[13:27] <seb128> ok, thanks
[13:30] <Sarvatt> hmm http://launchpadlibrarian.net/48707922/CurrentDmesg.txt
[13:39] <Sarvatt> i'd like to see a glxinfo from one of these
[13:40] <Sarvatt> every single one with logs has +/usr/bin/compiz (core) - Warn: Exceeded max texture size in it
[13:40] <seb128> Sarvatt, it's an open bug tracker, feel free to ask questions or add comments ;-)
[13:40] <Sarvatt> i'm sure one of these has logs, will ask if i dont find it of course :)
[13:44] <Sarvatt> ah when it says "/usr/bin/compiz (core) - Warn: Exceeded max texture size in it" it launches the fallback window manager and quits compiz
[13:46] <Sarvatt> i dont think any of these people are even using compiz
[13:47] <Sarvatt> they all fall back right after gnome starts in the .xsession-error logs
[13:47] <seb128> hum
[13:47] <seb128> so comments are confusing
[13:47] <seb128> because people said they solved the issue by uninstalling compiz
[13:49] <Sarvatt> i think its because they uninstalled compiz-gnome
[13:51] <seb128> how would that make a difference if they don't run compiz?
[13:52] <Sarvatt> because its still loading gtk-window-decorator always if you ever start compiz
[13:52] <Sarvatt> and doesn't quit it even if you stop running compiz
[13:52] <Sarvatt> have you seen issues with gtk-window-decorator and gnome-panel? because that might be what these people are hitting
[13:53] <Sarvatt> /usr/bin/compiz (core) - Warn: Exceeded max texture size
[13:53] <Sarvatt> Starting gtk-window-decorator
[13:53] <Sarvatt> that persons on a savage with the same problem
[14:41] <Sarvatt> seb128: i can reproduce it on my intel
[14:41] <Sarvatt> seb128: enable compiz, then go back to no effects
[14:41] <Sarvatt> and in a terminal run compiz-decorator
[14:42] <Sarvatt> panel disappears
[14:42] <seb128> Sarvatt, ok, thanks, so compiz bug?
[14:42] <Sarvatt> yeah
[14:47] <seb128> Sarvatt, thanks for investigating
[14:48] <Sarvatt> the decorator runs before compiz finishes bailing out if it cant load
[14:49] <seb128> the decorator should not be running if compiz doesn't run
[14:49] <seb128> I don't really get what is happening
[14:52] <Sarvatt> it never stops, I guess the old wrapper used to handle stopping it when compiz quit before?
[14:53] <Sarvatt> will look in git, digging through a trace of whats going on
[14:53] <seb128> hum
[14:53] <seb128> what doesn't stop? the decorator?
[15:03] <Sarvatt> yeah, before when the compiz wrapper stopped it stopped the decorator too but now they're seperate and stopping compiz doesnt stop the decorator
[15:10] <seb128> Sarvatt, ok thanks
[15:10] <seb128> Amaranth, ^
[15:10] <seb128> mvo, ^
[15:10] <seb128> do you guys know about that?
[15:11] <seb128> mvo, seems compiz doesn't run on matrox it's just that the decorator is still running after it bails out
[15:12] <Amaranth> The decorator shouldn't be doing anything if compiz isn't running to tell it what to do
[15:16] <Sarvatt> i'm not supposed to have /etc/xdg/compiz/compiz-manager anymore right?
[15:18] <Amaranth> it doesn't get used
[15:18] <Amaranth> but we can't remove config files
[15:20] <Sarvatt> just making sure before i remove it, thanks :)
[15:32] <seb128> Amaranth, did you read the bug pointed before?
[16:23] <asac> RAOF: http://launchpadlibrarian.net/49818073/buildlog_ubuntu-lucid-armel.libdrm_2.4.20-2ubuntu1~10.04~eglppa1_FAILEDTOBUILD.txt.gz
[16:35] <asac> RAOF: so do we want to not produce -intel there? guess we should make INTEL then more specific in rules
[16:35] <asac> hmm ... wonder why the build in maverick succeeded
[16:52] <Sarvatt> darn I was hoping launching compiz with the decoration plugin on the command line would kill gtk-window-decorator when you replaced it but nope. looks like this is a common problem with compiz going by how other distros handle it
[16:54] <Sarvatt> hah, thats funny because intel was added to arm specifically for libdrm even though it makes no sense
[16:54] <Sarvatt> because plymouth needed it
[16:57] <Sarvatt> that looks like a rules failure because it built, just didnt install?
[17:03] <Sarvatt> RAOF: Package: libdrm-intel1
[17:03] <Sarvatt> Section: libs
[17:03] <Sarvatt> Architecture: amd64 i386 kfreebsd-amd64 kfreebsd-i386
[17:03] <Sarvatt> thats why it didnt build
[17:19] <bryceh> morning
[18:18] <Sarvatt> morning bryceh!
[18:20] <Sarvatt> bryceh: how do you want to do your n-trig quirk in wacom now? patch doesn't apply anymore but it looks like you can load wacom for any tablet now with an xorg.conf snippet
[18:20] <Sarvatt> not sure though
[18:24] <bryceh> n-trig quirk?
[18:24] <bryceh> refresh my memory
[19:05] <bryceh> Sarvatt, is xorg-server ready to upload?  Can you give me a url for the orig tarball to use?
[19:05] <bryceh> Sarvatt, also, let me know status on debdiffs for anything you'd like to get uploaded later today once the xserver goes in
[19:42] <bryceh> anyway, I'll wait for you or raof to cue me when/what to upload, so lemme know
[21:52] <bryceh> http://www.theinquirer.net/inquirer/news/1652779/powercolor-hd5970-display-outputs
=== Kangarooo1 is now known as Kangarooo
[22:03] <Sarvatt> phew, its fun trying to install a system with no network and only the letters asebom working on my only usb keyboard :D
[22:05] <Sarvatt> wanna finish setting up this fglrx box real quick and i'll get right on the debdiffs
[22:13] <bryceh> btw only going to be available 3 more hrs; wife is doing major housecleaning today and demands being taken out to dinner this evening
[22:14] <Sarvatt> testing out xorg-server now, with http://xorg.freedesktop.org/releases/individual/xserver/xorg-server-1.8.1.901.tar.gz
[22:15] <jcristau> should i upload an xorg-server 1.8.1.901 to experimental so you have a tag/tarball to merge from?
[22:16] <bryceh> jcristau, that would be quite helpful
[22:17] <jcristau> ok, will try to do that then.  bad wireless permitting.
[22:17] <Sarvatt> RAOF: are you around?
[22:20] <Sarvatt> i got caught up putting together two radeon machines, sorry if I kept you hanging today :( haven't heard from RAOF since this morning, it sounded like he already did some of the merges
[22:20] <Sarvatt> bryceh: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/xf86-input-wacom/maverick/revision/5#debian/patches/100_ntrig_2010_02_03.patch
[22:20] <Sarvatt> thats the wacom patch
[22:21] <Sarvatt> http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=blob;f=src/wcmUSB.c;h=249a7bfb3e96454df82b0ca9e67cfdcb5e7aefa4;hb=HEAD
[22:21] <Sarvatt> and thats upstream
[22:22] <lucazade> hi
[22:22] <Sarvatt> hopefully debian is far enough behind that it applies :)
[22:23] <lucazade> there is a patch to fix opengl for poulsbo on lucid
[22:23] <lucazade> https://bugs.freedesktop.org/show_bug.cgi?id=28077
[22:23] <ubot4> Freedesktop bug 28077 in Acceleration/EXA "X segfault in miCopyRegion / fbCopyNtoN" [Normal,New]
[22:24] <lucazade> is a a bug in Xorg 1.7.6 EXA code 
[22:25] <lucazade> is it possible to apply this patch in the backport repository?
[22:27] <lucazade> now we have 2D/3D and video accel
[22:48] <kees> RAOF: does this new major bump of Xorg gain us a higher max client count?
[22:49] <kees> RAOF: (bug 260138)
[22:49] <ubot4> Launchpad bug 260138 in xorg-server (Ubuntu) (and 2 other projects) "(needs x11 protocol update) Xorg needs client limit raised (affects: 2) (dups: 1) (heat: 9)" [Wishlist,Triaged] https://launchpad.net/bugs/260138
[22:51] <Sarvatt> no, thats X12 I believe kees :)
[22:53] <kees> Sarvatt: oh... Major major.  ;)
[22:57] <Sarvatt> just curious, what do you do that hits the limit? seen ya asking for that for years :D
[22:57] <bryceh> Sarvatt, when I try to pbuilder this xserver I get some unmet deps:
[22:57] <bryceh>   pbuilder-satisfydepends-dummy: Depends: xutils-dev (>= 1:7.5+3) but it is not installable
[22:57] <bryceh>                                  Depends: libxau-dev (>= 1:1.0.5-2) but 1:1.0.5-1 is to be installed.
[22:57] <bryceh>                                  Depends: libxfont-dev (>= 1:1.4.1-2) but it is not installable
[22:57] <bryceh>                                  Depends: libpciaccess-dev (>= 0.11.0-2) but it is not installable
[22:57] <bryceh>                                  Depends: mesa-common-dev (>= 7.8) but it is not installable
[22:57] <bryceh>                                  Depends: libgl1-mesa-dev (>= 7.8) but it is not installable
[22:58] <Sarvatt> you're building in a lucid pbuilder
[22:59] <Sarvatt> or not updated in a few weeks?
[22:59] <bryceh> just now updated it
[22:59] <bryceh> sudo DIST=maverick pbuilder build xorg-server_1.8.1.901-1ubuntu1.dsc
[23:03] <kees> Sarvatt: I don't, but a friend of mine hits it all the time due to him running like 9 desktops and hundres of shells and firefox windows
[23:08] <bryceh> Sarvatt, regarding that ntrig quirk patch, it still looks valid, you just need to refresh it.  Lines 12-14 in the patch need to be changed to match lines 444-446 from http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=blob;f=src/wcmUSB.c;h=249a7bfb3e96454df82b0ca9e67cfdcb5e7aefa4;hb=HEAD
[23:08] <bryceh> I suspect everything else in that changeset remains the same
[23:11]  * Sarvatt wishes there was a git-bzr
[23:12] <jcristau> ok, got my xserver upload to people.d.o, so the painful part is done. now to sign it and move it over to ftp-master.
[23:12] <Sarvatt> and a gitlib in python while i'm at it
[23:16] <jcristau> bryceh: http://people.debian.org/~jcristau/xorg-server_1.8.1.901.orig.tar.gz is the tarball i uploaded.
[23:16] <bryceh> thanks!
[23:17] <jcristau> (with 1.9 we'll use the upstream tarball, since alanc removed the README.DRI file we'd been stripping.)
[23:20] <Sarvatt> is using an old xsfbs going to screw things up in xf86-input-wacom? looks like we imported it for some patches
[23:21] <jcristau> (and just to be sure, sha1sum is 46e647e61b3608dc4db5ae368f1bc9036c837d5c)
[23:21] <bryceh> Sarvatt, well you could probably use a newer xsfbs without any problem, but you'll need some sort of system there to apply the patch
[23:22] <bryceh> xorg-server_1.8.1.901-1ubuntu1_source.changes uploaded to my ppa
[23:23] <Sarvatt> well we dont have any of the provides so I guess it doesn't really matter
[23:23] <bryceh> rebuilding my maverick pbuilder instance, will try building it locally again after that
[23:32] <bryceh> ok, building nicely now
[23:43] <bryceh> built
[23:43] <bryceh> uploading...
[23:44] <bryceh> ...uploaded.
[23:44] <bryceh> Let the Games Begin
[23:46] <bryceh> [ubuntu/maverick] xorg-server 2:1.8.1.901-1ubuntu1 (Accepted)
[23:46] <RAOF> Thanks!
[23:50] <RAOF> bryceh: Could you also upload the SRU in the xorg-server ubuntu-lucid branch?  It's 2:1.7.6-2ubuntu8 with the miCopyRegion segfault & others fixed, not the GLX 1.4 backport
[23:51] <RAOF> Sarvatt: dulwitch is a gitlib in python.  Used by bzr-git.
[23:53] <bryceh> RAOF, I think that numbering is wrong
[23:53] <RAOF> Hm.  Quite possibly.
[23:54] <Sarvatt> bryceh: 2 more here, http://sarvatt.com/downloads/merges/ would you mind acking those sync requests on here https://wiki.ubuntu.com/X/PackageNotes ?
[23:55] <bryceh> alright
[23:57] <bryceh> RAOF, that's a lot of changes for an SRU...  do you have all of the 4 bugs there filed as SRU reports? 
[23:59] <RAOF> Yes.  The first two were filed by you, the third by pitti, the last by me.