[00:06] <waltermundt> O
[00:06] <waltermundt> oops
[00:07] <waltermundt> I just upgraded my desktop computer from 10.04 to 12.04, and have started running into frequent but unpredictable "scheduling while atomic" kernel panics.
[00:07] <waltermundt> I found https://wiki.ubuntu.com/Kernel/DebuggingSchedulingWhileAtomic
[00:07] <waltermundt> and have just installed the linux-crashdump package and rebooted
[00:07] <waltermundt> can I afford to just turn all those tracing flags on and go about my day until the system crashes, or will that produce too much tracing data to sort through?
[00:08] <ohsix> what does sysctl kernel.tainted say
[00:08] <waltermundt> kernel.tainted = 4097
[00:08] <ohsix> ok, can you post the entire output of "dmesg" and lsmod to a pastebin
[00:09] <waltermundt> will do
[00:10] <waltermundt> ohsix: http://pastebin.com/XKMYa0HK
[00:12] <waltermundt> fwiw, jockey-gtk lists "Broadcom STA wireless driver" as being loaded, in case that's related.
[00:12] <ohsix> yea, it may be; does the device work without it?
[00:13] <waltermundt> I already switched from fglrx to the open radeon video driver in case that was inflicting flakiness, but all that bought me was the ability to see the kernel panic in a text console when it happens
[00:13] <waltermundt> I don't think so, but I can try; I can also arrange alternate connectivity even if disabling it breaks the wifi card and see if the crashes subside
[00:15] <ohsix> line 189 might be worth looking into, i haven't seen that before
[00:16] <waltermundt> Thanks, will search around.  So, here's the plan: I'll disable the proprietary driver, and stick to a wired network connection if necessary.
[00:18] <waltermundt> If the crashes stop, I may turn it back on and see if I can get a trace, if only to report to the mfgr.  If they continue, then at that point I should be on the stock Ubuntu kernel and will come back here to consult about next steps.
[00:22] <ohsix> ok, check out the iommu option in the bios too, theres' no reason it shouldn't be enabled afaik
[01:09] <malaverdiere> Hello. I am running the latest upstream kernel packaged by you guys :) I am getting this when I boot: May 13 13:12:24 redemption kernel: [    7.482877] sdhci-pci 0000:02:00.1: Invalid iomem size. You may experience problems. 
[01:09] <malaverdiere> Would that be related to some crashes I got randomly?
[01:20] <ohsix> it would be hard to say if it was related, but crashing is a problem, you could try blacklisting the module and see if the crashes stop
[01:20] <malaverdiere> I am not able to narrow down the source of the crash much
[01:21] <malaverdiere> it is a case of suspend-will-not-resume
[01:21] <malaverdiere> I was told to upgrade my kernel on launchpad, which I did, and it helped - but the telltale log message is goners
[01:21] <malaverdiere> :(
[01:22] <ohsix> ah, that's tough
[01:22] <malaverdiere> I know !!!
[01:23] <malaverdiere> All I can tell is that I had a non-crashy system on F16, and I now have a crashy system on Ubuntu 12.04 :( :( :(
[01:24] <malaverdiere> ohsix: which log files may have hints? I looked at syslog, kern.log and dmesg
[01:25] <malaverdiere> is there a way I can crank up logging orsomething?
[01:26]  * malaverdiere is not a kernel guy
[01:27] <ohsix> i had to setup netconsole to debug the last problem i had with suspend, you need ethernet and another computer for that
[01:27] <ohsix> what does sysctl kernel.tainted say?
[01:30] <malaverdiere> sysctl kernel.tainted 
[01:30] <malaverdiere> kernel.tainted = 1024
[01:31] <ohsix> post the output of dmesg to a pastebin
[01:31] <malaverdiere> http://paste.ubuntu.com/986445/
[01:32] <malaverdiere> I can tell you that the problem happened at 18:55 local time. That's when there is a gap in the log file
[01:33]  * malaverdiere is not sure how to correlate dmesg time stamps with wall clock time
[01:36]  * malaverdiere holds back a lot of cursing
[01:36] <malaverdiere> just had a system freeze
[01:36] <malaverdiere> in the middle of typing!!!
[01:37] <malaverdiere> ohsix: you've got fresh log files... ask anything you want :D
[01:39] <ohsix> malaverdiere: the only thing i see is that rc6 is enabled, you could try disabling it; and you'd probably want to ask #intel-gfx if it might be a problem, i don't remember which way it goes on snb
[01:40] <malaverdiere> I am not sure I am getting you. Are you suggesting I rever to RC5?
[01:40] <malaverdiere> s/rever/revert
[06:09] <ppisati> moin
[07:16]  * ppisati syncs th hdd laptop with my desktop, rsync FTW
[08:26]  * smb synced ... and tired
[08:31] <ppisati> smb: morgen Stefan! :)
[08:32] <smb> ppisati, Ciao Paolo :)
[10:30]  * ppisati -> goes out to get some food
[12:06] <dileks> hi
[12:06] <dileks> since which version of ubuntu 'umask 0022 ...' is required?
[12:07] <dileks> apw: overlayfs-v13 :-)
[12:08] <smb> dileks, umask required for what? and apw is only a bot for today. ;)
[12:09] <dileks> I need that when cloning a source-dir and doing make thingies
[12:10] <dileks> as an example: http://nopaste.snit.ch/140848
[12:13] <smb> Hm, umasking the group should only be required if you want to be able to change things later by another user with a different group...
[12:14] <smb> also umask takes only one argument...
[12:18] <smb> So "umask 0022" will cause all files created after this to be only writable by the user itself... That is actually more restrictive, but I cannot see what would make it requried
[12:19] <dileks> lemme look into the src-code
[12:22] <awilkins> Hello ; I have a kworker process periodically consuming high CPU which is causing annoying pauses, like keyboard lag and skips in music ; is there any way I can diagnose this a bit more thoroughly?
[12:23] <awilkins> It's fairly regular and periodic, every ~ ten seconds I have a burst of activity on the same kworker process, accompanied 
[12:24] <awilkins> by keyboard lag
[12:27] <smb> ... and he is gone...
[12:33] <awilkins> Ok, I still have a kworker process that's eating CPU every 10 seconds or so, but no more lags ; I'm presuming that before it had CPU affinity with the same process that runs the keyboard IO and other stuff but now it doesn't because I've rebooted
[12:34] <awilkins> Any way I can find out what a given kworker process is doing?
[12:35] <smb> awilkins, Not sure how successful that will be but maybe perf (from linux-tools) is can show what functions are called (and which cuase the biggest delays)
[12:37] <awilkins> Looks like something to do with the nvidia hardware
[12:37] <awilkins> calling nv50_i2c_getscl
[12:38] <awilkins> But most of the CPU is in ioread32
[12:39] <awilkins> I didn't even think I was using the nvidia hardware in this laptop, it's an Optimus
[12:39] <smb> Are you using nvidia or the nouveau driver
[12:39] <awilkins> nouvea
[12:40] <awilkins> The list of functions look like it's polling the hardware for information every 10s
[12:40] <smb> ok, so that sounds a bit like maybe nouveau is acessing the card a lot... hm
[12:40] <awilkins> i2c functions, `nouveau_bios_embedded_edid`
[12:40] <smb> yeah
[12:41] <smb> Hm, that would be monitor info
[12:41] <awilkins> Theory : the i2c bus is slow and it's spending a lot of CPU in the ioread32 function because it's waiting for data transfers to finish
[12:42] <smb> Would make sense. i2c is bit banging... just why it is done all the time
[12:43] <awilkins> The reason this causes keyboard lag etc when the process affinity is shared with the keyboard IO process is that these IO routines block (note, I am not a regular kernel hacker so that's a guess)
[12:43] <awilkins> I was under the impression I was using the Intel GPU anyway
[12:43] <awilkins> The "additional drivers" dialog does not offer me the nvidia driver if I open it
[12:44] <awilkins> I could add the nouvea module to my modules blacklist and reboot and see if things still work
[12:45] <smb> It could be those use the same worker or maybe similar locks. Hard to say without looking at code for a while. The additional drivers only offers the binary ones if supported.
[12:46] <smb> Can be that nouveau supports that model but not nvidia (I've seen this once for ati)
[12:46] <awilkins> smb, It's not lagging anymore so I'm guessing that the keyboard IO has been allocated to a different kworker this time around
[12:46] <awilkins> There seems to be 2 kworker processes for each CPU core 
[12:47] <awilkins> I suspect the keyboard IO was on the same core last time around
[12:48] <awilkins> This is a Quadro 3000M so it's not your normal GPU card
[12:49] <smb> iirc there are different general purpose default work queues. Cannot remember which there were though...
[12:49] <smb> awilkins, Just to be clear, the lag has gone without any reboot?
[12:49] <awilkins> No, had to reboot
[12:49] <awilkins> Still have the CPU consumption every 10s
[12:49] <ppisati> ok, this is about systemd but is still cool: desktop boot time in ~2s
[12:50] <ppisati> http://freedesktop.org/wiki/Software/systemd/Optimizations
[12:51] <smb> awilkins, Ah, ok. So maybe the keyboard processing is still on the same type of queue but handled by the other core/thread by luck
[12:51] <smb> so at least thy kb does not lag
[12:51] <awilkins> smb, That's my guess
[12:52] <awilkins> It's an 8 core machine so my odds should be good ...
[12:52]  * lag is starting to regret his choice of pseudonym
[12:53]  * smb waves to lag
[12:53] <smb> lag, there is also a good deal of samba discussions going on for me to notice... ;)
[12:54]  * lag waves back :)
[12:54] <lag> smb: Yes, I can imagine :)
[12:55] <awilkins> Recent nvidia drivers claim to support this card (Quadro 3000M), so I'm still guessing that the "Additional Drivers" thing is not offering them because I'm using the Intel
[12:55] <smb> awilkins, So still the question for you that remains is why the edid info is read all the time
[12:55] <smb> Well if nouveau functions are causing this you seem to be running the nvidia part.
[12:55] <apw> smb, its probabally scanning to see if the connector has anything in it, which it does not as its 'off'
[12:56] <apw> smb, can you remember the sysfs incantations to turn that other card off, it may help
[12:56] <awilkins> smb, I have both i915 and nouveau modules running
[12:56] <lag> smb: I'm thinking the_kernel_is_running_perfectly_take_the_rest_of_the_month_off_paid, would be a better choice
[12:56]  * smb ignores apw. he is off today
[12:56] <apw> smb, roaf may know ... and that is why i am telling you :)
[12:56] <lag> apw: Are you standing?
[12:56] <smb> apw, Yeah thanks. He may or may not be asleep now
[12:57] <apw> lag, lying fown
[12:57]  * awilkins does `sudo rmmod nouveau`
[12:57] <lag> apw: :D
[12:57] <awilkins> Ok, so i) my desktop is still here
[12:58] <smb> awilkins, But yes, RAOF may be the one we need to ask about the nouveau part
[12:58] <Daviey> i think there is lag behind in the brain department.. oh hai lag.
[12:58] <awilkins> ii) No more CPU peakings
[12:58] <awilkins> RAOF?
[12:58] <smb> awilkins, irc nick of the one "knowing" the gpu parts best
[12:58] <awilkins> Ah.
[12:59] <apw> i am pretty sure for optimus, there is a sysfs thing to physically power of the unused nvidia part, stopping these issues and saving power
[13:00] <apw> awilkins, though you should file a bug against the kernel for the kworker thing if its really slow when doing it
[13:00] <smb> awilkins, Though he normally is on Australian time zone (if you got back there by now)
[13:01] <smb> apw, I don't think the kernel can do much more when it is asked to read edid stuff
[13:01] <awilkins> It's noticeable enough to be *really* annoying
[13:01] <apw> smb, we shouldn't be causing lags in anything else when bit banging i2c really
[13:02] <tgardner> apw, unless the i2c serial I/O is really stupid
[13:02] <awilkins> And the CPU time it's eating will probably drain the battery somewhat as well
[13:02] <smb> apw, guess it would help if the driver did create its own queue then...
[13:02] <apw> tgardner, heh indeed and that in itself would be a bug :)
[13:02] <awilkins> The only other thing that had eaten as much time was my Eclipse instance
[13:02] <awilkins> Which tells you how obnoxious it is...
[13:03] <apw> smb, the last time we had this, there was a bug in the intel i915 port scanning too ... and that got resolved
[13:03] <lag> apw: You heard much from Daviey? I heard he was run over by a parked car.
[13:03] <awilkins> I wouldn't be surprised if the i2c IO was really dumb
[13:03] <awilkins> It's not like it's really critical performance stuff
[13:03] <smb> awilkins, Likely yes. Though two things, it seems stupid to do it that often and then it should be done independently to not cause the generic work queues to delay other things
[13:03] <apw> lag, ?
[13:04] <tgardner> lag, how about the guys that had a bird strike leaving SFO? they had to turn around and spend another night.
[13:04] <smb> Those where going the other way though... 
[13:04]  * awilkins does `modprobe nouveau`
[13:04] <apw> smb, i'd suspect its locking for the iobus rather than the workqueues myself, but hey, needs poking, and a bug
[13:05] <lag> tgardner: Wow! That's something to tell the kids
[13:05] <awilkins> And it goes back to hitting ioread32 a lot
[13:05] <apw> tgardner, bird-stike -- that must be exciting
[13:05] <lag> tgardner: Did it take out an engine?
[13:05] <tgardner> lag, Bryan and Eric were on the plane. both got diverted
[13:05] <smb> awilkins, Right, so yes, we should look at that via a bug report
[13:05] <awilkins> smb, Just getting back that perf table for it
[13:06] <apw> tgardner, lucking both we on it together
[13:06] <lag> tgardner: Interesting stuff - I wonder if the passengers heard the strike
[13:06] <smb> apw, -EDOESHARDLYPARSE
[13:06] <tgardner> lag, dunno. we'll have to the details from Bryan some time
[13:06] <apw> smb, in the i915 case it was something dumb like not clearing the por needs checking interrupts so we just did it over and over
[13:07] <apw> smb, and it only didn't kill us completely cause we were doing i2c in it so it was slow
[13:07] <smb> apw, The description here sounds really very like that
[13:07] <awilkins> smb, which package should I file the bug in?
[13:08] <smb> awilkins, start with linux, we can add other taks/packages later
[13:10] <smb> awilkins, oh and use "ubuntu-bug linux" if it is not too late alreadya
[13:10] <awilkins> ? https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
[13:10] <davmor2> guys I hit an interesting powersaving issue on precise trying to watch the UDS live video stream.  If I unplug the laptop with the offending wifi module in slows right down, plug it back into the mains and it was fine, I'm going to do some experiments to see that it is reproducible what is the useful info you would want for a good bug?
[13:11] <smb> awilkins, Running "ubuntu-bug linux" creates the bug and collects some log files
[13:11] <awilkins> Ah, ok then
[13:19] <ogasawara> tgardner: have you started the -rc7 rebase yet?  If not, I will.  I want to get it upload today.
[13:19] <tgardner> ogasawara, no, I was pondering sending out an email about conference attendance.
[13:21] <awilkins> I'm wondering if this might be contributing to the moments of crashiness I've had from my Intel GPU when doing fancy things in Compiz (usually linked to the workspace switcher)
[13:21] <awilkins> Because I hear that the Intel drivers are very stable
[13:23] <awilkins> Bug sent : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/999125
[13:23] <ubot2> Launchpad bug 999125 in linux "nouveau module constantly polls i2c, consumes CPU, on unused nvidia / Optimus" [Undecided,New]
[13:23] <tgardner> lag, are you attending linaro connect ?
[13:24] <lag> tgardner: I am, will you be there?
[13:24] <tgardner> lag, no, but bryan wants to attend. was just looking through the schedule
[13:25] <smb> awilkins, I would say stability varies especially with newer gpu hw being added. Not sure whether using them both at the same time is really supported right now (and if to which degree)
[13:25] <awilkins> smb, Oh, I have no expectation of both being used
[13:25] <lag> tgardner: Is he still doing lots of ARM stuff?
[13:25] <awilkins> smb, I just rmmod-ed the nouveau again
[13:25] <lag> tgardner: If so, there's no better conference on the planet 
[13:25] <awilkins> smb, I'll blacklist it, I don't need a graphics workstation, just a working-station
[13:26] <smb> awilkins, Right, seem an appropriate work-around for now
[13:26] <tgardner> lag, well, he's just started back on the distro team, but as you know ARM is definitely one of our focus items.
[13:26] <lag> tgardner: I certainly don't think it would be the worst use of him time
[13:27] <lag> tgardner: And it's right by him too
[13:27] <tgardner> lag, that makes it attractive for him I'm sure :)
[13:28] <lag> tgardner: Right :)
[13:49] <dileks> smb: I found this... <http://freetz.org/browser/trunk/Makefile#L110>
[13:53] <smb> dileks, So (for whatever reason) the makefile checks for it. I suspect Ubuntu rather uses 0002 because the default user is created with its own exclusive primary group. So files writeable by group are less open.
[13:53] <Daviey> smb: Hey, i thought linux-server was dropped in precise, is this correct?
[13:53] <smb> Daviey, as a linux flavour yes
[13:54] <Daviey> smb: good 'o.
[13:54] <Daviey> thanks
[13:55] <apw> dileks, -v13 nice
[13:57] <brendand> Daviey, smb - thanks
[13:57] <dileks> unfortunately, I was helping my parents as my father got his 3rd apoplectic stroke last week, so I ended in re-packing an up2date precise chroot. but could not test with including my own kernel.
[13:58] <tgardner> apw, rtg@gomeisa:~$ sudo hdparm --fibmap /boot/grub/grub.cfg
[13:58] <tgardner> /boot/grub/grub.cfg:
[13:58] <tgardner>  filesystem blocksize 4096, begins at LBA 4096; assuming 512 byte sectors.
[13:58] <tgardner>  byte_offset  begin_LBA    end_LBA    sectors
[13:58] <tgardner>            0  550336976  550336983          8
[13:58] <tgardner>         4096  553970912  553970919          8
[13:58] <tgardner> I think its time to rebuild gomeisa
[13:59] <apw> tgardner, or perhaps just go into my account a zap one of my build/* directories
[13:59] <apw> and then run it again
[13:59] <tgardner> apw, it needs to be a bit more deterministic, don't you think ?
[13:59] <apw> tgardner, where is our swap ?
[14:00] <apw> tgardner, any chance we could make a /boot with it; i guess its in just the wrong place
[14:01] <tgardner> apw, its got a GPT partition. so I'm thrashing around trying to rememebr how to figure it out.
[14:01] <tgardner> rtg@gomeisa:~$ sudo parted -l
[14:01] <tgardner> Model: Intel Logical Volume (scsi)
[14:01] <tgardner> Disk /dev/sda: 2392GB
[14:01] <tgardner> Sector size (logical/physical): 512B/512B
[14:01] <tgardner> Partition Table: gpt
[14:01] <tgardner> Number  Start   End     Size    File system     Name  Flags
[14:01] <tgardner>  1      1049kB  2097kB  1049kB                        bios_grub
[14:01] <tgardner>  2      2097kB  2318GB  2318GB  ext4                  boot
[14:01] <tgardner>  3      2318GB  2392GB  74.0GB  linux-swap(v1)
[14:01] <apw> damn
[14:03] <tgardner> apw, I'll see when next someone is in the DC and just have'em plug in a CD.
[14:11] <dileks> apw: http://paste.ubuntu.com/987187/
[14:21] <apw> tgardner, i thought you could connect a local CD to it via the kvm thingy
[14:21] <tgardner> apw, hmm. lemme explore that.
[14:21] <apw> tgardner, no idea how bad the performance would be of course
[14:22] <tgardner> apw, that would be too handy.
[14:23] <smb> at least my board would allow (once you get byond the find-the-right-java hurdle)
[14:24] <apw> smb, yeah ... and tgardner is closer to the thing than me
[14:28] <tgardner> apw, damn. gomeisa got moved and nobody updated the wiki
[14:30] <apw> tgardner, really ... try the IS one i asked them to make sure they were on there so IS could find them
[14:30] <apw> tgardner, so he may not have updated our one, but only theirs
[14:31] <tgardner> ah, found it
[14:33] <tgardner> apw, doesn't look like we have the right gizmos hooked to gomeisa in order to simulate a CDROM
[14:33] <apw> tgardner, when we did tyler, they did a netboot install for us and we configured it, is that an option here
[14:34] <tgardner> apw, likely not since there is no orchestra server that we can address from tangerine/gomeisa
[14:34] <tgardner> they are on their own vlan
[14:35] <apw> tgardner, not one of ours, but theirs.  indeed but they could remote flip it to another vlan, install it, and flip it back
[14:35] <tgardner> apw, ah, I see. perhaps. I'll chat up Sean when he's back in the office.
[14:37] <tgardner> apw, actually, I'll see if I can get larry to do it
[14:41] <Daviey> tgardner: does it currently have an OS?
[14:42] <tgardner> davyep
[14:42] <tgardner> Daviey, yep
[14:42] <tgardner> Daviey, the problem is that grub.cfg is allocated somewhere about the 32 bit LBA block limit on a 2.4 TB disk
[14:43] <Daviey> oh.. nice.
[14:44]  * ogasawara back in 20
[14:47] <apw> Daviey, we'd ideally want to shift the start of root up and shim in a /boot
[14:48] <apw> Daviey, actually this is something you might want to think about this cycle, that you default to /boot config when there is moer than 2T of /
[14:49] <tgardner> apw, isn't the issue a bit more generic then that? If the LBA value exceeds 32 bits, then it wraps. I don't hink it makes a difference how large the file system or partition is.
[14:50] <tgardner> seems like its a decision the installer needs to make.
[14:50] <apw> tgardner, right the issue is that either grub or the bios is doing the wrong thing in the long-lba calls, but the /boot configuration drop /boot below root i believe
[14:51] <tgardner> apw, right. you just gotta make sure /boot is in the first part of the disk
[15:07] <Daviey> that sounds horrid.
[15:20] <tgardner> apw, is this reasonable perl ?
[15:20] <tgardner> system ("grep -q pae /proc/cpuinfo");
[15:20] <tgardner> if ($?) {
[15:20] <tgardner>         print "This kernel does not support a non-PAE CPU.\n";
[15:20] <tgardner>         exit 1;
[15:20] <tgardner> }
[15:24] <tgardner> apw, I see your overlayfs patches got hoovered up by miklos
[15:25] <apw> tgardner, i think i'd want to search for ' pae ' or something to make sure we don't match the wrong thing
[15:25] <tgardner> apw, seems reasonable
[15:26] <apw> tgardner, otherwise it looks about right
[15:26] <apw> tgardner, overlayfs> yeah 2 weeks after i sent them, but _yay_ 
[15:26] <apw> tgardner, i hope we can get a better reln there now
[15:32] <Daviey> tgardner: is that perl, or wrapped shell? :)
[15:32] <tgardner> Daviey, its perl in the pre-inst for the kernel
[15:41] <ppisati> how do you push a pkg to a ppa without a .changes? e.g. the kernel build done in the canonical-kernel-team ppa don't have .changes (at least the arm one)
[15:46] <tgardner> ppisati, the .changes file only says _what_ to push, but it is not included in the upload.
[15:47] <ppisati> tgardner: so do i need a .changes or not? because otehrs ppa/pkgs have this file while kernel's ppa do not
[15:50] <tgardner> ppisati, when you create a source package, one of the files created is .changes. so, dput uses that to decide what files to upload, e.g., the .diff, the orig tarball, the .dsc , etc
[15:50] <tgardner> ppisati, but I guess that doesn't completely answer your question
[15:50] <ppisati> tgardner: ah, actually debuild created it but i didn't see it... nevermind
[15:51] <dileks> apw: http://anonscm.debian.org/gitweb/?p=d-i/base-installer.git;a=blob;f=kernel/i386.sh
[17:00] <tgardner> ogasawara, hows the Quantal rebase going ?
[17:01] <ogasawara> tgardner: it's done.  just finishing up powerpc test build and boot testing.  but I'll push it.
[17:01] <tgardner> ogasawara, cool, I've got a couple of patches to jam in
[17:02] <ogasawara> tgardner: ah, did you want them in the upload, or can the wait till the next?
[17:02] <tgardner> nah, they can wait
[17:02] <ogasawara> s/the/they/
[17:18] <pgraner> sconklin, ping
[17:19] <sconklin> pgraner: whassup?
[17:19] <pgraner> sconklin, whats the link to the OpenHW wiki?
[17:19] <pgraner> sconklin, me and google are not getting along today
[17:19] <sconklin> https://wiki.ubuntu.com/OHW
[17:19] <pgraner> sconklin, great so frickin' obvious
[17:19]  * pgraner kicks himself
[17:20] <sconklin> discoverability is not a strong point of our wiki
[17:20]  * tgardner considers an understatement
[17:20] <tgardner> that an*
[17:26]  * ppisati -> gym/workout
[18:36] <herton> manjo, any news on bug 980965?
[18:36] <ubot2> Launchpad bug 980965 in linux "[11.10/12.04] Broadcom [0489:e042]bluetooth does not work." [High,Fix committed] https://launchpad.net/bugs/980965
[18:36] <herton> it's simple and could be marked verified may be...
[18:37] <manjo> Applied to both bluetooth.git and bluetooth-next.git.
[18:38] <manjo> herton, what do you want me to do? change status to verified ? 
[18:38] <manjo> herton, or add a comment ? 
[18:38] <herton> manjo, I need a confirmation the -proposed kernel works for you
[18:38] <herton> the oneiric one in this case
[18:39] <manjo> herton, let me track down the system 
[19:18]  * herton -> errand, back in 1h and a half
[19:25] <tgardner> bjf, your 2012Calendar show UDS as Nov 8, but I think it starts Nov 5 (which is a Monday)
[19:27] <bjf> tgardner: all dates are thursdays
[19:27] <bjf> tgardner: i just stole the release calendar to use
[19:28] <tgardner> bjf, so, today is a thursday ?
[19:28] <bjf> tgardner: all dates on the calendar are thursdays
[19:29] <bjf> tgardner: may 3, 10, 17,24, 31 are all thursdays
[19:29] <tgardner> bjf, I think everyday should be Friday. It would be just like Groundhog Day. We'd never achieve the weekend.
[19:34]  * tgardner bails out for some errands
[21:24] <jjohansen> ogasawara: would you prefer the fixes for apparmor's net and mount patches be done as patch refreshes or just a patch on top of the existing patches
[22:18] <ogasawara> jjohansen: refreshes would be good
[22:18] <jjohansen> ogasawara: okay