[02:04] <Kubuntiac> can anyone tell me the deb sources line to add the mainline kernel daily ppa? I don't mean "http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/" I'm looking for the line to add to sources to get files from that location on updates.
[02:04] <Kubuntiac> ie ppa:kernel-ppa/mainline or whatever it actually is
[02:05] <RAOF> There isn't one.
[02:05] <Kubuntiac> I must be misunderstanding something here then... what's the point of a ppa that you can't add to your sources?
[02:06] <RAOF> It's not really a PPA.
[02:06] <Kubuntiac> So it's just called kernel-ppa? o_O
[02:06] <RAOF> The intention is to make it easy for people to test on an upstream kernel.
[02:07] <Kubuntiac> Sure. I just want to contantly be testing the latest upstream kernel...
[02:08] <Kubuntiac> Anyway, thanks for your help. I guess I'll just download manually every few days
[08:05]  * abogani waves
[08:18] <abogani> How can I compile a separated module? Is there any guide about it?
[08:19] <jk-> abogani: does it have a makefile?
[08:19] <jk-> (and do you want to build a package, or just the .ko?)
[08:22] <abogani> jk-: I would want apply a very little patch on already present module.
[08:22] <jk-> so you have the source tree for the module?
[08:24] <abogani> I would prefer use the -headers package.
[08:25] <abogani> Is there any RTFM or wiki URL/I?
[08:26] <abogani> Google suggests this: http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html
[08:33] <kraut> moin
[08:41] <jjohansen1> smb: tim grabbed Bug #659084 today before I got to it
[08:41] <ubot2> Launchpad bug 659084 in linux (Ubuntu Maverick) (and 1 other project) "2.6.35-22-virtual is missing nfs modules (affects: 10) (dups: 1) (heat: 66)" [High,In progress] https://launchpad.net/bugs/659084
[09:39] <alexandrosorodio> Hello there , doen anyone have any solutions on how to injection to work with ath9k and ubuntu 10.10 patch or any other solution? Thanks
[09:43] <diwic> so given the new SRU cadence, what's the next deadline and when will that version reach maverick-updates?
[09:45] <smb> diwic, Unfortunately I don't think this can be said right now. As they have to draft out the details of the process on the go.
[09:45] <diwic> ok
[09:46] <smb> diwic, I would hope for at least end of next week. But I am not much wiser than you at the moment
[09:50] <diwic> smb, ok, then I'll have at least this week to produce patches :-)
[09:53] <smb> diwic, :) Heh, you can produce them anytime. But I can see the pain involved in getting them actually in. Which the new process tries to improve as soon as we know what the new process is.
[12:28] <apw> doko_, the libc fixes should be in the archive .... have at em
[12:28] <doko_> apw: thanks
[13:42] <tgardner> sconklin, your bug bot set the Lucid portion of bug 628776 to stable-reverted-lucid, but the Maverick patch is already fixed released. This seems like it needs a little oversight.
[13:42] <ubot2> Launchpad bug 628776 in linux (Ubuntu Maverick) (and 2 other projects) "HP NC511i Driver (be2net and be2scsi) is missing in kernel module udebs (affects: 2) (heat: 18)" [Low,Fix released] https://launchpad.net/bugs/628776
[14:38] <NoobFukaire1> anyone know of a PPA or something with an ubuntu kernel and the new wonder UI patch applied?
[15:06] <sconklin> tgardner: that was no bot, that was manual, and intentional. There's no verification for lucid, and a comment saying that there is a new pull request in progress with no further updates.
[15:08] <tgardner> sconklin, isn't that because no one has actually reviewed the pull request?
[15:09] <sconklin> tgardner: possibly, but no pull requests can be processed until the current cycle is complete, since we were sitting in the verification stage
[15:10] <tgardner> sconklin, hmm, this seems like a bug in the process. how are we going to handle patches in progress ?
[15:12] <sconklin> tgardner: it probably is a bug in the process, which assumed that patches are atomic and complete, and that once they are released in a -proposed kernel, the only options are to verify and release them, or revert them
[15:13] <sconklin> There's really no staging or working area other than what's applied for the next -proposed
[15:14] <sconklin> and there's an assumption that all the decisions for revert/verify can be made using information in the bugs, without any external knowledge from mailing lists, etc
[15:15] <tgardner> sconklin, perhaps bugs that are 'In Progress' should be ignored until they've gone 'Fix Committed'
[15:16] <sconklin> that bug was "fix committed" for lucid.
[15:16] <tgardner> sconklin, I guess I should have changed it back to 'In Progress'
[15:18] <sconklin> But - in a case where the fix actually has been committed, it's unclear what the right action is.
[15:19] <sconklin> shouldn't a change from fix-committed to in-process be accompanied by a revert? Since we don't really have an in-progress any more. Unless we add a staging branch to the repo.
[15:19] <tgardner> sconklin, I guess we'll just have to use our judgement based on the complexity of the patch and the chance for regression
[15:21] <sconklin> I do think that having a -next beanch may be helpful, although it would be rebased often. It would give developers a chance to test their patch on top of everything that's currently queued, and give us a little early testing, plus give visibility, and we could handle it like upstream merge windows. Although - we're having trouble just keeping up as it is. That will improve as our tools develop around the new process.
[15:23] <tgardner> sconklin, I am definitely in favor of a master-next branch. Its quite tedious (and not always conclusive) to grovel patchworks and the mailing list to find out the state of a patch.
[15:24] <tgardner> incoming patches should get applied to master-next sooner rather then later
[15:24] <tgardner> though I'm not sure it really solves the problem
[15:24] <sconklin> tgardner: we (the entire team and community) need to start talking about this larger problem. The whole mailinglist/patchwork/launchpad set of tools are not working and can't scale
[15:25] <sconklin> but that's the swamp, and I'm ass-deep in alligators
[15:28] <tgardner> sconklin, given that we're in verification week, do you know yet that you'll be able to get test results from cert ?
[15:30] <sconklin> tgardner: no, but Brad and I haven't yet uploaded the new -proposed, and that's a predecessor. Should do that today, earlyish.
[15:30] <sconklin> Right now I have to prepare a report for the meeting
[16:27] <sense> Is the Kernel Team aware of bug #653274? It is quite a visible regression in Maverik and Natty for Nvidia users and it has been around since the betas.
[16:27] <ubot2> Launchpad bug 653274 in linux (Ubuntu) (and 1 other project) "Plymouth doesn't show Kubuntu or Ubuntu logo with Nvidia proprietary driver (affects: 26) (heat: 154)" [Undecided,Confirmed] https://launchpad.net/bugs/653274
[16:33]  * JFo looks
[16:35] <bjf> apw, meeting status? (i didn't think you were planning on attending)
[16:36] <bjf> ##
[16:36] <bjf> ## Ubuntu Kernel Team Meeting - in 30 minutes - #ubuntu-meeting
[16:36] <bjf> ##
[16:42] <smoser> smb, if you're awake/around, we're having our Server Team meeting now
[16:42] <smoser> jj is gone, but normally he attends
[16:42] <smoser> (#ubuntu-meeting)
[16:42] <smb> smoser, I was there already
[16:42] <smoser> you dont miss a thing
[16:42] <sense> JFo: Thanks for taking a look.
[16:42] <smoser> thanks smoser 
[16:42] <smoser> smb
[16:43] <JFo> sense, my pleasure
[16:43] <JFo> still looking... got sidetracked
[16:59] <bjf> https://kernel-tools.canonical.com/srus.html
[16:59] <bjf> https://kernel-tools.canonical.com/queues.html
[17:00] <smb> "internal server error..."
[17:00] <bjf> smb, the links are working for both sconklin and myself
[17:01] <smb> second one does
[17:01] <smb> probably first one is an openid problem
[17:01] <bjf> smb, i'll go look at the logs
[17:01] <smb> bjf, It works now
[17:01] <sconklin> fails for me too, was working a bit ago
[17:03] <smb> bjf, Looks like my kernel packages needing love, just nicer. :)
[17:03] <kamal> kernel team meeting?
[17:03] <smb> server team just finished
[17:10] <ogasawara> JFo: just fyi, you can probably drop some of those kernels in your bug summary for future meetings.  for ex, linux-fsl-imx51 doesn't exist for Natty.
[17:10] <JFo> yeah, was wondering about that
[17:10] <JFo> thanks ogasawara 
[17:10] <JFo> :)
[17:11] <JFo> any other than that one?
[17:11] <ogasawara> JFo: mvl-dove too I think, and ec2?
[17:11] <JFo> ok, I'll remove them
[17:12] <JFo> easy to add them back if needed :)
[17:16] <smb> ogasawara, JFo I don't think any ec2 was dropper
[17:16] <smb> dropped
[17:16] <JFo> ok, so keep that one smb?
[17:16] <smb> JFo, Yes, please. Until I change my mind. :)
[17:17] <JFo> smb, will do :-)
[17:17] <ogasawara> smb: it may not have been officially dropped, but I don't see it existing at the moment - https://launchpad.net/ubuntu/+source/linux-ec2
[17:17] <smb> ogasawara, Oh gee, are we talking about natty?
[17:18] <smb> Sorry got confused
[17:18] <JFo> ah
[17:18] <smb> JFo, So for natty ec2 did never exist and I just changed my mind
[17:18] <JFo> heh
[17:18] <JFo> ok :-P
[17:20] <jjohansen> smb: so I lost internet at about 8:30 anything interesting happen
[17:20] <smb> jjohansen, I thought so. Not too much, I can send you a transcript privately
[17:20] <jjohansen> smb: thanks
[17:28] <c10ud> hello, just read about the "uber" responsiveness patch..i was wondering if it can work with .32 and/or anyone already thought about backporting (yes, i'm still using lucid)
[17:28] <JFo> c10ud, responsiveness patch?
[17:28] <JFo> do you have a link?
[17:29] <c10ud> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
[17:29] <JFo> ah, this one.
[17:29] <JFo> it must make it into the upstream kernel before we can get it
[17:29] <JFo> so nothing on backporting yet
[17:29] <JFo> I'm afraid
[17:30] <c10ud> np, i didn't know how your team works, that's why i was asking :)
[17:30] <JFo> :)
[17:30] <jjohansen> c10ud: so in general the principle is sound and it would work, I have know idea what it would take to backport, as it will depend on other scheduler changes
[17:31] <JFo> c10ud, our preference is to pull from the stable queue if possible
[17:31] <jjohansen> it is not something see being backported to the stable series, so my guess is no
[17:31] <smb> jjohansen, Not even in linux-next yet
[17:31] <c10ud> i see
[17:32] <jjohansen> nope, but it will be with the high praise it is getting
[17:32] <JFo> c10ud, but we are watching it :-)
[17:32] <smb> But generally as for upstream stable it needs to land in Linus tree first
[17:33] <c10ud> linus seems very positive about it, it's just i am too lazy to put some unstable stuff in my box..but lately i've been suffering of those responsiveness issue a bit so.. :)
[17:35] <jjohansen> c10ud: the problem is it is not just the 1 patch, my bet is it relies on other foundational work
[17:35] <c10ud> heh that was my biggest doubt...32 seems so old compared to this new shiny stuff, poor lucid
[17:35] <jjohansen> if it were just the 1 200+ line patch, I think it would make it to stable as several distros are using 2.6.32
[17:36] <tgardner> jjohansen, I have a 2.6.32 backport from spanasik@gmail.com
[17:36] <smb> jjohansen, Depending on how well Linus can sell that "new feature" as a bug fix to Greg. But I guess he can be pretty convincing.
[17:36] <jjohansen> tgardner: oh really?  Interesting
[17:36] <tgardner> it looks substantially the same as 2.6.37-rc2 version
[17:37]  * smb begins to wonder whether we all talk about the same patch
[17:37] <jjohansen> well my bet is suse will push greg to include it then, as it will probably be picked up for the sles kernel
[17:38] <tgardner> jjohansen, I'm sure we'll have a serious look as soon as its upstream
[17:38] <jjohansen> my assumption, without actually looking at the patch, is that it depended on some of the other scheduling work
[17:38] <jjohansen> definitely
[17:38] <jjohansen> as it would go a long ways to addressing certain bugs :)
[17:53] <tgardner> sconklin, bjf: I pushed a script update to Lucid/lts-backport-maverick. Be sure to update before turning that crank.
[17:56] <ogasawara> JFo: your sysrq handling email you sent to the k-t ml, was that in reference to bug 642792
[17:56] <ubot2> Launchpad bug 642792 in metacity (Ubuntu Maverick) (and 6 other projects) "ALT+PrtSc not recognised: breaks built-in screenshot function (affects: 85) (dups: 6) (heat: 478)" [High,Triaged] https://launchpad.net/bugs/642792
[17:56]  * JFo looks
[17:56] <JFo> indeed it is
[18:02] <sconklin> http://www.tomsguide.com/us/microSD-ATT-Windows-Phone-7-Focus-WP7-certified,news-8819.html
[18:03] <JFo> nice
[18:03] <sconklin> brings new meaning to plug and pray
[18:11] <JFo> yep
[18:15] <tgardner> ogasawara, do you have to run apport as root? re: kees wish to make dmesg protected.
[18:15] <ogasawara> tgardner: not that I know of
[18:16] <bjf> tgardner, because we collect acpi tables, we now require root for apport
[18:16] <tgardner> bjf, do we also get DMI info as root?
[18:16] <bjf> tgardner, this was a fairly recent change
[18:16] <bjf> tgardner, we only had to go to root priv. for the acpi tables, not for dmi
[18:20] <mjg59> kees: For the information you're talking about in dmesg, how much could an attacker determine by booting the same kernel version on a machine with a similar quantity of RAM and comparing /proc/iomem on the target machine?
[18:26] <kees> mjg59: I'm meaning various debugging details leaking out of the network stack
[18:27] <kees> mjg59: for full hilarity, see Dan Rosenberg's threads on net-dev
[18:30] <JFo> cking, you roc?
[18:30] <JFo> grrr
[18:30] <JFo> deleted half the sentence
[18:30] <cking> JFo, eh?
[18:31] <JFo> was meant to be: cking you rock... have I told you that lately?
[18:31] <JFo> :)
[18:31] <cking> oh, thanks. ;-)
[18:31] <JFo> the WMI brain dump
[18:31] <cking> oh. yeah. that was fun - not.
[18:31] <JFo> heh
[18:31] <JFo> but I appreciate it
[18:34] <cking> JFo, you need to thank mjg59 for all his helpful morsels of ACPI goodness he's been writing about that I find on google ;-)
[18:35] <mjg59> kees: Ah, got you
[18:36] <JFo> thanks mjg59 :)
[18:49] <tgardner> ogasawara, why didn't your v2.6.32.25 stable updates make into this most recent Lucid upload?
[18:49] <tgardner> you did the review (which is why I'm asking)
[18:50] <ogasawara> tgardner: I was told that it was going to instead be pulled from smb's 2.6.32.y+drm.33 tree
[18:51] <smb> ogasawara, tgardner It contained all the drm patches from .32 and then I think it was just late before trying to get the new process into place
[18:52] <ogasawara> tgardner: I've got a few other patches I want shoved into Lucid as well, but am waiting for the green light for the SRU merge window to open
[18:53] <tgardner> I'm beginning to think we need a -next branch 'cause I think stuff is getting lost.
[18:54] <smb> tgardner, Either a -next or being confident that master can go ahead while proposed is processed
[18:56] <ogasawara> I'd vote for a -next branch which gets rebased.  that way sconklin can still easily revert patches from master and then merge in -next when he's ready.
[18:58] <sconklin> ogasawara: +1, we're really not able to keep up with everything as it is and I hope it will help. I get anxious every time I think about you taking time off. 
[18:59] <smb> I tend to vote for doing the processing on a side branch and then merge that. But just because it seemed to work reasonable well for security and proposed re-uploads. MAybe the result of the merge looks even similar both ways
[19:00] <ogra_ac> bjf, bug 663642 was verification-done since quite some time already
[19:00] <ubot2> Launchpad bug 663642 in linux-linaro (Ubuntu Maverick) (and 3 other projects) "DVI doesn't work at BeagleBoard xM rev A3 (affects: 1) (heat: 18)" [Undecided,Fix released] https://launchpad.net/bugs/663642
[19:00] <ogra_ac> bjf, does your comment mean you removed the fixed package from proposed again ?
[19:00] <rsalveti> and the bug was changed to verification-done on time
[19:00] <ogra_ac> right
[19:00] <rsalveti> that was nov 08
[19:01] <smb> sconklin, Yeah I guess regardless what we end up with, the working branch would be good to be an officially pushed one
[19:01] <smb> or the next branch
[19:01] <smb> whatever suits better
[19:01] <bjf> rsalveti, ogasawara look at the action on 2010-11-13 which added "verification-needed" and removed "verification-done"
[19:01] <bjf> ogasawara, sorry not you, ogra_ac
[19:02] <bjf> ogra_ac, ^
[19:02] <rsalveti> bjf: I did that, because I thought the linaro one was tested
[19:02] <rsalveti> and not ours
[19:02] <rsalveti> my mistake 
[19:02] <rsalveti> but the deadline was nov 11
[19:02] <bjf> rsalveti, it looked like the testing was not done for maverick by the deadline which was yesterday
[19:03] <rsalveti> the bug said the deadline was nov 11
[19:03] <GrueMaster> I had changed the tag on 11-08 when I filed the comment.  Unfortunately it doesn't appear to have changed in LP at that time.
[19:03] <bjf> rsalveti, at this point it doesn't matter what the date was as the revert happened yesterday
[19:04] <rsalveti> urgh, so how to get it back?
[19:04] <GrueMaster> Would be nice for someone to ask us in the future before the patches get reverted.  I don't suggest relying on LP alone.
[19:04] <GrueMaster> (I can't even find half the bugs I need to track without google).
[19:05] <bjf> GrueMaster, we have to rely on LP
[19:05] <ogra_ac> in any case (before that turns into a LP discussion) can we have the fix back asap ?
[19:06] <GrueMaster> I fail to rely solely on it, as I don't even get half the emails for bugs I filed.
[19:06] <bjf> GrueMaster, rsalveti, ogra_ac, going forward there will be a "verification-needed-<rls>" tag which will help a little
[19:06] <GrueMaster> ok
[19:06] <rsalveti> GrueMaster: and how should we proceed when we have the bug on both kernel?
[19:06] <rsalveti> linaro and ubuntu
[19:07] <rsalveti> we need the verification-done for both, that was the main confusion for me
[19:07] <rsalveti> bjf: how can we get the patch back to the repo again?
[19:07] <GrueMaster> Understood.  But as a general rule, I try not to change tags without a supporting comment.
[19:08] <rsalveti> GrueMaster: martin pitt changed the tag
[19:08] <GrueMaster> Yes, I know.  And his comments supporting that change are...where?
[19:09] <GrueMaster> As I said, I had changed it when I added my comment.  But LP didn't take the change for some reason.
[19:10]  * tgardner lunches
[19:11] <bjf> rsalveti, am discussing with sconklin
[19:11] <bjf> GrueMaster, ogra_ac, ^
[19:11] <GrueMaster> But LP asside, we either need to get the patch re-reverted and back to where it was on 11-08, or we need to reapply it and re-recruit community members to retest (which imo makes us look incompetent).
[19:18] <bjf> GrueMaster, ogra_ac, rsalveti, am reapplying and will re-upload
[19:18] <ogra_ac> thanks 
[19:18] <rsalveti> bjf: thanks so much, and sorry about the confusion again
[19:18] <GrueMaster> Requiring retesting?
[19:18] <bjf> GrueMaster, would be a good idea
[19:19] <GrueMaster> sigh.  
[19:19]  * GrueMaster puts recruiter's hat back on.
[19:19] <bjf> GrueMaster, but there is no plan for a second revert pass if it isn't tested
[19:21] <GrueMaster> Unless it gets preempted by another security release.
[19:21] <GrueMaster> I've been down this path before with Dove and babbage.
[19:21] <jjohansen> pgraner: you around
[19:22] <sconklin> ogra_ac, GrueMaster: there is no other way for us to scale stable kernel maintenance other then relying on bugs to track the verification state. People will have to be responsible for tracking the things they care about.
[19:23] <GrueMaster> sconklin: The main issue here is that none of us have the newest board that requires this patch, so we need to rely on members of #beagle to test it for us.
[19:24] <GrueMaster> All I ask is that in the future, especially when there are different kernel packages in the same bug, that each tag change is followed by a comment.
[19:25] <GrueMaster> It would greatly help avoid future confusion.
[19:27] <ogra_ac> sconklin, the issue with that bug was that we have a duplicated package in the archive which caused confusion, there is the omap3 kernel as well as the linaro omap3 kernel verification for the one didnt happen for the other that caused the havoc we're in now
[19:29] <jjohansen> https://wiki.canonical.com/UbuntuPlatform/Sprints/TestAutomationSprint
[19:37] <smb> sconklin, bjf JFo ^ Sounds like it could be interesting to you (one at least)
[19:38] <JFo> hmmm
[19:39] <JFo> I'd be interested as long as the team thought that were a useful use of my time.
[19:40] <JFo> looks to be geared toward guidance of the framework as it stands and has been planned
[19:40] <bjf> i'm interested but haven't got the time
[19:42] <bjf> the other issue i have with it is it will be "yet another framework" which will take an entire dev cycle to get in place (at the least)
[19:44] <JFo> yeah
[19:45] <smb> bjf, It just seemed to be much about testing the proposed sru kernels that I thought there might be someone useful that knows the subject of the test and keeps people at bay of inventing the golden egg when we just need some simple ones
[19:45] <jjohansen> bjf: what I think would be useful is to hit manjo with a few points/notes as he is going
[19:46] <smb> yeah
[20:05] <manjo> smb, can I join you guys in mumble ?
[20:06] <smb> manjo, There is nothing interesting going on in hell. Just heat. 
[20:13] <sconklin> manjo: https://wiki.ubuntu.com/Kernel/StableReleaseCadence
[20:15]  * jjohansen -> lunch
[20:58]  * ogasawara lunch
[21:16] <achiang> was there some discussion here a few days ago about powernowd? is that package deprecated?
[21:26] <pgraner> jjohansen1, I am now
[21:32] <tgardner> jjohansen1, have you started on ecryptfs yet? It would be nice to get those patches in 2.6.38
[21:33] <jjohansen1> tgardner: no not yet, I'll start this week, I have been trying get the interface up that jamie will need for dbus
[21:33] <jjohansen1> pgraner: quick chat
[21:34] <jjohansen1> mumble or call I don't care
[21:55] <pgraner> jjohansen1, sure lemme get my headphones
[22:26] <bjf> ogra_ac, GrueMaster, rsalveti, new source package containing your patch has been uploaded
[22:40] <sconklin> skaet: lucid and maverick kernels are uploaded and awaiting acceptance, I'm outta here - catch you tomorrow.
[22:40] <skaet> sconklin,  sounds good.
[22:41] <skaet> sconklin,  re the sprint - yes, some of the concerns we talked about will be addressed.  Catch me on mumble tomorrow and I"ll give you more details. 
[22:43] <sconklin> skaet: great, thanks!
[22:43] <sconklin> and thanks for setting up the recurring meeting
[22:43] <skaet> heh, no worries.