[00:38] <RAOF> bryceh: Speaking of plymoth transitions, would you like to sponsor an xserver-xorg-video-nouveau upload with an -nr patch attached?
[00:41] <bryceh> RAOF, sure
[00:42] <RAOF> It's in pkg-xorg git, or I could attach a debdiff if you'd prefer.
[00:43] <bryceh> git's fine
[00:45] <bryceh> RAOF, looks good, upload sponsored
[00:46] <RAOF> Thanks.
[00:47] <bryceh> wow, nvidia.man is way out of date
[00:47] <bryceh> someday we should update that :-)
[01:22] <RAOF> Hm.  The intel gpu lockup event code looks like it'd be quite easy to port to nouveau :/
[05:12] <RAOF> Sarvatt: Do you have that upstream link for the plymouth bug?  I think it's time to actually tell launchpad about it!
[05:50] <vish> jcristau: hi. :) i had mentioned it to the cairo-dock team to contact you guys , since they had several OpenGL bugs and Sarvatt had mentioned that the mesa devs were not happy with how cairo-dock was doing its stuff.  [i forgot what Sarvatt mentioned exactly ]  hence it might have been a bit confusing to understand what they[fabounet/mattbe] were trying to get at.
[05:51] <vish> mostly they wanted to get in touch with the mesa devs who knew what the problem was and what the cairo-dock was doing wrong ;)
[05:53]  * vish hopes #dri-devel was the channel Sarvatt mentioned :)
[05:54] <vish> Sarvatt: anyone particular the cairo-dock team needs to get in touch with? 
[06:58] <RAOF> Eep!  Random people filing crazy bugs with nouveau upstream :(.
[07:01] <bryceh> ?
[07:01] <RAOF> Oh, just one of our users testing nouveau & filing bugs simultaneously in launchpad and upstream with nouveau.
[07:02] <RAOF> Filing *bad* bugs simultaneously upstream and in launchpad; basically "my log contains (EE) AIGLX: can't load /usr/lib/dri/nouveau_dri.so".
[07:02] <bryceh> ah
[07:03] <RAOF> Also, I'm fixing the xorg apport hooks; there are a couple of problems in the recent upload.
[07:03] <bryceh> oh?
[07:04] <RAOF> Things like “lsb_release -c" returning "Codename:\tlucid" rather than "Codename:  lucid", so the hook crashes and doesn't attach the extra information.
[07:04] <RAOF> Just a couple of small things.
[07:05] <RAOF> A missing comma in a list.
[07:05] <bryceh> ahh
[07:06] <superm1> RAOF, lsb_release -sc instead
[07:07] <superm1> then you dont need to try to parse whitespace 
[07:07] <RAOF> Ah, there was one substantial question I wanted to ask about that: how would you like people running “ubuntu-bug xserver-xorg-video-nouveau” handled - reading the GDM logs requires root, and so it will currently (once it's fixed) ask whether to add logs it can't actually add.
[07:07] <RAOF> superm1: Thanks!  I'll use that instead.
[07:09] <RAOF> There doesn't seem to be a good way to escalate to root in the apport hook, so we can either (a) only ask that message when run as root, or (b) when not run as root, ask people to re-run ubuntu-bug with root privs.
[07:10] <bryceh> it can't add the gdm logs?
[07:10] <bryceh> I think I added in the right code to cause apport to prompt for gksudo, however I haven't tested it
[07:10] <RAOF> It can't read the logs unless it's run as root.  And people can (and I *did*) run ubuntu-bug as not-root.
[07:10] <bryceh> right, I *think* apport will prompt for that now.  worth testing
[07:11] <bryceh> also, regarding how to call ubuntu-bug, I've been recommending people just file them via 'ubuntu-bug xorg'
[07:11] <RAOF> Well, right now it won't, because the hook crashes a couple of times before getting there.  And when I've fixed that up, I don't think ui.yesno actually escalates to root?
[07:11] <bryceh> then I have a cronjob on my end that reviews the bug reports and reassigns them to the driver package as appropriate
[07:12] <RAOF> Ok.  I'll do that in future.  Easier to type :)
[07:13] <bryceh> yeah, and it turned out users got really confused 
[07:14] <RAOF> There's a fair scope for users to get confused, yeah.
[07:14] <bryceh> some would file against xserver-xorg-driver-*, others would file driver bugs against xorg-server, or vice versa
[07:17] <bryceh> regarding reading gdm.log as root, I'll get that fixed up
[07:17] <tjaalton> bryceh: check bug 529583, the new apport code is probably a bit too effective :)
[07:17] <ubottu> Launchpad bug 529583 in xserver-xorg-video-intel "I do not know why his bug" [Undecided,Incomplete] https://launchpad.net/bugs/529583
[07:18] <bryceh> tjaalton, heh
[07:18] <RAOF> bryceh: I'll push the other fixes up to pkg-xorg git.
[07:18] <bryceh> ok, let me know once they're merged
[07:20] <bryceh> tjaalton, yeah we'll have to decide how to handle these kinds of bugs.  It seems a bad idea to send them upstream if the user is clueless, but freezes are not things we're going to be able to fix ourselves.
[07:38] <bryceh> RAOF, ok I'll tackle the gdm.log root stuff tomorrow
[07:38] <RAOF> I've just managed to make it work.
[07:38] <bryceh> basically the commands just need switched over to use root_command_output()
[07:38] <RAOF> Yup.
[07:39] <RAOF> Just writing the commit message.
[07:39] <bryceh> great
[07:39] <RAOF> Pushed to pkg-xorg git.
[07:40] <RAOF> I guess I should write a debian/changelog entry, too, while I'm at it.
[07:41] <RAOF> There we go.
[07:54] <bryceh> yep looks good
[10:10] <RAOF> Well, at least *some* people are finding nouveau nice; here's a bug about gnome-shell not working on the second monitor plugged into the displayport on the macbook!
[10:20] <bryceh> heh
[11:00] <apw> bryceh, do i expect my keymaps to get flushed when i VT switch?
[11:00] <apw> (or indeed anyone)
[11:01] <apw> also is restoration of CAPS etc LED state on return to X a userspace thing or ?
[12:37] <radoe> Hello. May someone please have a look at bug 402260? I have a debdiff ready and attached and also an ack from ubuntu-sru for a SRU regarding this bug. How to proceed further with this? Thx.
[12:37] <ubottu> Launchpad bug 402260 in xorg-server "[Needs SRU] segfault when running Xdmx" [Undecided,Fix released] https://launchpad.net/bugs/402260
[15:57] <superm1> apw, when a system is triggering the high temperature switch, does the kernel actually call into /sbin/shutdown, or does it arrange for a shutdown a different way?
[15:59] <apw> superm1, normally the bios takes the machine out without any indication or time to stop it
[16:00] <apw> there is a bug somewhere in lucid which is breaking the temp sensors on one of my dells, which stops the sensors and fans responding correctly after a suspend/resume ...
[16:00] <superm1> well the problem i'm looking at is actually in karmic
[16:00] <superm1> and i'm trying to figure out what is sending a SIGTERM and someother signal to all running apps during a factory install
[16:01] <superm1> given the machines are in burn racks, i'm starting to wonder if temperature was playing into the problem
[16:02] <superm1> so if the kernel was actually calling /sbin/shutdown or some other means to send signals like that to everything it sounds like its at least a possible venue for the problem
[16:02] <hyperair> i don't think the kernel calls /sbin/shutdown when overheating..
[16:02] <hyperair> it just hangs.
[16:30] <apw> superm1, right, i'd expect it to just stop dead and turn off, thats what mine does here
[16:30] <superm1> apw, dang.  back to the drawing board then :(
[16:31] <apw> well its worth asking cjwatson if there is anything else
[16:31] <apw> i'd expect that kind of thing if they ran out of battery for example
[17:32] <Ng> apw: superm1: fwiw, my laptop BIOS sends an ACPI event to linux and the machine shuts down gracefully. I had my laptop wake up for some reason once in my bag, hit 127 degrees C and then log that and shut down :/
[17:34] <hyperair> mine stopped dead while compiling kernels.
[17:35] <hyperair> and also compiling codelite
[17:35] <hyperair> kinda painful when doing testbuilds
[17:35] <hyperair> have to ^Z every 15 minutes
[17:35] <hyperair> wait for 15 minutes, then fg
[17:35] <hyperair> that was until i discovered PHC =D
=== radoe_ is now known as radoe
[18:32] <superm1> Ng, yeah that's what i was hoping is possible; it definitely coo-berates with the symptoms of this problem
[19:06] <bryceh> apw, keymap flushing should not happen when VT switching.  However losing keymaps is a common problem when unplugging/replugging the keyboard so perhaps its related to that?
[19:19] <apw> bryceh, i definaly get reset to UK layout on switch in and out of X
[19:19] <bryceh> apw, is that a new behavior?
[19:20] <apw> bryceh, i do it so rarely that i doubt i'd have noticed, i only did it today to test what appears to be a bug in LED handling for capslock and numlock over the same VT switch
[19:20] <apw> and said i couldn't test caps as i delete the key, and found it had come back!
[19:20] <bryceh> hmm
[19:22] <bryceh> can you see any evidence of any devices enabling/disabling through that?
=== Sinnerman is now known as Cobalt
[19:39] <tjaalton> bryceh: hey, we should probably upload mesa and xserver from git?
[19:40] <apw> bryceh, the only dmesg i get in that switch and back is this:
[19:40] <apw> [39732.660911] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[19:40] <apw> [39732.821452] Skipping EDID probe due to cached edid
[19:42] <bryceh> tjaalton, sounds good
[19:42] <bryceh> tjaalton, now that a3 is out it's a good time to upload
[19:43] <bryceh> apw, that first one I think might be plymouth
[19:43] <bryceh> apw, the second is just a kernel info message (in fact that should probably be commented out in the kernel as I've seen some people's logs where it gets pretty spammy)
[19:44] <apw> yeah that secnd one comes out scarily often
[19:45] <tjaalton> bryceh: yeah
[19:46] <apw> bryceh, i get a bunch of this on switch and back in Xorg.log
[19:46] <apw> (II) "Power Button": Device reopened after 1 attempts.
[19:47] <apw> and so on for everything that is an input device
[19:47] <tjaalton> bryceh: I'll upload them later unless you want to do the honors :)
[19:47] <apw> bryceh, we 
[19:47] <apw> bryceh, we get any feedback on the backport kernel?
[19:48] <apw> we have some positive noises from owners of some h/w
[19:50] <bryceh> tjaalton, go for it
[19:50] <bryceh> apw, jamie said it didn't fix the issue on his old radeon chip
[19:51] <apw> bryceh, hell, so no modeset for him then
[19:51] <bryceh> which is ironic since that's the issue that started us down this whole path, and that airlied said would be fixed if we went to .33
[19:51] <apw> .33 is much a pile of doings as anything else
[19:51] <bryceh> aside from that I've seen no negatives
[19:52] <apw> me either ... so i am angling to make any decision official
[19:52] <bryceh> great!
[19:52] <apw> i have an upload todo today, for everything before drm
[19:52] <apw> and then will push that in a couple of days, if you concur its a better place to be than .32
[19:53] <bryceh> btw, 'no modeset for him' -> have we a kms per-card blacklist set up?  I'd like to document the steps if so
[19:53] <apw> bryceh, nope, we don't
[19:53] <bryceh> yes I concur
[19:53] <apw> but we hoped to avod it by fixing him, but if it doesn't then a per id list will be needed
[19:53] <apw> which i will have to go add i suspect
[19:53] <bryceh> apw, ok well it's orthogonal to the .33 decision, but still would be worth having
[19:54] <apw> yep.  a generic list in drm is appropriate, as nomodeset is there it should be ok
[19:55] <apw> bryceh, will we have UMS still for i915 in lucid?
[19:56] <bryceh> apw, yes
[19:56] <apw> thats something at least, at least nomodeset will mean something across the board
[19:56] <bryceh> apw, I think we've more or less convinced ourselves to stick with 2.9.1 and retain UMS as an option on intel
[19:56] <bryceh> yeah
[19:56] <apw> bryceh, can i also confirm that to your knowledge there is no way to override the mode selected in KMS as it stands?
[19:57] <bryceh> someone mentioned some idea of lucid being "the last Ubuntu with UMS" so KMS by default with UMS as an option across the board feels quite right
[19:57] <bryceh> apw, that's correct to my knowledge - I dug around in the kernel code but didn't find anything
[19:58] <bryceh> nor have I run into online docs about this
[19:58] <bryceh> I definitely think it's something we're going to need
[19:58] <apw> it seems a major oversight that i cannot quite fathom how we have not noticed before
[19:58] <bryceh> having UMS as a fallback slightly reduces the severity of this issue, but it's not a good long term solution obviously, and is probably more hackery than most people would expect to need to do
[19:59] <bryceh> apw, other larger issues distracting us maybe?  ;-)
[20:01] <apw> bryceh, yeah i guess ... arrgllle
[20:15] <jcristau> setting the mode from the kernel command line doesn't work?
[20:16] <jcristau> fwiw it looks like debian will be going with the drm .33 backport
[20:17] <bryceh> jcristau, good to know