=== kees___ is now known as kees
[06:14] <sugnan> hello, am using Ubuntu 10.10 (Maverick), when i tried to compile the linux kernel of version 2.6.36 and 2.6.37( my default version is 2.6.35), i get the error mount mounting none on /dev failed: no such device, when i try to boot. can someone please help, am a newb and compiling kernel for the first time. is it because the ubuntu version am using doesnot support this version
[06:23] <sugnan> is it the right channel to ask question regarding ubuntu kernel  development ?
[06:25] <RAOF> Yes.
[06:25] <sugnan> RAOF, am using Ubuntu 10.10 (Maverick), when i tried to compile the linux kernel of version 2.6.36 and 2.6.37( my default version is 2.6.35), i get the error mount mounting none on /dev failed: no such device, when i try to boot. can someone please help, am a newb and compiling kernel for the first time. is it because the ubuntu version am using doesnot support this version
[06:26] <RAOF> First, the meta-question: why are you building a new kernel?
[06:27] <sugnan> actually i wanted to upgrade to the latest version, and i have added few user defined protocols in it
[06:29] <sugnan> RAOF, i have made my own device, in order interact with it i have designed my own protocol, so i have added that protocol in the linux kernel code, now i want to compile it, but i ended up with this problem
[06:33] <RAOF> I'm not familiar with that specific problem; it sounds like you perhaps haven't built in all the necessary options, such as devtmpfs?
[06:34] <sugnan> RAOF, ya i get some error relating devtmps too
[06:39] <sugnan> RAOF, can i just know how to compile the modified kernel for the current ubuntu am using, is it necessary that i need to compile the whole ubuntu? or is it necessary that i compile the same version of the kernel am having by default ?
[06:40] <RAOF> I'm not sure what the question is.  It's certainly not necessary to recompile anything other than the kernel, and it's entirely possible to use different kernels; the kernel team maintain a couple of different mainline builds, which work.
[06:41] <sugnan> RAOF, thanks
=== lamont` is now known as lamont
[08:42] <smb> morning
=== arun__ is now known as arun
[11:24] <smb> -> lunch
=== yofel_ is now known as yofel
[14:40] <komputes> Is there a tag for card reader bugs - Can someone please have a look into this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/670181
[14:40] <ubot2> Launchpad bug 670181 in linux (Ubuntu) "Dell Precision M6300 SD Card Reader (Ricoh R5C592 memory stick) Will Not Mount After Upgrade To 10.10 (affects: 1) (heat: 433)" [Undecided,New]
=== virtuald_ is now known as virtuald
=== achiang` is now known as achiang
[15:10] <manjo> komputes, can you try http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2010-11-04-maverick/ ? and post the results to the bug? 
[15:10] <manjo> komputes, sorry http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2010-11-09-maverick/
[15:12] <komputes> manjo: just the "image" and the "headers" for my arch? or the one that says "all" as well?
[15:13] <manjo> komputes, I think those headers are for i386
[15:13] <manjo> ie all
[15:14] <komputes> manjo: never mind
[15:15] <manjo> komputes, do you have the module  tifm_sd loaded?
[15:16] <m4t> i filed this under gcc, but maybe someone here can shed some light: https://bugs.launchpad.net/bugs/673236
[15:17] <ubot2> Launchpad bug 673236 in gcc-4.4 (Ubuntu) "maverick toolchain producing unbootable (hanging) kernels (affects: 1) (heat: 6)" [Undecided,New]
[15:18] <komputes> manjo: I don't see tifm_sd in the lsmod output
=== bjf[afk] is now known as bjf
[16:33] <skaet> https://wiki.ubuntu.com/Kernel/StableReleaseCadence
=== zul_ is now known as zul
=== elmo_ is now known as elmo
=== robbiew is now known as robbiew-lunch
=== Ian__ is now known as Ian_Corne
[18:03] <hallyn> uh oh, i see tangerine got rebuilt?  :)
[18:07] <jjohansen> hallyn: tim upgraded the disks
[18:14] <hallyn> jjohansen: yup, i knew it was coming eventually :)
[18:35] <pmatulis> why is the lucid netboot kernel [1] dated april 2010?  this is old.  am i missing something?
[18:35] <pmatulis> [1] http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/
[18:41] <sconklin> For bugs which are not verified and have the fix reverted, we can set them "wontfix" or "incomplete". Any thoughts from anyone about this?
[18:42] <bjf> sconklin, personally, i like "wontfix" and require a new bug and full, new SRU process for the related patch
[18:45] <sconklin> That's what I proposed, but I've heard the arguments that 1) wontfix isn't accurate, as we will fix it if it's tested, and 2) incomplete accurately reflects what happened. I'm afraid that bugs already turn into a mess too often, and we use them essentially for tracking tasks, so we should open a new bug. Otherwise, we also have to unwind the "fix committed" states
[18:48] <bjf> sconklin, but once a bug "needs verification" then it is more than just a bug, it is also tracking a process, which the bug states were never intended/designed to be for so it seems we can make them mean anything we want (i know this is a bit of a stretch but i hope you get my drift)
[18:51] <sconklin> bjf: right - we have no way to re-use a bug for another trip through the process, so I think we need to close it and start another. We agree?
[18:52] <bjf> sconklin, agreed
[18:52] <jjohansen> ugh, that is less than ideal
[18:53] <bjf> what would be ideal then?
[18:53] <sconklin> I'm open for suggestions
[18:54] <sconklin> by the way, I think we'll also break patchwork, when people reply to earlier email to re-request acceptance of a patch that was previously accepted. But we can deal with that later
[19:10] <jjohansen> sconklin: I don't have a better suggestion, ideally you could reuse the bug.  Having to close and start a new bug is just extra work and an extra step that mistakes can happen in.  /me was just kvetching that the process isn't as nice as it could be if it had been designed to accommodate SRU needs from the start
[19:24] <ogasawara> sconklin: hrm I slightly in favor of re-using the existing bug.  It should be simple enough to hammer out an arsenal script which posts a comment about the revert, sets the bug to Incomplete, and resets the tags.
[19:25] <ogasawara> sconklin: having to open a new bug, re-submit/re-ack patches is going to get annoying.  The patches and ack's should still be good, it's just the verification that failed.
[19:26] <lamont> how do I disable ipv6 on just one interface?  or can I?
[19:31]  * lamont finally finds it
[19:42] <sconklin> ogasawara: the actual agreement that was reached at UDS was that bugs will be closed "wontfix". There was a lot of discussion at UDS, and I feel like we're having it all over again.
[19:42] <sconklin> It's not that I'm opposed to refinement, but I do want to end discussion at some point and try something
[19:42] <ogasawara> sconklin: ack
[19:43] <ogasawara> sconklin: and we can always refine the process if we find our approach need tweaking
[19:44] <sconklin> My overriding goal from a selfish point of view is to minimize the amount of work that the stable team has to handle, as I'm not sure we will be able to keep up.
[19:44] <sconklin> And I am very open to changing things that don't work.
[19:44] <sconklin> I'm also concerned about creating still more bugs which seem to live forever
[19:45] <bjf> ogasawara, i'm curious to your thinking on not having to re-ack patches, once a patch has been reverted how would it get back into the repository?
[19:45] <sconklin> I'm frustrated by having to use a bug tracking tool to implement process, but it's what we have . . .
[19:47] <sconklin> so bjf - to recall some of the discussion that we had at UDS . . . One proposal was just to revert the patches and leave them on the tip of the tree until they eventually get tested.
[19:47] <sconklin> But this would lead to an ever-increasing load of cruft that we have to carry around.
[19:47] <bjf> sconklin, you'd revert, re-upload, then reapply?
[19:47] <sconklin> e also wanted to get assurance by whoever re-proposed the second SRU that there was a commitment to testing
[19:47] <ogasawara> bjf: I guess my thought process is that the patch was already reviewed and ack'd for it appropriateness, the fact that it was reverted due to failed verification doesn't actually reflect the patch itself is bad.  so if a reporter said "oops I was on vacation and wasn't around to test" we could just re-apply it.
[19:48] <sconklin> bjf: yeah - I'm NOT recommending that, it was just an idea that was rejected
[19:50] <ogasawara> bjf: and we could tag the bug with something like "re-apply" or whatever to know which patches to shove back in for the next upload.
[19:50] <sconklin> ogasawara: from the end user's POV I see this - if they're on vacation for a week and miss verification, we should make it easy for them to reapply. And honestly, getting everything correct on an SRU request is hard enough as it is.
[19:52] <sconklin> to totally throw a wrench in this - there are bugs which track the same fix in multiple releases
[19:52] <ogasawara> sconklin: ugh, now that could get messy
[19:53] <bjf> sconklin, known issue, and the question is when someone marks it verified which release were they referring to?
[19:53] <sconklin> example: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/580749
[19:53] <ubot2> Launchpad bug 580749 in linux (Ubuntu Maverick) (and 5 other projects) "Pulseaudio is not running VT1708 (affects: 2) (heat: 33)" [Undecided,Fix committed]
[19:53] <ogasawara> almost seems you'd need to make it verification-done-<release>
[19:54] <sconklin> bjf: This is currently handled manually by pitti. As he described it to me, when someone says it's verified for a release, he leaves both the verification-needed and verification-done flags set until every release is verified, then removes the verification-needed tag.
[19:55] <sconklin> I think we should probably change to verification-xxxxx-<release>, but this requires changes to Pitti's scripts that he uses
[19:55] <bjf> sconklin, but how does he know which release the commentor tested? does he ask them? (i'm assuming that he does)
[19:55] <sconklin> bjf: dunno, if it's not obvious from the comment
[19:56] <bjf> sconklin, if we ignore reverting patches, the fact that we now require certification testing of the proposed releases puts us in a much better place than we were before
[19:57] <sconklin> I'm worried that we have so much home-grown processes and so many tools which are dependent on special tags, text formatting in changelogs, etc, and so little of it is documented, that we have potential to break things unless we add more unique tags for our use.
[19:58] <sconklin> bjf: you mean if we don't revert? I don't think that's an option. But yes, I think we get more goodness from testing than from any other piece of this
[19:58] <bjf> sconklin, frankly the fact that we are using tags (which any user can add/remove/modify) for processes is not a good thing
[19:58] <bjf> sconklin, i'm not suggesting not reverting (though i'd like to)
[19:59] <sconklin> bjf: agreed, but today;s not the day for that fight. It's beyond the scope of what we can influence
[20:00] <sconklin> and reverting patches is being done to bring us in line with the release guidelines for Ubuntu, so unless they change, I'm trying to do a better job of compliance with those. I think requiring verification is a good thing.
[20:03] <sconklin> If we can manage the repositories, I don't think it would be terrible to just revert and reapply patches that don't get verified, then drop them after three strikes or something. We can think about that as an option if the process is too difficult to manage with reverts
[20:04] <sconklin> (that was more thinking out load than anything)
[20:07] <ikepanhc> sconklin: once verification for an SRU bugs finished, shall bug reporter modify the tag from verification-needed to verification-done or wait SRU team to review the verification and modify the tag?
[20:08] <sconklin> So far, we've let the user do it, and even instructed them to do it in the text added to tge bug
[20:11] <sconklin> ikepanhc: the reason is that I want to avoid another task that the stable team has to do on the verification deadline day, which is to open all the unverified bugs and read the comments to see whether it's verified. I want all of our operations to be scalable to more fixes without requiring more time, and I want them all to be able to be automated with scripting when possible.
[20:12] <ikepanhc> sconklin: make sense to me
[20:13] <jjohansen> however relying on reports to set tags right is not going to work well
[20:14] <ikepanhc> sconklin: another question, for bug 640214, everything is fine with karmic to enable Intel B43, but not on lucid, x-x-v-intel driver is not updated (maybe because nomination for lucid is not accpeted yet), can I just put verification-done there? (for kernel, it is done)
[20:14] <ubot2> Launchpad bug 640214 in xserver-xorg-video-intel (Ubuntu Karmic) (and 8 other projects) "X failed on Intel B43 machine (affects: 2) (heat: 24)" [Medium,Fix released] https://launchpad.net/bugs/640214
[20:14] <sconklin> ogasawara, bjf: another argument I just thought of in favor of NOT closing unverified bugs - they may have milestones set which are important, and be requiring new bugs to be opened, we may be proliferating cruft into the release and milestone tracking tools - this is another example of magic processes that work off of bugs that I don't fully understand
[20:15] <sconklin> ".... by requiring new bugs ... "
[20:15] <bjf> jjohansen, i agree completely, but we do it all the time
[20:17] <sconklin> bjf, jjohansen: so more accurately - instead of eliminating the need to review every unverified bug before reverting on revert day, I'm hoping to minimize the number that need to be looked at, by asking people to set the tags. I think review will still be required.
[20:18] <bjf> sconklin, so, we are going to have to visually inspect every bug to make sure the bug was not left on by mistake nor removed by mistake
[20:18] <jjohansen> bjf: yep, however we seem to be doing it more and more, and basically fear its getting to be too much
[20:18] <jjohansen> sconklin: what bjf said
[20:19] <bjf> sconklin, sorry "bug" -> "tag"
[20:20] <sconklin> I think that we at least have to check the ones without a verification-complete tag and see whether a comment says they are verified. For the converse, we have to decide what it means if someone sets the verification-done tag with no comment or explanation.
[20:20] <sconklin> As it stands now, we let them pass.
[20:23] <sconklin> and I think that now, no one pays much attention to bugs unless they are verification-needed. pitti would know. 
[20:23] <sconklin> I've asked him to join this room - he's away at the moment. 
[20:26] <sconklin> On monday we're going to do ~something~ to the unverified bugs - either close wontfix, or set to incomplete. (and we'll revert the changes). Since we're unsure about this, it seems to me that setting incomplete is the safer of the two options until we figure it out. Agree? Disagree? There will be text added explaining everything that is done.
[20:26]  * jjohansen -> lunch
[20:27] <ogasawara> sconklin: agree, setting to incomplete for now seems better imo.
=== Edgan_ is now known as Edgan
[20:39]  * apw notes boston has ok wifi
[20:59] <sconklin> ikepanhc: it's not clear to me from yoru comment in bug #640214 whether this is a pass or fail
[20:59] <ubot2> Launchpad bug 640214 in xserver-xorg-video-intel (Ubuntu Karmic) (and 8 other projects) "X failed on Intel B43 machine (affects: 2) (heat: 24)" [Medium,Fix released] https://launchpad.net/bugs/640214
[20:59] <ikepanhc> sconklin: for karmic, its passed, for lucid, proposed kernel works but still need xserver-xorg-video-intel supported
[21:01] <sconklin> ikepanhc: the change that's needed for lucid is all in xorg and not in the kernel, right? Are there any bad effects of having it in the kernel and not fixed in xorg?
[21:03] <ikepanhc> sconklin: for graphic chip support, we need to add ids in kernel and x-x-v-intel. no bad effects after kernel patched, at least we have the correct resolution on monitor
[21:04] <apw> that sounds like a pass to me :)
[21:04] <sconklin> apw: +1
[21:04] <ikepanhc> for kernel, I think it is
[21:04] <sconklin> I'm updating the bug now
[21:04] <apw> sconklin, whats the verified/unverified count today :)
[21:04] <ikepanhc> thanks
[21:05] <sconklin> give me a sec, and I'll have some numbers, I'm reviewing them all and spamming them now
[21:05] <apw> sconklin, liking the sound of that
[21:06]  * apw notes t.b has started building lucid
[21:06] <apw> (chroots)
[21:07] <sconklin> ikepanhc: you dais karmic and lucid in the bug, but the bug is open for karmic and maverick kernels
[21:08] <ikepanhc> sconklin: yes, but SRU patches is for karmic and lucid
[21:08]  * ogasawara lunch
[21:08] <sconklin> ikepanhc: yes I see. Thanks
[21:08] <ikepanhc> sconklin: the same patches landed on maverick through stable kernel
[21:08] <sconklin> excellent
[21:10] <sconklin> apw Lucid numbers are (probably) 8 verified, 15 unverified, and one fail that could be a show-stopper
[21:10] <sconklin> the status page is genrated by a cron job and lags reality
[21:10] <apw> sconklin, i assume we can just revert the fail too
[21:10] <sconklin> That's my plan
[21:10] <apw> is it one we care about ?
[21:11] <sconklin> apw: scratch that - the fail is probably not associated with any particular patch, and is reported against a tracking bug
[21:11] <apw> sconklin, heh ... well that is no use
[21:12] <sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/672964
[21:12] <ubot2> Launchpad bug 672964 in linux (Ubuntu Lucid) (and 1 other project) "2.6.32-26 unbootable: does not find root file system (affects: 1) (heat: 8)" [Critical,New]
[21:12] <sconklin> David is out today, so I expect he will respond to the latest comment tomorrow
[21:14] <apw> sconklin, isn't that one the one someone was talking about on here yesterday and had gone away and was not reproducible ...
[21:14] <sconklin> apw: I forgot - probably 4 of the "unverified" bugs I listed for Lucid are tracking bugs, so don't count - so it's better than it looks
[21:15] <apw> shouldn't you just move them verified (as they have no verification to do?)
[21:15] <apw> other than the one for QA of course
[21:16] <sconklin> smb said he thought that this one had come up before and been unreproducible, and a search of the forums, etc finds references to similar problems going way back, as far as I can tell they are generally fixed by doing what Tim suggested in the bug comment
[21:16] <sconklin> Pitti uses the verified status in those for tracking something, I think
[21:18] <sconklin> https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/654586 looks like a pass to me from the comments - any TI-OMAP experts wanna have a look?
[21:18] <ubot2> Launchpad bug 654586 in linux-linaro (Ubuntu Maverick) (and 1 other project) "No functionality to detect IGEPv2 board version (affects: 1) (heat: 99)" [Undecided,Fix released]
[21:19] <apw> sconklin, you'd probally want bryan or ogra for ti-omap (omap3) stuff
[21:19] <apw> coolooney is in the air though
[21:32] <sconklin> mpoirier: is it possible to test https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/654590 on Maverick?
[21:32] <ubot2> Launchpad bug 654590 in linux-linaro (Ubuntu Maverick) (and 1 other project) "WLAN-BT GPIOs need proper initialization (affects: 1) (heat: 97)" [Undecided,Fix released]
[21:32] <mpoirier> sconklin: looking
[21:32] <sconklin> There may be bugs for which we must accept verification in Linaro kernels of the same patch as valid for distro releases
[21:34] <mpoirier> sconklin: I thought I asked enric to test that one... hold on.
[21:35] <mpoirier> sconklin: I did ask him.  I'll look around for his anwer - I'm sure he did test it...
[21:37] <jcrigby> apw:thanks for fixing my work items
[21:37] <apw> jcrigby, heh, i get the error messages :)
[21:38] <apw> and i figured if i did that one, the email update would help you fix the others :)
[21:38] <jcrigby> apw, ahh now I understand
[21:39] <apw> jcrigby, fwiw you probabally should always use the 'Work items for <milestone>:' form, as without a milestone they don't track correctly and if you use the one on the blueprint some swine can change the overall milestone and make them all move without your notice
[21:40] <jcrigby> ok,I'll do that
[21:42] <sconklin> mpoirier: https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/651589
[21:42] <ubot2> Launchpad bug 651589 in linux-linaro (Ubuntu Maverick) (and 1 other project) "VBUS and overcurrent GPIO init missing in IGEPv2 board (affects: 1) (heat: 87)" [Undecided,Fix released]
[21:50] <sconklin> https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/654586
[21:50] <ubot2> Launchpad bug 654586 in linux-linaro (Ubuntu Maverick) (and 1 other project) "No functionality to detect IGEPv2 board version (affects: 1) (heat: 99)" [Undecided,Fix released]
[21:54] <sconklin> apw: Maverick numbers are approximately 17 verified, 2 tracking bugs, and 11 unverified, with two that I expect will get verification soon
[21:54] <apw> sconklin, that must be about a 4x on the normal ratio!
[21:55] <sconklin> I'm going to try to track the numbers each cycle. It will be interesting to see how it trends
[22:12] <apw> sconklin, sounds good to me ... /me goes find a tin can with wings
[22:12] <sconklin> I'm bailing out - thanks for all the help with the new stuff everyone!
[22:12] <bjf> c u monday
[22:13] <sconklin> There's a cold one calling me . . .
[22:20] <skaet> have a good weekend.
=== bjf is now known as bjf[afk]