[05:10]  * RAOF intrepidly wonders whether he can lock up his GM45 gpu as easily as his Q965
[05:14] <jk-> RAOF: I have a tool that might help
[05:14] <jk-> ls -l libflashplayer.so
[05:14] <jk-> -rw-r--r-- 1 root root 12127284 2011-04-18 09:46 libflashplayer.so -> /usr/lib/libfreezemyGPU.so
[05:16] <RAOF> jk-: I've got a better one - “while true ; do xset dpms force off ; sleep 5 ; xset dpms force on ; sleep 5 ; done”
[05:16] <jk-> oh awesome
[05:16] <RAOF> Of course, in order to get that to hang the GPU I need to get *compiz* to stop freezing first :)
[05:18] <RAOF> What?  And *now* I can crash the X server by playing with the screensaver?
[05:29] <RAOF> Oh, no.  That's because I got compiz to freeze.
[07:53] <fairuz> morning
[07:58]  * apw yawns
[07:59] <RAOF> apw: Are you aware that drm-intel-next has been failing to build for a while? (one of the staging drivers is breaking the build)
[07:59] <apw> RAOF, nope :)
[07:59] <RAOF> Consider it reported!
[08:00] <apw> la la la can't hear you
[08:00] <RAOF> I wanted to test an easily reproducible GPU hang against drm-intel-next before reporting upstream.
[08:00] <RAOF> I'm now a sad panda.
[08:01] <apw> did drm-intel-next-proposed build
[08:02] <RAOF> Do we even build that?
[08:02] <RAOF> http://kernel.ubuntu.com/~kernel-ppa/mainline/ doesn't think so.
[08:02] <apw> yeah we do, doesn't work either by the look of it, grrr
[08:05] <Sarvatt> RAOF: i386?
[08:05] <Sarvatt> i've got a drm-intel-next-proposed from 2 days ago built
[08:06] <RAOF> Yes, as it happens, i386
[08:07] <Sarvatt> http://kernel.ubuntu.com/~sarvatt/drm-intel-next-proposed/
[08:11] <Sarvatt> got the intel 2011Q1 release kernel too if you want to try that http://kernel.ubuntu.com/~sarvatt/2011Q1/
[08:13] <RAOF> drm-intel-next-proposed will do nicely.
[08:51] <apw> RAOF, ok i think i have the problem isolated, and possibly fixed ongoing, i'll let you know when zinc grinds out a build
[08:52] <RAOF> I've got sarvatt's drm-intel-next-proposed build that looks like it might not suffer from the same problem.
[08:52] <apw> nice
[08:53] <apw> RAOF, and manline v2.6.38-rc3 (ish) is affected?
[08:53] <RAOF> You mean 2.6.38.3ish?
[08:53] <apw> i meant 2.6.39-rc3 ish ...
[08:53] <RAOF> Ah.  I'll check that, too.
[08:53] <apw> as -proposed is presumably based on that
[08:54] <RAOF> At least, “while true ; xset dpms force off ; sleep 5 ; xset dpms force on ; sleep 5 ;done” hasn't caused the GPU to fly through the case yet.  And seems like it might also help with the missing vblank problems.
[08:57] <apw> RAOF, have you also tried drm-intel-backport ?
[08:58] <RAOF> No, I have not.
[08:59] <RAOF> I'll leave dpms cycling while I make dinner.  Once this has demonstrated it's really not going to blow up, I'll start going backwards.
[08:59] <apw> RAOF, sounds good, i am considering adding backports to the builds list
[12:07] <apw> ogasawara, on the config summary, how are you generating that, i have the scripts here that i used last year
[13:26]  * apw is dropping to shift locations (again), will be a couple of hours
[13:43] <tgardner> apw, have you upstreamed your frame buffer locking patch?
[13:43] <tgardner> apw, see on LKML: [2.6.39-rc2, framebuffer] use after free oops
[13:44] <smb> tgardner, note he is currently on the move
[13:44] <tgardner> smb, oh, I thought he was finally back home
[13:44] <ogra_> tgardner, wrt bug 766764, do we have all triggers and postinst scripts in the omap4 package ?
[13:44] <ubot2> Launchpad bug 766764 in linux-ti-omap4 "flash-kernel not run during kernel upgrade" [Undecided,New] https://launchpad.net/bugs/766764
[13:44] <smb> tgardner, He is, sort of
[13:45] <ogra_> (i havent confirmed the bug here yet, might be a red herring)
[13:45] <tgardner> ogra_, as far as I know it should be identical
[13:45] <ogra_> hmm
[13:45] <tgardner> wrt postinst, etc
[13:46] <tgardner> ogra_, it is, however, somewhat complex _and_ written in perl (not my best language)
[13:47] <ogra_> yeah, i just looked at it ... still rubbing my hurting eyes
[13:47] <ogra_> someone should reimplement that in shell some day
[13:58] <ogasawara> apw: I hacked together some scripts to generate it.  care to point me to your scripts?  I wouldn't mind running them to make sure we got the same output.
[14:03] <tgardner> JFo, what tag do you use for a bug that only applies to a specific release? verification-done or verification-done-maverick ?
[14:03] <JFo> I believe the latter
[14:04] <JFo> I haven't been using them, but I know the SRU team does
[14:04] <JFo> but for bugs that affect multiple releases the latter jogs a memory
[14:04] <tgardner> JFo, oh, well then I should be able to find it in a wiki. (famous last words)
[14:04] <JFo> heh
[14:04] <JFo> indeed :-/
[14:05] <JFo> I have a plan to update the /Tagging page once all of that is nailed down and reviewed
[14:05] <tgardner> not that it isn't there. I just won't be able to find it
[14:05] <JFo> same problem I always have
[14:05] <JFo> we need a google appliance
[14:05] <tgardner> bjf was talking about an external wiki site just for kernel info
[14:06] <JFo> that actually sounds like a great idea
[14:07] <JFo> tgardner, another bug with many duplicates: bug 766550
[14:07] <ubot2> Launchpad bug 766550 in linux "WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_fence.c:248 radeon_fence_wait+0x36f/0x3e0 [radeon]()" [Undecided,New] https://launchpad.net/bugs/766550
[14:07] <JFo> did we ever hear anything on the other?
[14:07] <tgardner> JFo, remember that LP bug bjf and I were complaining about yesterday? where you don't get bugmail even though you're on the right teams? turns out its a real regression.
[14:08] <JFo> wow
[14:08] <JFo> so they added something that broke that?
[14:08] <JFo> to LP I mean?
[14:08] <tgardner> yep
[14:09] <JFo> it was inevitable that you guys would notice given the sheer amount of bugmail we generate
[14:09] <tgardner> even though I don't read it all, I do kind of watch the flow.
[14:09] <JFo> yeah, it is a rather good health indicator
[14:12] <tgardner> JFo, hmm, I'm not seeing any fixes for bug #766550
[14:12] <ubot2> Launchpad bug 766550 in linux "WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_fence.c:248 radeon_fence_wait+0x36f/0x3e0 [radeon]()" [Undecided,New] https://launchpad.net/bugs/766550
[14:13] <JFo> not sure exactly when it popped up
[14:13] <JFo> looking now
[14:29] <JFo> me slaps LP search
[15:01] <JFo> bjf, did you replace markAsDuplicate with something else in the arsenal scripts? /me forgets
[15:02] <JFo> I'm trying to 'put new tires' on the suspend test finish script :-)
[15:02] <JFo> brb, some one is knocking on my door
[15:05] <bjf> JFo, nope
[15:06] <JFo> hmmm
[15:10]  * ogasawara back in 20
[16:02] <GrueMaster> ppisati: ping.  You around to discuss bug 588243?
[16:02] <ubot2> Launchpad bug 588243 in linux "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! " [High,Fix released] https://launchpad.net/bugs/588243
[16:21] <tgardner> sconklin, whats up with ara's email on the SRU list? are there other packages blocking its promotion?
[16:24] <sconklin> tgardner: it lacked the certification-done tag, but I don't think that's the hold up. I think that Pitti has just been waiting to be asked before publishing packages.
[16:24] <sconklin> tgardner: afaik there's no reason it shouldn't have been published. I just added the cert tag, but I don;t think that matters
[16:25] <tgardner> sconklin, that is something Brendan should have added? the cert done tag?
[16:27] <sconklin> tgardner: it's a little ambiguous. Pitti was adding them when he saw comments indicating completion. I would like for the teams completing the work to do it. But - as soon as we roll out the workflow manager scripts this will all be moot. And I'm hoping to test that during the next cycle.
[16:28] <tgardner> sconklin, ah. I thought the workflow stuff was already in place
[16:31] <eagles0513875> hey apw as this is a kernel specific issue im having how can one trace a kernel loop
[16:31] <apw> i presume you mean kernel oops
[16:31] <eagles0513875> ya 
[16:32] <apw> apport should report a bug with the relevant information
[16:32] <eagles0513875> i let it report it but it failed to report it cuz it said isnt a valid kernel package
[16:32] <eagles0513875> and i had to switch to gnome and gdm as i kde and kdm arent working for me
[16:33] <apw> eagles0513875, is that with my test package ?
[16:33] <eagles0513875> no with the 2.6.38-9 kernel in the ppa would you like me to try the test package
[16:34] <apw> ahh thats why then, its too new a package, not an official one
[16:34] <eagles0513875> well wifi is working fine on gnome
[16:34] <eagles0513875> with the kernel in the ppa
[16:34] <eagles0513875> :) 
[16:34] <eagles0513875> now to swear at kde and kdm
[16:34] <apw> you should have the error in your dmesg or /var/log/syslog
[16:34] <eagles0513875> ya ill take a look there trying to wrap my head around unity
[16:36] <eagles0513875> nothing odd in dmseg
[16:36] <eagles0513875> dmesg
[16:36] <ppisati> GrueMaster: yep
[16:37] <GrueMaster> ppisati: Did you see my email & ogra_'s reply?
[16:38] <eagles0513875> and nothing out of the ordinary in syslog either apw
[16:38] <ppisati> GrueMaster: just read it, fine
[16:38] <GrueMaster> ok.
[16:39] <ppisati> GrueMaster: then i'll write some stuff about kexec in the bug report but i'll leave it there
[16:39] <ppisati> GrueMaster: since lucid/ti-omap is dead
[16:39] <GrueMaster> Ok.
[16:40] <GrueMaster> Are you going to be helping with Oneiric armel kernel issues as they come up?  I hope so, as you have been doing a great job on backlog armel stuff.
[16:40] <ogra_> ppisati, dont get me wrong, its a nice to have but there are far more important things to manage atm and we dont have the resources for doing QA on unsupported releases
[16:41]  * ogra_ agrees with GrueMaster 
[16:41] <ppisati> GrueMaster: sure, point me to some stuff and i'll look at it
[16:42] <GrueMaster> Well, we aren't there yet.  :P  We do have some natty kernel bugs that will probably be SRU candidates at this point.
[16:43] <ppisati> i just thought we were still supporting lucid/ti-omap since it'll be alive till $somewheninthefuture
[16:44] <GrueMaster> Like I said, lucid omap was a tech-preview.  The image work wasn't started until after the Lucid platform sprint (actually iirc it was only 10 weeks of work).
[16:45] <GrueMaster> For Lucid Armel, we only support Dove & Babbage.
[16:45] <ppisati> fine
[16:45] <GrueMaster> Armel is kind of a tricky issue, as it is mainly contract generated.
[16:46] <GrueMaster> And we don't have LTS rules for armel.
[16:46] <GrueMaster> So 18 months is tops.
[16:46] <ppisati> ok, so, i'll pick some stuff from linux-ti-omap4 and see what i can do
[16:47] <GrueMaster> Cool.
[16:53] <JFo> <-lunch
[17:45] <bdmurray> bjf: I was looking at the apport-package hook for linux and report['Title'] = '[STAGING] ' + report.get('Title', '')
[17:46] <bjf> bdmurray, looking
[17:46] <bdmurray> bjf: bug titles with staging drivers end up always being [STAGING] as 'Title' doesn't exit
[17:46] <bdmurray> er exist
[17:47] <bdmurray> well or doesn't exist if people use 'ubuntu-bug linux'
[17:48] <bdmurray> https://bugs.edge.launchpad.net/ubuntu/+source/linux?field.searchtext=STAGING&orderby=-datecreated&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[17:49] <bjf> bdmurray, i was seeing some of those before making my change, though I will concede that I may have made it much worse
[17:50] <bdmurray> bjf: no I think that bit hasn't changed
[17:50] <bjf> bdmurray, so, you are pointing out a bug that existed prior to my latest hackage? 
[17:51] <bdmurray> bjf: yes, because I'm not certain what the kernel team wants to do here and you seem interested in the package hook
[17:52] <bdmurray> bjf: I'm guessing people figure [STAGING] is enough of a title and don't add anything else.
[17:52] <bdmurray> if [STAGING] wasn't there they'd have to enter something and staging might be best as a tag
[17:52] <bjf> bdmurray, good point
[18:01] <bdmurray> bjf: actually they are already tagged staging so I'd just remove the title bit
[18:01] <bjf> bdmurray, i'm thinking that as well
[18:02] <bdmurray> bjf: if it helps to have staging in the title you could have some bot preprend it then
[18:02] <bjf> true
[18:12] <bdmurray> bjf: I'm happy to do this is there someone I should check with though?
[18:15] <ogasawara> apw: you're away Fri ya?  If so, I'll handle the release meeting.
[18:15] <apw> ogasawara, oh yeah ... hrm
[18:16] <apw> thanks ;)
[18:16] <ogasawara> I suspect it'll just be a final bug scrub type of meeting
[18:16] <JFo> yeah, skaet said she was doing a final sanity check of the bugs :-)
[18:17] <JFo> speaking of which...
[18:17] <ogasawara> JFo: yet get all the bugs we went over updated?
[18:17]  * JFo goes off to check the cleanup bugs
[18:17] <JFo> most of them
[18:17] <JFo> only ones left are waiting for an answer from the OR
[18:17] <JFo> gonna look at them now
[18:18] <JFo> apw, any idea if a fix will be coming for bug 751689 before release?
[18:18] <ubot2> Launchpad bug 751689 in linux "Thinkpad x201* overheats due to slow fans when on 'auto'" [Critical,Confirmed] https://launchpad.net/bugs/751689
[18:18] <apw> we are not plannign on any updates before release
[18:18] <apw> everything on that one points to a bios bug, and anything we do would be a work around
[18:19] <JFo> thought as much, just wasn't sure if there was any patch needed
[18:19] <JFo> thanks :)
[18:19] <apw> its not a regression as maverick was also affected
[18:19] <JFo> ok
[18:20] <JFo> apw, were you ok with me closing as Won't Fix for natty but adding a comment saying that we are only closing this for Natty and we will re-evaluate for SRU if a fix comes through?
[18:20] <apw> i would have though just leaving it open and milestoneing for natty-later ?
[18:20] <JFo> can do that
[18:20]  * JFo adjusts
[18:22] <JFo> smb, you around?
[18:22] <JFo> was looking at bug 539467
[18:22] <ubot2> Launchpad bug 539467 in linux "SATA link power management causes disk errors and corruption" [Medium,Confirmed] https://launchpad.net/bugs/539467
[18:23] <JFo> guess not :-)
[18:27] <apw> JFo, that one is fixed in userspace, and i'd say mark it -updates too
[18:27] <JFo> ok, thank you sir :)
[18:29] <JFo> apw, have we still been seeing PowerPC build failures? bug 733805
[18:29] <ubot2> Launchpad bug 733805 in linux "[powerpc] ftbfs (ql4_nx.c:788:3: error: implicit declaration of function)" [Medium,New] https://launchpad.net/bugs/733805
[18:30] <apw> not recently
[18:30] <JFo> that is the last one I will pester you with :-)
[18:30] <JFo> ok
[18:44] <fred__> what is the most efficient process to request a bugfix to be backported from 2.6.39 to natty's kernel? 
[18:44] <ogasawara> fred__: open a bug since it'll need SRU, post a reference to the patch in the bug, let us know the bug #
[18:44] <fred__> k
[18:45] <ogasawara> fred__: do you know if the patch was CC'd to upstream stable?
[18:45] <ogasawara> fred__: if so, we'll get it automatically eventually
[18:46] <fred__> ogasawara, don't understand your question precisely. But the patch did not get into linux 2.6.38.x if that is your question
[18:46] <ogasawara> fred__: sorry, that's what I wanted to know
[18:51] <fred__> ogasawara, oh yes, it is now in 2.6.38.3: "Btrfs: Fix uninitialized root flags for subvolumes"
[18:51] <ogasawara> fred__: cool, 2.6.38.3 is already queued for the first kernel SRU
[18:52] <ogasawara> fred__: so you don't need to do anything :)
[18:52] <fred__> ogasawara, ah good news! do you know when it'll be released: as soon as possible, or after the natty's release only ?
[18:53] <ogasawara> fred__: it'll be after natty releases, as we'll currently frozen
[18:53] <ogasawara> fred__: but let me get you the details to run from our pre-proposed ppa which will have the fix
[18:53] <JFo> most of the regression-proposed for natty I am seeing are the sch_generic bug
[18:54] <ogasawara> fred__: https://launchpad.net/~kernel-ppa/+archive/pre-proposed
[18:54] <fred__> ogasawara, oh yes, I'll wait 12 hours to get these details!
[18:55] <ogasawara> fred__: install the linux-2.6.38-9.43~pre201104180902 kernel package from that ppa
[18:55] <fred__> ogasawara, is a -server kenel also included ?
[18:56] <ogasawara> fred__: yep
[18:56] <ogasawara> fred__: do you need i386 or amd64?
[18:57] <fred__> ogasawara, I guess I need that one for amd64, right ? linux-image-2.6.38-4-server_2.6.38-4.31~pre201102160903_amd64.deb 
[18:57] <ogasawara> fred__: yep that should be it
[18:57] <ogasawara> fred__: wait, that's not it
[18:58] <fred__> ogasawara, indeed, I need the -9 one..
[18:58] <ogasawara> fred__: https://launchpad.net/~kernel-ppa/+archive/pre-proposed/+files/linux-image-2.6.38-9-server_2.6.38-9.43~pre201104180902_amd64.deb
[18:58] <fred__> ogasawara, yep got it thanks
[18:58] <fred__> ogasawara, thanks a lot... 10 VMs will be able to restart tomorrow :)
[19:08]  * tgardner --> lunch
[19:29] <yhager> How can I upgrade my (maverick) kernel to latest? Are there binaries of latest kernels from kernel.org for ubuntu?\
[19:33] <jjohansen> yhager: you can either upgrade your whole OS to natty or you can choose to just upgrade your kernel.
[19:34] <yhager> jjohansen: I just want the kernel
[19:34] <jjohansen> you can download ubuntu kernels from packages.ubuntu.com (search for linux-image)
[19:34] <jjohansen> or mainline kernels from our ppa
[19:34] <jjohansen> http://kernel.ubuntu.com/~kernel-ppa/mainline/
[19:34] <jjohansen> yhager: install with dpkg -i
[19:35] <yhager> "mainline" means vanilla?
[19:35] <jjohansen> yhager: you may need to hold down the left shift key on boot to get to the grub menu to switch between kernels
[19:35] <jjohansen> yhager: yep, vanilla upstream
[19:36] <yhager> so I guess that apt-get update'
[19:36] <yhager> so I guess that 'apt-get update' takes the latest kernel for maverick, but if I want a later ubuntu kernel, I should remove 'maverick' from my search, right?
[19:38] <jjohansen> yhager: apt-get will use your sources from /etc/apt/sources.list
[19:38] <yhager> so what has better chances to work with maverick (no guarantee, I know) - mainline or natty?
[19:40] <jjohansen> yhager: they should both work, natty has the ubuntu extras like aufs enabled etc.
[19:40] <yhager> jjohansen: ok, I'll try. Thanks!
[19:40] <jjohansen> I would say go natty unless you really want to mess with mainline
[19:57]  * jjohansen -> lunch
[20:37] <njin>  hello guys, many times, expecially with overheating pc, I found this 'ACPI: BIOS _OSI(Linux) query ignored' , so i'm asking myself if it is not the case to have a tag for this particular branch of bioses?
[20:42] <mjg59> It's legitimate for a BIOS to ask that and it's legitimate for us to ignore it. It doesn't tell you anything about the machine.
[20:43] <cking> apart from it implements _OSI(Linux) :-)
[20:43] <mjg59> Well, the spec allows that
[20:43] <mjg59> So, ok, it doesn't tell you anything *useful* about the machine
[21:12] <pmcenery> Hi. Can this fix be included in Natty? https://bugzilla.kernel.org/show_bug.cgi?id=31232
[21:12] <ubot2> bugzilla.kernel.org bug 31232 in IPV6 "/proc/sys/net/ipv6 has two neigh folders" [Low,New]
[21:13] <pmcenery> Its apparently been merged v2.6.38-8876-g036a982
[21:13] <tgardner> pmcenery, it might be coming via stable already.
[21:14] <pmcenery> Is there a PPA that I can try? I've tried the 2.6.39-rc4 which is broken in some other way... get kernel panic
[21:15] <tgardner> pmcenery, hang on, still checking
[21:15] <pmcenery> tgardner: thanks. I'm running latest natty as of not so long ago... which has this kernel: linux-image-2.6.38-8-generic
[21:16] <pmcenery> not so long ago as in 30 minutes ago update...
[21:16] <tgardner> pmcenery, hmm, its not marked for stable. I'll see about getting it included.
[21:16] <pmcenery> This one may be marked as low, but it borks lxc in a big way
[21:17] <pmcenery> Bacially, any software in lxc doing sysctl check gets stuck in an infinite loop
[21:17] <tgardner> pmcenery, do you have a Launchpad bug yet, or just the bugzilla one ?
[21:17] <pmcenery> I've just found the kernel bugzilla one, not created a lp one yet?
[21:17] <sforshee> tgardner, looks like it's already in greg-kh's stable queue to me: https://lkml.org/lkml/2011/4/19/392
[21:17] <pmcenery> Should I create one?
[21:18] <tgardner> pmcenery, nope, looks like it won't be necessary. it'll show up in stable soon
[21:19] <tgardner> pmcenery, point your apt repo at https://launchpad.net/~kernel-ppa/+archive/pre-proposed and you'll get it as soon as we commit it.
[21:19] <pmcenery> tgardner: thanks.
[21:20] <pmcenery> tgardner: how soon after commit in stable does the PPA get updated?
[21:20] <tgardner> pmcenery, I generally get 'round to it within 24 hours.
[21:21] <tgardner> kind of depends on when he releases.
[21:23] <pmcenery> tgardner: thanks. I'll keep an eye on it. Thanks for the help
[21:40] <kees> ogasawara: random note for ubuntu-cve-tracker and upstream "released" versions: can you use "~" instead of "-" when specifying an rc release? i.e. 2.6.39~rc1 instead of 2.6.39-rc1
[21:40] <tgardner> kees, like we'll all remember that.
[21:41] <kees> tgardner: ah, sorry. she was last to touch it. it's just regular debian-style versioning, so 2.6.39-rc1 > 2.6.39 which isn't the intention.
[21:42] <tgardner> kees, but upstream kernel rc versioning _isn't_ debian compliant.
[21:42] <kees> tgardner: right, which is why I was asking, since u-c-t expects package versions.
[21:45] <ogasawara> kees: yep, smack me again if I forget in the future.
[21:46] <ogasawara> apw: ^^ just fyi since I saw you also making changes this morning
[21:53]  * tgardner is off to imbibe 2 or more mildly alcoholic beverages. cheers.
[21:56] <ogasawara> I've added a blurb to https://wiki.ubuntu.com/Kernel/Dev/FixingCVEs about the above, not that anyone cares.
[21:57] <bjf> "Thank you for your attention to detail"
[21:57] <ogasawara> heh
[22:09] <akgraner> Hi all you kernel teams folks - guess who is looking for a non-developer/non-technical session (you know for end users like me) on the Ubuntu Kernel...it's for open week...any takers...  I'll email the list as well, buth thought I would start here?
[22:10] <akgraner> s/teams/team even
[22:10] <akgraner> s/buth/but   jeez I suck at this typing thing today....
[22:12] <akgraner> man I'm hearing the faint sound of crickets...:-D  if you think of anything else you or anyone else would like to share with new users about 11.04 let me know  - thanks y'all
[22:14] <bjf> akgraner, no habla
[22:14] <ogasawara> bjf: don't make eye contact
[22:14] <akgraner> bjf, haha, no big kid table for you...
[22:15] <akgraner> ogasawara, why does everyone say that..;-)
[22:15] <ogasawara> heh
[22:15] <bjf> akgraner, i think manjo is interested
[22:16] <akgraner> bjf, something about a bus is coming to mind as I read that...
[22:17]  * sconklin whistles
[22:17] <akgraner> sconklin, ham radio with Ubuntu :-) yes!?
[22:18] <sconklin> akgraner: someday, after you show me how to capture screen video with audio commentary
[22:18] <lifeless> bjf: FYI the mail bugfix is deploying now
[22:18] <akgraner> sconklin, you got it at UDS will take less than 10 minutes...
[22:18] <bjf> akgraner, i think our mgr. told us not to talk to you, can't remember exactly why right now
[22:18] <bjf> lifeless, sweet!
[22:19] <akgraner> bjf, well there is that...o.O
[22:20] <sconklin> akgraner: and especially not to drink from any jars you offered. 
[22:20] <sconklin> or maybe that's my own memory
[22:20] <akgraner> that's your memory...
[22:22]  * akgraner goes away but if y'all think of some sessions that would rock to help end users become even better, more efficient users especially since we now have Unity...just let me know - I'll start hunting people down :-)
[22:23] <bjf> akgraner, users are not supposed to notice that a kernel even exists
[22:24] <akgraner> bjf, yeah but when they do they think is awesome they just aren't sure why...that's where you all come in..:-)
[22:42] <bjf> ogasawara, i was pushing lucid master-next possibly the same time you were, I didn't see your cve on it so i hope i didn't stomp on it
[22:43] <ogasawara> bjf: I don't think so, I'd only pushed the CVE's to branches in my personal repo
[22:44] <bjf> ogasawara, cool, i've just made it more difficult for you when you do go to push
[22:44] <ogasawara> heh
[22:51]  * ogasawara back on later