[07:10] <smb> Morning
[07:21] <brendand> cking - hi
[07:21] <cking> brendand, hiya
[07:23] <brendand> cking - it seems (without my knowledge) we've recently started using fwts for suspend testing. now the problem is we're using --s3-device-check and it's generating failures
[07:23] <brendand> http://paste.ubuntu.com/1060316/
[07:25] <brendand> cking, i'm going to assume those errors aren't that severe - in that they won't stop anything from working
[07:25] <cking> brendand, first rule of computing, assume nothing
[07:25] <cking> let me look at those errors
[07:27] <cking> if we just run a test, and it produces and error and we just assume its OK then why do we bother testing? ;-)
[07:27] <cking> s/and error/an error/
[07:30] <cking> brendand, file a bug as it looks like a bug with the way the APIC is being handled, which could be a problem
[07:34] <brendand> https://bugs.launchpad.net/ubuntu/+bug/1017841
[07:34] <ubot2> Ubuntu bug 1017841 in ubuntu "[Thinkpad Edge 15] register is already in use for vector 0xf9 on another cpu" [Undecided,New]
[07:42] <brendand> cking, any idea if it's something we have even the smallest chance of getting an imminent fix for? or is it a fw issue and we'll have to live with it for now
[07:42] <brendand> ?
[07:43] <cking> brendand, from a cursory view of the kernel source I believe it's a firmware issue
[07:43] <brendand> cking, okay thanks. that affects how we'll have to deal with this issue, so good to know
[07:44] <brendand> cking, the problem we have is that other certification tests depend on the suspend test to run and pass, so unless we're going to consider this issue has enough to fail certification, it's sort of scuppering our testing
[07:44] <brendand> cking, we may just have to change the test definition to something less strict
[07:45] <brendand> cking, any idea how to ignore those kinds of failures?
[07:45] <cking> how about "fwts --test-and-pretend-it-is-okay"?
[07:46] <brendand> cking, i understand and at a fundamental level agree with what you're saying
[07:46] <cking> brendand, as it is, the kernel is complaining that the firmware is broken, so it is a fault.  Do you want a S3 test pass to me "it suspends and resumes and we don't care about kernel error messages?"
[07:47] <cking> s/me/with/
[07:47] <cking> bah, what's wrong with my brain today
[07:48] <brendand> cking, well we don't want to be ignoring potentially serious issues, but at the same time we don't want to be failing systems left and right because of some shoddy bios engineering
[07:48] <brendand> cking, we have certain things that need to work and if they do then it's certified
[07:49] <brendand> cking, unless that changes then we can only be so strict
[07:49] <cking> it depends on one's definition "of need to work"
[07:49] <brendand> cking, it certainly does! tell me about it
[07:49] <cking> for fwts, it is to catch all stupid errors, and pick up any errors that the kernel warns about.
[07:53] <cking> ..so it is geared up for the enablement engineers to be really pedantic
[07:55] <brendand> that's good
[07:56] <brendand> we're a lot more liberal over here in certification land
[07:57] <brendand> so to answer your earlier question, if the system resumes and all the functionality which is required for certification is working then yes, we should consider the suspend was succesful
[07:57] <cking> even though the kernel was screaming about some failed APIC config?
[07:58] <cking> gawd help us
[07:58]  * apw blinks
[07:58] <brendand> just for kicks, what's a potential manifestation of this problem - user side
[07:58] <brendand> ?
[07:59] <cking> brendand, no idea, I've not got enough data in the bug report yet, and this needs some effort to look at
[07:59] <ppisati> moin
[08:00] <brendand> cking, ok. i hope you understand that i'm not in disagreement with you, but the definition of certification is not made at my level so there are other people to convince
[08:01] <cking> brendand, sure, I understand, somebody needs to make a value-judgement on this
[08:01] <brendand> information such as 'these errors could cause X' is helpful
[08:02] <cking> sure, but for this kernel message, I've not seen it before, so fwts can't advise automatically
[08:02] <cking> hence it flagged it up as something that should grab somebody's attention to look into
[08:10] <apw> henrix, you dissappeared
[08:19] <brendand> cking, just heads up that i don't seem to be able to hit launchpad from the system. i'll get you the logs some way or another asap
[08:20] <cking> ack
[08:20] <brendand> cking, oh and since the bug is package-less and you're asking for apport-collect, is that going to work? or would you like me to put it to the linux package?
[08:21] <cking> true, can you attach the kernel log, and output from "sudo acpidump" to the bug report?
[08:23] <brendand> cking, that'll be easier
[08:23] <brendand> cking, i'm on it
[09:15] <xnox> I am reading KernelUpdates page and I didn't understand this: $DEITY
[09:15] <xnox> what does $DEITY mean?
[09:16] <apw> xnox, your god of choice
[09:16] <xnox> apw: ah, marvin from hitchhicker's guide to galaxy. Ok.
[09:16] <apw> there you go :)
[09:18] <xnox> Any chance of me intruding kernel-ppa with hardware enablement SRUs? =)
[09:18] <xnox> In particular mdadm with support for DDF and Intel Matrix Raid?
[09:19]  * xnox is going via SRU currently, as it is 'user-space'. But I am pondering, if kernel-ppa is a better match
[09:19] <xnox> and updates to the e2fsprogs
[09:20]  * smb would not think this to be appropriate for the kernel-ppa.
[09:20] <apw> xnox, the kernel-ppa doesn't avoid the SRU process, I think the document you are reading is the one which defines the pre-approved variance of the common SRU policy for the kernel
[09:20] <apw> but that was taken to the DMB for those specific packages
[09:21] <xnox> hmmm
[09:21] <smb> And frankly I was not really happy with how the mdadm support worked with the versions I saw... Usually the raid seems to come up read-only.. :/
[09:21] <xnox> I am working on ReliableRaid spec and bugs
[09:22] <xnox> I want to push these bugs: https://bugs.launchpad.net/ubuntu/precise/+source/mdadm
[09:22] <smb> xnox, Isn't that targeted for Quantal?
[09:22] <xnox> as an SRU
[09:22] <xnox> smb: not if update-initramfs segfaults on precise & udev rules lack picking up Intel Matrix Raid and DDF formats and other things
[09:23] <xnox> look at the bug list: https://bugs.launchpad.net/ubuntu/precise/+source/mdadm
[09:23] <xnox> Me and slangasek kind of agreed that critical stuff should be SRUed for 12.04.1
[09:23] <smb> xnox, Yes, that is sort of why we still cling to dmraid
[09:23] <xnox> and we shouldn't.....
[09:24] <xnox> Intel itself recommends to use mdadm with their raid format......
[09:24] <smb> Agreed if we can really replace it
[09:24] <xnox> well, it's too early to replace it =) since I didn't fix it all yet ;-)
[09:25] <xnox> So shall I upload into precise-proposed and see what the SRU team says, or will you, kernel team, are interested in taking this update for testing in the kernel-ppa
[09:25] <smb> Yes, and also I was never sure whether IMSM and DDF are all that is out... compared to formats that dmraid would probably know
[09:25]  * xnox doesn't know what type of users you have.
[09:25] <smb> xnox, Yes, for SRU approach the ppa would not help you any way
[09:26] <xnox> ok.
[09:26] <xnox> To be honest I haven't looked at the state of dmraid yet.
[09:26] <xnox> I am expecting a small can of worms =)
[09:27] <smb> Heh, well I am certainly not doing exhaustive tests there, but at least it does allow me to access an MSM raid5
[09:27] <smb> But since the user-space relies on a not-really-supported anymore kernel module it is the right path to go forward with mdadm
[09:28] <xnox> Hmm... the new mdadm udev rule with try to assemble Intel Matrix Raids......
[09:28] <xnox> Which is part of this upcomming SRU.....
[09:29] <smb> So I may be early to notice when having -proposed enabled
[09:29] <smb> (which I should do)
[09:29] <smb> (if I have not already)
[09:31] <smb> xnox, Btw, last time I tried with Q there was an issue of the installer accessing the md raid and blowing up because at that time the array was read-only and the kernel did not like that
[09:31] <smb> I wanted to get back at it but got disctracted then
[09:32] <xnox> hmmm... I didn't hit that in my testing
[09:33] <xnox> mdadm is not in proposed yet. I'm just hovering over debsign && dput right now
[09:33] <xnox> still need to do some more testing first.
[09:33] <xnox> oh, no I don't. I did that yesterday
[09:33] <smb> xnox, sure, just for reference bug 1008479
[09:33] <ubot2> Launchpad bug 1008479 in linux "kernel BUG at /build/buildd/linux-3.4.0/drivers/md/md.c:6958" [Medium,Triaged] https://launchpad.net/bugs/1008479
[09:35] <smb> And for me there was also the problem that mdadm seemed to have set up the raid even before the installer asked about it. But I need to go back there with a2
[09:36] <xnox> smb: partman-auto-lvm (43) unstable; urgency=low
[09:36] <xnox>    [ dann frazier ]
[09:36] <xnox>    * Call update-dev --settle between creating lvs and accessing them
[09:36] <xnox> .... workaround or fix?
[09:37] <xnox> this is merged and will be part of alpha2. So if you could test there it would be wonderful
[09:37] <xnox> also the new mdadm is in alpha2 as well
[09:37] <xnox> which should work with IMSM, which I do not have access to
[09:38] <xnox> smb: well not the installer setup raid, but udev rules kicked in is my guess
[09:38] <smb> xnox, Hm, potentially not related. I must admin I am not really understanding why the raid is ro at that moment. It seems in a odd way related to be brought up in initrd. When I (hopefully in the same way) do it later it ends up in auto-ro which autimatically because rw later...
[09:39] <smb> *admit
[09:39] <smb> Oh bugger, my fingers do not seem to type what I think...
[09:39] <smb> *automatically become rw later
[09:41] <smb> xnox, But any way, it is likely the udev rules, just somewhat in an unexpected way. Probably needs some thought in the installer too
[09:42] <smb> Since back then this cause the question to be futile. Even when I said no, mdadm had set up the raid and caused the bug
[09:43] <smb> I try to keep that tracked as bug 1008423
[09:43] <ubot2> Launchpad bug 1008423 in debian-installer "Activate Serial ATA RAID devices dialog likely not working as expected" [Undecided,New] https://launchpad.net/bugs/1008423
[09:47] <xnox> smb: well I can't say anything about bug 1008423
[09:47] <ubot2> Launchpad bug 1008423 in debian-installer "Activate Serial ATA RAID devices dialog likely not working as expected" [Undecided,New] https://launchpad.net/bugs/1008423
[09:47] <xnox> let me check the upload history
[09:49] <smb> xnox, Yeah, I did not expect you to. Just as a pointer, while you are working on that topic... And maybe something to have in mind when doing tests...
[09:50] <xnox> smb: well the new mdadm with ISMS udev rules was uploaded on 2012-06-22 21:03:50 BST, but you filed the bug before that.
[09:50] <smb> It could be something that happened before since I usually updated the machine and did not reinstall. And there also was the "bug" of the dmraid kernel module not being build
[09:50] <xnox> is there any way I can get remote-hands access to ISMS to do some installer testing / interaction?
[09:51] <xnox> or are you going to be testing alpha2 on the ISMS
[09:51]  * xnox ISMS or IMSM well I bet you understood ;-)
[09:52] <smb> xnox, Sure. :) Yes, I plan to get back to that testing with a2. Fingers crossed and knocking on head
[09:58] <xnox> good luck & don't forget your towel ;-)
[09:59] <apw> (arch armel & value y) | value m
[09:59] <apw> (arch armel & / value y) | value m
[09:59] <apw> (arch armel & cur & value y) | value m
[09:59] <smb> xnox, :) One always needs to know where that is...
[10:02] <apw> (arch armel & ^ & value y)
[10:03] <apw> (arch armel ^ value y)
[10:04] <apw> (arch armel &^ value y)
[10:04] <apw> (arch armel / value y)
[10:05] <apw> (arch armel &/ value y)
[10:09]  * xnox please stop serving alphabet soup to apw. he's had enough!
[10:09] <apw> heh
[10:53] <dhana013> Hi
[10:54] <dhana013> Hi Guys I accidentally deleted my .config for my kernel configuration on Linux, and seem to remember there was a way to retrieve the kernel configuration via the proc filesystem somehow.
[10:54] <dhana013> In debian filesystem /proc/.config
[10:55] <dhana013> i can't see the .config in /proc directory please guide me
[10:58] <ppisati> brb
[10:59] <henrix> dhana013: if you're kernel has been configured to include it, it should be /proc/config.gz
[11:00] <henrix> dhana013: there's also a script that allows to extract that info from a kernel image
[11:01] <dhana013> henrix, I am using ubuntu 10.04 not seen /proc/config.gz file
[11:01] <henrix> dhana013: are you running a customised kernel? or the 10.04 kernel?
[11:01] <dhana013> henrix, please tell the script name, give script download location
[11:02] <dhana013> henrix, no
[11:02] <ogra_> dhana013, it is in /boot by default
[11:02] <ogra_> at least if you use an ubuntu packaged kernel
[11:02] <dhana013> ogra_,  soory I accidentally deleted
[11:02] <dhana013> ogra_, /boot/config file
[11:04] <henrix> dhana013: ok, so probably the easiest way is to just re-install the kernel pkg
[11:04] <ogra_> you could just "apt-get install --reinstall  linux-image-$(uname -r)" ... and it will magically come back
[11:05] <dhana013> thanks henrix ogra_ i try
[11:05] <dhana013> henrix, any script available find extract info current kernel
[11:06] <henrix> dhana013: yes, it's available on the kernel sources, in the scripts directory
[11:06] <henrix> dhana013: but to use it your kernel has to be built with a specific config option (can't remember the option atm)
[11:07] <dhana013> henrix, thanks I see the script directory lot of script there, I find out
[11:25] <brendand> cking, this issue is interesting because it's happening across lots of different BIOSes : http://paste.ubuntu.com/1060586/
[11:43] <xnox> random question: why does lsmod | grep ipv6 doesn't output anything?
[11:43] <xnox> or is the ipv6 module 'built-in'
[11:49] <henrix> xnox: if you grep the config file, you get CONFIG_IPV6=y
[11:49] <henrix> xnox: you're grep will probably return some output if you have NF modules loaded
[11:49] <xnox> henrix: ok, just hunting down an ipv6 bug in one package's testsuite
[12:38] <dhana013> Guys any documentation available understand linux kernel configuration
[12:39] <apw> dhana013, henrix, there is an option to burn the config into the kernel, but it just wastes memory given we can just ship it in /boot, as ogra_ says you can just reinstall your kernel package from /var/apt/cache and get it back
[12:41] <dhana013> apw, I want to do custom kernel configuration any documentation available understand linux kernel configuration
[12:41] <ogra_> apw, heh, your memory arg is funny .... the platforms with the lowes memory have the feature on in ubuntu (arm)
[12:41] <apw> dhana013, not really, every option is documented in the kernel itself, in the help options
[12:42] <apw> ogra_, you do?  why would you do that, thats mad
[12:42] <ogra_> userfirendlyness ... many complained in the arm world that their scripts dont work without it etc
[12:42] <apw> they are so full of poo
[12:42] <ogra_> though thats quite a while ago
[12:43] <apw> ogra_, what is the option even called
[12:43] <ogra_> we could try again to switch it off
[12:43] <ogra_> ugh, dont remember
[12:43]  * ogra_ checks
[12:43]  * apw either sigh
[12:44] <apw> debian.master/config/config.common.ubuntu:# CONFIG_IKCONFIG is not set
[12:44] <apw> ogra_, i think its not on any more
[12:44] <apw> CONFIGS/armhf-config.flavour.omap4:CONFIG_IKCONFIG=y
[12:44] <apw> CONFIGS/armhf-config.flavour.omap4:CONFIG_IKCONFIG_PROC=y
[12:44] <apw> oh it is on omap4 ... sigh
[12:44] <apw> but not on omap3
[12:45] <ogra_> ogra@panda:~$ ls /proc/config.gz
[12:45] <ogra_> /proc/config.gz
[12:45] <ppisati> it's been like this since M/omap4
[12:45] <ogra_> even before i think
[12:45] <ppisati> and no one complained
[12:45] <ogra_> no, they complained that it wasnt there before :)
[12:45] <apw> thats cause we have never done a proper config review for omap4 ... obviously
[12:46] <ogra_> but nowadays they can take linaro kernels if they want such extra options
[12:46] <apw> n
[12:46] <apw> Inconsistent policy=n not required as configs in /boot
[12:46] <ogra_> so i think we can disable it for quantal
[12:46] <apw> indeed now i have omap4 in the config review matrix, it even throws and error :)
[12:46] <ogra_> throw it back :P
[12:47]  * ppisati is doing the config review for omap4, but didn't met that option yet...
[12:48] <apw> ppisati, yep its a year of your life and no mistake
[12:49]  * ppisati preps another coffee...
[12:49] <ppisati> ogra_: btw, just sent last round of patches for omap3, after these kernel should be back in shape
[12:50] <ogra_> yay
[12:50] <ogra_> will there be another upload before the milestone ?
[12:50] <apw> i beleieve we are holding waiting for those patches indeed
[12:50] <ogra_> awesome !
[12:52] <apw> they'd better work tho :)
[12:54] <apw> ppisati, do you really want your gmail addy in that commit ?
[12:59] <ppisati> apw: wait
[13:00] <ppisati> apw: i'm subscribed to lkml&c with my personal address
[13:00] <rtg> apw, its just his Reported-by: address
[13:01] <apw> ppisati, yep, just wondering if you wanted that in the history as it is right now
[13:01] <apw> rtg, indeed, he might not want it there, just checking
[13:01] <rtg> I can always fix it up and repush
[13:02] <apw> yep, and it was just to get him to decide that i brought it up :)
[13:07] <ppisati> no problem
[13:07] <apw> ogasawara, as we have scheduled a config review post v3.5-rc1 at sprint i've closed that 'schedule config review' WI
[13:08] <ogasawara> apw: you read my mind :)  was on my list to tick off today.
[13:14] <ogasawara> apw: am just getting one last Alpha2 fix in for bug 1017879, and will pull in ppisati's patches then quick build/boot test and upload
[13:14] <ubot2> Launchpad bug 1017879 in debian-installer "External USB keyboard stops working when d-i starts" [Critical,Confirmed] https://launchpad.net/bugs/1017879
[13:15] <rtg> ogasawara, um, I think I already pushed them
[13:16] <rtg> runnign armhf build test right now
[13:16] <cking> yay, ISO testing time again
[13:17] <ogasawara> rtg: awesome, thanks
[13:40] <ogasawara> rtg: did that schroot issue on gomeisa ever get sorted
[13:41] <rtg> ogasawara, um, which one? my memory is only 2 days long.
[13:41] <ogasawara> rtg:  where builds would fail with some permission denied error
[13:42] <rtg> ogasawara, uh, maybe. I think I reinstalled since then.
[13:42] <rtg> ogasawara, I'm sure you'll tell me if its still an issue :)
[13:44] <ogasawara> rtg: I seem to have just hit it again
[13:44] <rtg> ogasawara, drat. lemme check
[13:44] <ogasawara> rtg: full build log in my home dir under quantal-i386/build.log
[13:46] <rtg> ogasawara, hmm, I wonder if messing about with sbuild might have done it. apw - are you using sbuild on gomeisa ?
[13:50] <apw> rtg, at this instant no
[13:50] <rtg> apw, ok, I'm gonna scrub sbuild and the chroots and start over
[13:58] <apw> rtg works for me
[13:58] <apw> we had that bad sbuild version installed for a while didn't we
[13:58] <rtg> apw, thats good :) 'cause its mostly gone....
[13:59] <rtg> apw, yeah, I removed sbuild and am rebuilding the quantal chroots
[14:30] <smb> sforshee, Hm, could it be that we caused some weird result in our competing updates to the blueprints? This looks a bit weird...
[14:31] <sforshee> smb, that one's been weird. I think my last update only changed the part that I wanted it to though...
[14:32] <smb> sforshee, I believe the overall sequence caused me to have two items now with the same name... /me wonders whether rtg suffered from that multiple times...
[14:33]  * rtg suffers from an excessive number of duplicates
[14:33] <sforshee> smb, when I tried to update it a couple of weeks ago it kept adding new items for rtg
[14:33] <smb> Yeah, 10 reviews without any more detail seems a lot...
[14:33] <sforshee> it seems to be behaving a bit better now
[14:34] <smb> I would try to reduce it to 1 if nobody else is on it right now...
[14:34] <sforshee> go for it
[14:34]  * smb finds the lack of locking a bit tedious
[14:35] <sforshee> you find locking-via-irc to be less than ideal?
[14:35] <smb> ok... hope its fixed now
[14:35] <smb> sforshee, its racy ... :-P
[14:38] <smb> rtg, You should have put "get rid of duplicate work-items" into your goals... ;)
[14:38] <rtg> smb, I could have looked like a hero for doing all that work :)
[14:39] <smb> exactly... hehe...
[14:39] <apw> ogasawara, did i see you upload into -proposed there ?
[14:39] <ogasawara> apw: yep
[14:39] <ogasawara> apw: as instructed by the release team
[14:40]  * rtg uploads Quantal LTS....
[14:40] <apw> ogasawara, we're not frozen yet are we ?
[14:40] <ogasawara> apw: I thought we were as of 2100 UTC yesterday?
[14:40] <smb> Quantal LTS sounds so wrong...
[14:41] <apw> ogasawara, oh have they moved it out ... sigh
[14:41] <bjf> smb, but not scary
[14:41] <ogasawara> apw: I'm not sure if that's official for all milestones now, but was the time I was told yesterday when I asked about a pending late upload
[14:42] <smb> bjf, Not? Oh, well just another release to support for 5 years... ;-P
[14:42] <apw> ogasawara, bah ... i'll hold lowlatency for after then
[14:43] <rtg> apw: did it FTBS ?
[14:43] <rtg> oh, the rebase. never mind.
[14:43] <apw> rtg, nope, i was going to rebase it to -2.2 to match mainline
[14:43] <rtg> apw: I don't think low-latency has any impact on the release team does it ?
[14:44] <apw> rtg its on an official release CD so i assume we'll be spinning them for A2
[14:44]  * rtg wonders how ubuntu-studio survives without a community
[14:49]  * ogasawara back in 20
[15:10] <brendand> cking, so it seems like even if we don't use --s3-device-check those errors are still registered and cause a failure...
[15:11] <cking> brendand, yep, --s3-device-check just checks if a bunch of devices disappear between S3 iterations
[15:15] <brendand> cking - hmm, certainly if devices are disappearing we'd want to know
[15:16] <apw> sounds like a real problem then
[15:17] <cking> otherwise S3 testing would be pointless ;-)
[15:19] <brendand> cking, would device check failures be considered critical?
[15:19] <apw> if bits of your machine were there before s/r and not after, i think you'd think it was important, no ?
[15:19] <cking> brendand, like video not working, or audio or webcams disappearing, yes
[15:20] <cking> fwts takes a pragmatic approach - if it fails the test, it marks it as failed
[15:21] <brendand> cking, if the system failed to suspend that would be marked as critical too, right?
[15:22] <cking> it's definitely a fail isn't it?
[15:22] <apw> a non-working s/r really aught to fail a s/r test
[15:22] <brendand> cking, you said assume nothing :)
[15:23]  * cking punches himself
[15:27] <cking> brendand, https://wiki.ubuntu.com/Kernel/Reference/fwts/s3
[15:31] <brendand> cking, i don't see anything about the severity levels of the different issues
[15:31] <brendand> cking, anything available on that? or just read the source?
[15:32] <cking> I didn't document the 983 different failure messages in the wiki, so it is an omission
[15:32]  * cking looks it up
[15:33] <brendand> cking, understand that i'm trying to establish if we can use 'no critical errors' as a criteria for passing the test for the purposes of certification
[15:34] <cking> brendand, the severity is more tuned to the engineers in HWE
[15:34] <cking> ..and it may change
[15:36] <brendand> cking, ok. our only other alternative then is to ignore them. we're going to go along with 'no critical errors' for now, it's better than nothing
[15:36] <cking> so, critical means "holy smokes it's going to catch fire or possibly will fry your CPU", which may not be the case for S3 failure
[15:37] <brendand> cking, right i see
[15:37] <brendand> cking, so if it tries to suspend but can't that might just be high?
[15:38] <cking> it probably should be
[15:41] <brendand> cking, so it sounds like if you're going to consider both not suspending in the first place and kernel error messages (which we don't know exactly what they mean) as the same severity, then fwts is not matching with our definition of S3 testing
[15:41] <cking> no, cert is not matching the HWE definition of a working S3
[15:42] <brendand> cking, indeed it isn't
[15:42] <cking> brendand, what is the cert criteria of a S3 pass?
[15:43] <brendand> cking - if the system suspends and resumes then the actual suspend/resume functionality is considered passed. but we do also check all of the functions seperately again after S3, e.g. video, wifi, media cards, usb, bluetooth etc
[15:44] <cking> but you don't scan the kernel log to see if it is wetting itself over broken drivers etc?
[15:45] <cking> or randomly oopsing?
[15:45] <cking> or if devices come back misconfigured?
[15:45] <cking> or if resume took too long?
[15:46] <cking> or got stuck on AMD C1E idle state?
[15:47] <brendand> no, we weren't
[15:48] <cking> well, we either test thoroughly or we are just kidding ourselves that our process is good enough
[15:51] <brendand> cking, i know that. but what i'm getting here is that you may only consider issues such as those to be high severity, along with the issue described in the bug i raised - which as far as we know does not actually impact on anything
[15:51] <brendand> of course it could be we can link it to some functional failure in which case i stand corrected
[15:53] <brendand> we need to be able to say okay, high severity failure == cert blocker
[15:53] <brendand> for sure
[15:54] <brendand> i think part of the problem here is that we have shifted the scope of certification which we don't normally do
[15:55] <brendand> so if we could honestly go back and say all systems which fail the s3 test with it's new criteria don't pass cert then we'd do that
[15:58] <cking> yep
[16:31] <ricotz> hello, did someone here by mistake uploaded  "linux-lts-quantal - 3.5.0-2.2~precise1" to ppa:xorg-edgers/ppa?
[16:37] <bjf> ricotz, it was intentional, that ppa is being used for "LTS backport" testing work
[16:37] <rtg> ricotz, no accident
[16:38] <tjaalton> wrong ppa, this is edgers :)
[16:38] <ricotz> bjf, don't mistake ppa:~ubuntu-x-swat/q-lts-backport with ppa:xorg-edgers/ppa
[16:38] <tjaalton> but maybe someone copied it there by hand
[16:40] <rtg> tjaalton, it was likely apw's automagic...
[16:40] <tjaalton> ok it was manually copied
[16:42] <rtg> ogasawara, take another run at gomeisa
[16:42] <ogasawara> rtg: ack
[16:44] <cking> sforshee, thee machine with the dodgy battery info was a Toshiba Portege M200, so it is so old I think it's beyond fixing
[16:46] <sforshee> cking, the machine I just got is also a Portege, so it's may be the same ODM. Let me check it ...
[16:46] <cking> apparently it "works with windows"
[16:49] <sforshee> cking, battery state updates okay on this machine and looks reasonable enough
[16:49] <arges> cking, http://apps.linuxaudio.org/wiki/jack_latency_tests   fyi
[16:56] <cking> arges, I was looking at: http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2latency_8c-example.html
[16:57] <arges> ah nice
[16:57] <cking> but got stuck because my laptop doesn't have working audio input
[16:58]  * cking hunts for a different machine
[17:05] <Sarvatt> it looks like linux-image-generic-lts-quantal is missing a depends on linux-image-extra-${kernel-abi-version}-generic
[17:08] <ricotz> Sarvatt, the backport kernel package doesnt create a extra package
[17:13] <rtg> Sarvatt, yeah, it should all be in one blob
[17:14] <Sarvatt> ah right indeed, sorry for the noise
[17:15] <rtg> Sarvatt, gonna upload the meta package in a couple mins
[17:25] <apw> rtg not my magic, not that one
[17:31] <smb> jsalisbury, arges So it seems that bug 1013199 is actually not hw related. I just think that the way they define the bridge, eth0 is left as down and so the bridge is down as no ports are up. I added my proposal for setup to the bug
[17:31] <ubot2> Launchpad bug 1013199 in linux "be2net driver used by HP BL460c bridge networking not working" [High,Confirmed] https://launchpad.net/bugs/1013199
[17:32] <jsalisbury> smb, great.  thanks for the feedback!
[17:33]  * cking saunters off
[17:51]  * smb is blinded by the sun sideways... (may as fell wander off to enjoy it)
[18:38]  * ogasawara lunch
[18:43] <arges> smb, thanks
[19:59] <vanhoof> ogasawara: hi
[20:00] <ogasawara> vanhoof: heya
[20:00] <vanhoof> ogasawara: time to chat?
[20:00] <ogasawara> vanhoof: for you, of course
[20:01] <vanhoof> ogasawara: :D
[20:45]  * rtg -> EOD
[20:56] <arges> ogasawara, just got my kit! : )
[20:56] <ogasawara> arges: sweet