[00:18] <maxb> Wasn't it already in karmic?
[00:20] <verbalshadow> didn't seem to work for me, thought there was a PPA it
[01:57] <RAOF> Oooh.  An upstreaming branch of nouveau appears.
=== verbalshadow_ is now known as verbalshadow
[05:41] <tjaalton> RAOF: I think it's upstream already
[05:44] <tjaalton> at least Linus tested it and it worked
[06:41] <tjaalton> yes, it is merged
[06:51] <tjaalton> Sarvatt: what should be done to bugs about edgers packages?
[07:05] <RAOF> tjaalton: That was fast - the for-airlied branch was only made 17 hours ago :)
[07:06] <RAOF> So, time to update my lucid kernel branch pulling nouveau from linus instead, I guess.
[07:45] <verbalshadow_> how do i tell if my lucid system is using KMS?
[08:06] <cwillu> verbalshadow, does switching vt's work, and does it take less than a tenth of a second?
[08:11] <tjaalton> only intel does it by default
[08:11] <tjaalton> there's a new kernel upload but it's probably not built yet
[11:33] <Duke`> I don't know why but for some weeks (or months?) I have no visible cursor with R200/lucid. I have to run xrandr once (without any change) and the cursor come back.
[12:17] <tjaalton> damn I hate that system test app which tries to run xrandr on hw that doesn't support it, and then files tons of bugs..
[12:21] <tjaalton> heh, and tons of related bugs filed against checkbox.. no-one seems to care though
[13:00] <tormod> tjaalton, bugs in xorg-edgers can be filed in launchpad, but add "xorg-edgers" in the title and subscribe the uploader
[13:01] <tormod> Duke`, your missing cursor: with kms?
=== mac_v_ is now known as mac_v
[14:53] <Duke`> tormod: yes with KMS
[17:20] <Duke`_> RAAAAHHH SHIETY CONNECTION§§!dfù!:df
[17:21] <Duke`_> I had written a long speech during disconnection ;_;
[17:21] <Duke`_> did you see something of what I said during the last 10 mins?
[17:34] <Sarvatt> tormod: ugh, looks like we are gonna have to replace linux-libc-dev again since intel git requires headers from 2.6.33?
[17:35] <Duke`_> http://pastebin.com/m1e7a2212
[17:35] <Sarvatt> ./include/drm/i915_drm.h:#define I915_PARAM_HAS_OVERLAY           7 (in libdrm)  and http://launchpadlibrarian.net/36710792/buildlog_ubuntu-lucid-amd64.xserver-xorg-video-intel_2:2.9.99.901%2Bgit20091211.8ecf70ea-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
[17:36] <tormod> Sarvatt, can't believe they unconditionally require 2.6.33 ? must be a bug
[17:36] <Sarvatt> they have a patch for 2.6.32...
[17:36] <Sarvatt> i think its intentional..
[17:36] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bd81734465912d79d6320a6fb021ce43d258b906
[17:37] <tormod> they removed the #ifdefs ... way to go
[17:37] <Sarvatt> the person who wrote that obviously doesn't use a debian based distro
[17:38] <tormod> "now that 2.4.16 is released..." what about waiting for the kernel to release, grrr
[17:39] <Sarvatt> i dont even think the overlay patches are in linus' tree yet?
[17:39] <tormod> "this needs at least kernel v2.6.33 to work", well in a few months time
[17:40] <Sarvatt> whatever distro he uses must have libdrm headers actually getting installed
[17:40] <Sarvatt> too bad we're stuck on 2.6.32 :(
[17:41] <tormod> he's probably using his own kernel with his own headers and expects the world to follow :)
[17:47] <Sarvatt> pretty safe to say noone using edgers will be using the ancient 2.6.32 4 months from now anyway :D
=== ripps_ is now known as ripps
[17:51] <Sarvatt> Duke`: I have the same problem
[17:51] <Sarvatt> lots of hangs with execbuff while wedged spamming dmesg
[17:52] <Sarvatt> thats on the drm-intel-next kernel though
[17:55] <Sarvatt> tormod: going to upload a new libdrm replacing linux-libc-dev and not deleting the headers in the rules I guess, unless you can think of something else to do
[17:57] <Sarvatt> could make a hook to revert that commit every time :D
[17:58] <tormod> Sarvatt, yes, sounds ok, like we once did. did you try it out locally?
[18:00] <tormod> but I can't believe they did this. this will be 2.10 for their Q4 package right?
[18:00]  * albert23 got -intel working that way yesterday
[18:01] <albert23> I think Eric Anholt explains it here: http://marc.info/?l=dri-devel&m=125770698907397&w=2
[18:01] <albert23> build against latest headers, then run-time detection if the feature is available
[18:02] <tormod> albert23, thanks
[18:24] <Sarvatt> hmm, someone saying a no change rebuild of nvidia 185.18.36 under lucid works, have to try that out
[18:32] <tjaalton> Sarvatt: by using IGNORE_ABI? doesn't help much
[18:33] <tjaalton> packaging wise
[18:39] <Sarvatt> they said it worked like normal after a rebuild to not remove xorg and bump the abi even though the release notes didnt start saying it supported 1.7 until 190, will have to test it when I get home later but I put it on edgers to rebuild just incase
[18:40] <Sarvatt> it sure was fun uploading the blob on a tethered cell connection :D
=== mac_v_ is now known as mac_v
=== nielsslot_ is now known as nielsslot
[19:01] <Sarvatt> darn nouveau box _really_ doesn't like being run with the lid closed for days - http://paste.ubuntu.com/340114/
[19:13] <Sarvatt> dlopen: /usr/lib/xorg/modules/drivers/nvidia_drv.so: undefined symbol: resVgaShared
[19:13] <Sarvatt> nvidia failed to load
=== _stink__ is now known as _stink_
[20:05] <Sarvatt> Why did we move away from the nvidia-glx, nvidia-glx-new, nvidia-glx-legacy naming scheme to the current nvidia-glx-(major version) one thats a major pain to update as often as nvidia bumps the major version?
[20:06] <Sarvatt> seems like it would be a good idea to leave a generic version scheme for the trunk then just version all the old legacy ones like they are now
[20:10] <Sarvatt> the .in's would work right if we did that too, they seem like a remainder from an old naming scheme since it just bumps the dep versions not the actual package names -- Package: nvidia-glx-185 Depends: nvidia-185-kernel-source (>= #VERSION#), nvidia-185-libvdpau (>= #VERSION#), x11-common (>= 1:7.0.0), ${shlibs:Depends}
[20:27] <Sarvatt> strange.. (185.18.36) Package: nvidia-glx-185-dev Depends: nvidia-glx-185 (>= 185.18.31) Conflicts: nvidia-glx-185 (>= 185.18.32)
[20:36] <superm1> personally i dont see why we dont just put all the packages into one big package (say nvidia-$MAJOR_VERSION), and then in the .in, just update that $MAJOR_VERSION if it's a bump
[20:37] <superm1> there's no reason to ever go mix and match some vdpau library here, or kernel source package there
[20:37] <superm1> and it would certainly help if you want to switch from nvidia->nouveaou and what not
[20:39] <superm1> same goes for debian, i think the same type of change would be applicable there
[20:46] <tjaalton> the older versions rarely change, so uploading four blobs every time seems a bit excessive
[20:47] <tjaalton> I think the latest version should be just n-g-d, without a version
[20:50] <tormod> Duke`__,  I also lose the cursor sometimes, gets back with console switching or xrandr
[20:52] <tormod> just verified now it is not related to compiz
[20:55] <Sarvatt> in this case all the old blobs need updating at the same time for the new xserver abi though :(
[21:03] <Sarvatt> hmm if we add MAJOR_VERSION like that to debian/upstream_info it wont add the old major version package names to be removed and stuff, will still have to hand edit all those hooks
[21:06] <Sarvatt> unversioned package name for the trunk is all i can see doing outside of rewriting all this stuff to pack them all together like that, would be alot easier i'd think to not have a major version in the main package name and leave the old versioned like they are?
[21:07] <Sarvatt> thats just if i was doing it though, i'm not good at this stuff :D
[21:12] <Sarvatt> or we could just define OLD_MAJORVERSION as well and add like nvidia-$OLD_MAJORVERSION to everything in control and leave the stuff there as well?
[21:12] <Sarvatt> oh but that wouldnt account for old old major version packages so that wont work
[21:13] <Sarvatt> dont mind me just thinking out loud
[21:24] <Sarvatt> all the nvidia legacy drivers have updates for xserver 1.7 so those would be easy to package up right now at least, just editing the versions in debian/upstream_info
[21:25] <Sarvatt> oh 71.xx hasn't been updated
[21:26] <Sarvatt> ftp://download.nvidia.com/XFree86/Linux-x86/96.43.14/  ftp://download.nvidia.com/XFree86/Linux-x86/173.14.22/
[21:27] <tjaalton> IIRC it newer will be
[21:29] <Sarvatt> its a shame the cards that need 71 dont work in nouveau either I believe
[21:31] <tjaalton> those are ancient anyway
[21:31] <Sarvatt> ah just tnt1, 71 is for tnt1 to geforce2
[22:11] <Sarvatt> hmm libvdpau_trace.so is gone from 195 nvidia drivers
[22:12] <Sarvatt> ah its another folder down in usr/lib/vdpau/ now
[22:21] <Sarvatt> libvdpau_nvidia too, ugh
[22:23] <superm1> Sarvatt, no dont install them
[22:23] <superm1> there is a NEW library, libvdpau
[22:23] <superm1> so you only need to install libvdpau_nvidia
[22:23] <superm1> and depends on libvdpau
[22:23] <Sarvatt> ohh I see
[22:24] <superm1> it's in debian main and ubuntu's NEW queue
[22:24]  * Sarvatt backs out alllll the changes in rules he just did
[22:30] <AlanBell> evening all, is there anything I can do to add to the information on bug 428769?
[22:31] <ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor" [Undecided,Confirmed] https://launchpad.net/bugs/428769
[22:31] <AlanBell> I just tried Lucid and it is the same there
[22:45] <Sarvatt> so there isnt going to be an nvidia-xx-libvdpau-dev anymore then right? looks like the headers in the seperate libvdpau package now.. I need to find the libvdpau package to see if its got vdpau_x11.h too
[22:46] <Sarvatt> yep both headers in there upstream, so i guess we need a transitional nvidia-185-vdpau-dev to depend on libvdpau-dev?
[22:47] <tjaalton> why?
[22:47] <tjaalton> doubt anything build-depends on that
[22:47] <tjaalton> and if so, those should be fixed
[22:47] <Sarvatt> dunno, is why i was asking :D
[22:47] <tjaalton> ok :)
[22:48] <superm1> mythtv build depended on it
[22:49] <superm1> but it's already got it as libvdpau-dev | nvidia...blah blah
[22:57] <Sarvatt> ohh superm1, mind if i copy your libvdpau and nvidia 190 drivers to xorg-edgers? didnt see ya had one in your ppa
[22:57] <Sarvatt> just so it builds against the newer xorg and doesnt try to remove it installing it
[22:58] <superm1> Sarvatt, grab the libvdpau from lucid NEW instead of the one in my PPA
[22:59] <superm1> you can grab the 190 if you want though
[22:59] <superm1> grab it from ~mythbuntu/trunk-0.22 instead of ~superm1
[22:59] <superm1> why not just upload to the archive though instead of edgers?
[23:00] <Sarvatt> i'm just a lowly ubuntu member :D
[23:04] <tjaalton> tseliot said he was working on it
[23:13] <Sarvatt> sheesh your package looks great, the others I was looking at still had nvidia-185-whatever in the dpkg hooks and stuff leaving dangling things everywhere
[23:30] <Sarvatt> *almost* made it a day without intel crashing
[23:32] <Sarvatt> [76508.606525] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error. and execbuf while wedged in dmesg again, can't use current git stuff with 2.6.32-7 either for some reason
[23:43] <Sarvatt> yeah I need to blacklist vga16fb in order to boot with KMS on the ubuntu kernels now
[23:44] <Sarvatt> failsafe x comes up with a corrupted screen otherwise
[23:44] <Sarvatt> must be a side effect of the forced vga16fb loading on 2.6.32-7 and up