=== jdstrand_ is now known as jdstrand
[06:06] <Lrush> Dear all, I find fedora 17 isntall  i3-3240 CPU  platform  Huaping screen!  have test latest kernel 3.6.2-2  ,but didn't work ? who can help me ?
[06:06] <Lrush> Dear all, I find linux isntall  i3-3240 CPU  platform  Huaping screen!  have test latest kernel 3.6.2-2  ,but didn't work ? who can help me ?
=== amitk is now known as amitk-afk
=== amitk-afk is now known as amitk
=== henrix_ is now known as henrix
[09:50] <apw> caribou, do you guys still keep copies of the .ddebs offline ?
[09:50] <caribou> apw: I have some stashed somewhere, but not all of them
[09:51] <caribou> apw: what do you need ?
[09:51] <apw> caribou, damn i had rumours you were keeping them all in an automated fashion
[09:51] <apw> caribou, one of the precise ones has gone missing and was wondering if you had them
[09:51] <caribou> apw: I did, but when they changed how ddebs were kept, my script went haywire and deleted some (mostly Natty's)
[09:52] <apw> ahh would you  have 3.2.0-32-* by any chance ?
[09:52] <caribou> apw: lemme check...
[09:53] <henrix> apw: what do you mean by "gone missing"?  an accident?  or they failed to build?
[09:54] <apw> henrix, actually "not there now and i would expect them to be"
[09:54] <henrix> apw: interesting. any idea how that could happen?
[09:54] <caribou> apw: I have 3.2.0-32.51
[09:55] <apw> caribou, can they all be somewhere i can pass them to pitti ?
[09:55] <caribou> apw: is .51 the only one you need ?
[09:55] <caribou> apw: I have the -generic, -generic-pae & virtual ones
[09:55] <caribou> i386 & amd64
[09:56] <apw> caribou, for now yes just .51 and those are better than none at all
[09:58] <caribou> apw: what are these ? 
[09:58] <caribou> apw: http://ddebs.archive.ubuntu.com/ubuntu/pool/main/l/linux/kernel-image-3.2.0-32-generic-di_3.2.0-32.51_amd64.udeb
[09:58] <caribou> apw: nevermind, they're udebs
[09:58] <apw> yeah ... that :)
[10:20] <brendand> henrix, hi
[10:20] <henrix> brendand: hey
[10:20] <brendand> henrix, i see the precise kernel is just verified. are we still expected to do certification testing by tomorrow?
[10:21] <henrix> brendand: we had 2 kernels (oneiric and precise) blocked by a bug verification, and i just got precise freed today
[10:22] <henrix> brendand: it would be nice to have the certification during this week, i believe.
[10:22] <brendand> henrix, ok - it's possible
[10:23] <henrix> brendand: that would be great
[10:23] <henrix> brendand: sorry for the delay
=== amitk is now known as amitk-afk
=== amitk-afk is now known as amitk
[12:01] <apw> henrix, where are we with linux-lts-quantal, how far from promoting that to -updates are we?
[12:01] <henrix> apw: it should be in -updates late this week
[12:02] <apw> henrix, and does another cycle start monday? 
[12:02] <henrix> apw: or, worst case, on monday
[12:02] <henrix> apw: yep
[12:02] <henrix> apw: i mean, another cycle starts on monday
[12:02] <apw> yep, cool
[12:02] <apw> henrix, we have a tiny patch to enable signed kernel generation on that one which we are waiting on, just wondering when we might see it in -proposed
[12:03] <apw> henrix, if you could poke me when the current one promotes that would be great
[12:03] <henrix> apw: sure, will do
[12:03] <apw> as i might sneak an upload (for -proposed only) in immediatly; which would just be the same with that patch
[12:04] <apw> it would not need testing or promoting to -updates or any of that jazz, and would be replaced when you do your normal uploads for the cycle
[12:05] <henrix> apw: ok, cool. maybe we can get jjohansen and infinity to have the current one on -updates today
[12:05] <apw> henrix, that would rock, i only care about lts-quantal the others are not blocking us at all
[12:06] <apw> henrix, if i wanted to upload something like this, i assume i would not put a tracking bug in it
[12:07] <apw> henrix, as it is not an SRU or indeed destined for anywhere, and i believe your tooling would just cope as it tells you the -vVERSION to use when making the src package
[12:07] <henrix> apw: no, tracking bugs are generated using a script, i.e., it has to be manually executed
[12:07] <henrix> apw: so, i guess that would be fine
[12:07] <apw> cool
[12:08] <apw> i will discuss with you all (bjf, herton etc) again later to make sure people are happy
[12:08] <henrix> apw: sure. in the mean time, i'll try to have it promoted to -updates today
[12:08] <apw> henrix, thanks indeed
[12:30] <rtg> apw, do you intend to create ubuntu-precise-signed.git ? I'm wondering if we shouldn't collapse all of the '-signed' repos into ubuntu-signed.git in order to cut down on the proliferation of the small repos.
[12:31] <rtg> of these*
[12:33] <ogra_> rtg, hey, i found some differently licensed firmware files for bug 1075549, linked it  in the last comment
[12:33] <ubot2> Launchpad bug 1075549 in linux-firmware (Ubuntu Raring) "please include fw_bcmdhd.bin and bcm4330.hcd in linux-firmware for support of the nexus7" [High,In progress] https://launchpad.net/bugs/1075549
[12:33] <rtg> ogra_, ack
[12:34] <rtg> ogra_, if it is appropriately licensed then why not just have Jani include it with the N7 kernel ?
[12:34] <ogra_> well, i suspect we'll have more devices using such a chipset in the future
[12:35] <ogra_> so linux-firmware seemed appropriate 
[12:35] <ogra_> we'll surely have more android device support in the near future and will likely need firmware even beyond broadcom
[12:36] <apw> rtg, i was intending on that indeed.  to be inline with -meta
[12:36] <rtg> ogra_, I'll be doing the raring linux-firmware filtering against kernel MODULE_FIRMWARE() useage soon. Perhps that binary will pop up as being used by the kernel but not provided by linux-firmware.
[12:36] <ogra_> technically it doesnt make any difference where its shiupped indeed
[12:36] <apw> rtg, i should probabally do that for now, and we can revisit whether there should be a -meta.git and a -signed.git as you have for firmware
[12:36] <ogra_> as long as the driver finds it in the instaled system
[12:37] <apw> rtg, as a separate action
[12:37] <apw> rtg, as indeed right now it would be a strange -signed as it won't have a master
[12:38] <rtg> ogra_, for now why not include it with the N7 kernel. If I find its in wide use then we can always populate linux-firmware
[12:38] <ogra_> rtg, alternatively someone could try to get brcm80211 on the nexus, thjey claim to support our chip 
[12:38] <ogra_> i didnt manage to though
[12:38] <rtg> apw, I'm just thinking these gizmos would be easier to manage if they were in a common repo.
[12:39] <apw> rtg, i cannot deny bootstrapping a local copy is a pain in the ass
[12:39] <apw> rtg, though once you have them there is little to differentiate them for me
[12:39] <rtg> apw, also updating your local repo is easier since you only have to fetch one origin
[12:40] <apw> rtg, there is slight advantage when one is doing what i am now, backporting features to have them separate
[12:40] <apw> rtg, but there is also nothing to prevent me having 3 clones of the same repo ...
[12:40] <ogra_> rtg, as i said, trechnically i dont care where it is shipped, l-f just seemed appropriate since a have a policy to get evereything for the device properly in the distro (like we would do with any x86 based device) 
[12:40] <apw> rtg, if we merge this one, we should merge -meta as well
[12:41] <rtg> apw, agreed
[12:41] <apw> rtg, ok for now then i will play with it merged here and see how that works
[12:41] <rtg> apw, we should first make sure we don't cause herton problems with maint scripts
[12:42] <apw> rtg, i assume we use precise as 'master from precise'
[12:42] <apw> rtg, ok ... as it is easy to merge un-merge i'll proceed as i am then
[12:42] <apw> and engage with -stable on it.  it will break all the preproposed stuff if i mangle meta etc so
[12:42] <apw> some planning is needed
[12:43] <rtg> apw, I kind of wish we'd done this years ago.
[12:44] <apw> well it doesn't work for linux anyhow because of tag overlaps i believe
[12:44] <apw> but for the non-linux repos it is a reasonable plan
[12:44] <rtg> apw, right, but the other repos shouldn't
[12:45] <apw> rtg, and the tagging should be fixable postumously
[12:45] <apw> if we ever cared to do it
[12:45] <rtg> that would _really_ cause herton problems
[12:46] <apw> heh i am sure it would :)
[12:47] <apw> though the great things about signed tags is they can point to tags, so we can even preserve them old ones without maintaining the names
[12:47] <apw> as i do for the u* series
[12:50] <janimo> rtg, hi, is shipping firmware blobs in the kernel package being done by any other kernel flavour that I could look at? Would shipping in an entirely new package be ok as well as long as it is not linux-firmware?
[12:51] <rtg> janimo, have a look at the Quantal LTS branch in precise.
[12:52] <rtg> janimo, since firmware tends to track kernel versions I've been packaging firmware with the kernel when it isn't already provided by linux-firmware
[12:54]  * rtg fixes 'BUNTU: [Config] CONFIG_USB_OTG=n for all but armel/armhf' typo in raring
[13:01] <apw> rtg, i note we are using lts-backport-<series> for branch names regardless of name of the source package
[13:03]  * apw follows this for -signed
[13:08] <rtg> apw, right, since I started the naming convention quite some time before 'backport' became a dirty word.
=== yofel_ is now known as yofel
[13:29]  * henrix -> SIGFOOD
[13:34] <arges> smb, caribou : somebody could be using this: http://moss.csc.ncsu.edu/~mueller/cluster/ps3/
[13:55] <janimo> rtg, apw has the possibility of using dpkg source format 3.0 for kernels ever come up?
[13:55] <janimo> just thought of that as it makes shipping blobs inside the package saner
[13:58] <rtg> janimo, how about a patch explaining the advantages ?
[13:59] <janimo> rtg, I'll try it on the nexus7 kernel first then see. Advantages should be about the same as for any other package that has witched
[13:59] <ogra_> rtg, multiple upstream tarballs
[13:59] <janimo> ogra_, upstream is a rolling git , so kernel may be special in that regard
[13:59] <ogra_> janimo, well, packages use a tarball still :)
[13:59]  * rtg will be back on in a bit
[14:00] <ogra_> no matter how well your VCS rolls them ;)
[14:01] <janimo> ogra_, one thing I could use though is not uploading 100Mb with each slight packaging change. But that is more of a native vs not distinction, not 1.0 vs 3.0
[14:01] <janimo> anyway, trying that on nexus kernel now
[14:27] <rainman> where can I get the details of power management protocols instructed by ubuntu-kernel on multicore systems?
[14:28] <BenC> http://kernel.ubuntu.com/git takes *forever* to load, FYI
[14:29] <rtg> BenC, zinc is a little under powered. gitweb causes swapping
[14:30] <BenC> rtg: what's the reference tree I can use to base off of for powerpc?
[14:30] <rtg> git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git
[14:30] <BenC> Does that contain the mechanisms for having powerpc build out-of-mainline?
[14:30] <rtg> BenC, I could prep something for you in an hour os so if you'd like
[14:31] <rtg> BenC, it doesn't yet. 
[14:31] <BenC> I'd appreciate that, thanks
[14:32] <rtg> BenC, gimme awhile. I'll get back to you
[14:32] <BenC> Ok
[14:56] <BenC> rtg: Do I just base it off of the ti-omap4 branch and debian.ti-omap4 directory? If so, that's easy enough for me to handle
[14:57] <rtg> BenC, Its gonna be a bit different, but close to the same. I'm almost there....
[14:57] <rainman> Hello, I need detailed information about Linux Operating System Power Management System Code(Drivers, protocols, algorithms, strategies) on especially multi-core systems. Can some experienced one give me a hand please? Thank you.
[14:58] <BenC> rainman: That could easily be a semester long 3xx level college course worth of information…maybe you can ask a specific question?
[15:00] <rainman> BenC: The question is, I am making a research on optimizing power of multi-core systems. In order for me to do that I first need to know what linux does in this respect and what does it allow for user-space applications to manipulate power schemas.
[15:01] <BenC> rainman: ==> www.google.com
[15:02] <rainman> BenC: Thanks for the hand.
=== henrix_ is now known as henrix
[15:16] <rtg> BenC, have a look at git://kernel.ubuntu.com/rtg/ubuntu-raring.git ppc
[15:17] <rtg> this branch should be a strightforward rebase against raring master (eventually). I used master-next to start with.
[15:20] <rtg> BenC, once you've got it building then think about enabling the doc/headers indep/libc packages. See debian.ppc/rules.d/*.mk for that.
[15:23] <abogani> Is debian.powerpc too long? :-)
[15:24] <BenC> rtg: thanks
[15:25] <rtg> BenC, the ti-omap4 branch in Raring isn't really a good example. in fact, it may disappear if we can get a unified arm kernel working from master
[15:27] <ogra_> rtg, wow, brave target ... are you prepared to double up build time ? :)
[15:27] <rtg> ogra_, hey, thats just what my arm dudes are telling me....
[15:28] <rtg> why would it double up build time ?
[15:28] <BenC> rtg: do we really have a ppc64 port?
[15:28] <ogra_> rtg, omap  and omap4 are built on pandas 
[15:28] <rtg> BenC, we've been building it. dunno if anyone is using it.
[15:29] <ogra_> so adding one new binary will get you one more build
[15:29] <BenC> I can't see it being built because there is no DEB_BUILD_ARCH=ppc64 on ubuntu
[15:29] <rtg> ogra_, it should be a wash if we can collapse arm4/5 into one binary
[15:29] <BenC> We have a powerpc64 kernel build for arch=powerpc
[15:30] <ogra_> rtg, we can do that already for omap ... prob here is that if we want to go on to support desktop on panda we'll have to add all the patches
[15:30] <ogra_> (mainline allows a single binary kernel for omap/omap4 atm)
[15:31] <BenC> rtg: I'll take care of it from here, thanks for setting up the tree
[15:31] <amitk> rtg: unified arm kernel was just a demo last week, there are still several problems to solve in real-life to get it into production
[15:31] <rtg> BenC, np. IIRC we pared down the powerpc flavours to just powerpc64-smp since it will also run on a UP
[15:32] <rtg> powerpc64*
[15:32] <rtg> amitk, so, you don't sound optimistic.
[15:33] <BenC>   * ppc64 -- add basic architecture
[15:33] <BenC> Added by Andy Whitcroft for 2.6.38 Feb/2011
[15:35] <rtg> BenC, I get lost in the acronyms for the power arch. ppc64 is different then powerpc64 ?
[15:35] <amitk> rtg: for R? A single fully-functional kernel for all your ARMs? I'm not. As they say in the single zImage world - it's not about the destination, it's about the journey. :)
[15:36] <BenC> rtg: yeah, it's a target for building a native 64-bit powerpc target (full userspace and such) that Debian supports, but we only have 32-bit powerpc userspace port, with 64-bit (powerpc64-smp) kernel
[15:36] <rtg> amitk, then I suppose I should get paolo bringing the ti-omap4 branch up to snuff.
[15:37] <rtg> BenC, ok, then that would be the fallout from an OEM deal that never panned. AFAIK we're only building the arches in debian.ppc/rules.d
[15:37] <amitk> rtg: he should talk to the architects of that work in Linaro, but yes, I'd do that.
[15:37] <BenC> Ok, I'll ditch it for now until I have a port to actually work on
[15:39] <rtg> BenC, cool. I'll consider it all your'n for now.
[15:42]  * ogasawara back in 20
[16:20] <StFS> Hi. I was hoping that 3.5.0-18 would have my alsa patch but it doesn't seem like it does. Is there a way for me to figure out what ubuntu kernel will include the patch for this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1060372
[16:20] <ubot2> Launchpad bug 1060372 in linux (Ubuntu) "No audio from headphone jack on Ultrabase Series 3 with ThinkPad T430" [Medium,In progress]
[16:21] <rtg> bjf, can you try vanilla mainline 3.7-rc4 on that emerald ? 'PERCPU: allocation failed' seems pretty heinous.
[16:23] <bjf> rtg, sure
[16:24] <BenC> rtg: FYI, debian.ppc/config/enforce does not override debian.master/config/enforce. Should I just remove the latter?
[16:24] <BenC> Err, former
[16:24] <rtg> BenC, that sounds right. apw ^^
[16:25] <rtg> BenC, I likely copied it by accident.
[16:25] <BenC> Np
[16:25] <apw> rtg, BenC, indeed it just uses master version and deliberatly so.  if you need to change it do patch that file, but also send it back to us so we can record it as part of our requirements
[16:25] <BenC> Will do
[16:26] <apw> (and fold it back into the master version)
[17:05] <BenC>     CC perf.o
[17:05] <BenC> In file included from util/../perf.h:29:0,
[17:05] <BenC>                  from util/cache.h:7,
[17:05] <BenC>                  from perf.c:12:
[17:05] <BenC> util/../../../arch/powerpc/include/asm/unistd.h:12:29: fatal error: uapi/asm/unistd.h: No such file or directory
[17:05] <BenC> rtg: I'm seeing that when I kick off the build.
[17:05] <BenC> arch/powerpc/include/uapi/asm/unistd.h does indeed exist
[17:05] <BenC> Are you seeing that on other architectures?
[17:07] <rtg> BenC, I'm just building arm (which has a ways to go), so I'm not sure yet. I may have disable perf for all but x86en.
[17:07] <BenC> Disabling do_tools for now
[17:12] <smooth-texan> Where can I download older versions of the Ubuntu kernel?
[17:13] <infinity> smb: Your email seemed to lack the footnote you referenced. :P
[17:14] <infinity> smb: So, I'm not sure precisely which package you're referring to.  But, if it really is "useless" as-is, that's a pretty valid justification for an SRU, and if backporting the whole thing is more readily verifiable and sane than cherry-picking patches, we'll need to look at doing it that way, yes.
[17:27] <BenC> rtg: So for meta, I'm just creating a whole new standalone package, right?
[17:27] <rtg> BenC, yep. you could start with raring-meta from a few commits ago (before ppc was removed)
[17:27] <BenC> Ok
[18:30]  * rtg -> lunch
[19:11]  * henrix -> EOD
=== henrix is now known as henrix_
[19:31] <rtg> apw, just pushed ubuntu-raring-signed. please review before I upload it.
[19:38] <arges> infinity, I think he was referring to bug 1064475
[19:38] <ubot2> Launchpad bug 1064475 in crash (Ubuntu) "crash version is outdated. Needs to import Debian version of the package" [Medium,In progress] https://launchpad.net/bugs/1064475
[19:39]  * ogasawara lunch
[20:00] <bjf> rtg, same results with the mainline kernel
[20:10] <BenC> ogasawara: Any thoughts on moving powerpc specific kernel bugs to the new linux-ppc package?
[20:12] <ogasawara> BenC: that works for me.  Is that package in the archive yet?  /me is not seeing it
[20:13] <BenC> Not yet
[20:13] <BenC> rtf branches for me today and I'm still in the process of testing the builds
[20:13] <BenC> *rtg
[20:14] <ogasawara> BenC: ack, lemme know when it's there and I'll have jsalisbury migrate existing bugs
[20:14] <BenC> Great, thanks
[20:24] <jsalisbury> ogasawara, BenC, ack
[20:25] <infinity> Oo, new kernels.  Yay.
[20:26] <infinity> BenC: Where is this PPC kernel maintenance going to be happening?  With a community hat on, I might want to get in on that action, should you ever drop the ball on a rebase or something. :P
[20:26] <infinity> (Plus, I want to learn apw's new world order of out-of-tree maintenance)
[20:27] <BenC> infinity: I have it on github. What email can I forward the info to you?
[20:27] <BenC> Sent info to ubuntu-powerpc and kernel-team, but I suspect you may not be on either of those
[20:27] <infinity> BenC: I'm on the latter, but I don't read it often.
[20:28] <infinity> BenC: But sending to adconrad@whatever will do fine.
[20:28] <infinity> BenC: You could also pre-emptively give me commit on the github project. ;)
[20:28] <BenC> Is that adconrad as well?
[20:29] <BenC> infinity: You could just fork it and send pull requests :P
[20:29] <infinity> BenC: Looks like.
[20:29] <infinity> BenC: If I'm doing scary things, fork and pull makes sense.  If I'm doing things I intend to actually upload (rebases, security updates, whatever), I'd rather the master repo match the archive.
[20:30] <BenC> infinity: you've been added to the kernel and meta packages
[20:30] <infinity> Danke.
[20:30] <infinity> I don't intend to use this power, except in anger.
[20:31] <infinity> But if you fall behind, I want my PPC kernels to match my x86 kit. :P
[20:31] <BenC> Your vengeance is likely better than most people's whole-hearted attempts at chipping in
[20:33] <rtg> bjf, ack. I'll work on it tomorrow.
[20:33]  * rtg -> EOD
=== BenC_ is now known as BenC