[00:07] <bryce> ok up to 5 now - #307609
[00:08] <bryce> tjaalton: you might want to peek at that bug 307609
[00:08] <ubottu> Launchpad bug 307609 in pixman "libpixman is built with Altivec on ppc" [Undecided,Incomplete] https://launchpad.net/bugs/307609
[00:16] <tjaalton> bryce: the configure script doesn't have an option to turn it off
[00:16] <tjaalton> so upstream should provide one
[00:17] <bryce> ok, so this should go upstream then.  thanks
[00:22] <bryce> hum
[00:22] <bryce> dnl Check for VMX/Altivec
[00:22] <bryce> if test -n "`$CC -v 2>&1 | grep version | grep Apple`"; then
[00:22] <bryce>     VMX_CFLAGS="-faltivec"
[00:22] <bryce> else
[00:22] <bryce>     VMX_CFLAGS="-maltivec -mabi=altivec"
[00:22] <bryce> fi
[00:23] <bryce> configure.ac does seem to have stuff for altivec support
[00:23] <tjaalton> yes, but it only checks the arch
[00:23] <bryce> --disable-vmx seems to be the switch associated with it
[00:24] <bryce> ok, I guess I don't understand exactly what we require... if you can jot a few notes I can upstream it right now
[00:25] <bryce> oh, it needs to have a check of some sort to not use altivec support with ppc?
[00:25] <tjaalton> oh, right
[00:26] <tjaalton> vmx/altivec
[00:28] <bryce> do you think appending --disable-vmx to the configure line should be sufficient?  maybe I should ask the original reporter
[00:30] <bryce> ...asked.
[00:31] <tjaalton> should be enough
[00:32] <bryce> huh, `xkbcomp -C :0` busted
[00:32] <bryce> thanks kees
[00:33] <bryce> ;-)
[00:35] <tjaalton> what did he do this time?-)
[00:36] <bryce> ah, remember that presentation he gave at UDS about new compiler security checking stuff?  seems xkbcomp is being naughty
[00:37] <tjaalton> ah ok
[00:37] <tjaalton> 02:36 < Atomo64> lp should be designed to cope with the kind of users it has; one should be  able to split, remove, merge, clone, and more (all forms editing, IOW)
[00:37] <tjaalton> from #debian-x
[00:37] <tjaalton> makes sense..
[00:37] <bryce> completely agreed
[00:38] <bryce> I think I've filed wishlist bugs for at least a couple of those capabiltiies :-)
[00:38] <tjaalton> hehe
[00:40] <tjaalton> anyway, night ->
[00:42] <bryce> night
[01:01] <kees> i've got it fixed
[01:05] <bryce> https://bugs.freedesktop.org/show_bug.cgi?id=19490
[01:05] <ubottu> Freedesktop bug 19490 in App/xkbcomp "Buffer overflow in WriteCHdrKeyTypes running 'xkbcomp -C :0'" [Normal,New]
[01:07] <kees> ah, cool
[01:08] <bryce> kees, are you going to package and upload the patch, or shall I?
[01:08] <kees> bryce: well, I wanted to test it first, but the patch system hates me
[01:09] <bryce> ah
[01:09] <bryce> yeah looks like there isn't a patch system
[01:09] <kees> debian/xsfbs/xsfbs.mk says "quilt"
[01:09] <bryce> dpatch:
[01:09] <bryce>   - Add "dpatch" to debian/control Build-Depends
[01:09] <bryce>   - Change debian/rules to include dpatch makefile
[01:09] <bryce>     "include /usr/share/dpatch/dpatch.make"
[01:09] <bryce>   - Update the "build" and "clean" rules
[01:09] <bryce>     "build-stamp: -> build-stamp: patch"
[01:09] <bryce>     "clean: -> clean: clean-patched unpatch"
[01:09] <bryce>     "clean-patched:"
[01:09] <bryce> er
[01:09] <bryce> nevermind that
[01:10] <bryce> quilt:
[01:10] <bryce>   - Copy xsfbs dir into debian/ if needed
[01:10] <bryce>   - In debian/control add quilt as a Build-Depends
[01:10] <bryce>   - In debian/rules, add these lines:
[01:10] <bryce> PACKAGE = <packagename>
[01:10] <bryce> include debian/xsfbs/xsfbs.mk
[01:10] <kees> OH! it _missing_ quilt as a build-dep
[01:10] <bryce> ...
[01:10] <bryce> build: patch build-stamp
[01:10] <kees> it's got all the support for it, it's just not actually pulling quilt in
[01:10] <bryce> aha
[01:10] <bryce> ok, feel free to upload that once you've confirmed it 
[01:24] <kees> Could not load keyboard geometry for :0.0 ... 
[01:24] <kees> should it be able to run?
[01:24] <bryce> hmm
[01:24] <bryce> I think that might be an acceptable response
[01:25] <bryce> yep
[01:25] <bryce> I get the same thing if I run just 'xkbcomp :0'
[01:25] <bryce> in any case if that's wrong, it's unrelated to the buffer overflow I think
[01:26] <kees> cool.  I fixed 2 more overflows before it'd give me a normal exit.  :P
[01:26] <kees> updated the upstream bug patch and am uploading to jaunty now
[01:26] <bryce> I'm not certain that 'xkbcomp -C :0' is correct usage
[01:27] <bryce> oh, yeah I guess it is
[01:28] <bryce> but I just get error messages, strange
[01:28] <bryce> bryce@chideok:~/src/xorg/xorg-ubuntu-git/debian/apport$ xkbcomp :0
[01:28] <bryce> Warning:          Could not load keyboard geometry for :0
[01:28] <bryce>                   BadAlloc (insufficient resources for operation)
[01:28] <bryce>                   Resulting keymap file will not describe geometry
[01:48] <Rocket2DMn> Hey guys, I ran across a few X related bugs this evening, I kept my eyes open for them at your request.  I need help triaging them though since I'm not an X pro.
[01:49] <Rocket2DMn> I'll be chilling here for awhile, so just ping me if/when you're ready
[01:51] <bryce> sure
[01:51] <bryce> I'm just going through bugs
[01:51] <bryce> heh  "lspci -vvnn ? what things are these and can it be done on desktop, no command line to me."
[01:51] <bryce> (272814)
[01:52] <Rocket2DMn> lol, nice
[01:52] <Rocket2DMn> alright, let's start with bug 315603
[01:52] <ubottu> Bug 315603 on http://launchpad.net/bugs/315603 is private
[01:53] <Rocket2DMn> looks like the retrace failed, thought idk how useful those are to you guys.  There is no backtrace but there is a CoreDump
[01:54] <Rocket2DMn> i haven't a clue how to access a coredump or if there is anything useful there for the humna eye anyway if it does get interpreted from its binary format
[01:54] <bryce> yeah the retracer often fails
[01:55] <bryce> but the backtraces it gathers are hardly ever sufficient.  we almost always end up asking the user to collect a full backtrace and reference them to wiki.ubuntu.com/X/Backtracing for directions
[01:55] <Rocket2DMn> yesterday you guys suggested getting a dump rather since getting that backtrace was such a pain, is there enough info in a dump to do a triage?
[01:55] <bryce> maybe
[01:55] <Rocket2DMn> seems like the guy who filed that report doesnt know much either, and may not be able to reproduce the crash at will
[01:55] <bryce> I've never actually tried that myself.  in theory though it should work (that's what the retracer is doing)
[01:56] <bryce> quite true
[01:56] <Rocket2DMn> so i guess the question is - what do we do with that report? mark it as triaged?  how do i know if there is enough in the coredump (and how would i even check)?
[02:00] <bryce> hmm
[02:01] <bryce> try this
[02:01] <bryce> sudo gdb /usr/bin/Xorg /whatever/core
[02:01] <bryce> Then run the "backtrace full" command inside gdb. 
[02:01] <Rocket2DMn> you mean me download the coredump and do that?
[02:02] <Rocket2DMn> how i wish intrepid ran in a vbox
[02:03] <bryce> that's right
[02:03] <bryce> I'll try it too
[02:03] <Rocket2DMn> i need to install the necessary packages on my intrepid laptop first
[02:03] <bryce> hrm
[02:04] <bryce> well looks fairly useless to me so far...
[02:04] <bryce> (gdb) bt full
[02:04] <bryce> #0  0x0000000000000000 in ?? () from /lib64/ld-linux-x86-64.so.2
[02:04] <bryce> No symbol table info available.
[02:04] <bryce> Cannot access memory at address 0xbfd7250800000001
[02:05] <Rocket2DMn> yeah thats not good
[02:06] <Rocket2DMn> does that dump need to be extraced first?
[02:08] <Rocket2DMn> bryce, i got the same error you did (different address)
[02:09] <bryce> yeah I'm not sure what to do from here
[02:09] <bryce> normally I'd ask the user to reproduce the crash and collect a backtrace manually
[02:10] <bryce> like you said, most of the time that's way over their head so we kind of get collectively stuck at that point
[02:10] <Rocket2DMn> well we still can, but we're likely to get a no response or a "duh what?"
[02:11] <Rocket2DMn> i guess it's worth setting to incomplete and asking, if they dont get back in 60 days, close it as an expired bug
[02:12] <Rocket2DMn> is there a reason you keep 2 copies of that X/Backtracing page? the one on the wiki and https://wiki.ubuntu.com/DebuggingXorg
[02:13] <bryce> nope, that latter one can probably be removed.  Thought I'd already done that.
[02:13] <Rocket2DMn> yeah not so quick though
[02:14] <Rocket2DMn> https://wiki.ubuntu.com/Bugs/Responses#Missing%20a%20back%20trace
[02:14] <bryce> yeah I've just finished looking through gdb help to see if there's any commands that'd be useful, but am not seeing something obvious
[02:14] <Rocket2DMn> wait hold wrong link
[02:14] <bryce> My stock backtrace-needed reply is "Are you able to reproduce this issue? If so, please collect a full backtrace - see http://wiki.ubuntu.com/X/Backtracing for directions."
[02:14] <Rocket2DMn> nvm
[02:15] <Rocket2DMn> ok that second page is linked from https://wiki.ubuntu.com/DebuggingProgramCrash
[02:15] <bryce> often I also ask for steps to reproduce the problem if not given already
[02:16] <Rocket2DMn> lol that page is just and include of X/Backtracing
[02:16] <bryce> heh
[02:17] <bryce> that's probably fine then; there are probably old forum posts and bugs and stuff referencing that old link
[02:17] <bryce> I've been trying to consolidate all the X info under the X/ namespace
[02:18] <Rocket2DMn> yeah probably just leave the wiki page
[02:19] <Rocket2DMn> ill post back to that bug
[02:20] <bryce> ok cool
[02:21] <Rocket2DMn> alright done.
[02:21] <Rocket2DMn> next one, bug 315542
[02:21] <ubottu> Launchpad bug 315542 in xserver-xorg-video-intel "X hangs on ubuntu 8.1 intrepid laptop" [Undecided,New] https://launchpad.net/bugs/315542
[02:21] <Rocket2DMn> the gal is using unofficial drivers to try and get it working
[02:22] <Rocket2DMn> and there is possibly an infinite loop - can a backtrace actually catch that?
[02:22] <bryce> usually not
[02:23] <Rocket2DMn> didnt expect so
[02:23] <bryce> these infinite loop bugs are a bit harder to debug.  I spent some time with jesse (from Intel) asking about tricks for debugging these
[02:23] <bryce> in this case the problem looks like this:
[02:23] <bryce> (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error
[02:24] <bryce> usually whatever gets printed out before it starts with the mieqEnequeue gobbltigook is what's relevant for the issue
[02:25] <bryce> here's my notes...
[02:25] <bryce> Lockups
[02:25] <bryce> * Black screen, with stuff otherwise still functional - mode issues, so collect intel_reg_dumper output.
[02:25] <bryce> * hard hangs - pipe quirks, could be modesetting related
[02:25] <bryce> * wait lp ring soft hangs - render accel or 3d bugs.  Try turning off DRI or EXANoComposite to try isolating where they occur.  I\
[02:25] <bryce> f it occurs with a specific application with/without DRI.
[02:25] <bryce> * Screen corruption.  Having a photo helps.  Short lines 8px wide, will be GPU related.  Long lines will be tiling issues.
[02:25] <bryce> Screensaver just pulls from the framebuffer
[02:25] <bryce> sysprof can help with high cpu issues
[02:25] <bryce> ltrace sometimes useful
[02:25] <bryce>  
[02:26] <bryce> In general, with these kinds of bugs triaging is going to be limited to making sure they have the usual files, and a good precise set of steps to reproduce, and the conditions under which the bug occurs
[02:26] <bryce> e.g., with or without compiz, with certain programs loaded, etc.
[02:27] <Rocket2DMn> the usual files? you mean xorg.conf, Xorg.0.log, dmesg?
[02:29] <bryce> Xorg.0.log, lspci -vvnn, xorg.conf, yeah.  Sometimes photos if there's screen corruption.
[02:33] <Rocket2DMn> alright ill get as much as i can from this person
[02:34] <Rocket2DMn> should i have them remove that testing driver?
[02:35] <bryce> nah, that's not a big deal
[02:36] <Rocket2DMn> ok, in that case the bug is filed against the intel driver, not xorg-server, should i switch it
[02:36] <bryce> yep
[02:37] <Rocket2DMn> ok, but the error above is from the driver still: (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error
[02:37] <Rocket2DMn> ill put it on xorg-server
[02:38] <bryce> oops wait, I read your comment backwards (sorry, wife just came home so I'm distracted)
[02:38] <bryce> yes leave it against the -intel drivers
[02:39] <Rocket2DMn> hehe oops, ok i changed it back
[02:39] <bryce> as a general rule, if in question, default to filing against the driver, because there are more active engineers focusing on drivers than there are on the xserver
[02:39] <Rocket2DMn> bugmail spam heading your way
[02:39] <Rocket2DMn> ok, noted.
[02:39] <Rocket2DMn> and on the topic of drivers, bug 315274
[02:39] <ubottu> Launchpad bug 315274 in patch "Updating of ATI drivers crashes" [Undecided,New] https://launchpad.net/bugs/315274
[02:40] <Rocket2DMn> i assume that should be filed against fglrx-driver and not patch
[02:40] <bryce> hehe
[02:40] <bryce> yep, that's right
[02:41] <Rocket2DMn> i guess that is just an update failure, not an X crash
[02:41] <bryce> also fwiw oftentimes these problems with crashes from upgrades with fglrx are due to them having mixed up -ati and -fglrx installs
[02:41] <bryce> each of them provide certain glx files, so having both installed end up causing toe-stepping
[02:42] <bryce> the solution is to do a complete purge of the driver they don't want, and a full reinstall of the driver they do want
[02:42] <bryce> not enough info in this bug report to know for certain that's the problem here, but that'd be my gut guess
[02:42] <bryce> also, most flgrx bugs are not going to be going anywhere
[02:43] <Rocket2DMn> yeah ive noticed restricted driver bugs dont get a lot of love
[02:43] <bryce> I am an contact with the ATI guys and able to pass a >few< bugs up to them, but really only ones that are pervasive, easily reproduced, and/or very well reported go up
[02:43] <bryce> imho it's barely worth the trouble to triage fglrx bugs
[02:44] <Rocket2DMn> alright ill leave this one alone, it looks like a bad download or something anyway
[02:44] <bryce> yup
[02:45] <bryce> ok, sorry wife wants me to take her out to dinner so I gotta run.
[02:45] <Rocket2DMn> ok, we're done, thanks bryce , have fun
[09:50]  * bryce waves to tseliot
[09:50] <tseliot> hey bryce
[19:07] <pwnguin> what else is needed for triage on bug #315882?
[19:07] <ubottu> Launchpad bug 315882 in xserver-xorg-input-synaptics "[Jaunty] synaptics fdi file does not contain entry for touchpads know as "ETPS/2 Elantech Touchpad" starting with 2.6.28 series kernels" [Undecided,New] https://launchpad.net/bugs/315882
[19:13] <jcristau> just needs a new upstream, afaict