[00:03] <Sarvatt> so it was just one little change and git wasnt updated, phew
[00:03] <Sarvatt> thats test building now so i can look at the package contents
[00:09] <Sarvatt> hurry up mesa!
[00:10] <RAOF> Sarvatt: Have you re-pulled mesa and found my merge?
[00:11] <Sarvatt> yep and fixed it, its just almost done building, i want to make absolutely sure every file is correct :)
[00:11] <RAOF> It all _looked_ right to me :/
[00:11] <Sarvatt> RAOF: wasn't your fault, i thought it was more screwed up than it was because you forgot to push :)
[00:12] <RAOF> Right.
[00:12] <RAOF> It would have looked like a half-baked 7.8.1-2
[00:12] <Sarvatt> was my fault for putting the header in the wrong place when i redid the dri build locations, that hadn't been uploaded to debian yet so its all ok
[00:13] <Sarvatt> we should probably explicitly disable some gallium stuff wasting time getting built, like svga
[00:14] <RAOF> That's the only thing wasting time, isn't it?  It doesn't take long, and it'd be annoying to maintain another GALLIUM_DISABLED variable :)
[00:14] <Sarvatt> yeah true :)
[00:14] <Sarvatt> swrastg
[00:15] <RAOF> Isn't built?
[00:15] <RAOF> At least, there 'aint no swrastg_dri.so generated.
[00:15] <Sarvatt> oh
[00:15] <Sarvatt> no point enabling radeon and intel if we arent shipping it?
[00:16] <RAOF> We are shipping it - in egl.
[00:16] <RAOF> That's also why we're enabling gallium swrast.  It doesn't generate a DRI driver, but it does generate an EGL swrast.
[00:17] <Sarvatt> ah ok, i was thinking it'd need the dri driver too to be usable for some reason
[00:17] <Sarvatt> its running make install now, 2 minutes tops
[00:24] <bjsnider> about how long is it supposed to take do install 25 or so updates after they've been downloaded?
[00:25] <Sarvatt> debian/libgl1-mesa-glx.prerm  is bogus
[00:25] <Sarvatt>   update-alternatives --remove gl_conf /usr/lib/GL/ld.so.conf
[00:27] <Sarvatt> http://sarvatt.com/downloads/files-six.txt
[00:27] <Sarvatt> file list
[00:31] <Sarvatt> ok pushed to origin/ubuntu
[00:38] <RAOF> You know, cairo has an openvg backend.  That might be interesting to play with on a lazy weekend.
[00:39] <Sarvatt> yeah I fixed that silly problem with the one header rule in that build, debdiff coming up
[00:41] <RAOF> One header rule?
[00:42] <Sarvatt> http://sarvatt.com/downloads/merges/mesa/ -- needs sponsor! :)
[00:42] <Sarvatt> yeah silly mistake
[00:42] <Sarvatt> drwxr-xr-x root/root         0 2010-06-15 16:18 ./usr/include/Gl/
[00:42] <Sarvatt> -rw-r--r-- root/root      3463 2010-06-15 16:18 ./usr/include/Gl/glx_mangle.h
[00:42] <Sarvatt> Gl :)
[00:47] <Sarvatt> geser: can you sponsor by any chance?
[00:50] <Sarvatt> http://sarvatt.com/downloads/files-seven.txt is the file list for this one
[01:04] <Sarvatt> need to figure out how to transition -gallium to -experimental
[01:04] <Sarvatt> ppa-purge with -gallium installed leaves it installed and will conflict with -experimental
[01:09] <Sarvatt> RAOF: I thought you fixed up nvidia-current and got it uploaded?
[01:43] <RAOF> Sarvatt: I did.
[01:43] <Sarvatt> oh, weird
[01:46] <Sarvatt> this is a lot nastier than I expected, there was a *huge* debian sync just now and some of the packages that check for GL might have just disabled supported and built anyway :(
[01:48] <RAOF> :(
[01:49] <RAOF> That should be fairly easy to check for, though.
[01:50] <RAOF> Thanks for cleaning this up!
[02:07] <Sarvatt> quite a few packages all failed with this - 
[02:07] <Sarvatt> CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE):
[02:07] <Sarvatt>   Could NOT find FLTK (missing: FLTK_INCLUDE_DIR)
[02:08] <Sarvatt> i dont have much more time until i pass out, stopping going through every build to see if its got undefined behavior from no GL and just started checking ftbs
[02:16] <Sarvatt> so much for fixing up cairo today :(
[02:17] <Sarvatt> \o/ almost done
[02:30] <Sarvatt> chrome/chromium do not like cairo 1.9.8 :(
[02:56] <RAOF> Man, everyone and their dog have a personal cairo branch!
[03:05] <bjsnider> will the blob build on the .34 kernel yet?
[03:11] <RAOF> You mean nvidia-current?  Yes.  It's even installable!
[03:12] <Sarvatt> it works fine on .35 too..
[03:13] <Sarvatt> 195.24 even
[03:13] <Sarvatt> RAOF: see any freetype lcdfilter patches in any of them?
[03:14] <RAOF> Nope, but I was only after master anyway.
[03:15] <Sarvatt> debian experimental works with no changes if you dont pull from git :)
[03:16] <Sarvatt> but i had glew problems enabling gl, should be fixed in git
[03:17] <RAOF> Yup, it is.
[03:18] <Sarvatt> got the lcdfilter patch refresh
[03:18] <Sarvatt> ed
[03:19] <Sarvatt> kinda, need to clean up some fuzz
[03:19] <Sarvatt> editing patches by hand sucks :)
[03:34] <Sarvatt> hmm the ubuntu patch in 1.8.10  is actually drastically different than what I was working with
[03:36] <Sarvatt> yeah scratch the one i was working on, i'll go with the firefox patch :)
[03:39] <RAOF> :)
[03:49] <Sarvatt> cairo-perf has some limitations on where it works i didnt know about
[04:11] <RAOF> Such as?
=== Bernardo is now known as Bernardo|Away
=== Bernardo|Away is now known as Bernardo
=== Bernardo is now known as Bernardo|Away
=== Bernardo|Away is now known as Bernardo
=== Bernardo is now known as Bernardo|Away
=== Bernardo|Away is now known as Bernardo
=== fluffymaster is now known as apachelogger
[10:30] <seb128> does anybody knows about "unclutter" there or has an opinion on it?
[10:30] <seb128> Description: hides the cursor in X after a period of inactivity
[10:30] <seb128> isn't that something xorg should be doing by itself ideally?
[10:30] <jcristau> no
[10:30] <seb128> context is bug #16492
[10:30] <ubot4> Launchpad bug 16492 in gtk+2.0 (Ubuntu Maverick) (and 3 other projects) "Mouse pointer should disappear when keyboard is in use and mouse isn't (affects: 19) (heat: 113)" [High,Triaged] https://launchpad.net/bugs/16492
[10:30] <seb128> sabdfl asked to review using unclutter in the default installation
[10:31] <seb128> jcristau, why not?
[10:32] <jcristau> comment 3 on that bug
[10:34] <seb128> ok, fair enough
[10:34] <seb128> so back to the first question, does anybody has an opinion on "unclutter"?
[10:35]  * jcristau doesn't
[10:42] <tseliot> I'm starting to think
[10:42] <tseliot> that it's not such a bad idea
[10:42] <tseliot> to use unclutter, that is
[10:44] <tseliot> seb128: do you need a code review or what?
[10:44] <seb128> tseliot, code review, comments from somebody who has an opinion about what it's doing
[10:44] <seb128> RAOF, hey
[10:44] <RAOF> seb128: Ho
[10:45]  * RAOF missed the start of this discussion
[10:46] <seb128> bug #16492
[10:46] <ubot4> Launchpad bug 16492 in gtk+2.0 (Ubuntu Maverick) (and 3 other projects) "Mouse pointer should disappear when keyboard is in use and mouse isn't (affects: 19) (heat: 113)" [High,Triaged] https://launchpad.net/bugs/16492
[10:46] <seb128> sabdfl asked us to evaluate using "unclutter" in the default installation
[10:46] <tseliot> RAOF: BTW I uploaded X in lucid-proposed yesterday and cjwatson has just approved it (LP: #563100)
[10:46] <seb128> I'm trying to gather opinions on it
[11:00] <RAOF> tseliot: Ah, thanks.  I'll merge your changes into the ubuntu-lucid branch in git.
[11:01] <tseliot> RAOF: sounds good. Thanks
[11:38] <tseliot> RAOF: we're going to use xserver 1.8 (not 1.9) in Maverick, right?
[11:39] <tseliot> seb128: after a quick look at unclutter, the code seems fine even though I'm not used to that coding style
[11:41] <RAOF> tseliot: We're planning on 1.9 for Maverick
[11:41] <tseliot> RAOF: ah, good
[11:42] <RAOF> And mesa 7.9, but that's probably less interesting on the binary driver front :)
[11:43] <tseliot> yes, that is why I was asking
[11:43] <RAOF> I sent a mail to the Ubuntu & Debian X lists with an outline of what we'd planned.  It's also on the “General X plans” blueprint.
[11:44] <tseliot> I'll have a look at it then, thanks
[11:46] <tseliot> note: I'm doing more work on open drivers for oem work than on proprietary drivers and it's good to know that we'll have mesa 7.9 :-)
[11:50] <RAOF> Yay!  Source code!  Decypherable backtraces!
[11:50] <RAOF> :)
[11:52]  * tseliot nods
[12:23] <seb128> tseliot, ok, thanks for the review
[12:23] <tseliot> np
[13:48] <RAOF> Of course, now that I've got gdb attached X refuses to segfault.
[14:05] <tseliot> it makes sense ;)
[15:24] <helo> upgrading to xorg 1.7.6-2ubuntu7.1 last night is giving me persistent "out of range" errors on my monitor, regardless of whether i use nvidia, nv, or vesa driver
[15:25] <bjsnider> RAOF, that exact thing happened while i was trying to backtrace gnome-shell. it still crashes when i don't have gdb running.
=== Bernardo is now known as Bernardo|Away
=== evilshadeslayer is now known as shadeslayer
=== Bernardo|Away is now known as Bernardo
=== Bernardo is now known as Bernardo|Away
=== Bernardo|Away is now known as Bernardo
[21:53] <Sarvatt> argh
[21:53] <Sarvatt> dpkg-source: info: using source format `3.0 (quilt)'
[21:53] <Sarvatt> dpkg-source: warning: patches have not been applied, applying them now (use --no-preparation to override)
[21:54] <Sarvatt> hope that doesn't screw up the orig.tar.gz
[21:54] <Sarvatt> that was when doing debuild -S -sa
[22:18] <cnd> bryceh: do you know if I build X from git will it run on maverick?
[22:19] <cnd> I'm interested in knowing if X will work at all, or if it would need patches from our package
[22:37] <Sarvatt> wonder if i should update cairo on lucid edgers too
[22:38] <Sarvatt> RAOF: I refreshed the lcdfilter patch btw - http://sarvatt.com/downloads/patches/0001-Refresh-lcdfilter-patch-so-it-applies-to-1.9.8.patch
[23:00] <bryceh> cnd, should run fine
[23:01] <bryceh> cnd, Sarvatt actually has the best handle on peculiarities of the upstream git trees
[23:01] <jg> Sarvatt, RAOF: could I ask one of you to spin me something to try for https://bugs.freedesktop.org/show_bug.cgi?id=28070 (launchpad bug 585651)? The patch has converged to a very small one, and I have a new disk I can try installing onto....
[23:01] <ubot4> Launchpad bug 585651 in linux (Ubuntu) (and 1 other project) "Cannot install on eDP laptops such as HP Elitebook 2540p or 8440p (affects: 4) (heat: 149)" [High,Confirmed] https://launchpad.net/bugs/585651
[23:01] <bryceh> cnd, but RAOF and him have landed in maverick pretty much all the pre-reqs needed for the building the latest bits
[23:02] <ubot4> Freedesktop bug 28070 in Driver/intel "[Arrandale] No output (black) on eDP" [Major,New]
[23:04] <Sarvatt> jg: no I can't because I need a kernel deb to make you a new livecd, I'm sorry :(
[23:04] <Sarvatt> cnd: xserver 1.9 will be in edgers in a day or two, if you want to use it now you can add xorg-edgers and then also add my xorg-testing PPA
[23:05] <Sarvatt> cnd: add both xorg-edgers and https://launchpad.net/~sarvatt/+archive/xorg-testing
[23:06] <Sarvatt> cnd: plymouth/gdm hate it when the server doesn't support -nr, just a heads up :)
[23:06] <jg> Sarvatt: If I can generate a kernel deb for you??  I can borrow my daughter's machine, and build it there....
[23:07] <jg> Sarvatt: or can I put things on flash, and add the kernel deb myself?
[23:07] <Sarvatt> yeah then I can, making the debs right for ubuntu is pretty tricky though, make deb or make-kpkg wont work with a livecd as it is, you need to adapt the ubuntu kernel build system
[23:08] <Sarvatt> yeah if you have persistant storage you can just update it there
[23:09] <jg> Sarvatt: luckily I just bought myself a 4 gig usb key...
[23:09] <Sarvatt> if drm-intel-next worked i could just use that deb but the people on the bug report say it doesnt
[23:09] <jg> yeah, I know.  I'm screwed...
[23:09] <jg> the bug is still being chased by the intel developer.
[23:09] <Sarvatt> drm-intel-next kernels are available here - http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/
[23:10] <jg> the next time I see keithp I'm going to rib him about this...
[23:12] <jg> Sarvatt: I'll try the build my own and update a usb key method tomorrow, and see what happens.
[23:14] <jg> Sarvatt: hmmm... I may have put 32bit Lucid on my kids machine; I need to run 64 bit on my new toy.  Will that get me into trouble building the kernel?
[23:14] <Sarvatt> yeah, lots :(
[23:15] <jg> ugh...
[23:16] <jg> And this machine is running 32 bit, so upgrading it won't have the effect I want....
[23:16] <Sarvatt> can just use a 32 bit livecd for the testing
[23:17] <jg> true, but that doesn't get me a machine to carry with me to California next week, sparing me lugging two machines on the plane...
[23:18] <Sarvatt> if you can convince someone to pull it into drm-intel-next by then that'll work :)
[23:18] <Sarvatt> i can make ya a livecd with that kernel you can install from
[23:19] <Sarvatt> jg: which patch do you want to try specifically?
[23:19] <jg> heh... I can nudge the Intel guy to see if he's figured out why drm-intel-next doesn't work, despite Ajax's similar patch being upstream.
[23:21] <Sarvatt> need to see if it applies to the most recent lucid kernel
[23:21] <jg> https://bugs.freedesktop.org/show_bug.cgi?id=28070#c21 seems to be what the doctor ordered, until ykzhao figures out what's wrong with drm-next.
[23:21] <ubot4> Freedesktop bug 28070 in Driver/intel "[Arrandale] No output (black) on eDP" [Major,New]
[23:22] <Sarvatt> yeah but there are a bunch of patches in that bug
[23:22] <Sarvatt> someone was saying either one worked, not sure which you want to try or if you want to try both
[23:25] <jg> Sarvatt: this started as two patches; one of them sets the refresh speed to max, hardly desirable.  The other is the fix in c21.  The new mystery is why drm-next was having trouble.  I nudged ykzhao in case he's made progress (I think he's in China), and I can't set up to do anything before the morning, anyway.
[23:25] <Sarvatt> apw: is there any chance you might be willing to build a lucid kernel with http://bugs.freedesktop.org/attachment.cgi?id=35782 applied for possibly including in lucid regarding bug #585651 ?
[23:25] <ubot4> Launchpad bug 585651 in linux (Ubuntu) (and 1 other project) "Cannot install on eDP laptops such as HP Elitebook 2540p or 8440p (affects: 4) (heat: 149)" [High,Confirmed] https://launchpad.net/bugs/585651