=== cooloney is now known as cooloney-afk
=== cooloney-afk is now known as cooloney
=== MTecknology is now known as MTeck-ricer
[07:45] <kraut> moin
=== hrw|gone is now known as hrw
[08:37]  * apw waves
[08:37] <apw> morning lag 
[08:37] <cking> morning
[08:38] <apw> hi cking 
[08:38] <ikepanhc> good morning
[08:38] <apw> evening ikepanhc 
[08:38] <ikepanhc> not evening yet - afternoon now
[08:38] <apw> ahh :)
[08:39] <ikepanhc> 15:38 here
[08:39] <apw> ahh early you slacker :)
[08:39] <lag> Morning apw ;)
[08:39] <ikepanhc> :P
[08:40] <psurbhi> good morning! o/
[08:41] <apw> psurbhi, hi-ya, you recovered from the ubu-plague ?
[08:41] <lag> Hey cking
[08:41] <ikepanhc> good morning surbhi
[08:41] <psurbhi> apw, not completely yet :( i have few tests lined up
[08:41] <psurbhi> but good enough to work :-) so not too bad!
[08:41] <ikepanhc> psurbhi: still sick?
[08:42] <apw> psurbhi, thats cirtainly a bad one ... glad to hear you are getting well(ish)
[08:42] <psurbhi> ikepanhc, a little.. but good during most of the day
[08:43]  * psurbhi notes the ubu-plague ;) thats not the virus for sure
[08:44]  * ikepanhc just confused about plugra and prague - thought why prague makes surbhi sick...
[08:44] <apw> ikepanhc, heh
[08:45] <ikepanhc> :P
[08:45] <psurbhi> :D
[09:00] <smb> morning .*
[09:00] <ikepanhc> good morning smb
[09:01]  * apw waves to smb
[09:01] <ikepanhc> smb: I am rebasing hardy netbook-lpia branch, will send email when done, could you review for me?
[09:01] <smb> ikepanhc, will do
[09:02] <lag> Morning smb
[09:02] <ikepanhc> smb: thanks
[09:07] <ogra> amitk, why does maverick still have the lucid omap binary ... and apw why does the meta package still point to it ?
[09:07] <apw> ogra, i would think the latter is triggering the former
[09:07]  * smb also relates good morning to ogra 
[09:08] <ogra> oh, and the package description of the new one is wrong, it talks about omap3 and 4, we will need two distinct binaries for that
[09:08] <ogra> moring too, everyone :)
[09:08] <apw> ogra, given we don't even have the omap4 ... indeed so
[09:08] <ogra> apw, and if we have it the current patchset needs its own binary 
[09:09] <ogra> (we'll need to have omap4 by A2)
[09:09] <apw> ogra, i've not seen any omap4 code proposed as yet
[09:09] <ogra> apw, well, cooloney will likely have to work on it (since 10.07 went happen)
[09:09] <cooloney> apw: i missed some context here. 
[09:10] <amitk> apw: any ETA for TI to give us a re-based patchset on top of maverick master?
[09:10] <cooloney> apw: yeah, i got a omap4 branch but it is for lucid not maverick
[09:10] <amitk> and good morning
[09:10] <cooloney> amitk: morning, man
[09:10] <apw> amitk, i've not been told any dates no
[09:10] <cooloney> i don't know either.
[09:10] <ogra> cooloney, so the good news for you is that a) i have a panda branch: http://gitorious.org/pandaboard/u-boot/commits/omap4_panda (should be only a few patches on top of the current omap4 kernel)
[09:10] <apw> cooloney, are you owning omap4 for maverick or is that meant to be mathieu/lag ?
[09:10] <ogra> cooloney, and b) we dont do 10.07 
[09:11] <smb> apw, \o Gm, when the others are done I have a question, too
[09:11] <cooloney> apw: i am going to do that. mathieu will own the omap thing in master branch. i think
[09:11] <apw> ok then ogra i refer you to the omap4 owner cooloney  :)
[09:12] <ogra> amitk, we were told they would rebase on to of our tree during this week, so i would expect something latests by beginning of next week
[09:12] <ogra> apw, ^^
[09:12] <apw> cooloney, seems we need something very very soon
[09:13] <apw> ogra, i think we need to get cooloney plugged into the information stream you have from ti
[09:13] <ogra> apw, the call is at an awkward time for him :(
[09:14] <apw> ogra, ok, but we need to make sure he gets the info either way, as you know things he needs to be on top of :)
[09:14] <cooloney> apw: yeah, normally i will email and irc contact with sebjan
[09:14] <ogra> apw, thats why i gave him the info right now :)
[09:14] <cooloney> apw: right, i need to sync up with ogra 
[09:15] <ogra> apw, the decision to drop 10.07 was made friday evening 
[09:15] <apw> ogra, sounds sane and will make smb happy
[09:15] <cooloney> ogra: what's kind of decision? hehe. i just arrived at hugh and haitao's hotel, and wifi from the lobby
[09:16] <cooloney> ogra: maybe i missed some info
[09:16] <smb> Everything which is a S.E.P. makes me happy
[09:16] <amitk> cooloney: NO LUCID OMAP4 KERNEL! :)
[09:16] <ogra> right
[09:16] <ogra> you can put your efforts into 10.10
[09:17]  * cooloney feels someone punch his head to the iron door
[09:17]  * smb immediately forgets about Lucid-ti-omap4
[09:18] <cooloney> amitk and ogra, really? skip 10.07 ti-omap4 kernel 
[09:18] <cooloney> and just 10.10 ti-omap4 kernel, right?
[09:18] <ogra> right
[09:18] <cooloney> and how about the time frame of this
[09:19] <ogra> asap, but the ball is at TI
[09:21] <apw> smb you are up
[09:23] <smb> apw, Just wanted to check with you on the state of the upstream patches for the sync-time problem. I believe we said we will try to take the set of three and put it into the next proposed. I am not sure I missed something but I saw no mail or git update
[09:23] <apw> smb, indeed somehow i didn't get to it
[09:24] <apw> smb, i can look at it now
[09:24] <smb> apw, Ok, awesome. Thanks
[10:50] <amitk> dmesg
[10:50] <amitk> erm, -EWRONGWINDOW
[10:59] <ikepanhc> eh, looks like ecryptfs with chroot environment is a bad idea, I can not bind /home to chroot's /home
[11:08] <anoteng> Hello, I'm git-bisecting a kernel, and all of a sudden the kernel image deb depends on linux-tools-kernelversion which of course does not exist. Is it safe to force the installation? What does the linux-tools packages do?
[11:08] <apw> ikepanhc, heh
=== amitk is now known as amitk-afk
[12:44] <smb> anoteng, Just supplies user-space half of some tools (perf afaik). For testing it should be safe to force
[12:48] <apw> anoteng, i think you were pretty unlucjy there, pretty sure that that dependancy was not there for very long at all
[12:49] <apw> anoteng, and yes you can ignore it and push the package harder
[12:49] <smb> apw, pushed Karmic fsl-imx51 rebased to my current master
[12:50] <apw> smb, ahh thanks ... am still building the comparisons ... as they broke the first time
[12:50] <smb> apw, Something on master broke or the merge of abstracted?
[12:51] <RAOF> Ok, so it seems that both 2.6.34-5 and 2.6.35-1 have a habit of panicking and then rebooting.  Is there a debug kernel I can install to make these events maximally useful?
[12:51] <apw> smb, the first breakage was because the existing packaging actually is broken and does not make the contents of the docs package ... which does not work, a minor source tweak to the kernel itself sorts that out
[12:52] <apw> smb, the second is because the new packaging produces the debug packages with the correct new names, which i'd not allowed for
[12:52] <smb> Ah ok... Not nice but ok...
[12:52] <smb> Hm... haven't I changed that already?...
[12:52] <apw> smb, i am assuming we are happy to have the debug images have the new name ?
[12:53] <Sarvatt> 2.6.35-1 is nasty, my netbook no longer goes into C3 on it and idles around 2x higher power usage :D
[12:54] <smb> apw, Yeah sure. Ah, ok I only fixed the packaging to be using the contents of CurrentlyBuilding, not the naming
[12:54] <apw> smb, ahh ok makes sense
[12:54] <smb> Sarvatt, I think I saw a patch for that today
[12:54] <Sarvatt> yea it was on master just before rc2 released luckily
[12:54] <apw> Sarvatt, does not supprise me at _all_, noone should run an -rc1 kernel they are crack smoking messes
[12:55] <apw> i am sure we'll be uploading -rc2 asap
[12:55] <smb> apw, If noone would run -rc1, who would find the bugs. ;-P
[12:55] <apw> s/noone/noone sane/  perhaps :)
[12:55] <smb> heh
[12:57] <Sarvatt> finding bugs gives me an excuse to learn more about what's broken, i don't mind :)
[12:57] <apw> Sarvatt, yeah if i had more time i'd be like that too
[13:01] <RAOF> So, is there a kernel debug package?  And if so, where is it? :)
[13:04] <apw> RAOF, there is a a package with more symbols, nothing with more debugging code in it
[13:06] <RAOF> The former was what I was expecting.  What's the package called?  “aptitude search linux” doesn't seem to pick up anything relevant.
[13:15] <apw> RAOF, they are in the ddebs archive
[13:16] <smb> Though I am not sure this is what RAOF is expecting. More for post mortem debugging and disassembly that more verbose output. Maybe saying debug on the kernel command line (instead of quiet) is enough for that purpose
[13:18] <apw> RAOF, what are your symptoms on failure
[13:19] <RAOF> The screen stops for about a second, perhaps getting distorted colours, and then the system shuts down.
[13:21] <RAOF> Without the plymouth splash kicking in.  One of the lines is something along the lines of “kernel panic, restarting”.
[13:21] <RAOF> Basically what I want to do is to produce a useful bug for you, preferably without rebuilding my kernel a hojillion times.
=== cking is now known as cking-afk
[13:28]  * cking-afk goes for some food
=== amitk-afk is now known as amitk
[13:45] <apw> RAOF, ok so i'd first try booting without quiet and splash on your command line and see how that looks
=== rsalveti_ is now known as rsalveti
[13:46] <pgraner> tgardner: emerald is back in the rack
[13:47] <Daviey> Hi, there seems to be bit of a kernel regression in current maverick that is potentially pretty critical for the server.  It seems to (oddly), caused a userspace issue of a *java* library not working as expected.  I don't know if it's related to entropy or something, but the function is handling en/de-cryption.  I would appreciate input, thanks :)  bug #588861
[13:47] <ubot2> Launchpad bug 588861 in linux (Ubuntu) (and 1 other project) "Instances block in pending state, and don't start (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/588861
[13:48] <Daviey> ^^ Unrelated to KVM.
[13:48] <tgardner> pgraner, ack
[13:48] <apw> Daviey, i suspect there will be an -rc2 kernel very shortly and that has to be less broken than -rc1
[13:49] <Daviey> apw: that is great, do you think that will be this week?
[13:49] <apw> Daviey, i'd say that is very likely
[13:49] <Daviey> apw: awesome, thanks
[13:50] <apw> its probabally not worth spending to much time debuggnig on -rc1 is really my feeling
[13:50] <Daviey> apw: Ok, moving on :), thanks
[13:51] <Daviey> apw: Whilst i'm here.....
[13:51] <Daviey> Is there anything that can assist bug #576601
[13:51] <ubot2> Launchpad bug 576601 in linux (Ubuntu) (and 1 other project) "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected (affects: 85) (heat: 588)" [High,Triaged] https://launchpad.net/bugs/576601
[13:51] <Daviey> crikey, i notice there is now a bounty! 
[13:53] <apw> Daviey, other than trying upstream releases like -rc2, probabally not a lot
[13:53] <Daviey> apw: ok, thanks.
=== cking-afk is now known as cking
[14:09] <anoteng> apw: thanks for your reply earlier. Didn't see it until now...
[14:34] <smb> tgardner, apw *sigh* ok for the sake of simplicity I would squeeze in the sfc update into the same bug as 2.6.32.13. There don't seem other updates for that in .33. 2.6.34.y did not have a stable release, yet. So the other parts of this Frankenkernel had no counterparts, yet (beside of a lot of skipping for thinkpad-acpi)
[14:34] <tgardner> smb, too late, I've already created a bug
[14:34] <apw> smb, sounds ok
[14:35] <smb> tgardner, Ok, we can decide that then in July
[14:35] <smb> apw, Could you have a quick look and potentially ack or are you quite busy?
[14:35] <tgardner> smb, bug #590783
[14:35] <ubot2> Launchpad bug 590783 in linux (Ubuntu Lucid) (and 1 other project) "Lucid sfc stable updates from 2.6.33.4 (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/590783
[14:36] <apw> smb, if it can wait about 30 mins i may be able to, trying to fix an install bug i think we are about to hit
[14:36] <smb> apw, It can
=== MTeck-ricer is now known as MTecknology
=== amitk is now known as amitk-afk
[15:31] <JFo> smb, do we do re-rolls of non-free firmware for older releases?
[15:31] <JFo> by reroll, I mean do we update that package for them?
[15:31] <smb> JFo, tgardner and cnd took care of that mostly. I think not too far back, but for LTS
[15:32] <smb> Depends a bit on the driver too
[15:32] <JFo> ah, my Q was in reference to the last comment in bug 387875
[15:32] <ubot2> Launchpad bug 387875 in linux (Ubuntu) "Samsung N120 Realtek wireless fails in Karmic (affects: 4) (heat: 34)" [Medium,Confirmed] https://launchpad.net/bugs/387875
[15:32] <cnd> JFo: is it marked against linux-firmware or linux-firmware-nonfree?
[15:32] <tgardner> JFo, I consider those to be desktop issues, therefore encourage a more recent release
[15:33] <JFo> tgardner, i thought as much
[15:33] <JFo> thanks
[15:33] <JFo> cnd, no it was against the linux pkg
=== amitk-afk is now known as amitk
[15:42] <Keybuk> hmm, since the latest kernel update on maverick, my laptop can't connect to the wireless network anymore
[15:45] <apw> Keybuk, is that using wl ?
[15:46] <apw> NAME = Sheep on Meth
[15:46] <apw> i note that 2.6.35 is names at above currently
[15:46] <Keybuk> apw: iwl3945
[15:46] <apw> Keybuk, no working from starbucks for you then
[15:47] <Keybuk> known bug or not?
=== sconklin-gone is now known as sconklin
[15:49] <tgardner> Keybuk, likely not, so you should try the mainline kernel as well, then complain upstream if its still not working.
[15:58] <apw> ogasawara, yo!  you about ?
[15:58] <ogasawara> apw: yep, just startin my day
[15:59] <apw> ogasawara, ok you are going to his this build issue as soon as you rebase to -rc2 ... the one i was seeing last friday
[15:59] <apw> i think i know the right fix now, just need a tree to do it to :)
[16:00] <ogasawara> apw: cool, was going to apply any outstanding patches from the k-t ml and then rebase to -rc2
[16:00] <apw> ogasawara, awsome, i'll push out a patch for it for you shortly
[16:00] <ogasawara> apw: sweet
=== amitk is now known as amitk-afk
[16:24] <cnd> JFo: I'd put bug 577114 as kernel-net since it's dealing with rfkill wifi issues
[16:24] <ubot2> Launchpad bug 577114 in linux (Ubuntu) "Wireless and Bluetooth switch does not work correctly on lenovo ideapad s10-3 (affects: 2) (heat: 10)" [Medium,Triaged] https://launchpad.net/bugs/577114
[16:28] <bjf> cnd, fyi: http://gizmodo.com/5556985/apple-multitouch-trackpad-peripheral-leaked
[16:28] <cnd> bjf: yep, saw that this morning
[16:29] <cnd> I usually read a live blog of wwdc keynote, so I'll see what it's all about
[16:29] <ogasawara> JFo: I notice the top 50 bug list counts bugs which we've closed (ie Fix Released, Invalid, etc.)
[16:30] <cnd> ogasawara: maybe they're bugs we've closed in the past week?
[16:30] <ogasawara> JFo: would you prefer if I modify the script to show the # of open vs closed rather than the total
[16:30] <cnd> his list is manually created
[16:31] <ogasawara> cnd: right, I was just thinking along the lines that when the # goes above 50 it indicates we need to hammer on the list, but that's not exactly true right now
[16:32] <cnd> ahhh, yeah
[16:45] <apw> ogasawara, but that is in the 'added this week' section isn't it?  and those stay there
[16:46] <apw> even when closed
[16:47] <apw> fir t
[16:48] <apw> for the week they were added
[16:48] <manjo> bjf, http://people.canonical.com/~manjo/netbooks/
[16:48] <ogasawara> apw: that's true, so I assume JFo will then go clear out the closed ones
[16:49] <apw> ogasawara, he may need to be taght
[16:51] <apw> smb, about
[16:51] <apw> ?
[16:52] <apw> ogasawara, i thought that in that table generator that the curernt week was always in full, and there was actually two tables 'this week' and 'the lot' and in the second table the closed ones are elided ?
[16:53] <JFo> cnd, cool
[16:54] <JFo> ogasawara, I can remove them during our meeting, I actually like them being there so that we can see what has happened over a week.
[16:54] <ogasawara> apw: but for the top50 list we only have a single table
[16:54]  * manjo otp ... brb soon...
[16:54] <ogasawara> apw: that can obviously be changed though
[16:54] <apw> ogasawara, i had assumed when i saw 'added this week' that this would work like the other one
[16:55] <apw> if its easy to do it might be nice to keep that semantic
[16:56] <ogasawara> apw: should be easy to add back the bits
[16:57] <apw> ogasawara, no biggie
[16:58] <ogasawara> JFo: I'll get you an updated script
[16:58] <JFo> ogasawara, cool
[17:00] <JFo> cnd, you joining us for bug chat or you busy?
[17:00] <manjo> JFo, do we have a call ? 
[17:00] <cnd> I'm going to join
[17:01] <JFo> cnd, cool
[17:01] <JFo> manjo, mumble
[17:02] <JFo> http://qa.ubuntu.com/reports/jfo/kernel-Top50.html
[17:09] <smagoun> Anyone know much about power mgmt/batteries in ubuntu on apple hardware? I bought a 63 watt-hr battery for my macbook pro. /proc/acpi/battery/BAT0/info shows the design capacity is only 58000mWh, and last full capacity is 52000 mWh. How likely is it that those values are accurate? They don't match what I expect from the hardware.
[17:10] <smagoun> (i'm on 10.04, fwiw)
[17:10] <amitk-afk> smagoun: the question is does, MacOS show the capacity correctly?
=== amitk-afk is now known as amitk
[17:10] <jjohansen> smagoun: they should be accurate
[17:11] <smagoun> amitk-afk: good question, I dunno. Haven't booted macos w/ this battery yet
[17:16] <smagoun> jjohansen: hmm, I just swapped in my old (OEM) battery, which is clearly labeled 60 watt-hr. /proc/acpi/battery/BAT0/info shows the design capacity is 56000mWh. At least the system is consistently wrong
[17:17] <jjohansen> smagoun: I've never had a battery match its printed capacity, though they are usually have higher values, not lower
[17:17] <smagoun> jjohansen: It's Apple kit, Think Different I guess
[17:17] <amitk> doesn't a LiON battery require a few charge-discharge cycles to reach its pull capacity?
[17:17] <amitk> *full
[17:18] <smagoun> amitk: that shouldn't affect the design capacity, just the last full capacity
[17:18] <amitk> true
[17:22] <smagoun> 63 W-hr is 5833 mAh * 10.8v (the design voltage). That's pretty close to the reported design capacity (58000mWh). Any chance the hardware reports design capacity in mAh rather than mW? Where does the value come from, is it pulled directly from ACPI or is it calculated?
[17:24] <jjohansen> smagoun: yeah I think it does actually report in mAh now that you mention it
[17:34] <bjf> ogasawara, where is the source for the source_linux.py apport hooks ?
[17:34] <ogasawara> it's in apport
[17:58] <bjf> ogasawara, a "bzr branch lp:apport" does not give me the source_linux.py anywhere in the resulting tree
[18:03] <ogasawara> bjf: I'd typically do a `debcheckout apport` and it should be in data/package-hooks/source_linux.py
[18:05] <bjf> ogasawara, just did that and data/package-hooks only has "source_apport.py"
[18:05] <ogasawara> bjf: hrm, not sure what's happened then
[18:06] <bjf> ogasawara, thanks, i'll figure it out
[18:06] <ogasawara> bjf: I'm seeing it here, but it's lucid.  http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/lucid/apport/ubuntu/files/head:/data/package-hooks/
[18:07] <bjf> ogasawara, hmmm 
[18:08] <bjf> ogasawara, i've been "bzr branch bzr+ssh://bazaar.launchpad.net/~apport-hackers/apport/trunk/" which doesn't get it for me
[18:09] <manjo> apw, heh.. https://wiki.ubuntu.com/KernelTeam/KernelForIdiots
[18:10] <bjf> ogasawara, or even "bzr branch lp:~apport"
[18:10] <ogasawara> bjf: not sure what the apport-hackers team is
[18:11] <ogasawara> bjf: https://wiki.ubuntu.com/Apport - "If you want to contribute to it or develop your own system based on it, you can get your own branch with bzr get lp:apport for trunk, or debcheckout -a apport for the Ubuntu packaging branch."
[18:11] <ogasawara> bjf: but then the "browse it online" link point to the apport-hackers
[18:11]  * ogasawara is confused
[18:12] <ogasawara> bjf: is that the upstream source?
[18:12] <bjf> ogasawara, not sure what you are asking?
[18:13] <ogasawara> bjf: just trying to figure out what the code shown in apport-hackers is
[18:13] <bjf> ah, yes, that "seems" the latest and greatest
[18:14] <bjf> ogasawara, a "debcheckout -a apport" got it for me, but I still don't understand
=== kamal-away is now known as kamal
[18:16] <manjo> psurbhi, long time no see 
[18:18] <psurbhi> manjo, hie :)
[18:20] <manjo> psurbhi, looks like you finally recovered ubuntuflu 
[18:20] <psurbhi> hey, i did not have a ubuntuflu and nor have i fully recovered.. infact i have to do some tests to eliminate further infection :) 
[18:21] <psurbhi> so will soon find out if i am out of it or not :)
[18:21] <manjo> psurbhi, sorry to hear that... looks like it got you good this time 
[18:21] <psurbhi> :-/
[18:22] <manjo> psurbhi, will you be in shape to attend the platform sprint ?
[18:22] <psurbhi> manjo, yes! i think so... so we can meet up then!
[18:25] <manjo> psurbhi, yep
[18:28]  * manjo out for lunch
[18:53] <apw> JFo, ok ... i've put together a very basic todo and style guide linked from the Kernel page
[18:53] <JFo> cool
[18:54]  * JFo goes to peruse
[18:54] <apw> JFo, what do you think about mixing debugging and testing together, or does that need its own section ?
[18:55] <JFo> hmmm
[18:55] <JFo> I actually like that idea
[18:55] <amitk> apw: do you start editing 20 pages at once and do an atomic save?!
[18:55] <JFo> as there will be parts pertinent to both
[18:55] <amitk> *wiki pages
[18:55] <apw> amitk, heh no why ?
[18:56] <amitk> apw: just wonderig about the 10 emails with wiki updates from you :)
[18:56] <apw> amitk, ahh no just incompetant
[18:58] <amitk> hehe
[18:59] <JFo> looks great apw, I especially like the current layout of both the todo and the gardening guide
[19:02] <apw> JFo, so what do you think about testing?  should i add it to debugging?
[19:02] <apw> or perhaps we could have a longer list of topics on the front page
[19:03] <apw> and that could be one of them
[19:03] <apw> JFo, i think i'll mock that up for testing and see how it looks
[19:03] <JFo> hmmm
[19:03] <JFo> ok
[19:04] <JFo> maybe we will need to have testing and then set up debugging links from the testing bit?
[19:04] <JFo> I'd really like for testing to be a bit separate from debugging, i think
[19:04] <JFo> I could be completely wromg though
[19:06]  * JFo heads to a quick lunch
[19:09] <apw> JFo, i'll treat it separate, we can have a full list of areas on the front page, but only links in the menu to those which are critical and commonly used
[19:09] <apw> see the current front page for what i mean
[19:12] <JFo> yeah, I like having that in the Topics section
[19:17] <apw> JFo, ok i've added that to the documentation and copied over the testing topics
[19:19] <JFo> sweet
[19:19]  * JFo goes to grab that lunch now
[19:34] <pgraner> ogasawara: ping
[19:34] <ogasawara> pgraner: pong
[19:34] <pgraner> ogasawara: [14:09] <robbiew> pgraner: looks like broadcom (STA) driver is busted on latest maverick kernel (2.6.35)
[19:34] <pgraner> [14:10] <robbiew> I'll file a bug, just an fyi
[19:34] <pgraner> [14:10] <robbiew> DKMS crapping out on building the module...works fine in the previous 2.6.34-5 kernel
[19:35] <robbiew> :)
[19:35] <ogasawara> robbiew: can you point me to your bug# so I can keep it on the radar
[19:35] <pgraner> ogasawara: I have notified the proper authorities
[19:35] <JFo> heh
[19:35] <robbiew> will do..need to recreate so I have stuff to post :)
[19:36]  * robbiew finds his ethernet cable :/
[19:36] <ogasawara> heh
[19:36] <pgraner> tgardner: any idea when henry will get the OSS driver free?
[19:44] <tgardner> pgraner, I asked him that just last week. He said he'd let me know as soon as possible. kind of vague.
[19:45] <tgardner> I've been pushing himto get it available in time for Maverick
[19:45] <pgraner> tgardner: yea, would be nice if they gave us some beta code to test, I'm sure we would help this whip it into shape, would be nice to have it this early in the cycle
[19:54] <robbiew> ogasawara: bug 590924
[19:54] <ubot2> Launchpad bug 590924 in linux (Ubuntu) "Broadcom STA (bcmwl) driver fails to build with 2.6.35-1 kernel (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/590924
[19:54] <ogasawara> robbiew: thanks
[19:55] <robbiew> ogasawara: I'll leave it with that version if you all need me to do any testing or log grabbing
[19:55]  * robbiew used ubuntu-bug, so you should have all the standard files
=== pgraner is now known as pgraner-afk
[20:15] <jjohansen>  -> Lunch
[20:26] <ogasawara> robbiew: just want to check, were the dkms errors you saw the same as http://launchpadlibrarian.net/49811242/DKMSBuildLog.txt
[20:28]  * tgardner wished we could stop packaging wl
[20:28] <tgardner> wishes*
[20:44] <manjo> JFo, I marked BGug #564051  as invalid, can you remove bugs marked invalid from your top 50 list ? 
[20:59] <robbiew> ogasawara: I never saw that on the screen...is there a logfile I can check?
=== pgraner-afk is now known as pgraner
[21:39] <ogasawara> robbiew: do you have anything under /var/lib/dkms/bcmwl/<version>/log/make.log ?
[22:43] <kees> ogasawara: do you know which of the maverick CVEs have been fixed?  http://people.canonical.com/~ubuntu-security/cve/pkg/linux.html
[22:43] <kees> ogasawara: I want to get the tracker updated
[22:44] <ogasawara> kees: let me try to get a list together for you as we split them up amongst stefan, surbhi, and myself
[22:44] <kees> ogasawara: ah, cool.  I wasn't sure if maverick was being done the same way as the stables.
[22:45] <ogasawara> kees: typically for maverick smb will tell me which one's I need fixes for.  but assuming if they're already upstream I might not need to do anything.
[22:46] <kees> ogasawara: yeah, that where I'm a bit lost.  I assume nearly all of them are fixed, but finding them isn't always obvious to me.
[22:52] <robbiew> ogasawara: okay...exact same text
[22:52] <robbiew> except mine was ALL in english
[22:52] <robbiew> no cyrillic 
[22:52] <robbiew> lol
[22:52] <ogasawara> robbiew: cool, thanks :)
[23:09] <ogasawara> kees: http://pastebin.ubuntu.com/446324/
[23:10] <ogasawara> kees: a few I marked not-affected? based solely on the CVE description but I didn't dig any further to officially verify
[23:10] <ogasawara> kees: so you may want to actually mark those needs-triage just so we can double check
=== bjf is now known as bjf[afk]
[23:11]  * bjf[afk] will be back later
[23:21] <kees> ogasawara: cool, thanks
[23:35] <kees> ogasawara: I validate the ones you had question marks on; all not-affected.  :) wheee
[23:36] <ogasawara> kees: sweet
[23:36] <kees> er, validated.