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:27 |
stgraber | actually: "<cjwatson> except I vaguely remember looking at that before and deciding against - check ith RAOF to see if he remembers?" :) | 02:28 |
RAOF | Ah, so this is nvidia hardware but nouveau drivers, right? | 02:29 |
stgraber | nope, that was with the blob | 02:30 |
RAOF | I don't recall discussing this with Colin :/ | 02:30 |
RAOF | Does this also happen with nouveau? | 02:31 |
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:32 |
RAOF | Let me finish some testing and I'll flip the switch on my netbook :) | 02:33 |
stgraber | cool! | 02:33 |
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:34 |
Sarvatt | found your doctoral thesis! http://isotropic.org/papers/chicken.pdf | 02:45 |
Sarvatt | bah wrong channel | 02:45 |
Sarvatt | sorry :) | 02:45 |
RAOF | :) | 02:46 |
RAOF | stgraber: Sorry for the delay. Tested my netbook with nouveau, it displays the menu fine. Just installing the blob nowe | 06:57 |
RAOF | stgraber: And, yup, installing nvidia_current breaks the recovery mode in exactly the described fashion. | 07:07 |
=== ara is now known as Guest99538 | ||
=== Amaranthus is now known as Amaranth | ||
Amaranth | Sarvatt: was there any progress with getting the vmwgfx driver going in xorg-edgers? | 12:21 |
=== ara is now known as Guest78845 | ||
=== mvo_ is now known as mvo | ||
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:43 |
apw | Sarvatt, RAOF ^^ | 16:44 |
=== yofel_ is now known as yofel | ||
Sarvatt | RAOF: so ia32-libs breaks non mesa 32 bit libGL | 19:34 |
Sarvatt | it's installing a /usr/lib32/libGL.so.1 | 19:35 |
Sarvatt | http://people.ubuntu.com/~ricotz/tmp19573/GL | 19:39 |
Sarvatt | ugh | 19:39 |
ricotz | uh | 19:39 |
Sarvatt | oh nevermind! | 19:40 |
Sarvatt | he doesn't have a 32 bit nvidia libGL.so.1 in that, another person in the bug report does though | 19:42 |
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:44 |
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:45 |
bjsnider | would that bug still exist if they install wine:i386? | 19: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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
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:55 |
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:56 |
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:57 |
bryceh | since 507 was added in this development cycle, I don't think there'd be any issue dropping it. | 21:58 |
RAOF | It's not going to cause regressions from Natty, but it invalidates some testing. | 21:59 |
bryceh | RAOF, certainly; however there's still a couple weeks before release | 22:00 |
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:01 |
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:02 |
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:03 |
cnd | bryceh, ok, I can do that | 22:04 |
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:06 |
RAOF | Ack | 22:07 |
cnd | I'm going to assume bryceh is an Ack too | 22:14 |
bryceh | cnd, yep Ack | 22:14 |
cnd | ok, I'll get started after I take the dog out for a walk :) | 22:15 |
* RAOF finishes waking up. | 22:18 | |
cnd | bryceh, RAOF: the first server is uploaded | 23:13 |
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:14 |
RAOF | I don't think you do, no. | 23:15 |
cnd | ok, then I'll upload right after it's accepted | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!