[08:24] <ppisati> moin
[08:53] <apw> moin
[09:48] <zequence> apw: both lowlatency ready to be pulled
[09:53] <apw> zequence, more ?
[09:54] <zequence> apw: hmm, more?
[09:55] <zequence> apw: Oh, and I wanted to ask you if now would be a good time to hand over the prepare package bit too?
[10:00] <apw> zequence, yes it probabally is a good time to start that
[10:13] <apw> zequence, i'll get myself suitibly caffinated and put together a short description
[10:13] <apw> zequence, then you can make one, and i'll do the same for comparison
[10:19] <zequence> apw: I'll do the same (get myself some coffee) :)
[11:26] <apw> zequence, just dropped you a potted instruction set on makeing the packages have a read and then we can have a go
[11:27] <zequence> apw: Yes, thanks. A very thorough one as well
[11:29] <apw> zequence, i don't know if you have somewhere you can publish those easily, perhaps google drive would work, or ubuntu one, as ideas
[11:33] <zequence> apw: Can't I just push to a PPA?
[11:34] <apw> zequence, that would work i think, i can just copy it out of there into our one once happy to get it in the process
[11:34] <apw> zequence, so, lets try that :)
[11:35] <apw> zequence, i suggest you make a new PPA for your attemps as once you get it wrong the PPA can get broken and need removing, which is annoying if it is a useful one
[11:38] <zequence> apw: Yes, I'm creating one specifically for lowlatency SRUs only
[11:38] <apw> zequence, sweet, that works welll then our process becomes 'pocket copy the packages when happy' which is nice
[11:41] <apw> zequence, this covers the main packages, when we have this working i'll show you the meta packages and you will be self-sufficient
[11:48] <apw> zequence, then i can write it up for my team so anyone can help with it too, win win
[11:56] <zequence> apw: Sounds great
[12:27] <ppisati> that's what i'm saying:
[12:27] <ppisati> flag@flag-desktop:~$ find /usr/src/linux-headers-3.5.0-17/drivers/ -name \*.h | wc -l
[12:27] <ppisati> 177
[12:27] <ppisati> flag@flag-desktop:~$ find /usr/src/linux-headers-3.8.0-7/drivers/ -name \*.h | wc -l
[12:28] <ppisati> 0
[12:28] <ppisati> and i need one of those headers for a dkms
[12:29] <zequence> apw: So, the packages are awaiting build at ppa:zequence/linux-lowlatency. I'll let you know when they finish. The only addition I had to make to the procedure was changing the release in the changelog from "precise-proposed" to "precise". I suspect this is what you do for the Canonical PPA as well?
[12:30] <apw> zequence, actually we normally change the name in the .changes file and re-sign it ... that said the archive now knows you mean precise-proposed when you say precise now so it no longer matters, so in short what you have done makes sense
[12:30] <apw> zequence, i have recently changed the lowlatency rebase script in raring to remove the -proposed bit permenatly we might want to do that anyhow
[12:30] <apw> in the ones in P and Q as it no longer matteres
[12:31] <apw> ppisati, the flavours header package is actually using include only in raring
[12:32] <zequence> apw: I see, I see
[12:32] <apw> ppisati, and if a header is outside there it seems to be copied by hand specifically by name in 3-binary-indep.mk
[12:33] <ppisati> apw: ah, found!
[12:33] <ppisati> "cp -a drivers/staging/omapdrm/omap_dr*.h $(indep_hdrdir)/drivers/staging/omapdrm"
[12:34] <ppisati> that's what i need
[12:34] <apw> so we need an equivalent indeed in raring, spin a patch and i'll get it in
[12:34] <ppisati> apw: i'll do
[12:35] <ppisati> 1fd90d0b88f66b1759b498b8c00dbbe43c672f85
[12:35] <ppisati> UBUNTU: [Config] installing omapdrm specific headers for external drivers
[12:35] <ppisati> we already have it
[12:37]  * rtg grinds through 93 emails in ubuntu-devel
[12:40]  * ppisati builds another kernel
[12:49]  * rtg goes to figure out why his server isn't booting
[13:27] <rtg> cking, henrix: bouncing gomeisa for kernel and ssl update
[13:30] <ppisati> rtg: if yo've to do the same on tangerine, let me finish a build first
[13:30] <rtg> ppisati, will get to it _after_ gomeisa comes back.
[13:30] <henrix> rtg: ack
[13:37] <cking> ack
[13:48] <rtg> cking, henrix: gomeisa is back
[13:48] <henrix> rtg: ack, thanks
[13:48] <rtg> ppisati, lemme know when your build is complete non tangerine
[13:50] <ppisati> rtg: ok
[14:20] <ppisati> rtg: go ahead
[14:20] <rtg> ppisati, ack
[14:20] <rtg> jjohansen, rebooting tangerine ?
[14:30] <rtg> tangerine is _such_ a pain in the ass to reboot
[14:34] <rtg> ppisati, tangerine should be back
[14:41] <cking> rtg, why? cos it gets stuck or just slow to spin up again?
[14:41] <rtg> cking, it won't shut down after it has accumulated a zillion chroot mount points. something to do with upstart I think
[14:43] <ppisati> rtg: yep
[15:23]  * ogasawara back in 20
[16:07] <lfaraone> Is there a way to get advanced notification of new proposed kernels for precise that are going to get rolled in as a stable update? 
[16:08] <lfaraone> the recent kernel update adversely affected a rather large deployment because of #1015925
[16:08] <lfaraone> LP 1015925
[16:08] <ubot2`> Launchpad bug 1015925 in openafs (Ubuntu Precise) "openafs: Support quantal’s kernel 3.5" [High,In progress] https://launchpad.net/bugs/1015925
[16:13] <apw> zequence, those source packages seem ok indeed -- will copy them over and see what happens
[16:14] <apw> zequence, a good thought to use a ppa here, it looks to be a simple workflow for us
[16:16] <bjf> lfaraone, i'm not sure what exactly you are asking for
[16:17] <bjf> lfaraone, we run a 3-week cadence. new kernels hit proposed approx. every 3 weeks
[16:21] <apw> zequence, ok copied over ... looking to be working well ... plus i have pushed your source too
[16:21] <apw> zequence, this is getting close
[16:23] <apw> lfaraone, yeah kerenls which are coming to a release pop into the -proposed pocket some two weeks minimum before they would make -updates
[16:24] <apw> lfaraone, and i would not expect this to affect anyone who didn't opt into the 3.5 kernel which they would have not done accidentally ?
[16:24] <zequence> apw: nice!
[16:25] <lfaraone> apw: this apparently hit users who did not "opt in". 
[16:25] <apw> lfaraone, how ?  if they havent' opted in they won't have any 3.5 kernels to affect the dkms package
[16:25] <lfaraone> apw: how does one opt-in?
[16:26] <apw> lfaraone, by installing the linux-lts-backports-* meta package normally
[16:26] <apw> if this was a new install from .2 then they might i guess have had this but then that ought to be a new install and by definition tested before use
[16:26] <rtg> or installing from the 12.04.2 point release
[16:26] <apw> so i am somewhat confused how an existing install got broke
[16:27] <apw> rtg, indeed that was what i was trying to say
[16:27] <rtg> apw, you don't suppose the headers got trashed, do you ?
[16:27] <lfaraone> apw: sorry, we had people reinstall Ubuntu on their workstations at MIT and it made OpenAFS sad
[16:27] <apw> rtg, i don't think so, in this case the dkms package is not 3.5 aware in precise so any 3.5 kernel on the system will break it
[16:28] <rtg> ok, so that makes it hard to claim that an existing functional installation broke unless the kernel release was upgraded
[16:28] <apw> lfaraone, so thats just a basic failure to test in advance error (which sounds harsh) not us breaking existing installs at least
[16:28] <apw> lfaraone, obviously it should be fixed, and it think has been indeed
[16:29] <apw> rtg, do we announce when we add a new lts-backports-foo kernle to precise or whereever anywhere ?
[16:29] <lfaraone> apw: I didn't say you broke existing installs. 
[16:29] <apw> lfaraone, no probabally not, i inferred it from what little irc i read and the bug
[16:30] <rtg> apw, kteam list
[16:30] <Sarvatt> apw: 12.04.2 release notes
[16:30] <apw> lfaraone, so all i am saying is good, we havent' broken everyone in the world here only people installing fresh
[16:30] <apw> lfaraone, so that is less frightening than i thought it was
[16:30] <rtg> point release install then ?
[16:31] <apw> lfaraone, so it sounds like we announce them in the .x release notes and on our main kernel-team@ mailing list
[16:31] <apw> seems so indeed rtg
[16:32] <lfaraone> The main thing that's confusing is if a user says  "I'm running Ubuntu 12.04 and have applied all the updates", we still have no idea i.e what kernel they're running. 
[16:32] <apw> i can see that indeed, a trade off between stable versions and modern hardware support
[16:32] <rtg> lfaraone, note that you can also be testing against a 3.8 Ubuntu kernel from https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport by installing linux-generic-lts-raring
[16:33] <apw> in older releases.  not an easy trade off to make without some confusion
[16:33] <lfaraone> So it becomes a world where we have to test both upgrades and new installs, in order to catch things like this.
[16:34] <lfaraone> apw: To ensure this doens't happen again, should I subscribe to kernel-team? or is there a way to just get messages about proposed kernels and not other traffic? 
[16:34] <rtg> lfaraone, have you tried to upstream your driver ?
[16:39] <apw> lfaraone, we normally announce anything significant there indeed.  like when rtg started publishing the 3.8 lts backport kernels for testing they would have been announced there
[16:39] <apw> lfaraone, and those are likely to come to precise in the same manner in the next point release i would assume
[16:51] <rtg> ogasawara, you have any USB 3.0 gizmos ? just pushed the patches for bug #1011415
[16:51] <ubot2`> Launchpad bug 1011415 in intel "[Feature] USB3 Port power off mechanism " [Undecided,New] https://launchpad.net/bugs/1011415
[16:51] <ogasawara> rtg: I don't unfortunately
[16:52] <rtg> hmm, I wonder who does....
[16:53] <apw> ogasawara, rtg, wasn't it manjo who had such things
[16:53] <apw> and just maybe sforshee may have said he had something
[16:53] <apw> i have a disk which claims to be it, but i don't think i have anything with a blue hole to shove it in
[16:54] <sforshee> rtg, I do have a USB 3.0 flash drive
[16:54] <rtg> I'm inclined to just turn it loose on the word, then go away on vacation :)
[16:54] <cking> apw,  you have that intel laptop
[16:54] <rtg> world*
[16:54] <apw> cking, ahh maybe that has one
[16:54] <cking> apw, reckon it does
[16:56] <sforshee> based on the bug description I wouldn't think that the peripheral itself needs to be 3.0, just the port
[16:56] <manjo> was wondering why this is USB 3.0 specific and not to the whole of usb 
[16:57] <manjo> ie usb ports that are unused 
[16:57] <apw> rtg, i note that the request says "most" ... are we sure this is even complete
[16:57] <sforshee> I'm thinking it's a feature of their USB 3.0 host hw to turn off vbus
[16:58] <rtg> apw, it is what is upstream so far
[16:58] <rtg> at least it does not appear to have wretched USB2.0
[16:58] <apw> rtg, and it is no use without the userspace bits, that description implies the sysfs interface is not yet set in stone ... so there won't be anything using ti either
[16:59] <apw> might we actually be jumping the gun if the abi might change
[16:59] <rtg> apw, the ABI cannot change if these commits are in the 3.9 merge window
[16:59] <apw> rtg, it could if they change it before 3.9 final
[17:00] <cking> sforshee, I like the reference in the bug to " If BIOS writers have done their job right..."  -  some hope
[17:00] <sforshee> apw, the description in comment #5 indicates it would be used to power off unused internal ports, which I presume requires no userspace interaction
[17:00] <sforshee> cking, ;-)
[17:01] <rtg> I wonder what sarah thinks about 'em. I'm happy to retract 'em, but they also don't appear to be doing any harm.
[17:03] <cking> sforshee, it seems to imply that we should add some user space interaction with it on specific events, like screen blanking
[17:03] <sforshee> cking, for external ports yes
[17:03]  * cking wonders how much extra power it saves
[17:06] <manjo> cking, its in mAmps x 5v ... 
[17:07] <sforshee> of course the question is how much current is used to power vbus when no device is attached
[17:08] <cking> i doubt it will keep my laptop alive for an extra 30 mins then
[17:09]  * ppisati -> EOW
[17:09] <manjo> I think the displays eat more battery than unused usb ports 
[17:10] <cking> bah, I'm now so curious I'm itching to get the power meter onto this..
[17:10] <manjo> s/more/faster
[17:15] <manjo> cking, but that quirk seems more appropriate for mobile devices 
[17:17] <sforshee> manjo, mobile devices don't typically operate as usb hosts. I'm not sure about the details of how OTG works however.
[17:18] <apw> or indeed have any ports worth speaking about
[17:21] <manjo> deviating slightly ... have you guys seen this ? http://www.apple.com/thunderbolt/ it can provide up to 10Watts to devices
[17:23] <manjo> we will soon need nuclear powered batteries at this rate 
[17:24] <sforshee> I'd hope there's some kind of negotiation involved so that a laptop running only on battery could limit power draw to something more reasonable
[17:24] <apw> i am amazed the port doesn't melt pulling that sort of current
[17:25] <kamal> 10W!?   I can make ham radio contacts with that!
[17:26] <sforshee> 18V at 550 mA, wow
[17:28] <apw> kamal, you will probabally be making contact with people via radio whether you intend it or not at that power and frequencies
[17:28] <kamal> apw: hahaha!
[17:32] <cking> hrm, thunderbolt powered taser...
[17:39] <manjo> cking, yeah there is an app for that 
[17:39] <apw> cking, whats that about 3 ports would be enough to kill you i recon
[17:39] <cking> depends what you taser really
[17:39] <sforshee> manjo, I was curious about the OTG thing so I looked it up
[17:39] <manjo> yeah me too ... 
[17:40] <manjo> :) 
[17:40] <sforshee> for OTG there's a different connector type with an extra pin and two different plug types, A for plugging in a peripheral and B for connecting to a PC
[17:40] <sforshee> the new pin on the A-type cable is grounded, so I suspect a mobile device puts a weak pull-up on that pin and only turns on vbus when it detects the pin being pulled low
[17:40] <manjo> I wonder what kind of efficiencies they get .... 80% ? 
[17:41] <manjo> cking, tasers are old school now ... replaced with drones now 
[17:43] <cking> sforshee, http://www.maximintegrated.com/app-notes/index.mvp/id/1822
[17:47] <sforshee> cking, that's a nice description. It doesn't quite confirm what I said, but I can't think of any other way it would work.
[17:47] <cking> once I need piccies of the H/W schematics I get a better idea of how it all hangs togther
[17:48] <cking> s/need/get/
[17:48] <sforshee> yeah, it's helpful. But it just shows the id pin as going off into the ether or something.
[17:48] <cking> indeed, a bit weird that
[17:49] <apw> bjf, fyi i only marked the upload-to-ppa tasks in progress and everything else has done its thing magically including closing that task too
[17:49] <bjf> apw, thanks, good to know
[17:49] <sforshee> cking, but the way I've typically seen that done is to pull up the signal and look for a high-to-low transition
[17:49] <apw> bjf, only slight wrinkle is it has picked the wrong person as the owner of upload-to-ppa, it would be more right to use the copier if that information was available in the interfaces it is using
[17:50] <sforshee> cking, for a b-type cable you wouldn't see that because the id pin will still be floating
[17:50] <cking> ok
[17:50]  * cking ~~> food
[17:57]  * manjo off to school .. 
[18:21] <apw> bjf, in the ckt ppa i see some natty packages, we could zap those i assume
[18:25] <infinity> ikepanhc: How is it that armadaxp is the only flavour that didn't bump ABI in precise?  Did something get messed up there?
[18:27] <lfaraone> apw:  cool, thanks
[18:27] <lfaraone> rtg: that's not possible, sadly, for licensing reasons. 
[18:27] <lfaraone> http://git.openafs.org/?p=openafs.git;a=blob;f=doc/LICENSE
[18:28] <lfaraone> there's a choice of law clause which is GPL-incompatible.
[18:29] <lfaraone> There's kAFS which is in the kernel, but kAFS is basically a bad idea based off a misunderstanding which doesn't support things like authentication. 
[18:29] <apw> lfaraone, has anyone asked ibm if they can relicence it, they have been receptive in the past
[18:31] <apw> lfaraone, it may take them a year of course, but they like gpl
[18:33] <infinity> ikepanhc: Hrm, looks like the ABI checker ran, so assuming you had the right ABI files from the previous version, I guess it didn't lie.  Weird.  The ABI bump must have been x86-specific.
[18:34]  * rtg -> lunch
[18:38] <lfaraone> apw: I asked around, and heard back "yes, and no because $politics and $embargoed_reasons"
[18:39] <apw> heh
[18:40] <lfaraone> apw: this apparently was brought up ages ago and people are still talking about it. 
[18:48]  * henrix -> EOD
[20:20]  * rtg -> eow
[20:59] <ikepanhc> infinity: I do not fully check the abi number, the checker do not ask for bump abi number
[21:00] <ikepanhc> s/number/hash
[21:06] <bjf> ikepanhc, where is your git repo for armadaxp?
[21:07] <ikepanhc> bjf: git://kernel.ubuntu.com/hwe/armadaxp-{precise,quantal}.git
[21:07] <bjf> ikepanhc, thanks
[21:11] <bjf> ikepanhc, is that really: git://kernel.ubuntu.com/hwe/ubuntu-{precise,quantal}-armadaxp.git ?
[21:21] <ikepanhc> bjf: yes, sorry, just wake
[21:21] <bjf> ikepanhc, np