[00:47] <jsalisbury> arges, what bjf said ;-)  I also add the tag: kernel-bug-fixed-upstream
[00:49] <jsalisbury> arges, I generally marked a bug as "Triaged" if it has a patch/commit available upstream, which has not yet made it into the Ubuntu kernel via a development kernel rebase or stable update.
[07:46] <rudimeyer> I noticed the kernels for Ubuntu 11.10 (3.0) and Ubuntu 12.04 (3.2), in Amazon EC2 have a defective handling of EBS drives (Xen virtual block devices). Anyone know of this?
[08:13] <smb> rudimeyer, No, and "defective handling" is not really helpful to provide any better answer.
[08:14] <rudimeyer> smb: Sorry, I will try to discribe it better. The issue is, then a EBS disk is disconnected, by API or error. The system doesn't handle the disconnect. Fx. in a raid setup (mdadm) , the array "hangs" and never gets to mark the disk as faulty
[08:17] <rudimeyer> I have tried to explain it here: https://forums.aws.amazon.com/thread.jspa?messageID=402877&#402877
[08:17] <smb> rudimeyer, You probably should open a bug report on this where logfiles could be attached and so on. Generally the blockfront driver is working (at least those instance types that are PVM)
[08:18] <smb> rudimeyer, Ah, so it is not only Ubuntu having issues with mdadm but about anything but Redhat images...
[08:19] <rudimeyer> smb: Yes, what I have testet out, and I'm no expert, is kernel version 3.0+ thats giving the problem. (All tested on EC2)
[08:19] <rudimeyer> smb: Its not limited to mdadm. Gluster, lvm etc. also has the issue of hanging when disk is pulled.
[08:20] <rudimeyer> smb: It never "fails", just hanging/waiting forever on the disk
[08:21] <smb> rudimeyer, Ok, and the detach command is from the ec2 tools/aws web console, right
[08:21] <rudimeyer> smb: Yes, 'force-detach'
[08:24] <smb> Hm, so probably removing the drive on xen level (though only Amazon would know what they do). Since there are no error messages it is not so easy to find out what is going wrong. Could be some udev processing or the upstream netfront driver.
[08:25] <smb> You could probably try to see whether there are suspicious looking processes after detaching 
[08:26] <smb> And to see whether thing potentially changed in recent kernels, try some mainline kernels
[08:26] <smb> !mainline
[08:26] <ubot2> The kernel team supply continuous mainline kernel builds which can be useful for tracking down issues or testing recent changes in the Linux kernel. More information is available at https://wiki.ubuntu.com/Kernel/MainlineBuilds
[08:26] <rudimeyer> smb: Alot of good input, will get on with that. Thank you very much
[08:31] <smb> rudimeyer, Your welcome.
[09:11] <jtb1> hi! is there a way to get the linux-tools for the kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
[09:12] <smb> jtb1, No, I don't think so
[09:13] <jtb1> is there a way to build it by myself?
[09:15] <smb> jtb1, That should be possible when you download the same version of upstream code and then apply the patches from the mainline page
[09:20] <jtb1> is there some way to add this as feature request? ;)
[09:27] <apw> jtb1, i cannot remember why we do no make them
[09:27] <apw> jtb1, i suspect originally they wern't buildable, i just cannot remember any more
[09:48] <rudimeyer> smb: Hope you're still around :) I've tested out a couple of mainline kernels, one according to "Ubuntu to Mainline kernel version mapping" and newest patch release of 3.2 corresponding to the 3.2.x of my precise installation. No luck. Logs show nothing but a entry about a file operation "blocked for more than 120 seconds". Processes related to the disk is in the 'D' state.
[09:49] <rudimeyer> smb: Is it anyway possible to get a qualified person to maket the same tests i did, gather data and descirbe the issue? My company is willing to pay for a resolution.
[09:51] <smb> rudimeyer, I am. And yes, the blocked process likely could be related. 
[09:55] <smb> As for making it more official, not sure you have already support contracts with either Amazon or Canonical, so filing bugs there would be the next steps
[09:56] <smb> Or the other question would be whether basically pulling out drives from a (virtual) machine is exactly the testcase you want to cover or whether it rather could be errors on the drive
[09:57] <smb> I think there have been some device-mapper targets that could be used for that.
[09:58] <smb> From the top of my head I cannot say whether blockfront is supposed to support hot-unplug or not. I agree that it likely should. But it could be some feature yet ot be implemented than a pure bug fix...
[10:00] <rudimeyer> smb: I've been thinking the same thing, maybe may test is off. But again, it work on 2.6 kernels :|
[10:02] <smb> rudimeyer, Ah, ok. So if it used to work, then it should still. 
[11:04] <yf-geek> Do I have to apply manually the ubuntu patches to the kernel even if i "apt-get source linux-image-$(uname -r)" then compiling it?
[11:05] <ogra_> nope
[11:05] <ogra_> the ubuntu patches are maintained in git, the tarball the linux-image-* package uses contains the whole git tree (incl. all patches)
[11:12] <yf-geek> hmm, why i feel that the mouse(actually  a touchpad) is not that snappy anymore after i installed a kernel that is compiled with that, even if it is the same version......
[11:15] <yf-geek> how do i tell the dkms modules to build after i have installed the kernel image by myself?
[11:23] <yf-geek> nvm, i already found the solution
[11:24] <yf-geek> now i really don't understand why i have to press the left mouse click button for a longer time before i can do any kind of dragging actions? i am using kubuntu, wondering that if there is any difference between ubuntu's kernel and kubuntu's
[11:56] <tyf> hmm, seems like removing a non-dkms driver (alx) solved the mouse drag problem, perhaps the driver will cause the interrupt to work oddly?
[11:57] <tyf> now reinstalled it and everything works fine
[12:05] <tyf> usually, PAE kernel or the 64bit kernel is more stable?
[12:26] <rtg> apw, ogasawara: any objection to uploading today ?
[12:31] <apw> rtg, give me 2 mins
[12:31] <apw> just doing some s/r testing on it
[12:31] <rtg> apw, no rush
[12:31] <apw> rtg, for next time could you make them ~pre1 or something so we get the official kernels automagically ?
[12:33] <rtg> apw, I'm not following you. Are you building the raring repo as COD ?
[12:34] <apw> rtg, no i am testing the binaries you posted yesterday, but they are numbered as official releases
[12:35] <apw> rtg, i was suggesting slamming a ~pre1 in the version when you build like that
[12:35] <apw> rtg, nyhow seems to boot ok for me, on both  32 and 64 bit and s/r cycles seem ok
[12:35] <rtg> apw, hmm, you should get new binaries anyways because they are newer and the MD5 sums don't match.
[12:36] <apw> rtg, i don't believe that will occur, i believe it will say the version i have is the same and be done
[12:36] <apw> but when you upload it, we can test that
[12:36] <rtg> apw, shall we test the theory ?
[12:36] <rtg> I'll wait to see if ogasawara has anything in the pipeline
[12:39] <apw> works for me
[12:52]  * henrix -> lunch
[13:08] <tyf> any guide for troubleshooting complete lockups? i am using Precise
[13:09]  * smb suggest big hammer. Does not help the lockup but one feels less troubled afterwards...
[13:10] <smb> Otherwise maybe https://wiki.ubuntu.com/Kernel/CrashdumpRecipe helps
[13:14] <tyf> hmm, i will give it a try.
[13:17] <tyf> I don't have kernel panic/oops, will LKCD works with complete lockups? Why the NMI watchdog doesn't kick in and produces a oops when lockup happens?
[13:27] <arges> smb, hey, I have a xen question for you
[13:27] <smb> arges, Yup, wassup? :)
[13:28] <arges> smb, i've been trying to verify a patch for eglibc for lucid/oneiric domU 
[13:28] <arges> smb, my machine has avx extensions, but if I boot with the xen dom0 kernel (raring) i don't see that cpu flag after booting
[13:29] <arges> unfortunately i need that extension to be present to actually reproduce the bug and verify
[13:29] <smb> arges, What dom0 are you using (and or hypervisor version)
[13:29] <smb> Oh, so raring dom0?
[13:29] <arges> yes
[13:29] <arges> smb, i assume all the patches are in ubuntu-raring.git ? or do I need to look elsewhere
[13:29] <smb> Unfortunately the xen4.2 packages are still stuck in proposed...
[13:30] <arges> i could enable proposed and check
[13:30] <smb> I think passing throught the xsave flags depends on the hypervisor
[13:30] <smb> arges, Give me a sec to check whether I still got some test builds around
[13:30] <smb> arges, Youdontwantproposedinraring!
[13:31] <arges> i thought i had tried xsave=1... trying it again this morning
[13:32] <rtg> hmm, it seems that the Lucid network manager really doesn't like a 3.7 kernel. dhclient can't create an addrlist socket.
[13:33] <smb> AFAIK it also requires the hypervisor itself to set osxsave correctly and I am not sure that already was done in xen 4.1.3
[13:33] <arges> smb, so are the xen packages custom patched kernels? where would i find the git tree for the hypervisor?
[13:33] <smb> arges, try to wget the packages from https://launchpad.net/ubuntu/raring/+source/xen/4.2.0-1ubuntu2
[13:34] <smb> arges, No, there is two parts: dom0 is a normal kernel that also works as dom0 kernel
[13:34] <smb> arges, But the dom0 is just a specially priviliged guest started by the hypervisor 
[13:35] <smb> Which is the gz file you see booted via multiboot in grub
[13:35] <arges> so the hypervisor is the OS that has all the (XEN) messages flying by?
[13:35] <smb> arges, yep
[13:35] <arges> ok
[13:35] <smb> arges, which you can recheck with "xm dmesg" as long as we still use the xm stack
[13:36] <smb> Last time I was looking at xl it said "not implemented" to that
[13:37]  * smb has slight issues listening to his own thoughts while his neighbours seem to convert a concrete wall into swiss cheese
[13:37] <arges> installing 4.2 now 
[13:38] <smb> arges, note that when installing in parallel you will end up with xen-4.1 and xen-4.2 selectable from grub
[13:40] <arges> smb, yup i'll select that from there. running it on a laptop : ) 
[13:40] <smb> arges, :) Why not as long as it has virt extensions enabled.
[13:41] <smb> ...and you got enough memory as that cannot be overcommitted
[13:41] <arges> it actually heats up the laptop quite a bit
[13:42] <smb> In theory it should do freq scaling and pm from the hypervisor (though you could check with xenpm)
[13:42] <smb> But I think it does not use more than c2 for some historic reason
[13:42] <smb> at least before xen 4.2 again
[13:43] <smb> So maybe that gets better (or worse) as well
[13:43] <arges> we'll see! 
[13:43] <ogasawara> rtg: +1 for an upload today.  want me to prep it or do you?
[13:47] <rtg> ogasawara, I'm most of the way there. gimme a bit.
[13:48] <arges> smb, woo hoo 4.2 boots fine and i have the proper cpu flags
[13:49] <smb> \o/
[13:49] <arges> smb, thanks
[13:49] <smb> welcome
[13:57] <rtg> apw, while I'm doing the upload would you have a look at 'UBUNTU: [Config] install-arch-headers needs a valid config' to make sure I'm not on crack. its always aufs_type.h that breaks the packaging, and having a valid config seems to fix the problem (which sort of makes sense)
[13:59] <cafetiere> Will do shortly, though the description makes sense enough on its own
[13:59] <cafetiere> Rtg ^^
[13:59] <rtg> cafetiere, is there a simpler way to choose a config flavour ?
[14:00] <cafetiere> Not at my keyboard right now, will c heck when am
[14:02] <ogra_> janimo, should bug 1073499 and bug 1073840 be reassigned to the kernel team or do you actually work on it ?
[14:02] <ubot2> Launchpad bug 1073499 in ubuntu-nexus7 "please consider turning on all possible modules for external USB devices" [Medium,Confirmed] https://launchpad.net/bugs/1073499
[14:02] <ubot2> Launchpad bug 1073840 in ubuntu-nexus7 "Sync kernel configuration with the one from the Ubuntu kernel" [Medium,Triaged] https://launchpad.net/bugs/1073840
[14:04] <rtg> ogasawara, ^^
[14:07] <ogasawara> ogra_: janimo is doing the nexus7 config review, so it would seem to me he is the right assignee
[14:07] <ogra_> k
[14:07] <ogra_> just going over the buglist :)
[14:25] <janimo> ogasawara, last I heard apw took a config I pasted him and said he'd do an initial review/merge with the existing tools
[14:28] <vanhoof> janimo: we'd agreed you do the initial pass, yeah?
[14:29] <apw> janimo, i was indeed going to get the review tools to work on it, i got sidetracked onto making it produce some update lists for this kind of thing
[14:29] <janimo> vanhoof, yes and apw asked for a config from me to do it himself last week
[14:29] <janimo> when I asked what to do re the initial pass
[14:30] <janimo> apw, no worries as long as we're all on the same page :)
[14:30] <vanhoof> fair enough :)
[14:30] <apw> so i believe i am producing a review for that flavour, which someone will then have to apply
[14:31] <janimo> apw, ok
[14:31] <apw> but i also hope the new tooling which has come out of this will give us a list of expected values you can just 'shove in'
[14:36] <apw> rtg, you are using the first flavour yes?
[14:37] <apw> rtg, there is an incantion for that for the autopkgtest thing in debian/rules
[14:37] <apw> $(firstword $(flavours))
[14:37] <apw> you could do that on the rule
[14:40] <rtg> apw, cool. I'll change to that
[14:41] <apw> rtg, though i conceptually wonder if you should actuall be deping on the prepare-$(first_flavour) sort of thing
[14:41] <arges> smb, hmm can't install oneiric domU's onto xen, looks like drivers for disk/networking are missing. who should i file a bug against? 
[14:41] <apw> rtg, as it clearly works some of the time and not others, so something in parallel must make what it needs in that case
[14:41] <smb> arges, xen_emul_unplug=never
[14:42] <arges> smb, is this in a wiki somewhere?
[14:42] <apw> rtg, but for now if that works, ship it and we can think about it later
[14:43] <smb> arges, maybe, though not that I would know how to find it... That actually should be in the release notes (if someone ever reads them)
[14:43] <rtg> apw, dep'ing on the prep stamp delays the header build (though not a lot). I could never figure out why the failure was intermittent.
[14:43] <arges> smb, and I assume this is a kernel boot option?
[14:43] <apw> rtg, i worry slightly about having the code to make a config in more than one place
[14:44] <apw> and if we could share it by using prepare-foo as a dependancy longer term that seems better
[14:44] <rtg> apw, agreed. lemme figure it out.
[14:44] <smb> arges, Right, yes, potentially only needed for installation but to be sure you would need to add xen_blkfront to the /etc/modules list
[14:45] <apw> smb, didn't we build all those in for you so that you didn't have to do that ?
[14:45] <smb> apw, Don't think for Oneriric and even less so for the install images
[14:45] <arges> smb, bug 839492 is related
[14:45] <ubot2> Launchpad bug 839492 in xen-tools (Ubuntu) "xen-blkfront module missing from initramfs, Ubuntu as DomU can't boot" [Undecided,In progress] https://launchpad.net/bugs/839492
[14:45] <arges> smb, and that single kernel option works fine : )
[14:46] <arges> on lucid it works without that option btw
[14:46] <smb> arges, Yes because on Lucid the server kernel had them built in
[14:48] <apw> smb, why did we unbuild them in if we need them for the boot images .. hmmm
[14:48] <apw> (assuming they didn't do it to themselves via renaming or something dumb)
[14:48] <smb> apw, Thinking of it I guess we build them in now for Oneiric and Precise but since O is no LTS the cd images never get updated
[14:48] <apw> smb, ahhh that would do it
[14:49] <smb> apw, I think we did not realized soon enough that they miss and either need to go into udebs or be built in
[14:49] <smb> And when we realized it was too late for IO
[14:49] <smb> *O
[14:55]  * herton hopes smb has some hearing protection ear plugs
[14:56]  * smb has not and is slightly going more insane than usual
[15:17]  * herton -> lunch
[15:33] <apw> herton, ok they should be building "now" modulo the rather large queue the zinc outage has caused
[15:33] <apw> herton, i assume we no longer need the herton/linux-stable stuff built ?
[15:39] <rtg> apw, please review the top 2 commits on raring master-next
[15:39] <apw> rtg, will do
[15:43] <apw> rtg, well it looks a hell of a lot less vile than the mess we had before
[15:43] <apw> rtg, and i thnk it does what you intend, though testing it would be the only way
[15:43] <apw> rtg, to know for sure.  which i assume you have done
[15:43] <rtg> apw, in progress. seems to be building OK
[15:43] <apw> it looks much more sane by the end there
[15:46] <apw> rtg, and better yet it won't even break lowlatency
[15:47] <rtg> apw, well, it does not appear to have completely solved the problem. wtf ?
[15:47] <rtg> unifdef: can't open /home/rtg/ukb/raring/i386/master-next/ubuntu-raring/debian/tmp-headers/install/include/linux/aufs_type.h.tmp: No such file or directory
[15:48] <rtg> what is unidef ?
[15:48] <apw> unifdef is part of the kernel installer, it removes the #ifdef _KERNEL_ bits from headers etc
[15:50] <rtg> ah, helps if I spell it correctly
[15:50] <herton> apw, thanks. Keep linux-stable stuff for now, it's the prestable, I have to work on it to move to mainline-build
[15:51] <apw> herton, well they are being built daily already
[15:51] <apw> in theory
[15:52] <herton> apw, yep, that's good, I'll submit more changes to you to enhance it and so I can stop doing the prestable builds myself
[15:52] <rtg> apw, hmm, I wonder if its $(conc_level) ? why the hell didn't I see that to begin with.
[15:53] <apw> rtg, i think this is a bug in the kernel rather than us if anything
[15:53] <apw> rtg, i conjecture it is making the directories in parallel with installing the headers
[15:53] <rtg> yep, which is why I only see it on raring
[15:54] <arges> apw, hey looking at bug 1075181 (efi/secureboot for precise). colin says that most of it is in place,  but a few packaging fixes are needed, anything I can help with ? or help test?
[15:54] <ubot2> Launchpad bug 1075181 in ubuntu-defaults-builder (Ubuntu Precise) "Backport UEFI Secure Boot support for Ubuntu 12.04.2" [High,Fix committed] https://launchpad.net/bugs/1075181
[15:59] <apw> herton, any idea how close to releasing linux-lts-quantal into -updates -- as once it is there i would like to slip a tiny packaging change in between your cycles
[15:59] <apw> herton, for secure-boot support
[15:59] <herton> apw, it's on testing right now, let me look
[15:59] <apw> herton, thanks
[16:00] <herton> apw, waiting on QA only, jjohansen already did security signoff, so once QA tests it (this is the testing week), it is good to go for -updates
[16:01] <apw> herton, ok excellent
[16:07] <jsalisbury> **
[16:07] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:07] <jsalisbury> **
[16:15] <apw> herton, is the next SRU cycle the last one before 12.04.02 or is there one more do you know
[16:15] <herton> apw, no, may be bjf knows
[16:15] <bjf> apw, looking
[16:17] <bjf> apw, the cycle that starts the week of Dec. 27 is likely to be the 12.04.2 kernel
[16:17] <bjf> https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock
[16:17] <bjf> aps, ^
[16:17] <bjf> apw, ^
[16:18] <apw> that was what i thought you would be saying, my counting on that wiki said the same; thanks
[16:18] <apw> so anything in the tree by next monday ... yeeks
[16:18] <bjf> apw, no you have two cycles
[16:19] <bjf> apw, it has to be in the tree before Dec. 27th
[16:19] <apw> we cannot guarentee that that kernel will hit by the 10th can we ?
[16:20] <apw> that is only 2 weeks later
[16:20] <apw> plus we lose what 2 weeks for xmas and the shutdown ?
[16:21] <ogasawara> yeek, I was going by thee dec 27th kernel source freeze noted in that wiki
[16:21] <bjf> apw, i still think that kernel will be the one
[16:21] <apw> bjf, basically i am assuming the nov 27th cycle will release the week with the 20th dec in it, then there will be a gap, and week one will be jan 3rd
[16:21] <bjf> apw, we've not had a respin in quite some time
[16:22] <apw> ogasawara, well bjf seems happy we can get things in the next cycle
[16:22] <apw> so i am going to try and hit this one, and hope we can get another in for the things that miss
[16:22] <apw> thanks all
[16:22] <bjf> apw, ogasawara i'll make it happen
[16:24] <bjf> apw, ogasawara i'm also trying to scare vanhoof .. he seems unflappable right now though
[16:24] <ogasawara> bjf: heh
[16:25] <rtg> bjf, vanhoof is still trying to recover from holiday. of course he's unflappable.
[16:26] <rtg> apw, pushed a couple more on master-next. I think I'll quit obsessing about headers and move on to uploading raring for the precise backport.
[16:43] <apw> rtg, i am worried about these changes for the headers, these headers now rely on a config (whereas before they used defconfig) but on powerpc we do not have any flavours
[16:43] <apw> rtg, oh presumably we don't have any headers there either?
[16:43] <vanhoof> bjf: hey now :)
[16:43] <rtg> apw, how can it _not_ have flavours ?
[16:44] <apw> rtg, powerpc in master has no flavours
[16:44] <vanhoof> rtg: -ETOOMUCHTURKEY
[16:44] <rtg> apw, well, I don't think it generates headers anyway
[16:44] <rtg> vanhoof, :)
[16:44] <apw> rtg, we generate headers for powerpc linux-libc-dev
[16:44] <vanhoof> ogasawara: we should have some feedback on a couple machines for ya RSN :D
[16:45] <rtg> apw, but that comes from the master package, right ?
[16:45] <apw> rtg, which is why it used a defconfig (or did)
[16:45] <apw> rtg, right i am talking about the master package indeed
[16:45] <ogasawara> vanhoof: sweet, I'm going down a checklist right now trying to compare my test kernel with a drm-intel-nightly build
[16:45] <apw> rtg, you have just made the headers depend on a flavour config, right?
[16:45] <vanhoof> ogasawara: cool, the tree we spoke about last week should be in our hands tomorrow as well
[16:45] <rtg> apw, ok, since $(conc_level) was the root cause I can switch back to defconfig
[16:45] <ogasawara> vanhoof: good, I was curious about when we'd see that
[16:46] <vanhoof> ogasawara: yeah got feedback that its going through testing now and should have it no later than tomorrow
[16:47] <apw> rtg, 
[16:47] <apw> headers_dir := $(CURDIR)/debian/linux-libc-dev
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:56] <jsalisbury> ##
[17:10] <rtg> apw, ok, I think you're right that depending on a flavour will break ppc. I'm gonna re-upload with a corrected rule before BenC gets around to rebasing.
[17:11] <rtg> I also think powerpc will FTBS
[17:11] <ogra-cb> pessimist
[17:12] <apw> rtg it should, i thought we uploaded before that change though
[17:13] <rtg> apw, nope. '# Pick the first flavour from which to make a valid config'
[17:13] <apw> rtg, ack
[17:14] <rtg> apw, damn. no good deed goes unpunished.
[17:14] <apw> rtg, sadly indeed
[17:15] <apw> at least we caught it pretty early
[17:15] <apw> rtg, and if ben rebases on teh bad commit, _his_ upload will be ok
[17:15] <rtg> apw, true
[17:15] <apw> rtg, and britney will stop ours leaving -proposed
[17:16] <apw> as there would be no linux-libc-dev for ppc, so i think we are safe, but it will ftbfs on powerpc surely
[17:16] <rtg> apw, I'll get infinity to reject -4.10 as soon as I get an upload going. gotta redo -signed, right ?
[17:17] <apw> rtg, i don't t
[17:17] <apw> rtg, i don't think you need to reject anything ... the new ones will reject the old ones automatically, or replace them
[17:17] <apw> rtg, yes -signed is upload number specific
[17:17] <rtg> apw, ack
[17:18] <apw> rtg, let me know when you are done and i'll re-rebase lowlatency for sanity
[17:18] <rtg> apw, will do
[17:44] <rtg> apw, pushed
[17:50] <apw> rtg, ta, rebasing and buildtesting now
[17:51] <rtg> apw, I'm whooping up on tangerine
[17:52] <apw> heh there will be some howling in that lab
[18:18]  * rtg -> lunch
[19:13] <apw> rtg, you will be amused to find that the armhf build of your -4.10 build failed with the same headers failure you have hopefully now fixed
[19:13] <rtg> apw, saw that. I'm running -4.11 test build on my SabreLite (w -j4)
[19:19] <ogasawara> bjf: I was going to send the following announcement out -> http://pastebin.ubuntu.com/1392532/
[19:20] <ogasawara> bjf: however, I noticed some discrepancy between kernel freeze dates noted in https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule vs. https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule
[19:20] <bjf> reading
[19:22] <bjf> ogasawara, i don't think the dates make any difference really. it's which cycle will be the last before the release and that will start the week of the 27th
[19:22] <ogasawara> bjf: ack
[19:23] <ogasawara> bjf: if there are any edits you want me to make before sending, let me know
[19:23] <bjf> ogasawara, pgraner owns the schedules now so I guess he might be interested in the discrepancy (but probably not)
[19:23] <bjf> ogasawara, it looks good to me
[19:52] <apw> rtg, your powerpc just ftbfs again
[19:53] <apw> make: *** No rule to make target `/build/buildd/linux-3.7.0/debian/build/build-/.config', needed by `install-arch-headers'.  Stop.
[19:53] <rtg> apw, shit
[19:53] <rtg> apw, I think I'll unwrap the whole mess and start over
[19:53] <apw> ack
[19:59] <jsalisbury> kamal, is this a custom or test kernel that you built:
[19:59] <jsalisbury> ProcVersionSignature: Ubuntu 3.5.0-18.29+kamal11~DellXPS-generic 3.5.7
[19:59] <jsalisbury> kamal, I noticed that kernel was being used in bug 1075752
[19:59] <ubot2> Launchpad bug 1075752 in linux (Ubuntu) "My system froze for several minutes" [Medium,Incomplete] https://launchpad.net/bugs/1075752
[20:01] <kamal> jsalisbury: that is my Sputnik PPA kernel from https://launchpad.net/~canonical-hwe-team/+archive/sputnik-kernel ...
[20:01] <kamal> jsalisbury: but the backtrace doesn't look related to any of the sputnik changes
[20:02] <jsalisbury> kamal, ack.  Thanks for taking a look.  
[20:02] <kamal> jsalisbury: oh, I see the person reports the problem against 3.7-rc7 also.   this looks to me like they've actually got a hardware problem.   bad SSD?
[20:03] <jsalisbury> kamal, will that model of system always need to get it's kernel from your Sputnik PPA?
[20:04] <kamal> jsalisbury: no, the machine works fine with a regular kernel too -- the Sputnik PPA kernel just adds the touchpad driver and some backlight fixes
[20:04] <bjf> apw, Mainline Build announcements on the mailing list; do those announcements come out automatically or do you have to do them by hand?
[20:04] <bjf> apw, they are going to start triggering testing of those mainline kernels
[20:05] <kamal> jsalisbury: so yes, testing that machine with mainline kernels or stock ubuntu kernels is a valid thing to do (I do it all the time).   (and I don't see anything like the reported issues).
[20:05] <jsalisbury> kamal, ok, thanks for the info
[20:07] <apw> bjf, the ones for specific version tags right?  those are automated by the publication into public_html
[20:07] <bjf> apw, ack
[20:08] <bjf> apw, you can see an example here: http://kernel.ubuntu.com/testing/index.html     precise kernel with (Mainline.Builder) after it
[20:09] <bjf> apw, i should say, precise configuration
[20:12] <apw> bjf, nice, there are no results udner the name
[20:13] <bjf> apw, from there i got to: http://kernel.ubuntu.com/beta/testing/test-results/gonzo.2012-11-27_18-24-00/results-index.html
[20:13] <bjf> apw, did you click the link under the "ran" column?
[20:14] <apw> bjf, yeah the right hand ones work, its the machine name which not so much
[20:14] <bjf> apw, that's just supposed to tell you about the system the test was run on
[20:14] <bjf> apw, i could rethink that
[20:15] <apw> bjf, np
[20:15] <apw> bjf, so (Mainline.builder) is a person in this context
[20:15] <bjf> apw, correct
[20:16] <apw> bjf, do they expire off this front page?  or will we end up with millions
[20:16] <bjf> apw, it was the simplest way of distinguishing it from others
[20:16] <bjf> apw, i'm working on the expiration bit
[20:16] <bjf> apw, it's easy enough to do by hand right now (for me)
[20:17] <apw> bjf, looks great, and as always with these things one doesn't know if it works till it runs for a bit
[20:17] <bjf> apw, yup
[20:18] <apw> bjf, so you are testing the 'tags' mainline builds build and announce, that sounds good
[20:18] <bjf> apw, yes, and this same process will be the trigger for automatic kick-off of SRU cycle kernel testing
[20:18] <bjf> apw, so it will all me auto-magic
[20:19] <apw> bjf, from hertons emails, or is there an automagic one
[20:19] <bjf> apw, from herton/henrix emails to the ktml
[20:22] <apw> bjf, if thats all we have gotten then great, though perhaps we can shankbot to emit a reliable
[20:22] <apw> relaible email to trigger it
[20:23] <bjf> apw, henrix and i discussed that and it's on the todo list
[20:23] <apw> great, though i guess it emiting 'herton/henrix's email mgith kill two birds
[20:25] <herton> shankbot has or had some email hooks, yes can just be reenabled
[20:31]  * rtg -> EOD
[23:16] <phillw> Hi good people, a real quick check... does "init 6" still cause the kernel to restart the computer?
[23:49] <engla> sforshee: hi, I tested your brcmsmac patch series in the first version
[23:51] <engla> sforshee: I see on the ML there is a story about a blocked connection after a high bandwidth burst (i.e. youtube); I reproduce this with an Apple air port AP.