[06:25] <idempotent> I am trying to rebuild the kernel one of the "proper" ways, based on the Kernel/Compile wiki page.  I am stuck when trying to tweak the config.  For example (for no real reason), I removed the BTRFS module.  Now I get an error, "MISS: btrfs" ... "EE: Missing modules (start begging for mercy)"...
[06:25] <idempotent> (sorry, can't pastebin, as error is on another unconnected computer)
[06:27] <idempotent> kernel source was installed using "apt-get source --only-source linux", config was edited with debian/rules editconfig (changed the amd64 {generic,preemt,server} configs), and built with "AUTOBUILD=1 debian/rules binary-debs"
[06:27] <idempotent> what am I doing wrong?
[06:27] <RAOF> idempotent: The “proper” way includes a bunch of cheks to ensure that the config matches kernel policy.  If you're breaking policy with your config changes (such as disabling btrfs) then you'll need to skip those checks.
[06:28] <idempotent> note that a pristine build works (unaltered config)
[06:30] <idempotent> RAOF: the check-config results at the end of editconfigs came up clean
[06:30] <idempotent> "21/21 checks passed -- exit 0"
[06:30] <RAOF> Oh, right.  Of course.
[06:31] <idempotent> I figured BTRFS would be a module I could remove with little/no dependency effects
[06:32] <RAOF> Yeah, but it's changed the kernel ABI which has raised the checking flags.
[06:32] <RAOF> Basically you just want to ignore the ABI checker.  And, in fact, all the checks.
[06:33] <idempotent> happy with it changing the ABI, and noticing that.  Seems "right" behaviour.  Just need to figure out why things have broken
[06:33] <bjf> idempotent: are you following https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel ?
[06:33] <idempotent> so I should try with something like "skipabi=1"?
[06:35] <RAOF> Yeah.  I forget quite what all the flags are.
[06:35] <bjf> idempotent: if you are having trouble with abi, look at: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance  and search for "skipabi"
[06:35] <idempotent> bjf: only just saw that, but, yes, it's pretty much what I'm doing
[06:36] <bjf> idempotent: the first one i mentioned is pretty straight forward, the second one covers a multitude of issues and isn't very well organized
[06:40] <idempotent> bjf: thanks, the first one is not working for me.  I do editconfigs and then binary-server, and it fails
[06:40] <idempotent> bjf: I am trying teh second one now - will try with skipabi=1 first, but I think using dch to change the ABI in the changelog is a better way to go
[06:41] <bjf> idempotent: which kernel are you trying to build ?
[06:43] <idempotent> bjf: lucid.  Build machine is a VM rnuning 11.10
[06:43] <bjf> idempotent: are you building using apt-get source or git clone ?
[06:44] <idempotent> apt-get source
[06:45] <bjf> idempotent: do you run into errors early in the build or towards the end ?
[06:47] <idempotent> towards the end in the sense that it takes maybe 30min to get to the error (though rerunning the command immediately gets me to the error quickly).  As soon as I do editconfigs, then it will be a "long" build time again
[06:48] <bjf> idempotent: ok, did you try just building the sources before making any changes ?
[06:48] <idempotent> bjf: yes, a pristine build successfully produces deb files
[06:49] <idempotent> bjf: I also did a compare on all files in debian.master/config and noted that the changes made sense (after understanding splitconfig.pl and kernelconfig scripts)
[06:50] <idempotent> "changes made sense" = "changes after debian/rules editconfigs made sense"
[06:51] <bjf> idempotent: then i guess i'd suggest skipabi=true skipmodule=true  (see the second url i posted)
[06:52] <idempotent> bjf: diong a build with skipabi now but not skipmodule.  Will try with skipmodule if the Bump ABI process doesn't work
[06:52] <bjf> idempotent: sounds like you are very close, and it is getting hung up in some of the automated checking that happens towards the end
[06:52] <idempotent> but, skipabi sounds like a workaround, right?  I shouldn't need to do this
[06:53] <bjf> idempotent: it depends on what config changes you are making
[06:54] <bjf> idempotent: i've got to turn in now, there will be some other kernel devs comming on soon
[06:54] <idempotent> sure.  I'm happy to have the ABI bumped (I think)
[07:03] <idempotent> so skipabi=1 made no change.
[07:03] <idempotent> Did dch -i and added some stuff, then redid the debian/rules binary-server - gets the same error immediately
[07:04] <idempotent> everything gets me the error quickly.  Am doing a clean
[07:29] <idempotent> still no joy.  Failing any other suggestions, I think I might raise a bug on the kernel?
[07:29] <idempotent> other clue: my VM is 11.10, but I am chrooting to a debootstrap of lucid, including the lucid-{updates,backports,security} repos
[07:35] <idempotent> trying it with an oneiric kernel in an oneiric chroot
[08:01] <idempotent> I am afk for now, back in about 16 hours or so
[08:01] <idempotent> RAOF: thanks
[08:01] <idempotent> bjf: thanks
[08:31]  * smb yawns
[08:34]  * apw yawns too
[08:57]  * diwic notices that https://wiki.ubuntu.com/KernelTeam/KernelUpdates and https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat are not exactly synced...
[08:58] <smb> diwic, You could change that... ;)
[08:58] <diwic> smb, of course, if you all will abide to my new rules ;-)
[08:59] <smb> diwic, I'd rather say that the former seems quite old... 
[09:00] <diwic> smb, hmm, that's bad, I think I just followed the former 
[09:02] <smb> diwic, So what did you find was conflicting?
[09:03] <diwic> smb, take the subject line, for example, one of them specifies things such as "UBUNTU: SAUCE: (pre-stable)" whereas the other does not seem to care
[09:03] <diwic> smb, one specifies sru justification in the bug, the other in the email
[09:05] <diwic> or maybe I became confused and did a mix-up
[09:05] <diwic> of both procedures
[09:07] <smb> Well the second seems more concerned with the look of the patch itself and we wrote that up later. Mostily to clarify all those different SAUCE or not and UBUNTU or not questions
[09:08] <smb> The justification should go into the bug report. Both versions should hopefully say that
[09:09] <smb> Ah I see
[09:10] <smb> Probably can be clearer. Mainly it should be in the bug report. And having them in there, you may copy it into the description/introduction area of the email
[09:12] <smb> Just as an additional helper for the person reading the email. To understand the issue, and because you had to write the whole thing in the report already
[09:12] <smb> The second document is more concerned about the actual patch (not caring that much about anything around it)
[09:13] <diwic> smb, could you or someone else take an action item on the next kernel team meeting to unify both wiki pages or make one link to the other?
[09:14] <smb> diwic, No, this is what I try to explain
[09:14] <smb> Its two things
[09:14] <smb> But it assumes that when you send an email with a patch for sru review, you got two parts
[09:15] <smb> 1. some introduction/description which is not part of the patch
[09:15] <smb> 2. the patch either inlined, attached or sent as a follow up
[09:15] <diwic> hmm, but does the patch have a subject line in that case?
[09:16] <smb> diwic, If you export it with git format-patch, yes
[09:16] <smb> (it is the commit title)
[09:16] <diwic> that does not make sense either with the current text
[09:17] <diwic> how could a patch's subject line say [pull request] ?
[09:18] <smb> I think I see the confusion 
[09:18] <smb> That should not be for the patch itself, that would be the subject of the whole email (thread)
[09:19] <smb> Its probably a bit special with pull-request anyway because there you have the patches themselves in a repo
[09:39] <apw> and actually git am ignores all the crap in [xxx] by default
[09:39] <apw> so you can add [Oneiric SRU] [PATCH 1/2] and those will not get added to whats committed
[10:13]  * apw reboots
[10:56] <smb> apw, Oh well. I thought it only would ignore the [PATCH.*] parts... If it ignores anything in [] it would make the need for slightly different subjects less important...
[10:56] <apw> smb, pretty sure its evertying in []'s, as i don't tkae special action when applying SRUs
[11:00] <apw> smb, the manual implies it strips [PATCH <anything>] from the title
[11:00] <apw> now i can't remember if everything is that form by luck
[11:00] <smb> apw, Yeah, seems to be more like a any [] at the beginning
[11:00] <smb> Just tried
[11:01] <smb> [oneiric] [PATCH] UBUNTU: [bla]
[11:01] <smb> becomes 
[11:01] <smb> UBUNTU: [bla]
[11:01] <apw> so any [] prefix then, fair enough
[11:02] <cking> was that by design or just luck that we chose to use [] as a prefix then?
[11:02] <smb> right. but anyway I would be too lazy to add something to the patch subject which goes away when I got the other subject
[11:02] <apw> cking, no because its a common idiom 
[11:03] <smb> cking, Maybe luck that it is more. But [PATCH.*] was common before
[11:03] <cking> ok, just wondering..
[11:03] <apw> that git am splunges it just makes it handlier
[11:45] <ogra_> apw, the tech overview page for A1 says "Set CONFIG_PANEL_DVI=y on arm" ... mind if i set that to "on omap" ? "on arm" is pretty unprecise 
[11:46] <apw> ogra_, seems more correct to me, go ahear
[11:47] <apw> ahead
[11:47] <ogra_> thx
[11:47] <ogra_> done
[11:48] <apw> ogra_, got a link to the notes so i can review them in general
[11:48] <ogra_> https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
[11:49] <apw> that overview is rather, erm, crap
[11:54] <ogra_> fix it then :)
[12:12] <apw> ogra_, yep, will get with ogasawara to do that
[12:57] <bjf> jsalisbury, there are more than 25 bugs on the hot list
[13:06] <ogra_> apw, for https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-arm-p-optional-initrd do you have any idea when the kernel team item on this might be ready (i would like to add the WI to a milestone)
[13:07] <apw> ogra_, stick an A2 on it and then we'll find out :)
[13:07] <ogra_> will do :)
[13:49] <bjf> apw, before you start whining (:-D), yes you are getting a double dose of the Morning Bug Report today. This one includes the top 10 bugs from the hot list. 
[13:50] <apw> bjf, *zip*
[13:53]  * bjf notes that the top 10 is wrong, it's in fact the bottom 10 from the list
[14:10] <jsalisbury> bjf, I'll go through the list and reduce it to 25
[14:11] <jsalisbury> bjf, any bugs with the iso-testing tag automatically get added.  maybe we want to change that?
[14:21] <bjf> jsalisbury: yes, i think so, they should be automatically added to your, da list, but only the "hot" ones included on the hot list, though maybe iso-testing should push non-iso-testing ones from the list
[14:21] <bjf> tgardner, apw, ogasawara, ^ what do you think ?
[14:22] <tgardner> yeah, just 'cause they are ISO testing bugs doesn't make 'em any hotter then bugs found independently.
[14:23] <apw> tgardner, right unless they are stopping a release, ie just before a milestone
[14:23] <apw> and i am sure we'll hear about those pretty quickly
[14:24] <tgardner> apw, as will independently discovered bugs is they are stopping a release. my point is that ISO testing has no bearing on the hotness of a bug. its merely another vehicle for performing some testing.
[14:25] <bjf> tgardner: i'm not sure that is how others are treating it, though pgraner would know for sure
[14:29] <pgraner> bjf, iso testing bugs are "hotter" than others, this is due to the fact some (weather automated or manual) has tested specifically for the milestone. We as a team have a requirement to make sure they are triaged within a week of the milestone.
[14:30] <pgraner> tgardner, jsalisbury: ^^^^
[14:31] <bjf> pgraner, the hot list is for bugs that are probably already triaged and are ready to be worked for a fix
[14:32] <bjf> pgraner, i don't think that changes how we will deal with iso-testing bugs
[14:32] <pgraner> bjf, my point was not what list they lie on per se but they iso-testing bugs are a bit different
[14:32] <pgraner> s/they/the/
[14:33] <bjf> pgraner, ack
[14:36] <pgraner> tgardner, I forgot who the macs go to, can you refresh my memory?
[14:37] <pgraner> tgardner, I thought one of each was to go the sforshee for enablement and the others?
[14:37] <tgardner> pgraner, eventually Q/A should get one of each, but I thought we'd try 'em out first to see what kind of bugs we're having. 
[14:38] <tumbleweed> seeing a lot of ath9k-related kernel panics with the current precise kernel (a couple a day) bug 898658
[14:38] <ubot2> Launchpad bug 898658 in linux "Lots of ath9k related kernel panics" [Undecided,New] https://launchpad.net/bugs/898658
[14:38] <tgardner> I'd say send a Pro, air, and mini to Seth initially.
[14:38] <pgraner> tgardner, ok, I thought we slotted one for cjwatson for mac boot issues
[14:38] <tgardner> pgraner, do we know there are issues yet ?
[14:39] <pgraner> tgardner, we hit a few on release week IIRC and that was one of the reasons that prompted us getting them
[14:39] <tgardner> send me one of each and I can probably work through the issues with cjwatson. he doesn't want anymore HW anyways.
[14:40] <tgardner> I'll probably end up send one around to cking to do some power profiling.
[14:40] <cking> tgardner, I'm up for that
[14:41] <tgardner> as far as I can tell, they are all 3 very different machines.
[15:01] <jsalisbury> pgraner, bjf, I will make it so the iso-testing bugs are automatically added to the DA hotlist: http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/_kernel_da_hot_.html
[15:02] <jsalisbury> pgraner, bjf, from there I can move them over to the kernel team hotlist once triaged
[15:02] <jsalisbury> pgraner, bjf, I check the DA hotlist very frequently
[15:04] <bjf> jsalisbury, that sounds like a reasonable workflow, note when you are out on holiday or are sick we'll need someone else to monitor that report as well
[15:04] <jsalisbury> bjf, right.  I'll be sure to clear all time off with the team and ensure there is coverage
[15:07] <cyphermox> tgardner: you had done a MIR in the past for iw, fyi, I'm writing a new one now (iw is needed by crda)
[15:09]  * herton -> lunch
[15:09] <tgardner> cyphermox, yep, I noticed from pitti's dependency graph. isn't iw just recommended by crda ? I haven't looked at the packaging recently.
[15:10] <cyphermox> tgardner: yeah, it's just a recommends, but iw is a verynicetohave anyway, I think.
[15:11] <cyphermox> tgardner: I for one would be happy with just iw and ip ;)
[15:11] <apw> tgardner, recommends have to promoted, suggests not i believe
[15:11] <apw> we always install recommends iirc
[15:11] <tgardner> cyphermox, I'm fine with it. iw is well supported upstream and is the preferred tool. it should probably become a depends.
[15:12] <cyphermox> ok
[15:24]  * ogasawara back in 20
[15:24] <cyphermox> tgardner: done, I subscribed you to the bug.
[15:25] <tgardner> cyphermox, ack
[15:33] <bjf> apw, you have any insight into whether bugzilla.kernel.org is ever coming back ?
[15:34] <apw> bjf, that is an interesting question, i have heard nothing about it no
[15:34] <apw> bjf, i am starting to think that people screaming for it is required
[15:34] <tgardner> bjf, rumor is that it will reincarnate in some form some day.
[15:34] <bjf> apw, i wonder if jjohansen or kees would know
[15:35] <bjf> tgardner, i wonder if they'd like "someone" to host it for them, in the cloud maybe
[15:36] <tgardner> bjf, I don't think hosting resources is the issue. last I read on LKML its being worked on....
[15:41] <bjf> tgardner, yes i see an email on the 11th that indicates they are waiting for HW to be put in place
[15:42] <tgardner> bjf, I agree that the pace is glacial, but you get what you pay for.
[15:43] <bjf> brendand, do you have a gameplan for bug 897773 ? where is it priority wise for you ?
[15:43] <ubot2> Launchpad bug 897773 in linux "[Acer AR320 F1 and Acer AR160 F1] Halting shortly after booting with 10.04.3" [High,Incomplete] https://launchpad.net/bugs/897773
[15:47] <jsalisbury> bjf, herton The following bug prevents the Oneiric server flavour from booting on Dell PE 2950.  The generic flavour boots fine: bug 897243
[15:47] <ubot2> Launchpad bug 897243 in linux "Dell PowerEdge 2900/2950 crashing with Ubuntu Server 11.10" [High,Triaged] https://launchpad.net/bugs/897243
[15:49] <brendand> bjf - pretty high. it's what ctf is working on as first priority at the moment. mainly to find out what's going on, since it seems more and more to not be something that is very likely to be triggered in normal use
[15:50] <bjf> brendand, ok, i'm keeping an eye on the bug. have seen no updates in the last 24hrs
[15:51] <bjf> brendand, thanks for the info
[15:51] <brendand> bjf - i'll talk to him about keeping the bug up-to-date properly
[15:59] <apw> ogasawara, yo ... infinity could really do with the armhf fix uploading as its holding up the bootstrap
[16:00] <apw> ogasawara, how far from the next upload are we.  if its days then we probabally should do a non-abi upload of the armhf commit
[16:06] <tgardner> apw, this is thutrsday. I think she was planning an upload as soon as A1 is released.
[16:06] <ogasawara> apw: I'm planning one today, right after Alpha1 releases
[16:06] <tgardner> jinx
[16:06] <ogasawara> heh
[16:06] <apw> ogasawara, then that should make infinity happy.  i think the freeze may be done
[16:07] <apw> 12:30:27      pitti | ... lifting freeze, happy uploading!                                                    │ AaronMT
[16:07] <apw> ogasawara, ^^
[16:08] <herton> jsalisbury, about this bug, I took a look, doesn't make much sense the config difference between generic/server causing the issue, well may be it's a timing issue. They seem to be complaining about controllers not being found, can be some problem in megaraid_sas with 3.0 kernel
[16:08] <ogasawara> apw: ah, so it is.  I thought it didn't lift until the actual announcement gets sent out
[16:11] <apw> ogasawara, its cirtainly unclear to me
[16:11] <ogasawara> apw: where did you see pitti mention that?
[16:11] <apw> ogasawara, that is on #ubuntu-devel
[16:19] <ogasawara> apw: just got clarification.  since we won't be respinning anything so it's ok to upload.  but for future reference we should typically wait of the announcement to note the archive is unfrozen.
[16:20] <apw> ogasawara, that makes little sense.  if #u-d topic says we are unfrozed, what are we
[16:20] <apw> ogasawara, i am sure we cna wait until the freeze is announced over
[16:21] <ogasawara> apw: we're unfrozen, even without the announcement having been sent out.  but I this is a one time scenario.
[16:21] <ogasawara> apw: I've gotta bail here in 10min for the dentist anyways.  I'll just wait till I get back to upload.
[16:21] <apw> ogasawara, seems reasonable to me
[16:22] <apw> ogasawara, i'd say have a good one, but its the dentist, so, erm
[16:22] <ogasawara> heh
[16:24] <jsalisbury> herton, Yeah, they report the filesystem goes read only when running the server flavour.  I'll see if they can post some logs after the server goes read only.
[16:29] <herton> jsalisbury, may be it's a kernel and an installer/initramfs issue, they say the kernel installed from the installer doesn't boot, but installed manually boots. Also comment #17 indicates may be personality to report as kernel 2.6.x could be needed, or at least to use some of that OMSA tools, although if they say kernel 3.2.x may I don't know, this may be just noise.
[16:30] <herton> *s/may/if they say kernel 3.2.x works flawlessly then/
[16:30] <bjf> herton, we have a PowerEdge 2950 in-house. i'm trying to determine how we can go about getting testing done on it
[16:31] <herton> ok
[16:32]  * apw calls it a day, some errands to run
[16:41] <cking> http://reports.qa.ubuntu.com/reports/boot-speed/
[16:42] <cking> so my only gripe is that we need multiple runs to just get an idea of the kind of variation we can expect to see 
[16:43] <cking> and if it's automated that shouldn't be hard to do should it? ;-)
[16:43] <tgardner> cking, your _only_ gripe? I'll hold you to that :)
[16:43] <cking> heh
[16:43] <cking> well, I don't like the colors too
[16:49] <brendand> which kernel version was just before the one for Alpha1?
[16:50] <tgardner> brendand, its been a 3.2-rc{12} kernel for a bit
[16:52] <brendand> tgardner - ok, the webcam has stopped working on my netbook. i'm sure it was yesterdays respin that did it. maybe it's a different package that's the problem
[16:53] <tgardner> brendand, yeah, there hasn't been anything significant in a week or so
[17:01]  * cking kicks a machine into a first round of intensive soak tests - back later
[17:09] <jsalisbury> hggdh, When you have a chance, can you test the 3.2.0-2.5 kernel for bug 894070
[17:09] <ubot2> Launchpad bug 894070 in linux "IOMMU error loop early in boot" [High,Triaged] https://launchpad.net/bugs/894070
[17:10] <jsalisbury> hggdh, I'd like to do a bisect, but want to confirm the issue is still in the latest kernel.
[17:15] <luis_> hi there! i'm needing help regarding how to install the newest kernel in order to solve this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/898615
[17:15] <ubot2> Launchpad bug 898615 in linux "[Presario C500] Hibernate command fails and returns to userspace" [Medium,Confirmed]
[17:15] <luis_> i've downloaded and installed the .deb header from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc3-oneiric/
[17:16] <luis_> but it doesn't show in the GRUB boot screen
[17:25] <luis__> hi there! i'm needing help regarding how to install the newest kernel in order to solve this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/898615
[17:25] <ubot2> Launchpad bug 898615 in linux "[Presario C500] Hibernate command fails and returns to userspace" [Medium,Confirmed]
[17:26] <lool> apw: Hey!
[17:26] <lool> apw: infinity tells me you're working on the linux/armhf FTbFS
[17:27] <lool> apw: I have this http://paste.ubuntu.com/756182/, but it's untested
[17:36] <luis__> hi there! i'm needing help regarding how to install the newest kernel in order to solve this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/898615
[17:36] <ubot2> Launchpad bug 898615 in linux "[Presario C500] Hibernate command fails and returns to userspace" [Medium,Confirmed]
[18:09] <dantti> Hi, I'm trying to provide a patch to the upstream kernel but weirdly I'm not being able to install the upstream kernel it does not create the /lib/modules/kernel-version, I did make menuconfig (with .config from /boot), make and make install (even tryied make modules install but afair it wasn't needed), any tips on what I might be missing? 
[18:09] <dantti> I'm on 11.10 and I have a clone of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
[18:10] <dantti> it compiles fine but emits some FATAL saying modules.dep does not exist which is true as /lib/modules/... does not exist..
[18:32] <bjf> tgardner, wrt bug 790863 will we ever re-enable CONFIG_NET_NS ? or should we "Won't Fix" the bug ?
[18:32] <ubot2> Launchpad bug 790863 in linux "Unable to start lxc container after update to 2.6.32-32" [Critical,Confirmed] https://launchpad.net/bugs/790863
[18:35] <tgardner> bjf, checking
[18:39] <bjf> ogasawara, i'm looking at bug 843892, what does it mean that the linux-lts-backport-natty package has a Oneiric task ?
[18:39] <ubot2> Launchpad bug 843892 in linux-lts-backport-natty "Repeatable kernel oops on container delete" [Medium,Confirmed] https://launchpad.net/bugs/843892
[18:40] <ogasawara> bjf: hrm, dunno.  I'll look.
[18:41] <hggdh> jsalisbury: will test now
[18:41] <ogasawara> bjf: I'm not sure why that linux-lts-backport-natty task was even added to that bug
[18:41] <bjf> ogasawara, i'm only asking because you are the one that added the nomination
[18:42] <bjf> ogasawara, i think both of those tasks should be "Fix Released" anyway, i was just confused
[18:42] <ogasawara> bjf: I added the nomination for the linux task, which lp then automatically assumes it should open a nomination for all the present tasks
[18:42] <bjf> ogasawara, how helpful that is
[18:43] <ogasawara> bjf: yah, just close those out
[18:43] <bjf> ogasawara: done
[18:47]  * cking preps 2 more boxes for soak testing overnight and calls it a day..
[18:48] <bjf> cking, don't you waste a lot of water doing that? or do you spread that on the garden tomorrow after the test?
[18:48] <cking> lulz
[18:50] <cking> bjf, I wondered why putting the boxes on the bath caused them to be unreliable...
[18:50] <bjf> cking, shoddy HW
[18:53] <hggdh> jsalisbury: fails the same on 3.2.0-5. I do not know if it affects or not, but this is a system with encrypted LVM, multiple filesystems under the encrytped LVM
[18:55] <vanhoof> herton: should bug 794642 be Fix Commited for natty, and have a verification-needed-natty tag?
[18:55] <ubot2> Launchpad bug 794642 in linux "[Dell optiplex 390][SFF] Dvd drive not recognized by system" [High,Fix released] https://launchpad.net/bugs/794642
[18:55] <vanhoof> herton: looks that way from ubuntu-natty.git
[18:55] <vanhoof> just wanted to confirm
[18:57] <herton> vanhoof, it was verified for natty, but looking at bug history ming changed manually from fix commited to fix released after verification, it wasn't needed, so just be fix commited yet, once release the janitor automatically sets to fix released
[18:57] <herton> *so it should be just fix commited yet
[18:58] <vanhoof> herton: ack, fixed it up
[18:59] <vanhoof> herton: thanks for the confirmation
[19:07]  * tgardner -> lunch
[19:14] <jsalisbury> hggdh, thanks for testing.  We may have a few more test kernels from the bisect.  Did you have the same config(encrypted LVM, etc) when the issue didn't happen in 3.1 and earlier?
[19:33] <tgardner> jdstrand, what do you think about CVE-2011-2189 wrt bug #790863 ?
[19:33] <ubot2> Launchpad bug 790863 in linux "Unable to start lxc container after update to 2.6.32-32" [Critical,Confirmed] https://launchpad.net/bugs/790863
[19:33] <ubot2> tgardner: net/core/net_namespace.c in the Linux kernel 2.6.32 and earlier does not properly handle a high rate of creation and cleanup of network namespaces, which makes it easier for remote attackers to cause a denial of service (memory consumption) via requests to a daemon that requires a separate namespace per connection, as demonstrated by vsftpd. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2189)
[19:33] <hggdh> jsalisbury: yes indeed, no changes
[19:34] <bjf> tgardner, any thoughts on that bug i mentioned earlier?
[19:34] <tgardner> bjf, thats what I just pinged jdstrand about
[19:34] <bjf> d'oh
[19:35] <jdstrand> tgardner: what is the question exactly, that this bug is that CVE?
[19:35] <tgardner> jdstrand, what do you think about applying the fix for it to Lucid vsftpd ?
[19:36] <jdstrand> tgardner: I feel dense, where is the fix for vsftpd?
[19:37] <jdstrand> I see kernel commits in the bug...
[19:37] <tgardner> jdstrand, dunno. Debian applied a fix to vsftpd to check kernel versions before using network name spaces.
[19:37] <jdstrand> oh
[19:38] <tgardner> so, I'd like you to consider the same approach.
[19:39] <jdstrand> this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629373
[19:39] <ubot2> Debian bug 629373 in vsftpd "Remote DoS with vsftpd on Linux 2.6.32" [Serious,Fixed]
[19:39]  * jdstrand pulls the package
[19:39] <tgardner> looks like it
[19:41] <tgardner> jdstrand, fixing vsftpd in conjunction with a kernel patch proposed by Tetsuo Handa might ameliorate the OOM killer DOS
[19:43] <tgardner> smoser, ogasawara just uploaded the fix for the virtual flavour network device inclusion bug.
[19:44] <jdstrand> tgardner: I am not opposed to it. with slight massaging I can get 10-remote-dos.patch to apply on lucid
[19:44] <tgardner> jdstrand, cool. If you would drive that, then I'll take care of the kernel side.
[19:45] <jdstrand> tgardner: do these have to happen in tandem or can we snag this as part of our normal flow?
[19:45] <tgardner> vsftpd should go up first
[19:45] <smoser> tgardner, ogasawara thank you. how long till that would appear in archive (ie, how long to build it.)
[19:45] <tgardner> however, it'll be a week or so before the kernel gets loanded in -updates
[19:45] <ogasawara> smoser: should only be but a few hours
[19:46] <jdstrand> ok
[19:46] <bjf> tgardner, right now it would go up in 6 weeks to -updates
[19:47] <jdstrand> tgardner: would it be ok if I added a lucid task?
[19:47] <tgardner> bjf, right, a week "or so"
[19:47] <tgardner> jdstrand, yep
[19:55]  * bjf is will be back in a bit, running an errand
[19:55] <jdstrand> tgardner: so, just so I am clear-- I can upload this for all releases monday (say), but you guys will be handling lucid in your own timeframe. is that accurate?
[19:56] <tgardner> jdstrand, yes. I think there is _no_ chance that we'll get a kernel in -updates before you get vstpd uploaded.
[19:56] <jdstrand> tgardner: ok, cool. we were tracking this, but it was 'low'. sounds like it should be 'medium' based on remote DoS nature of the bug. it is on our radar, we will handle it
[19:57] <tgardner> jdstrand, thanks
[20:23] <jsalisbury> hggdh, re bug 894070 Can you also confirm that this was not an issue with the Ubuntu 3.1.0-1.3 kernel?  That way we have a starting point for the bisect.
[20:23] <ubot2> Launchpad bug 894070 in linux "IOMMU error loop early in boot" [High,Triaged] https://launchpad.net/bugs/894070
[20:24] <jsalisbury> hggdh, actuall 3.1.0-2.3
[20:33] <jsalisbury> hggdh, I would also like to request two other kernels to be tested.  I'll add the details to the bug.
[20:51] <hggdh> jsalisbury: no kernel before 3.2 failed
[20:51] <hggdh> and I installed all precise kernels
[20:53] <hggdh> jsalisbury: additionally, 3.1.0-2.3 was my fallback kernel when I first booted 3.2
[20:54] <jsalisbury> hggdh, thanks for the info.  Would it be possible for you to test the mainline 3.2-rc2 kernel?  That will rule out any Ubuntu patches as causing the issue.  
[20:55] <jsalisbury> hggdh, and also v3.2-rc1.  That will give us a good good spot to start with the least amount of changes.
[20:56] <jsalisbury> hggdh, Depending on your results. We will either bisect between upstream v3.1 and v3.2-rc1 or between upstream v3.2-rc1 and v3.2-rc2.
[20:56] <hggdh> jsalisbury: downloading the 3 kernels now
[20:56]  * hggdh prepares for an orgy of reboots
[20:56] <jsalisbury> hggdh, great, thanks!  
[20:57] <hggdh> jsalisbury: thank YOU :-)
[20:57] <jsalisbury> hggdh, :-)
[21:14] <hggdh> jsalisbury: both upstream kernels -- 3.2rc1 and 3.2rc2 work when booted without intel_iommu=off
[21:15] <hggdh> jsalisbury: OTOH, I lose wireless on them
[21:17] <jsalisbury> hggdh, hmm, that indicates an Ubuntu patch introduced this
[21:17] <hggdh> yeah, sounds like it
[21:18] <hggdh> jsalisbury: do you still want me to boot 3.1 mainline?
[21:18] <jsalisbury> hggdh, you probably don't need to.  I would assume that it works, since both 3.2 release candidates work.
[21:19] <hggdh> jsalisbury: I agree, but wanted to be sure
[21:19] <hggdh> anyway, I can install & run the beast later
[21:20]  * ogasawara lunch
[21:21] <jsalisbury> hggdh, ok, thanks.  So this issue appears to be an Ubuntu patch applied between 3.1.0-2.3 and 3.2.0-1.1
[21:22] <jsalisbury> hggdh, can you post your mainline testing results to the bug, so they are tracked.
[21:26] <jsalisbury> hggdh, Interesting that there is a similar RHEL bug, since this is pointing to an Ubuntu patch.
[21:26] <hggdh> jsalisbury: already did
[21:26] <hggdh> jsalisbury: indeed, and I wonder if this was a RH patch also -- reported on 2.32, and now closed
[21:27] <jsalisbury> hggdh, maybe the same patch we both applied since it was not upstream.  I see 12 SAUCE entries in the change log between 3.1.0-2.3 and 3.2.0-1.1
[21:29] <Sarvatt> or a config change, mainline kernels were still using older configs if they didn't have wireless
[21:30] <jsalisbury> Sarvatt, hmm, interesting.
[21:31] <luis__> hi there! i'm needing help regarding how to install the newest kernel in order to solve this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/898615
[21:31] <ubot2> Launchpad bug 898615 in linux "[Presario C500] Hibernate command fails and returns to userspace" [Medium,Confirmed]
[21:32] <jsalisbury> luis__, can you post the output from the following to the bug: dpkg -l | grep linux-image
[21:33] <luis__> ok jsalisbury
[21:34] <luis__> http://paste.ubuntu.com/756449/
[21:35] <jsalisbury> luis__, Hmm, I don't see the mainline 3.2rc2 kernel listed.  Did you install it with dpkg?
[21:35] <luis__> at first i made the mistake of installing it via software center
[21:36] <Sarvatt> CONFIG_MEMSTICK_R592 was enabled which hggdh's device on 04:00.0 is using
[21:36] <luis__> but the second try i did it via dpkg
[21:36] <jsalisbury> luis__, Go to http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc2-oneiric/
[21:36] <jsalisbury> luis__, Download linux-image-3.2.0-030200rc2-generic_3.2.0-030200rc2.201111151435_i386.deb	
[21:36] <luis__> i've done that!
[21:36] <jsalisbury> luis__, Run sudo dpkg -i linux-image-3.2.0-030200rc2-generic_3.2.0-030200rc2.201111151435_i386.deb	
[21:36] <luis__> i've done that too!
[21:37] <jsalisbury> luis__, did you have any errors while installing?
[21:37] <luis__> none at all
[21:37] <luis__> as you can see in the bug, i've posted that it didn't show up un the grub 
[21:37] <luis__> if I uninstall it now, and re install via dpkg only
[21:38] <jsalisbury> luis__, And id didn't show up in the dpkg output you posted.
[21:38] <Sarvatt> jsalisbury, hggdh: http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=blob;f=dmar-disable-when-ricoh-multifunction.patch;h=a4528617ecfdc437072e96c47cafbe10b5e5478f;hb=HEAD
[21:38] <jsalisbury> luis__, can you attach the dpkg.log file to the bug and I'll have a look at it.
[21:38] <Sarvatt> believe we have a winner there
[21:38] <luis__> ok
[21:38] <jsalisbury> Sarvatt, looking
[21:39] <bjf> luis__ try to install it again and see if it tells you that it is already installed
[21:39] <luis__> ok, doing that bjf
[21:39] <bjf> luis__, also, pastebin the output from that attempt
[21:40] <bjf> luis__, is this a multi-boot system ?
[21:41] <jsalisbury> Sarvatt, hggdh I see this in commit: fe763ab898670195870b889e145483ce5c8997d5
[21:41] <luis__> yes bjf
[21:41] <luis__> have win xp
[21:41] <luis__> but before the update to oneiric the hibernate worked just fine
[21:41] <jsalisbury> Sarvatt, hggdh, ogasawara: http://paste.ubuntu.com/756455/
[21:42] <Sarvatt> jsalisbury: yeah
[21:42] <luis__> i even got it to hibernate on this version at some attempts, but it were really scarce to isolate what happened those successful times
[21:42] <Sarvatt> the fact he doesn't have wireless implies it was using the older configs because the wireless problem got fixed up after 3.2-rc2 was uploaded to precise
[21:42] <Sarvatt> it being the mainline builds
[21:44] <Sarvatt> aka 3.2-rc1 and 3.2-rc2 mainline builds used the 3.1 kernel configs and the memory stick module wasn't built
[21:44] <jsalisbury> Sarvatt, awesome.  Thanks for the research!
[21:46] <luis__> jsalisbury, now i see you told me to instal 3.2rc2, now i see i was trying to install 3.2rc3
[21:46] <luis__> i'm gonna try now with that image
[21:46] <jsalisbury> luis__, ahh, yeah I don't know if there is a complete .deb there yet
[21:47] <luis__> we'll see if it works now jsalisbury
[21:47] <jsalisbury> luis__, great thanks.  please post your findings to the bug.
[21:48] <hggdh> darn, I got so many things connected to the system...
[21:48] <jsalisbury> hggdh, heh, you should be able to connect anything you want ;-)
[21:48]  * tgardner -> EOD
[21:49] <hggdh> jsalisbury: roight
[21:49] <jsalisbury> hggdh, I'll see if I can build a test kernel without that patch/config change and post it to the bug to be tested.
[21:50] <hggdh> jsalisbury: perfect, thank you.
[21:50] <Sarvatt> jsalisbury, hggdh: got a kernel building already
[21:50] <jsalisbury> hggdh, np, thanks for all the testing.  And Sarvatt thanks for your help.
[21:50] <jsalisbury> Sarvatt, awesome
[21:51] <Sarvatt> jsalisbury: oh, sorry, I was building one with that patch added, might still want one with the config change reverted?
[21:52] <jsalisbury> Sarvatt, ahh, ok.  Your building a test kernel with the patch listed on: http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=blob;f=dmar-disable-when-ricoh-multifunction.patch;h=a4528617ecfdc437072e96c47cafbe10b5e5478f;hb=HEAD
[21:52] <Sarvatt> there is a fix, it's just only in fedora/redhat/SUSE
[21:53] <luis__> bjf jsalisbury, i think it'll work now http://paste.ubuntu.com/756468/
[21:54] <jsalisbury> luis__, looks like you'll need the linux-headers-3.2.0-030200rc2-generic package too.
[21:54] <jsalisbury> luis__, its avaiable at that same link.
[21:54] <luis__> ok
[21:57] <luis__> jsalisbury, it showed an error http://paste.ubuntu.com/756474/
[22:01] <hggdh> luis__: you need both the generic and the arch header packages
[22:02] <luis__> hggdh: you mean i must install linux-headers-3.2.0-030200rc2_3.2.0-030200rc2.201111151435_all.deb too?
[22:02] <jsalisbury> luis__, so these ones too: linux-headers-3.2.0-030200rc2_3.2.0-030200rc2.201111151435_all.deb
[22:02] <luis__> got it
[22:03] <luis__> the order in which i've installed it will alter something?
[22:03] <luis__> or the order doesn't matter?
[22:03] <jsalisbury> luis__, I believe the all package needs to be done before the arch one?
[22:04] <luis__> thanks jsalisbury
[22:09] <luis__> jsalisbury hggdh  http://paste.ubuntu.com/756488/
[22:14] <luis__> i'm gonna give it a try
[22:15] <luis__> booting it anyway... BRB
[22:19] <SpamapS> Hey guys, working on pushing out the new kernel update to lucid-updates
[22:20] <SpamapS> just want to make sure I get the packages right
[22:20] <SpamapS> linux, linux-meta, linux-backport-modules-2.6.32 all are already in lucid-updates
[22:20] <bjf> SpamapS: checking
[22:20] <SpamapS> what about linux-firmware ?
[22:22] <luis_> jsalisbury hggdh, worked! posting to bug. Is this kernel version stable? will I have any problems with it?
[22:22] <bjf> SpamapS: yes to  linux, linux-meta, linux-backport-modules-2.6.32
[22:23] <bjf> SpamapS: i think linux-lts-backport-oneiric and linux-lts-backport-maverick are ready as well
[22:23] <Sarvatt> hggdh: http://kernel.ubuntu.com/~sarvatt/lp894070/
[22:24] <Sarvatt> you've pretty much already verified it works though by using intel_iommu=off
[22:25] <bjf> SpamapS: i'm not sure of linux-firmware, i think you should be able to publish it as well
[22:25] <hggdh> Sarvatt: aye ;-)
[22:25] <hggdh> Sarvatt: I have to walk the dogs -- it is the time of day they start arfing around me asking for it --; as soon as I am back I will boot it
[22:27] <jsalisbury> luis_, That is an upstream kernel, so its not the supported Ubuntu kernel.  However, since your bug is fixed upstream, the fix will make it into Precise(12.04) if it hasn't already.  
[22:27] <SpamapS> bjf: but the lack of the maverick/oneiric backport kernels won't be a problem for users of the normal lucid kernel, right?
[22:27] <SpamapS> bjf: I'd rather hold off on the backport kernels.
[22:27] <bjf> SpamapS: that's correct
[22:28] <jsalisbury> luis_, thanks for your help testing!
[22:28] <SpamapS> bjf: ok, I'm going to hold off on those two for now. I'd like to have a brief discussion with pitti and then make sure the process is outlined in the right place in the wiki so there's no confusion next time.
[22:29] <luis_> jsalisbury, I'm the one that thanks you! thank you too hggdh!
[22:29] <bjf> SpamapS: sorry, my bad, the lts-backport kernels have not finished testing
[22:32] <bjf> ogasawara, the wireless model mentioned in bug 836250 . were any of those in the collection you got from intel ?
[22:32] <ubot2> Launchpad bug 836250 in network-manager "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [High,Invalid] https://launchpad.net/bugs/836250
[22:32] <luis_> two more questions jsalisbury, 1) I don't know exactly what an upstream kernel is, where can I get info on that? 2)What is your recommendation in your guts? Should I use this kernel or not?
[22:41] <jsalisbury> luis_, An upstream kernel, is the vanilla kernel that all Linux distros base their code on.  If you can live with this bug, it's best to go back to the Ubuntu kernel.  Else if you can't live with this bug, it should be OK to run the upstream kernel until Precise(12.04) is released.
[22:44] <luis_> jsalisbury, that really helped. I think I'm gonna give it a try, take the risks and see how it works. Since my laptop battery is virtually dead, I really need that functionality.
[23:01] <hggdh> Sarvatt, jsalisbury: test kernel boots successfully, without any DMAR errors being reported
[23:02] <Sarvatt> those multifunction ricoh's are very popular devices, i'm surprised there aren't more bug reports
[23:03] <hggdh> I also wonder about that -- but, then, we did not have the module loaded before, and Precise is still at alpha1, so only demented people run it
[23:04]  * hggdh notes a lot of kernels to test on SRUs...
[23:05] <bjf> hggdh, how close are we to having deadicated SRU testing resources ?
[23:13] <hggdh> bjf: rather close, I think. Close-ish is perhaps more correct
[23:13] <hggdh> bjf: I hope DEADicated was a misstype ;-)
[23:15] <hggdh> bjf: anyway, I will start on this new crop tomorrow
[23:23] <bjf> hggdh, you don't want to learn how to spell from me, that's for sure
[23:34] <ogasawara> bjf: I'd have to check.  I was procrastinating on getting the wifi harness from Intel to ease switching out the cards for testing.
[23:35] <bjf> ogasawara: the pci cards?, there were 4 in lexington, 1 to tim, 1 to seth and 1 for Qa, 1 left over
[23:36] <bjf> ogasawara: if you'd like one, i think that can be arranged
[23:37]  * ogasawara is confused now
[23:37] <ogasawara> bjf: I thought you were talking about the wifi cards from the last roadmap meeting
[23:38] <bjf> ogasawara: i was and you were talking about wifi harness so i'm not sure what harness you are referring to
[23:39] <bjf> ogasawara: i thought you ment pciexpress cards that you could plug the modules into
[23:40] <ogasawara> bjf: ah. all I know is pete was getting i think 6 kits which would allow easily interchanging the cards so you don't have to go through the hassle of connecting/disconnecting the leads etc.
[23:40] <ogasawara> bjf: if that's what he had in lexington, then yes I'd like one.
[23:40] <bjf> ogasawara: yes, that's what i was talking about, maybe it was 6 and not 4
[23:41] <ogasawara> bjf: regardless if there are extra I could definitely make use of it.  I'll ping pete.
[23:41] <bjf> ogasawara: there were extras whatever the case
[23:42] <ogasawara> bjf: some of the labels on the wifi cards are not all that informative (eg "sample").  but the others have slightly more info.  I'll cross check that info with what's in the bug.
[23:42] <bjf> ogasawara: cool
[23:51] <ogasawara> bjf: doesn't look like the cards I have match up with those in the bug.  they are n mode capable though.  I'll see if I can get some testing in tomorrow.
[23:52] <vanhoof> ogasawara: bjf: talking intel?
[23:52] <ogasawara> vanhoof: yah
[23:53] <vanhoof> ogasawara: leme send you guys something