[03:00] <superm1> so i'm having a hard time making sense of https://wiki.ubuntu.com/X/Bisecting . whenever i try to operate off of one of the "ubuntu" branches, as soon as i put in the good and bad commits, debian/ disappears 
[03:00] <superm1> so i could no longer run debuild etc
[03:00] <superm1> is that the intended behavior?  
[05:05] <tjaalton> bryce: mesa 7.4 is the stable release, 7.3 was a devel snapshot :)
[06:47] <DarknessssenkraD> Hi, I have a question, can I enable UXA on intrepid ibex?
[06:50] <RAOF> DarknessssenkraD: Yes.
[06:50] <RAOF> DarknessssenkraD: Sorry, I should read the actual question.  No :)
[06:50] <DarknessssenkraD> ok now I'm confused :P
[06:50] <DarknessssenkraD> so I can't :( ?
[06:52] <RAOF> That's right.  You can't.  I was thinking of Jaunty.
[06:52] <RAOF> Both the X driver and the kernel modules are too old to do that in Intrepid.
[08:20] <tjaalton> bryce: I've got a new wacom-tools (0.8.2.2) with the fedora patches to support proper hotplug (with all the devices, not just stylus). will test next
[08:20] <bryce> tjaalton: ok
[08:26] <tjaalton> according to the fdi file it should support serial devices too
[08:27] <bryce> nice
[08:28] <bryce> regarding mesa, I don't have an issue going to 7.4 if you'd like, but it should probably go in post-beta
[08:31] <tjaalton> of course
[08:32] <tjaalton> about the strange crasher with intel.. the backtrace mdz got had something about libdbus-1.. I wonder if --enable-config-dbus broke something
[08:33] <tjaalton> at least it's pretty much unmaintained upstream
[08:33] <tjaalton> and enabled only because of the wacom daemon which is not in the archive
[08:33] <tjaalton> (by Alexia)
[08:55]  * bryce nods
[08:55] <bryce> well, time for bed... got the desktop meeting in 6.5 hrs.  night.
[08:55] <tjaalton> night
[09:34] <tjaalton> wacom hotplug works, but my device still gets the "usbParse: Exceeded channel count" errors, and the cursor doesn't move
[09:35] <tjaalton> need to revert one change
[10:14]  * Ng hopes we can find and fix that intel crasher
[10:14] <seb128> what crasher?
[10:14] <Ng> LP #328035
[10:15] <seb128> I don't get this one
[10:15] <Ng> (bryce and tjaalton had a quick chat about it a while ago, I was just chiming in because it's annoying me, but I don't have anything useful to add, unfortunately ;)
[10:18] <seb128> but my box completely freezes on xorg session switches sometimes
[10:18] <seb128> which is really annoying
[10:18] <seb128> can't use guest session or user switch since jaunty
[10:18] <Ng> erk
[10:18] <Ng> I rarely use either. lemmie try Guest...
[10:18] <tjaalton> seb128: which driver? that happens with nvidia here
[10:18] <seb128> intel
[10:18] <tjaalton> ok
[10:18] <seb128> intel 965 card on a d630 laptop config
[10:19] <tjaalton> I'll try to reproduce on mine
[10:20] <Ng> well that didn't go well
[10:21] <Ng> guest session started ok, but the brightness was minimal and I couldn't change it (the notifications appeared, but nothing happened). logged out of the guest session and the screen stayed black, changing VT made no difference (I think because it just wasn't changing, or the chip was so wedged that it couldn't draw anything). sysrq s and u produced disk activity, but b did nothing
[11:48] <tjaalton> seb128: about user switch: here going back to the original user exits/crashes the second session
[11:48] <seb128> Ng: that seems similar to the issue I'm having there
[11:49] <seb128> tjaalton: I don't get that one
[11:50]  * Ng just dropped xorg-edgers PPA in and while I haven't had time to burn it in, so far having a slightly newer driver and UXA has fixed the most conspicuous problems I was having. Hardly a good solution this close to release though :/
[12:09] <tjaalton> Ng: can't seem to reproduce the crash with the non-dbus xserver
[12:10] <Ng> tjaalton: interesting, although do you have a reliable test case? it seems to be something that happens sometimes and often only when suspended for some time
[12:11] <tjaalton> no test case, just suspended a number of times
[12:16] <tjaalton> I'll let it sleep for a while now
[15:51] <tjaalton> Examining /etc/kernel/header_postinst.d.
[15:51] <tjaalton> run-parts: executing /etc/kernel/header_postinst.d/nvidia-common
[15:51] <tjaalton> run-parts: /etc/kernel/header_postinst.d/nvidia-common exited with return code 10
[15:51] <tjaalton> Failed to process /etc/kernel/header_postinst.d at /var/lib/dpkg/info/linux-headers-2.6.28-11-generic.postinst line 110.
[15:51] <tjaalton> sigh
[16:02] <tjaalton> mvo: hey, you have ideas why that ^^ happens? here's the more complete output: http://pastebin.ubuntu.com/136835/
[16:27] <bryce> morning
[16:28] <tjaalton> howdy
[16:28] <tjaalton> so, the new wacom package works properly with hotplug
[16:28] <tjaalton> had to revert one change in 0.8.2.2 though
[16:29] <bryce> Ng: that crash happens because of a bug in the log timestamping code
[16:29] <bryce> Ng: going to disable it asap
[16:29] <tjaalton> heh
[16:29] <Ng> bryce: yeah, I saw the bug mail. very happy that's been identified :)
[16:30] <tjaalton> hope it fixes my issues as well
[16:30] <Ng> although quite how time manages to go backwards while suspended.... *shrug*
[16:30] <bryce> tjaalton: you've had it too?
[16:30] <tjaalton> bryce: not necessarily the same, hard to say
[16:31] <bryce> there's enough bugs in -intel to go around, so maybe you have your own
[16:32] <tjaalton> hmm, blinking cursor on resume
[16:33] <tjaalton> last time I docked it when this happened, and the kernel crashed
[17:17] <mvo> tjaalton: run-parts: /etc/kernel/postinst.d/nvidia-common exited with return code 10 - what happens if you run this manually?
[17:18] <mvo> tjaalton: without the run-parts?
[17:18] <mvo> tjaalton: eh, nevermind
[17:18] <tjaalton> mvo: :)
[17:20] <mvo> tjaalton: is that from a bugreport or do you get it on your system? it looks like the nvidia-common debconf tempalte got not registered with debconf for some reason
[17:21] <superm1> of maybe debconf corruption
[17:21] <superm1> wasn't there a report from stgraber that there was corruption on a fresh install somehow too?
[17:21] <tjaalton> mvo: on my server yes
[17:21] <mvo> yep, corruption is quite possible as well
[17:21] <tjaalton> installed yesterday
[17:22] <stgraber> yeah, there was a bug with debconf corrupting the template
[17:22] <superm1> bug 347648
[17:22] <stgraber> it's been fixed by colin last night
[17:22] <tjaalton> oh, ok
[17:23] <superm1> so there is some benefit that i see all ~ubuntu-installer bugs :).  i thought i saw that fly by
[17:23] <tjaalton> heh :)
[17:23] <tjaalton> I get them too, but rarely have time to look at them
[17:24] <tjaalton> I'll reinstall it tomorrow anyway, so if it works then it's ok
[18:44] <tjaalton> bryce: mind pushing the xserver changes to git for easier review?
[19:05] <tormod> and please upload one of my patches for bug 328035 ...
[19:16] <bryce> tjaalton: sure
[19:16] <tjaalton> thanks :)
[19:17] <bryce> done
[19:17] <bryce> tormod: got it - https://edge.launchpad.net/~bryceharrington/+archive/ppa
[19:20] <bryce> tjaalton: probably too late now for -beta
[19:20] <tjaalton> bryce: no worries
[19:20] <tormod> bryce: I looked at the code and it seems to overflow the buffer after (ahem) 28 hours
[19:20] <bryce> tormod: O_o
[19:21] <tormod> 28 hours uptime should be enough for everyone :)
[19:21]  * tormod wears a brown paperbag
[19:21] <bryce> tormod: how do we not get tons of bug reports about that??
[19:22] <bryce> you know, I've not seen crashes at 28 hrs on my machines
[19:22] <tormod> that is one question I have - I guess small overflows 1-3 byte won't matter in many cases
[19:22] <bryce> yeah
[19:22] <bryce> well, overflow doesn't always result in crashes
[19:22] <tormod> because of word alignment etc
[19:22] <bryce> right
[19:22] <tormod> the second question I have is how could Matt get such a big negative number as a time delta?
[19:23] <bryce> anyway, I guess I can say my gut was right that we should have excluded the patch for -beta
[19:23] <tormod> yes, absolutely. and your initial analysis in the bug report was correct. I only saw it today.
[19:24] <tormod> is it not worthy a BFe?
[19:25] <bryce> I think it's worth it, just that cd's are already being spun...
[19:26] <tormod> I wonder if it would resolve a number of "random" crashes after resume
[19:27] <bryce> heh
 tormod has done some additional analysis and sees that there is a stack corruption after 28 hours with this patch
[19:27] <bryce>  I'm kicking myself for not pulling it out earlier.  I bet a number of our "random crashes" we've gotten lately have been an outcome of this patch
[19:27] <bryce> tormod: I had the same thought at the same time as you ;-)
[19:29] <tormod> Matt's time delta was -1009303149 seconds. how is that possible? is gettimeofday out whack for a second after resume? or is the casting of time intervals into int (?) the reason?
[19:31] <bryce> hmm, uninitialized value vs. a signed/unsigned value
[19:32] <tormod> I was thinking signed/unsigned but that number is like 1/4 of 2^32.
[19:32]  * bryce nods
[19:33] <tormod> bryce, btw, where was that <bryyce> quote from?
[19:34] <bryce> it's a pdx'er channel on LinuxNET 
[19:35] <tormod> pdx?
[19:35] <bryce> pdx == portland
[19:42] <bryce> sounds like snprintf ought to be used in that patch (or an X equivalent if it's not available)
[19:45] <tormod> well all lengths are known, except if the number of digits of the timestamp goes above the format specification. one could print the timestamp to a (large enough) buffer first and count the characters, but then you might as well make the target buffer large enough like I did in today's patch.
[19:46] <tormod> or truncate the timestamp of course
[19:50] <superm1> bryce, what are your feelings on that bug that i went and tracked down the commits from xorg server causing the troubles with mythtv?
[19:51] <superm1> unfortunately it will make mythbuntu beta disks kinda useless unless you are using closed drivers :(
[19:52] <mvo> bryce: hrm, I just fixed a bug in the fglrx -> ati transition code :/ looks like this needs to be in the beta notes that this is not working with the current u-m (the version in bzr should be fine though)
[19:54] <bryce> superm1: I looked at it briefly last night.  Good work chasing it down.  Since the patch made it through a freeze review and cherrypicked into the 1.6 release, I assume it solves an important bug, so am hesistant to drop it outright, so think the next step would be to raise the bug upstream for input
[19:55] <bryce> mvo: oh what is the trouble?
[19:55] <bryce> mvo: fwiw, I have some directions on fglrx -> ati, which I tested several times and found worked on my system:  
[19:55] <bryce> https://wiki.ubuntu.com/X/Troubleshooting/FglrxInteferesWithRadeonDriver
[19:56] <mvo> bryce: just a bug in update-manager, it marks the package for removal but then when it performs the upgrade forgets about that earlier marking :/
[19:57] <mvo> bryce: I did a initial test today with the fix and it looks fine, I will do a full upgrade test again tomorrow that includes the fix
[19:57] <mvo> but I'm pretty positive that this will then work
[20:16] <bryce> mvo: cool
[20:21] <kees> bryce: this updated patch for 160 will avoid the overflow creep: http://pastebin.osuosl.org/25076
[20:22] <kees> bryce: but I don't think upstream will take it, due to the asprintf use.
[20:23] <bryce> right
[20:23] <bryce> there may be an X equivalent.  I've added the patch to bug 328035 to keep track of it for now
[20:23] <kees> ah, cool
[20:27] <jcristau> isn't that bug caused by an ubuntu patch in the first place? :)
[20:27] <bryce> I think I'm going to require the patch to be gutted and rewritten before taking it in
[20:28] <bryce> jcristau: oh stop laughing at us.  ;-)
[20:28] <kees> jcristau: heh, good point.  though I was thinking someone might want to push timestamping upstream at some point.
[20:28] <jcristau> bryce: i'd never do that. then you'd talk to me about openssl.
[20:28] <kees> heh
[20:29] <kees> bryce: this is almost certainly the source of my USB crashes.  the USB disconnect would ... write a log entry.  :)
[20:29] <bryce> aha!
[20:29] <kees> but people doing suspend/resume, etc etc which my desktop never does would see it "right away" after 28 hours.
[20:29] <bryce> yeah, once tormod described what was going on, I wondered if this could be the source of a number of random crashes we've had.  I'll have to troll through our trackers a bit more closely
[20:31] <slangasek> jcristau: a patch following in the wonderful upstream example of sprintf and strcat, yes. :)
[20:34] <jcristau> slangasek: next you'll tell me that buffer overflows in setuid root code are bad.
[20:35] <jcristau> what's not to love about the X code? :)
[20:36] <slangasek> don't make me nostalgic for xmkmf
[20:45] <superm1> bryce, ack, i'll do that, thanks
[20:47] <tjaalton> bryce: ok, I'll mail ubuntu-devel about the new wacom-tools with proper hotplug, and ask people (in addition to davmor2) to test it
[20:47] <bryce> tjaalton: great thanks