[02:54] <philipballew> is there a way to put a time stamp in my terminal so i can have it coenside with my var logs?
[08:33] <ogra_> [    0.270865] ns_cgroup deprecated: consider using the 'clone_children' flag without the ns_cgroup.
[08:33] <ogra_> [    0.270887] Initializing cgroup subsys cpuacct
[08:34] <ogra_> apw, any idea about that ? the server team is pushing for having CONFIG_NS_USER enabled for LXC (in my ac100 kernel) but i always see this message on boot here (on a .38 kernel)
[08:34] <ogra_> should we push the server guys to make LXC work with 'clone_children' ?
[11:15] <hydromet> Hello, I'm curious what "ppa" means in the text "kernel-ppa" in the context of Ubuntu?
[11:22] <apw> hydromet, kernel-ppa is just a username in launchpad and on kernel.ubuntu.com ... the user on which our original PPA was attached
[11:22] <apw> (before groups existed in launchpad)
[11:23] <hydromet> apw: thank you (I have a rule for myself that I'll never use acronyms or words that I don't know the meaning of) :-)
[11:24] <apw> like not passing a word you don't know in a book without looking it up
[11:24] <hydromet> I'm coming over from a mostly Mac OS X world (the domain of the Mach kernel courtesy of Avie Tevanian)
[11:24] <hydromet> indeed
[11:24] <ogra_> apw, did you see my ping in your backlog ?
[11:24] <apw> ogra_, nope
 [    0.270865] ns_cgroup deprecated: consider using the 'clone_children' flag without the ns_cgroup.
 [    0.270887] Initializing cgroup subsys cpuacct
 apw, any idea about that ? the server team is pushing for having CONFIG_NS_USER enabled for LXC (in my ac100 kernel) but i always see this message on boot here (on a .38 kernel)
 should we push the server guys to make LXC work with 'clone_children' ?
[11:24] <apw> backlog got lost when i packed my puter in case we had to run from the looting
[11:25] <ogra_> oh my
[11:25] <hydromet> apw: I would like to install Linux kernel 3.0 onto a Natty Narwhal system, is there any reason why I shouldn't be able to do so (knowing full well that things might break)?
[11:26] <apw> ogra_, well it sounds like they have some thing to look at their either way
[11:26] <ogra_> i'm surprised that went unnoticed
[11:26] <apw> ogra_, we have resisited CONFIG_NS_xxx on older releass cause they are poor back there and cause issues for others, i think we tried in lucid and failed just recently
[11:26] <apw> is it not turned on in oneiric though?
[11:27] <ogra_> it is a request of the server team for omap4 atm and they asked me to turn it on on my ac100 kernel (since they use that device in the server team for arm)
[11:28] <ogra_> thats what made me notice the message
[11:28] <ogra_> LXC is a critical feature for arm server afaik
[11:29] <hydromet> I plan to install 11.04 on an Apple Xserve (late 2006 with Xeon Woodcrests) ... but would like to avail of the 3.0 kernel if possible 
[11:29] <hydromet> btw Apple stopped selling the Xserve so I can imagine people who own them may want to run Linux on them in the future if they would like to move off of OS X
[11:29] <ogra_> (openstack needs some kind of v irtualization ... LXC is the only one we have thats usable from a preformance POV)
[11:30] <ogra_> stgraber, ^^^
[11:30] <apw> well i suspect you need the option either way no ?  i suspec the message is separate
[11:30] <ogra_> iirc there is a bug open for the omap4 side 
[11:30]  * ogra_ searches
[11:31] <ogra_> bug 787749
[11:31] <ubot2> Launchpad bug 787749 in linux-ti-omap4 "Missing configuration for LXC containers on omap4" [Undecided,Fix committed] https://launchpad.net/bugs/787749
[11:31] <apw> which seems to be already fixed
[11:32] <ogra_> but doesnt mention the deprecation at all either
[11:33] <ogra_> paolo only mentions the deprecation of CONFIG_SECURITY_FILE_CAPABILITIES
[11:49] <apw> ogra_, will investigate and get back to you
[11:49] <ogra_> k, i'll try to get info from stgraber too about the server team plans
[11:56] <apw> ogra_, ok the call is _gone_ in oneiric
[11:57] <apw> ogra_, so they need to react for oneiric
[11:57] <ogra_> gone ?
[11:57] <apw>     cgroup: remove the ns_cgroup
[11:57] <ogra_> aha, a 3.0 change ?
[11:57] <apw> in the 3.0 kernel that deprecation warning will become a failure as t
[11:57] <ogra_> k
[11:57] <apw> the code is gone.  and i believe we will have a 3.0 kernel right ?
[11:57] <ogra_> for omap4 we do
[11:57] <apw> so ... they need to react then
[11:58] <ogra_> yep
[11:58] <apw> ogra_, is that NS_USER or USER_NS
[11:59] <ogra_> user_ns  iirc
[11:59] <apw> ok that is already on in oneiric
[11:59] <ogra_> User namespace: missing	 CONFIG_USER_NS
[11:59] <ogra_> from the bug
[11:59] <apw> debian.master/config/config.common.ubuntu:CONFIG_USER_NS=y
[11:59] <apw> from the source tree
[12:00] <ogra_> right, but it wont help if the code is gone :)
[12:00] <apw> oh that is master
[12:00] <apw> USER_NS is different from the other deprecation thing
[12:00] <ogra_> aha
[12:21] <apw> ogra_, all of the options they are asking for are either already on or gone as far as i can tell (on ti-omap4)
[12:22] <ogra_> k
[12:22] <apw> ogra_, who is asking for this ?
[12:22] <ogra_> well, for the gone ones they might need to compensate
[12:23] <ogra_> server team ... specifically stgraber but i think you could also talk to Daviey 
[12:23] <apw> Daviey, ... should be awake ^^
[12:23] <ogra_> if he's noot been looted over night or something 
[12:24] <ogra_> these tv pictures are scary
[12:28] <apw> ogra_, it was bad last night.  first time i've packed for flight; even the IRA blowing the crap out of us with bombs was less scarey
[12:29] <ogra_> yeah, it really looks like 1944 
[12:33] <Daviey> o/
[12:33] <Daviey> ogra_: Fancy a new widescreen TV?
[12:33] <apw> Daviey, clealy not on fire then ... heh
[12:33] <ogra_> heh, same old one 
[12:33] <Daviey> Hmm
[12:33] <Daviey> I'm missing context?
[12:34] <Daviey> Is this the issue regarding the arm kernel not having certain config options on that we have on server?
[12:34] <ogra_> lxc requires CONFIG_USER_NS ... 
[12:34] <Daviey> Such as iscis?
[12:34] <Daviey> Yeah, there are a few we are missing
[12:34] <ogra_> with it enabled in .38 i get a deprecation warning on boot
[12:34] <ogra_> and apparently that deprecation was made more serious in 3.0
[12:34] <Daviey> ogra_: Why do i care about .38?
[12:34] <apw> Daviey, well FF is like now, so if you haven't asked for them soon you won't get them easily
[12:35] <ogra_> so that you might be missing bits and pieces for lxc in 3.0
[12:35] <Daviey> apw: There is already at least one bug i have seen
[12:35] <apw> missing as in the s/w requires feasures which have been deprecated since 2.6.27 and is now gone
[12:35] <apw> Daviey, could you point me to any you know of pls
[12:35] <Daviey> Hmm. Why aren't we seeing this on tradional arches?
[12:36] <apw> Daviey, you likely are, one of the things ogra_ says its using ... has gone in 3.0
[12:36] <Daviey> bug 820349
[12:36] <ubot2> Launchpad bug 820349 in linux "iscsi is not enabled in omap4 kernels" [Undecided,New] https://launchpad.net/bugs/820349
[12:36] <Daviey> apw: ^^
[12:37] <apw> Daviey, keep em coming
[12:38] <Daviey> apw: That is the only one i have come across.
[12:38] <Daviey> Please note, we only got our mitts on arm hardware last week.
[12:38] <ogra_> did you have ac100's months ago ?
[12:39] <ogra_> *didnt
[12:39] <Daviey> ogra_: Good point, but i don't think any of us got oneiric running on them yet.
[12:39] <ogra_> ah
[12:39] <Daviey> TBH, without a cat5 connector, the ac100's were difficult for what we were trying to do.
[12:39] <ogra_> well, upgrading should just work
[12:40] <Daviey> \o/
[12:40] <ogra_> the kernel supports all USB NICs our x86 kernels support ;)
[12:40]  * apw isn't going to be impressed if we are starting to test critical functionality the same week as FF
[12:40] <ogra_> the config was stolen from our tree 
[12:40] <Daviey> ogra_: odd, i did try a usb nic and it failed to work :/
[12:40] <ogra_> weird
[12:41] <ogra_> i have  three wired usb nics here two asix and one pegasus based, all three work fine
[12:41] <Daviey> apw: I agree, it's not the position we'd like to be in either.
[12:44] <Daviey> ogra_: just checked, it is an asix one. :/
[12:44] <ogra_> very weird
[12:44] <Daviey> 0b95:1780 ASIX Electronics Corp. AX88178
[12:44] <ogra_> well, try to upgrade to oneiric we have a new kernel there
[12:44] <Daviey> ogra_: sadly, i'm in Millbank this week - and it's back home.
[12:44] <ogra_> ah, bad
[12:44] <Daviey> i suck.
[12:45] <ogra_> nah, you dont 
[12:45] <apw> oh please let us beat on him a bit at least :)
[12:45] <ogra_> lol
[12:45] <ogra_> .oO( brits ... )
[13:06] <apw> Daviey, both of those iscsi options are already on ??
[13:09] <apw> Daviey, belay that, looking on the wrong version grrr
[13:42] <bjf> ##
[13:42] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[13:42] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[13:42] <bjf> ##
[13:53]  * smb feels weird receiving the reminder in the morning without seeing Brad type...
[13:55]  * tgardner thinks smb must be in TX
[13:56]  * smb thinks he is, too
[14:10] <jjohansen> smb: are you melting yet?
[14:10] <smb> jjohansen, Not as long as I stay inside
[14:10] <smb> (which is most of the day) 
[14:11] <jjohansen> smb: yeah I saw even lunch is there which might not be a bad thing
[14:11] <tgardner> jjohansen, are you headed there tomorrow?
[14:12] <jjohansen> tgardner: yeah, though I start traveling today, from my families back to portland and then fly out tomorrow
[14:13] <smb> jjohansen, Right, though you probably need to limit expectations. It was sandwiches yesterday. Not the worst I have seen but if it stays that way it could get a bit boring. :)
[14:13] <jjohansen> smb: good thing I will one be bored for two days then :)
[14:13] <smb> jjohansen, Yeah. :) was about to say that
[14:35] <apw> pgraner, did you test those ncq kernel at all?
[14:43] <apw> tgardner, i've pushed a couple of configuration changes to the oneiric/ti-omap4 kernel
[14:43] <tgardner> apw, ack. saw them go by
[14:47] <pgraner> apw, no not yet network failure here, I'm limping by until I can get a new router
[14:48] <apw> pgraner, wtf you are cursed man cursed
[14:54] <pgraner> apw, it was acting flaky and flashed the firmware and it bricked
[14:55] <apw> ouch
[14:57] <jpds> Could someone look at the touchpad bug at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/810327 ?
[14:57] <ubot2> Ubuntu bug 810327 in linux "Synaptics touchpad ceases functioning after suspend and resume" [Undecided,Confirmed]
[14:58] <jpds> Doing: SUSPEND_MODULES="psmouse" in unload_modules is a workaround to the issue.
[15:01] <apw> jpds, i've annotated it for fujitsu as its likely h/w specific and we don't want it dogpiled
[15:02] <jpds> apw: I have someone who has the issue on a Dell vostro v13.
[15:02] <apw> then mentioning that in the bug would have been helpful
[15:03]  * jpds went https://bbs.archlinux.org/viewtopic.php?id=66829 → bug #59867 → that bug.
[15:03] <ubot2> Launchpad bug 59867 in linux "Synaptics touchpad ceases functioning after suspend and resume." [Medium,Won't fix] https://launchpad.net/bugs/59867
[15:12]  * ogasawara back in 20
[15:37] <apw> tgardner, what do you think the chances of getting yet another quirk table into the atkd driver is
[15:37] <tgardner> apw, as an SRU ?
[15:38] <apw> upstream
[15:38] <tgardner> fiik.  who is the maintainer ?
[15:39] <apw> dimitry
[15:39] <apw> (input maintainer)
[15:39] <tgardner> possibly. get cnd to do it. he's got a good working relationship with him
[15:41] <apw> heh yeah perhaps so
[15:41] <tgardner> ogasawara, I sure thought I pushed the work I did last week to add packaging for tools/power/x86/turbostat and tools/power/x86/x86_energy_perf_policy. Do you remember ever having seen it?
[15:42] <apw> perhaps i should ask the question as to why all arches but x86 reset their keybaord by default
[15:42]  * apw never say anything for those tgardner
[15:42] <ogasawara> tgardner: I don't recall ever seeing it
[15:42] <tgardner> drat
[15:42] <tgardner> oh well, won't take but a little bit to recreate that
[15:43]  * tgardner must have been in a hurry to go rafting
[15:49] <cnd> apw, you too can have a good working relationship with dmitry for low *low* price of an email containing a patch!
[15:50] <cnd> boy, that sounds like a great deal to me!
[15:50] <cnd> :)
[15:50] <apw> heh
[15:55] <tjaalton> is there a master bug about the poweroff/halt issue, which prevents proper shutdown?
[15:55] <apw> tgardner, any idea why we have atkb as =y ?
[15:55] <apw> tjaalton, which of poweroff/halt doesn't work ?
[15:56] <tjaalton> apw: well, the one that was mentioned on the list too, where it was determined that 'halt' does the right thing now. the last message I see is "power down", but the system remains on nevertheless
[15:57] <apw> right the 'correct' behavior from halt is to stop without powering off
[15:57] <tjaalton> this is with choosing the shutdown option of the indicator menu
[15:58] <apw> well the correct test is does poweroff work, if not then its broken 
[15:58] <apw> ie if you do sudo poweroff does it power off, if not then thats a bug
[15:58] <tjaalton> ah ok, I'll try that
[15:59] <apw> if it works then the menu is likely broken ie using the wrong shutdown, if not then its likely a machine specific bug likely in the kernel or bios i guess
[16:00] <bjf> ##
[16:00] <bjf> ## Kernel team meeting in one hour
[16:00] <bjf> ##
[16:01] <tgardner> apw, re: atkb=y, I don't remember
[16:04] <tjaalton> apw: right, poweroff didn't work, so something weird going on
[16:05] <apw> tjaalton, so that normally means a bios bug, sometimes it can be worked around with a quirk
[16:07] <smb> Something to try there is to change the shutdown method in /sys from platform to shutdown (looking where exactly...)
[16:07] <smb> Ah here /sys/power/disk
[16:08] <apw> right i think there is also a like reboot=<letter> which can select which method
[16:08] <smb> apw, Though that is reboot
[16:08] <apw> point, hmmm
[16:09] <smb> apw, Master king got a vulcan death grip program in his treasure chest 
[16:09] <apw> yeah cking will know i am sure
[16:10] <tjaalton> hehe
[16:34] <hifi> there seems to be a problem with my system and 3.0.0, almost all kernels hang for a long time when I try to boot them (before "Starting up..." after grub) except -7
[16:35] <hifi> as there is no output to the dmesg log before that I can't really debug it very much
[16:35] <hifi> had some timeout issues with my USB mouse but booting with nousb just removed the usb messages from dmesg
[16:36] <hifi> and it seems to hang even with all my USB devices disconnected
[16:41] <hifi> the delay takes 1 minute and 50 seconds, where -7 boots around 1 second
[16:43] <apw> hifi i suspect comparison of the two dmesgs is the first step, so i'd say get a bug filed the latest kernel and include the -7 dmesg
[16:43] <hifi> if I look trough the dmesgs and see nothing that differs
[16:44] <hifi> I'll post the bug anyway of course
[16:44] <hifi> but there just ain't anything in the dmesg that points to it
[16:44] <hifi> as the seconds in the log start from 0 and end up around 7 when init gets a hold of the boot
[16:45] <hifi> oh well, the dmesg is so bulky these days I couldn't tell a clear difference
[16:49] <bjf> ##
[16:49] <bjf> ## Kernel team meeting in 10 minutes
[16:49] <bjf> ##
[16:51] <NCommander> apw: so LXC patches were dropped in 3.0? (followup to a conversation you had with ogra this morning)
[16:51] <Daviey> erk
[16:52] <apw> NCommander, the only thing i have said was that some of the things that LCX was requesting were deprecated in 2.6.27 i think it was and finally removed in 3.0
[16:52] <apw> _if_ ogra_'s testing was with the latest userspace
[16:53] <ogra_> i only ran the checkconfig script for stgraber and enabled the needed bits in my ac100 kernel
[16:53] <ogra_> what triggered me to ask initially was the warning in dmesg that USER_NS is deprecated
[16:53] <NCommander> ogra_: well, Cgroup namespace is known to be depericated and gone as of 3.0 though I can't tell if its actually needed for LXC
[16:54] <ogra_> NCommander, USER_NS is, thats the issue
[16:54] <apw> and user_ns still exists
[16:55] <ogra_> apw, you said it was fully deprecated now
[16:55] <apw> ogra_, i think we are getting confused
[16:56] <ogra_> [    0.270858] ns_cgroup deprecated: consider using the 'clone_children' flag without the ns_cgroup.
[16:56] <ogra_> that was the message that got me here 
[16:56] <apw> that thing is fully deprecated yes, _that_ is not USER_NS
[16:56] <ogra_> i only get that message since i enabled USER_NS
[16:56] <ogra_> and it was a single build i only did for that one option
[16:56] <apw> that may be because you are exiting earlier though
[16:57] <apw> that doesn't make it related to that option necessarily
[16:57] <apw> just means you get past the user_ns check and drop into that warning
[16:57] <ogra_> hmm, k
[16:57] <apw> (they may be related, but i am not sure you have any evidence of that)
[16:57] <ogra_> i dont have any evidence of anything but that warning message
[17:05] <jjohansen> ogasawara: just a heads up re: feature freeze jdstrand has already set up for an exception for apparmor dbus mediation and there may be another kernel patch on top of what I have for that.  Nothing definite yet, I won't be sure until I get into some more of the dbus patch with him next week
[17:05] <ogasawara> jjohansen: ack
[17:05] <hifi> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/823409 should contain everything?
[17:05] <ubot2> Ubuntu bug 823409 in linux "3.0.0 hangs for a long time when loading" [Undecided,New]
[17:06] <ogasawara> jjohansen: for the kernel we likely have a little more time, since kernel freeze isn't till Sep 15.
[17:07] <apw> bjf, link fixed in the build tools so should be right next week
[17:07] <jjohansen> ogasawara: oh it will be well before then, it needs to be in the next couple of weeks if the dbus mediation is going to go in.
[17:07] <ogasawara> jjohansen: cool, keep me posted.
[17:08] <jjohansen> ogasawara: will do
[17:08] <bjf> apw, ogasawara someone may need to cover the irc meeting next week for me (i we have one) as i'll be in london dodging the rioters 
[17:08] <ogasawara> bjf: ack, I can chair next week.
[17:09]  * sconklin read "meditation" and was trying to parse what dbus meditation might be like
[17:14] <jjohansen> sconklin: hehe, that is what happens when I mess up the code and dbus loops trying introspect where to send denied signals forever :)
[17:14] <sconklin> ommmmm
[17:18] <apw> sconklin, more sort of ommmmmmoops
[17:23] <bjf> apw, i was able to post to voices.canonical.com, maybe your access issues have been fixed as well
[17:44] <apw> bjf, yes i think that is true, i have not posted, but i have been able to get a lot further
[18:04]  * tgardner --> lunch
[18:34] <apw> ok i think i've had it for the day, they are threatening to burn down my shops again ... bah ... /me authorised the use of deadly force
[18:34] <tgardner> apw, be careful
[18:45] <kees> hggdh: sconklin and I would like more details on the hardy xen test. where are the prior test results, does it happen on multiple runs, etc?
[18:47] <hggdh> kees: I did not run multiple tests on this kernel/install (m1.small), I never do. 
[18:47] <hggdh> kees: all tests are saved to cranberry:/srv/qa.ubuntu.com/reports/kernel-sru/
[18:48]  * smb seems to have missed any results
[18:48] <kees> -bash: fork: Cannot allocate memory
[18:49] <hggdh> machine is dead...
[18:49] <kees> that doesn't seem like a healthly state for cranberry
[18:50] <herton> smb: bug 822967
[18:50] <ubot2> Launchpad bug 822967 in linux "2.6.24-29.92-xen: failure on QRT 'ASLR of mmap'" [High,New] https://launchpad.net/bugs/822967
[18:51] <hggdh> now not even opens a SSH session anymore
[18:51] <kees> hggdh: it would be interesting to run the m1.small-i386 again -- I'm not sure how to do that myself.
[18:51] <hggdh> kees: will do
[18:52] <kees> hggdh: okay, thanks. and if it fails again, is there some way I can log in remotely?
[18:52] <hggdh> kees: I can add you in the .ssh/authorized_users
[18:52] <kees> hggdh: cool
[18:53] <smb> kees, hggdh Yeah its strange. Unless this is a new test I thought I had been running those ok
[18:54] <hggdh> smb: yes, we had been
[18:54] <kees> smb: yeah, that test is unchanged for a long time now, and the verbose output on it looks like a real ASLR failure.
[18:54] <hggdh> previous saved tests for hardy m1.small: hardy-2.6.24-29.89-m1.small-i386.tar.bz2  hardy-2.6.24-29.90-m1.small-i386.tar.bz2  hardy-2.6.24-29.91-m1.small-i386.tar.bz2  hardy-2.6.24-29.92-m1.small-i386.tar.bz2
[18:54] <kees> it's _possible_ for it to fail, but the chances are extremely remote.
[18:55] <kees> so, I wanted to see if running it again would pass or fail. if it passes, then it's just bad luck, and I can add more cycles to the test
[18:55] <smb> Ok, yeah. 
[19:28] <lool> ogasawara: Ok, retested 10 kernels out of the 15 and the first 9 were correct, the 10th one was the first wrong result, probably my day-to-day system introduces way too many other random issues to be useful, but with a stable USB key natty setup, it's not likely to interfere again!
[19:29] <lool> ogasawara: Is this what you use to build kernels?  https://wiki.ubuntu.com/KernelMainlineBuildsCreator
[19:30] <ogasawara> lool: yep, the mainline-build-one script
[19:31] <ogasawara> lool: eg mainline-build-one <sha1> <series>, where series in this case is oneiric
[19:31] <lool> ok
[19:31] <lool> I have another bug to bisect where I might attempt to use it
[19:31] <ogasawara> lool: I'll use one of our build machines like tangerine or tyler
[19:31] <lool> but it's much more painful: I get wifi disconnect maybe every 10 minutes or so
[19:32] <lool> It might be due to background scans, but didn't confirm
[19:32] <lool> ogasawara: Ok; maybe it's best if we finish this one bug with you building kernels and me testing them
[19:32] <lool> plus, it kind of forces me to keep iterating  :)
[19:32] <ogasawara> lool: sounds good.  gimme a bit to get the bisect reset
[19:33] <lool> Yup; I'll keep an eye on the bug, time to get the kid in bed though
[19:33] <ogasawara> lool: ack, I'll post to the bug when I've got something
[19:33] <lool> bbl
[19:33] <lool> (thanks!)
[19:46] <hggdh> kees: one more run, another failure
[19:48] <hggdh> kees: seems to fail consistently
[19:48] <kees> hggdh: that's no good. what's the IP?
[19:48] <hggdh> kees: ec2-72-44-56-248.compute-1.amazonaws.com
[19:50] <kees> ASLR of mmap ... ok
[19:59] <kees> hggdh: ^^ looks like bad luck in the test. only thing I can think of is to lengthen the sample size
[20:00] <hggdh> kees: bad luck is my middle name :-)
[20:00] <kees> hehe
[20:01] <hggdh> kees: good -- we can chalk this one to cosmic rays
[20:01] <kees> I get 12 failures out of 10000 on the rekey test (the specific sub-portion that failed)
[20:01] <hggdh> er
[20:01] <kees> that seems correct based on vailable entropy
[20:01] <kees> *available
[20:01] <kees> i.e. roughly 1 in 1000 chance of repeated mmap location
[20:01] <hggdh> ah, thank you, was just going to ask you about the probability
[20:02] <hggdh> so we could change it so that it reports only if there is a spike
[20:02] <kees> well, I think I need to expand the check length. right now I test 50 times, allowing up to 2 failures
[20:03] <kees> er, allowing 1
[20:03] <kees> but it could fail more.
[20:03] <hggdh> 1 in 50 is already twice the average you expected
[20:03] <hggdh> 20
[20:03] <kees> yeah, but the "50" sample size is very low
[20:03] <hggdh> yes
[20:05] <hggdh> well. I have run, I do not know, a few hundreds of this test. This is the only failure I found
[20:05] <kees> okay, sounds good.
[20:06] <hggdh> so, by the law of large numbers, I was bound to get hit
[20:06] <kees> yeah. I'll adjust it a bit and commit it.
[20:06] <hggdh> and please add a comment asking for a rerun on failure
[20:06] <kees> okay
[20:07] <kees> that's actually a standing request for all the tests
[20:07] <hggdh> heh. Please be more vocal on these standing requests, I am partially deaf, and never heard it before ;-)
[20:08] <kees> hggdh: heh, okay, sorry. yeah, if you see a kernel test failure, it's worth it to run it again and verify it fails twice the same way
[20:08] <hggdh> roger wilco
[20:10] <hggdh> kees: so, can I shutdown the EC2 image?
[20:11] <kees> hggdh: yup, thanks. I'm all done now. just finished double-checking.
[20:11] <hggdh> thank you
[20:24] <hggdh> bjf: well, Lucid is out of the way also, just -passed it
[20:28] <bjf> sconklin, herton, ^
[20:29] <sconklin> bjf: well. That's a relief.
[20:29] <sconklin> hggdh: thanks!
[20:30] <herton> nice. I think we can prepare hardy now, and go on with lucid also once it get copied to -updates