=== BruceMa is now known as BruceMa_afk === mainerror_ is now known as mainerror [08:24] moin [08:53] moin === henrix_ is now known as henrix === smb` is now known as smb [09:48] apw: both lowlatency ready to be pulled [09:53] zequence, more ? [09:54] apw: hmm, more? [09:55] 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] zequence, yes it probabally is a good time to start that [10:13] zequence, i'll get myself suitibly caffinated and put together a short description [10:13] zequence, then you can make one, and i'll do the same for comparison [10:19] apw: I'll do the same (get myself some coffee) :) [11:26] zequence, just dropped you a potted instruction set on makeing the packages have a read and then we can have a go [11:27] apw: Yes, thanks. A very thorough one as well [11:29] 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] apw: Can't I just push to a PPA? [11:34] 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] zequence, so, lets try that :) [11:35] 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] apw: Yes, I'm creating one specifically for lowlatency SRUs only [11:38] zequence, sweet, that works welll then our process becomes 'pocket copy the packages when happy' which is nice [11:41] 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] zequence, then i can write it up for my team so anyone can help with it too, win win [11:56] apw: Sounds great [12:27] that's what i'm saying: [12:27] flag@flag-desktop:~$ find /usr/src/linux-headers-3.5.0-17/drivers/ -name \*.h | wc -l [12:27] 177 [12:27] flag@flag-desktop:~$ find /usr/src/linux-headers-3.8.0-7/drivers/ -name \*.h | wc -l [12:28] 0 [12:28] and i need one of those headers for a dkms [12:29] 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] 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] 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] in the ones in P and Q as it no longer matteres [12:31] ppisati, the flavours header package is actually using include only in raring [12:32] apw: I see, I see [12:32] 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] apw: ah, found! [12:33] "cp -a drivers/staging/omapdrm/omap_dr*.h $(indep_hdrdir)/drivers/staging/omapdrm" [12:34] that's what i need [12:34] so we need an equivalent indeed in raring, spin a patch and i'll get it in [12:34] apw: i'll do [12:35] 1fd90d0b88f66b1759b498b8c00dbbe43c672f85 [12:35] UBUNTU: [Config] installing omapdrm specific headers for external drivers [12:35] 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 === Nafallo_ is now known as Nafallo [13:27] cking, henrix: bouncing gomeisa for kernel and ssl update [13:30] rtg: if yo've to do the same on tangerine, let me finish a build first [13:30] ppisati, will get to it _after_ gomeisa comes back. [13:30] rtg: ack [13:37] ack [13:48] cking, henrix: gomeisa is back [13:48] rtg: ack, thanks [13:48] ppisati, lemme know when your build is complete non tangerine [13:50] rtg: ok [14:20] rtg: go ahead [14:20] ppisati, ack [14:20] jjohansen, rebooting tangerine ? [14:30] tangerine is _such_ a pain in the ass to reboot [14:34] ppisati, tangerine should be back [14:41] rtg, why? cos it gets stuck or just slow to spin up again? [14:41] cking, it won't shut down after it has accumulated a zillion chroot mount points. something to do with upstart I think [14:43] rtg: yep === kentb-afk is now known as kentb [15:23] * ogasawara back in 20 === jmp is now known as Guest89697 === Guest89697 is now known as _jmp_ [16:07] 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] the recent kernel update adversely affected a rather large deployment because of #1015925 [16:08] LP 1015925 [16:08] Launchpad bug 1015925 in openafs (Ubuntu Precise) "openafs: Support quantal’s kernel 3.5" [High,In progress] https://launchpad.net/bugs/1015925 [16:13] zequence, those source packages seem ok indeed -- will copy them over and see what happens [16:14] zequence, a good thought to use a ppa here, it looks to be a simple workflow for us [16:16] lfaraone, i'm not sure what exactly you are asking for [16:17] lfaraone, we run a 3-week cadence. new kernels hit proposed approx. every 3 weeks [16:21] zequence, ok copied over ... looking to be working well ... plus i have pushed your source too [16:21] zequence, this is getting close [16:23] 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] 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] apw: nice! [16:25] apw: this apparently hit users who did not "opt in". [16:25] lfaraone, how ? if they havent' opted in they won't have any 3.5 kernels to affect the dkms package [16:25] apw: how does one opt-in? [16:26] lfaraone, by installing the linux-lts-backports-* meta package normally [16:26] 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] or installing from the 12.04.2 point release [16:26] so i am somewhat confused how an existing install got broke [16:27] rtg, indeed that was what i was trying to say [16:27] apw, you don't suppose the headers got trashed, do you ? [16:27] apw: sorry, we had people reinstall Ubuntu on their workstations at MIT and it made OpenAFS sad [16:27] 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] ok, so that makes it hard to claim that an existing functional installation broke unless the kernel release was upgraded [16:28] lfaraone, so thats just a basic failure to test in advance error (which sounds harsh) not us breaking existing installs at least [16:28] lfaraone, obviously it should be fixed, and it think has been indeed [16:29] rtg, do we announce when we add a new lts-backports-foo kernle to precise or whereever anywhere ? [16:29] apw: I didn't say you broke existing installs. [16:29] lfaraone, no probabally not, i inferred it from what little irc i read and the bug [16:30] apw, kteam list [16:30] apw: 12.04.2 release notes [16:30] lfaraone, so all i am saying is good, we havent' broken everyone in the world here only people installing fresh [16:30] lfaraone, so that is less frightening than i thought it was [16:30] point release install then ? [16:31] lfaraone, so it sounds like we announce them in the .x release notes and on our main kernel-team@ mailing list [16:31] seems so indeed rtg [16:32] 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] i can see that indeed, a trade off between stable versions and modern hardware support [16:32] 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] in older releases. not an easy trade off to make without some confusion [16:33] So it becomes a world where we have to test both upgrades and new installs, in order to catch things like this. [16:34] 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] lfaraone, have you tried to upstream your driver ? [16:39] 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] lfaraone, and those are likely to come to precise in the same manner in the next point release i would assume [16:51] ogasawara, you have any USB 3.0 gizmos ? just pushed the patches for bug #1011415 [16:51] Launchpad bug 1011415 in intel "[Feature] USB3 Port power off mechanism " [Undecided,New] https://launchpad.net/bugs/1011415 [16:51] rtg: I don't unfortunately [16:52] hmm, I wonder who does.... [16:53] ogasawara, rtg, wasn't it manjo who had such things [16:53] and just maybe sforshee may have said he had something [16:53] 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] rtg, I do have a USB 3.0 flash drive [16:54] I'm inclined to just turn it loose on the word, then go away on vacation :) [16:54] apw, you have that intel laptop [16:54] world* [16:54] cking, ahh maybe that has one [16:54] apw, reckon it does [16:56] based on the bug description I wouldn't think that the peripheral itself needs to be 3.0, just the port [16:56] was wondering why this is USB 3.0 specific and not to the whole of usb [16:57] ie usb ports that are unused [16:57] rtg, i note that the request says "most" ... are we sure this is even complete [16:57] I'm thinking it's a feature of their USB 3.0 host hw to turn off vbus [16:58] apw, it is what is upstream so far [16:58] at least it does not appear to have wretched USB2.0 [16:58] 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] might we actually be jumping the gun if the abi might change [16:59] apw, the ABI cannot change if these commits are in the 3.9 merge window [16:59] rtg, it could if they change it before 3.9 final [17:00] sforshee, I like the reference in the bug to " If BIOS writers have done their job right..." - some hope [17:00] 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] cking, ;-) [17:01] 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] sforshee, it seems to imply that we should add some user space interaction with it on specific events, like screen blanking [17:03] cking, for external ports yes [17:03] * cking wonders how much extra power it saves [17:06] cking, its in mAmps x 5v ... [17:07] of course the question is how much current is used to power vbus when no device is attached [17:08] i doubt it will keep my laptop alive for an extra 30 mins then [17:09] * ppisati -> EOW [17:09] I think the displays eat more battery than unused usb ports [17:10] bah, I'm now so curious I'm itching to get the power meter onto this.. [17:10] s/more/faster [17:15] cking, but that quirk seems more appropriate for mobile devices [17:17] manjo, mobile devices don't typically operate as usb hosts. I'm not sure about the details of how OTG works however. [17:18] or indeed have any ports worth speaking about [17:21] deviating slightly ... have you guys seen this ? http://www.apple.com/thunderbolt/ it can provide up to 10Watts to devices [17:23] we will soon need nuclear powered batteries at this rate [17:24] 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] i am amazed the port doesn't melt pulling that sort of current [17:25] 10W!? I can make ham radio contacts with that! [17:26] 18V at 550 mA, wow [17:28] kamal, you will probabally be making contact with people via radio whether you intend it or not at that power and frequencies [17:28] apw: hahaha! [17:32] hrm, thunderbolt powered taser... [17:39] cking, yeah there is an app for that [17:39] cking, whats that about 3 ports would be enough to kill you i recon [17:39] depends what you taser really [17:39] manjo, I was curious about the OTG thing so I looked it up [17:39] yeah me too ... [17:40] :) [17:40] 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] 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] I wonder what kind of efficiencies they get .... 80% ? [17:41] cking, tasers are old school now ... replaced with drones now [17:43] sforshee, http://www.maximintegrated.com/app-notes/index.mvp/id/1822 [17:47] 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] once I need piccies of the H/W schematics I get a better idea of how it all hangs togther [17:48] s/need/get/ [17:48] yeah, it's helpful. But it just shows the id pin as going off into the ether or something. [17:48] indeed, a bit weird that [17:49] 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] apw, thanks, good to know [17:49] 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] 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] cking, for a b-type cable you wouldn't see that because the id pin will still be floating [17:50] ok [17:50] * cking ~~> food [17:57] * manjo off to school .. === henrix is now known as henrix_ === henrix_ is now known as henrix [18:21] bjf, in the ckt ppa i see some natty packages, we could zap those i assume [18:25] 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] apw: cool, thanks [18:27] rtg: that's not possible, sadly, for licensing reasons. [18:27] http://git.openafs.org/?p=openafs.git;a=blob;f=doc/LICENSE [18:28] there's a choice of law clause which is GPL-incompatible. [18:29] 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] lfaraone, has anyone asked ibm if they can relicence it, they have been receptive in the past [18:31] lfaraone, it may take them a year of course, but they like gpl [18:33] 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] apw: I asked around, and heard back "yes, and no because $politics and $embargoed_reasons" [18:39] heh [18:40] apw: this apparently was brought up ages ago and people are still talking about it. === henrix is now known as henrix_ === henrix_ is now known as henrix [18:48] * henrix -> EOD === henrix is now known as henrix_ [20:20] * rtg -> eow [20:59] infinity: I do not fully check the abi number, the checker do not ask for bump abi number [21:00] s/number/hash [21:06] ikepanhc, where is your git repo for armadaxp? [21:07] bjf: git://kernel.ubuntu.com/hwe/armadaxp-{precise,quantal}.git [21:07] ikepanhc, thanks [21:11] ikepanhc, is that really: git://kernel.ubuntu.com/hwe/ubuntu-{precise,quantal}-armadaxp.git ? [21:21] bjf: yes, sorry, just wake [21:21] ikepanhc, np === kentb is now known as kentb-out