[08:14]  * smb yawns
[09:36] <apw> when things are broken, they are very broken
[09:43] <smb> apw, They can get more broken easily
[09:43] <smb> but not the other way round
[09:43] <cking> breakage is like entropy, always increasing and always unavoidable
[09:43] <apw> heh yeah, i have much internal network outage
[09:43] <apw> dhcp server and radv servers both went on the friz
[09:44] <apw> and now my tunelling has gone wonkey
[12:53] <ppisati> brb
[13:15] <ppisati> http://www.androidcentral.com/google-working-experimental-38-linux-kernel-android
[13:16]  * ppisati wonders if they'll try to use nvidia's opensource tegra driver
[13:17] <apw> ppisati, interesting
[13:20] <ppisati> apw: /me wonders if we can use it for our phablet/nexus7 img
[13:20] <apw> ppisati, indeed.  why don't you find out :)
[13:20] <ogra_> theiur opensource driver is for X, isnt it ?
[13:20] <ogra_> wont help on phablet
[13:21] <ppisati> ogra_: no idea
[13:21] <ppisati> apw: don't think it's ready yet, but i can give it a look
[13:21] <ogra_> and i dont think it has full 3D support in X so wont be of much use on n7 desktop either
[13:22] <ogra_> phablet uses libEGL directly, thats the part they will never make free
[13:26] <rtg> apw, 'binary-arch-deps-$(do_libc_dev_package) += binary-arch-headers' is why headers are not getting packaged in the LTS backport build for Raring.
[13:26] <apw> rtg ?
[13:26] <ppisati> ogra_: "x11, drm, fbdev, and gdi" which backend do we use with libegl?
[13:27] <apw> rtg, how does that work in any version if that is true
[13:27] <rtg> apw, bug #1134441
[13:27] <ubot2`> Launchpad bug 1134441 in linux-lts-raring (Ubuntu Precise) "kernel headers are missing from 3.8" [Undecided,In progress] https://launchpad.net/bugs/1134441
[13:27] <rtg> apw, becasue we set that flag false for the LTS backport build
[13:27] <apw> rtg, obviously we don't want libc making back there though
[13:27] <apw> rtg, and how does it work in the quantal lts backport
[13:27] <rtg> apw, dunno, was just gonna go have a look
[13:27] <apw> rtg that change is nothing new
[13:28] <apw> rtg, and remember binary-arch-headers is in more than one place, depending on settings
[13:29] <apw> rtg, and binary-arch-headers is _not_ the headers for the kernel, that is only libc-dev
[13:29] <rtg> apw, well, hmm.
[13:30] <rtg> apw, what builds linux-headers*all.deb ?
[13:31] <apw> rtg,  install
[13:31] <rtg> install-headers
[13:31] <apw> rtg, ie binary-arch
[13:31] <apw> rtg, so binary-arch-headers is only about libc-dev, binary/install et al all make the headers
[13:32] <apw> binary-headers is a convienience for you as a human and not used internally iirc
[13:32] <ogra_> ppisati, gralloc
[13:32] <apw> rtg, search for "        # The flavour specific headers image
[13:34] <apw> rtg, this is on the raring backport branch right ?  
[13:34] <rtg> apw, yep
[13:34]  * apw pokes
[13:42] <apw> rtg, any idea when we might see 3.8.1, cause this had is pissing me right off
[13:42] <apw> heap
[13:42] <rtg> apw, today according to his announcement
[13:43] <apw> as soon as you have it i want want want want *stamp foot* *cry*
[13:45]  * apw is getting grumpy a losing his environment every other hour
[13:45] <apw> and this is too hard to reporoduce to be able to bisect it reliablly
[13:45] <apw> and not far enough apart to not be annoying
[13:47] <apw> rtg, not that there is any hope that it will be fixed by that, there is none of the flip fixes in there, bugger
[14:05] <apw> rtg, got it, its that -SRCPKG thing agian
[14:05] <rtg> yeah, I was just getting to that conclusion
[14:05] <apw> dh_installchangelogs -plinux-lts-raring-headers-3.8.0-7
[14:05] <rtg> must be in a control file
[14:06]  * apw will sort it out
[14:06] <rtg> apw, k, I'll go back to the N7 kernel
[14:07] <rtg> apw debian.master/control.stub.in:Package: SRCPKGNAME-headers-PKGVER-ABINUM
[14:08] <apw> rtg, we're not using those in theory
[14:08] <apw> rtg, as we are on the branch
[14:08] <apw> and control is right actually as we make the right package name in the output
[14:08] <apw> but we don't put the shit in the right place, so it is empty
[14:11] <apw> rtg, this is all because we don't let the indep package change name, which we should really do
[14:11] <apw> these lts-backports packages are a bit of a mess ... arg
[14:12] <rtg> the indep packages are unique because of the ABI number, right ?
[14:12] <apw> they are for lts-backports _only_ because they don't overlap
[14:13] <apw> for example in ppc they are not
[14:13] <apw> or indeed in the linux-lowlatency
[14:13] <apw> so we have to be very careful in changing the indep parts
[14:13] <apw> _or_ more likely we should be letting the indep package in the lts-backports be different
[14:13] <rtg> so you're thinking it _should_ be linux-lts-raring-headers 
[14:14] <apw> perhaps, we can discuss that at 'sprint', the important thing is for now we need to fix that
[14:14] <apw> but only on the lts-backport branch
[14:14] <apw> not in the master, as that is carried over to ppc and lowlatency
[14:14]  * apw confirms this is the issue
[14:14] <rtg> apw, well, if we are going to change the name we need to do it before sprint
[14:20] <apw> rtg, will figure out the deps for ppc and lowlatency and propose somethign on kernel-team@
[14:20] <rtg> ack
[14:20] <apw> we need the change i am having to revert there, so for now i'll do it on the branch
[14:50] <rtg> apw, policy on CONFIG_PATA_ACPI in raring is that it has to be 'y' or 'm', right ?
[14:50] <apw> yeah
[14:50] <rtg> I think it should _never_ be 'y'
[14:51] <rtg> as it will match any storage PCI ID
[14:58] <apw> rtg is it causing an issue? 
[14:58] <rtg> apw, bug #1084783
[14:58] <ubot2`> Launchpad bug 1084783 in linux (Ubuntu Raring) "[Regression] SATA reset failing since Linux 3.6" [High,Fix committed] https://launchpad.net/bugs/1084783
[15:00] <apw> rtg, if the description in that bug is right then indeed it should not be y, it being y is interesting it must have been switch that way for a reason, no idea why tho.
[15:00] <rtg> apw, I couldn't find one either. just thought you might know.
[15:01] <rtg> I'm gonna make the policy 'm'
[15:01] <apw> nope i dont recall, perhaps uni-cum ?
[15:02] <rtg> wtf is uni-cum ?
[15:02] <apw> what we were drinking in bundapesht
[15:02] <rtg> ah :)
[15:03] <apw> rtg, though from its position in the annotation list i would say we did it when we were picking the most common disk device drivers, soh
[15:03] <rtg> likely just a foobar decision then
[15:17] <apw> rtg, what was teh headers thing bug #
[15:18] <rtg> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1084783
[15:18] <ubot2`> Launchpad bug 1084783 in linux "[Regression] SATA reset failing since Linux 3.6" [High,Fix committed]
[15:18] <apw> ta
[15:18] <rtg> apw, nm
[15:18] <apw> oh thats the other one
[15:18] <rtg> apw, yeah, looking. hang on
[15:19] <rtg> apw, bug #1134441
[15:19] <ubot2`> Launchpad bug 1134441 in linux-lts-raring (Ubuntu Precise) "kernel headers are missing from 3.8" [Undecided,In progress] https://launchpad.net/bugs/1134441
[15:30]  * ppisati kicks a new arm build and evaporates for a bit
[15:30]  * ogasawara back in 20
[15:40] <rtg> apw, working on v3.8.1. should have it in a bit
[15:40] <apw> great
[15:42] <rtg> apw, I was within 30 seconds of uploading for that PATA_ACPI boto fix when I noticed your build daemon email
[15:42] <rtg> boot*
[15:42] <apw> rtg ?  boto daemon?
[15:43] <rtg> boot fix
[15:43]  * apw cannot recall this boot fix
[15:44] <rtg> apw, bug #1084783 is a boot failure
[15:44] <ubot2`> Launchpad bug 1084783 in linux (Ubuntu Raring) "[Regression] SATA reset failing since Linux 3.6" [High,Fix committed] https://launchpad.net/bugs/1084783
[15:45] <apw> rtg i don't recall sending any email about that one, you sure it was me
[15:45] <rtg> apw, 'Mainline Build v3.8.1'
[15:46] <rtg> that one ^
[15:46] <rtg> isn't that your build bot somewhere ?
[15:46] <apw> yeah it is a build bot jobby
[15:46] <apw> now i get you, yo mean you uploaded just before seeing there was a .1 you could rebase to at the saem time
[15:47] <rtg> I *almost* uploaded. caught it just in time. now I have to go remove the tag etc
[15:47] <apw> heh
[16:13]  * ppisati disappears again
[16:42] <Windows> Hello is this the English Channel?
[16:44] <rtg> apw, zinc.canonical.com:~rtg/linux-image-3.8.0-9*
[16:44] <apw> Windows, it is an ubuntu kernel discussion channel, wherein people know english
[16:45] <Windows> apw: German?
[16:45] <Windows> apw: Where can I find a german channel?
[16:45] <apw> not me
[16:45] <apw> #ubuntu-de ?
[16:46] <Windows> apw: I have got a question about the kernel!
[16:46]  * rtg bounces
[16:57] <BenC> infinity: ppc kernel about to be uploaded
[16:59] <apw> Windows, then as per the topic, ask it and see what happens
[17:04] <rtg> apw, did you have a patch for the raring LTS headers issue yet ?
[17:19] <rtg> apw, never mind. I fixed it.
[17:35] <BenC> rtg: when are you guys going to switch to using an upstream tar ball with 3.8?
[17:36] <rtg> BenC, usually just before handoff prior to release. guess thats coming right up.
[17:37] <BenC> Ok
[17:37] <rtg> BenC, I'll try to remember it for the next upload.
[17:58] <infinity> BenC: Ah, wasn't around.  Oh well, you get adare.
[18:26]  * rtg -> lunch
[18:39] <apw> rtg, you changed that indep thing on master-next in raring, that is the wrong place, that will break ppc et al
[19:03] <rtg> apw, you're sure ?
[19:06] <rtg> apw, ok, dropped that patch for now
[19:11] <apw> rtg, yeah they both have full header sets, including their own independant common header, to allow them to migrate britney independantly
[19:11] <rtg> apw, ok, I've just left it in the LTS branch
[19:17] <unkle_george> This is more of a glibc/alloc thing, but maybe someonehere can explain it to me:  "deallocated space is not placed
[19:17] <unkle_george>  on the free list for reuse by later allocations" http://man7.org/linux/man-pages/man3/mallopt.3.html
[19:18] <unkle_george> So any allocations over 128k are not reusable by my app even after free?
[19:19] <unkle_george> while(1) {delete [](new char[128*1024]);} will eventually exhuast memory space?
[20:07] <rtg> henrix, I think 'Re: [PATCH 018/139] tty: Prevent deadlock in n_gsm driver' on the kteam list is directed at you.
[20:30] <rtg> apw, pushed N7 again with some config updates. seems to work OK on the desktop.
[20:31] <henrix> rtg: checking
[20:33] <henrix> rtg: interesting, looks like we're not building that driver in with our config.
[20:34] <henrix> rtg: i need to take a closer look at that
[20:34] <rtg> henrix, you should likely be building vanilla stable with allyesconfig
[20:35] <henrix> rtg: i was testing with the same config we use for the mainline builds
[20:35] <rtg> henrix, which I beleive is derived from Ubuntu
[20:35] <henrix> rtg: most likely. i'll start doing that. thanks
[20:59]  * rtg -> EOD
[21:23] <ppisati> do any of you know how i can debug a dkms pkg? IOW it doesn't want to apply one of the patch that are "there"
[21:23] <ppisati> if i explode .deb, go inside and manually apply the patch, it works ok
[21:24] <ppisati> but during the installation, that patch is not applied
[21:24] <ppisati> (but it's there, it's corrent and it's in the right place)
[21:24] <ppisati> grrr...
[21:44]  * ppisati has found the problem... :P
[21:55] <JanC> ppisati: so, what was it?
[21:59] <ppisati> JanC: spoke too early...
[22:08] <ppisati> JanC: mispelled patch in dkms.conf.in
[22:08] <ppisati> but now i've another problem... uhm...
[22:11] <JanC> sounds... interesting  ☺
[22:16] <JanC> about debugging: I suppose you already checked if the build log has some useful info?
[22:56] <Redoubt> 1swutrif;QWE