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