[09:30] <didrocks> psivaa: coming?
[09:30] <didrocks> cyphermox_: https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV91cTRvNmQyMWJvNmJ0bm1mcW9xZWtsNTdnOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.us2orfbhb8ssqjui2u15tajj3s
[09:54] <psivaa> ogra_`: i'm thinking of starting with 'launch music from home scope' and working my way towards the left, since i dont have a sim
[09:55] <ogra_`> psivaa, well, my maguro has a dead battery and i need to pull the image via a 2MBit line ... will still take a while until i can start
[09:56] <sil2100> cyphermox_: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Ai33BkOcORLLdE4xLTFtSE80ZkpITXZ3aV85cWtPX2c&usp=drive_web#gid=0
[09:56] <ogra_`> psivaa, so just go ahead i'll ask you what you finished then
[09:57]  * ogra_` gets rid of that fly sh*t on his nick ... where did that come from ?
[09:57] <psivaa> ogra_`: ack, sounds good. starting to flash the device now..
[10:08] <cyphermox_> robru: http://paste.ubuntu.com/6872207/
[10:41] <robru> cyphermox_, like this? https://code.launchpad.net/~robru/ubuntu-html5-theme/better-package-transition/+merge/204632
[11:12] <sil2100> ogra_, psivaa: how's the maguro testing going?
[11:13] <sil2100> ogra_, psivaa: I tested the mako and it's all green, as per the spreadsheet
[11:13] <ogra_> sil2100, mine is just charged enough now to flash it
[11:13] <ogra_> (which takes ~30min)
[11:13] <psivaa> sil2100: just in the 'Location works' test.. enabled location and gps..
[11:13] <psivaa> sil2100: how do you verify that location works?
[11:14] <ogra_> heh
[11:14] <sil2100> psivaa: sooo...
[11:14] <sil2100> psivaa: I went up to the roof, sat there for like 10 minutes catching a cold
[11:14] <ogra_> you should start smoking :P
[11:14] <ogra_> keeps you warm up there
[11:14] <sil2100> psivaa: you open the indicator, enable location and GPS, then start webbrowser, go to google maps and allow it to use location
[11:15] <ogra_> catching a gps fix can take quite long though
[11:15] <ogra_> 15min isnt unusual
[11:15] <sil2100> psivaa: and then just mash the 'fetch location' button there every time it says 'Your location could not be determined'
[11:16] <psivaa> sil2100: ok :), thanks for that. not the first time i feel stupid :D
[11:17] <sil2100> psivaa: I didn't know how to test that as well! Until Mirv told me webbrowser can be used ;)
[11:17] <ogra_> or the google maps app ;)
[11:18] <sil2100> Yeah, installed that one as well, since I was worried that something's wrong with webbrowser
[11:18] <sil2100> But no, it just took f**king ages to catch that signal
[11:18] <sil2100> ;)
[11:18] <ogra_> yeah
[11:18] <ogra_> teall tvoss to finish AGPS support
[11:23] <sil2100> I guess he's blocked by us as well
[11:29] <psivaa> sil2100: location is not working for me, dont know if this is a regression or an ongoing issue in maguro..
[11:30] <sil2100> psivaa: how long did you wait for it?
[11:30] <psivaa> basically after enabling location and gps from the indicator panel opening a browser makes them disabled again
[11:30] <sil2100> psivaa: since it's taking REALLY long
[11:30] <sil2100> psivaa: oh, that's normal
[11:30] <sil2100> psivaa: that's a known bug
[11:31] <psivaa> sil2100: ack, then it *is working :D
[11:31] <sil2100> psivaa: just open up the indicator once, switch all on and don't open it anymore
[11:31] <sil2100> ;D
[11:31] <sil2100> Since if you open it up again after some time, it will switch it off
[11:31] <psivaa> lol, will do
[11:31] <sil2100> So just enable and forget ;p
[11:31] <psivaa> right.
[11:37] <Mirv> we've an issue that all x86 builders seem busy so cu2d (and others) are pretty much stalled
[11:37] <ogra_> finally flashing ...
[11:38] <davmor2> didrocks: I forgot to say yesterday I'm not in today, Uncles Funeral.  I've had a play with 162 on mako click is fixed with the revert and everything else is on par with normal.
[11:38] <davmor2> and with that I'm outta here
[11:42]  * ogra_ twiddles thumbs ... 
[11:42] <ogra_> still flashing
[11:42] <ogra_> i forgot how slow maguro is
[11:48] <ogra_> bah, so flashing took so long that suspend kicked in ... you actually end up with a black suspended screen after install
[11:49] <sil2100> psivaa: so, all tests besides the sim-card-ones are passing, yes?
[11:50] <psivaa> sil2100: still looking for location, but rest of them are ~ok
[11:53] <ogra_> psivaa, did you manage to install a click package ?
[11:54]  * ogra_ only gets the spinner after clicking install 
[11:54] <ogra_> doesnt do anything it seems
[11:54] <sil2100> Here installing and removing (on mako) worked fine
[11:54] <ogra_> hmm
[11:55] <ogra_> must be the app
[11:55] <ogra_> works fine with a different one
[11:55] <sil2100> Don't you dare reporting a regression
[11:55] <sil2100> Don't you dare!
[11:55] <sil2100> ;)
[11:55] <ogra_> yeah, totally regressed
[11:56] <ogra_> cant install smartfart !
[11:56] <ogra_> thats surely a blocker
[11:56] <ogra_> we cant promote without fart app support
[11:56] <sil2100> hoho
[11:59] <rsalveti> didrocks: ogra_: need a landing slot for https://code.launchpad.net/~rsalveti/platform-api/kitkat-porting/+merge/202599, and sergio is not around
[12:01] <sil2100> ogra_: did you do the sim-related tests like calling and messaging?
[12:01] <sil2100> ogra_: since psivaa did all the other ones
[12:01] <psivaa> sil2100: ogra_ : just confirmed click package installation on maguro
[12:01] <psivaa> works, that is
[12:02] <sil2100> o/
[12:02] <sil2100> We just need the phone-related stuff
[12:03] <ogra_> sil2100, on it, calls work fine
[12:03]  * psivaa off the dogfooding hook then
[12:03] <sil2100> psivaa: thanks :)
[12:03] <psivaa> sil2100: yw
[12:03] <ogra_> sms too
[12:05] <ogra_> bah ... it resorted to 2G signal is to bad here
[12:05] <ogra_> but i get the start page in the browser
[12:05]  * ogra_ tries to get a better signal
[12:06] <sil2100> Good enough for me
[12:06] <sil2100> ;)
[12:06] <ogra_> well, sheet says 3G testing :P
[12:06] <sil2100> pfff ;p
[12:10] <sil2100> ogra_: any luck? Sorry for poking all the time but we really want to promote this image
[12:10] <sil2100> Badly
[12:11] <ogra_> sil2100, looks fine, i cant get a better signal it seems
[12:12] <sil2100> ogra_: so, you +1 the dogfooding steps on maguro? ;)
[12:12] <ogra_> for the calls/sms and data networking, yes
[12:13] <ogra_> for the rest ask psivaa :)
[12:13] <ogra_> (but i think he acked already)
[12:14] <sil2100> ogra_: could you promote #161 then? ;) Be sure to promote 161, not 162 ;p
[12:14]  * ogra_ promotes 162 then :P
[12:15] <sil2100> Aaaaa, release troll!
[12:15] <sil2100> ;)
[12:17] <ogra_> "Waiting for other process to release the global lock" ...
[12:17] <ogra_> bah
[12:18] <ogra_> and there it sits ...
[12:19] <ogra_> *twiddle*
[12:23] <ogra_> that doesnt seem to go so well
[12:24] <ogra_> ah, well, seems the image ended up where it should, even though there was strange output of the command
[12:25] <sil2100> o_O
[12:26] <ogra_> [12:26] <ogra_> :P
[12:50] <sil2100> :|
[12:50] <ogra_> sil2100, whats wrong ?
[12:51]  * sil2100 gives ogra_ an angry stare
[12:51] <sil2100> ;)
[13:02] <sil2100> cjwatson: hi! Do you know by any chance why the i386 and amd64 builders are so busy today?
[13:07] <Mirv> +1 ^
[13:07] <cjwatson> sil2100: There was what looked like a browser security update in progress earlier
[13:08] <cjwatson> Those usually take a while to get anywhere
[13:08] <Mirv> https://launchpad.net/builders/ says "3137 jobs" for i386
[13:08] <cjwatson> https://launchpad.net/~canonical-chromium-builds/+archive/stage
[13:09] <cjwatson> Mirv: That's the test rebuild - most of those are scored way below anything you care about.  And that's been going on for the last week
[13:09] <Mirv> yeah, I looked chromium seemed up taking most of the builders
[13:09] <Mirv> cjwatson: right, that explains that part
[13:09] <Mirv> then we just wait, and plus +1:s on any plea for new build hardware
[13:10] <cjwatson> It's due for delivery this week
[13:10] <cjwatson> AIUI from the ticket
[13:10] <Mirv> wow, great news
[13:13] <cjwatson> that's https://rt.admin.canonical.com/Ticket/Display.html?id=67098
[13:16] <Guest438> sil2100: hey...i'm up :)
[13:16] <Guest438> oh crap
[13:16] <sil2100> Guest438: and you are..? ;)
[13:16] <Guest438> kgunn
[13:17] <sil2100> Guest438: so... there are some complications (as always), but we're working on it to get stuff released ASAP
[13:17] <sil2100> Guest438: it seems we're lacking i386 builders ;/
[13:17] <cjwatson> I've got no problem with scoring up individual builds you need
[13:17] <Guest438> ack
[13:18] <cjwatson> Though most of the builds in progress right now appear to be touch builds anyway
[13:18] <sil2100> kgunn: basically - I see those are running now, but we'll have a slot for mir in up to an hour
[13:18]  * cjwatson frees up batsu which was stuck
[13:18] <sil2100> cjwatson: thanks! :)
[13:18] <kgunn> sil2100: cool...
[13:19] <kgunn> sil2100: just hoping i'm lucky this morning and get thru w/o some prob of my own creation :0
[13:19] <Mirv> I've enough stuff to do while waiting for the various builds to start, so no need to prioritize. it's good there's no bigger problem.
[13:19] <cjwatson> nope, nothing systemic
[13:19] <sil2100> kgunn: I prepared everything for mir, like xorg-server and some changelog-sync, so once we're out with platform-api we're in building spree
[13:20] <cjwatson> also, Debian autosyncs stop for trusty in two days or so, so that will reduce the routine load
[13:20] <cjwatson> (until U opens)
[13:20] <ogra_> we should probably start nagging for a name for U :)
[13:21] <cjwatson> hm, I wish there were a page where I could see the entire build queue, rather than on a per-archive basis
[13:34] <didrocks> rsalveti: can you talk to kgunn? He's going to have a Mir landing and so locking platform-api. Maybe he wants to sneak it in it.
[13:35] <rsalveti> didrocks: well, it's not related with mir, so doesn't really matter
[13:35] <didrocks> rsalveti: yeah, but kgunn wants a slot now for Mir as a priority, so just agree with him :)
[13:35] <rsalveti> didrocks: I can wait mir to land (as long I don't have to wait that much)
[13:35] <rsalveti> didrocks: when are we planning to land mir, today?
[13:35] <didrocks> rsalveti: depends on them
[13:35] <rsalveti> didrocks: can I have the slot if mir landing fails today?
[13:35] <didrocks> we attribute a slot, then, it's when they are ready
[13:36] <rsalveti> hm, that's kind of annoying
[13:36] <didrocks> rsalveti: meaning they will have to through away their work
[13:36] <rsalveti> kgunn: when are you releasing the lock for platform-api? :-)
[13:36] <didrocks> so again, better that you talk with them, if you change is small, we can get it first
[13:36] <didrocks> s/we/you/
[13:36] <didrocks> if they agree to wait for 2 hours
[13:36]  * rsalveti spinning 
[13:37] <rsalveti> let's wait for kgunn then
[13:37] <didrocks> yep
[13:46] <sil2100> kgunn: ping?
[13:48] <kgunn> sil2100: yo
[13:49] <kgunn> rsalveti: alternately we could incorporate your platform-api change into my silo ?
[13:49] <rsalveti> kgunn: that could work as well
[13:50] <rsalveti> didrocks: how can we do that ^?
[13:50] <kgunn> rsalveti: what's the risk ? mp link ?
[13:50] <kgunn> afaik, we just need to add in the mp
[13:50] <kgunn> sil2100: didrocks ^ correct ?
[13:50] <didrocks> yeah :)
[13:53] <rsalveti> kgunn: didrocks: https://code.launchpad.net/~rsalveti/platform-api/kitkat-porting/+merge/202599
[13:54] <rsalveti> kgunn: no risks :-)
[13:54] <didrocks> rsalveti: he's taking the risk for you! :) /me kidding
[13:54] <rsalveti> only change the android side of it, which is not even built with the package
[13:54] <rsalveti> and mostly just used with SF
[13:55] <cjwatson> every time I hear you guys talk about a silo I wonder briefly why you care about sparc boot loaders
[13:55] <didrocks> rsalveti: I'll need to ask you some question in a quieter time on how to build the android side from the git branches, but I think that will be another day :)
[13:59] <kgunn> rsalveti: ok...i'll add...as long as you help me if i get in silo trouble ;)
[14:06] <rsalveti> cjwatson: lol
[14:06] <rsalveti> kgunn: sure, I also want mir to land soon
[14:06] <rsalveti> my 4.4 porting work is depending on it as well
[14:06] <rsalveti> didrocks: sure
[14:07] <kgunn> sil2100: just fyi since i know you're sussing me up a silo soon....i added salveti's mp to the landing sheet
[14:07] <sil2100> kgunn: ok, thanks :)
[14:08] <sil2100> kgunn: still waiting for platform-api to land in the archive
[14:09] <didrocks> (to be published in the release pocket to be exact)
[14:09] <kgunn> sweet
[14:11] <balloons> cjohnston: can you kick off a rebuild for this? https://code.launchpad.net/~nskaggs/ubuntu-ui-toolkit/emulator-docs-try3/+merge/199353
[14:12] <cjohnston> balloons: done
[14:13] <balloons> cjohnston: I am crazy to not be seeing it? https://jenkins.qa.ubuntu.com/job/ubuntu-ui-toolkit-ci/
[14:14] <cjohnston> balloons: your looking at public jenkins
[14:16] <balloons> cjohnston: *you are
[14:17] <balloons> :-p
[14:17] <balloons> ty
[14:17] <cjohnston> you're crazy and I can't spell.. what's your point? :-P
[14:24] <cjwatson> The x86 builders seem to be mostly back to doing test rebuild stuff, so the backlog of anything more important must have cleared
[14:36] <balloons> cjohnston: I guess my point is I blame you for the builds not working :-) This doesn't look right: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/5041/.
[14:37] <cjohnston> balloons: look at all the crashes
[14:37] <balloons> They don't appear to be running
[14:37] <balloons> I've not changed the sdk code at all, it's not possible
[14:37] <balloons> err, the uitk code
[14:37] <balloons> see like so: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/5041/testReport/junit/ubuntuuitoolkit.tests.test_emulators/TextFieldTestCase/test_write/
[14:38] <sil2100> kgunn: silo ready! You can press 'Build'
[14:38] <kgunn> thanks man
[14:38] <sil2100> kgunn: I already pushed the xorg-server package to the PPA already, so it should be in dep-wait for the new mir now
[14:39] <sil2100> :)
[14:39] <cjohnston> balloons: iirc the 'testability' issue is from the qmlscene crash.. but maybe the maliit-server crash
[14:39] <sil2100> kgunn: tell me if there are any errors when trying to build, since we had to sync the changelog
[14:40] <kgunn> sil2100: so...is that normal to see a bunch of "old builds" in there ?
[14:43] <sil2100> kgunn: what do you mean?
[14:43] <sil2100> kgunn: are you looking at the right silo? :)
[14:44] <sil2100> kgunn: in silo 002 there's only xorg-server, which is normal as I pushed it directly for the rebuild
[14:44] <kgunn> sil2100: yep when i visit jenkins from the button in silo 002....it had a list of 13 previous builds
[14:44] <sil2100> Ah, normla
[14:44] <sil2100> normal
[14:44] <sil2100> No worries, it's a history of builds for the silo
[14:44] <kgunn> yep...i hit the button anyway :)
[14:48] <balloons> cjohnston: can you do something to fix the enviroment so the tests won't encounter these issues, and therefore run?
[14:48] <cjohnston> balloons: the crashes have to be fixed
[14:50] <cjohnston> fginther: do you by chance have the link to the bug for the crash causing issues with the 'testability' flag?
[14:53] <fginther> cjohnston, no. I saw this being mentioned as the cause of recent crashes, but it's old: https://bugs.launchpad.net/mir/+bug/1236525
[14:53] <cjohnston> ta
[14:54] <fginther> ugh, woopsie can't even process the crashes.
[15:10] <balloons> mmm
[15:15] <sil2100> kgunn: so now all is left is waiting ;) Things are building correctly so far
[15:15] <kgunn> sil2100: yes....
[15:17] <kgunn> sil2100: http://memegenerator.net/instance/45629700
[15:18] <sil2100> kgunn: hah ;)
[16:03] <kgunn> sil2100: so unity-mir failed to build due to "broken packages"...is that just the build interdependency problem (menage a trois of papi, unity-mir & mir)
[16:05] <sil2100> kgunn: so, there are two ways of fixing it:
[16:07] <sil2100> kgunn: it's a problem with packaging, so one way is to modify the unity-mir source and bump the platform-api dependency there as well, as currently it's like this - mir built, platform-api and unity-mir started building at the same time, since platform-api was still building and unity-mir did not depend on the new version it started building with the old platform-api version
[16:07] <sil2100> kgunn: which doesn't work with mir
[16:08] <sil2100> kgunn: so, you can fix it by modifying unity-mir dependencies to depend on a new platform-api
[16:08] <sil2100> kgunn: the second way is easier:
[16:08] <sil2100> kgunn: you can simply rebuild only unity-mir in the silo once platform-api is built
[16:09] <sil2100> kgunn: you can do that by specifying unity-mir in the build job in the PREPARE_ONLY text edit
[16:10] <sil2100> kgunn: but you have to have platform-api already built in the PPA
[16:10] <sil2100> kgunn: it's less 'nice', but much faster and acceptable this time
[16:10] <kgunn> sil2100: ok....so do i wait? or kill the build ?
[16:10] <sil2100> kgunn: just wait
[16:10] <kgunn> ah
[16:10] <kgunn> thanks...
[16:11] <sil2100> kgunn: just wait, and once it's done, just click Build, write 'unity-mir' in PREPARE_ONLY and rebuild
[16:11] <kgunn> sil2100: right...i recall it from the training....just didn't know if i should wait
[16:11] <kgunn> but makes sense
[16:16] <sil2100> kgunn: actually the wait until the building is finished because of platform-api, we want it to be built before we press rebuild
[16:39] <sil2100> kgunn: could you make sure that a 'run ALL autopilot tests are run' in the test-plan for Mir landings? Since it's a component that can affect many many components ;)
[16:58] <bfiller> sil2100: what's the status of line 43 in CI Train?
[17:00] <sil2100> bfiller: hm, we can land it soon I guess
[17:00] <sil2100> I have to go AFK now, so see you tomorrow
[17:00] <ogra_> didrocks, no meeting ?
[17:01] <ogra_> (seeing sil2100 leave)
[17:01] <bfiller> didrocks: have a bunch of things in the CI Train asks for a few days
[17:01] <didrocks> ogra_: on the way
[17:01] <ogra_> ah k
[17:01] <ogra_> no hurry
[17:01] <ogra_> just wanted to know
[17:01] <bfiller> didrocks: do those automaticaly get a silo? I do I ned to do something else?
[17:01] <didrocks> bfiller: you can join the meeting
[17:01] <bfiller> didrocks: which meeting?
[17:02] <didrocks> bfiller: check the UE calendar
[17:02] <didrocks> you should see a meeting
[17:02] <didrocks> right now
[17:03] <didrocks> https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV91cTRvNmQyMWJvNmJ0bm1mcW9xZWtsNTdnOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.cg7k3h1nmqml7psc1nn68223i0
[17:03] <didrocks> bfiller: ^
[17:07] <bfiller> didrocks: Im at sprint in meeting can't come
[17:07] <bfiller> didrocks: could you look at my requests in the sheet? there are a few of them
[17:07] <bfiller> should be pretty self explanatory
[17:08] <bfiller> didrocks: if not I'll try and join tomorrow
[17:10] <didrocks> bfiller: one sec, will explain to you
[17:14] <Mirv> doanac: intel AP machine crash http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=qa-intel-4000/1298/console
[17:14] <doanac> Mirv: ack
[17:15] <didrocks> bfiller: back from the meeting
[17:16] <didrocks> bfiller: so… as described on the ubuntu-touch ML, we had a lot of regressions
[17:16] <didrocks> bfiller: so, we had to block landings so that we can move quicker after that
[17:16] <bfiller> didrocks: ah ok
[17:16] <bfiller> I'm behind on my mail :)
[17:16] <didrocks> (and give priority slots to what we had to revert)
[17:16] <didrocks> bfiller: ah ok, that explains :p
[17:17] <didrocks> bfiller: so, you have one slot assigned to you already
[17:17] <didrocks> bfiller: and the dialer-app crash isn't fixed btw
[17:17] <bfiller> didrocks: I know, we've been trying. don't know how to fix
[17:17] <didrocks> anything else you need to land urgently (we can still assign another slot to you I guess)
[17:17] <didrocks> ?
[17:17] <Mirv> doanac: and nvidia seems pretty dead too http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=autopilot-nvidia/1298/console
[17:18] <bfiller> didrocks: we can't repro the crash on the device for the dialer-app. and stack trace is useless
[17:18] <bfiller> didrocks: so we don't know how to proceed
[17:18] <Mirv> I'd wish to get one good run of unity stack check job (unity7)
[17:18] <didrocks> bfiller: one maguro? weird, we can get it everytime though
[17:18] <bfiller> didrocks: make
[17:19] <bfiller> mako
[17:19] <didrocks> plars: can you maybe help bfiller, is there any discrepency in the way we are running tests?
[17:19] <didrocks> bfiller: meanwhile, I can attribute to you as well line 44
[17:19] <didrocks> Fix for incorrect keyboard orientation on tablet sidestage
[17:19] <didrocks> but as there is source + MP, maybe it's a complex landing for oyu
[17:19] <didrocks> bfiller: would you prefer "Share current call contact info with the greeter in preparation for greeter running as lightdm user. Fix bug with call duration time."
[17:19] <didrocks> (line 43)
[17:20] <plars> didrocks, bfiller: you mean between mako and maguro? no
[17:20] <bfiller> didrocks: whichever one is easier to land is fine, no prefereence
[17:21] <didrocks> ogra_: image rebuilding
[17:21] <ogra_> yay
[17:21] <bfiller> plars: the dialer crash, is it on mako or maguro? we've been testing on mako and can't repro
[17:21] <didrocks> bfiller: ok, so attributing to you 43, you have two slots, enjoy :)
[17:21] <bfiller> didrocks: thank you:)
[17:21] <didrocks> yw!
[17:22] <plars> bfiller: it's on mako - there's no difference between how those two devices run the tests
[17:22] <didrocks> and it's 100% of the time, so there is clearly a difference somewhere in how the CI system and bfiller is running the tests I guess
[17:23] <didrocks> bfiller: plars: I let you in your hands :)
[17:23] <bfiller> plars: boiko and I have tried so many times. I just run autopilot run dialer_app direclty on the device
[17:23] <plars> bfiller: let me try on my device at home
[17:23] <bfiller> plars: anything different we need to do?
[17:24] <plars> bfiller: the main difference for us is that we are running scripts that do all the setup stuff around it (unlocking, etc)
[17:24] <bfiller> plars: yup, try it on your device and see if you can repro
[17:24] <plars> bfiller: do you use phablet-test-run?
[17:25] <bfiller> plars: no
[17:25] <plars> bfiller: any reason why not?
[17:25] <bfiller> plars: I run autopilot directly
[17:25] <bfiller> plars: I can try that
[17:25] <didrocks> bfiller: you should really try as well to use phablet-test-run (especially when using the train)
[17:25] <bfiller> ok
[17:25] <didrocks> bfiller: that will help to avoid "green to me, not on CI infra"
[17:25] <didrocks> thanks!
[17:25] <plars> bfiller: We use a script at the moment run from utah that runs autopilot, but the scripts we are moving to run it with phablet-test-run (it also shows up under our staging system where we're running that)
[17:26] <bfiller> plars: will try with phablet-test-run
[17:26] <bfiller> should be the same
[17:33] <doanac> Mirv: looks like the kernel may have gotten boggled on the nvidia node. i'm trying to get it unstuck now
[17:36] <Mirv> doanac: thanks, if it takes more than 24 minutes, if you don't mind rerun the 'unity' stack of cu2d head with 'foo' in the package parameters list so that it tries to run check job only :)
[17:53] <doanac> Mirv: the nodes are both back online now.
[17:53] <Mirv> doanac: thanks, I'll try them out
[17:57] <plars> didrocks: bfiller disappeared, but I get the same crash locally when just running with phablet-test-run
[18:01] <didrocks> plars: let's see when he's back, you should have some time coverage :)
[18:01] <didrocks> but ok, you can reproduce thanks!
[18:01] <plars> yep
[19:05] <dobey> can anyone retry https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5551494 please? looks like thumbnailer got published after this build failed
[19:06] <cjwatson> dobey: done
[19:06] <dobey> cjwatson: thanks
[21:19] <plars> something is looking very wrong on 163
[21:19] <plars> http://ci.ubuntu.com/smokeng/trusty/touch/
[21:19] <plars> we're not very far in, but 14-15 tests on both devices
[21:21] <asac> plars: ouch :)
[21:21] <tvoss> asac, plars seems to be location-service spinning
[21:22] <asac> http://people.canonical.com/~ogra/touch-image-stats/20140204.1.changes
[21:22] <tvoss> asac, plars with that system-settle-before and system-settle-after fail
[21:22] <asac> systemsettle
[21:22] <asac> so yeah
[21:22] <tvoss> on it
[21:22] <plars> indeed: https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-gallery-app-autopilot/155/artifact/clientlogs/top_after.log/*view*/
[21:23] <plars> thanks tvoss
[21:23] <asac> can phablet-test-run also run systemsettle?
[21:23] <asac> that would have helped the lander to see this i guess
[21:23] <tvoss> yup, that would have helped
[21:23] <asac> saving time as lander can fix as he goes
[21:23] <asac> tvoss: still have the same silo?
[21:23] <asac> or was it taken away :)?
[21:23] <tvoss> asac, nope, taken away
[21:24] <asac> heh
[21:24] <tvoss> asac, mir occupied it
[21:24] <asac> ok so reenter the scene
[21:24] <asac> so the initial approach was to only merge to trunk and release once the image goes green
[21:24] <asac> guess means we need to keep free capacity of silos
[21:24] <asac> so we cant get an emergency landed due to all silos being active
[21:25] <asac> like fasttrack silos
[21:25] <tvoss> asac, plars I ran the complete autopilot setup according to the wiki page
[21:25] <rsalveti> asac: right
[21:25] <asac> sure, but the systemsettle isnt included
[21:25] <asac> so include it
[21:25] <plars> systemsettle isn't an autoilot test though - it's just looking at top
[21:25] <asac> not sure how to run it thoug :) ... but would be cool to have it as a reminder/todo
[21:26] <asac> plars: right. henmce i was hoping we could have a phablet-test-run --with-ss
[21:26] <asac> or something
[21:26] <asac> until then its a bit tricky to run (but can be done i am sure)
[21:26] <tvoss> plars, asac can I just fix on top of trunk?
[21:26] <asac> i dont know
[21:26] <asac> you need a MP to land
[21:26] <rsalveti> tvoss: what caused the location service to top the cpu this way?
[21:26] <asac> if nohthing else lands on trunk you can also land trunk
[21:26] <asac> but doesnt really help much i guess
[21:27] <asac> if you had the silo still you could have hit rebuild
[21:27] <asac> after updating the MP with the fix
[21:27] <tvoss> asac, that would have been ideal, yes
[21:27] <tvoss> rsalveti, it's happening somewhere on the android side of the gps provider
[21:28] <tvoss> rsalveti, after some time trying to acquire a fix, it goes spinning *sometimes*, have seen that on my phone, too
[21:28] <tvoss> rsalveti, not sure what would access the gps in the test setup, though
[21:28] <rsalveti> right, shouldn't we revert the lastest upload then?
[21:28] <rsalveti> until we're able to get this fixed properly
[21:28] <asac> veebers: you have two silos?
[21:28] <asac> veebers: 004 and 007?
[21:29] <veebers> asac: let me check
[21:29] <asac> i think landing-010 is free
[21:29] <veebers> asac: ah right, 004 is for liabutopilot-qt and can be removed (as those changes were backed out)
[21:29] <rsalveti> guess it can't be reverted that easily as you also migrated to the new dbus cpp api
[21:29] <tvoss> rsalveti, +1, I know how to fix it, but it's getting late here
[21:30] <rsalveti> besides adding tons of coding style fixed and so on
[21:30] <rsalveti> *fixes
[21:30] <rsalveti> tvoss: problem is that it might not build if we revert it
[21:30] <tvoss> rsalveti, fair
[21:31] <asac> tvoss: guess, its not super urgent; fix it tomorrow morning and reach out to didrocks first thing (or send him a mail so he knows you are coming through)
[21:31] <asac> unless there are new landings flushing happening
[21:31] <asac> anyway would be better to get this fixed now :)
[21:31]  * asac has to learn how this thing works
[21:31]  * rsalveti wants to land mir today if possible still
[21:31] <asac> slangasek: do you know how this silo allocationm/cleaning thing works?
[21:31] <asac> slangasek: in the spreadsheet?
[21:31] <tvoss> rsalveti, asac easy fix is to just not start the gps provider. It won't hurt as people are not using it anyway (or it takes 15 minutes for a fix)
[21:31] <tvoss> with that, we can unblock the image and land the proper fixes over the next days
[21:32] <slangasek> asac: I know the principles, I don't have access to the mechanics of allocating them
[21:32] <tvoss> asac, rsalveti thoughts?
[21:32] <rsalveti> it's really bad that we only have people that knows about the silos and such at the EU timezone
[21:33] <asac> its just hitting a button once people know what to remember
[21:33] <asac> so i think we should train a few more core devs like slangasek so they can help allocating those silos for emergencies
[21:33] <asac> etc.
[21:34] <rsalveti> tvoss: well, if you can get a better fix tomorrow morning that would still be better
[21:34] <asac> do we see other tests failing?
[21:34] <asac> or only settle?
[21:35] <asac> if there is another test failing due to the timing things
[21:35] <asac> we should ensure its going away locally by fixing this
[21:35] <asac> and then its not really critical
[21:35] <asac> afaik we promoted an image today?
[21:35] <asac> for me its important to see if we got other regressions on top - which would be hidden if anything else failed beyond ss
[21:36] <asac> tvoss: just send a mail to didrocks saying you work on a fix and will touch base with him tomorrow about landing that.
[21:36] <asac> guess thats fine
[21:37] <tvoss> rsalveti, that would mean me splitting the big branch in a hurry. Not sure if that makes sense
[21:39] <asac> tvoss: i think its fine to just keep the bandaid fix so we can land it tomorrow alongside the other landings
[21:39] <rsalveti> tvoss: right, can't you just debug and try to fix the issue itself?
[21:39] <rsalveti> asac: we promoted an image today
[21:39] <asac> as long as its just systemsettle it shouldnt block the line if your bandaid is confirmed (if i was the landing manager)
[21:39] <rsalveti> so not promoting one tomorrow should still be fine, but we should get this fixed tomorrow
[21:40] <asac> rsalveti: yeah, so i think if we have a profen fix/workaround for tomorrow to land, we can continue flushing silos, which is all we care
[21:40] <asac> rsalveti: we can still promote if the workaround lands tomorrow
[21:40] <rsalveti> yup
[21:40] <asac> we certainly dont want to keep ss failing
[21:40] <asac> as new things might sneak in
[21:40] <asac> covered
[21:40] <rsalveti> yeah, problem is not knowing if we had regressions or not
[21:40] <rsalveti> besides this one
[21:40] <asac> tvoss: so yeah, propose the workaround 1 line patch to not start the service, double check that that helps
[21:40] <asac> and then put it on spreadsheet for morning shift
[21:41] <tvoss> asac, just sent mail to didrocks, will work with him for the fix tomorrow, or do you want it today?
[21:41] <rsalveti> tomorrow morning should still be fine
[21:41] <asac> tvoss: you get up early enough. think we ould be good if he could just land something in the first batch tomorrow
[21:42] <tvoss> asac, sure, will take care of that
[21:42] <asac> if the real solution takes a while, dont tryu to hurry things, just go safe and get ss green with the least disrupting detour imaginable
[21:42] <tvoss> yup
[21:42] <asac> still double sure you test whatever is landing :P
[21:42] <asac> even single lines are causing havoc
[21:42] <asac> hehe
[21:42] <asac> thanks
[21:42] <asac> go to bed then :)
[21:42] <asac> or have fun
[21:43] <tvoss> asac, of course, just started armhf package build
[22:07] <thomi> fginther: got a second?
[22:09] <fginther> thomi, in a couple minutes
[22:10] <rsalveti> asac: hey, we need you
[22:10] <rsalveti> asac: we need to either remove xorg-server from landing slot 2 or do a packaging respin of the latest version to build against latest mir
[22:11] <rsalveti> and only you, did or sil can do that
[22:11] <rsalveti> kgunn: ^
[22:17] <asac> rsalveti: ?
[22:17] <asac> rsalveti: do you know where the ppa is?
[22:18] <asac> rsalveti: do you know what i need to do?
[22:18] <asac> delete the package from ppa?
[22:18] <rsalveti> yup
[22:18] <rsalveti> hold on
[22:18] <asac> kk
[22:18]  * asac will wait
[22:18] <rsalveti> asac: https://launchpad.net/~ci-train-ppa-service/+archive/landing-002
[22:18] <rsalveti> asac: delete xorg-server
[22:19] <asac> thats outdated
[22:19] <asac> how can that cause issues>?
[22:19] <rsalveti> asac: that's why
[22:19] <asac> what doesnt work?
[22:19] <fginther> thomi, what's up?
[22:19] <rsalveti> Please ensure that this version has been merged back in trunk and relaunch prepare or use ignore version destination option.
[22:19] <rsalveti> asac: ^
[22:19] <rsalveti> 2014-02-04 22:04:59,574 INFO Checking xorg-server (2:1.14.5-1ubuntu5)
[22:19] <rsalveti> 2014-02-04 22:05:02,686 ERROR Previous available version (2:1.14.5-1ubuntu4) is not the latest version anymore in the archive (2:1.15.0-1ubuntu1).
[22:19] <rsalveti> Please ensure that this version has been merged back in trunk and relaunch prepare or use ignore version destination option.
[22:19] <rsalveti> http://162.213.34.102/job/landing-002-2-publish/12/console
[22:19] <thomi> fginther: I was hoping I could get you to please disable automerging on lp:autopilot, as apparently it conflicts with the new landing process
[22:19] <rsalveti> I tried to use the ignore version destination flag, but didn't work
[22:20] <asac> rsalveti: did you get trained?
[22:20] <rsalveti> indirectly, yes
[22:20] <rsalveti> that in theory would fix that (selecting the right option when publishing it)
[22:20] <asac> rsalveti: you remember didrocks saying something about those packages being mandatory to be there or optional after the silo was configured to have them?
[22:20] <rsalveti> but didn't work
[22:20] <fginther> thomi, sure. Is the landing process supposed to be using lp:autopilot or lp:autopilot/1.4?
[22:20] <asac> i know he said one of those, but cant remember :/
[22:20] <fginther> thomi, just asking in case something else is borked
[22:21] <rsalveti> asac: not sure for packages that are manually uploaded, as xorg-server
[22:21] <rsalveti> that wasn't part of the CI
[22:21] <asac> right he was teaching something about them :/
[22:21] <thomi> fginther: apparently lp:autopilot. I haven't figured out how we're going to support multiple releases yet.
[22:21] <rsalveti> asac: just remove and we'll see :-)
[22:21] <asac> rsalveti: well in the first training session it was :)
[22:21]  * asac scared
[22:21] <rsalveti> lol
[22:22] <thomi> I may delete the 1.4 series until we're in 'U'
[22:22] <asac> i have literally no idea how to delete packages from ppas anymore :)
[22:22] <asac> hehe
[22:22] <asac> funnny
[22:22] <asac> ok found it
[22:22] <rsalveti> asac: cool
[22:22] <asac> now need to be brave
[22:22] <rsalveti> ppa info -> delete packages
[22:22] <rsalveti> DONE
[22:22] <asac> ok done
[22:22] <asac> Source and binaries deleted by Alexander Sack:
[22:22] <asac> xorg-server 2:1.14.5-1ubuntu5 in trusty
[22:23]  * asac adds another TODO to talk to didrocksa bout
[22:23] <asac> wants to know why not all core-dev are in that teawm
[22:23] <asac> guess is because we have no docs to hand out about this part
[22:23] <rsalveti> asac: yeah, indeed
[22:24] <rsalveti> well, the problem here is that the flag is not working properly
[22:24] <asac> what flag?
[22:24] <rsalveti> IGNORE_VERSIONDESTINATION
[22:24] <rsalveti> Ignore if the latest version in destination doesn't match when prepare was started
[22:24] <asac> isnt this IGNORE_VERSIONSOURCE ?
[22:24] <asac> e.g. ppa content being the source rather than the dest?
[22:24] <rsalveti> well, I don't have this flag here
[22:24] <asac> right
[22:24] <asac> just saying might be the wrong destination you think you are tweaking :)
[22:25] <asac> you need to attend training next time
[22:25] <rsalveti> right
[22:25] <asac> and someone write docs :)
[22:25] <rsalveti> yup
[22:25] <rsalveti> let's see now
[22:25] <asac> rsalveti: isnt sergio the lander? get trained by him :)
[22:25] <asac> if you are his backup
[22:25] <rsalveti> asac: not the lander itself (I still need to sponsor the landing)
[22:25] <rsalveti> asac: but he's off today
[22:25] <asac> so is the package gone?
[22:26] <rsalveti> asac: it seems
[22:26] <rsalveti> bus factor is really high currently here
[22:26] <asac> what does the role "landing-sponsor" entail? e.g. the core-dev sign off before copying to archive?
[22:26] <rsalveti> asac: yup
[22:27] <asac> ok. was a new term for me :)
[22:27] <asac> but ok to adopt i guess
[22:27] <rsalveti> yup
[22:30] <rsalveti> asac: still failed, guess we need a respin for xorg-server
[22:31] <rsalveti> asac: can you temporarily add me to the team?
[22:31] <rsalveti> can remove right after the upload
[22:32] <asac> sure
[22:32] <asac> rsalveti: rsalveti.net?
[22:32] <asac> is your new primary email?
[22:32] <rsalveti> asac: yup
[22:32] <asac> didnt you use canonical at some point?
[22:32] <asac> ok
[22:33] <asac> welcome to the team
[22:33] <asac> please use your powers wisely
[22:33] <rsalveti> yeah, but used rsalveti.net to better handle the tons of emails I get from launchad
[22:33] <asac> procmail > /dev/null
[22:33] <rsalveti> canonical.com is fine now that we have gmail support
[22:33] <asac> i use procmail to inject mailing=list tags
[22:33] <asac> so i can sort them in gmail reliably
[22:34] <asac> because all other searches based on subject etc. seem to be fuzzy :)
[22:34] <asac> hehe
[22:34] <rsalveti> yeah
[22:34] <asac> s/tags/headers
[22:35] <kgunn> asac: rsalveti....i see some serious voodoo going on here :)
[22:35] <kgunn> hope it works
[22:38] <rsalveti> kgunn: trying hard
[22:39] <rsalveti> now waiting for xorg-server to build and then will try to publish it again
[22:42] <asac> rsalveti: did you rebase our change ?
[22:42] <asac> or did we do a zero change bump before?
[22:42] <rsalveti> asac: that was just a packaging bump to build against latest mir
[22:42] <asac> ok so transition
[22:43] <asac> rsalveti: so the tool should have auto updated that package at best, right?
[22:44] <asac> so not really a "source package", but a special category "transition reverse"
[22:44] <asac> that could be treated more smartly with auto bumping
[22:44] <fginther> thomi, automerger for lp:autopilot is disabled now
[22:44] <rsalveti> asac: ideally, yes
[22:45] <rsalveti> an automatic way to build reverse-dependencies when we have an api/abi change
[22:45] <rsalveti> brb
[22:48] <thomi> thanks fginther, I take it that's effective immeadiately?
[22:48] <fginther> thomi, yes
[22:48] <thomi> coolio!
[22:48] <thomi> cheers
[22:48] <fginther> thomi, have a good day
[23:03] <xnox> rsalveti: what do you mean "automatic"? unless there is hard versioned shlib depends, such rebuilding will not help upgrades with apt, since one would be able to upgrade half things but not the others (on the end client that is). And if library packages are not renamed, they wouldn't be co-installable such that e.g. all PPAs would break once ubuntu archive moves.
[23:04] <xnox> rsalveti: it's less pain to not break API/ABI if at all possible, failing that do a proper transition. None of which should be part of "i'm landing a mir bug-fix".
[23:07] <rsalveti> xnox: right, there's no easy way, but we could try to automate if we don't leave the slot open for too long
[23:08] <xnox> rsalveti: well, we have plenty of tools available, but we do not have support for "binNMUs" in launchpad. (debian has it)
[23:09] <xnox> rsalveti: with binNMUs, you'd be able to request launchpad to bump version number and rebuild reverse-depends against "bumped soname library".
[23:09] <xnox> rsalveti: that's the most painful part, that could be automated - thus not requiring "no change rebuilds" source packages prepared and uploaded.
[23:10] <xnox> rsalveti: but it also is a very hard non-trivial bug to solve on launchpad, and due to multiarch, hasn't been yet fully resolved to keep co-installability working when only partial architectures get the binNMU rebuild.
[23:10] <rsalveti> right, indeed
[23:10] <xnox> (on dpkg / apt level)
[23:12] <xnox> rsalveti: there is a proposal / design to resolve dpkg, and then we could look into designing/implementing things on launchpad/soyuz side. But it's a large investment of development time, and we have other bigger priorities at the moment. We've managed for 10 years without that shortcut ;-)
[23:13] <rsalveti> yeah, we have way bigger things to deal first
[23:24] <rsalveti> kgunn: did you get the ci training as well?
[23:24] <kgunn> rsalveti: i did
[23:24] <rsalveti> kgunn: still can't land because it's now complaining about my direct upload
[23:24] <rsalveti> 2014-02-04 23:19:43,259 ERROR Version in ci-train-ppa-service/landing-002 (2:1.15.0-1ubuntu2) is not the last one prepared (2:1.14.5-1ubuntu5) (direct upload?).
[23:24] <rsalveti> 2014-02-04 23:19:44,751 ERROR Previous available version (2:1.14.5-1ubuntu4) is not the latest version anymore in the archive (2:1.15.0-1ubuntu1).
[23:25] <kgunn> rsalveti: mmm, only thing i know about that is rel team & "core-dev" can upload
[23:25] <kgunn> so its all voodoo to me
[23:25] <rsalveti> kgunn: what do you need to do when you want a package rebuild from something that doesn't have a proper mr
[23:25] <rsalveti> kgunn: how do you add a new MR?
[23:25] <rsalveti> to the slot
[23:26] <kgunn> sorry...i only know from a "lander" perspective that you can add an MP to the landing sheet
[23:26] <kgunn> then it'll get added into the silo by some magic
[23:26] <rsalveti> right, there must be some magic place where they actually add that
[23:27] <kgunn> rsalveti: its only a guess but maybe the button labeled "reconfigure (landing team)"
[23:28] <kgunn> rsalveti: for fear of borking...maybe we leave it for sil/didrocks to help address ?
[23:28] <rsalveti> kgunn: where is that button?
[23:28] <veebers> doanac, fginther: is there a way to use the calxeda server to build debs? i.e. if i'm working on a lib that doesn't build under qemu
[23:28] <kgunn> look on the tab for the 002 silo
[23:29] <rsalveti> right
[23:29] <doanac> veebers: sorry - don't know the answer.
[23:29] <rsalveti> that should be it
[23:29] <veebers> doanac: nw, cheers
[23:29] <kgunn> rsalveti: note...xorg-xserver is totally manual wrt this process...
[23:29] <kgunn> unless you're trying to add something else ?
[23:32] <rsalveti> kgunn: yeah, I give up, don't want to explode things around
[23:32] <rsalveti> kgunn: let me sent an email
[23:32] <kgunn> rsalveti: thanks for trying...i do appreciate it...i want it in archive as bad as anybody
[23:33] <kgunn> ok..wife calling me
[23:33] <kgunn> later