[00:24] kgunn: image fails [00:25] are there older images [00:25] racarr: thanks... rsalveti how far back can we go ? ^ [00:25] I have a copy of [00:25] july 26th [00:25] on my desktop it seems [00:26] thats kind of far though XD [00:26] so 12th would be 1 week...and the bug describes it popping up ~2 weeks ago [00:27] racarr: question...is the hwcomposer.h etc matching from the 12th to current ? [00:27] no hwcomposer.h on the image [00:28] lets check hardare.h though [00:28] racarr: yeah...that's what i meant [00:28] gralloc and fb as well [00:29] yep [00:29] the same [00:29] ok im going to september 26th because [00:29] err [00:29] uly 26th [00:29] because I dont have anything else to do :p [00:31] kgunn: maybe check your ~/Downloads/phablet-flash [00:31] for images? [00:31] though [00:31] i e dont have the images elsewhere [00:31] racarr: will do [00:31] then bisecting probably ont help much [00:32] also...as you're building, check the ubuntu/hybris/hybris/include/android/hardware/ and see how those headers compare [00:32] 26th vs current [00:34] ubuntu/hybrys/hybris/hat [00:34] /what? [00:34] racarr: i have a jul 25th :) [00:34] I have been looking in /usr/include/android [00:35] oops...nvmd...i was looking in source i downloaded [00:35] that's where they are before image creation [00:35] XD [00:35] ./ubuntu/hybris/hybris/include/android/hardware/fb.h [00:35] etc [00:35] thats a hell of a path [00:35] I realized [00:35] e can rule in our out the headers [00:35] in an easy ay [00:36] well that whole theory [00:36] did surface flinger change? [00:36] I guess that doesnt necessarily rule it out [00:36] whathcya mean? [00:37] I mean we have this theory that libhardware changed [00:37] and it broke mir because mir has the static in tree headers [00:37] but if surface flinger didn't change [00:37] that seems unlikely [00:42] racarr: right...but isn't it truly in tree for surface flinger (e.g. he's not gonna get headers outta sync) [00:42] since its all just part of android [00:46] kgunn: Right I am just saying if e literally haven't updated [00:46] the surfaceflinger binary [00:52] havent tested this image yet but want to go get pizza before the bakery closes [00:52] back soon [00:53] racarr: actually....i think i just found a jul 29 & aug 9 images [00:54] I am trying to build mir on this image...but [00:54] build deps are pulling in a hybris upgrade [00:54] so it would be not so surprising if it didn't work? [00:55] ghsdflKSDfljLKsdgjldkfjglkdjglkejrg;lakerjgl;kejrgt [00:55] just a little keyboard mashing :p [00:55] brb pizza [01:09] Ah, yes. [01:09] It's important not to leak fds. [01:14] Huh. Something's broken in our resource cache it seems. [01:32] back [01:35] racarr: dont we rebuild surfaceflinger from source everytime ? (i thot we built the whole android file system...for what we have source for) [01:35] stepping out...biab [01:37] kgunn: yeah I guess its probably never the same [01:37] racarr: just comparing bins of libsurfflinger they are diff between jul 25 & latest [01:37] but not surprising [01:37] ok...really stepping out [01:41] racarr: is surface flinger relevant to the Nexus4 bug? We intentionally disable it to run Mir (usually) [01:45] kgunn: july 26th works! [01:45] duflu: No but one of the theories is that there is a libhardware mismatch [01:45] but I didn't relize we rebuilt surface flinger everytime [01:45] I see [01:46] duflu: Want to check your ~/Downloads/phablet-flash and see if you have any images beteen [01:46] july 26th and august 18th [01:46] and can verify mir orks/doesn't work on them [01:46] bisecting ;) [01:46] but I am out of images [01:46] err august 12th sorry [01:47] ricmm: rsalveti: Any way we can get images from before august 12th [01:48] racarr: Only July 26th (works for me I think) and August 8th (broken) [01:49] August 8th broken. Awesome [01:49] kgunn: ^ [01:50] racarr: At least that appears to be the latest one I have. And the latest broke my N4 [01:50] Though surely we can get image dates/versions from the devices? [01:51] duflu: The problem right now is cdimages.ubuntu.com [01:51] only has back to august 12th :p [01:51] so I am trying to bisect [01:51] racarr: Yeah Albert logged the bug on 13th a few days after he first mentioned it. Because it took me a few days to upgrade and confirm [01:51] but the range is uly 26th to august 8th now [01:52] but there are no images [01:52] inbeteen [01:52] ween [01:52] Spill on keyboard:( [01:52] Pork and beans? [01:52] Argh [01:52] That would be weezer [01:52] I suck [01:58] I guess I will start [01:58] reading changeloads [01:58] racarr: Actually 20130808 may not be accurate. The download date for that was 20130813 and I remember I did an update immediately after [01:59] Will have to reflash it without updates to confirm [01:59] Ah! thanks. [01:59] lxc-android-config (0.67) saucy; urgency=low [01:59] * allow devices that use EFS as label for the factory partition to mount it [01:59] under /efs instead of /factory [01:59] that means anything [02:00] -- Oliver Grawert Sun, 04 Aug 2013 12:24:23 +0200 [02:00] I wonder if [02:00] I have nothing in /factory on the working image so probably not [02:00] I dont know what a /factory is though [02:00] im going to bisect [02:00] lxc-android-config [02:01] because permissions are suspect [02:01] oh I can't really do that as easily as I want to [02:03] ok I upgraded lxc-android-config [02:03] and it still works [02:03] im going to upgrade packages one at a time lol [02:05] that was kind of silly :p not even sure what to try next [02:06] no hybris updates [02:06] N4 sez: Not enough charge to turn on yet. This seems to happen a lot [02:07] lets upgrade lxc [02:07] duflu: Happens to me a lot too :( and you can [02:08] use more poer than you get off low power USB compiling [02:08] mir [02:08] racarr: Yeah I put it on mains for a while [02:09] * duflu wonders if the USB 3 port would have more power than USB 2 [02:09] Maybe [02:11] not lxc! let's upgrade apparmor [02:11] im staring at a list of like 200 packages trying to pick ones that could be relevant lol [02:13] racarr: Maybe consider those that Mir depends on [02:16] duflu: Mm. should just start with that [02:21] all the build deps [02:21] are newest version [02:22] as are the dependencies [02:22] except or [02:22] multiarch support [02:22] *tests* [02:24] racarr: phablet-flash has no options to specify an image file(s) any more. Any clue? [02:24] duflu: You have to use clockwork mod [02:24] duflu: You flash the armel+dev first then the armhf [02:24] Great. Later then [02:24] you have to use adb push file /sdcard/ [02:24] instead of [02:24] /sdcard [02:24] or it ust silently fails ater taking [02:24] forever [02:24] lol [02:25] aw not multiarch support either [02:28] Grr overlapping outputs. [02:34] ok I think I narrowed it don to a set of 20 packages [02:35] is there an easy way to reverse my last [02:35] apt transaction [02:36] http://pastebin.ubuntu.com/6004993/ [02:36] something in here killed it' [02:37] http://pastebin.ubuntu.com/6004994/ [02:37] this is suspiscious [02:44] reverting back to working image to narrow the list [02:45] Setting up initramfs-tools-ubuntu-touch (0.34) ... [02:45] seems sort of sketchy [02:45] compared to everything else at least [03:21] racarr: arrrround? [03:27] smspillaz: Enthusiastically! === chihchun_afk is now known as chihchun [03:33] racarr: you're awsome...so down to 20 packages, somewhere between jul 26 & aug 8 [03:35] kgunn: Actually just got a working system again and clicking, so more like 19 packages lol [03:35] really only like 4 or 5 that seem reasonable we should know super soon [03:36] racarr: cool [03:37] duflu: so I don't know if something I'm seeing is a bug in the mir buffer swapper or a bug in my code [03:37] duflu: ping [03:38] duflu: basically if I do draw1 -> swap1 -> draw2 -> swap2 -> draw3 -> swap3 [03:38] I seem to see something like [03:38] after swap1 : nothing after swap2 : draw1 after swap3: draw2 [03:38] (using mir_surface_swap_buffers directly) [03:39] smspillaz: Do you have a very recent server? That was probably fixed in lp:mir r955 [03:39] duflu: bzr pulled as of yesterday [03:39] kgunn: Hi [03:40] smspillaz: Yeah that's new enough [03:40] hmm ok I'll try again [03:40] maybe I was just an idiot and forgot to set my path right or something last night [03:41] smspillaz: For manual testing that kind of thing I use fingerpaint (in which single clicks generate single swaps and should generate immediate output) [03:41] Though we have automated tests for it of course [03:41] ah you know what [03:41] it could be that stupid thing with sudo not working with LD_LIBRARY_PATH [03:41] kgunn: pong? [03:41] well not stupid, but a gotcha nonetheless [03:42] so I was probably still running the one in /usr/bin [03:42] smspillaz: Yeah you have to set it after sudo [03:42] you guys really need something like weston-launch [03:42] smspillaz: You mean a dumb and simple shell? [03:44] duflu: not really. Its a setuid thing that talks to pam to get the invoking env, handles all of the vt switching and drmSetMaster/drmDropMaster stuff and then runs weston as user [03:44] smspillaz: Oh right. I have thought about similar [03:44] Someone just has to do it [03:44] lol [03:45] it makes life a lot easier :) [03:45] smspillaz: Ill take care of it on Yotday, the imaginary day I just invented inbetween [03:45] now and featufre freeze [03:45] :p [03:45] though admittedly not as useful anymore because logind no longer allows arbitrary processes other than init to spawn new sessions [03:46] so it has to start on the same vt you launched it on as opposed to starting on a new one [03:46] As long as you don't want VT switching you should be able to run mir_demo_server_shell as your user directly. [03:47] RAOF: don't you need root for input? [03:47] I seem to recall that's what half of what weston-launch was about [03:47] sudo chown smspillaz /dev/input/**/* [03:47] or maybe that was to do with vt-switching and input [03:48] RAOF: :/ [03:48] smspillaz: Hey, it's harmless¹ [03:48] ¹: As long as you trust everything on your box [03:49] I guess my alternative solution of doing source /home/smspillaz/.bashrc was probably not better [03:49] (so that I didn't have to re-type every bloody path again) [03:50] Nooooooooooooooooooooooooooooooooo [03:50] bisection failed [03:50] life [03:50] no [03:50] just bisection [03:57] duflu: :/ I'm still getting the one-frame lag [03:57] (correct paths and all) [03:59] err [04:00] ...I retract my err [04:01] though oddly its not happening on the demo clients which use mir_surface_swap_buffers_sync!?! [04:02] Hrm [04:03] attack of the threads! [04:06] smspillaz: Not sure then. We have automated and easily manual testing of this issue. If you can figure out the scenario exactly that would be helpful [04:07] duflu: I'm just doing a dump of the image surface to a png to figure out what's going on for now [04:07] reeeeecompiling [04:12] racarr: bisection failed as in ...you added everything back one by one to a failing image that no longer fails but actually boots with unity-mir ? [04:12] kgunn: I think I made a istake in thinking I hd found a broken set of packges [04:12] in that it just didnt ork once [04:12] maybe I didnt use sudo and forgot because adb history was fucked up or something [04:12] I dunno [04:12] no I am still on a orking images [04:12] and adding more and more packages [04:12] about 20 at a time then rebooting and testing [04:13] lol [04:13] this last one pulls in a bunch of stuff so I have a feeling this will break it but then to bisect this smaller list I need to go all the way back [04:13] and reflash [04:14] ubuntu-touch-generic-initrd ubuntu-touch-session [04:14] these are the most suspsicious packages that I havent ruled out yet [04:14] all the mir dependencies and build dependencies [04:14] are ruled out [04:23] racarr: can you pastebin the remaining packages ? [04:24] just updating the bug [04:24] thomi, is jenkins screwed up again? (https://jenkins.qa.ubuntu.com/job/lightdm-saucy-amd64-ci/85/console) [04:24] and http://s-jenkins:8080/job/lightdm-ci/168/ [04:24] just in case you don't find the offender [04:24] it wouldn't surprise me, let me see [04:24] kgunn: http://pastebin.ubuntu.com/6005189/ [04:24] almost through a bunch though [04:25] robert_ancell: the public jenkins has been up and down all day today [04:25] robert_ancell: private jenkins should be working though [04:25] thomi, also, do you happen to know who I can poke to make a PPA have a high priority? [04:26] robert_ancell: #launchpad-ops [04:26] robert_ancell, rcimm & rsalveti [04:26] kgunn: http://pastebin.ubuntu.com/6005191/ [04:26] I ust ran mir succesfully [04:26] after a reboot [04:26] and those are the only remaining packages [04:26] in upgrade [04:26] going to eat some ice cream then come back to it [04:27] ricmm, rsalveti, you can bump PPA priorities? Can you set ppa:mir-team/qa-testing to the same priority as ppa:mir-team/staging? [04:27] robert_ancell: you mean build priority in the lp build queue, right? [04:27] going to eat icecream and revisit [04:28] oh [04:28] wow [04:28] thomi, yeah [04:28] im going around in workspace switching loops [04:28] robert_ancell: I thought so, I've always had to ask launchpad people to tweak that for me, but maybe others have more permissons than I do [04:29] racarr: icecream can only help [04:40] kgunn: so I'm working at the australian election and our counting how-to guide give the example of replacing the candidates name with "ice cream" [04:40] as an example of an informal vote [04:41] I really don't know who or why somebody would want to vote for ice cream [04:42] so close [04:42] ps daily show had coverage of australlian elections it as hilarious [04:42] racarr: I saw that! [04:42] ahh good ol' cameron diaz [04:44] does anyone have time to revie client-focus-notifications while I am still awake? [04:47] libopenobex1 libpam-systemd libpixman-1-0 libplymouth2 libpolkit-agent-1-0 libpolkit-backend-1-0 libpolkit-gobject-1-0 libsystemd-daemon0 libsystemd-login0 libupower-glib1 libusb-1.0-0 libwaudio1 login multiarch-support packagekit-plugin-click plymouth policykit-1 powerd systemd-services telepathy-gabble telepathy-ofono tzdata [04:48] one is evil [04:49] racarr: Sure. I want that branch landed :) [04:49] RAOF: It feels like today is the day [04:50] https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/179801 is the current one, right? [04:50] I'm looking for the words to say...I don't think I can hide...what I'm feeling inside... [04:50] RAOF: https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/180903 [04:50] didn't you check the moon charts? [04:51] libpam-systemd libplymouth2 libpolkit-agent-1-0 libpolkit-backend-1-0 [04:51] libpolkit-gobject-1-0 libsystemd-daemon0 libusb-1.0-0 libwaudio1 [04:51] multiarch-support packagekit-plugin-click plymouth policykit-1 powerd [04:51] systemd-services [04:51] hmmm [04:52] im trying to eliminate ones which seem really unlikely to break mir [04:52] first so when I finally break it (and have to start the whole thing over again) [04:52] the pool is super small and I can just guess [04:54] libpam-systemd libplymouth2 libsystemd-daemon0 plymouth policykit-1 powerd systemd-services [04:55] any bets? :p [04:55] systemd plymouth policykit or powerd one of them broke mir on the nexus 4 [04:58] * RAOF lays a bet on "systemd" [04:58] seems likely [04:58] it wasn't powerd [04:58] seeing if plymouth is the surprise offender now [04:59] damnit, ran demo ithout root, 30 second penalty as phone hangs. [04:59] :p [05:00] * RAOF should really get around to submitting a branch that fixes the build with clang 3.4 [05:01] plymouth, hitelisted [05:04] what [05:04] I am fully upgraded [05:04] and just ran mir [05:04] ufahsufashfasha [05:04] Huzzah! [05:04] You've fixed it! [05:05] what if it fixed itself in the archive [05:05] while ive been doing this all day [05:08] ive been using [05:08] the same mir [05:08] binary [05:08] ...maybe a header changed [05:08] ugh [05:08] ok literally no headers changed [05:10] im flashing a latest image and upgrading to see if it really did just [05:10] ...fix itself [05:15] good morning [05:15] RAOF, we have exclusive access to the ati machine :) [05:20] Excellent. [05:20] * RAOF is making coffee for a moment. [05:23] RAOF, I'm back in ~1 hour [05:26] tvoss: So I've been bisecting images, until I got to august 12th broken july 26th orks then I ran out of images so I started [05:26] installing packages to upgrade, about 10 at a time [05:26] and rebooting and testing [05:26] at one point it seemed to break, so I bisected those packages from the working image [05:27] but then it always orked so I started over [05:27] over about 30 reboots I saw maybe 2 failures here I had to reboot, but then it alays worked until I was [05:27] fully ugpraded, and it still worked! [05:27] racarr, wtf [05:27] and then I verified I asn't crazy, and the fully upgraded binary was working [05:27] and cmake, didn't detect any thing as touched, i.e. mir needing rebuild, in fact none of the mir [05:27] racarr, could you reboot like 20 times to rule out a race? [05:28] build depdencies were ever upgraded [05:28] tvoss: I have, it seems either it always fails, or [05:28] just occasionally it fails in this one way that a reboot fix [05:28] but always works otherwise [05:28] what I am doing now is a clean image to see i it was [05:28] magically fixed in the archive [05:28] okay [05:29] racarr, can you compile that into an email? [05:30] tvoss: Yeah I am about 5 minutes away from the result on the [05:30] clean image then I will write things up [05:31] it doesn't really make any sense as far as I can see, but I was pretty careful [05:31] but I dunno, I haven't really zoomed back out yet [05:31] ive just been...in robot mode [05:34] ugh [05:34] it didn't work [05:35] hey robert_ancell! Just a quick note on lightdm packaging, you took my cleanup branch, right? (https://code.launchpad.net/~didrocks/lightdm/packaging-cleanup) [05:35] it was merged in the /unity one, not sure you took it for trunk [05:36] didrocks, yeah, it's a mix of a few different packaging branches :) [05:36] i.e. what was in the archive + the changes you made + the test changes made for CI [05:36] will be nice to be down to one branch :) [05:37] robert_ancell: indeed ;) thanks! [05:37] * didrocks can close a tab then \o/ [05:39] tvoss: OK I commented on the bug [05:44] brain basically off now [05:45] didrocks: Yo! [05:45] RAOF hey! [05:46] Bah. Why aren't all the rdeps of xmir magically rebuilt when I break the ABI? :) [05:48] didrocks: By the way, this patch http://paste.ubuntu.com/5983202/ worked fine; it was when we turned on logging for the msg-processor and frontend that the race disappeared. [05:48] And by ‘worked fine’ I obviously mean “hung like a bastard” [05:49] RAOF: was the rdepends a question for me? [05:50] RAOF: ah, so you got all the info you needed? [05:50] No :) [05:50] didrocks: Well, we got all the information that patch provided. :) [05:50] heh [05:50] Which was "yes, XMir really is writing the request to the socket and is not receiving a reply" [05:52] RAOF: the ATI machine is completely deprovisionned btw [05:52] So I hear. [05:52] (just done) [05:53] if you need help to setup the environment, do not hesitate [05:53] I think others are taking the lead on this bug for a while, while I get multihead for XMir done. [05:53] ok [06:14] racarr: dpms ping [06:22] I seem to be leaking ALL THE FDs [06:23] But I don't think that's my fault. [06:24] the awkward moment when you have been writing C++ for so long that you forgot how to write GObjects [06:24] I hear the correct way to do that is to write a DSL. [06:25] RAOF: DSL? [06:26] Domain Specific Language; ie: Vala [06:26] lol [06:26] actually [06:26] I think this marks the first time this year [06:26] I will have written a GObject [06:26] \o/ [06:26] not a cause for celebration [06:27] or /o\ depending on how you look at it [06:27] /o\ most certainly [06:43] gcc. How I hate you and your insane C++ error messages [06:46] Yes [06:53] good morning [07:41] Hrm. [07:42] RAOF, ? [07:42] I think we might leak fds for clients with more than one window [07:43] Or, at least, we leak ALL THE FDs when XMir has two surfaces, one for each of my displays, and we don't leak fds when XMir is only driving one display. [07:49] The problem could be in the XMir code, but I thought that mirclient should handle the fds sent over the wire. [07:51] RAOF: Is this related?... 1194534 [07:51] bug 1194534 [07:51] bug 1194534 in Mir "mir_connection_release does not free associated surfaces" [Medium,Triaged] https://launchpad.net/bugs/1194534 [07:51]