| bryce | ok up to 5 now - #307609 | 00:07 |
|---|---|---|
| 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:08 |
| tjaalton | bryce: the configure script doesn't have an option to turn it off | 00:16 |
| tjaalton | so upstream should provide one | 00:16 |
| bryce | ok, so this should go upstream then. thanks | 00:17 |
| 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:22 |
| 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:23 |
| 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:24 |
| bryce | oh, it needs to have a check of some sort to not use altivec support with ppc? | 00:25 |
| tjaalton | oh, right | 00:25 |
| tjaalton | vmx/altivec | 00:26 |
| bryce | do you think appending --disable-vmx to the configure line should be sufficient? maybe I should ask the original reporter | 00:28 |
| bryce | ...asked. | 00:30 |
| tjaalton | should be enough | 00:31 |
| bryce | huh, `xkbcomp -C :0` busted | 00:32 |
| bryce | thanks kees | 00:32 |
| bryce | ;-) | 00:33 |
| tjaalton | what did he do this time?-) | 00:35 |
| bryce | ah, remember that presentation he gave at UDS about new compiler security checking stuff? seems xkbcomp is being naughty | 00:36 |
| 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:37 |
| bryce | I think I've filed wishlist bugs for at least a couple of those capabiltiies :-) | 00:38 |
| tjaalton | hehe | 00:38 |
| tjaalton | anyway, night -> | 00:40 |
| bryce | night | 00:42 |
| kees | i've got it fixed | 01:01 |
| 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:05 |
| kees | ah, cool | 01:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:24 |
| 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:25 |
| 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:26 |
| bryce | oh, yeah I guess it is | 01:27 |
| 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:28 |
| 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:48 |
| Rocket2DMn | I'll be chilling here for awhile, so just ping me if/when you're ready | 01:49 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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)? | 01:56 |
| bryce | hmm | 02:00 |
| 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:01 |
| Rocket2DMn | how i wish intrepid ran in a vbox | 02:02 |
| 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:03 |
| 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:04 |
| Rocket2DMn | yeah thats not good | 02:05 |
| Rocket2DMn | does that dump need to be extraced first? | 02:06 |
| Rocket2DMn | bryce, i got the same error you did (different address) | 02:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| bryce | nope, that latter one can probably be removed. Thought I'd already done that. | 02:13 |
| Rocket2DMn | yeah not so quick though | 02:13 |
| 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:14 |
| 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:15 |
| Rocket2DMn | lol that page is just and include of X/Backtracing | 02:16 |
| bryce | heh | 02:16 |
| 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:17 |
| Rocket2DMn | yeah probably just leave the wiki page | 02:18 |
| Rocket2DMn | ill post back to that bug | 02:19 |
| bryce | ok cool | 02:20 |
| 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:21 |
| Rocket2DMn | and there is possibly an infinite loop - can a backtrace actually catch that? | 02:22 |
| bryce | usually not | 02:22 |
| 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:23 |
| bryce | usually whatever gets printed out before it starts with the mieqEnequeue gobbltigook is what's relevant for the issue | 02:24 |
| 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:25 | |
| 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:26 |
| Rocket2DMn | the usual files? you mean xorg.conf, Xorg.0.log, dmesg? | 02:27 |
| bryce | Xorg.0.log, lspci -vvnn, xorg.conf, yeah. Sometimes photos if there's screen corruption. | 02:29 |
| Rocket2DMn | alright ill get as much as i can from this person | 02:33 |
| Rocket2DMn | should i have them remove that testing driver? | 02:34 |
| bryce | nah, that's not a big deal | 02:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| Rocket2DMn | alright ill leave this one alone, it looks like a bad download or something anyway | 02:44 |
| bryce | yup | 02:44 |
| 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 | 02:45 |
| * bryce waves to tseliot | 09:50 | |
| tseliot | hey bryce | 09:50 |
| 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:07 |
| jcristau | just needs a new upstream, afaict | 19:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!