[01:00] <bryceh> Sarvatt, what kind of help do you need exactly?
[01:01] <Sarvatt> core-dev :P
[01:02] <Sarvatt> https://wiki.ubuntu.com/X/PackageNotes
[01:05] <bryceh> are there debdiffs prepared for the merges?
[01:06] <Sarvatt> nope but I can come up with that before server goes in on monday, been doing what I can asking debian to update things and merging things in git
[01:06] <bryceh> that would be great
[01:06] <Sarvatt> but even things like nvidia-current need rebuilding now since xserver-xorg-core breaks every package providing the old abi
[01:06] <Sarvatt> and virtualbox
[01:06] <bryceh> if it's just down to package sponsoring I can probably carve out a couple hours monday to lend a hand
[01:07] <Sarvatt> yeah its just sponsoring really
[01:07] <bryceh> don't worry about the proprietary drivers at this point
[01:07] <Sarvatt> i do because xserver wont upgrade and will remove input/video-all if they have the prop drivers installed :)
[01:07] <bryceh> it's traditional that they all break once xserver is updated, and stay broken until we receive compatible versions
[01:08] <bryceh> won't upgrade?
[01:08] <Sarvatt> if it was just the drivers broken it'd be one thing but xserver wont even install now
[01:08] <bryceh> hmm
[01:08] <bryceh> but that affects only users with proprietary drivers installed?
[01:08] <Sarvatt> upgrading the safe upgrade stuff which didn't include -core made nvidia-current get installed on  my netbook
[01:09] <bryceh> I would be highly doubtful that there are many people running proprietary drivers on maverick right now, but if there are some, then they can clean up manually
[01:09] <Sarvatt> maybe we should just not have nvidia-current provide an abi, it doesn't make sense thinking about it because the ones in maverick are compatable wth multiple video abi's
[01:09] <bryceh> if you want to be nice, maybe include some hints in an email
[01:11] <bryceh> historically, we've always had a broken period from when the new xserver appeared until the drivers built, which could last a couple days
[01:12] <bryceh> a good goal would be to minimize that by getting xserver and the main foss drivers in as close to each other as possible
[01:12] <bryceh> the outlier drivers, including proprietary drivers, probably can wait for the second round after that
[01:12] <Sarvatt> i'll start gathering up debdiffs :)
[01:12] <bryceh> excellent
[02:19] <Kangarooo> Sarvatt: ive got 3 more crashes different with Xorg. should it post to the same bug?
[03:55] <Sarvatt> https://edge.launchpad.net/ubuntu/+ppas -- must beat language pack builders! :D
[04:26] <Kangarooo> Sarvatt: I added more dgb to bug 587710
[04:26] <ubot4> Launchpad bug 587710 in nvidia-graphics-drivers (Ubuntu) "if FF wit lot Gif & overloading CPU then X-boom to login (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/587710
[05:39] <ripps> *sigh* I remember when gmpc-trunk used be in the Most Active list. That was before the developer went on hiatus.
[05:43] <ripps> When is dri2 sync + swap coming?
[07:58] <ripps> what is this? Do I see a 2.6.35 kernel building for maverick? Only a matter of time til one is backported to either xorg-edgers or kernel-ppa
[08:33]  * hyperair growls at x-x-v-i
[08:59] <ricotz> Sarvatt, i am building 2.6.35-1.1 for lucid in my ppa and will copy it over to edgers if it works
[10:40] <lucazade> adding XAANoOffscreenPixmaps to poulsbo xorg.conf fix 3D but icons/pixmaps are broken.... grrr
[10:46] <lucazade> any hint?
[11:06] <lucazade> adding also RENDER "disable" fix both 3D and icons.. but not optimal workaround
[11:53] <Sarvatt> heads up if you are using the dynpm module option for radeon its gone in that .35 kenel so it wont load
[12:02] <ricotz> Sarvatt, :( i said it is building in my ppa, so there wasnt a need to jam more builders
[12:04] <Sarvatt> i  didnt look at irc when i woke up, sorry
[12:05] <ricotz> Sarvatt, alright
[12:46] <Sarvatt> ricotz: are you patching mutter? it's pretty much useless in maverick without http://sarvatt.com/downloads/patches/0001-Use-gdk_screen_get_system_colormap-instead-of-gdk_sc.patch
[12:48] <Sarvatt> i need to figure out how to get collab-maint packages working with auto-xorg-git..
[13:07] <ripps> geez, everybody and their sister is building 2.6.35 in launchpad
[13:42] <Sarvatt> theres the 2048x2048 compiz fix for intel \o/ - http://cgit.freedesktop.org/mesa/mesa/commit/?id=add3260157368458501709d08a3f913ed448234f
[13:49] <Sarvatt> hmm randrproto installs docs to /usr/share/doc/randrproto instead of /usr/share/doc/x11-proto-randr-dev now
[13:50] <ricotz> Sarvatt, yes, i am patching mutter with it
[13:53] <ricotz> Sarvatt, yesterday you mentioned a shell script for updating edgers ppa, could i have a look at it?
[13:55] <jcristau> Sarvatt: it does?
[13:56] <Sarvatt> yeah
[13:56] <Sarvatt> in git
[13:57] <Sarvatt> i just made a script that build the world automatically in debian packages and that and libxt were the failures, fixed libxt in unstable
[13:58] <ricotz> ok
[13:58] <Sarvatt> http://cgit.freedesktop.org/xorg/proto/randrproto/commit/?id=68f8fbe50792e0525ba767d854b18db4acda07ff
[13:59] <jcristau> i guess i never test built libxt
[13:59] <jcristau> ah right
[14:00] <jcristau> hmm but dh_installdocs randrproto.txt should still put it in the right place
[14:00] <Sarvatt> digging up the build logs
[14:01] <Sarvatt> ricotz: will upload it to xorg-pkg-tools soon, working out some kinks
[14:01] <Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+build/1774308/+files/buildlog_ubuntu-lucid-i386.x11proto-randr_1.3.1+git20100604.6ecbca5e-0ubuntu0sarvatt~lucid_FAILEDTOBUILD.txt.gz
[14:02] <ricotz> Sarvatt, thanks
[14:03] <Sarvatt> dh_install: x11proto-randr-dev missing files (usr/share/doc/x11proto-randr-dev/*), aborting
[14:03] <jcristau> wtf
[14:03] <jcristau> yeah.  wonder what's going on there
[14:04] <jcristau> hum
[14:04] <jcristau> ../configure: line 4078: PKG_PROG_PKG_CONFIG: command not found
[14:05] <jcristau> this is also broken :)
[14:05] <jcristau> pkg-config not installed?
[14:06] <Sarvatt> oh sheesh i fixed that in the upload before it and forgot, need to make a hook too add it to build depends
[14:08] <Sarvatt> or should it be that way in git in the first place? :)
[14:08] <Sarvatt> Build-Depends:
[14:08] <Sarvatt>  debhelper (>= 5.0.0),
[14:08] <Sarvatt>  automake,
[14:08] <Sarvatt>  xutils-dev (>= 1:7.5~1)
[14:08] <jcristau> may be easier to just give up and add it to xutils-dev Depends
[14:09] <jcristau> but yeah, adding it to randrproto build-deps in git sounds good
[14:10] <Sarvatt> okie pushing it
[14:11] <Sarvatt> and depends of xutils-dev sounds good to me :)
[14:14] <Sarvatt> oh noes, input-citron doesnt build against 1.8 either http://launchpadlibrarian.net/49692666/buildlog_ubuntu-lucid-amd64.xserver-xorg-input-citron_1:2.2.2%2Bgit20100604.6341ecaa-0ubuntu0sarvatt~lucid_FAILEDTOBUILD.txt.gz
[14:14] <jcristau> surprise..
[14:18] <Sarvatt> big old list here if you ever want to see build logs for anything - https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+builds?build_text=&build_state=all
[14:23] <Sarvatt> ricotz: http://sarvatt.com/sarvatt-update-ppa.sh --  just dont run it on edgers anytime because it relies on only one person running it stores the latest commit in .lastcommit so it knows to only update the package if its been update :)
[14:24] <Sarvatt> if you change the ppa to an undefined one it'll make source packages for the world
[14:26] <ricotz> thanks, will have a look
[14:27] <ricotz> Sarvatt, i would be nice if the date in version-string is actually the date of git-commit
[14:28] <ricotz> LASTCOMMITDATE=$(git log ${LASTCOMMIT:7} --pretty=%ci | head -1 | awk '{ print $1 }' | sed 's/-//g')
[15:15] <Sarvatt> ricotz: oh but its ok to use for mesa, thats the CUSTOM_ONE target
[15:17] <Sarvatt> i put the hacky hook that replaces debian/ in hooks-sarvatt
[15:55] <Sarvatt> argh found yet another problem in fglrx-installer, patch pointing at the wrong file. i'm not getting any feedback on it and cant test it so i asked people to come here if they have a problem with it :)
[16:17] <Sarvatt> i hate uploading things i cant test :)
[17:27] <Bernardo> Sarvatt: did you manage to advance in the psb drivers?
[17:35] <jcristau> Sarvatt: do you remember when/how the 'Failed to submit batchbuffer: Input/output error' intel errors got fixed?
[17:58] <Sarvatt> jcristau: there were so many different bugs causing that, it depends.. most were the "dont release *something* at load detect time" commit in the kernel that i dont think ever made it upstream
[17:59] <Sarvatt> looking for the commit, i know debian had it though
[17:59] <Sarvatt> i remember bgoglin pinging it on intel-gfx saying you were carrying it
[17:59] <Sarvatt> ah crap, script moved mesa to a +
[17:59] <Sarvatt> libgl1-mesa-dri-gallium_7.9.0+git20100605.6d741627-0ubuntu0sarvatt_i386.deb
[17:59] <Sarvatt>  :(
[18:13] <Sarvatt> jcristau: if it was happening at suspend/resume or when idle and doing a dpms off this is the commit - https://patchwork.kernel.org/patch/80474/
[18:13] <Sarvatt> that one had really specific triggers
[18:14] <Sarvatt> but there are so many bugs that cause that error message
[18:21]  * hyperair gapes at the amount of upgrades from the xorg-edgers ppa
[18:22] <jcristau> Sarvatt: okay, thanks
[20:42] <ripps> dammit, the new 2.6.35 is incompatible with linuxwacom. I have Bamboo CTL-460, and it requires building a new wacom module, but I'm unable to build a module for this kernel.
[20:53] <Sarvatt> it's not in 2.6.35?
[20:54] <Sarvatt> is it just the kernel side that doesnt support it or xf86-input-wacom? wacom module load?
[20:57] <Sarvatt> yeah i dont see the pci ids in the kernel :(
[21:08] <Sarvatt> why haven't they pushed that to the mainline kernel yet
[21:08] <Sarvatt> i mean i see it in here over a year ago
[21:14] <Sarvatt> oh ok here's where they added support for your d4 device in linuxwacom, not as old as i thought - http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/linuxwacom;a=commit;h=2683f4f52f4e43f4bbabb168d1a31e78200d9d8c
[21:51] <ripps> Sarvatt: I fixed the wacom issue. The module didn't work, and the code in linuxwacom-0.8.6-2/0.8.7-2 was out of date. I had to change the name of a few functions in order for the the module to build
[21:52] <ripps> in wacom_sys.c
[21:54] <ripps> yeah, but this crap should be in mainline already. No reason I should be rebuilding wacom modules at this point.
[21:55] <ripps> if this doesn't go in, they better make a dkms or something