[01:04] <jk-> m4t: shouldn't do
[01:14] <sangeeth> I heard the right step to hack the linux kernel is to begin with Linux 0.01 kernel... I could get a hand on the source code, but couldn't get any guide... PLEASE HELP ME...
=== bjf[afk] is now known as bjf
=== bjf is now known as bjf[afk]
[02:02] <rlpb> Can anyone help with debugging acpi? I'm running acpiexec but not getting the same battery status as reported in /proc/acpi/battery/... . How does acpiexec emulate actual hardware?
=== ayan_ is now known as ayan
[04:45] <kusanagi> hi, i am running lucid. How can i install latest kernel? or at least 2.16.36?
[04:54] <RAOF> The lucid-maverick-backport kernel is in the archives now I think.  Either that, or it's in the kernel team PPA.
[04:58] <kusanagi> RAOF, I have backports activated in lucid, but nothing proposed. Do i have to add the ppa to get it proposed?
[05:03] <RAOF> Hm, maybe.
[05:03] <RAOF> I can't see it in the lucid archives.
[05:03] <kusanagi> mm ok i have added the ppa
[05:03] <kusanagi> how do i install the kernel now?
[05:04] <kusanagi> it is not proposed if i do an update && upgrade
[05:05] <RAOF> It looks like you'd want to install the linux-meta-lts-backport-natty package
[05:05] <kusanagi> cant find that package :S
[05:06] <kusanagi> whats the difference between meta and not meta?
[05:06] <RAOF> Dunno, sorry.
[05:07] <kusanagi> ok, it found it without meta
[05:07] <kusanagi> thanks RAOF i think i can take it from here on ;D
[05:08] <kusanagi> mmm it seems there is only headers and source packages :S
[05:08] <kusanagi> :(
[10:50] <apw> man its quiet today ...
[10:50] <smb> Now you broke it. :)
[10:52]  * apw prepares the flood gates ...
[10:53] <apw> smb, did you sort out that bundle?  it seems you can treat filename as a remote, git ls-remote and git fetch <file> <branch>:<branch2> style things work on it
[10:54] <smb> apw, No, could not really be bothered
[10:56] <apw> anyone remember who it was who was doing cross-compilation and finding x86 binaries in the header files ?
[10:57] <apw> and indeed remember the bug number?
[11:17]  * apw finds a multi-iso stick in his kit ... damn these are good
[11:47] <lool> Someone knows kettgordon at gmail.com?
[11:47] <lool> alternatively, is there an admin for the Ubuntu kernel-team mailing-list around?  :-)
[11:48] <lool> everyone posting to kernel-team@ gets a message to confirm emails going to this subscriber
[11:48] <apw> lool, what do you need ?
[11:48] <apw> oh thats a lot crap
[11:48] <lool> apw: I think we should unsubscribe this guy and write him to not subscribe to mailing-list with this address
[11:49] <apw> heh welll if i write to him and it asks me to confirm, i won't bother, so they won't find out
[11:49] <lool> (He's probably subscribed with an @boxbe.com address, but the autoreplier mentions the kettgordon at gmail.com as a contract address)
[11:49] <lool> apw: Fair enough  :-)  I suppose the kettgordon gmail.com one isn't filtered though
[11:54] <apw> lool can you fwd me the autoreply ??  i don't seem to get them
[11:54] <lool> apw: done
[11:54] <lool> apw: Maybe he whitelisted @ubuntu.com, @canonical.com, but not @linaro.org (or anyone possibly posting to the list)
[12:03] <apw> lool, maybe so... seems he needs a poke for sure
[12:09] <apw> lool, ok i have sent a whining email to him on your behalf
[12:10] <lool> apw: Thanks;
[12:10] <lool> I could have done the latter part myself I realize, I went straight to listmasters because I don't want other subscribers to be annoyed :)
[12:24] <apw> yep, well you also wouldn't know whether we were all being spammed which we don't, and it sounds more appropriate coming from a list person, so it seems right
[13:22] <kraut> moin
[14:39] <doko> apw, tgardner: any idea about  bug #673073 ?
[14:39] <ubot2> Launchpad bug 673073 in linux (Ubuntu) (and 1 other project) "<net/if.h> and <linux/if.h> are incompatible (affects: 3) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/673073
[14:40] <tgardner> doko, looks like an upstream issue. we'll work on it.
[14:40] <doko> thanks!
[14:46] <apw> tgardner, i wonder if its a simple case of _kernel_ round that include
[14:47] <tgardner> apw, doko, I think this was introduced by eglibc. include/linux/if.h has not changed significantly for over a year
[14:48] <apw> tgardner, i think the file that has changed is rtnetlink.h
[14:48] <apw> which is triggering an include of if.h indirectly now
[14:48] <apw> commit 24824a09e35402b8d58dcc5be803a5ad3937bdba
[14:48] <apw> Author: Eric Dumazet <eric.dumazet@gmail.com>
[14:48] <apw> Date:   Sat Oct 2 06:11:55 2010 +0000
[14:48] <apw>     net: dynamic ingress_queue allocation
[14:48] <tgardner> apw, ah, hadn't drilled down to that yet
[14:49] <apw> that one brought a new include of netdevice.h to that header
[14:51] <doko> tgardner: are you sure? eglibc isn't yet updated ...
[14:51] <tgardner> doko, no, I'm not sure. apw pointed out changes in rtnetlink which are the likely culprit
[14:53] <apw> doko, do you have some code which triggers this error on compilation, somethign short?
[14:54] <tgardner> apw, the bug report does. we could just hack the local chroot copy of rtnrtlink to see if its a workaround
[14:54] <apw> tgardner, yeah going to try tha
[14:54] <doko> apw: in the bug report, bug description
[14:57] <apw> tgardner, ok it seems that putting that include in an __KERNEL__ at least lets the example compile
[14:57] <apw> not sure if that would be enough for elibc ....
[14:57] <apw> doko, if i spin a test kernel with that change can you test it against your eglibc build ?
[14:58] <tgardner> apw, you should probably send a note to Duzamet and Miller.
[14:58] <doko> apw: sure
[14:58] <apw> tgardner, for sure
=== cking is now known as cking-afk
[15:23] <lag> diwic: Where is your 'self help' Wiki page?
[15:27] <diwic> lag, what do you need help with?
[15:27] <lag> My 'friend' has audio issues
[15:28] <lag> Didn't you have some scripts that was used for debugging?
[15:28] <diwic> lag, https://wiki.ubuntu.com/DebuggingSoundProblems ?
[15:29] <diwic> although I don't really recommend everything there, some of it is outdated
[15:29] <lag> What was the script I ran, which churned out lots of debug?
[15:30] <diwic> https://wiki.ubuntu.com/Audio/AlsaInfo
[15:30] <lag> I think that's it
[15:30] <lag> Is that still in date?
[15:30] <diwic> yes
[15:30] <lag> Great, thanks
=== bjf[afk] is now known as bjf
[15:50] <apw> doko, could you see if the versions of linux-libc-dev fix your issue: http://people.canonical.com/~apw/rtnetlink-netdevice-include-natty/
[15:50] <apw> (i think they should)
[15:52] <beaver74> hey
[15:53] <beaver74> i have only a small question, is it possible running the AMD SB850 SATA controller in AHCI mode with 2.6.35 kernel?
[15:54] <doko> apw: will do, my remote machine is currently not reachable ... will update the bug report
[16:07] <apw> doko, i take it this is a blocker on you
=== cking-afk is now known as cking
[16:17] <apw> tgardner, i've copied you on the patch i've send upstream for this one
[16:20] <tgardner> apw, ack
[16:21] <tgardner> apw, we should just commit that for natty for now regardless of whether upstream takes it.
[16:26] <bjf> tgardner, apw, http://ireport.cnn.com/docs/DOC-518781?hpt=C2   
[16:27] <tgardner> too weird...
[16:30] <kamal> bjf, sconklin: guess that ^^ is the same as we saw the kids playing in Cambridge then?  still seems to me that the broomsticks are superfluous here.  ;-)
[16:30] <bjf> kamal, ack, tgardner and apw and I saw another group "flying" around boston common on Sat.
[16:31] <kamal> guess they were gearing up for the 'big match' ;-)
=== yofel_ is now known as yofel
[16:40] <doko> apw: yes, the patch works
[16:46] <smb> apw, ogasawara Could you have a quick look at https://wiki.ubuntu.com/Kernel/Dev/KernelDriverDeviations to see whether my "reason"s sounds reasonable to you as well?
[16:47] <ogasawara> smb: sure
[16:49] <ogasawara> smb: looks fine to me
[16:50] <smb> ogasawara, ok, cheers. then we can tick that off the list
=== cking is now known as cking-afk
[17:24] <ogasawara> sconklin: just fyi re: bug 672964.  determined to not be a kernel issue and is getting resolved via udev.
[17:24] <ubot2> Launchpad bug 672964 in udev (Ubuntu Maverick) (and 2 other projects) "2.6.32-26 unbootable: does not find root file system (affects: 1) (heat: 732)" [High,Fix committed] https://launchpad.net/bugs/672964
[17:25] <sconklin> ogasawara: sweet, a nice first bit of news for the day
[17:25] <smb> sconklin, Then I could add that I still got network when updating on an acer aspire one, so the other report is probably something special as well
[17:26] <sconklin> smb: great! Should I log off now before the law of averages catches up?
[17:27] <bjf> sconklin, where are we "in the process" right now?
[17:27] <smb> sconklin, There is always something broken somewhere. Trying to escape is futile :)
[17:28] <sconklin> bjf: Today is the day we revert all unverified fixes. We'll need to actually look at each bug first, of course. I don't think we have a good tool yet to remove the buglinks from reverted patches, so we'll probably have to manually edit the changelogs after insertchanges. Sound right to you?
[17:29] <smb> sconklin, Doh! And the OS installed Maverick now. So much for reproducing...
[17:29] <smb> Eh no, it was another guy on the bug 
[17:30] <bjf> sconklin, yes, sounds right, have you started
[17:30] <sconklin> bjf: no, I just sat down. Haven't even looked at the status yet
[17:30] <ogasawara> sconklin: let us know if you want help.  I'm also fixing up some build failures for the CVE's at the moment and will move on to some quick smoke testing and regression tests after that.  will send you, bjf, and smb an email with results.
[17:32] <sconklin> ogasawara: thanks. I think it makes sense for bjf and I to each take a release - Maverick and Lucid are the ones to be done. What you're doing is great. I'll write some boilerplate for the bugs first, so we have consistent text.
[17:33] <mildoe> hi
[17:33] <sconklin> The number of verified fixes in lucid is disappointing
[17:33] <mildoe> what is the major difference between RHEL and the ubuntu kernel?
[17:33] <mildoe> similar?
[17:35] <ogasawara> mildoe: depends which version of RHEL and Ubuntu you're referring to.  and even then, I'm not sure who on this channel follows the RHEL kernel closely enough to give you a good comparison.
[17:36] <mildoe> rather arent most distro kernels the same?
[17:36] <mildoe> just minor differences here and there for services and such
[17:36] <jjohansen1> mildoe: yes and no, they all derive from upstream, but will include some different sauce patches and configuration differences
[17:37] <bjf> sconklin, i'm reviewing the "verification-needed" bugs for maverick
[17:37] <apw> mildoe, RHEL is aimed at very long term stability, and therefore is most comparible with Lucid (our LTS release), otherwise our normal releases are more like Fedora releases, aimed at the latest versions of everything
[17:37] <sconklin> bjf: then I'll take lucid
[17:38] <mildoe> ah
[17:38] <mildoe> so rhel and ubuntu is almost similar in most cases?
[17:38] <mildoe> ok thats what i thought
[17:41] <apw> mildoe, in a very simplistic sense yes
[17:49] <sconklin> ogasawara, bjf: Hmm, we haven't exactly defined the steps to take to have a fix reconsidered. How about this text in the wiki:
[17:49] <sconklin> When fixes are reverted due to lack of verification, they may be proposed for reconsideration by performing the following:
[17:49] <sconklin>  * update the bug with a firm commitment to verify the fix during the next stable kernel release cycle (usually this will begin one week after the fix is reverted).
[17:49] <sconklin>  * Send a request to the Ubuntu Kernel mailing list request reconsideration of the fix. Include the bug number, and if possible, reply to the original SRU request that was made for the fix.
[17:49] <bjf> i thought we were going to just reapply then for the next cycle?
[17:49] <sconklin> bjf: not without some commitment to test
[17:49] <bjf> we talked about many options and i'm not exactly sure what we are doing at this point
[17:50] <sconklin> that was my memory
[17:50] <sconklin> Originally we were going to close wontfix, and require a whole new SRU request, but we changed to just incomplete, and now it's unclear 
[17:52] <sconklin> We can change what doesn't work - but for this cycle, there are bugs that have not gotten any response from multiple requests to test, so I have no faith that we won't be in the same position next week as we are now if we simply reapply them
[17:52] <ogasawara> sconklin: do we really need them/us to send an email to the Ubuntu kernel team mailing list?  I suspect most users are not subscribed and it'll just add noise to the list.
[17:53] <tgardner> sconklin, regardless if they send an email they at least need to update the LP bug with some commitments
[17:53] <ogasawara> sconklin: I'd just be fine with the first bullet point and then maybe tagging the bug with kernel-patch-reapply or something
[17:53] <sconklin> ogasawara: maybe your work flow is different, but if they simply reply to the bug, it'll get lost in noise for me. It won't be in the pending SRU tracking any more, and we have to way to track this class of bugs now
[17:54] <ogasawara> sconklin: indeed, hence the need for the tag
[17:54] <sconklin> ogasawara: yeah, how about this:
[17:54] <bjf> ogasawara, tgardner i'm with sconklin (as far as I can tell) how do we know which bugs to add without email to the list?
[17:54] <sconklin> when we revert we tag with stable-reverted, and when the commitment to test is added, they tag with stable-reapply
[17:55] <ogasawara> sconklin: I like that
[17:55] <apw> asking them to remove tags has generally been our way
[17:55] <apw> as they are less likley to spell the tag wrong that way
[17:55] <sconklin> it would be up to the edn user to add tags. Can anyone edit tags, or does it require special privs?
[17:55] <sconklin> end user
[17:55] <ogasawara> sconklin: unfortunately anyone can add/remove tags
[17:55] <sconklin> I've assumed all along that anyone could do it
[17:55] <bjf> sconklin, it's your call but I think doing it via tags is going to be a mess
[17:56] <apw> is not the current process tag driven though, with needs-verification etc ?
[17:56] <sconklin> bjf: what's your alternative? email to the list?
[17:56] <ogasawara> bjf: I think having to track multiple emails would be just as messy
[17:56] <bjf> sconklin, yes, email to the list just like any other patch request
[17:57] <bjf> ogasawara, so we have to continuously scan bugs for the right "stable-reapply" tag? yes it can be done but it's yet another process.
[17:58] <sconklin> tgardner, apw, smb, (and everyone) ^^ thoughts? Tags are a bit messy but list email subjects the entire kernel team to a bit of stable process that not everyone is interested in
[17:58] <tgardner> sconklin, I think we should use LP as the basis for our process, and that means tagging.
[17:58] <tgardner> email is abit ad-hoc
[17:59] <bjf> tgardner, trying to not be a complete ass here, but why do we ask for the inital email to the mailing list when we could just accept a "please-pull" tag on LP bugs instead?
[18:00] <sconklin> I think that the barrier for reapplication should be pretty low - i.e. someone says they'll test. So since we have two acks for the patch already, we don't need the number of eyes that we get from email
[18:00] <tgardner> I guess because the list is lower volume then LP ?
[18:00] <sconklin> bjf: for the acks
[18:00] <bjf> sconklin, you can do the acks in the lp bug as well
[18:01] <sconklin> but acks come from the entire kernel team, and reapplying is a part of a process that only the few team members dealing with stable process care about
[18:02] <smb> i guess the email process seemed to be more open to people not looking at specific bug reports and quicker to work with in general (for the acks)
[18:03] <smb> Just from gut feeling it seems better to work the process itself with lp and tags. Just as it seems simpler to query and process that programatically
[18:05] <sconklin> smb: I think I agree, although we're continuing to really abuse launchpad as a process tool it was never intended to be. But it's the only tool we have.
[18:06] <sconklin> So I think the vote is for tags. If it was a tie, I'm happy with being the tiebreaker for tags
[18:06] <sconklin> next question - 
[18:06] <sconklin> When we reapply, do we revert the revert?
[18:06] <sconklin> or reapply
[18:06] <tgardner> sconklin, nah, just apply
[18:07] <ogasawara> +1
[18:07] <tgardner> it might be a different patch by then anyways
[18:07] <sconklin> tgardner: doing that has the advantage of getting the correct entry in the changelog, which is important
[18:07] <sconklin> ok, decided.
[18:08] <tgardner> sconklin, apw was working on a tool to futz the changelogs when a patch is reverted
[18:08]  * manjo getting lunch will be back soon 
[18:08] <sconklin> tgardner: yes, I'm aware of that - for today we'll manually deal with it
[18:12] <sconklin> bjf, ogasawara: should we make the tags release-specific i.e. "stable-reverted-lucid", as some of these bugs are against multiple releases?
[18:13] <bjf> sconklin, i guess so
[18:13] <ogasawara> sconklin: makes sense
[18:15] <sconklin> check me on this https://wiki.ubuntu.com/Kernel/StableReleaseCadence
[18:23] <bjf> sconklin, so how much discretion are we giving ourselves in deciding the keep a non-verified patch versus reverting it?
[18:23] <ogasawara> sconklin: looks good.  I know you're going to do this, but I'd add a blurb to Details section that along with setting the bug to Incomplete for unverified patches, a comment will be posted to the bug for how they can request re-application of the patch pending their commitment to test.
[18:24] <bjf> sconklin, i have a one line quirk which fixes 7 LP bugs but didn't get verified
[18:24] <sconklin> ogasawara: good point, I'll do it now
[18:24] <sconklin> bjf: who's responsible for testing
[18:24] <sconklin> ?
[18:24] <bjf> sconklin, so you'd revert it
[18:24] <bjf> ?
[18:26] <mildoe> apw: ok
[18:26]  * apw doesn't think this is going to get sorted out in one pass, i think we need a solid proposal to test-execute and critique
[18:27] <bjf> sconklin, also, if a patch has 7 buglinks, do they all have to verify it fixed or is any single good enough?
[18:27] <sconklin> bjf: In general yes. If there was any sort of explanation from someone about why it wasn't testable and was safe or something, I might consider taking it, but it would be a hard call. Remember that the verification requirement is actually part of the archive admin process, and not something we can just be free about. In this case, try asking pitti what he thinks
[18:28] <sconklin> bjf: that's a very good question, and I'd take it. If it was a patch with many model numbers in the quirks, it gets harder, but still and especially for audio, if we assume that (for example) the mapping of codecs to model numbers is right, it should be OK
[18:28] <bjf> sconklin, this is essentially new process. i understand what you are saying that it is part of the archive admin process. however, since we've are just now starting to implement it, i consider it new
[18:28] <sconklin> bjf: agreed, and we are making it up as we go along . . .
[18:29] <sconklin> the details, anyway
[18:29] <ogasawara> if a patch fixed 7 bugs, I'd think they would all be marked as dups with one master bug?  And you then have 7x the possibility of it being verified.
[18:30] <bjf> ogasawara, so the one master must be verified as fixed
=== _LibertyZero is now known as LibertyZero
[18:31] <sconklin> bjf: in that case, yeah, which is another unenforced policy step
[18:31] <ogasawara> bjf: right, you'd just pick one of the 7 to be the master, dupe the other 6 to it, and lp tells the other 6 to add comments to the master bug rather than continue using the duped bug
[18:32] <bjf> ogasawara, yes, if the users have done what they are supposed to do and created a master bug
[18:33] <ogasawara> bjf: the user doesn't have to create a master bug, you as the triager/developer just choose which one you want to be the master
[18:33] <ogasawara> bjf: that's how duplicate bugs have always been handled
[18:34] <sconklin> and if they are all separate in the pending SRU for a -proposed release, you may have to individually set them all to verified
[18:34] <bjf> ogasawara, i understand what you are saying, but i am not necessarily the triager and not all triagers are going to do the right thing
[18:36] <apw> tgardner, did that fixy to the rtnetlink.h make sense to you?  i am thinking if we are happy i should upload it sooner rather than later
[18:36] <lool> apw: If you upload to fix linux-libc-dev, would you mind including https://patchwork.kernel.org/patch/320712/ ?
[18:36] <tgardner> apw, yep
[18:38] <apw> lool, that is the second patch of a pair from its commentary?  are both needed ?
[18:41] <bjf> sconklin, are we the beginning of the first week of a new cycle? if not then i assume next monday is the first week of a new cycle (it seems we are several weeks into this cycle when did it officially start?)
[18:43] <sconklin> Next week will not be the beginning of a new cycle unless a miracle happens. Once we revert, we're in a hold until testing happens, and the definition of "what's good enough" for that for the first pass will have to be made with input from QA, Cert, and the release manager.
[18:44] <sconklin> I think that most likely, we will end up running out through the next two weeks, and effectively skip a cycle
[18:44] <tgardner> sconklin, any test results from cert's dry-run ?
[18:44] <lool> apw: It's not; it's a fix for commits which are already in the Ubuntu tree
[18:45] <sconklin> tgardner: in a word, no
[18:45] <apw> sconklin, who are we interfaced with over in QA for this
[18:45] <sconklin> there were some results, but they were not all useful
[18:45] <sconklin> apw: Victor
[18:47] <vanhoof> sconklin: i'd vote heavily towards skipping a cycle ;)
[18:47]  * vanhoof prays each night for .37 in -proposed to release :D
[18:47] <sconklin> vanhoof: it's not really up for a vote, but fwiw I hear you
=== cking-afk is now known as cking
[19:07] <cking> oops, not been away for hours, my fail
[19:07] <bjf> sconklin, for maverick it looks like 3 reverts
[19:08] <bjf> sconklin, 8 lp bugs affected 
[19:08] <sconklin> bjf: for lucid, it's eight bugs, haven't counted how many reverts that maps to yet
[19:08] <sconklin> some of them (most?) are the same bugs as maverick
[19:08] <bjf> yes :-)
[19:17] <bjf> sconklin, i'm going to start reverting patches, updating trees and doing builds
[19:17] <sconklin> bjf: exactly where I am. I just fetched.
[19:18]  * tgardner lunches
[19:21] <bjf> sconklin, so we need to "startnewrelease", revert, "finish-release", then upload
[19:22] <bjf> sconklin, with building and boot testing mixed in there as well
[19:23] <sconklin> yeah, but is it insertchanges instead of "finish-release"? (along with manually editing changelog to remove buglinks on the reverted original patches
[19:24] <bjf> sconklin, there is no "finish-release", yes I meant "insertchanges" + any other final details before uploading
[19:24] <sconklin> bjf: whew
[20:37]  * jjohansen1 -> lunch
[20:41] <smoser> smb, can you poke bug 659084 ? or jjohansen1 so we can get it on future maverick kernel udpate.
[20:41] <ubot2> Launchpad bug 659084 in linux-meta (Ubuntu) "2.6.35-22-virtual is missing nfs modules (affects: 10) (dups: 1) (heat: 145)" [Medium,Confirmed] https://launchpad.net/bugs/659084
[21:12]  * tgardner breaks for a few hours
=== tgardner is now known as tgardner-afk
[21:27] <bjf> apw, someone going to report out status for you in tomorrows meeting?
[23:35] <sconklin> http://stacksmashing.net/2010/11/15/cracking-in-the-cloud-amazons-new-ec2-gpu-instances/
[23:36] <bjf> sconklin, well that's just special
[23:37] <sconklin> yeah, he was attacking deprecated SHA1s but still . . .
[23:38] <jjohansen1> yeah, the cloud can make massive compute power available to anyone
[23:40] <jjohansen1> and that can be scarry, sure he was just attacking sha1 but the same thing could be applied to stuff that isn't deprecated.  How many people really have good pass phrases on things