[03:23] <bizhanMona> hi
[03:24] <bizhanMona> Hi how could I force Linux to re-enumerate the PCIe bus? thx
[04:59] <the_voice_> Hi
[04:59] <the_voice_> I followed the tutorial here on how to update the Ubuntu http://wiki.freeswitch.org/wiki/Amazon_EC2 here
[05:00] <the_voice_> however when I go /boot/
[05:00] <the_voice_> I don't see a newer version of vmlinuz-*
[09:00]  * apw yawns heavily
[11:25] <rainman> how do most recent linux kernels alternate the frequencies of processor and/or cores in order to save power? do they do it on the core level or the processor level? anybody has an idea?
[11:27] <amitk> rainman: it depends on the processor (HW). The software can do either. It really depends on whether the cores can be scaled independently or not.
[11:28] <rainman> amitk: let's say the processor allows scaling on the core level, so OSPM(operating system power management) code does individually scale cores?
[11:29] <amitk> rainman: yes
[11:30] <amitk> rainman: look at affected_cpus and related_cpus in the cpufreq framework code
[11:30] <rainman> amitk: I am on it, thank you very much for the lead
[11:31] <rainman> amitk: do you have experience on ACPI and power management by the way?
[11:31] <amitk> x86 hides a lot of this behind acpi bios calls, ARM deals with the details in kernel code
[11:31] <rainman> wow that's a good point
[11:31] <amitk> rainman: a bit..
[11:31] <rainman> so that means arm gives a lot of playability since it does the stuff in kernel code
[11:33] <amitk> rainman: but current ARM-based SoCs can only do processor-level scaling (architecture limitation). I think Qualcomm, Marvell and Nvidia can do core level since they only have to be compatible and can play around with the arch
[11:42] <rainman> amitk: can I humbly request a contact detail of you to ask lots of questions if you do not mind of course, I am doing a research in optimizing power on multi-core systems.
[12:27] <herton> apw, do you know if am I safe cloning from linux repo on zinc under ubuntu/, for the 3.5 stable stuff? I just don't want to use it if it can be modified or be gone etc. in the future
[12:30] <rtg> herton, I periodically update it, and have no plans to remove. it could be used as a ''reference for some repos
[12:30] <apw> herton, thats the repo with the u* tags in it right?  if so then that is a slowly following linus branch and will never rewind; ie. it is safe to reference
[12:30] <rtg> --reference (I mean)
[12:30]  * smb would believe that if that is gone then zinc is gone
[12:30] <herton> rtg, ack, yes I want to use it as reference, instead of cloning everything from master linus, will do thanks
[12:30] <herton> apw ^
[12:31] <apw> yep
[12:32] <rtg> herton, have you thought about making 3.5 stable just a branch in ubuntu-quantal ?
[12:33] <rtg> instead of creating yet another repository ?
[12:34] <herton> rtg, I could do, but then it ties more to our kernel may be, I think just using a master linus branch and putting 3.5 in a branch would be better, don't know
[12:34] <rtg> herton, then just create a 3.5.y branch in the linux repo
[12:34] <herton> yes, that's my plan
[12:35] <herton> rtg, ah, you mean directly in the linux repo, instead of cloning another? I could do that as well
[12:35] <rtg> herton, yes
[12:37] <smb> herton, The only reason I could see for a seperate tree would be people often getting confused by branches...
[12:37] <smb> But then, they changed to that in upstream, too. Just with one linux-stable...
[12:38] <herton> smb, yes, I think using existing linux is fine. But if we plan to maintain other versions in the future, may be we should have also a linux-stable separated
[12:39] <herton> rtg, ok, so I'll create 3 branches there, 1 for the main 3.5, one for the -queue (I don't want to have a separate repo for the queue), and one for review (to announce review of the patches, alternative to who doesn't want to download the patches for review from the mailing list)
[12:40] <rtg> herton, s'fine with me
[12:46] <rtg> apw, it took me all freaking day yesterday to get armel to build properly, then slangasek announces armel is dead.
[13:01] <apw> rtg, man you kid me ... really
[13:01] <apw> so we are dopping armel in R ?
[13:02] <apw> herton, sounds better than what we have for the others
[13:03] <rtg> apw, https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036106.html
[13:04] <apw> well i guess thats good ...
[13:06] <rtg> apw, I finally have an armhf system built up 'cause the qemu-armhf gizmo on tangerine just kept faulting
[13:06] <apw> yeah it does that ... pos
[13:11] <apw> rtg, are we expecting powerpc uploads from BenC soon do you know ?  dropping them has put us in all sorts of britany pain
[13:12] <BenC> apw: I'll be uploading today or today
[13:12] <apw> BenC, great
[13:14] <BenC> *tonight
[13:14] <rtg> apw, why is britany complaining ? that kind of ties powerpc to the distro kernel build. wtf ?
[13:14] <apw> rtg, it is complaining because our src stops making them, so migrating our package would leave us with no ppc builds at all
[13:15] <apw> so it gets all whiney.  i believe once bens package is in, they will migrate as a pair this time
[13:15] <apw> and once thats done they will be unlinked from each other
[13:15]  * rtg grumbles
[13:16] <apw> rtg, britany has a point, you are orphaning whole swathes of the archive
[13:16] <apw> it doesn't know ben is sorting that out, till he uploads
[13:16] <rtg> apw, we've still got a periodic parallel build failure that I'm gonna go after today. Its bitten me several times in the last couple of days.
[13:17] <apw> rtg, arse, those are a royal pain, in what bit ?
[13:17] <apw> (if you know)
[13:17] <rtg> apw, thats the hard part.
[13:18] <apw> rtg, fyi i am working on raring-meta, we have some other deps issues due to the temp disablement of the linux-tools on arm
[13:18] <apw> which is also stopping migration
[13:18]  * henrix -> lunch
[13:18] <rtg> britany doesn't seem very flexible
[13:22] <apw> rtg, her job is to stop you breaking the archive.  by dropping linux-tools a couple of package exploded
[13:22] <apw> she knows what she is doing 
[13:25] <rtg> apw, if I figure out the armhf tools build problem, can we just ignore armel ? (though they are likely the same).
[13:25] <apw> rtg, ahh while i remember, we are missing a couple of tags for ubuntu-raring (the last two uploads) and one of the meta ones too
[13:25] <rtg> apw, I just fixed the Ubuntu-3.7.0-0.5 tag
[13:25] <apw> rtg, probabally, i'll find out when armel is getting zapped
[13:26] <apw> rtg, i think we are also missing .4
[13:26] <rtg> apw, I never uploaded the others so I didn't bother tagging. those commits are also linear and easy to reproduce
[13:26] <apw> though i suspect it is linear from .5
[13:26] <apw> ack
[13:27]  * rtg will bbiab
[14:04] <rtg> cking, are you OK with me bouncing gomeisa ?
[14:05] <rtg> I'm trying to remove a chroot and can't get all of the mount point released. damn schroot anyways.
[14:05] <cking> yep
[14:06] <rtg> cking, done
[15:16] <BenC> apw: When I get a chance I'll write up a test case for you
[15:16] <BenC> Gotta get this package out the door first...
[15:21] <apw> BenC, if you can just show me the form i can debug it, as all the forms i'd expect you to have used test right and have tests already
[15:22] <BenC> apw: Use the old enforce (before my commit) against my set of powerpc configs (with e500 and e500mc)
[15:23] <BenC> That NVRAM check fails on e500 and e500mc, but it shouldn't
[15:23] <apw> BenC, ta
[15:23] <BenC> And the ADT check before it succeeds even though the check is the exact same syntax against the exact same flavours and the exact same value in the configs
[15:24] <apw> (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \
[15:24] <apw>  value CONFIG_NVRAM m | \
[15:24] <apw>  !exists CONFIG_NVRAM
[15:24] <ubot2> apw: I am only a bot, please don't think I'm intelligent :)
[15:25] <apw> BenC, like that ... but you have it =y on powerpc-e500 and powerpc-e500mc and thats not valid under that form
[15:25] <apw> so it correctly fails on those two
[15:26] <apw> BenC, or perhaps not ... /me pokes
[15:28] <apw> BenC, no i am right
[15:28] <apw> CONFIGS/powerpc-config.flavour.powerpc-e500:CONFIG_NVRAM=y
[15:28] <apw> CONFIGS/powerpc-config.flavour.powerpc-e500mc:CONFIG_NVRAM=y
[15:28] <apw> CONFIGS/powerpc-config.flavour.powerpc-smp:CONFIG_NVRAM=y
[15:28] <apw> those three have NVRAM set, so for the rule to be right it has to expect Y for those three
[15:29] <apw> (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \
[15:29] <apw> and that only allows it to be powerpc and powerpc-smp, so they will fail
[15:30] <apw> (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \
[15:30] <apw> damn that paste
[15:33] <BenC> apw: I tried add "| value CONFIG_NVRAM y" and it still failed
[15:35] <apw> BenC, will try that even though it doesn't represent what you want
[15:36] <BenC> apw: I don't want to force NVRAM=y on e500/e500mc
[15:36] <BenC> It's fine if it's one, don't care otherwise
[15:36] <BenC> *on
[15:37] <BenC> apw: What I want is for it to be forced on powepc-smp, and not care for anything else
[15:38] <BenC> But the error only arose when it listed power and powerpc-smp as flavours, and the exact same situation existed for the ADT rule and it worked as expected
[15:38] <BenC> powerpc
[15:39] <BenC> So if the NVRAM rule works as expected, then the ADT rule isn't :)
[15:39] <apw> BenC, nope, cause that _is_ only Y on powerpc-smp, and that rules says Y for that and _must_not_exist_ on all the others
[15:39] <apw> so the rule matches reality, not necessarily what you care about
[15:39] <BenC> it exists on e500/e500mc right?
[15:39] <apw> nope
[15:40] <apw> apw@dm:~/git2/ubuntu-raring$ grep CONFIG_THERM_ADT746X CONFIGS/*
[15:40] <apw> CONFIGS/powerpc-config.flavour.powerpc-smp:CONFIG_THERM_ADT746X=y
[15:40] <BenC> Hmm…then I wasn't paying close enough attention
[15:41] <apw> (flavour powerpc powerpc-smp &/ value CONFIG_NVRAM y) | \
[15:41] <apw>  (flavour powerpc-e500 powerpc-e500mc) | \
[15:41] <apw>  value CONFIG_NVRAM m | \
[15:41] <apw>  !exists CONFIG_NVRAM
[15:41] <ubot2> apw: I am only a bot, please don't think I'm intelligent :)
[15:41] <apw> so i think that encodes what you are saying
[15:41] <BenC> so the second line just basically ignores e500/e500mc?
[15:42] <apw> yeah it says this rule is "happy" if we are on one of those flavours, without checking anything related to the option
[15:42] <apw> its just a logical or
[15:42] <apw> i'll test that on master, and if it works splat it in
[15:43] <BenC> Ok, thanks
[15:43] <BenC> apw: I suggest you comment out the debug in the loop for possibles for the flavour predicate though…in my testing, it only showed the first flavour
[15:43] <BenC> Hence my concern about multiple flavours
[15:45] <apw> BenC, the commented out debug is just plain wrong, i prints $a[1] each time, instread of $possible
[15:45] <apw> but its commented out indeed
[15:45] <BenC> err, meant uncomment so you see what it is
[15:46] <BenC> I didn't see it only prints the [1] in the array
[15:46] <BenC> That alleviates some of my concern then :)
[15:46] <apw> yeah i clearly fixed the debug in the arch one, and not the flavours one
[15:46] <apw> must have not had to debug flavours recently
[15:56] <apw> BenC, ok i've fixed the debugging for next time
[15:56] <BenC> Gracias
[16:59]  * rtg takes a break to shovel some of the 16" of snow received overnight while the armhf build slowly crawls along
[17:24]  * smb -> EOW
[17:59]  * henrix -> EOD
[18:22] <slangasek> rtg: urk, you were losing time fighting with armel?  Well, on the bright side... you don't have to do that again :P
[18:23] <rtg> slangasek, urk, indeed :0
[18:23] <rtg> :)
[18:25] <rtg> slangasek, the next kernel upload won't contain _any_ armel support. Is brittany gonna be able to deal with that ?
[18:25] <slangasek> yep
[18:26] <rtg> slangasek, I understand moving powerpc support kind of made it complain
[18:27] <slangasek> well, once removed we have to make sure we clean up behind it and aren't leaving uninstallable packages in the archive
[18:27] <slangasek> but that's what britney's supposed to do
[18:27] <rtg> hopefully BenC's upload will get everything sorted
[18:28] <BenC> I'm in the final stages of proofing the packages
[18:42]  * apw calls it a day
[19:41] <BenC> infinity: Will I need to do a MIR for linux-ppc?
[19:43] <infinity> BenC: No, it's just a source split producing things that were already in main.
[19:43] <BenC> infinity: Ok, upload is in progress…can I pester you for processing when it's done?
[19:44] <infinity> BenC: If you've already added your bits to it, it might need a quick audit to make sure your patches are all license-compliant as part of the NEW process, but here's hoping you've been doing that sanely, with an eye to upstreaming. :P
[19:45] <infinity> BenC: I'm ubufluish, and considering wandering back to bed, but poke me and I'll get to it this weekend with a community hat on.
[19:45] <BenC> infinity: There's some patches from Freescale, but they are all available from Freescale's public linux.git and are in the process of upstreaming
[19:56]  * rtg -> EOD