=== oubiwann_ is now known as oubiwann
=== TheMuso` is now known as TheMuso
=== lifeless_ is now known as lifeless
[08:50]  * apw yawns
[08:51] <RAOF> Good morning!
[08:55] <jk-> heya apw, RAOF.
[08:57] <apw> RAOF, heya, jk- evening!
[08:57] <apw> RAOF, did sconklin drop you a line about the lid detect bug ?
[08:58] <RAOF> apw: Indeed he did.  I've replied, and cc'd you.
[08:58] <apw> ahh then i'll read m'email
[08:59]  * apw shouts at compiz which has dumped twice in two days
[08:59] <RAOF> apw: In short, I think it's possible to fix in a way that would minimise regression potential, and be acceptable upstream, but requires more work than the pseudo-patch I dumped in the bug.
[09:03] <ikepanhc> good morning .eu
[09:08] <apw> afternoon .ap
=== _Traxer is now known as Traxer
[09:11] <ikepanhc> .ap?
=== Kevin`_ is now known as Kevin`
[09:18] <cooloney> ikepanhc: as you are maintaining the #hwe tree, i got a question for you
[09:18] <cooloney> ikepanhc: when we got a new board defconfig and some small patches to enable a new board, 
[09:19] <cooloney> ikepanhc: do you just add a new flavor or something else
[09:20] <ikepanhc> cooloney: for a custom kernel, its another branch, so I will have a new debian folder
[09:20] <ikepanhc> cooloney: and restart the abi/changelog/flavour
[09:21] <cooloney> ikepanhc: ok, creating a new debian.project folder
[09:22] <ikepanhc> cooloney: yeah
[09:22] <cooloney> ikepanhc: and if you got a new board which can be fitted into this project
[09:22] <cooloney> shortly, this project has 2 boards,
[09:22] <cooloney> board-a and board-b
[09:22] <cooloney> will you create 2 flavors for that?
[10:46] <ogra> cooloney, if you are tlaking about the omap4 kernel above, the same omap4 kernel will run on both boards, dont bother with fiddling with different flavours
[11:31] <cooloney> ogra: the panda board use is own config file instead of the original one omap4_sdp_defconfig.
[11:31] <ogra> that will change
[11:31] <ogra> just ignore omap4_sdp_defconfig for that build 
[11:31] <ogra> and use the panda one
[11:32] <cooloney> ogra: and we cannot generate 1 kernel to support that 2 boards. i just got a compiling failure
[11:32] <cooloney> ogra: yeah, that's what i am doing. 
[11:32] <ogra> TI said it will be one kernel
[11:32] <cooloney> thanks for heads up
[11:32] <ogra> probably not yet though :/
[11:32] <cooloney> ok, it guess it will be panda, not sdp
[11:32] <cooloney> no problem
[11:32] <ogra> yes, main target is panda for 10.10 anyway
[11:33] <cooloney> and one another thing is the panda config also got a problem
[11:33] <cooloney> it built in both 8250 serial and omap serial driver
[11:33] <cooloney> weird
[11:33] <cooloney> i am still working on that
=== cooloney is now known as cooloney-afk
[12:27] <Kano> apw: is it possible to change options based on enforce?
[12:28] <apw> Kano, not currently is purely a check and abort function right now
[12:29] <Kano> so how do you change options
[12:31] <apw> Kano, add the new values by hand and updateconfigs normally
[12:32] <Kano> where to put the .config ?
[12:35] <apw> there is a file called OVERRIDES you can put them in _temporarily_ then run updateconfigs, then remove it
[12:39]  * cking wonders if that's documented anywhere
[12:40]  * apw knows it is not, though the source is pretty easy to read
=== oubiwann is now known as oubiwann_
=== oubiwann_ is now known as ouniwann
[13:51] <amitk> apw: our build system is not an easy read anymore (for newcomers) :)
[13:52] <apw> amitk, bah of course it is :)
[13:55] <amitk> apw: that's like saying that "War and peace" is an easy read
[13:55] <amitk> :-p
[13:57] <ericm|ubuntu> apw, amitk, is there any easy way to extract the scripts of updateconfigs quickly into a separate script, so that multiple _defconfig can be used as input and a common.config and a bunch of <flavor>.config as output?
[13:58] <ericm|ubuntu> I guess that seems to be very useful for the ARM _defconfig mess we are now facing with
[13:58] <apw> ericm|ubuntu, the processing works in that manner internally
[13:58] <apw> there is a script to apply to a directory of configs
[13:58] <ericm|ubuntu> apw, which one?
[13:59] <ericm|ubuntu> splitconfig.pl?
[13:59] <apw> yep
[13:59] <apw> kernelconfig uses it so you can see how to
[14:00] <ericm|ubuntu> apw, thanks man - I'll take a look
[14:01] <amitk> ericm|ubuntu: while it is worth looking into, I don't have high hopes that it will find too much common stuff.
[14:01] <ericm|ubuntu> amitk, well at least find a base to start the merge with
[14:02] <ericm|ubuntu> amitk, though I guess won't be very optimal
[14:05]  * amitk nods
=== cooloney-afk is now known as cooloney
=== bjf[afk] is now known as bjf
=== alex_jon1 is now known as alex_joni
[15:45] <apw> ogasawara, yo ... hows -rc2
=== ouniwann is now known as oubiwann
=== ericm|ubuntu is now known as ericm-Zzz
[15:59] <ogasawara> apw: bah, I sent you email but looks like it didn't go out.  /me re-sends
[16:01] <apw> ogasawara, heh thanks
[16:05] <bjf> pgraner, cking needs http://www.bluemic.com/snowball/
[16:06] <pgraner> bjf: heh
[16:30] <cking> bjf, I probably need to write a driver for the snowball before I can use it
[16:31] <bjf> cking, it works on a mac, and that's just like linux, i don't think there would be a problem
[16:32] <cking> bjf, you being funny?
[16:32] <bjf> cking, yup
[16:36] <Zhenya> hi guys!
[16:37] <Zhenya> i am having lots of fatal kernel panis
[16:37] <Zhenya> panics
[16:37] <Zhenya> lol
[16:37] <Zhenya> It hasn't done it today yet, but once i switch to dual screens and run some music, i feel like its guaranteed in an hour or so
[16:37] <Zhenya> if someone would help it would make my machine much more usable :/
[16:42] <Zhenya> anyone?
[16:45] <JFo> Zhenya, do you have a bug filed about the issue?
[16:45] <Zhenya> JFo: no i do not as i dont even know how to get all the details except for dmesg and i wanted to make sure it wasnt my hardware
[16:45] <Zhenya> (however this did NOT happen when i was on 9.10)
[16:46] <JFo> you can run ubuntu-bug linux from a terminal window
[16:46] <JFo> it will gather all that we need
[16:46] <JFo> so the command
[16:46] <JFo> 'ubuntu-bug linux'
[16:47] <Zhenya> do i just wait for it to then panic?
[16:47] <Zhenya> oh cool!
[16:48] <Zhenya> which is this?
[16:48] <Zhenya> kernel config? filesystem?
[16:48] <Zhenya> other?
[16:50] <JFo> what do you mean?
[16:50] <JFo> this pulls all the data we want and opens a bug on Launchpad
[16:50] <Zhenya> gotcha
[16:50] <Zhenya> nm
[16:51] <Zhenya> thanks for showing me this!
[16:52] <JFo> my pleasure :)
[17:02] <Zhenya> JFo: in case you want to check it out :D https://bugs.launchpad.net/ubuntu/+source/linux/+bug/591330
[17:02] <ubot2> Launchpad bug 591330 in linux (Ubuntu) "Kernel panic - random (affects: 1) (heat: 6)" [Undecided,New]
[17:04] <JFo> thanks, I'll take a look in a bit :)
[17:08] <bjf> ##
[17:08] <bjf> ## Kernel team meeting in 55 minutes
[17:08] <bjf> ##
[17:17] <Zhenya> JFo: next time my machine crashes should i grab the dmesg right after the crash and attach it to the log also?
[17:17] <Zhenya> log=bugreport
[17:17] <JFo> sure, that is helpful indeed
[17:19] <Zhenya> ok great.i am awaiting the caps lock wink of death
[17:19] <JFo> heh
[17:32] <JFo> apw, did we ever explain the new bug process to cking?
[17:33] <apw> JFo, dunno cking ?
[17:33] <JFo> hmm
[17:33] <JFo> I can't remember us discussing it with him
[17:33] <JFo> and I just realized that there are a few in need of review that he may not be aware of
[17:33] <JFo> kernel-acpi bugs that is
[17:38] <cking> JFo, I'm not aware of what was discussed, got a brain like a sieve at the moment anyway, so is it documented?
[17:40] <JFo> heh
[17:40] <JFo> yeah, lemme dig it up
[17:41] <apw> more work for cking ... yay
[17:41]  * cking sinks
[17:41] <JFo> heh
[17:41] <cking> glub glub
[17:42] <JFo> so here are the new tags we crated, did you see them cking? https://wiki.ubuntu.com/Kernel/Tagging
[17:42] <JFo> we used your name in vain for one
[17:42] <cking> cool - all the yummy ACPI goo
[17:42] <JFo> yep, there isn't much
[17:42] <JFo> here is the rough idea of the process https://wiki.ubuntu.com/Kernel/BugReview
[17:44] <cking> JFo, that's coherent - great!
[17:44] <JFo> :-)
[17:44] <JFo> let me know if you have any questions
[17:45] <JFo> we are still working out the bugs so to speak
[17:45] <cking> no - it's easy peasy to use - thanks for making it fool proof
[17:45] <JFo> well, we try :)
[17:46] <ogasawara> jjohansen: so I'm sue you saw, but I've rebased our maverick kernel to 2.6.35-rc1 and will soon be pushing our rebase to 2.6.35-rc2...
[17:46] <JFo> the big thing is to make it super easy for you guys to get relevant and timely bugs to have a look at cking 
[17:46] <ogasawara> jjohansen: in my rebasing I spaced on dropping any AA patches like we'd discussed.
[17:46] <ogasawara> jjohansen: will that be an issue for you in bringing us up to date with the latest AA patches for 2.6.35
[17:46] <JFo> and the top 50 list at http://qa.ubuntu.com/reports/jfo/kernel-Top50.html is so you can have a look  at the overall workload
[17:47] <jjohansen> ogasawara: yep, its not a problem
[17:47] <ogasawara> jjohansen: cool, phew
[17:47] <jjohansen> ogasawara: we can either drop them separately or, patch on top, which ever works best for you
[17:48] <jjohansen> ogasawara: probably best they didn't get dropped just yet anyways as I have some compatability bugs to work out
[17:49] <ogasawara> jjohansen: cool.  doesn't make much of a difference to me if we drop them separately or just a patch on top.
[17:49] <jjohansen> okay, I'll probably drop and do a clean import for you as that will give a nice clean history
[17:49] <ogasawara> jjohansen: sounds good
[17:52] <sconklin> I just took a lucid update and now my machine won't boot. I'll let you know what I find out.
[17:52] <JFo> nicew
[17:52] <JFo> s/w//
[17:54] <sconklin> ok, It's not catastrophic. It boots fine when the external USB drive isn't attached.
[17:55] <tgardner> sconklin, does it have abootable partition?
[17:56] <Zhenya> JFo: ok i just had a panic
[17:56] <Zhenya> and i got the dmesg
[17:56] <Zhenya> should i pastebin it?
[17:56] <JFo> put the file in the bug please
[17:57] <JFo> sconklin, I seem to recall someone else seeing that issue as well
[17:57] <bjf> ##
[17:57] <bjf> ## Kernel team meeting in 5 minutes
[17:57] <bjf> ##
[17:57]  * JFo reasies for the meeting
[17:57] <JFo> redies*
[17:57] <JFo> sigh
[17:57] <JFo> I give up on typing for today
[17:57] <tgardner> JFo, crack your knuckles
[17:58] <JFo> oh wow... wonder how long I have needed that
[17:58] <JFo> oh yes, hands are working much better now :)
=== sconklin1 is now known as sconklin
[18:03] <JanC> Zhenya: best attach it to your bug report so that it doesn't get lost
[18:03] <Zhenya> JanC: ok i will do it! i rerequested my password from launchpad and its taking forever to get here.....
[18:05] <JanC> heh, how did you upload an hour ago without that password?  ☺
[18:05] <Zhenya> i had one
[18:05] <Zhenya> and i tried using it and it DIDNt work right now
[18:05] <Zhenya> i know i had the right password, very weird....
[18:07] <sconklin> http://www.webson.co.za/complete-guide-fixing-grub-error-17/
[18:11] <JFo> cking, that is by far the BP that has me most excited
[18:12] <cking> JFo, the BIOS testing one?!
[18:12] <JFo> yep
[18:12] <cking> your're welcome to get the sources, build it, use it and give me feedback ;-)
[18:12] <Zhenya> JFo: still no password, do you have the correct permissions to attach things to the bug reports?
[18:20] <manjo> apw, do you want us to put names along side the todo items ?
[18:20] <JFo> yes, if you are going to be doing that item
[18:21] <JFo> cking, I may do that
[18:21] <apw> manjo, thats what the instructions say yes
[18:21] <JFo> I am eager to see what it does in the testing ISOs
[18:21] <manjo> apw, AH instructions :) 
[18:21] <apw> bjf, can you remember what smb calls his 'manual' for stable
[18:21] <apw> he has a nice name i think
=== bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - June-15 - 17:00 UTC
[18:21] <bjf> apw, yes
[18:22] <bjf> apw, https://wiki.ubuntu.com/KernelTeam/StableHandbook/UpstreamStableReview
[18:22] <cking> JFo, I'd better write a README file then ;-)
[18:22] <apw> bjf, and what does he call it
[18:22] <apw> handbook, thank you
[18:22] <apw> JFo, i think we need a Handbook section of the Kernel wiki
[18:22] <JFo> cking, yes please :)
[18:22] <bjf> apw, was getting the url from bookmarks
[18:22] <apw> for those sorts of things
[18:22] <JFo> apw, I agree
[18:22] <apw> bjf, sorry i was not actually thinking of the URL though it has the information :)
[18:22] <JFo> I think that is massively useful
[18:24]  * bjf thinks we need some user experience people to help design the kernel wiki pages (maybe a useability study or two)
[18:24]  * manjo getting lunch will be back soon
=== sconklin is now known as sconklin_
[18:26] <JFo> I think that is a thumping good idea bjf
[18:26] <JFo> work the layout flow out and all
=== sconklin_ is now known as ai4qr
=== ai4qr is now known as sconklin
[18:29] <jaminc> my laptop appears to be periodically rebooting as a result of a kernel crash...  however most attempts to submit the requested bug report for the kernel crash result in a "HTTP Error 500: Internal Server Error" response after several minutes trying to upload the data.  Is there any other way I can report this problem and provide the necessary data?
[18:31] <JFo> I think you are encountering the same issue as Zhenya jaminc 
[18:32] <JFo> there seems to be some kind of server issue
[18:33] <jaminc> k... wasn't sure if it was me or the server... it's an annoying issue... leave the system for a while and come back to find it rebooted at the login screen... no idea why... only report I have successfully uploaded indicated that my kernel was too old, though I'm pretty sure it was the most current at the time
[18:35] <apw> JFo, as we do not have any advanced topics i wonder if we should make 'Advanced' into 'Other'
[18:35] <apw> then have essentially the same list of topics under 'Topics' on there
[18:35] <apw> hrm, perhaps not, what does that get me
[18:43] <lag> Right, that's me! Night all.
[18:57] <lamont> Jun  8 11:16:07 rover3 libvirtd: 11:16:07.449: error : udevStrToLong_ui:73 : Failed to convert '008' to unsigned int#012
[18:57] <lamont>  wtf is up with that
[19:01] <cking> tgardner, not sure if that patch will work - doesn't the pcmcia_request_irq require interrupts to be enabled to detect the IRQ probing?
[19:01] <tgardner> cking, as far as I could tell it did not. everything was just I/O reads and writes.
[19:02] <cking> tgardner, ok - well, then I'm very happy with it ;-) Thanks for picking this up - I'm the slacker
[19:02] <tgardner> cking, lets see if it actually works :)
[19:03] <cking> tgardner, if it does, the same code should be applied to a bunch of those drivers that use the same probing/config methodology 
[19:05] <apw> lamont, odd isn't it, i saw that when testing kvm myself.  i had assumed it was a udev/libvirtd interaction
[19:06] <apw> lamont, and therefore blamed kirkland 
[19:11] <Zhenya> JFo: you mean on launchpad or kernel wise?
[19:17] <apw> tgardner, i think your script which adds ~lucid1 has gotten a little out of hand as its adding them everywhrere there is a ) ... should only apply on lines which do not have whitespace as the first character
[19:18] <cking> JFo, I've dumped a readme file in the top level of the test suite - it's ready for you to play with
[19:23] <bjf> pgraner, if I go to http://voices.canonical.com/kernelteam/ i'm not getting any of the links on the right side of the page (so I can't go to admin and post) 
[19:23] <bjf> pgraner, is it working for you?
[19:23]  * pgraner looks
[19:24] <pgraner> bjf: nope
[19:28] <tgardner> apw, I had that fixed once. sed '1s/..../
[19:28] <apw> tgardner, hrm well its unwell again i am afraid
[19:29] <tgardner> apw, no worries. I'll figure it out.
[19:32] <tgardner> apw, fixed and pushed
[19:32] <apw> tgardner, cool
[19:33]  * cking attends to kids - seeya tomorrow
[20:11] <Zhenya> JFo: still no way to access launchpad
[20:13] <jaminc> Zhenya, what problem are you having accessing launchpad?
[20:59] <jjohansen> -> Lunch
[21:05] <cnd> hooray! I think I'm finally out from under pm-utils work :)
[21:06] <cnd> twas a little more than I bargained for when I took it over at the end of the lucid cycle...
=== bjf is now known as bjf[]
[21:12]  * bjf is here
[21:24] <apw> pgraner, is emerald ok
[21:25] <tgardner> apw, no tyler either
[21:25] <apw> yet pgraner is here ... odd
[22:21] <methril_work> is here the proper place to ask for linux rt kernel?
[22:21] <methril_work> i see some updates in the rt preempt patch taht are not reflected with the rt kernels
[22:22] <apw> methril_work, abogani is the man for those kernels, though they are not here at the moment
[22:23] <methril_work> apw: thanks. Do you know his time zone?
[22:24] <apw> i think .eu though its sometimes hard to tell as that might be his off work time
[22:25] <methril_work> apw: i´ll try to catch him later
[22:29] <Zhenya> jaminc: cannot log in or retrieve password
[22:33] <smoser> anyone around who can answer a quick question before i open it as a bug ?
[22:33] <smoser> jjohansen maybe 
[22:33] <jjohansen> smoser: whats up
[22:33] <smoser> i'm playing around with eucalyptus, and attaching a bunch of EBS block devices , detaching them, reattaching them.
[22:34] <smoser> the block devices get (in udev) KERNEL=/dev/vda at first
[22:34] <smoser> then vdb
[22:34] <smoser> then vdc .... vdz
[22:34] <jaminc> Zhenya, hmmm can do both here... simply can't submit a kernel crash bug report
[22:34] <smoser> they are never re-used
[22:34] <jaminc> JFo thought we might be experiencing the same issue, but doesn't seem to be
[22:35] <Zhenya> jaminc: gotcha.i think they are ahving server isssues
[22:35] <jjohansen> smoser: hrmm, that seems wrong
[22:35] <smoser> my experience with other busses (scsi) is that when a block device was detached, and then reattached it would be freed.
[22:35] <smoser> ok. i'll open a bug. just wanted to make sure it wasn't obviously working as expected from the kernel perspective.
[22:35] <jjohansen> yeah, that is generally the case
[22:35] <jaminc> smoser, esata doesn't reuse unless you explicitly tell the kernel to delete it
[22:36] <smoser> hm..
[22:36] <jaminc> try echoing 1 into /sys/block/${DEV}/device/delete
[22:36] <jjohansen> right there are some exceptions
[22:36] <jaminc> that's how I get the kernel to remove the old esata devices
[22:37] <smoser> well, i'll open a bug, and let kernel deal with it.
[22:37] <jjohansen> smoser: subscribe me to the bug
[22:37] <smoser> jaminc, well, there is only at this point a /sys/block/vdag entry (no others)
[22:37] <smoser> so presumably i'd have to do that before the entry was removed.
[22:37] <smoser> maybe thats housekeeping that udev is supposed to do ?
[22:38] <jaminc> hmmm I'd think the device names would be reused if the entry no longer exists...
[22:40] <jaminc> is there a time limit on uploading lauchpad bug data via apport?
[23:29] <smoser> jjohansen, bug 591469
[23:29] <ubot2> Launchpad bug 591469 in linux (Ubuntu) "virtio block devices names are not recycled (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/591469
=== sconklin is now known as sconklin-gone