[00:00] <Sarvatt> sudo tune2fs -C 200 /dev/sdax to force a fsck
[00:01] <rye[fixing-x]> Sarvatt, the initrd archive contains regular file, hm...
[00:01]  * rye[fixing-x] has not enough knowledge about the boot process
[00:06] <Sarvatt> looks like it uses the ones in / by the time it tries to load the video driver from that bugs dmesg and it just packs all the modprobe.d confs in incase any of them are relevant early
[00:06] <RAOF> So, just a regular reboot worked fine.
[00:07] <RAOF> I'll force a fsck.
[00:08] <BUGabundo> great
[00:08] <BUGabundo> going to a tty, closed my gdm and session :(
[00:09] <BUGabundo> any logs you guys might find useful ?
[00:10] <Sarvatt> rye[fixing-x]: was that bug i linked earlier yours?
[00:10]  * Sarvatt cant load launchpad
[00:12] <rye[fixing-x]> Sarvatt, erm... what bug? The one with backlight - yes, that was mine, bug 534469 is not mine, but I have the same symptom, I suppose
[00:12] <ubottu> Launchpad bug 534469 in nvidia-graphics-drivers "Failed to load NVIDIA 195.36.08 kernel modules because nouveau is loading." [Undecided,New] https://launchpad.net/bugs/534469
[00:12] <Sarvatt> ah ok
[00:12] <RAOF> Ok.  And booting with a fsck still works.
[00:12] <rye[fixing-x]> Sarvatt, subscribed to it...
[00:13] <RAOF> So, it looks like this is only an issue for those with /usr on a separate partition?  In which case, I'm back to f-spot hacking.
[00:13]  * rye[fixing-x] wants to drop separate partitions, since he has issues with mounted, ureadahead and now with X due to separating of /usr and /var...
[00:15] <BUGabundo> Sarvatt: RAOF: you guys want my xorg logs? would be nice to see this not happen again :(
[00:16] <RAOF> BUGabundo: Feel free to file a bug with “ubuntu-bug xorg”; that'll attach everything we'd like, and I go through the nouveau bugs frequently.
[00:16] <BUGabundo> blob
[00:18] <BUGabundo> "Please wait while bug data is processed. This page will refresh every 10 seconds until processing is complete." ??
[00:18] <rye[fixing-x]> Sarvatt, should I as bug £534469 about separate /usr or you will do that?
[00:18] <rye[fixing-x]> awesome, GBr layout makes me mad
[00:19] <rye[fixing-x]> Sarvatt, bug #534469
[00:19] <ubottu> Launchpad bug 534469 in nvidia-graphics-drivers "Failed to load NVIDIA 195.36.08 kernel modules because nouveau is loading." [Undecided,New] https://launchpad.net/bugs/534469
[00:20] <BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/534755
[00:20] <ubottu> Launchpad bug 534755 in xorg "gdm/session killed when jumping to TTY" [Undecided,New]
[00:21] <BUGabundo> RAOF: ^^^
=== rye[fixing-x] is now known as rye
[00:26] <rye> ok, it is now 2:26 AM here, so I go offline. Will ask OP about separate /usr in case nobody else does in the morning
[00:27] <rye> good luck and thanks for the help with troubleshooting
[00:35] <Sarvatt> sorry, in the middle of a bunch of other troubleshooting at the moment, will take a look at it in a bit
[00:36] <Sarvatt> got an interesting crash resuming with the blob - http://pastebin.com/Ptqia4fi
[00:49] <Sarvatt> no problem with the blob after 6 boots here, glad its not as bad as it could have been :)
[00:51] <RAOF> Sarvatt: Yeah.
[00:51] <RAOF> I didn't particularly want to do any nvidia firefighting today :)
[00:53] <Sarvatt> maybe we need our systems to boot in 15 seconds like the bug reporter to reproduce :)
[01:21] <Sarvatt> hmm looks like BUGabundo got the same X segfault resuming with the blob as I did in one of his old logs - http://launchpadlibrarian.net/40541663/GdmLog2.txt
[02:58] <bjsnider> nvidia released an update to the nv driver
[02:59] <bjsnider> they added gem, gallium, dri2, vdpau, and full support for all hardware reaching back over 10 years
[03:00] <superm1> haha
[03:01] <bjsnider> ok, maybe not
[03:01] <bjsnider> they added ion support after their usual 5 minutes of work
[03:08] <bryceh> tjaalton, btw notice some pending stuff for xorg in git; is there a reason this isn't uploaded yet?
[03:09] <bryceh> tjaalton, and if not, shall I upload it? (I've a fix for apport I'd like to roll out)
[03:16] <Sarvatt> apw: unfortunately the i915 powersave=0 module option is still needed on my netbook so dont be surprised if you hang after resume with -16
[03:16] <Sarvatt> the plus side is it no longer flickers constantly with powersave=1 after resume, but it still eventually hangs to a solid color until I suspend/resume again
[03:19] <Sarvatt> i'm not sure what's up with xorg, tjaalton was pinging you a few days ago saying you needed to import an older release before uploading it I think?
[03:24] <Sarvatt> [14:40] <tjaalton> bryceh: expect a yet-another merge clash with xorg, since you didn't push the changes :)
[03:24] <Sarvatt> [14:41] <tjaalton> just the changelog though, as usual
[03:24] <Sarvatt> [15:46] <tjaalton> hm, need to merge xorg since xorg-dev is uninstallable
[03:24] <bryceh> yeah pretty sure I fixed that
[03:28] <bryceh> Sarvatt, still unclear why the git tree isn't pushed... was there an issue with it?
[03:28] <bryceh> s/pushed/uploaded/
[03:42] <Sarvatt> checking it out now, had a few problems
[03:59] <Sarvatt> hmm
[03:59] <Sarvatt> looks like your failsafe translation stuff got zapped
[04:00] <Sarvatt> think thats what tjaalton was talking about
[04:01] <Sarvatt> xgettext -f debian/po-failsafe/POTFILES.in -d failsafexinit -o debian/po-failsafe/failsafexinit.pot -L Shell
[04:01] <Sarvatt> xgettext: error while opening "debian/po-failsafe/POTFILES.in" for reading: No such file or directory
[04:05] <Sarvatt> bryceh: xorg git should be all fixed up now
[04:07] <Sarvatt> forgot to git add the internationalization file before commiting
[04:08] <Sarvatt> oops, would help if i remembered to enter my pass to push that last one :) now its fixed
[05:09] <tjaalton> Sarvatt: the Vcs* tags were removed from debian
[05:10] <tjaalton> and Standards-Version is in the wrong place :)
[05:11] <tjaalton> bryceh: other than that it's good to go, I was just waiting for other potential fixes
[05:18] <tjaalton> hmm, it never had any Vcs tags in debian
[05:18] <tjaalton> so if they were added by us, then ok
[05:20] <tjaalton> oh yeah, 2009-11-05 Bryce Harrington Add Vcs tags
[05:41] <Sarvatt> ahh sorry, thanks for fixing it
[05:42] <Sarvatt> 4 hour queue for the fixed up linux-backports-modules in edgers :(
[05:53] <RAOF> :(  There goes my quick PPA build of f-spot.
[05:55] <Sarvatt> anyone else's trackpads get laggy today?
[05:56] <RAOF> Not mine.
[05:56] <Sarvatt> ugh, maybe it was the -intel update
[05:57] <RAOF> Let me flick the stupid switch on my nvidia/intel netbook and check :)
[06:03] <RAOF> My (now intel) netbook doesn't know anything about laggy trackpads.
[06:08] <RAOF> Bah!  Stupid IA32-only atom processors.  Who produces a chip that only supports such a register starved, ancient ISA anyway!
[08:28] <tjaalton> superm1: before I file a bug, do you know why dkms fails to build nvidia when invoked via dpkg-reconfigure, but succeeds when I put the make command in a script?
[08:28] <superm1> tjaalton, did it fail on first install too?
[08:28] <tjaalton> the error is "make[1]: Makefile: No such file or directory"
[08:28] <superm1> and are you seeing this on lucid or karmic?
[08:29] <tjaalton> both actually, but now using only lucid
[08:29] <superm1> on karmic i'd expect it was caused by a permissions problem
[08:29] <superm1> but on lucid everything should be owned by root:root
[08:29] <tjaalton> it succeeds when the package is installed via preseeding pkgsel/include
[08:30] <tjaalton> or at least I think it does
[08:30] <superm1> well that sounds a bit bizarre then
[08:30] <tjaalton> hum no, it wasn't installed like that
[08:31] <tjaalton> "make module" does create the Makefile when run by hand or via the script
[08:31] <tjaalton> but not the dkms way
[08:31] <superm1> so it sounds like something is wrong in the dkms.conf then for this nvidia driver
[08:32] <superm1> although i would expect to be hearing a lot more about this then
[08:33] <superm1> you don't already have a Makefile in /usr/src/nvidia-current-195.36.08$  ?
[08:33] <tjaalton> yes, but it's cleaned away
[08:33] <tjaalton> when the dir is copied to /var
[08:34] <tjaalton> running make creates a symlink to Makefile.kbuild
[08:35] <tjaalton> make clean removes the file/symlink
[08:35] <superm1> why would Makefile be cleaned when the dir is copied over though?
[08:36] <tjaalton> I'll pastebin the shell debug output
[08:36] <tjaalton> added 'set -x' to dkms
[08:36] <tjaalton> it does run make clean there
[08:37] <superm1> but i dont see anything in the clean rule for the Makefile that deletes itself
[08:39] <tjaalton> but it's in makefile
[08:39] <superm1> oh i see
[08:39] <tjaalton> http://pastebin.ubuntu.com/391587/
[08:40] <tjaalton> so it copies the source and then cleans it :)
[08:41] <tjaalton> lines 994-1012
[08:41] <superm1> still sounds to me like a bug in the way the nvidia source is doing it
[08:41] <superm1> running clean should be safe
[08:42] <superm1> but i'm baffled still why this would work during the first install then
[08:42] <tjaalton> yep
[08:42] <tjaalton> well it didn't, was wrong about that
[08:42] <superm1> i've got installs here that it has worked on first install and on upgrades though
[08:44] <superm1> speaking of which, i just did an install of the -16 kernel on a system with nvidia right now, and it DTRT
[08:45] <superm1> let apport file the bug for you on the failure and attach that set -x run to dkms to the bug too
[08:49] <tjaalton> this is a slightly modified environment, apport isn't useful there.
[08:51] <superm1> well then attach everything it would have attached
[08:54] <tjaalton> ok I will
[08:57] <superm1> http://paste.ubuntu.com/391604/ yeah, it def still WFM
[09:03] <tjaalton> superm1: could you get the same output of it (set -x), so I could compare them?
[09:04] <superm1> tjaalton, in /usr/sbin/dkms?
[09:04] <tjaalton> superm1: yep
[09:06] <superm1> http://pastebin.com/Mf6AC8iY tjaalton 
[09:07] <tjaalton> hrm, I did a rollback of all the custom settings and reinstalled the package, and it built fine
[09:07] <superm1> oh dang, that didnt capture it
[09:07] <tjaalton> I can't think of anything that would conflict with this though
[09:07] <tjaalton> there's only one make etc
[09:07] <superm1> what were you customizing?
[09:08] <tjaalton> well some shell settings might have something to do with it
[09:08] <tjaalton> there are lots of changed configs etc, for the uni environment
[09:08] <tjaalton> or perhaps just that I logged in from the console, and not via sudo
[09:09] <superm1> its quite possible that some variables need to be unset for DKMS that aren't being unset then
[09:09] <tjaalton> hmm I can get the output here
[09:09] <superm1> it wouldnt be the first bug that came up from an unsanitary environment at least
[09:11] <tjaalton> ok, I'll dig something out of this :)
[09:11] <tjaalton> noticed that there are a bunch of variables being unset in dkms
[09:12] <superm1> yeah, quite possible there needs to be more unset
[09:12] <tjaalton> though why does it succeed when run by hand, hmm..
[09:12] <tjaalton> anyway, thanks so far
[10:58] <tjaalton> superm1: found it, unsetting ARCH made it work
[10:59] <tjaalton> don't know why we set that
[11:07] <bdrung> has someone time to sponsor bug #534026?
[11:07] <ubottu> Launchpad bug 534026 in xserver-xorg-video-ati "Please merge xserver-xorg-video-ati 1:6.12.191-1 (main) from Debian experimental (main)." [Undecided,Confirmed] https://launchpad.net/bugs/534026
[11:07] <tjaalton> we are past FF, so it probably needs an exception
[11:08] <tjaalton> oh it's approved already
[11:08] <tjaalton> he
[11:08] <tjaalton> *eh
[11:08] <tjaalton> don't change the packaging
[11:10] <tjaalton> check how other packages enable the patchsystem
[11:10] <tjaalton> synaptics for instance, they all are basically the same
[11:11] <jcristau> debian/README.source should have explanations how to enable the patch system
[11:12] <tjaalton> right
[11:19] <bdrung> debian/README.source is not very helpful. the debian maintainers remove all quilt invocation from their rule file.
[11:21] <bdrung> i know, that we shouldn't change the packaging, but in my opinion using 3.0 (quilt) is better than hacking debian/rules. the debian maintainers prefer quilt. So this is not the issue.
[11:21] <bdrung> tjaalton: ^
[11:24] <tjaalton> bdrung: I don't understand... debian/rules already had everything set up for patching
[11:25] <tjaalton> changing the source package format is way bigger than keeping the rules diff
[11:25] <bdrung> tjaalton: http://launchpadlibrarian.net/40489726/xserver-xorg-video-ati_6.12.191-1ubuntu1-v2.patch
[11:26] <tjaalton> well, philosophically anyway :)
[11:28] <bdrung> yes
[11:28] <bdrung> tjaalton: i can convert the debdiff if you insist on not using 3.0 (quilt)
[11:34] <jcristau> 3.0 (quilt) is unusable
[11:34] <tjaalton> bdrung: perhaps wait until bryceh chimes in
[11:35] <jcristau> bdrung: enabling the patch system is not "hacking debian/rules", and it's 2 lines in the debdiff instead of a complete revamp of the package
[13:41] <bdrung_> tjaalton, jcristau: i updated the patch for bug #534026 to make you happy. ;)
[13:41] <ubottu> Launchpad bug 534026 in xserver-xorg-video-ati "Please merge xserver-xorg-video-ati 1:6.12.191-1 (main) from Debian experimental (main)." [Undecided,Confirmed] https://launchpad.net/bugs/534026
[13:51] <jcristau> bdrung_: ta
[13:52] <bdrung_> jcristau: ta?
[13:52] <jcristau> thank you
[13:55] <bdrung_> jcristau: for what does the a stand in ta?
[13:56] <jcristau> http://www.urbandictionary.com/define.php?term=TA :)
[13:59] <bdrung_> interesting
[14:04] <tjaalton> bdrung_: thanks, replied
[14:07] <bdrung_> tjaalton: thanks. what does the ACK mean? wouldn't uploading it instead of acknowledging it the right thing to do?
[14:09] <tjaalton> bdrung_: I'd like to hear what bryceh thinks
[15:04] <superm1> tjaalton, okay file a DKMS bug to add it to the unset list too then
[15:07] <tjaalton> superm1: done, bug 534986
[15:07] <ubottu> Launchpad bug 534986 in dkms "please unset ARCH in /usr/sbin/dkms" [Undecided,New] https://launchpad.net/bugs/534986
=== seb128_ is now known as seb128
[17:58] <apw> bryceh, does switching away from and back to VT-7 work for you with an updated system?
[17:59] <apw> actually scratch that, bryceh does your X end up on VT-8 now?
[17:59]  * apw has a drm:drm_mode_getfb error on VT-7, and X is on 8 ... oddness
[18:01] <bryceh> apw, what's odd is I do have some systems on VT8, and others on VT7
[18:01] <bryceh> it's not consistent
[18:02] <apw> and now i have the feeling something odd happened during boot ... somethign i'd not twigged about
[18:02] <bryceh> also I do see a myriad number of issues related to vt switching
[18:02] <bryceh> probably all unrelated
[18:02] <apw> i got a modeset between plymouth and gdm which i shouldn't
[18:02] <apw> i suspect it started on 7 blew up, and restarted on 8
[18:02] <bryceh> I had a system where vt switching did not work at all, because plymouth was not installed; after installing it, it worked again
[18:03] <apw> wibble
[18:03] <bryceh> apw, there seem to be a set of pretty severe interactions between plymouth and X
[18:03] <bryceh> esp. related to vt switching - see the bugs filed in the plymouth bug tracker
[18:03] <apw> very strange, i presume keybuk is looking at plymouth at the mo
[18:04] <superm1> and i assume it's those same interactions to blame for why enter is killing X sometimes?
[18:04] <apw> superm1, i am starting to feel its when you don't have KMS you get that behaviour
[18:04] <apw> that always first return fecks you
[18:05] <apw> but i've not done any sort of repeated test to confirm
[18:05] <superm1> apw, i've had it happen with KMS working
[18:05] <superm1> well "working"
[18:05] <apw> its perfect, wonderful, you cannot see any issues
[18:05] <bryceh> superm1, that's right
[18:05] <superm1> i have problems where the second monitor doesn't work once X starts
[18:05] <bryceh> superm1, bug 532047
[18:05] <ubottu> Launchpad bug 532047 in plymouth "Plymouth text-mode splash causes X to crash on first run due to shared tty7" [High,In progress] https://launchpad.net/bugs/532047
[18:05] <apw> superm1, which version have you tested kernel wise
[18:06] <superm1> apw, -15 and the -16 that just hit the archive
[18:06] <superm1> i just updated hardy->lucid the other day
[18:06] <apw> so -16 is as bad, boo
[18:06] <bryceh> superm1, basically, while X is showing the login screen plymouth is displaying some confirmation dialog behind the scenes and waiting for user input.  If the user hits enter or '2', plymouth sends X a SIGQUIT
[18:07] <apw> bryceh, yay for plymouth
[18:07] <bryceh> yeah
[18:07] <superm1> I thought gdm requests plymouth to quit though?
[18:07] <jcristau> superm1: seems to be full of races..
[18:08] <bryceh> superm1, the bug had been believed fixed at one point but users are definitely still reproducing it on latest bits, so dunno
=== radoe_ is now known as radoe
[18:29] <Sarvatt> the problem is that plymouth is leaving the signal handler active on its console X is starting on and it just so happens that both the 2 or enter keycodes are quit key sequences, first time they are hit after it happens gdm restarts X on VT8 and its fine after that
[18:31] <Sarvatt> you should be able to add a stty -F /dev/tty7 -isig somewhere in the gdm startup scripts to work around it
[18:50] <apw> bryceh, do we yet have any known bad cards which need blacklisting.  i have preliminary blacklisting code which could do with a test
[18:50] <apw> (for kms)
[19:07] <bryceh> apw, yeah jdstrand would be a good test case
[19:08] <bryceh> he's quite motivated to seeing the issue he saw resolved and has been quite active at helping do testing for us
[19:08] <apw> bryceh, sounds good ... i hear he is doing some testing for manjo right now, once he has those results i'll ask him for his ids
[19:24] <Sarvatt> shoot, looks like a bunch of stuff I said got dropped
[19:24] <Sarvatt> <Sarvatt> bryceh, apw: any ideas on ways to add chipset detection logic to i915 to selectively set the default module options for certain cards? a way to set powersave=0 default for 945 and modeset=0 for 8xx would help a lot since 965+ doesn't need powersave=0 and such
[19:24] <Sarvatt> <Sarvatt> 8xx seems to be just as buggy with UMS as KMS from what I can see, just in different ways.. It's working with modeset=0 for a lot of people as a side effect of us explicitly disabling UMS support in intel so vesa is used
[19:24] <Sarvatt> <Sarvatt> and if we're sticking with --kms-only on 2.9.1 theres not much reason not to update to 2.10.x imo
[19:25] <Sarvatt> but sounds like you guys were already talking about it while i was disconnected :)
[19:26] <apw> Sarvatt, i have patches which currently would allow a change of options, they currently only change modeset
[19:27] <apw> it would be no real difficulty to go one step further
[19:27] <Sarvatt> changing powersave=0 just for 945 would be nice, the 965+ bugs with it seem to be fixed
[19:27] <jcristau> my 945gm seems happy enough with powersave now
[19:28] <apw> the change of powersave sounds like somethign which should just be turned off for those cards in the driver itself
[19:28] <Sarvatt> have you suspended and used the machine more than 30 minutes after resuming?
[19:28] <apw> rahter than overriding the module parameters
[19:28] <bryceh> Sarvatt, I'm going to drop the --kms-only bit
[19:28] <jcristau> Sarvatt: ah, no, i haven't used suspend
[19:28] <apw> yeah suspend is always a pig
[19:29] <Sarvatt> thats where the problem is, it hangs to a black screen with 100% gpu usage in framebuffer compression after resume and another suspend/resume cycle fixes it until it happens again
[19:29] <jcristau> ok
[19:29] <apw> yeah that one was a swine to find last time, is it back in the drm .33 backport they
[19:29] <jcristau> do you know the fdo bug number for that off-hand?
[19:29] <apw> then
[19:30] <Sarvatt> i've been just dealing with it and suspending/resuming again to fix it for the power savings though :D
[19:30] <apw> heh that was a world of pain
[19:31] <apw> so Sarvatt i think the powersave thing may need doing a more sane way
[19:31] <Sarvatt> jcristau: one sec, i'll dig some up but i'm in the middle of formatting a pixman patch to submit upstream for arm simd detection problems with our toolchain
[19:31] <jcristau> Sarvatt: yeah no hurry, thanks
[19:31] <apw> using the driver flags themselves so if you could email me with a list of the cards which are bust, i915 and !945+ or whatever it is and we'll see about fixing it properly
[19:32] <apw> Sarvatt, actually lets file a bug on it a nice clean generic bug on the kernel asking for it disabled for them, and assign it to me
[19:36] <Sarvatt> jcristau: https://bugs.freedesktop.org/show_bug.cgi?id=26594  (marked fixed but its only fixed by the reporter using powersave=0..) http://bugzilla.kernel.org/show_bug.cgi?id=14781 (lots of me-too's from 945 with the seperate issue from the original reporter..)
[19:36] <ubottu> Freedesktop bug 26594 in DRM/Intel "[945GM] Screen corruption and flickering" [Normal,New]
[19:37] <Sarvatt> seems like those are the only two i have bookmarked, i subscribed to other ones and they are somewhere in my mailbox so they will take some digging
[19:38] <jcristau> hrm not much activity on that fdo bug
[19:38] <Sarvatt> darnit, I need to get my butt in gear and put in a resume to you guys so I can have time to do all of this stuff instead of doing it while sitting in traffic all day between jobs :)
[19:40] <bryceh> heh
[19:48] <Sarvatt> ah hah
[19:48] <Sarvatt> jcristau: https://bugs.freedesktop.org/show_bug.cgi?id=26266
[19:48] <ubottu> Freedesktop bug 26266 in Driver/intel "Screen lockup some time after wakeup from standby (to ram)" [Critical,Assigned]
[19:50] <jcristau> Sarvatt: ah thanks, i'll ping this
[20:07] <bryceh> morning RAOF
[20:08] <RAOF> bryceh: Good morning.
[20:12] <RAOF> Why don't I ever run into these bugs first? :/
[20:13] <bryceh> RAOF, I know, I ask myself that a lot 
[20:13] <bryceh> insufficient time usually
[20:21] <Sarvatt> hmm, with these new launchpad dialogues do debdiff's count as patches?
[20:21] <Sarvatt> This file does not look like a patch.
[20:22] <Sarvatt> ah well I'll just say yes anyway :)
[20:26] <bryceh> debdiffs do count as patches
[20:26] <bryceh> really launchpad should distinguish between regular patches and debdiffs better, but it doesn't
[21:19] <bryceh> tjaalton, I've uploaded xorg with the fix for the intel apport script.  Geir will probably appreciate it
[21:22] <tjaalton> bryceh: ok good, don't forget to push :)
[21:22] <bryceh> oh yeah
[21:28] <tjaalton> bryceh: btw, did you see that bdrung merged -ati?
[21:28] <tjaalton> waiting for upload
[21:28] <bryceh> yeah working on it next in fact
[21:28] <tjaalton> ok
[21:28] <bryceh> it's fine by me, I've just been swamped with other stuff
[21:29] <bryceh> thanks for reviewing and mentoring ben
[21:30] <tjaalton> np
[21:44] <bryceh> -ati uploaded
[21:46] <RAOF> bryceh: I'm cleaning up nouveau DDX; I'll have a package in git soon for you to sponsor, if you could.
[21:46] <bryceh> RAOF, great, I'll be ready
[21:47] <bdrung> bryceh: debuild -S -sa
[21:47] <bryceh> dah
[21:50] <ibkanat> >	anyone have tips on getting a tablet to work with ubuntu 10.4? I followed https://help.ubuntu.com/community/AiptekTablet but didnt work
[21:52] <bdrung> bryceh: thanks for sponsoring
[21:53] <bryceh> bdrung, thanks for doing the merge!  It xx'd out two items from my todo list :-)
[21:53] <bdrung> :)
[21:54] <bryceh> (technically I think we needed a FFe for updating -ati, but since we're still pre-beta I think we can handwave through it and beg forgiveness if anyone complains)
[21:54] <bdrung> bryceh: we have a FFe for it
[21:55] <bryceh> bdrung, ah then excellent.  
[21:55] <bryceh> bdrung, will that cover to upgrade to 6.13 when its out?
[21:55] <bdrung> bryceh: bug #534026 comment 5
[21:55] <ubottu> Launchpad bug 534026 in xserver-xorg-video-ati "Please merge xserver-xorg-video-ati 1:6.12.191-1 (main) from Debian experimental (main)." [High,Fix released] https://launchpad.net/bugs/534026
[21:56] <bdrung> bryceh: probably not, but i assume that an upgrade request will be granted
[21:59] <bryceh> ok
[22:20] <Sarvatt> \o/ https://wiki.ubuntu.com/X/Tagging -- I didn't know that existed and was just about to ask if you had a list bryce :)
[22:26] <bryceh> Sarvatt, :-)
[22:26] <bryceh> Sarvatt, ah didn't know it wasn't common knowledge, yes it's quite good
[22:27] <bryceh> Sarvatt, also if you don't know about this report, you might like it as it goes along with that page nicely:  http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/symptoms_intel.html
[22:28] <bryceh> Sarvatt, that's a report showing the symptoms for bugs in a sortable column, limited to ones tagged 'lucid' (so you don't have to troll through ones against karmic that haven't been re-tested yet)
[22:28] <bryceh> Sarvatt, that report is a good way to spot dupes
[22:40] <Sarvatt> my bug work would be a *heck* of alot more productive if I could figure out how to mass search attached logs on bug reports. I usually spend most of my free time keeping up to date with mailing lists and git logs and every day I find myself trying to find errors strings that aren't in the bug reports so I have to resort to searching for symptoms and wasting time trying to see if its the one thats fixed
[22:41] <Sarvatt> almost wish you could get attachments sent in bug mails though i'd need 10 gmail accounts then :)
[22:44] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel?field.searchtext=GPU+lockup&orderby=-importance&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_pack
[22:44] <Sarvatt> age=
[22:44] <Sarvatt> 845 and 855 have major problems for sure
[22:45] <BUGabundo> Sarvatt: ahaha
[22:45] <Sarvatt> oops too long for one line
[22:46] <Sarvatt> thats like not even a week's worth of bugs and 845/855 is dominating it
[22:46] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel?field.searchtext=GPU+lockup
[22:46] <Sarvatt> there we go
[22:51] <bryceh> Sarvatt, arsenal has some stuff to help do searches on attachments
[22:51] <bryceh> Sarvatt, if you grab the arsenal code I can help show you how to craft tools to search log files
[22:51] <Sarvatt> most of the 8xx bugs seem to be page table error hangs
[22:52] <BUGabundo> for a moment I though you meant the english team that beat my FCPorto tonight 
[22:52] <Sarvatt> including the EIR: xxxxxxxxx line from i915_error_state in the bug description would be nice
[22:55] <bryceh> Sarvatt, I may be able to do that in the apport script
[22:56] <bryceh> I need to look into what Geir's been doing with the reports; I think there's fair room for more automation
[23:07] <Sarvatt> checking out arsenal now, proposed a merge with a change to the README to point at the new Template-Python svn address
[23:08] <bryceh> great
[23:09] <RAOF> bryceh: pkg-xorg git has xserver-xorg-video-nouveau update in it.
[23:09] <bryceh> RAOF, ok on it
[23:09] <Sarvatt> looks pretty straight forward
[23:15] <Sarvatt> yeah process-xorg-retargeting.py needs some fixing up for nvidia from what I see, it's retargetting nvidia-graphics-drivers bugs on lucid to nvidia-graphics-drivers-180
[23:15] <bryceh> RAOF, uploaded
[23:16] <RAOF> bryceh: Danke.
[23:17] <bryceh> Sarvatt, true
[23:17] <bryceh> Sarvatt, bzr pull and check again
[23:17] <Sarvatt> i'm going to need to set up a private launchpad instance to mess with these scripts I guess :)
[23:18] <Sarvatt> oh dang, I was behind a few days
[23:42] <bryceh> Sarvatt, nah, many of the scripts include a dry_run bool you can set so you can run them without causing changes
[23:43] <bryceh> those that don't have that probably should