[02:27] <stgraber> RAOF: hey! I've been poking at bug 854967 a bit this week and it seems clear that it's a problem between grub/kernel/nvidia driver
[02:27] <ubot4> Launchpad bug 854967 in friendly-recovery (Ubuntu) "boot to rescue mode in Oneiric (affects: 2) (heat: 12)" [Undecided,Incomplete] https://launchpad.net/bugs/854967
[02:27] <stgraber> RAOF: Colin told me about the use of "set gfxpayload=text" that worked fine on my test nvidia system but he seemed to remember a discussion with you regarding it
[02:28] <stgraber> actually: "<cjwatson> except I vaguely remember looking at that before and deciding against - check ith RAOF to see if he remembers?" :)
[02:29] <RAOF> Ah, so this is nvidia hardware but nouveau drivers, right?
[02:30] <stgraber> nope, that was with the blob
[02:30] <RAOF> I don't recall discussing this with Colin :/
[02:31] <RAOF> Does this also happen with nouveau?
[02:32] <stgraber> no idea, the machine I had around (I borrowed it, I only have intel ...) had the binary driver installed
[02:32] <stgraber> if you have a machine around that's running nouveau, it's pretty trivial to test with up to date oneiric. Just boot in recovery mode and if you can see the menu, you're good
[02:33] <RAOF> Let me finish some testing and I'll flip the switch on my netbook :)
[02:33] <stgraber> cool!
[02:34] <stgraber> would be great if I could have some data by tomorrow so I can talk to Colin about changing the gfxpayload value for recovery mode
[02:45] <Sarvatt> found your doctoral thesis! http://isotropic.org/papers/chicken.pdf
[02:45] <Sarvatt> bah wrong channel
[02:45] <Sarvatt> sorry :)
[02:46] <RAOF> :)
[06:57] <RAOF> stgraber: Sorry for the delay.  Tested my netbook with nouveau, it displays the menu fine.  Just installing the blob nowe
[07:07] <RAOF> stgraber: And, yup, installing nvidia_current breaks the recovery mode in exactly the described fashion.
=== ara is now known as Guest99538
=== Amaranthus is now known as Amaranth
[12:21] <Amaranth> Sarvatt: was there any progress with getting the vmwgfx driver going in xorg-edgers?
=== ara is now known as Guest78845
=== mvo_ is now known as mvo
[16:43] <apw> when you boot with the lid closed on a laptop who decides that that screen is not to be used
[16:43] <apw> (in an oniric KMS world)
[16:44] <apw> Sarvatt, RAOF ^^
=== yofel_ is now known as yofel
[19:34] <Sarvatt> RAOF: so ia32-libs breaks non mesa 32 bit libGL
[19:35] <Sarvatt> it's installing a /usr/lib32/libGL.so.1
[19:39] <Sarvatt> http://people.ubuntu.com/~ricotz/tmp19573/GL
[19:39] <Sarvatt> ugh
[19:39] <ricotz> uh
[19:40] <Sarvatt> oh nevermind!
[19:42] <Sarvatt> he doesn't have a 32 bit nvidia libGL.so.1 in that, another person in the bug report does though
[19:44] <Sarvatt> ok i'm going to stop looking at that bug until I'm done doing this other stuff, I'm confusing myself now :)
[19:45] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/852873
[19:45] <ubot4> Launchpad bug 852873 in ia32-libs (Ubuntu) "32 bit GL on amd64 is broken on oneiric with nvidia-graphics-drivers (affects: 18) (heat: 82)" [Medium,Confirmed]
[19:49] <bjsnider> would that bug still exist if they install wine:i386?
[21:49] <cnd> bryceh, RAOF: a couple weeks ago I pushed three patches from Carlos Garnacho into our xserver
[21:49] <cnd> they included fixes for the multitouch stuff
[21:49] <cnd> now I'm finding that one of them regresses behavior
[21:49] <RAOF> To what extent?
[21:49] <cnd> now, no one in the world other than Carlos and myself probably hit these code paths at this point
[21:50] <cnd> because there aren't any released applications that use touch grabs yet
[21:50] <cnd> ideally, I suppose i would like to revert the patch to make my development easier
[21:50] <cnd> however, it's not a really big deal, I can always run my own version of the server locally
[21:51] <bryceh> cnd, I'm fine with them being dropped
[21:51] <cnd> so I wanted your thoughts on whether I should push the patch in given the oneiric final freeze is less than 48 hrs from now
[21:51] <cnd> s/push the patch in/drop the patch/
[21:52] <cnd> will there be another upload before the final freeze?
[21:52] <cnd> or: any issues if I push another upload with just that change?
[21:52] <RAOF> I don't have one planned.
[21:53] <bryceh> me either
[21:53] <RAOF> What is the regression potential of dropping this patch?
[21:53] <bryceh> cnd, think it should be fine if you push an upload dropping a patch.  RAOF or I can do a debdiff review if that'd make you more comfortable
[21:54] <cnd> bryceh, I'm not too concerned with getting the upload right, just wanted to verify it won't hose anything up
[21:54] <cnd> RAOF, regression potential should be minimal
[21:54] <cnd> we've been running the same code in natty for quite a while
[21:55] <cnd> oh, I just reviewed the changes in my tree and realized there's one other *tiny* fix I have
[21:55] <bryceh> are these patches 505-507?
[21:55] <cnd> bryceh, just 507 needs reverting
[21:56] <cnd> and I would add: http://paste.ubuntu.com/698756
[21:56] <cnd> it fixes touch ownership events not being sent for non-emulated touches that have been rejected by the current owner
[21:56] <bryceh> do you have a bug# for that one?
[21:57] <cnd> I don't have a bug for either yet
[21:57] <cnd> I plan on filing them
[21:57] <cnd> I'm just running across these bugs today as I am developing the new utouch stack
[21:57] <bryceh> yeah just for tracking purposes at this stage in the release it's good to have bug #'s
[21:57] <cnd> yeah, I think uploads are required to have them during any freeze
[21:58] <bryceh> since 507 was added in this development cycle, I don't think there'd be any issue dropping it.
[21:59] <RAOF> It's not going to cause regressions from Natty, but it invalidates some testing.
[22:00] <bryceh> RAOF, certainly; however there's still a couple weeks before release
[22:01] <RAOF> Yeah.  I'm happy with the patch being dropped, but -release will want some bugs filed :)
[22:01] <bryceh> now, for the exevents.c patch, it's a different story... but it looks pretty trivial and I guess is an obviously correct change?
[22:02] <cnd> yeah, it's a very obviously correct change, if XI multitouch spec is obvious to you :)
[22:02] <bryceh> I don't have a feel for what the regression risk is for that but offhand it doesn't _look_ scary
[22:02] <cnd> note: that wasn't sarcasm
[22:02] <cnd> the function DeliverTouchOwnershipEvent does exactly what it says it does
[22:02] <cnd> and nothing more
[22:03] <bryceh> cnd, I might suggest breaking these up into two separate uploads.  Do the patch revert first.
[22:03] <cnd> bryceh, two uploads before the deadline tomorrow?
[22:03] <bryceh> that way the two changes can be evaluated separately, and if there is any worry/risk  over the exevents.c then just that revision can be reverted
[22:04] <cnd> bryceh, ok, I can do that
[22:06] <cnd> bryceh, RAOF: are we in agreement? I'll open two bugs and make two separate uploads for the patch reversion and the touch ownership event fix?
[22:07] <RAOF> Ack
[22:14] <cnd> I'm going to assume bryceh is an Ack too
[22:14] <bryceh> cnd, yep Ack
[22:15] <cnd> ok, I'll get started after I take the dog out for a walk :)
[22:18]  * RAOF finishes waking up.
[23:13] <cnd> bryceh, RAOF: the first server is uploaded
[23:14] <cnd> I'll wait until it is at least accepted into the archive before doing the second
[23:14] <cnd> do you know if I need to wait for it to be built and published before uploading the second
[23:14] <cnd> ?
[23:15] <RAOF> I don't think you do, no.
[23:15] <cnd> ok, then I'll upload right after it's accepted