[04:23] forget sil2100's messages, he was too tired to remember the PPA does not have the mir now :) [08:18] duflu: alf_ - anyone object to me merging https://code.launchpad.net/~alan-griffiths/mir/fix-1244192/+merge/192503 by hand as CI seems so reluctant? [08:19] alan_g: So long as the failure is spurious. I don't understand what the "android i386" platform is... [08:22] duflu: I'll ask about it when fginther comes online - it certainly has nothing to do with the change [08:23] alan_g: If it really is unrelated, retrying should eventually work. Because other proposals are succeeding [08:25] duflu: I know - I'll give it one more try... [09:15] alan_g: I just had another quick look at "fixing" render_surfaces to not reference mir::surfaces::. It would seem that we first need surfaces::Surface to implement shell::Surface. Are you still planning on trying that? [09:16] duflu: I think that something like that is needed. But there's a lot of "low hanging fruit" to clear before getting to that. [09:18] alan_g: Let me know if and when you start. Otherwise I may... but not this week [09:18] duflu: ok [09:18] * duflu is buried in said fruit [09:19] * alan_g laughs [09:19] Maybe that's why I feel sticky === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g [12:57] alf_: It would be easier to remove report implementation classes from public if I rolled logging and lttng into a "reporting" component. Does that work for you? === alex_abreu is now known as alex-abreu [13:13] alan_g: no objections [13:14] alf_: Good. I think I'll leave it until the next pass - I don't want to start controversy over the simpler stuff. === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [14:39] alf_: hey can we ask for a big favor ? [14:40] alf_: can you test lp:mir/trusty against xmir ? (which will require a rebuild of xserver-xorg-xmir) [14:41] kgunn: do you want to know if it works or if it builds? [14:41] alf_: it should in theory [14:42] alf_: duflu bumped the client api.... [14:42] alf_: so to make sure we didn't break just need some sanity [14:43] kgunn: so which one works or just builds against? :) [14:45] alf_: as much as possible [14:48] alan_g: ok, "builds" it is then... [14:51] alf_: question is can you also create packages for upload (xserver-xorg-xmir) [14:52] as didrocks would like to have those [14:52] to release as well [14:52] i suppose we usually rely on RAOF for this...part...but as he's not in or going to be in till monday.... [14:52] kgunn: oh, not for me, it's more for you :) [14:53] alf_: kgunn: if you tell me a rebuild is enough and your tests are fine, I'll handle the upload of xserver-xorg-xmir to the archive when we release Mir [14:53] didrocks: well yeah :).... alf_ in effect we can't release/update mir without it === dandrader is now known as dandrader|lunch [16:27] didrocks: ping [16:27] kgunn: pong [16:27] kgunn: cyphermox is going to continue helping you btw (as it's nearly EOW for me) [16:28] didrocks: ack... alf_ had to go as well [16:28] kgunn: do you think there is still hope before EOW? [16:28] didrocks: i am doubting...but chris will be in on sunday u.s. time [16:29] didrocks: is that ok ? [16:29] otherwise i'll see if bschaefer might be able to help us out... [16:29] hey, whats up? [16:29] bschaefer: have you ever built the xorg packages for xmir ? [16:29] kgunn: well, it's still delaying all the landings for the rest, but I think we don't have that much choice [16:29] hmm no i've not [16:30] mlankhorst: ^ ? ...are you EOW'ing soon :) [16:30] kgunn: I hope we can get some confirmation at least on Monday once sil2100 start to wake up :) [16:30] * kgunn asks sheepishly [16:30] didrocks: that should be totally do-able [16:30] kgunn: he did EOW yesterday I guess [16:31] kgunn: again, if you have a ppa with latest mir, unity-mir and so on… I can upload xserver-xorg-xmir for you [16:31] (then, leaving up the tests to you) [16:31] didrocks: oh wait...are you saying you have them built ? we just need to test ? [16:33] kgunn: no, I'm telling that if you have a ppa with mir and all the rest built, I can build xserver-xorg-xmir in it [16:37] didrocks: ah....we should https://launchpad.net/~mir-team/+archive/staging [16:37] can cyphermox do the same? (e.g. build xmir for us if we get those packages updated) didrocks [16:37] kgunn: hum, it's rev 1153, from 3 days behind [16:38] so without this ABI bump [16:38] didrocks: right...we need to update [16:38] kgunn: doing it for you, both mir, u-s-c and xserver-xorg-xmir [16:39] kgunn: but you need to spread this knowledge within the team, please ;) [16:39] didrocks: yep [16:39] kgunn: you have alf, mterry and RAOF who can help spreading it I guess :) [16:40] urgh [16:40] 0.1.0bzr1153trusty0 [16:40] * mterry looks up [16:40] the version is horrible… [16:40] oh, there is a mterry [16:40] he can do it as well ;) [16:41] mterry: https://launchpad.net/~mir-team/+archive/staging needing latest mir, u-s-c and rebuild xserver-xorg-xmir [16:41] didrocks, you mean those packages need mir-version bumps? [16:41] i.e. that's not a manual upload PPA is it? [16:42] mterry: it guess the version will have to be 0.1.0bzr1161trusty1 [16:42] mterry: I guess nothing uploads to there anymore [16:42] as you pull to trunk [16:42] and not merged [16:42] mterry: so, manual uploads are needed [16:42] (on trusty) [16:43] so first mir, then u-s-c and xserver-xorg-xmir [16:43] "pull to trunk and not merged" [16:43] ? [16:43] didrocks, sorry, I guess I'm out of loop. Why is this outside our normal infrastructure? [16:43] mterry: yeah, you bzr pull dev to trunk [16:43] mterry: on duflu's request [16:44] mterry: I agree, we should get the mir team back to the way other teams are working [16:44] mterry: i'll fwd you the thread [16:44] kgunn: TBH, I didn't anticipate this side-effects on the ppa not being updated neither [16:44] kgunn: already done for the week on thursday [16:45] mlankhorst: ok, get back to enjoying weekedn [16:45] didrocks, well anyway. You're asking me to take trunk of those packages and upload to that PPA? I can do that... [16:45] mterry: yes please ;) [16:45] (ensure the xmir package builds against latest mir of course) [16:45] then I guess kgunn will trap someone to test it [16:45] didrocks, pfft, that's what staging PPAs are for! [16:45] mterry: if you do it i am thankful..... are you simply "dput ppa:your-lp-id/ppa " [16:45] mterry: isn't it? :p [16:46] kgunn: can you ensure sil2100 is aware about the result on Monday? [16:46] kgunn, basically [16:46] didrocks: will trap someone somewhere yes [16:46] as he's not travelling and stay in the EU time, we can win half a day [16:46] mterry: can you enlighten me so i can help in the future [16:46] didrocks, you want a particular version? [16:47] mterry: latest trunk (which is lp:mir/trusty [16:47] kgunn, sure, but I meant package version [16:47] kgunn, enlighten you on the steps? I'm just planning on doing bzr branch; debuild -S -sa -i -I; dput [16:48] with some minor changelog modification to make sure that they say trusty and such instead of UNRELEASED [16:49] ;) [17:00] didrocks, just to clarify, you just want a rebuild of xorg-server, not a fresh-trunk build, right? [17:01] mterry: for xorg-server, yeah, a rebuild against latest mir you are/did upload [17:01] and of course the rebuild of u-s-c against this latest mir for the ABI break [17:01] so that kgunn finds the victim to test all 3 of them on the desktop :) [17:01] didrocks, yup, I'm pulling mir and usc trunk. but only xorg-server trusty packaging [17:01] right! [17:05] robotfuel: ^ if you're looking for something to do :) [17:06] robotfuel: you could run xmir testing, even just locally.... after mterry finishes [17:06] bschaefer: ^ [17:08] kgunn: I am working on porting autopilot apps to from 1.3 to 1.4, but I am suppose to give mir priority so I'll do it. :) [17:09] what am I waiting for mterry to land? [17:09] kgunn: mterry^ === alan_g is now known as alan_g|EOW [17:09] robotfuel, a new mir/u-s-c/xorg in mir-team/staging [17:10] robotfuel, just waiting for builds now. I can ping you [17:10] robotfuel, in particular, if you can just make sure that xmir still works fine [17:11] mterry: which ppa? I can setup jenkins to get something more interesting that just works [17:12] robotfuel: it'll be the mir packages for trusty that are in ~mir-team/staging === dandrader|lunch is now known as dandrader [17:36] So... Mir trunk is failing the test ServerShutdown.server_removes_endpoint_on_abort -- anyone else seeing it? [17:36] racarr, ^ ? [17:39] kgunn, ^ [17:40] not just that test... [17:40] https://launchpadlibrarian.net/154994415/buildlog_ubuntu-trusty-i386.mir_0.1.0bzr1153trusty1_FAILEDTOBUILD.txt.gz [17:41] I'm not sure who to ask about these [17:41] kdub, ? ^ [17:46] i don't know anything specifically, i can test though === racarr is now known as racarr|sick [18:07] warnings of sickness from earlier became fever last night [18:07] woke up to eat food. back to not moving now though :p [18:31] get better racarr|sick [19:24] kdub: thanks if you can help fix the failures [19:26] kgunn, kdub, sorry may have missed some talk about the test failures. Can you look at them? [19:27] mterry: did you happen to run tests locally ? [19:28] kgunn, not yet, let me do so now [19:29] trunk passed for me [19:29] well :) ~mir-team/mir/development-branch [19:29] but then again, im on saucy, maybe it has something to do with trusty? [19:30] kdub: uh...can't imagine...but never know....can you try trunk ? [19:31] * kgunn tries [19:43] kdub: mterry ... i'm able to run the test locally, several times just in case...no failures, wonder if its classic misleading ci failures [19:44] kdub, I've been using lp:mir [19:45] mterry: did your local tests pass ?...if yes, then i would vote to update the ppa manually [19:46] kgunn, well, that's what I did, but these are local build tests and the PPA build failed. I could disable tests during build... [19:50] kdub, kgunn: OK, I do get failures locally with lp:mir [19:50] kgunn, my understanding was that didrocks was intending upload of lp:mir, not the development branch? [19:50] mterry: you amd64 or i386 ? [19:50] kgunn, amd64 [19:51] mterry: i'm also amd64.... [19:51] kgunn, but I didn't believe the buildd had a difference [19:51] kgunn, did you build development-branch? [19:51] mterry: i built lp:mir [19:51] mterry: and didrocks uses lp:mir [19:51] not the dev branch [19:51] kgunn, weird... [19:51] * mterry is curious how kdub finds lp:mir [19:52] mterry: i haven't updated since yesterday (or maybe day before)....you ? [19:52] kgunn, I updated yesterday I believe [19:53] * kgunn updates now just in case [19:54] back in a minute [19:56] the only failure I got was in the devel-branch was TestClientInput.hidden_clients_do_not_receive_pointer_events, which is know and logged here https://bugs.launchpad.net/mir/+bug/1227683 [19:56] Ubuntu bug 1227683 in Mir "valgrind acceptance-tests FAIL: TestClientInput.hidden_clients_do_not_receive_pointer_events" [High,Triaged] [19:56] but I was building in saucy [19:56] https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-saucy-amd64-ci/243/console is the build log [19:58] mterry, trunk looked okay to me too [19:59] kdub, meaning lp:mir? [20:03] kgunn, if development-branch works better, is that acceptable to upload to PPA? Or are there changes there that we don't want yet? [20:04] mterry, yes, lp:mir [20:09] hmm...he quit [20:09] rebooting myself [20:11] whoops, got disconnected [20:16] mterry: to answer your question about development-branch vs lp:mir/trusty [20:16] technically they are one in the same... [20:16] at least dev branch is the source for lp:mir.... [20:17] altho a little ahead [20:17] no one is supposed to mp target or push to lp:mir [20:17] only to dev branch [20:18] then we (semi)regularly update "trunk" (in this case trusty) with dev-branch [20:28] kgunn, so I just updated again, trying once more locally. If I fail again, I can disable tests, upload the brokenish Mir, just so we can at least test xmir against it. I'm not sure we should promote it to trusty unless we can investigate the failures though [20:29] mterry: yeah...just sharing i updated locally, blew away build dir, rebuilt, retested a few times and all passing [20:29] mterry: are you falling reliably ? [20:29] kgunn, looks like it [20:29] every run? 50% ?..? [20:29] kgunn, for me so far, 2/2 failed, plus the one in the buildd [20:31] mterry: just to make sure we're all doing the same thing...when you test...you're in your local src dir/build & you run ctest [20:31] kgunn, no these were debuild runds [20:31] debuild runs [20:31] kgunn, I can try local ctest too [20:31] kdub: ^ [20:31] but based on accounts, sounds like that would pass while a debuild would fail [20:32] mterry: how does it vary ? [20:32] kgunn, could be environment variables or the way the tests are run.. not sure yet [20:33] kdub: how are you running ? ctest ? [20:33] kgunn, ctest works for me [20:34] kgunn, does running the following in the root dir work for you? [20:34] GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1 [20:34] That's what debuild runs [20:35] mterry: uh...so i export that / [20:35] ? [20:35] then run ctest ? or ? [20:36] sorry..i'm really dumb when it comes to incantations [20:36] kgunn, no, not an export, that was just a variable set before calling dh_auto_test [20:36] kgunn, dh_auto_test is the important part [20:36] run dh_auto_test [20:38] ... which ends up calling ctest [20:38] and now when I cd into the build dir and manually run ctest I see a failure [20:39] mterry: i don't see anything when i run dh_auto_test [20:39] mterry: maybe its missing something from the debbuild ? [20:40] kgunn, oh, you probably don't have the builddir it expects.. let me see [20:40] kgunn, pass -B BUILDDIR [20:41] mterry: hmm, same thing...it just takes the command line...but no output [20:42] kgunn, pass --verbose, maybe see what it's trying to do [20:42] kg@kg-MacBookPro:~/workspace/mir/trusty$ dh_auto_test -B BUILDDIR --verbose [20:42] kg@kg-MacBookPro:~/workspace/mir/trusty$ [20:42] mterry: ^ [20:42] kgunn, huh. Well, substitute BUILDDIR for whatever your builddir was [20:42] :) [20:43] kgunn, but besides that might be some other debuild-y thing it expects [20:43] mterry: magic! [20:43] really all it does is call ctest with --force-new-ctest-process -j1 [20:43] inside the builddir [20:44] mterry: hmm passed all tests 5 out of 5 attempts [20:44] kgunn, stop having it work! [20:44] mterry: you on saucy or trusty on your machine [20:44] kgunn, trusty [20:44] mterry: uh oh [20:45] kgunn, you're on saucy? [20:45] mterry: let me got update [20:45] i know tsk tsk tsk [20:45] kgunn, I can't... I can't even look at you right now [20:45] mterry: i've brot shame to this house [20:47] kgunn, I'm testing a small change now that might, maybe work. It simply runs ctest without any arguments [20:47] kdub, you were testing in trusty? [20:47] mterry: pretty sure he was saucy too....shame on us [20:48] * mterry throws his hands up [21:04] kgunn, that worked for me... [21:04] kgunn, (just running ctest) [21:05] kgunn, I don't understand it, but I'll upload it for now, we're still running the tests... [21:05] mterry: thanks... [21:05] mterry: so that's mir, u-s-c....and now i need to get cyphermox to build xserver ? [21:06] just making sure you weren't building xserver-xorg-xmir [21:06] kgunn, oh I was intending to upload that too yeah [21:06] kgunn, just had to wait for mir to finish first, but it never did [21:06] mterry: oh...ok [21:06] kgunn, are we still going to have people to test it? [21:14] mterry: you mean me? [21:14] what do you mean you'll upload though? [21:14] where are you uploading? [21:15] cyphermox, ppa:mir-team/staging [21:15] ah, cool [21:15] cyphermox, right now just mir, but next usc and xorg [21:15] yeah [21:15] ok so I'll wait for you to rebuild those in the PPA, then I'll install the packages and kick off some quick testing [21:15] cyphermox, you're a guinea pig? [21:16] * mterry hugs cyphermox [21:16] then I need to rebuild all of that and xserver-xorg-xmir and run full autopilot tests of everything before releasing to the archive ;) [21:26] mterry, not in trusty [21:28] mterry: cyphermox ....sorry, huge interruption, daughters roommate...bill paying...awesome [21:29] not in trusty? [21:29] bschaefer: ^ actually, when mterry hits up the ppa with new mir, usc, & xorg can you test xmir ?...mainly unity7 comes up and doesn't fall over [21:29] :) [21:30] kgunn, sure! [21:30] * bschaefer hasn't used xmir for a bit now though [21:30] bschaefer: thanks man!....if you succeed just email [21:30] bschaefer, cyphermox: I'll poke you guys when ready [21:30] mterry, cool, thanks! [21:30] kgunn, and will do [21:30] mterry: alright, thanks! [21:30] kgunn, after I upload and assuming tests are good, is that all you need from me? [21:30] bschaefer: i know...kinda scary wading into the xmir waters again :) [21:30] :) [21:31] mterry: yes, thank you for all the help [21:31] kgunn, cool [21:31] i'll check back in later....and write a mail for chris & daniel in the event euro morning monday needs some assitance [21:31] bschaefer: also...let cyphermox know [21:31] bbiab [21:32] alright [21:36] know what? [21:37] cyphermox, how xmir works with the new ppa on unity7? [21:37] thats what i got out of that [21:39] kgunn: I have xmir phoronix test setup for trusty in the qa lab, I can enable autopilot tests for unity7 as well if you want [21:39] bschaefer: ^ [21:39] also for the staging ppa [21:40] robotfuel, the AP tests for unity7 will take 2-3 hours [21:40] bregma, do you want the AP tests enabled for unity7 atm? [21:41] in trusty? [21:41] for xmir [21:45] kgunn, if this latest change doesn't work... how badly do we need this to go in? [21:46] kgunn, like... disabling tests is the quick and dirty way, but that's got red flags all over it [21:46] kgunn, else we could have Mir team look at it (in trusty! :)) [21:47] kgunn, and the test still failed [21:49] mterry: +1 the tests need to be fixed [21:49] robotfuel, yar :-/ [21:51] Is anyone here familiar with the error "Failed to find server" ? [21:51] That seems to be the exception thrown by the tests [21:52] mterry: is there a log you can post for the failed tests? [21:53] robotfuel, current build isn't quite finished, but this was previous build: https://launchpadlibrarian.net/154994415/buildlog_ubuntu-trusty-i386.mir_0.1.0bzr1153trusty1_FAILEDTOBUILD.txt.gz [21:53] I expect the errors to be the same [21:53] robotfuel, errors aren't terribly informative [21:53] robotfuel, are you on trusty? [21:54] mterry: no I have a machine in the lexington lab I can use though [21:55] robotfuel, seems to not happen on saucy [22:26] mterry: i'm guessing duflu and RAOF might inherit looking into this [22:28] mterry: wait...i'm confused...is this really the top of the lp:mir/trusty ? [22:28] what is it 1153 [22:28] oops/what/why [22:28] kgunn, I'm seeing [22:28] kgunn, 1161 [22:28] i mean, why isn't it 1161 [22:29] kgunn, I dunno about lp:mir/trusty. I'm using lp:mir [22:29] presumably they're the same? [22:29] mterry: yes...same thing [22:29] kgunn, I'm thinking of just disabling tests so we can build xorg against mir. But before mir hits archive, we should fix tests [22:30] mterry: yeah that's worthy [22:30] we can still get some test results on xmir and then feed all this to duflu and chris [23:10] rebooting