[00:17]  * jjohansen heads out for a bit, back on in 20
[00:31] <bjf> pgraner, http://kernel.ubuntu.com/~bradf/table.html
[00:32] <bjf> pgraner, that is with a better dataset, just lucid bugs
[00:32] <bjf> pgraner, still very simple algo. none of the code you sent to me
[02:43] <ogasawara> kees: have you boot tested that last yama patch you added?  "UBUNTU: SAUCE: Yama: verify inode is symlink to avoid bind mounts"
[02:44] <ogasawara> kees: I'm getting an oops/panic on two test systems I've tried (one's i386 the other amd64)
[02:45] <ogasawara> kees: if I back out just that last patch, the systems boot fine
[02:45] <ogasawara> kees: I posted some test kernels on tangerine in my home directory under yama/
[02:46] <ogasawara> kees: the "good" debs are of the latest ubuntu-maverick tip http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=summary which contains just the first 2 yama patches you originally submitted
[02:47] <ogasawara> kees: the "bad" debs are the latest ubuntu-maverick tip plus that last yama patch you added
[02:50] <ogasawara> kees: for now I'm only going to apply the first 2 patches and do an upload upload since I rebased to 2.6.35-rc5 and want to get it uploaded for testing asap
[03:05] <Dawgmatix> how do i add directories to the module search path ?
[03:11] <jk-> Dawgmatix: i don't think you can
[03:11] <Dawgmatix> ok
[03:12] <jk-> oh, you can add -d to the modprobe command line
[03:12] <jk-> but I don't think you can specify it for other invocations of modprobe
[03:13] <Dawgmatix> hmm looks like you can change modules.conf to add paths too
[03:13] <jk-> I don't see a configuration parameter to do that
[03:14] <Dawgmatix> I was going by http://pwet.fr/man/linux/formats/modules_conf 
[03:14] <Dawgmatix> that has a path parameter that you can set
[03:14] <jjohansen-afk> back on later
[03:16] <jk-> Dawgmatix: my modprobe isn't trying to read any /etc/modules.conf file though
[03:16] <jk-> (sudo strace -e trace=open,stat modprobe pretend-module-name)
[03:16] <Dawgmatix> yeah i just realised ubuntu doesnt come with a modules.conf 
[06:22] <kraut> moin
[07:10] <kees> ogasawara: I did; I functionally tested it, in fact.  You can see my tree on tangerine.  :(
[07:11] <kees> ogasawara: ah, no, I totally lied.
[07:11] <kees> ogasawara: one sec, I will fix.
[07:12] <kees> ogasawara: I had a slightly different version.  :(
[07:13] <ogasawara> kees: no worries, just push the fixed version to your tree and I'll pull it
[07:13] <ogasawara> kees: it'll make the next upload
[07:13] <kees> it's really loopy having my pristine yama source, the security-next tree and the maverick tree.  :P
[07:14] <ogasawara> kees: just for good measure, go ahead and send the pull request to the mailing list
[07:15] <kees> ogasawara: okay.  is the tree with the other two pushed already?  I can rebase my maverick tree if so.
[07:15] <ogasawara> kees: I've already applied and uploaded the other two
[07:15] <kees> okay, I'll rebase
[09:23] <lag> apw, smb: http://www.amazon.co.uk/dp/B003HIWHN0
[09:48] <hrw> lag: class2?
[09:51]  * lag shrugs
[09:52] <lag> I thought SDHC was class 4?
[09:58] <smb> There are class 6 of those as well, though that kind of triples the price
[10:10] <hrw> lag: class2/4/6/10 maybe class8 too
[10:11] <lag> @ 32GB?
[10:16] <lag> The HTC Desire's specification says: "microSD™ memory card (SD 2.0 compatible)"
[10:16] <lag> Does that mean classes >2 won't work?
[10:16] <hrw> lag: I did not know that 32GB microsd exists 
[10:16] <apw> lag, don't think so, think thats specification 2.0
[10:16] <lag> That's what I was bringing to apw and smb's attention 
[10:16] <hrw> lag: that mean that it support microsd
[10:17] <lag> How does that differ to class 2?
[10:17] <hrw> class 2/4/6/8/10 is just speed 
[10:17] <apw> classes are simply speed specifications
[10:17] <apw> presumably minimum speeds in some sense
[10:17] <hrw> sd 2.0 is specification of SD standard version 2.0
[10:17] <lag> k
[10:18] <hrw> so things like "suport for 1/4/8 bits, sdio support things"
[10:29] <hrw> 1
[10:35] <ripps> What would be the best way to get a patch into the kernel? I basically just need to drag'n'drop the wacom module source files into the kernel.
[10:36] <ripps> The kernel wacom source is out of date and doesn't support the wacom bamboo pen & touch series.
[10:39] <ripps> I've figured out the the source files in drivers/input/tablet/wacom* are the same as those in the linuxwacom package, so a simple drag and drop of the files should work. Can someone give me some advice on this.
[10:40] <smb> ripps, Upgrading a whole driver is usually rather frowned upon for released kernels, at least if that brings a log of changes. And the other question would be whether it needs some userspace update as well?
[10:41] <smb> One thing might be to have the updated driver included in linux-backports-modules
[10:41] <ripps> smb: I've already confirmed that the only the kernel module needs update. I've currently been pointing people to use a wacom-dkms package in one of my ppas
[10:41] <smb> s/a log/a lot/
[10:42] <ripps> yeah, linux-backports-modules sounds like a good idea
[10:42] <ripps> The problem is in lucid too, would it be possible to backport the driver there, as well?
[10:45] <smb> If you say Lucid, too. Is the other release Maverick? Ultimately for Maverick it would be a goal to update the driver upstream as well. Though it might be a bit late for that. And yes, for Lucid I think it would be reasonable to have that backport there as well. Maybe needs thinking of having a seperately grouped binary package, like linux-backports-input
[10:45] <ripps> sounds good to me.
[10:47] <ripps> although, the kernel input api is different between the lucid kernel and the maverick kernel, so the maverick version of the wacom source needs to be tweaked
[10:47] <ripps> Is there a guide out there on how to make a linux-backports package?
[10:47] <smb> ripps, So I would say the best approach is to bring the issue and proposal up in a mail to kernel-team@lists.ubuntu.com and let it be discussed/documented  there
[10:48] <smb> ripps, We do the l-b-m package and sadly I guess to make that extension is rather well undocumented and probably complex. 
[11:38] <tseliot> apw, smb: I've found a regression in the kernel from 2.6.32 to 2.6.35 which affects the radeon driver. How do you suggest that I start bisecting? I cloned the maverick branch but obviously it doesn't contain an Ubuntu-2.6.32 tag
[11:38] <apw> tseliot, thats triciker
[11:39] <tseliot> apw: how tricky is that?
[11:39] <apw> tseliot, i would try the mainline kernels and see if the issue is in there
[11:39] <tseliot> ah
[11:39] <apw> as thats much easier to bisect
[11:40] <apw> and you can use the mainline builds in between to narrow your search
[11:41] <tseliot> apw: and shall I rely on the date the kernel was built and look it up in the linus tree?
[11:53] <apw> tseliot, how to map an ubuntu kernel into a mainline version is a question in the kernel FAQ :)
[11:54] <apw> https://wiki.ubuntu.com/Kernel/FAQ#Given an Ubuntu kernel package version how do we find the exact mainline release it is based on?
[11:54] <apw> which points you here: http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html
[11:54] <tseliot> apw: thanks, I'll RTFM ;)
[11:57] <apw> :)
[12:44] <ripps> did the kernel-team mailinglist get my linux-backports-input proposal?
[12:45] <smb> ripps, Did not yet see anything but it might be stuck in moderation until the right half of the planet is awake
[13:32] <TeTeT> smb: thanks for your kernel source, it was built yesterday evening and we test it today :)
[13:33] <smb> TeTeT, Good to hear
[13:45] <apw> pgraner, how is your machine which was grinding till we freed the buffers ... how many more cycles has it managed
[13:47] <pgraner> apw, its done 35 and was doing fine until I started copying data to the usb disk, now even mumble is dead, I had to switch to my netbook
[13:47] <pgraner> apw, same box is showing the I/O issues
[13:48] <apw> pgraner, ok
[13:48] <apw> 35 would be counted as success me thinks on the original issue
[13:48] <pgraner> apw, yep I would agree, so tgardner's patch should do the trick
[13:48] <apw> pgraner, fingers crossed
[14:08] <andreserl> hi all. I was wondering how can I know which cn_idx number I should use for DRBD. Where can I find that #?
[14:09] <apw> andreserl, you might have better luck asking that on #ubuntu-server as they do more with DRBD than we do
[14:10] <andreserl> apw, yeah but afaik the cn_idx is the number related to the kernel. But will try asking there :) THanks
[14:10] <andreserl> (I mean the number that the module uses in the kernel)
[14:10] <apw> andreserl, its just not a kernel feature most of us would routinely use, they might and might answer sooner (or indeed at all :)
[14:11] <andreserl> apw, ok :)
[14:11] <andreserl> thanks
[14:15]  * apw cirtanly has no idea what the cn_idx even is :)
[14:20] <smb> apw, Guess we can guess what the idx part is but cn... :)
[14:20] <tgardner> smb, cn == channel number ?
[14:21] <andreserl> connection index
[14:22] <smb> Could be a lot without knowing. So andreserl might know more than us here
[14:23] <andreserl> smb, I just know I need to now the cn_idx for the DRBD kernel module and make the change in the drbd8 package before uploading :/
[14:23] <apw> what does cn_idx stand for even
[14:24] <apw> idx presumably is the index ... 
[14:24] <smb> apw, I think we were at connection index
[14:24] <andreserl> apw, connection index
[14:24] <smb> But server is likely the guys. Given they provide the kernel module as dkms
[14:25] <andreserl> smb, The drbd kernel module is included in the kernel starting from 2.6.33,
[14:25] <andreserl> so there's no longer the need to use dkms
[14:26] <andreserl> and even so, when using dkms, we also specify the cn_idx
[14:27] <smb> andreserl, ok, I might be backwards there. Last thing I remember was making it dkms because we had it in seperate modues and too often behind what was needed
[14:29]  * apw is looking for it
[14:29] <andreserl> smb, ummm what I know is that in drbd module was in hardy kernel, after that, it wasn't. And for what I understand, from now on, the DRBD module will be in the kernel starting from 2.6.33
[14:31] <andreserl> http://www.drbd.org/download/mainline/
[14:33] <andreserl> in the drbd8 source package, in debian/dkms.conf we specify the cn_idx: "MODULES_CONF[0]="options drbd cn_idx=7"
[14:33] <andreserl> in hardy, Intrepid, I believe it used to be 6
[14:33] <andreserl> in debian is 4
[14:33] <andreserl> so now in maverick, I don't really know which one is it
[14:34] <apw> include/linux/connector.h:#define CN_IDX_DRBD                   0x8
[14:34] <andreserl> apw, awesome! thanks :)
[15:19] <amitk> tgardner: looks like you're the person with the IGEPv2 OMAP board
[15:23] <tgardner> amitk, oddly enough, I am just in the process of turning it on this morning. I've never encountered a web site that is quite so bad (http://www.igep-platform.com)
[15:24] <amitk> heh :)
[15:25] <amitk> tgardner: some folks are interested in knowing if it is well-supported in ubuntu. My suspicion is that it'll required only a few patches to get it well supported.
[15:26] <tgardner> amitk, the default image isa 2.6.28 kernel, but I see they alaso have up to 2.6.33 on their web site
[15:26] <hrw> tgardner: I would just try to boot default ubuntu omap3 kernel
[15:26] <tgardner> amitk, perhaps I should just try a Lucid omap3 rootfs?
[15:27] <amitk> tgardner: just boot with lucid
[15:27] <amitk> including the kernel
[15:27] <tgardner> amitk, easier said then done. still figuring out how to do that.
[15:27] <amitk> the only thing I have no idea about is the bootloader on there.... so keep what they ship with.
[15:28] <tgardner> amitk, I think it'll boot from micro SD
[15:28] <amitk> tgardner: keyword: ogra 
[15:28] <amitk> tgardner: but yes, micro-sd is the quickest way
[15:29] <tgardner> amitk, gotta find the rootfs first. somewhere on ubuntu.com ?
[15:32] <amitk> tgardner: http://cdimage.ubuntu.com/ports/releases/10.04/release/
[15:33] <tgardner> amitk, try the omap server install?
[15:34] <amitk> tgardner: yes, unfortunately we don't provide premade rootfs yet 
[15:34] <amitk> you can create your own rootfs with rootstock scripts
[15:34] <tgardner> amitk, so if it boots from SD, where does it install? External USB driver?
[15:35] <mpoirier> tgardner: you'll have to use netboot to get your setup on SD card.
[15:35] <amitk> yes, USB drive/HDD
[15:36] <mpoirier> tgardner: I'm running into the same problem install  lucid UNR on beagleboard.
[15:40] <tgardner> mpoirier, on the phone, hang on.
[15:46] <apw> tseliot, about ?
[15:46] <tseliot> apw: yep
[15:47] <apw> wondering if you knew what plymouth did when it is started ... whether it clears the VT it is selecting for instance
[15:48] <apw> in broad terms its activity while owning the VT
[15:49] <apw> tseliot, ^^
[15:51] <apw> tseliot, can i get plymouth to tell me what happened to it during a boot for instance.  interested to know (as an example) if it gets a resize event on drm load
[15:51] <tseliot> apw: plymouth gets its own "screen" that it swaps in with a black screen (at the beginning)
[15:52] <tseliot> ah, a resize event? Why do you need to know that?
[15:53] <apw> well i am trying to work out when plymouth has control over the screen and what it does during the time
[15:53] <apw> it being the one which switches VT is interesting
[15:54] <tseliot> apw: if you want some good answers you can join #plymouth and ask halfline (i.e. the author). He's very helpful
[16:07] <manjo> JFo, are we having the bug chat this morning ?
[16:08] <JFo> no, we are having the team bug day in this channel
[16:08] <JFo> there was no plan for a bug chat
[16:08] <JFo> just coordination to keep from duplicating effort
[16:08] <manjo> JFo, my cal says 10am-1pm .. could my cal is misbehaving 
[16:09] <JFo> nope, that is correct
[16:09] <JFo> 3 hour block per tgardner to solely work on bugs
[16:09] <smb> manjo, Mine says from 5pm to 8pm, yours is in the wrong tz. ;-P
[16:09] <JFo> nicely blocked out on the cal by request of smb
[16:09] <JFo> :)
[16:10] <smb> Right, at least we won't forget it then
[16:10] <manjo>  yeah don't know why my cal is always messed up
[16:10] <manjo> we need utc google cal 
[16:10] <JFo> hmmm, your times may be off. tgardner wants it to start at 8AM PST
[16:10]  * smb hopes manjo recognizes a joke when it passes by
[16:11] <JFo> heh
[16:11] <manjo> smb, wrong tz... ah you got me !
[16:11] <smb> sorry could not resist
[16:11] <bjf> manjo, the time is now 8:12 PST
[16:12] <manjo> smb, yeah easy target
[16:12] <JFo> 12 minutes past the start of the bug day
[16:13] <tgardner> JFo, your search URL in the calendar event doesn't produce many items
[16:13] <smb> apw, JFo So there one or the other where at least some issues are understood but whether there is a fix is unclear and also how much other issues are mixed
[16:13] <smb> like bug 563156
[16:13] <ubot2> Launchpad bug 563156 in linux (Ubuntu) "[ATI Graphics][Lucid] laptop runs hot, shorter battery life, fan always on (affects: 31) (heat: 179)" [High,Triaged] https://launchpad.net/bugs/563156
[16:13] <JFo> tgardner, search url?
[16:13] <tgardner> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-proposed+karmic&field.tags_combinator=ALL
[16:14] <JFo> ugh
[16:14] <JFo> wrong link
[16:14] <manjo> tgardner, http://qa.ubuntu.com/reports/jfo/kernel-Top50.html
[16:14] <JFo> I'll fix
[16:14] <smb> tgardner, I replied to his mail with the right link
[16:14] <smb> I hope to the right mail
[16:14] <amitk> JFo: what group membership gets all that bug mail? (I want to remove myself from the group). kernel-bugs doesn't seem to be it.
[16:14] <JFo> tgardner, changed it now
[16:14] <tgardner> amitk, ubuntu-kernel-team ?
[16:15] <amitk> tgardner: aah, it is kernel-team?
[16:15] <manjo> amitk, arnt you *supposed* to be subscribed to get all bug mails ?
[16:15] <JFo> smb, I had a bad link in the calendar item
[16:15] <JFo> so I fixed it
[16:15] <JFo> sorry for leaving it out of the e-mail
[16:15] <amitk> manjo: nope, everyone in a _certain_ group gets all bug mail filed against the linux package
[16:15] <smb> JFo, Oh calendar. :) Good. I saw that there was only a [1] in your mail
[16:15] <JFo> got in too big a hurry
[16:15] <tgardner> amitk, I get 'em because of 'You received this bug notification because you are a member of Canonical Kernel Team'
[16:16] <bjf> tgardner, i think amitk is saying he no longer wishes to be "a member of Canonical Kernel Team"
[16:17] <tgardner> bjf, I'm not sure he gets a choice there.
[16:17] <JFo> heh
[16:17] <bjf> tgardner, maybe he is giving notice :-)
[16:18] <amitk> bjf: I've got 24871 emails in my ubuntu-bugs folder (and growing). But yes, that'd be a nice subtle way to give notice ;)
[16:18] <tgardner> amitk, weren't you the one promoting server side procmail ?
[16:18] <JFo> don't do it amitk! think of the children! ;)
[16:19] <amitk> tgardner: it is all filtered away nicely, but it is an eyesore
[16:23] <jjohansen> bjf: http://launchpad.net/kslm
[16:24] <bjf> jjohansen, thanks
[16:24] <jjohansen> bjf: also www.headinthecloud.net
[16:27] <bjf> jjohansen, am i missing something, that launchpad link is little more than a title
[16:28] <jjohansen> bjf: nope, that is all I have
[16:28] <jjohansen> well that and the headinthecloud.net
[16:38] <bjf> pgraner, http://kernel.ubuntu.com/~bradf/table.html
[16:39] <jjohansen> bjf: from what I gathered kslm doesn't do atop functionality yet "KSLM which may add similar capabilities to the kernel but in a  more elegant way"
[16:40] <jjohansen> bjf: from looking around I am not sure it does anything yet, I've asked SpamapS if he has anymore info
[16:40] <bjf> jjohansen, from the comment on the mailing list and the lack of other information, it's vaporware
[16:40] <jjohansen> yeah, that is my impression
[16:53] <bjf> JFo, is there a wiki page with your "standard replies"?
[16:53] <JFo> there isn't one with the kernel specific ones yet
[16:54] <JFo> there is for regular bug comments
[16:54] <JFo> but I assume you want the kernel specific ones
[16:54] <bjf> JFo, ack
[16:54] <manjo> sconklin, he is deafend 
[16:54] <JFo> actually, I seem to recall there being one in KernelTeam bjf
[16:55] <sconklin> manjo: no biggie. 
[16:55] <JFo> I remember ogasawara pointing me to it
[16:55] <bjf> JFo, i'll hunt a bit
[16:55] <ogasawara> lemme dig it up, just a sec
[16:55]  * manjo gets some coffee
[16:56] <sconklin> JFo: I've seen a bunch of "Pulse audio crashes when I play something" and "PA crashes when I configure inputs for recording" bugs lately - there are patches for some of those in the pile that's waiting in stable, which will get queued after the next security update for Lucid.
[16:56] <JFo> excellent
[16:56] <JFo> thanks for the heads up sconklin 
[16:57] <sconklin> it'll be a couple of weeks at least until they hit preproposed
[16:57] <sconklin> possibly less
[16:57] <ogasawara> bjf: https://wiki.ubuntu.com/Bugs/Responses but I don't think that has our kernel stock replies listed
[16:57] <tgardner> amitk, is there a Freenode ARM channel?
[16:58] <ogra> tgardner, bing it to the sprint and we'll get the board running maverick :)
[16:58] <ogra> *bring even
[16:59] <tgardner> ogra, I've got the Lucid image on SD, but can't figure out how to get it to boot it. 
[16:59] <amitk> tgardner: #ubuntu-arm, #armlinux, #linaro
[16:59] <amitk> take your pick
[17:00] <tgardner> amitk, ack
[17:01] <ogra> tgardner, lucid only includes bootloader binaries for bagelboards
[17:01] <ogra> *beagle ... (they dont have a hole :P )
[17:02] <ogra> tgardner, its likely that you need another bootloader binary 
[17:02] <bjf> ogra, bagelboards, if they don't boot you can eat em
[17:02] <tgardner> ogra, this gizmo has x-boot and u-boot, though I don't know what is actually installed
[17:03] <ogra> tgardner, so you end up in a serial u-boot prompt if you fire it up ?
[17:03] <tgardner> ogra, nope, its got a 2.6.28 kernel that brings up X. 
[17:03] <ogra> hmm
[17:04] <tgardner> using on-board flash that came with it pre-programmed
[17:04] <ogra> well, you should see the boot process on the serial console somehow
[17:04] <tgardner> ogra, I don't have the serial adapter, Loic is bringing it
[17:04] <ogra> and usually u-boot has an option to stop the boot so you can input bootloader cmds
[17:04] <ogra> ah
[17:04] <ogra> yeah, without it gets tricky
[17:05] <tgardner> ogra, the monitor goes white until too late. by then the kernel has booted.
[17:05] <ogra> i'm hoping linaro finds a way to add framebuffer console support to u-boot some day
[17:05]  * ogra hates serial consoles with passion
[17:06] <tgardner> ogra, yeah, this one requires the usual square pin header
[17:06] <ogra> ah, i'll have mine with me 
[17:10]  * apw notes that * psurbhi is now known as csurbhi-afk
[17:12] <bjf> JFo, ogasawara https://wiki.ubuntu.com/Kernel/BugTriage/Responses
[17:13] <JFo> awesoem, thanks bj
[17:13] <JFo> sigh
[17:13] <JFo> bjf that is
[17:13] <JFo> I am not a keyboard cowboy today\
[17:13] <JFo> see ^
[17:21] <bjf> JFo, i just worked bug 494476 a bit
[17:21] <ubot2> Launchpad bug 494476 in linux (Ubuntu) ""Smbd","kjournald2" and "rsync" blocked for more than 120 seconds while using ext4. (affects: 5) (heat: 32)" [Medium,Incomplete] https://launchpad.net/bugs/494476
[17:21] <ogasawara> smb: can you refresh my memory...when sending a patch to stable, should I CC everyone who signed off on the patch or just CC the maintainer?
[17:21] <ogasawara> smb: I'm basically looking at upstream commit 68f194e027ecfbbc8d5515bc40787e542eed59e9 for bug 544740
[17:21] <ubot2> Launchpad bug 544740 in linux (Ubuntu Lucid) (and 1 other project) "fix for iSight cameras not being recognized (affects: 3) (heat: 20)" [Medium,Triaged] https://launchpad.net/bugs/544740
[17:21] <JFo> that is an interesting bug bjf
[17:22] <ogasawara> smb: and I assume stable is still accepting patches for 2.6.32.y?
[17:22] <smb> ogasawara, I usually cc all on sob
[17:23] <smb> ogasawara, Yes, still open. Usually if it applies to all in stable it gets applied to all. Currently .32, .33 and .34
[17:23] <smb> Not sure how long .33 goes on
[17:24] <ogasawara> smb: cool.  yah my main concern is .32 for Lucid
[17:24] <smb> ogasawara, As it would be mine. :)
[17:28] <bjf> cnd, ping
[17:34] <tseliot> apw: do we have a kernel 2.6.35 without maverick's patches in the mainline repository?
[17:34] <apw> we have 2.6.35-rcN in there yes
[17:35] <tseliot> I'm asking because I can't find any: http://kernel.ubuntu.com/~kernel-ppa/mainline/
[17:35] <apw> tseliot, look to be there to me
[17:35] <tseliot> apw: I can see v2.6.35-rc5-maverick
[17:35] <apw> thats the one yes
[17:36] <tseliot> apw: but isn't that based on maverick's tree?
[17:36]  * smb sees a faq question coming up
[17:36] <tseliot> yes, I know that mainline kernels are supposed to come from upstream
[17:36] <apw> smb, its already in the faq
[17:37] <apw> tseliot, that is the release from which the configuration came
[17:37] <smb> apw, I know. I should have probably said sees the pointer to faw coming
[17:37] <tseliot> oh, "Why do mainline kernel builds have a -<series> suffix?"
[17:37] <apw> heheh yeah
[17:37]  * manjo getting lunch will be back soon
[17:37] <tseliot> my sight is not good when my blood pressure is low, sorry
[17:38] <smb> tseliot, No worries. Being a bit silly which I attribute to the heat
[17:39] <tseliot> it's really too hot here in Italy
[17:39] <smb> Same here in Germany
[17:40] <apw> tseliot, whats the temp today?  is a nice 20c here
[17:40] <tseliot> lucky you, it's more than 32° here...
[17:40] <tseliot> and it's humid
[17:41] <smb> apw, In the sun it seems to be near 40 here
[17:41] <tseliot> I heard they have 40° in Venice...
[17:41] <smb> But 34 is probably more realistic
[17:41]  * apw likes the .uk
[17:42]  * smb will ask again when apw is drowning in rain
[17:42] <tseliot> apw: in what part of the UK?
[17:42]  * bjf notes it is currently 17 C here in portland
[17:42]  * ogra is envious
[17:42] <tseliot> Portland - Oregon?
[17:42] <bjf> tseliot, yes
[17:43] <apw> smb, indeed :)  tseliot in london near wimbledon tennis
[17:43] <tseliot> ah
[17:44] <tseliot> is Portland as rainy as London (I've never been to London or to the UK)
[17:44] <tseliot> ?
[17:44] <bjf> tseliot, we have had a *lot* of rain this last 12 months
[17:45] <ogra> if you want to see real rain go to bergen in norway
[17:45] <tseliot> I noticed that when I visited Portland in January
[17:45] <ogra> they have umbrella vending machines on every corner
[17:45] <tseliot> hehe
[17:46]  * tseliot reboots
[17:46]  * smb thinks he did enough damage for today and relocates somewhere closer to cool drinks
[17:56]  * jjohansen nees to run an errand for 30 min
[17:57] <ogasawara> JFo: I just noticed a small typo in the KernelBugListTop50.py script which I think is preventing the Won't Fix bugs from showing up under the Closed Bugs section on the web page
[17:58] <JFo> hmm, I hadn't even noticed
[17:58] <ogasawara> JFo: line 217, there's as bit to check bug_task.status == "Won't Fix "
[17:58] <JFo> ah the space
[17:58] <ogasawara> JFo: yep
[17:59] <ogasawara> JFo: I'd fix it myself, but I don't have permissions to commit it to the canonical-qa-tracking tree
[17:59] <JFo> k, no sweat
[18:02] <JFo> ogasawara, fixed
[18:03] <ogasawara> JFo: sweet, thanks
[18:03] <JFo> np
[18:03] <JFo> may take a bit for it to pull and run
[18:26] <jjohansen> bjf: just got confirmation that KSLM is pie in the sky vaporware atm
[18:26] <bjf> jjohansen, nice!
[18:33] <Keybuk> People who include the mouse cursor in screenshots should be killed
[18:33] <Keybuk> *glares at cking*
[18:35] <apw> ogasawara, are you looking at bug#589123
[18:36] <ogasawara> apw: I was just digging into that, but it seems it's dependent on addition config options
[18:36] <apw> ogasawara, ok i'll move on
[18:36] <tgardner> Keybuk, I sent a merge request for ureadahead. did I get it right this time?
[18:36] <Keybuk> tgardner: will look later
[18:37] <Keybuk> oh, no, it's right in front of me
[18:37] <Keybuk> yes, that looks right :p
[18:37] <apw> ogasawara, so this top 50, i think we want to elide the closed bugs from the top table now don't we
[18:38] <tgardner> Keybuk, how do I test it? I installed an updated package and rebooted, but the trace buffer size is still 1408. Can I exercize ureadahead without rebooting?
[18:38] <ogasawara> apw: I thought the original consensus was to keep them there, but it's an easy tweak to omit them
[18:38] <apw> i th
[18:38] <Keybuk> tgardner: sure, just run ureadahead
[18:38] <Keybuk> ;)
[18:38] <Keybuk> w/ --force-trace etc.
[18:39] <ogasawara> apw: I prefer them not showing at the top as they're displayed at the bottom as closed anyways
[18:39] <apw> ogasawara, it not clear quite how we can count the active ones if the closed ones are in the top
[18:39] <Keybuk> I think 1408 kB is the default
[18:39] <Keybuk> wing-commander scott% cat /sys/kernel/debug/tracing/buffer_size_kb 
[18:39] <Keybuk> 7 (expanded: 1408)
[18:39] <Keybuk> no idea what that expanded stuff means
[18:39] <Keybuk> probably the minimum size ~1.5MB
[18:40] <jbarnes> arg
[18:40] <jbarnes> make install from my kernel tree *still* doesn't work in 10.04
[18:41] <tgardner> Keybuk, well, regardless of what the initial value should be, ureadahead appears to be restoring it.
[18:42] <Keybuk> cool
[18:42] <Keybuk> it should
[18:43] <Keybuk> it always used to, until I deleted that code ;-)
[18:43] <tgardner> Keybuk, shall I upload it again for Lucid?
[18:43] <Keybuk> for lucid, I'll be uploading ureadahead2 soon enough
[18:44] <tgardner> Keybuk, just to be clear, ureadahead2 is for Maverick only?
[18:45] <Keybuk> yes
[18:50] <apw> jbarnes, did we break you ?
[18:51] <jbarnes> apw: yeah I think it worked briefly
[18:51] <jbarnes> but somehow /sbin/installkernel lost its mkinitramfs and update-grub calls
[18:51] <tgardner> apw, debian commonization?
[18:52] <apw> tgardner, not sure we even supply that file
[18:52] <apw> nope its part of debianutils
[18:52] <tgardner> oh, I thought it was part of post-init
[18:53] <apw> tgardner, yep we do it there as well for our kernels
[18:55]  * tgardner is feeling stupid, must need lunch.
[18:56] <apw> jbarnes, seems to be a direct sync from debian, so i guess they are borked too
[18:58] <jbarnes> yeah maybe, I haven't tried regular debian
[18:58] <jbarnes> maybe you should use the fedora bits :)
[18:58] <apw> jbarnes, heh thanks
[19:02] <ogasawara> JFo: sent you email with a patch to the KernelBugListTop50.py script to omit showing the closed bugs at the top, since we already display them at the bottom
[19:02] <JFo> cool, thank you
[19:03] <apw> JFo, so how is the bug 'hours' going ?
[19:03] <apw> are we going to get stats like we do for normal bug days ?
[19:03] <apw> with little up and down arrows ?
[19:03] <JFo> hmm, I didn't set that up for this, but I should get that going
[19:03] <JFo> I actually forgot all about it
[19:04] <JFo> haven't been doing it for the Bug Days either
[19:04]  * JFo fail
[19:04] <apw> JFo, ogasawara, btw currently 'Won't Fix' is not a closed state ... which is is
[19:04] <ogasawara> apw: it's a closed state, should be fixed with the patch I just sent JFo
[19:05] <apw> ogasawara, cool thanks
[19:05]  * apw has hit 5 at least ... in two hours ... hrmph
[19:05] <ogasawara> JFo: I'd found one other place where there was an additional whitespace inserted
[19:06] <JFo> k
[19:09] <apw> JFo, does that mean its too late to get the before numbers ?
[19:10] <JFo> apw, most likely
[19:10] <JFo> the only thing that could be possible...
[19:10] <JFo> one sec.. let me check something
[19:11] <apw> JFo, it nice to be able to see if anyone bothered
[19:17] <ogasawara> JFo: it might be possible to extract the before numbers by looking at http://qa.ubuntu.com/reports/jfo/kernel-buglist-Top50-archive/kernel-buglist-2010-07-13.html
[19:18] <JFo> yep was just looking at that
[19:51] <jjohansen> -> lunch
[20:02] <sabdfl> hello all
[20:02] <sabdfl> who's the right person to look into https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/554099
[20:02] <ubot2> Launchpad bug 554099 in linux (Ubuntu Maverick) (and 3 other projects) "[PATCH] Qualcomm Gobi 2000 3G (gobi_loader/qcserial) broken in 10.04 (affects: 45) (dups: 4) (heat: 274)" [High,Confirmed]
[20:02] <sabdfl> common 3G device that doesn't work with lucid but needs to
[20:02] <sabdfl> pgraner: ^?
[20:06] <bjf> jfo, lets get this bug ^ on our top 50 and i'll at least start looking at it
[20:07] <bjf> sabdfl, that ok?
[20:07] <JFo> yep, sorry, was off reading the bug
[20:07] <JFo> it will be added, chatting with pgraner about it now
[20:08] <bjf> JFo, sabdfl looks like there are patches attached the bug, i'll look at them
[20:08] <JFo> thanks bjf 
[20:09] <JFo> sabdfl, I've made pgraner aware of the issue. He was taking care of an errand before travel this week.
[20:09] <JFo> I have added the bug to our "hot list"
[20:13] <JFo> bjf, looks like it is no issue for MAverick
[20:13] <bjf> JFo, ack, though i'd like to see more testing there to be sure
[20:13] <JFo> I agree
[20:14] <JFo> tgardner, you around?
[20:14] <tgardner> JFo, yo
[20:15] <JFo> any experience with gobi_loader?
[20:15] <tgardner> nope
[20:15] <JFo> per the bug mentioned by sabdfl above
[20:15] <JFo> hmmm
[20:15] <tgardner> looking
[20:15] <JFo> thank you
[20:15] <JFo> :)
[20:18] <tgardner> JFo, looks like smb has already been working on the Lucid solution via LBM. bug #592046
[20:18] <ubot2> Launchpad bug 592046 in linux-backports-modules-2.6.32 (Ubuntu Lucid) (and 3 other projects) "Lenovo x201 WWAN module in Lucid kernel (dup-of: 554099)" [Wishlist,In progress] https://launchpad.net/bugs/592046
[20:18] <ubot2> Launchpad bug 554099 in linux (Ubuntu Maverick) (and 3 other projects) "[PATCH] Qualcomm Gobi 2000 3G (gobi_loader/qcserial) broken in 10.04 (affects: 45) (dups: 4) (heat: 274)" [High,Confirmed] https://launchpad.net/bugs/554099
[20:18] <JFo> ah, great news
[20:18]  * JFo loads those bugs
[20:19] <JFo> or rather that bug, since I have the other open already
[20:20] <JFo> ah, now I remember why this is familiar
[20:21] <tgardner> JFo, I suggest dropping a note to smb requesting that he git 'er done.
[20:21] <JFo> I was just thinking that
[20:21] <bjf> JFo, i/we need to get with smb and get the bug updated (the one sabdfl pointed at)
[20:21] <bjf> :-)
[20:21] <JFo> tgardner, do you think it worthwhile to copy over smb's request for testing?
[20:21] <JFo> bjf, you read my mind :)
[20:21] <tgardner> JFo, couldn't hurt
[20:21] <JFo> k, will do
[20:22] <bjf> JFo, tgardner if this is something that has lagged because of smb's load, i'll work with him to get 'er done
[20:23] <tgardner> bjf, I'm sure he won't mind
[20:23]  * smb get red ears
[20:24] <smb> tgardner, The request itself had been dropped as the customer in question moved to a different hw but I have the patches prepared (but not tested)
[20:24] <jbarnes> apw: I'll trade you fixes: patch for fdo bug #28739 for a fix to installkernel :)
[20:24] <ubot2> Launchpad bug 28739 in mythplugins (Ubuntu) "--enable-exif (heat: 2)" [Medium,Fix released] https://launchpad.net/bugs/28739
[20:24] <jbarnes> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/578673 is the corresponding lp bug
[20:24] <ubot2> Launchpad bug 578673 in linux (Ubuntu) "[arrandale] Resume doesn't work on a Latitude E6410 (affects: 25) (dups: 2) (heat: 143)" [Critical,Confirmed]
[20:24] <bjf> smb, read the scrollback for another related bug sabdfl pointed us at
[20:24] <JFo> smb, is that package still there?
[20:25] <tgardner> smb, sounds like at least one _big_ customer is still interested.
[20:25] <smb> JFo, I did not delete it
[20:25] <JFo> ah good
[20:25] <JFo> I have asked for further testing of it in the related bug
[20:25] <JFo> if that makes sense to you
[20:25] <smb> JFo, tgardner One thing to note is that there is no firmware which is required
[20:26] <JFo> I saw that it seems to work in Maverick
[20:26] <JFo> is that due to these patches?
[20:26] <JFo> or rather it seems to work
[20:26] <smb> JFo, The kernel parts have gone upstream
[20:26] <JFo> bjf and I agree that more testing is probably warranted
[20:26] <JFo> cool
[20:26] <smb> JFo, But there is the fw-loader and the fw
[20:26] <JFo> I see
[20:27] <smb> mjg59, has done the loader but cannot provide fw
[20:27] <JFo> due to licensing
[20:27] <smb> as that is qualcom licensed
[20:27] <smb> Yeah
[20:27] <tgardner> smb, we could always drop it into the non-free package
[20:27] <smb> tgardner, The advice I've seen was to extract from win packages. So maybe fw cutter
[20:28] <mjg59> The firmware is not only non-free, it's non-distributable
[20:28] <JFo> ugh
[20:28] <mjg59> The license on the firmware packages expressly prohibits distribution
[20:28] <JFo> do we know someone at Qualcomm we can yell at? :-) j/k
[20:28] <mjg59> I've yelled at everyone in Qualcomm I've found without any joy
[20:29] <JFo> tgardner, is that an option?
[20:29] <JFo> or would we open ourselves to issues
[20:29] <tgardner> smb, well then, perhaps a README with instructions for how to get the firmware.
[20:30] <tgardner> why does Maverick work ?
[20:30] <JFo> good question
[20:30] <JFo> hence my thought that more testing is needed
[20:30] <smb> tgardner, Yes I hope I already copied the original one from mjg59 into the packaging
[20:30] <smb> But it was a quick job
[20:31] <smb> I wanted to know first whether the packaging in general works
[20:31] <mjg59> I suspect Maverick works because the tester rebooted from Windows
[20:31] <JFo> ah, good point
[20:31] <tgardner> ah, the 'ol softboot ...
[20:31] <JFo> this is why i vaguely recalled this issue
[20:32] <mjg59> Using Windows as a glorified firmware loader is obviously an option, but a kind of expensive one
[20:32] <JFo> and not at all desirable
[20:32] <JFo> :)
[20:38]  * JFo starts getting ready for his classroom session
[20:44] <pgraner> tgardner, the bug sabdfl pointed out said it worked in Karmic, how was that the case if the firmware is a legal nightmare?
[20:45] <mjg59> I know that there's several companies who have contracts with Qualcomm to distribute the firmware internally
[20:45] <tgardner> pgraner, well, we did do a bunch of firmware cleanup
[20:45] <mjg59> Pre-Lucid,they'd just need to drop in the firmware and things would work. In Lucid, the kernel is broken
[20:46] <pgraner> tgardner, I did that during Jaunty/Karmic and I don't remember that one, and if we had it in linux-firmware, we moved it to -non-free
[20:46] <tgardner> pgraner, mjg59 points out that the driver in Lucid is just broken
[20:46] <pgraner> mjg59, ture, the reported didn't mention if they cut the fw and dropped it in
[20:47] <pgraner> tgardner, we should look in non-free and see if its there just in case
[20:49] <tgardner> pgraner, doesn't look like it is in non-free
[20:50] <pgraner> tgardner, ok then my guess is that they cut the fw and dropped it in
[20:50] <tgardner> pgraner, wou'dn't be surprised
[20:56] <pgraner> there goes the neighborhood... jcastro just arrived
[20:56] <jcastro> I am trying to figure out the main developer of a certain feature in the kernel (fscache), I have deduced from the upstream mailing list that it's probably David Howells @ Red Hat. Is there a way I can find out for sure without checking out the entire kernel?
[20:56] <jcastro> also, hi pgraner, good to see you too. :D
[20:57] <tgardner> jcastro, FS-CACHE: LOCAL CACHING FOR NETWORK FILESYSTEMS
[20:57] <tgardner> M:      David Howells <dhowells@redhat.com>
[20:57] <tgardner> L:      linux-cachefs@redhat.com
[20:57] <tgardner> S:      Supported
[20:57] <tgardner> F:      Documentation/filesystems/caching/
[20:57] <tgardner> F:      fs/fscache/
[20:57] <tgardner> F:      include/linux/fscache*.h
[20:57] <jcastro> tgardner: thank you very much!
[20:59] <simar> Good Luck JFo , for the current session :)
[20:59] <JFo> thanks :)
[20:59] <pgraner> just  like a community guy drop in here only when they need something....
[20:59] <pgraner> jcastro, ^^^^^^^^^
[20:59] <jcastro> pgraner: I am waiting on your guy to finish the docs so I can finish my forum work item. :p
[20:59] <JFo> I'm headed to #ubuntu-classroom for those who'd like to join me
[20:59] <JFo> jcastro, :-P
[21:00] <simar> cheers for JFo !!!
[21:00] <bjf> JFo, i love a good train wreck :-P
[21:00] <JFo> heh
[21:01] <achiang> jcastro: if you're trying to avoid pulling the entire git tree, you can just look online http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree
[21:22] <sabdfl> bjf: thanks much, sorry was afk
[21:23] <bjf> sabdfl, no prob. looks like smb already has most of a solution
[21:23] <pgraner> sabdfl, looks like we have a patch, the issue with this card is the firmware, it is non-redistributable :-(
[21:23] <sabdfl> mjg59: we could try reach Qualcomm through another route
[21:25] <sabdfl> are there a whole bunch of different firmwares from QC we should ask about, or just this one?
[21:26] <mjg59> There's a generic GSM firmware, a generic CDMA firmware and then at least 10 carrier-specific firmwares
[21:36] <solarion> sabdfl: hey
[21:46] <ogasawara> JFo: good session
[21:46] <JFo> thanks ogasawara :)
[21:46] <bjf> JFo, good job
[21:46] <JFo> thank you bjf
[21:48] <pgraner> JFo, good one
[21:48] <JFo> thanks pgraner 
[21:48] <JFo> hope i covered the items clearly
[21:49] <sconklin> yeah JFo I caught the end, it was good
[21:49] <JFo> cool, thanks sconklin 
[21:56] <pgraner> jjohansen, any news on AA upstreaming?
[21:57] <jjohansen> pgraner: just running checkpatch on my patches
[21:57] <jjohansen> ended up doing a bug fix yesterday
[21:58] <pgraner> jjohansen, cool, ping me when you send it upstream pls
[21:59] <jjohansen> pgraner: do you want a CC on the header email?
[21:59] <pgraner> jjohansen, whatever is easiest for you
[22:00] <jjohansen> pgraner: ack
[22:00] <pgraner> jjohansen, thanks
[22:21]  * pgraner is outta here for the day, gotta pack travel tomorrow... later
[22:24] <JFo> same here
[22:24] <JFo> see you chaps
[22:43]  * manjo heads out to get some exercise