[00:13] <Sarvatt> definitely something to ask in #ubuntu-kernel though, i'm not sure. looks like the only requirement to show it is CONFIG_LOCKDEP but we dont have that set and i dont see what selects it, doesn't seem to be CONFIG_LOCKDEP_SUPPORT though
[00:14] <Sarvatt> hmm FTRACE might disable it
[00:18] <Sarvatt> ilmari: are you having that problem still with xserver 2:1.7.6-2ubuntu7?
[00:19] <ilmari> yes
[00:31]  * ilmari builds a kernel with LOCKDEP, LOCK_STAT and PROVE_LOCKING enabled
[01:22] <ilmari> yeah, now sysrq-d works
[01:24] <ilmari> Sarvatt: thanks
[01:38] <bryceh> Sarvatt, http://www.happyassassin.net/2010/04/27/when-qa-works-x-org-and-memory-leaks-and-crashes-oh-my/
[01:41] <Sarvatt> ignoring the fact it's still broken in F-12/RHEL-6 where they originated from then I guess?
[01:41] <bryceh> hah
[01:42] <RAOF> And as far as I'm aware, the issues with compositing managers *still* haven't been resolved.
[01:42] <RAOF> Unless that changed since yesterday evening. 
[01:42] <Sarvatt> it's working fine here now, i added another patch to xorg-edgers a few days ago thats fixing it
[01:42] <bryceh> Sarvatt, you're messin' with his righteousness
[01:43] <RAOF> Sarvatt: Was that the incorrect-but-works-ok patch on xorg-devel?
[01:45] <Sarvatt> bryceh: not trying to sign up to that person's blog to say that, but it sounds like they don't consider it an issue because they don't ship clutter 1.2 with it so the only people reproducing the bug are people compiling things themselves. the crash bug is still there in the server though..
[01:45] <Sarvatt> RAOF: yeah
[01:45] <bryceh> I did find one interesting bit on that post... redhat uses something called 'bodhi' to help with their QA
[01:46] <bryceh> Sarvatt, you're probably right.  that's funny in a way
[01:46] <RAOF> That's their equivalent of *-proposed, IIUC, but it's got a dedicated UI, package karma, and such.
[01:46] <bryceh> bodhi - http://fedoraproject.org/wiki/Bodhi_Guide
[01:46] <bryceh> RAOF, interesting; is that turned on for the whole development process?
[01:47] <bryceh> or is that only used for testing post-release ala our SRU mechanism?
[01:48] <RAOF> bryceh: It's not clear to me.  I don't *think* rawhide goes through bodhi, so it'd be equivalent to our SRU mechanism.
[01:49] <bryceh> kind of reminds me of our http://qa.ubuntu.com/reports/xorg_prop_drivers/
[01:49] <bryceh> kind of a mashup of that and PQM
[01:49] <RAOF> Since when has *that* existed?
[01:50] <RAOF> That's the result of our call for dedicated restricted driver testing?
[01:50] <bryceh> yep
[01:50] <bryceh> sorry, assumed it was general knowledge.  alberto and I have been fielding questions from the testers all release
[01:51] <RAOF> Either there's an X development list I'm not subscribed to or you've been fielding questions in private :0
[01:51] <RAOF> Or maybe while I'm sleeping, I guess :)
[01:51] <bryceh> heh, yeah ara set up a separate mailing list for this
[01:52] <bryceh> which is just as well, a lot of the questions were really pedestrian
[01:52] <bryceh> xorg-prop-drivers-testers@lists.launchpad.net
[01:52] <bryceh> https://launchpad.net/~xorg-prop-drivers-testers
[01:53] <bryceh> RAOF, you might want to browse through the archives.  This turned out to be a pretty successful little effort
[01:53] <bryceh> I'd suggest repeating it for MM, and maybe even expand it to additional drivers if you'd like
[01:54] <Sarvatt> that fallback testing result list is as expected since the test case had no chance of working in the first place..
[01:54] <bryceh> yeah
[01:55] <bryceh> the test plan needs some tuning up
[01:55] <bryceh> I wrote it back before the alternatives system went in and some things I thought would work ended up not being implemented
[02:02] <RAOF> bryceh: Thanks for that pointer.
[02:06] <bryceh> heh, bug #568475
[02:06] <bryceh> he couldn't take a photo of the screen to show the corruption, so he *drew* it
[02:07] <bryceh> first time I've seen that :-)
[03:49] <rafiyr> bryceh: if you have a moment, take a look at https://launchpad.net/bugs/556761, the ntrig pen support needs a couple lines updated in 10-wacom.conf
[04:30] <Sarvatt> note to self: reboot and make sure you can mount the luks encrypted partition before you move things onto it in the future... :(
[04:44] <RAOF> I've not had *that* particular problem with luks :)
[05:02] <Sarvatt> only thing I can think of was I typoed the passphrase both times while creating it
[05:03] <RAOF> Oh, you can't open it *at all*?
[05:03] <Sarvatt> nope, tried every possible typo I can think of too
[05:04] <RAOF> :(
[05:51] <lapion> ilmari you there ?
[05:59] <lapion> my system can be running for days with tvtime activity the whole time, occasionally using firefox as well, but then if I want to use the update-manager the system crashes.(hangcheck-crash) while updating or getting package information.
[06:02] <lapion> of course I also get the crash on occasions when I am not using the update manager manually, I have never thought of checking if it started up autamatically
[17:55] <Sarvatt> looks like the --with-dri-searchpath change to accommodate gallium isn't ideal, aiglx must be hardcoded to load from /usr/lib/dri and doesn't honor that. for now i'm just keeping things that only have gallium drivers in libgl1-mesa-dri (/usr/lib/dri) as well
[18:19]  * bryceh waves
[18:19] <Sarvatt> morning bryceh 
[19:02] <bryceh> Sarvatt, heya I notice RAOF committed a 2:1.7.6-2ubuntu7.1 to git last Saturday with the glx patches and the updated upstream fix
[19:03] <bryceh> Sarvatt, however I don't see signs that a matching SRU was filed, or that it was uploaded to lucid-proposed yet
[19:04] <bryceh> Sarvatt, I'm going to prep an SRU xorg-server today so am wondering if I can just drop that 7.1 or if I'd be stepping on RAOF's toes impolitely if I did that
[19:05] <Sarvatt> i don't know what the deal is with that, fixing savage at the expense of breaking all swrast users again doesn't seem like a good idea to me though :)
[19:06] <bryceh> Sarvatt, how does savage come into this?
[19:07] <Sarvatt> savage had a regression with clutter apps not starting with 2ubuntu7
[19:07] <bryceh> ah
[19:08]  * bryceh boggles at people running clutter on savage
[19:09] <Sarvatt> but swrast is broken with clutter when the server has glx 1.3+ and I can't find anything but clutter people saying its mesa and mesa people saying its clutter's fault
[19:09] <bryceh> heh
[19:10] <bryceh> which means probably either one could be patched but neither wish to do it
[19:12] <Sarvatt> yup :) if it's only savage RAOF was doing it for I'd like to try to fix up savage instead of breaking swrast again which affects a huge amount more people comparatively
[19:13] <bryceh> no my guess is that this was a shot at fixing the memleak without sacrificing glx
[19:13] <bryceh> fortunately he did it on a branch (ubuntu-linux) so looks like I can just do my changes on the main ubuntu branch
[19:14] <Sarvatt> yeah need to ask RAOF what his thoughts are on it, savage is the only regression I have heard of so far
[19:15] <Sarvatt> and that's been broken in many ways with clutter since the beginning :)
[19:16] <bryceh> yeah and there's been a couple corruption bug reports I've seen which resolved when we moved to 1.2
[19:22] <Sarvatt> bryceh: IMO those other SRU's (exa one in there?) should go in first since they're important crash fixes and the glx one is more of a wishlist thing that will probably need more lengthy testing and hold it up
[19:24] <Sarvatt> the exa one is affecting everyone using radeon and the noscript extension that's really popular
[19:24]  * bryceh nods
[19:24] <bryceh> pitti also has one change I'll include
[19:25] <bryceh> Sarvatt, on another topic...  have you looked into packaging -intel 2.11?
[19:26] <Sarvatt> yeah I have been meaning to ask if you think it is something we should put in x-updates, but then I started questioning libdrm updates too and am unsure how much to put in that PPA :)
[19:26]  * bryceh nods
[19:27] <bryceh> do you know if anything besides libdrm needs updated?
[19:27] <bryceh> if it's just libdrm I'd be game to include that
[19:28] <bryceh> but if it starts needing mesa or other bits to be updated, maybe we should skip it and leave it to xorg-edgers
[19:28]  * bryceh breakfasts... bbiab
[19:30] <Sarvatt> nah, libdrm doesn't need to be updated for just intel 2.11
[19:36] <Sarvatt> i'll package it up and upload it to x-updates, mainly I was thinking a PPA that had just libdrm/ddx/mesa stable branch in it would be useful for bug reporters to test against to check for things that need backporting, xorg-edgers is a bit drastic of a change :)
[19:39] <Sarvatt> mesa stable seems safe to me, I mean look at the changes post 7.7.1 :) http://cgit.freedesktop.org/mesa/mesa/log/?h=mesa_7_7_branch
[19:50] <bryceh> yeah a lucid-oriented ppa wouldn't be a bad idea
[19:52] <bryceh> Sarvatt, ignoring the apple stuff, yeah looks like a few things maybe worth backports there
[19:52] <Sarvatt> 2.11 uploaded
[19:53] <bryceh> Sarvatt, key is to be able to tie those fixes to bug reports in LP, else justifying a SRU will be hard
[19:54] <Sarvatt> meego has a copy-fb patch that applies to 2.11 at least :P
[19:58] <Sarvatt> the blobs are pretty important to have in x-updates for sure since installing from the vendors websites doesn't work anymore, i put 195.35.24 in there the other day which is needed to support the whole new generation of cards that just came out
[19:58] <bryceh> I've spoken with nvidia about that, and sounds like they're open to helping us out there
[19:59] <bryceh> dunno about fglrx
[20:03] <bryceh> thanks for uploading 2.11
[20:03]  * bryceh crosses off the todo list
[20:06] <Sarvatt> what are the policies regarding nvidia blob updates in a stable release given that it is unrealistic to keep one version for 3 years with how they do things? makes me wish there was a restricted-updates :)
[20:06] <bjsnider> why couldn't there be a restricted-updates?
[20:11] <Sarvatt> hardy could update from nvidia.com or use envyng or whatever but i can see it being a problem in lucid since by the end of desktop support 6 new generations of cards wont be supported at all
[20:12] <bryceh> Sarvatt, so far the policy has been o/~ no, no no o/~
[20:13] <bryceh> good question though
[20:13] <bryceh> restricted-updates seems a sane idea as well
[20:16] <bjsnider> nvidia sometimes introduces regressions in the blob, like the current problem with hdmi audio, but generally updates are necessary to support new hardware. and that should override other considerations
[20:18] <Sarvatt> having it in the partner repo would be nice
[20:21] <bryceh> maybe the right way is to have each driver update in x-updates as they're available
[20:21] <Sarvatt> i *really* need to move ppa-purge over to python and look into integrating it with things so it purges ppa's on upgrade instead of just disabling them, this seems to be a really big problem with PPAs
[20:21] <bryceh> and if there is an update which is found to be all good, no regression, suggest it for restricted-updates (assuming one was made to exist)
[20:25] <Sarvatt> yeah I was just thinking it would be nice if there were "blessed" ppa's that could be enabled graphically with software sources to make that easier without requiring archive shuffling, but it seems like something that would be right for the partner repo since its proprietary and required with how they do updates. i'm not aware of all of the limitations on partner though
[20:25] <bryceh> me either
[20:25] <bryceh> well, in any case this is totally what I'd had in mind for x-updates
[20:32] <imbrandon> i think i'm bitten by the intel kms bug but i'm not really good at truble shooting X problems , anyone arround to bounce some ideas off from to see if i need to file a new bug or if its an existing one ( i'm fairly confident its the latter but not 100% )
[20:32] <Sarvatt> yeah for sure, same here, it's just the policies for what we put in x-updates that I am sketchy about. We should probably avoid libdrm if at all possible in there since it complicates things (new drivers will require the updated libdrm as well if built against it) but we're at the mercy of upstream there
[20:33] <Sarvatt> like the blob will require the updated libdrm too if its built against it even if it doesn't use it..
[20:33] <bryceh> Sarvatt, true
[20:34] <bryceh> Sarvatt, yeah my original thinking had been drivers-only
[20:34] <bryceh> although esp. with intel, it seems deps change a lot
[20:34] <imbrandon> basicly here is what happens ( lucid upto date laptop as of an hour ago , no special ppa or anything ) , normal boot i get a blank screen after plymouth but before X ( i see plymouth ) , but if i add i915.modeset=1 i can get into X and everything seems normal until i goto play video ( with any player ) X crashes 
[20:35] <imbrandon> sooo am i bit by the same bug, isnt there a ppa to fix it , i'm REALLY bad at X trubleshooting
[20:35] <bjsnider> Sarvatt, i don't think the blob is build against libdrm
[20:36] <Sarvatt> imbrandon: sounds like you have a 8xx generation intel? :)
[20:37] <imbrandon> Sarvatt: yes, 845 i think, i can look if it matters
[20:37] <imbrandon> 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
[20:37] <Sarvatt> theres no magical PPA that can fix 8xx at the moment unfortunately, it's horribly broken in general everywhere
[20:38] <imbrandon> Sarvatt: ahh ok, so no better work arround than the i915.modeset thing ? is there as bug i can subscribe to to watch ?
[20:38] <Sarvatt> yeah there are quite a few bugs, one sec I'll dig some up
[20:38] <imbrandon> anything i can do to help test ? being a ubuntu dev i'm pretty familiar with the process, just not X ;)
[20:39] <imbrandon> lol
[20:39] <Sarvatt> this will be a problem on any modern distro though, its not ubuntu specific
[20:39] <imbrandon> Sarvatt: yea i figured
[20:39] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/541511
[20:39] <imbrandon> seems like an intel driver thing, but i wasent 100% sure thus comming in here
[20:40] <imbrandon> fix released ?
[20:40] <imbrandon> ohh fixed in the release notes
[20:40] <imbrandon> :)
[20:41] <imbrandon> Sarvatt: great, gives me a place to start, thanks 
[20:43] <Sarvatt> imbrandon: the first thing I would try is i915.modeset=1 + manually changing the driver to fbdev in your xorg.conf. you won't have multiple monitors or acceleration but it should work at native resolution. if that has problems I would try without KMS (which is the default) and use the vesa driver
[20:44] <Sarvatt> both options are ugly but if you don't want to use an older release and cant upgrade the GPU there isn't much choice at the moment :(
[20:45] <imbrandon> right now just the modeset seems to be working with justa a few artafacts in X
[20:45] <imbrandon> i'm typing on this laptop ( screen + irrsi )  now so its not 100% lost
[20:46] <imbrandon> might try the fbdev driver, dont care about accel or multimonitors
[20:46] <imbrandon> Sarvatt: how can i turn KMS off though without recompiling the kern ?
[20:46] <jcristau> boot with i915.modeset=0
[20:47] <imbrandon> k
[20:47] <Sarvatt> kms is defaulted to off on 8xx in lucid, just dont add i915.modeset=1
[20:47] <imbrandon> ahh well without i915.modeset=1 i get a hard lock after plymouth
[20:48] <Sarvatt> have you tried disabling splash?
[20:48] <imbrandon> yes
[20:48] <Sarvatt> how about blacklisting vga16fb?
[20:48] <imbrandon> that i havent tried
[20:50] <Sarvatt> echo "blacklist vga16fb" | sudo tee /etc/modprobe.d/blacklist-framebuffer.conf && sudo update-initramfs -u and try booting without splash. worth a shot :)
[20:50] <imbrandon> ok so let me get this clear ( in my head ) what i should try ( gonna reboot in a sec to try it ) is blacklist that module, leave the modeset in the grub kernel line and switch to the fbdev driver ?
[20:50] <imbrandon> Sarvatt: kk i'll try that first
[20:51] <Sarvatt> in UMS there are a lot of options you can play with to see if you can get it usable, man intel in a terminal will list them, i'd start by disabling tiling 
[20:51] <imbrandon> ok i'm detaching screen, bbiab , thanks for the pointers guys
[20:52] <Sarvatt> dont use fbdev unless you're using KMS
[20:53] <imbrandon> got it
[20:53] <jcristau> kms+fbdev should work fine afaik
[20:55] <Sarvatt> yeah vga16fb is only used with plymouth without KMS so it sounded like he was going to use that on top of dropping i915.modeset=1 (which would make him use UMS) and fbdev wouldn't work
[20:55] <imbrandon> yea no i'm blacklisting it , leaving the modeset to 1
[20:55] <imbrandon> and switching to fbdev
[20:55] <imbrandon> first two done, making an xorg.conf now
[20:56] <Sarvatt> blacklisting wouldn't matter there, was suggesting that to try to get intel working with UMS since you said that wasn't working
[20:57] <Sarvatt> UMS+intel would be the ideal combination if you could get it working, the vesa or fbdev options are worst case scenarios
[20:58] <imbrandon> ahh ok
[20:58] <imbrandon> soo since i have it blacklisted i should "try" UMS and intel ?
[20:58] <Sarvatt> yeah
[20:58] <imbrandon> k lemme do that, its done now, brb
[21:02] <bryceh> imbrandon, your questions make me wonder a bit...  a number of people have come here with similar questions, and I imagine there are going to be more once the release is out
[21:02] <imbrandon> bryceh: probably :)
[21:02] <imbrandon> ok so i'm back
[21:02] <bryceh> I'd sort of like to figure out a way to address questions for folks higher up, prior to them coming here
[21:02] <bryceh> imbrandon, can I ask you a few questions in relation to this
[21:03] <imbrandon> ums+blacklist+intel dident work
[21:03] <bryceh> imbrandon, what places did you look for a solution before coming here?
[21:03] <imbrandon> so now i'm gonna try kms+fbdev
[21:03] <imbrandon> bryceh: LP, but the intel driver stuff is a maze
[21:03] <bryceh> imbrandon, how did you identify #ubuntu-x as a channel to ask on?  Did someone refer you, or a website, or just a guess?
[21:03] <imbrandon> bryceh: i'd be happy to help maintain a wiki since i have the hardware to test it too
[21:04] <bryceh> imbrandon, ok in LP what specifically were you looking for?  (The bug report is there, but evidently not in a form which you found easily digestible)
[21:04] <imbrandon> bryceh: i'm a ubutnu-core-dev i just "knew" lol , but i'm just not a good X person
[21:04] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel?field.searchtext=[i855] is a good list of similar bugs, the ones numbered 500000 and up are lucid ones mostly
[21:04] <bryceh> ok, so #ubuntu-x based on past experience
[21:04] <imbrandon> ( about the channel that is )
[21:04] <imbrandon> yea
[21:05] <bryceh> imbrandon, by chance did you look at the release notes or the Ubuntu-X wiki pages before coming here?
[21:05] <bryceh> if not, is that because you didn't know about them, or because you knew but didn't think they'd have the answers?
[21:05] <imbrandon> bryceh: yea, berifly, thats why i knew it was a wider problem that there might be a work arround for, just wasent clear on what the workarround was
[21:05] <imbrandon> release notes, not the wiki
[21:05] <Sarvatt> it helps a lot having someone willing to test things in real time not having access to the hardware myself :)
[21:06] <imbrandon> wiki pages for teams i rarely check as from experice ( maybe not in X's case ) havent had awnsers about bugs, only the team
[21:06] <bryceh> imbrandon, ok good to know - did you spot the wiki link from the entry about it in the release notes?
[21:06] <imbrandon> yea
[21:07] <imbrandon> Sarvatt: heheh yea , an i love this laptop, its my "main" dev machine, i hate to replace it ;)
[21:07] <Sarvatt> imbrandon: if you want to test UMS more later it might be worth trying the version of xserver-xorg-video-intel thats in this PPA -https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-retro
[21:07] <bryceh> Did you follow the link?  Why or why not?  If you followed it, did you find it useful or not?  (too technical? too general?)
[21:08] <imbrandon> Sarvatt: sure i'm down for testing whatever, i have a few working desktops and servers should i totaly fubar something 
[21:08] <imbrandon> ;)
[21:08] <imbrandon> bryceh: i followed it but it was too general it seemed so i quickly ( without a through look ) dismissed it
[21:08] <imbrandon> maybe wrongly but i did
[21:08] <imbrandon> ;)
[21:09] <bryceh> ok
[21:09] <Sarvatt> imbrandon: since you're on 855 there are some promising kernel changes that are much too invasive to backport right now that might fix things up too, i can dig you up a link and I think Geir has made kernel debs out of it
[21:09] <bryceh> I'll have to firm it up
[21:09] <imbrandon> Sarvatt: k
[21:09] <imbrandon> bryceh: k
[21:10] <imbrandon> bryceh: if there is anything else i can do wiki wise lemme know, i'm more than willing to help, just a bit behind the X curv, untill today its always "just worked" for me since warty on all my hardware ;)
[21:11] <Sarvatt> karmic worked?
[21:11] <imbrandon> well there was that one thing in early dapper but that bit everyone ;) shhhh
[21:11] <Sarvatt> using the kernel in karmic is an option :)
[21:11] <imbrandon> Sarvatt: yea, karmic worked like a charm on this laptop for months
[21:11] <imbrandon> Sarvatt: hum, never thought about that
[21:12] <bryceh> imbrandon, cool, yeah we could definitely use help improving the wiki pages at wiki.ubuntu.com/X, especially the Troubleshooting section
[21:12] <bryceh> imbrandon, a lot of what we need help with is just basic copyediting.  I tend to be overly verbose in my wordings so a second set of eyes to boil stuff down to simplify it would likely improve it
[21:12] <imbrandon> so just to be clear in my head here, is this a kernel problem or an intel/X problem or a mix
[21:12] <imbrandon> lol
[21:12] <bryceh> less is more, 'nat
[21:13] <imbrandon> bryceh: cool, i can do that
[21:13] <Sarvatt> mostly the kernel
[21:14] <imbrandon> ok so if i un-backlist that module ( just to be clean ) and install the latest karmic kernel ( via apt pinning ) i "should" be ok ?
[21:14] <imbrandon> and obviously boot form it via grub
[21:14] <Sarvatt> possibly :)
[21:15] <imbrandon> that is assuming karmic worked for me , that might be an option for the general public too since karmic will be supported kernel wise for a nother year, hum
[21:15] <imbrandon> apt pinning is a bit above most ppl but i bet it could be made easy via a wiki
[21:16] <Sarvatt> don't need to pin anything, just have to select it from the list in grub :)
[21:16] <imbrandon> Sarvatt: hum true, i forget kernel is one that can be installed side by side
[21:17] <imbrandon> ok let me try that next, if that dont work i'll go down the fbdev route
[21:23] <imbrandon> Sarvatt: how can i tell what -video driver i have loaded ?
[21:24] <Sarvatt> /var/log/Xorg.0.log should make it obvious
[21:25] <imbrandon> ok bbiab, gotta get the kids from school
[22:01] <bjsnider> Sarvatt, what's the deal with poulsbo on lucid?
[22:10] <bryceh> Sarvatt, while I finish up this xorg-server upload... any other changes you know of which we know we need?
[22:11] <bryceh> bjsnider, no deal at the moment
[22:11] <bryceh> bjsnider, use vesa, unless you feel like working on porting over the mandriva psb kernel patches
[22:12] <bjsnider> mandriva is using an old x server
[22:16] <bryceh> sorry I meant s/mandriva/meego/
[22:17] <imbrandon> back
[22:17] <imbrandon> well both the old kernel and kms+fbdev both are good worksarounds
[22:17] <imbrandon> bryceh Sarvatt ^^
[22:18] <imbrandon> bryceh: i'll touchup over the wiki some this evening after everyone is asleep in the house and I can concentrate a bit more
[22:20] <bryceh> imbrandon, great, thanks :-)
[22:53] <bryceh> gahh, writing up srus is so time consuming....
[23:17] <bryceh> Sarvatt, RAOF, xserver uploaded, sru's filed.  3 fixes included.
[23:17] <bryceh> and git pushed
[23:17] <BUGabundo> iihhhh
[23:17] <BUGabundo> I see we are going to have huge updates post release
[23:17]  * BUGabundo refreshs SRU page
[23:18] <bryceh> BUGabundo, are you complaining?
[23:18] <BUGabundo> I'm not
[23:18] <BUGabundo> I'm use to it
[23:19] <bryceh> yeah it's pretty standard operating procedure, esp. for an LTS
[23:19] <bryceh> if anything I think it's going to be light compared with hardy, at least for X stuff.  But we'll see.
[23:20] <BUGabundo> ehe
[23:20] <BUGabundo> well, the 6th ill upgrade to 10.10
[23:21] <bryceh> good man :-)
[23:22] <BUGabundo> some one must keep tabs on your guys works 
[23:59] <bryceh> imbrandon, Sarvatt, I've refactored https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes to hopefully be less generic