[00:02] <Wellark> robru: thanks!
[00:10] <ToyKeeper> alecu: Is silo 8 fixed now?
[00:11] <alecu> ToyKeeper: yes, we added a fix, and we added some workarounds to the test plan to account for a misterious bug where the dash remains fixed and untappable until you switch apps.
[00:12] <alecu> ToyKeeper: tedg suspects that bug is in Unity, and will look at it tomorrow with tvoss
[00:15] <ToyKeeper> alecu: Flashing now for testing...  could take a while to finish though.
[00:16] <alecu> thanks!
[00:16] <ToyKeeper> (faster if none of the features work in the stock image...  longer if they work but changed, since I need to test before and after)
[00:16] <alecu> will join the family for dinner and will check here afterwards
[00:17] <ToyKeeper> I'm a little distracted today too; just have tonight to finish house repairs before the new floor goes in tomorrow morning.
[00:18] <alecu> ToyKeeper: keep in mind that this feature is hidden for normal users; only QA people wishing to test purchases in staging end up running this script and following these steps
[00:18] <ToyKeeper> Hmm.
[00:18] <alecu> ToyKeeper: also, it's the first time we are asking QA people to take a look at this
[00:19] <ToyKeeper> In that case, perhaps I can skip the "before" phase.
[00:19] <alecu> great
[00:20] <alecu> sorry this is so late in the cycle, but we've been blocked by dash-as-app landing in order for the final installation step is completed after the purchase.
[00:20] <ToyKeeper> I think pretty much everyone is behind where they'd like to be.  There's just too much to do.  :)
[00:21] <alecu> indeed :-
[00:21] <alecu> )
[01:56] <ToyKeeper> alecu: It mostly looks good so far, but the default page to add a card isn't working.  Probably because the card details field is partly hidden and it's not obvious what the expected data is:  http://toykeeper.net/tmp/phablet/2014-08-07/add-cc-doesnt-fit.png
[01:58] <alecu> ToyKeeper: those are awesome news!
[01:58] <ToyKeeper> ... and the OSK starts in a mode which doesn't allow entering the correct data.  Like, there's no way to enter a space or a slash.
[01:59] <alecu> ToyKeeper: the page to enter card details is a webpage straight out of our servers, and it's very far away from what we are changing in this branch
[01:59] <alecu> ToyKeeper: in fact, let's open a bug with that screenshot in Software center agent
[02:00] <ToyKeeper> alecu: ... and after entering bad data on the legacy interface, it fails back to the new UI with no link back to the legacy UI.
[02:00] <ToyKeeper> But again, server-side.
[02:00] <ToyKeeper> The client looks fine.
[02:01] <alecu> yay!
[02:01] <ToyKeeper> (aside from issues noted in the test plan, which I assume we're not blocking over)
[02:01] <alecu> sure
[02:02] <alecu> ToyKeeper: thanks a lot for staying so late. Hope you can finish with your house repairs :-)
[02:03] <ToyKeeper> It's not late for me...  I'm just working 15+ hours between Canonical and the house repairs.  I'll be back again later tonight.
[02:03] <robru> ToyKeeper, thanks!
[02:05] <imgbot> [02:05] <robru> infinity, stgraber: anybody around? need a core dev ack on a new binary package https://ci-train.ubuntu.com/job/landing-008-2-publish/lastSuccessfulBuild/artifact/packaging_changes_pay-service_2.0.0+14.10.20140807.1-0ubuntu1.diff
[02:05] <ToyKeeper> Er, did we just miss getting silo 8 into image 178?
[02:05] <alecu> I'm very happy anyway :-)
[02:06] <robru> ToyKeeper, yep
[02:06] <ToyKeeper> Sigh.
[02:06] <robru> ToyKeeper, it wasn't a close miss. between the core dev ack + proposed migration it'll probably be 2-3 hours before it's actually in the archive.
[02:06] <ToyKeeper> It took a while to get the environment changes to stick, since I don't have phablet-shell set up and it doesn't work via adb shell.
[02:09] <alecu> ToyKeeper: we can add some instructions to run over plain adb shell
[02:09] <alecu> ToyKeeper: "su -l phablet" should be enough
[02:51] <Wellark> so quiet..
[03:40] <imgbot> [03:40] <imgbot> [04:04] <Mirv> hello
[06:59] <cjwatson> Morning.  How are we looking for a promotion?
[07:01] <cjwatson> The bug list doesn't look immediately promising for that :-(
[07:06] <ToyKeeper> Drat, it doesn't want to let me mount /android/system as read-write.
[07:06] <cjwatson> Loop-mount on RO base?
[07:07] <ToyKeeper> Yes, I think so.  I'm looking for the image file.
[07:10] <Mirv> no progress seems to be yet done on the date/time picker or the camera launch (popup notifications)
[07:10] <Mirv> music app was confirmed to be fixed as it passed 100% on #177
[07:11] <Saviq> cihelp, hey, our qmluitests job started timing out after yesterday's jenkins reboot (??) http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/814/console
[07:11] <Saviq> a complete run before took under an hour, now it times out after 3h
[07:12] <Saviq> always after the actual tests complete, last step seems to be generating coverage report
[07:13] <Mirv> #178 would be the bestest ever if it weren't for those two blockers
[07:13] <Mirv> mako pass rate 99.0%
[07:24] <Saviq> we'll get there :)
[08:03] <tvoss> trainguards: can I get a silo for line 31?
[08:06] <sil2100> tvoss: hi! Let me try
[08:06] <tvoss> sil2100, thank you
[08:06] <ogra_> wow, looks like traincon actually helped :)
[08:08] <sil2100> tvoss: how's silo 004 going? :)
[08:09] <sil2100> Ah, ok, so the hot-fix landed in the meantime
[08:09] <ogra_> camera app crashes though :/
[08:09] <sil2100> So the only blocker left for us is the date-time picker...
[08:09] <sil2100> ogra_: on start?
[08:09] <ogra_> no on the smoketest page
[08:10] <ogra_> surely unrelated to the location stuff
[08:10] <ogra_> but due to that we didnt have any results for it for the last uploads it had
[08:11] <sil2100> It works fine on my device, so I wouldn't consider it a blocker, as it probably crashed on shutdown
[08:11] <ogra_> oh, i didnt talk about it being a blocker :)
[08:11] <ogra_> just another thing we have to look at now
[08:11] <sil2100> zsombi: hi! Soooo...! Any luck with the date-time picker?
[08:12] <sil2100> zsombi: it's basically our last blocker (I hope)
[08:12] <zsombi> sil2100: I made a small JS workaround for it, as it did not work in C++.... it ended up that Qt Compositor changes screwed it up
[08:12] <sil2100> ogra_: right... let's see if it happens on the next smoketesting
[08:12] <ogra_> yup
[08:13] <sil2100> zsombi: yeah, we saw Mirv bi-secting it to QtCompositor - so do you think we can land the JS workaround today? We would be super happy
[08:13] <zsombi> sil2100: so, all we can do in the toolkit is to provide this workaround which apps shoudl use till we get the Qt Compositor fixed
[08:14] <zsombi> sil2100: that wouldn't be the only thing we must do: apps must use the PickerPanelWorkaround.openDatePicker() in order to get it working
[08:14] <sil2100> zsombi: ah, ok, so like a new component will have to be used instead now by applications? i.e. the calendar app will have to be modified as well?
[08:14] <zsombi> sil2100: yes, until we get the causing bug fixed, then they can go back to PickerPanel
[08:14] <zsombi> sil2100: replacing the component "PickerPanel" with the workaround woudl break the API
[08:14] <tvoss> sil2100, still exhibiting the issues, but the immediate user facing problems are fixed by whitelisting the camera app and osmtouch
[08:15] <ogra_> tvoss, trust-stored-skeleton also has a bunch of crashes during testing, did anyone ping you about that already ?
[08:15] <tvoss> ogra_, nope
[08:15] <sil2100> zsombi: works for me! If you and Zoltan could prepare a landing for the PickerPanelWorkaround addition we would drive that, and then ask someone from the calendar-app developers to use the new component
[08:16] <zsombi> sil2100: ai sire!
[08:16] <ogra_> tvoss, at the bottom of http://ci.ubuntu.com/smokeng/utopic/touch/mako/178:20140808:20140805.2/9562/default/ and http://ci.ubuntu.com/smokeng/utopic/touch/mako/178:20140808:20140805.2/9562/webbrowser_app/ if you want to look at them later
[08:16] <sil2100> zsombi: thanks in overall!
[08:16]  * sil2100 smells promotion today
[08:17] <tvoss> zsombi, do we have a theory why qtcomp influences the date-time picker. I have difficulties understanding why qtcomp would influence in-app rendering
[08:17] <sil2100> davmor2: ready your dogfooding skills, those will be needed soon!
[08:17] <tvoss> ogra_, thanks, do we have retraces available for the crash files?
[08:18] <zsombi> tvoss: not much, but all we know was that it got broken after that fix
[08:18] <ogra_> tvoss, i dont think so ... psivaa-afk-bbl could tell you i guess
[08:18] <zsombi> tvoss: what it looks from our side is that it behaves like the Singleton would have been created with a different root context
[08:18] <zsombi> tvoss: despite it gets created with the same QML engine
[08:19] <zsombi> tvoss: the Singleton (PickerPanel) does not get anything from the other root context
[08:19] <tvoss> zsombi, sure, but that's not influenced by qtcomp. Are you sure that the setup is not racy, and that no change to qt/qml landed at the same time?
[08:19] <zsombi> tvoss: any context property that it gets defined there
[08:20] <psivaa> tvoss: ogra_: we only have this at the moment, if that helps: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/677/artifact/clientlogs/webbrowser_app/_usr_bin_trust-stored-skeleton.32011.crash/*view*/
[08:20] <zsombi> tvoss: there was no other change in between those two releases that would have affected it...
[08:20] <psivaa> otherwise this file has to be processed manually i guess
[08:20] <ogra_> yeah, thought so
[08:21] <Mirv> tvoss: it works by downgrading platform-api, unity8 and by switching from qtmir to qtubuntu+unity-mir. so, no other Qt/QML changes.
[08:23] <Mirv> that is, doing those downgrades on #158 image to the versions that were on #157
[08:26] <tvoss> Mirv, so I would suspect the issue in qtmir then, in its implementation of the qpa
[08:26] <tvoss> Mirv, zsombi do you guys have time on your hands to look into the issue?
[08:27] <zsombi> tvoss: greyback promised to look deeper into this
[08:27] <tvoss> zsombi, ack
[08:31] <Mirv> tvoss: indeed greyback will be looking from the QPA side of things. I was thinking that I'd try to find time to just hack randomly on the calendar's QML although I believe zsombi would have better success rate :) but he's doing the SDK workaround.
[08:56] <psivaa> Saviq: re: your unity-phablet-qmluitests-utopic timing out.. have been digging a *bit.. could not find a reason/solution. will have to wait for either retoaded or fginther
[08:57] <Saviq> psivaa, ok thanks, same happened in http://s-jenkins.ubuntu-ci:8080/job/ubuntu-settings-components-qmltests-utopic/ FWIW
[08:58] <psivaa> Saviq: yea, the same slave
[09:04] <tvoss> sil2100, could you reconfigure silo 4, please?
[09:08] <sil2100> ACK
[09:10] <sil2100> tvoss: done
[09:10] <tvoss> sil2100, thank you
[09:10] <sil2100> yw!
[09:15] <tvoss> hmmm, jenkins is a bit slow today, have been waiting for a vote for +1 hour now: https://code.launchpad.net/~marcustomlinson/process-cpp/set_mask_on_restore/+merge/230059
[09:29] <tvoss> cihelp, could someone help me in understanding the build timeout here: https://jenkins.qa.ubuntu.com/job/location-service-utopic-amd64-ci/163/console
[09:42] <psivaa> tvoss: we see this timing out in some other jobs too.. waiting for retoad to see what caused it
[09:50] <tvoss> psivaa, something is indeed weird: https://jenkins.qa.ubuntu.com/job/process-cpp-utopic-armhf-ci/11/console
[09:59] <sil2100> I need to AFK for a moment, brb
[10:01] <popey> ooh, bug!. making note to file this - have two events at the same time, dismiss first, can't dismiss second...
[10:01] <popey> phone unusable
[10:22] <brendand> are there any silos that need testing?
[10:23] <ogra_> Saviq, the new UI !!!!!!
[10:23] <ogra_> so sexy !!!!!!!!
[10:24]  * ogra_ just upgraded to 178 and is super impressed
[10:25] <brendand> ogra_, you mean the indicator?
[10:25] <brendand> Saviq, url-dispatcher broke again
[10:25] <ogra_> brendand, nope, unity8
[10:26] <brendand> ogra_, what - you mean the loading bar? and the dots?
[10:26] <ogra_> yeah :)
[10:27] <brendand> i think the dots should remain static when swiping
[10:28] <ogra_> yeah, true
[10:28] <ogra_> file a bug :)
[10:29] <cjwatson> sil2100: Was there ever a decision on where the target series would go in the spreadsheet?
[10:33] <nik90> brendand: what changed with the indicator?
[10:34] <Mirv> the dots are nice I agree
[10:38] <Saviq> brendand, ogra_, they can't stay static
[10:38] <Saviq> as the bar in which they are in can move around
[10:38] <ogra_> yeah, what i thought ... would be nicer though
[10:38] <ogra_> it feels like the icon drawing slowness got a bit worse though
[10:39] <ogra_> (in the app scope)
[10:39] <ogra_> (when scrolling)
[10:39] <Saviq> ogra_, [the dots] that was the initial plan, but when we started thinking of all the corner cases, it was safer to make as it is, until we decide on a more static place to put them on at least
[10:39] <ogra_> yeah, no biggie
[10:40] <brendand> nik90, sim details are shown
[10:40] <nik90> brendand: ah yes that
[10:45] <Mirv> I'll try out zsombi's UITK branch and try to modify calendar to use it
[10:46] <alf_> cihelp: Hi! http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-utopic-amd64-ci/871/console is stuck (been building for 3h40m now), can you please check what the problem is?
[11:03] <sil2100> cjwatson: there will be an additional column, but we didn't yet decide on the position
[11:04] <sil2100> cjwatson: I'll experiment as we already have, so to say, 'too many columns'
[11:05] <sil2100> Mirv: thanks!
[11:05] <sil2100> Mirv, bzoltan: is there a branch ready somewhere? Or a landing prepared?
[11:07] <Mirv> sil2100: https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/pickerpanel-workaround/+merge/230075 - from sdk channel I read that it's not being prepared so far, only kept as a backup solution in case the QPA side fix isn't found or such. but given timeline, maybe a landing should be already prepared for that.
[11:09] <sil2100> Yeah, so I would opt for the workaround, as to get a promotable image today still we would have to build an image in like at max 2 hours
[11:10] <piiramar> sil2100: landing item "tone generator support on dialer and telephony-service" (row 22 in the spreadsheet) would need one more test plan https://wiki.ubuntu.com/Process/Merges/TestPlans/tone-generator . can you add that?
[11:10] <Mirv> sil2100: I think we could even add a landing line plus kick a build without waiting for Zoltan?
[11:10] <piiramar> boiko requested it
[11:10] <Mirv> in case it takes time
[11:11] <Mirv> piiramar: adding
[11:11] <piiramar> Mirv: thanks
[11:11] <Mirv> olepa hyvä
[11:11] <piiramar> kiitos
[11:13] <sil2100> piiramar: done
[11:13] <piiramar> thanks
[11:14] <sil2100> Mirv: yeah, would make sense, but first make sure bzoltan is aware of that since I'm not completely aware of their workflow (i.e. staging etc.)
[11:14] <sil2100> So that we make sure it's in staging as well
[11:29] <davmor2> sil2100: so I don't see anything that isn't already known in 178
[11:36] <davmor2> sil2100: oh except the twitter password in accounts I must bug that before I head off :)
[11:40] <popey> davmor2: seen the issue where if you have two alarms at the same time it blocks pin unlock, you have to reboot phone?
[11:40] <sil2100> ;)
[11:41] <davmor2> sil2100: https://bugs.launchpad.net/account-plugins/+bug/1354402 not a blocker just annoying :)
[11:41] <davmor2> oSoMoN: ^ that one might be of interest to you
[11:42] <davmor2> popey: I haven't but I don't often have 2 alarms going off, did you file a bug for it in the meantime I'll try and reproduce it
[11:43] <popey> no, will do
[11:48] <bzoltan> sil2100:  what Mirv said is correct. I am preparing that MR and land it on the staging when we decide to go with the workaround
[11:50] <davmor2> popey: confirmed it so just need a bug
[11:51] <rsalveti> sil2100: the hot fix is not to make it promotable though
[11:52] <rsalveti> sil2100: as it has the camera-app version hardcoded in it, is just to unblock other stuff
[11:53] <rsalveti> sil2100: so the location-service trust-helper changes are still blocking promotion, until silo 4 lands
[11:53] <tvoss> rsalveti, why wouldn't we promote with the hotfix in?
[11:54] <rsalveti> tvoss: because as soon we update camera-app or osmtouch (from app store, for example), it will be broken again
[11:54] <rsalveti> unless we don't care about osmtouch
[11:54] <rsalveti> not sure if camera-app could be updated via store though
[11:54] <popey> davmor2: bug 1354406
[11:55] <tvoss> rsalveti, so your proposal then is to extend the hotfix to arbitrary versions in case silo 4 does not fix the issue?
[11:55] <rsalveti> tvoss: if you want a promotable image, yes
[11:56] <rsalveti> or a revert, as we discussed yesterday
[11:56] <rsalveti> but I thought silo 4 would land today
[11:56] <rsalveti> is it still in progress?
[11:56] <tvoss> rsalveti, dednick is on it, I rebuilt it an hour ago, will test it now
[11:57] <rsalveti> great
[11:57] <rsalveti> sil2100: which other issue is blocking promotion?
[11:58] <davmor2> Right guys I'm off have a great weekend catch you all Monday, sil2100 I won't be around for the  morning meeting so I'll catch up on irc at 11:00 :)
[12:03] <oSoMoN> sil2100, hey, can we have a silo for line 32 ?
[12:04] <ogra_> rsalveti, time/date picker issues iirc
[12:06] <sil2100> tvoss, rsalveti: so, to get things straight... the current hot-fix for the camera-app only work for the current camera-app?
[12:06] <sil2100> And it will be broken again if we release a new version of camera?
[12:06] <bzoltan> sil2100:  we have the workaround branches for the UITK and for the Calendar ready if you guys want it
[12:07] <popey> davmor2: have a great weekend.
[12:07] <sil2100> bzoltan: do you know how the real fix is going?
[12:07] <sil2100> davmor2: see you next week!
[12:07] <bzoltan> sil2100: I do not.
[12:07] <pmcgowan> sil2100, gerry knows why it broke and is working on it
[12:07] <bzoltan> sil2100:  and that is not coming from the SDK team for sure.
[12:08] <rsalveti> sil2100: basically, yes
[12:08] <sil2100> greyback: hi, how far are you with the real fix for the date-time picker?
[12:08] <rsalveti> hm, booted 178 on flo and got a black screen in unity8
[12:08] <bzoltan> sil2100: pmcgowan: just give me the signal if you decide to go with the workaround.
[12:08] <Mirv> bzoltan: sil2100: FYI I didn't get the workaround working yet at least, please advise if I'm doing something wrong https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1351024/comments/20
[12:08] <greyback> sil2100: I have a preliminary fix: https://code.launchpad.net/~gerboland/qtubuntu/fix_1351024/+merge/230094 but it needs careful review & testing
[12:09] <rsalveti> unity8-dash crashed
[12:09] <bzoltan> Mirv:  you need this on the calendar app https://code.launchpad.net/~bzoltan/ubuntu-calendar-app/lp_1351024_workaround/+merge/230095
[12:09] <cjwatson> Forking RTM
[12:09] <rsalveti> together with maliit-server and system-settings
[12:09] <pmcgowan> doooh
[12:09] <Mirv> bzoltan: looks identical to mine http://bazaar.launchpad.net/~timo-jyrinki/ubuntu-calendar-app/use_pickerpanelworkaround_lp1351024/revision/387
[12:09] <pmcgowan> cjwatson, good luck!
[12:09] <cjwatson> (don't panic, there'll be an e-mail a bit later with more details and why this isn't a problem for anyone yet)
[12:10] <alecu> (collective sigh of relief)
[12:12] <sil2100> cjwatson: \o/
[12:12] <rsalveti> sil2100: Saviq: just got on flo https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1354412
[12:12] <rsalveti> now public https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1354412
[12:13] <sil2100> Mirv: you sure it does not work?
[12:13] <cjwatson> This has been a bit of an exercise in how much time we can spend polishing a single extremely complicated run-rarely launchpadlib script
[12:14] <pmcgowan> greyback, do you recommend we go with the sdk and app side workaround or await your review and test?
[12:15] <pmcgowan> tvoss, any testing get done on silo 14?
[12:15] <Mirv> sil2100: well, it doesn't work for me, other eyeballs on the branches and testing would be welcome
[12:15] <greyback> pmcgowan: my fix is more correct, I think it would be better to get it in
[12:15] <tvoss> pmcgowan, have to check with charles, he worked on it yesterday
[12:15] <pmcgowan> greyback, ok lets focus there bzoltan Mirv
[12:16] <sil2100> greyback: excellent
[12:16] <Mirv> yay for greyback's fix
[12:16] <greyback> I'm running UITK AP tests now
[12:16] <bzoltan> greyback: I love you man... I was feeling bad about our solution
[12:17] <greyback> bzoltan: yeah I didn't like it so much :)
[12:17] <bzoltan> greyback:  tell me if you need any help :)
[12:18] <greyback> bzoltan: when CI has the package built, I'd appreciate testers
[12:25]  * sil2100 gets his device ready
[12:33] <cjwatson> restarting branching script, we found a mistake just in the nick of time :)
[12:35] <Mirv> bzoltan: sil2100: greyback|lunch: working! "Tested with a local build, works with this branch! (ie. similar to #157)"
[12:35] <Mirv> (added a comment to greyback's branch)
[12:35] <sil2100> Mirv: with greyback|lunch's lunch? :)
[12:35] <sil2100> *branch
[12:35] <Mirv> sil2100: indeed
[12:39] <Mirv> but was CI broken btw? and does anyone want my hand-build .deb:s to install?
[12:39] <Mirv> I'd add a line for qtubuntu already (doing)
[12:40] <sil2100> Mirv: if you could upload those somewhere then it would save me some time
[12:40] <tvoss> pmcgowan, so silo 14 fixes the issue that we see in the indicator <-> location service communication. However, charles encountered issue in the indicator backend <-> frontend configuration
[12:41] <pmcgowan> tvoss, thanks for update, so still diddling that silo?
[12:41] <Saviq> rsalveti, can you grep ~/.cache/upstart/unity8-dash.log* for "what", the abort message?
[12:41] <charles> pmcgowan, tvoss: yes, it looks like it might be the same issue as https://bugs.launchpad.net/indicator-network/+bug/1336715 in indicator-network <-> the ui toolkit switches
[12:42] <tvoss> pmcgowan, I'm torn, it fixes known issues, but not the whole story. With that, we might want to keep the silo until after traincon and land, then
[12:42] <tvoss> charles, pmcgowan makes sense?
[12:42] <charles> pmcgowan, tvoss, so that still leaves an asterisk next to kenvandine's u-s-s GPS changes, but IMO doesn't block silo 014
[12:42] <rsalveti> Saviq: hm, sorry, flashed it again, will try to reproduce and see if I can get that to you
[12:43] <charles> tvoss, yes, that's fine
[12:43] <pmcgowan> charles, but we could enable at that point yes?
[12:43] <pmcgowan> modulo the bug above
[12:43] <charles> pmcgowan, yes, IMO that's the way to go
[12:43] <pmcgowan> +1
[12:43] <Mirv> http://people.canonical.com/~tjyrinki/datepicker/qtubuntu-android_0.60+14.10.20140728+fix1351024-0ubuntu1_armhf.deb
[12:43] <Saviq> rsalveti, thanks
[12:43] <tvoss> charles, pmcgowan I will take care of getting it in then, likely Monday though
[12:43] <Mirv> and building in silo 015
[12:43] <charles> pmcgowan, tvoss I'll be looking into the UI issue, if I can find the cause before silo 014 lands I'll coordinate with tvoss to see about sandwiching the fix in
[12:43] <sil2100> Mirv: \o/
[12:43] <sil2100> Mirv: thanks
[12:44] <Mirv> yw
[12:44] <Mirv> sil2100: doh, what was the most modern way to do the -gles part, or still a manual upload?
[12:46] <sil2100> Mirv: rsalveti and Saviq know more, but now they do it through MRs, changing the watch file to fetch the non-gles tarball from the silo you're building in
[12:46] <sil2100> Mirv: best if you check some examples in qtmir, since it had some recent uploads to the gles branch
[12:46] <Saviq> Mirv, something along those lines is needed https://code.launchpad.net/~saviq/qtmir/gles-sync-20140716/+merge/227000
[12:47] <Saviq> Mirv, needs a dch -v $non-gles-version and an update to the watch file to point at the correct silo
[12:47] <Mirv> sil2100: Saviq: ok, trying
[12:48] <rsalveti> Saviq: got it again, let me get that for you
[12:48]  * sil2100 is trying out greyback|lunch's fix
[12:49] <rsalveti> Saviq: http://paste.ubuntu.com/7988563/
[12:49] <Saviq> rsalveti, interesting, unity8.log ?
[12:49] <rsalveti> Saviq: http://paste.ubuntu.com/7988571/
[12:50] <Saviq> rsalveti, *interesting*
[12:50] <pmcgowan> Mirv, I am not seeing it fixed here with that deb
[12:51] <Saviq> rsalveti, dash is basically saying it can't connect to unity8, which seems to be happily running
[12:51] <sil2100> Mirv, greyback|lunch: confirming it fixed here on my device
[12:51] <Saviq> rsalveti, like some env isn't set up properly
[12:51] <pmcgowan> what did I do wrong
[12:51] <sil2100> pmcgowan: how come? What do you see?
[12:51] <Saviq> rsalveti, can you please upload those to the bug and confirm it
[12:51] <pmcgowan> same nothing pops up
[12:51] <rsalveti> Saviq: done
[12:51] <sil2100> pmcgowan: since the date-time picker will appear below the keyboard if you have it visible, so you have to dismiss the keyboard first
[12:52] <jgdx> cihelp: seems building of uss is broken? https://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-ci/1173/
[12:52] <Mirv> Saviq: trying with that https://code.launchpad.net/~timo-jyrinki/qtubuntu/gles-sync-20140808/+merge/230101
[12:52] <sil2100> pmcgowan: did you reboot after installing the package?
[12:52] <pmcgowan> sil2100, ahh, forgot about tht other bug
[12:52] <pmcgowan> once sec
[12:52] <pmcgowan> yep its there
[12:52] <Mirv> pmcgowan: it gets fixed only to the state it was at #157
[12:52] <pmcgowan> yeah
[12:52] <sil2100> At least it's usable now
[12:52] <pmcgowan> so works
[12:53] <Mirv> bug #1338956 is that other problem
[12:53] <sil2100> We need to make sure now nothing else is b0rken, but so far things look good
[12:55] <josepht> jgdx: let me try re-running that job, we had to restart jenkins yesterday as well as genie the jenkins-slave this job ran on.
[12:56] <jgdx> josepht, that's great. Thanks. My sbuild is broken locally for uss, probably not related though.
[12:56] <rsalveti> Saviq: any other info?
[12:56] <Saviq> rsalveti, don't think so, you get that on first flo boot after flashing? wiped?
[12:57] <tvoss> rsalveti, silo 4 fixes the issue for me. Could you give it a spin?
[12:57] <tvoss> dednick, ^
[12:58] <sil2100> \o/
[12:58] <tvoss> sil2100, ^
[12:58] <sil2100> Then there's a possibility that we won't have to rely on any workarounds/hot-fixes if we'll be able to get both landed
[12:58] <rsalveti> tvoss: did you also revert your location-service changes on that silo?
[12:58] <dednick> tvoss: woop
[12:59] <tvoss> sil2100, silo 4 actually reverts the location service hotfix
[12:59] <tvoss> rsalveti, yup
[12:59] <rsalveti> Saviq: yes, bootstrap on flo, first boot
[12:59] <rsalveti> tvoss: sure
[12:59] <sil2100> It makes me smile then
[12:59] <tvoss> sil2100, please give it a spin, too
[12:59]  * Mirv is foreseeing a promotion today
[12:59] <popey> uhoh
[12:59] <sil2100> tvoss: will do!
[12:59] <rsalveti> tvoss: missing qtmir-gles in there
[12:59] <Mirv> ...and then popey found a Bug? ;)
[13:00] <tvoss> rsalveti, yup, taking care of that now
[13:00] <rsalveti> great
[13:00] <popey> heh
[13:00] <sil2100> popey: NO
[13:00]  * popey puts the phone down
[13:00] <sil2100> We say NO to bugs
[13:00] <sil2100> Bad popey!
[13:03] <Saviq> rsalveti, really weird, as the dash should only start after unity8 started, so it should've set up the environment properly ;/
[13:04] <tvoss> Saviq, greyback|lunch https://code.launchpad.net/~thomas-voss/qtmir/sync-20140808/+merge/230103
[13:04]  * Mirv tries to guess the magic order/way of building the silo with twin package
[13:04] <tvoss> Mirv, first with ignore twin packages, grab version, propose mp, take mp and add to silo
[13:05] <tvoss> sil2100, could you reconfigure 4, please?
[13:05] <Mirv> tvoss: sounds like I'm guessing ok, but I also pre-guessed the version and proposed MP, I'll just do the build after this ignore twin packges single package build finishes. thanks!
[13:05] <sil2100> tvoss: sure
[13:05] <tvoss> sil2100, thanks
[13:07] <sil2100> Done
[13:07] <Saviq> Mirv, yup, pre-guessing version works, too ;)
[13:07] <Saviq> tvoss, ACK
[13:08] <tvoss> Saviq, just need to rebuild the gles twin, correct?
[13:08] <Saviq> tvoss, yup, you don't want to rebuild non-gles as it would get a different version again
[13:08] <tvoss> Saviq, yup
[13:09] <tvoss> sil2100, rsalveti building
[13:14] <sil2100> tvoss: installed your silo as well, now I will perform some tests on it to see if all is ok
[13:15] <sil2100> And I guess we'll land both silos (4 and 15)
[13:16] <brendand> sil2100, i think there's a functional bug in gallery app caught by the autopilot tests
[13:16] <brendand> sil2100, basically you can see the shell from behind the image
[13:16] <sil2100> brendand: is it something serious? What do you mean it can be seen?
[13:16] <brendand> sil2100, not sure if the corresponding AP test actually fails, i need to look closer
[13:16] <brendand> sil2100, more details soon
[13:17] <brendand> sil2100, just a heads up that it could be a promotion blocker
[13:17] <sil2100> brendand: ok, give me a sign as well if it's serious or not, since small visual glitches shouldn't block us from promoting
[13:17] <brendand> sil2100, well okay
[13:23] <alecu> hi trainguards! may I ask you what's needed for silo-008?
[13:24] <sil2100> alecu: hi! It seems Robert wasn't able to review the changes for that, so now I'll publish it once we build a new image - so in around 1-2 hours
[13:24] <alecu> great, thanks!
[13:26] <rsalveti> sil2100: we need QA to sign silo 4
[13:28] <sil2100> rsalveti: theoretically we do not need to, but on the other hand it would be good to double-check nothing is broken
[13:28] <sil2100> brendand: can you install silo 4?
[13:28] <rsalveti> sil2100: the reason for QA is that we're now finally using trust-store for camera
[13:28] <rsalveti> sil2100: so while this is fixing a bug, it's also adding a feature
[13:29] <rsalveti> that was supposed to be validated before, but which wasn't
[13:29] <rsalveti> and that's how we got the bug in first place :-)
[13:29] <sil2100> Right ;) So in theory it was supposed to be already QA signed-off
[13:29] <sil2100> Anyway, +1 on that in overall
[13:29] <brendand> sil2100, yes!
[13:29] <sil2100> brendand: are you busy now? We would need this really since we want to land it ASAP ;)
[13:30] <brendand> sil2100, om26er is around now as well, but i can certainly give a second pair of eyes
[13:30] <sil2100> om26er: pong!
[13:30] <brendand> sil2100, it fixes the camera issue?
[13:31] <sil2100> brendand: yes
[13:31] <om26er> sil2100, don't you mean ping ?
[13:31] <om26er> ;)
[13:31] <sil2100> om26er: ;)
[13:31] <brendand> sil2100, i'm on it
[13:32] <sil2100> om26er: ok, so brendand is doing the sign-off of silo 4 already, so I guess 2 people on one silo might be a bit too much
[13:32] <Mirv> sil2100: landing-015 just finished the qtubuntu part, should QA be testing that too at the same time?
[13:33] <sil2100> Mirv: not sure if QA needs to test that, would be enough if the lander tests it
[13:33] <sil2100> Mirv: as it's an isolated bugfix for a blocker
[13:34] <rsalveti> brendand: so please test camera-app and osmtouch
[13:36] <Mirv> sil2100: ok, if you think so. I was just thinking that any QPA plugin changes may not be as isolated as one would initially think.
[13:41] <brendand> rsalveti, with camera app the dialog appears
[13:42] <rsalveti> great
[13:42] <brendand> rsalveti, interesting that the ap tests can pass with that there
[13:46] <Saviq> retoad, hey, psivaa directed me at you with some weird behaviour of http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/ and http://s-jenkins.ubuntu-ci:8080/job/ubuntu-settings-components-qmltests-utopic/
[13:47] <rsalveti> brendand: even before accepting it on the first time?
[13:47] <Saviq> retoad, after a restart (?) yesterday, the jobs started timing out (3h for unity, 1h for u-s-c), when normal run takes under an hour for unity, and much less for u-s-c
[13:47] <retoad> Saviq, /me looks
[13:47] <brendand> rsalveti, you ran them right?
[13:47] <Saviq> retoad, the jobs get stuck on generating coverage info
[13:47] <rsalveti> brendand: autopilot? not yet
[13:47]  * Mirv lets device run UITK+U8+calendar AP:s with updated qtubuntu
[13:47] <rsalveti> but I'd imagine that this might break autopilot tests for camera
[13:47] <Saviq> retoad, like this one is currently stuck there http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/826/console
[13:48]  * sil2100 runs calendar app with both silos enabled
[13:48] <sil2100> (the AP tests)
[13:48] <brendand> rsalveti, i thought tvoss solution was to whitelist camera-app so no dialog is needed?
[13:48] <rsalveti> brendand: silo 4 is the real fix, no whitelist
[13:48] <brendand> rsalveti, or is a dialog still needed even with whitelisting?
[13:49] <rsalveti> that's why you got a dialog during first time
[13:49] <sil2100> brendand: yeah, it's a full fix now, so the dialog is now visible again
[13:49] <retoad> Saviq, ack, will poke to see if I can find anything
[13:49] <rsalveti> just wonder if the dialog could break autopilot on our CI
[13:49] <Saviq> retoad, thanks
[13:50] <brendand> sil2100, hey wait a minute - camera_app passed this morning ???
[13:50] <brendand> sil2100, weird
[13:50] <sil2100> brendand: yes, as it had the whitelisting hot-fix in it
[13:50] <sil2100> brendand: silo 4 removes that hot-fix and fixes the issue the right way
[13:51] <brendand> sil2100, i'm going to check it now but i don't think that will work with autopilot
[13:51] <brendand> sil2100, and is the 'right' fix really to always have a dialog asking for location?
[13:51] <cjwatson> Initial RTM copies all done; the derived distros publisher is going to be a bit busy for a while
[13:52] <sil2100> brendand: shouldn't it only show it once and then remember? It's not like that?
[13:52] <brendand> sil2100, i didn't get that far
[13:52] <brendand> sil2100, still the AP tests will probably be broken by it
[13:52] <brendand> sil2100, so they might need to be updated to dismiss the dialog
[13:53] <sil2100> I hope the lander ran the camera-app tests ;)
[13:54] <tvoss> brendand, the user's answer is remembered
[13:55] <rsalveti> cjwatson: nice
[13:55] <rsalveti> tvoss: but what will happen with the autopilot tests during first run?
[13:55] <tvoss> rsalveti, we will either have to set an env variable to force a testing mode, or preseed the trust database
[13:55] <sil2100> We need to poke jhodapp most probably
[13:56] <jhodapp> sil2100, what's up?
[13:57] <brendand> sil2100, should we land this when it's going to re-break the autopilot tests?
[13:57] <brendand> sil2100, although i haven't *confirmed* that it does
[13:57] <rsalveti> tvoss: right
[13:57] <Mirv> sil2100: silo 015 ready for landing build wise. note that I need to shift to EODish mode now, but I'll be checking in.
[13:58] <Mirv> greyback: ^ silo 15 is ready with your branch
[13:58] <tvoss> rsalveti, but right now, the ap tests don't check for location anyway, and the camera will eventually start (the dialog times out)
[13:58] <rsalveti> cool, let's try and hope for the best
[13:58] <tvoss> rsalveti, there is a crash of the trust-stored-skeleton under ap that I'm investigating, too
[13:59] <rsalveti> tvoss: oh, ok, would that block the landing?
[13:59] <tvoss> rsalveti, TRUST_STORE_PERMISSION_MANAGER_IS_RUNNING_UNDER_TESTING is your friend
[13:59] <tvoss> rsalveti, nope, the ap tests pass all fine
[13:59] <tvoss> brendand, TRUST_STORE_PERMISSION_MANAGER_IS_RUNNING_UNDER_TESTING
[13:59] <greyback> Mirv: thanks. dandrader wants me to change the code, so I'll need a rebuild shortly
[13:59] <rsalveti> great
[13:59] <tvoss> rsalveti, set it to 1
[13:59] <Mirv> greyback: ok.
[14:00] <kalikiana> josepht: can you help rsalveti and I here; getting a strange failure at https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/3207/console where it says "E: Unable to locate package ubuntu-push-notifications-autopilot" the package was intentionally removed from the build and won't exist, but it keeps looking for it for some reason
[14:00]  * brendand hands tvoss the 'longest environment variable name ever award'
[14:00] <rsalveti> lol
[14:00] <sil2100> brendand, tvoss: so, the camera-app tests should normally pass? Is this variable set during our smoketesting?
[14:00] <brendand> sil2100, i don't think so
[14:00] <brendand> sil2100, someone probably has to update camera-app
[14:01]  * Mirv pre-bumped the gles branch version number so that it's suitable for rebuild
[14:01] <sil2100> greyback: code change? :<
[14:01] <greyback> sil2100: just cleaning up, nothing major
[14:01] <sil2100> Still, we'll have to re-test it
[14:01] <brendand> sil2100, ah tvoss just mentiond the dialog times out
[14:02] <brendand> sil2100, that would be okay then
[14:02] <greyback> sil2100: prefer I hold off?
[14:02] <greyback> and do it later?
[14:02] <brendand> sil2100, the problem before was that the window was disappearing
[14:02] <brendand> sil2100, so this should be ok
[14:02] <josepht> kalikiana: looking
[14:02] <sil2100> greyback: how long would the refactor and rebuild take?
[14:03] <greyback> sil2100: refactor done, I just need to push.
[14:03] <kalikiana> josepht: thx
[14:03] <sil2100> greyback: ok, then let's do it
[14:03] <greyback> sil2100: ok, pushing
[14:03] <brendand> tvoss, when are you planning the fix the fact that the dialog uses the click package name
[14:03] <brendand> ?
[14:03] <sil2100> greyback: once we rebuild the package I'll re-run calendar-app tests
[14:03] <greyback> sil2100: ack
[14:03] <sil2100> We need to have this silo tested ASAP
[14:04] <brendand> sil2100, silo 4?
[14:04] <Kaleo> sil2100, the calendar thing was the last thing holding us back in TRAINCON?
[14:04] <sil2100> brendand: silo 4 is being tested by you, I'm talking about silo 15
[14:05] <brendand> sil2100, who's handling silo 15?
[14:05] <sil2100> brendand: the lander, but I'm helping out as well
[14:05] <sil2100> brendand: e.g. greyback
[14:05] <brendand> sil2100, what about from the QA side?
[14:05] <sil2100> brendand: theoretically we don't need a QA sign-off for that
[14:05] <brendand> sil2100, ok
[14:06] <sil2100> But most probably it would be simply faster if someone from QA could help in testing this silo
[14:06] <sil2100> om26er: are you busy right now?
[14:06] <brendand> sil2100, as soon as these camera tests finish i'll do it - or get om26er on it
[14:06] <sil2100> brendand: anyway, we need to wait for the silo 15 to rebuild now anyway
[14:07] <om26er> sil2100, not really.
[14:07] <sil2100> greyback: did you press rebuild already, or can I do it?
[14:07] <greyback> sil2100: I didn't, please do
[14:08] <sil2100> om26er: so, once silo 15 rebuilds we would appreciate help in testing it
[14:08] <kalikiana> josepht: any ideas? basically we don't want ap for this package, only unit tests - we may add them later but not for the moment
[14:08] <josepht> kalikiana: that packages was passed as a parameter to the build job, I can re-run without that package if you'd like
[14:08] <om26er> sil2100, ok
[14:08] <kalikiana> josepht: if you can remove the parameter, that'd be great!
[14:20] <greyback> sil2100: the MR was approved, so we hould be good to go
[14:21] <sil2100> Great, waiting for the builds to finish
[14:26] <brendand> tvoss, sorry - even though there is a timeout it still prevents AP tests from passing
[14:26] <brendand> tvoss, rsalveti - someone will have to fix the AP tests
[14:26] <brendand> tvoss, let me try that env variable. what was it again :) ?
[14:27] <rsalveti> brendand: who can work on that?
[14:27] <rsalveti> probably setting up the env var for now
[14:28] <brendand> yeah just setting the env variable works. should be an easy fix. somebody just has to do it
[14:28] <brendand> i *suppose* i could :)
[14:28] <popey> hm, screen never goes off, on my flo
[14:28] <rsalveti> brendand: that would be even better
[14:28] <rsalveti> popey: nice
[14:29] <popey> rsalveti: wanna bug filed?
[14:29] <rsalveti> probably an issue with unity8 + system-compositor
[14:29] <Wellark> still on TRAINCON-0 ?
[14:29] <Wellark> silo 1 has to wait then
[14:29] <rsalveti> popey: can you run powerd-cli list?
[14:29] <rsalveti> Wellark: unfortunately, yes
[14:30]  * Wellark checks the remaining blockers..
[14:30] <popey> rsalveti:   Name: com.canonical.Unity.Screen, Owner: :1.19, State: 1
[14:30] <rsalveti> Wellark: unless you require QA to signs it off for you
[14:30] <rsalveti> popey: right, then the issue is that for some reason system-compositor + unity8 is not timing out
[14:30] <popey> rsalveti: bug against unity8?
[14:30] <rsalveti> popey: yeah, and system-compositor
[14:31] <popey> kk
[14:32] <Wellark> rsalveti: the fixes in silo 1 are minor. no need waste QA power to it at this point
[14:32] <rsalveti> popey: thanks
[14:32] <rsalveti> Wellark: got it
[14:32] <Wellark> I'm sure they have more important stuff to sign off atm
[14:33] <popey> np
[14:34] <brendand> rsalveti, the hardest part is using this environment variable without causing a pep8 error :)
[14:34] <josepht> kalikiana: building now
[14:34] <rsalveti> brendand: right
[14:34] <brendand> rsalveti, otherwise - MP imminent
[14:36] <sil2100> om26er: hi!
[14:36] <sil2100> om26er: could you test the packages in silo 15?
[14:36] <om26er> sil2100, hello
[14:36] <sil2100> om26er: they're built now
[14:36] <om26er> sil2100, no test plan ?
[14:36] <sil2100> om26er: I'll be now building the -gles counterparts, but those are unrelated to what needs testing on the phone
[14:36] <om26er> sil2100, did anyone else test it ? like the developers ?
[14:37] <sil2100> om26er: the developers, me and Mirv did some basic testing, but not sure about any official test plan
[14:37] <sil2100> greyback: do you have a test plan for qtubuntu?
[14:38] <sil2100> (like, written somewhere?)
[14:38] <greyback> sil2100: I'm not aware of one.
[14:38] <om26er> sil2100, who is the owner of the project ?
[14:39] <sil2100> om26er: it should be greyback and ricmm in overall
[14:40] <om26er> sil2100, without the testplan I can only test the bug fix. Who is going to take the blame if things break ;-)
[14:40] <kalikiana> josepht: awesome! thanks a lot
[14:40] <sil2100> I was sure we had a test plan for this
[14:40]  * sil2100 looks for it
[14:42] <sil2100> om26er: ok, I see it never had any test plan, just 'exploratory testing'
[14:43] <sil2100> A bit worrying for a component that touches so many things
[14:44] <greyback> om26er: I can tell you the biggest risk is the input handing change, so please make sure that what you tap actually reacts, and not the thing above/below it
[14:44] <greyback> om26er: also make sure the application is filling the screen correctly
[14:46] <om26er> greyback, ok, But I think we should have a testplan for this to test most basic and important things and reliabilities.
[14:46] <greyback> om26er: I'm not objecting to that. We just haven't written one
[14:47] <brendand> rsalveti, providing this gets landed before, silo004 has my ack: https://code.launchpad.net/~brendan-donegan/camera-app/longest_variable_name_evar_fixes_autopilot_tests/+merge/230122
[14:47] <brendand> rsalveti, do i need to update the spreadsheet?
[14:47] <kenvandine> are there jenkins problems right now?  All the settings CI jobs are failing, with build time outs
[14:48] <rsalveti> brendand: can we put this in the same silo?
[14:48] <brendand> rsalveti, i guess so. i thought click apps were pulled from the store though
[14:48] <sil2100> rsalveti, brendand: is camera-app still released through the train? It's a click package now, right?
[14:48] <rsalveti> brendand: indeed
[14:49] <rsalveti> who can approve/merge and upload that then?
[14:49] <brendand> rsalveti, try Kaleo
[14:49] <sil2100> rsalveti: wait
[14:49] <sil2100> rsalveti, brendand: add it to the silo
[14:50] <sil2100> rsalveti, brendand: I see Bill and oSoMoN still release the debs before pushing it to the store
[14:50] <rsalveti> oh, indeed
[14:50] <rsalveti> then add to the silo
[14:50] <sil2100> So we should use the train not to break their workflow
[14:50] <sil2100> brendand: is the branch ready for releasing? I'll add it if it is
[14:51] <brendand> sil2100, someone needs to review and approve my branch
[14:53] <tvoss> rsalveti, brendand anything I can help with?
[14:53] <brendand> tvoss, review a camera-app branch?
[14:54] <tvoss> brendand, shoot
[14:54] <brendand> https://code.launchpad.net/~brendan-donegan/camera-app/longest_variable_name_evar_fixes_autopilot_tests/+merge/230122
[14:55] <tvoss> brendand, mind filing a bug to remove that "hack" with preseeding the database?
[14:55] <brendand> tvoss, ? you mean in the test - or in camera-app - or another component
[14:56] <tvoss> brendand,  in the test
[14:56] <tvoss> brendand, but already approved your branch
[14:56] <brendand> tvoss, why not let's do that now? show me the code
[14:56] <tvoss> brendand, no code, yet. Have to think throught it, first
[14:56] <brendand> tvoss, ok
[14:56] <plars> sil2100: I'm not going to be able to make the meeting in an hour, anything urgent for me?
[14:57] <tvoss> brendand, it's on my plate anyway, so feel free to file a bug or not
[14:57] <brendand> tvoss, i'll file a bug then
[14:57] <tvoss> brendand, thanks
[14:57] <sil2100> plars: I think we're fine, we'll kick a new image in like an hour probably anyway...
[14:58] <plars> sil2100: from our end, balloons was able to get the reminders tests working, so I ran those against the latest image, 18 new passes :)
[14:58] <retoad> Saviq, I wasn't able to find anything in the last build and it timed out before I could finish poking around. The VM reset itself and another job kicked off so I am tracking through that one now.
[14:58] <sil2100> plars: passes! I like the sound of that ;)
[14:58] <Saviq> retoad, ok thanks
[14:58] <plars> sil2100: I can make them fail if you like
[14:58] <sil2100> plars: those run as autopkgtests?
[14:58] <Saviq> retoad, it's kind-of weird as it started happening just after jenkins was stopped
[14:58] <plars> sil2100: no
[14:59] <sil2100> plars: oh oooh noooo!
[14:59] <Saviq> retoad, the jobs before were completing fine
[14:59] <kenvandine> retoad, are there jenkins issues?  all my system-settings CI builds are tailing with timeouts
[14:59] <plars> sil2100: the autopkgtest stuff still doesn't work. We'll need to spend some more time on that
[14:59] <kenvandine> Build timed out (after 120 minutes). Marking the build as failed.
[14:59] <kenvandine> java.lang.InterruptedException
[14:59] <kenvandine> retoad, is that related to what you were talking about?
[14:59] <retoad> Saviq, it is indeed weird.
[15:00] <brendand> tvoss, https://bugs.launchpad.net/camera-app/+bug/1354491
[15:00] <sil2100> plars: ok, then it seems balloons liked the idea of working-around it by adding dependencies through the testconfig? ;)
[15:00] <retoad> kenvandine, I have no idea what the issue is at the moment.
[15:00] <balloons> sil2100, indeed.. the autopkgtest route was being more painful
[15:00] <kenvandine> retoad, but there is an issue?  it's not specific to my stuff right?
[15:00] <balloons> we still need to finish it, but for now reminders needed to get running
[15:01] <retoad> kenvandine, yes there does appear to be an issue.
[15:01] <kenvandine> ok, i'll stop spinning my wheels then and let the experts figure it out :)
[15:01] <kenvandine> retoad, thanks!
[15:05] <balloons> plars, I see those tests were skipped, that explains the quick runtimes. Need to push a new version of reminders to the store which should let all those run
[15:05] <balloons> store is slightly old
[15:08] <Kaleo> I don't see any update on https://bugs.launchpad.net/camera-app/+bug/1353956 (nor on https://bugs.launchpad.net/qtmir/+bug/1352977), I trust it's being worked on though?
[15:08] <sil2100> Kaleo: it's being tested by QA right now
[15:09] <Kaleo> sil2100, cool
[15:09] <sil2100> Kaleo: actually, it has been tested more or less, with an additional fix finishing right now
[15:09] <Kaleo> sil2100, great
[15:09] <sil2100> greyback: btw. could you top-approve the qtmir branch from dednick ?
[15:09] <Kaleo> sil2100, so that was the last blocker to exiting TRAINCON?
[15:09] <brendand> rsalveti, should i expect osmtouch to get the location eventually?
[15:09] <sil2100> Kaleo: there's the date-time picker that's also tested right now
[15:09] <Kaleo> yes
[15:10] <brendand> rsalveti, it's not working atm is it?
[15:10] <greyback> sil2100: done
[15:10] <sil2100> greyback: thanks :)
[15:12] <dednick> sil2100, greyback: need the unity8 branch MR'd as well.
[15:13] <sil2100> Indeed
[15:14] <greyback> dednick: have people functional tested it from the silo?
[15:14] <sil2100> The packages are built already, so once someone approves the merge and we get a +1 from brendand
[15:14] <greyback> dednick: I'm reviewing it now code-wise anyway
[15:15] <dednick> greyback: yeah. tvoss has tested against the bug.
[15:15]  * sil2100 thinks some things are happening a bit out-of-order
[15:15] <sil2100> Usually I prefer when the merge is already approved before we test the silo and sign it off ;)
[15:16] <brendand> sil2100, +1 from me - do i need to put that in the spreadsheet?
[15:16] <sil2100> \o/ Yeah
[15:16] <Mirv> \o/
[15:18] <om26er> sil2100, can you change the status of 'testing pass' to yes
[15:18] <ogra_> so where is the image !
[15:18] <om26er> sil2100, I will then approve it. seems to work fine for me.
[15:18] <sil2100> om26er: \o/
[15:18] <sil2100> om26er: done
[15:18] <sil2100> om26er, brendand: thanks guys!
[15:21] <greyback> woo!
[15:22] <sil2100> greyback: so, how's the review? ;)
[15:22] <greyback> om26er: sil2100: brendand thank you for your help
[15:22] <greyback> sil2100: I'll need time, it's not a small change
[15:22]  * greyback feels like the bottleneck
[15:22] <sil2100> om26er: switch qa-sign-off to yes once you have a moment ;)
[15:23] <om26er> sil2100, yes in a few, testing one last thing.
[15:30] <sil2100> \o/
[15:30] <sil2100> PUBLISHING!
[15:32] <popey> ʘ‿ಠ
[15:32] <sil2100> Now just the review from greyback, no pressure o/
[15:32] <greyback> :P
[15:37] <greyback> sil2100: if dednick's stuff has been functional reviewed by someone else, I'm happy to approve that MR
[15:37] <rsalveti> oh
[15:38] <rsalveti> brendand: yeah, that bad behavior is known :-)
[15:38] <rsalveti> sorry, was on a call
[15:38] <sil2100> greyback: I think tvoss did a functional review ;)
[15:38] <greyback> sil2100: very well, marking approved
[15:38] <rsalveti> getting closer to a promotable image
[15:41] <sil2100> greyback, tvoss, dednick: thanks guys for all the hard work, silo 4 is now landing as well
[15:42] <sil2100> Once those migrate, and it will take a while, we'll have an image kicked
[15:42] <pmcgowan> yay
[15:42] <greyback> cool
[15:42] <sil2100> I would still consider promoting an image today, so when the image gets built we'll ask ToyKeeper or om26er|dinner to perform promotion dogfooding
[15:43] <rsalveti> yeah
[15:46] <retoad> Saviq, how long does the coverage generation usually take? In the current job I am monitoring http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/828/console it has gotten to that point. I see the process on the slave node and the empty file that is created for the output but nothing ever makes it into the file. At this point it looks like it has nothing to do with the jenkins server but something to do with gcov
[15:46] <retoad> r (which is the same issue we're seeing on other slave nodes; gcovr hanging forever).
[15:46] <Saviq> retoad, it should be seconds
[15:46] <Saviq> retoad, so it does indeed suggest gcovr is b0rked
[15:46] <Saviq> retoad, let me try around her
[15:46] <retoad> Saviq, I will try running ti by hand to see what it spits out
[15:52] <retoad> Saviq, the command works whe run from the CLI (not tested within the chroot environment though).
[15:59] <retoad> Saviq, doesn't seem to be that gcovr is borked. Works well when called directory from the CLI. Also works when called through cmake (as the job does) when using a .cmake file that includes the full system path (again, not chrooted) to the build.
[16:01] <camako> josepht, we still in TRAINCON-0? (Sorry, was travelling, and trying to catch up on email).
[16:02] <ogra_> yes
[16:02] <ogra_> travel more ... then we'll be out
[16:02] <Saviq> retoad, wonder what is causing it to hang in jenkins then... lack of tty or something?
[16:02] <retoad> Saviq, no idea atm, am running same tests in chrooted environment now
[16:17] <retoad> Saviq, and it appears that gcovr hangs when being run from within the chrooted environment. Digging deeper the version of gcovr being run within the chrooted environment (v3.1)  is different that what is installed on the host system (v2.4 r2774) so it is possible that gcovr is b0rked.
[16:17] <popey> balloons: might need you a bit later to upload camera-app as sil2100 has some fixes landing
[16:17] <balloons> sure, just ping
[16:18] <popey> ta
[16:20] <plars> balloons: ah, ok. Why would they show up as passed then?
[16:20] <elopio> ok, we have screenshots of the makos!
[16:20] <plars> elopio: nice!
[16:20] <elopio> it's still a little hard to see them, but I'm seeing one.
[16:23] <balloons> plars, the dashboard showed everything correctly. Anyway, we pushed the updated version, so the next run will reflect everything
[16:23] <plars> balloons: ok, great
[16:25] <om26er> sil2100, which image needs testing
[16:25] <Saviq> sil2100, ugh, what's that https://ci-train.ubuntu.com/job/landing-011-1-build/150/console ?
[16:26] <sil2100> om26er: none yet ;) But 179 will need testing once it's built!
[16:27] <sil2100> Saviq: it means that someone released something to distro and didn't merge it into trunk yet
[16:27] <Saviq> sil2100, huhuh
[16:27] <sil2100> Saviq: ah
[16:27] <sil2100> Saviq: we're releasing unity8 right now
[16:27] <Saviq> sil2100, ah that thing, need to wait for it to migrate then
[16:27] <sil2100> Saviq: it was part of the location-service qtmir bug
[16:27] <sil2100> Yeah...
[16:28] <sil2100> Might take some moments ;/
[16:28] <Saviq> sil2100, that's ok, just didn't know what's happening
[16:46]  * sil2100 gives autopkgtests on unity8 an evil eye
[16:49] <greyback> sil2100: could we get silo2 included?
[16:52] <sil2100> greyback: where?
[16:52] <greyback> sil2100: well, could it be landed, or you prefer wait until traincon lifts?
[16:53] <sil2100> I would prefer not including anything new before we get this image
[16:53] <sil2100> \o/
[16:53] <greyback> sil2100: ok
[16:53] <sil2100> Ok, let me merge and clean this silo, wait a bit and then build a new image
[16:53] <Wellark> umm.. what is going on here...
[16:53] <Wellark> https://jenkins.qa.ubuntu.com/job/indicator-network-utopic-amd64-ci/31/console
[16:53] <sil2100> robru: if anything I'm still around so I'll kick a new image once it's possible
[16:53] <Wellark> Build timed out (after 120 minutes). Marking the build as failed.
[16:53] <robru> sil2100, ok
[16:53] <sil2100> (we need to make sure that all components are really in)
[17:03] <pmcgowan> Wellark, that may be the gcovr issue the guys have been looking into
[17:04] <infinity> robru: Did you get your ACKs sorted yesterday?  I was off and nowhere near a computer.
[17:05] <robru> infinity, no, looks like it still needs it: https://ci-train.ubuntu.com/job/landing-008-2-publish/71/artifact/packaging_changes_pay-service_2.0.0+14.10.20140807.1-0ubuntu1.diff
[17:06] <Wellark> pmcgowan: ok. yes, gcovr that gets stuck
[17:06] <Wellark> so it's a known issue
[17:06] <Wellark> and more importantly, it's not my fault
[17:06] <Wellark> ;)
[17:06] <infinity> robru: Looking.
[17:06] <robru> infinity, thanks
[17:08] <infinity> robru: Looks reasonable.
[17:08] <robru> infinity, thanks
[17:17] <sil2100> (we need to make sure that all components are really in)
[17:17] <sil2100> ugh, wrong window
[17:19] <rsalveti> sil2100: did someone upload the camera-app click to the store?
[17:19] <sil2100> balloons: could you build an upload the new camera-app?
[17:19] <sil2100> balloons: popey should still be around to review it
[17:19] <balloons> aye aye
[17:19] <sil2100> balloons: thanks!
[17:24] <robru> sil2100, looks like everything is in. are we just waiting for the new camera-app click then?
[17:24] <sil2100> robru: yes, let's wait for that for a little bit and then kick a new image
[17:24] <robru> sil2100, ok, sounds good
[17:25] <sil2100> balloons: give us a sign once it's there :)
[17:27] <popey> sil2100: i am
[17:28] <balloons> gonna be a bit on the build, things are queued
[17:29] <popey> k, no worries, I'll keep checking in
[17:47] <sil2100> Just hope it won't take much longer
[17:53] <sil2100> balloons: still building?
[18:08] <sil2100> Damn, this takes forever
[18:10] <sil2100> balloons: it looks as if we're missing free executors on http://s-jenkins.ubuntu-ci:8080/job/generic-click-builder-utopic-armhf/
[18:12] <nik90|Dinner> sil2100: you are looking to send that happy email that we are out of TRAINCON, arent you :P
[18:12] <ogra_> we all do
[18:12] <sil2100> Yes :|
[18:12] <sil2100> And things are getting in my way!
[18:12] <Wellark> sorry, could not resist: https://i.imgflip.com/ayxp5.jpg
[18:12] <Wellark> <3
[18:13] <nik90|Dinner> lol
[18:13] <Wellark> sil2100: you have our full support. just keep cool and things will work out in the end :)
[18:15] <balloons> sil2100, yes it's backed up
[18:15] <sil2100> hahah ;)
[18:16]  * nik90 imagines sil2100 as Gru with us as the minions (Despicable Me)
[18:16]  * ogra_ goes afk for a while again ... looks like this will take longer
[18:17] <sil2100> hm, ok
[18:17] <sil2100> ogra_: before you go
[18:17] <sil2100> ogra_: I'm thinking about kicking an image right now - camera-app tests will fail, but the app will work fine
[18:17] <sil2100> And we know they pass because we ran the tests ourselves even
[18:18] <sil2100> ogra_: what do you think?
[18:19] <pmcgowan> sil2100, why will they fail if you ran them ok?
[18:19] <sil2100> pmcgowan: an environment variable needs to be set, that's what the new camera-app basically does
[18:20] <sil2100> It sets a test environment variable which is required to skip one dialog at start
[18:20] <sil2100> WIthout it the tests fail, but we ran them with the branch already
[18:20] <pmcgowan> seems worth building and blessing to me
[18:20] <pmcgowan> unless its easy to add something to make them pass
[18:21] <sil2100> We just have to release the new click package, btu this seems to be stuck now
[18:21] <sil2100> And I don't see any merit in waiting just for a test fix (if we know the tests are passing currently)
[18:21] <pmcgowan> sil2100, so new camera click package has the fix bit its not available?
[18:22] <pmcgowan> why is the click stuck? sil2100
[18:22] <pmcgowan> sorry to rehash what you probably discussed
[18:22] <sil2100> pmcgowan: exactly, the camera click package that adds setting this env variable at beginning of a test is still building - seems like there are no available executors right now
[18:22] <sil2100> balloons mentioned something there's a lot of other things queued up
[18:23] <pmcgowan> damn that murphy
[18:23] <kenvandine> pmcgowan, murphy has been around all week
[18:24] <kenvandine> sil2100, if there is still that problem of gcov hanging the builds in CI, we can probably go through and kill a bunch that we know won't finish
[18:25] <kenvandine> like i think there are 4 jobs running for settings now
[18:25] <sil2100> kenvandine: could you poke some people about that?
[18:25] <kenvandine> and they just keep timing out after 2 hours
[18:25] <sil2100> plars: hi, maybe you could help us out?
[18:25] <kenvandine> i think retoad is looking into the hang
[18:25] <plars> sil2100: I'll try, what's up?
[18:25] <kenvandine> but i can kill all the settings jobs now
[18:25] <kenvandine> should free some up
[18:25] <sil2100> plars: we need a way to get  http://s-jenkins.ubuntu-ci:8080/job/camera-app-ci/251/console finishing
[18:26] <sil2100> plars: it seems that it can't do the last step because of not enough executors...
[18:27] <kenvandine> sil2100, i kill the 3 settings jobs
[18:27] <kenvandine> +ed
[18:27] <retoad> kenvandine, am looking to some degree. One problem I have found is that gcovr seems to be having problems. v3.1 just hangs and never returns results.
[18:30] <kenvandine> sil2100, i killed everything i feel comfortable killing, hopefully that will free up some and reduce the queue a bit
[18:30] <kenvandine> i know they will just hang for 2 hours
[18:30] <sil2100> kenvandine: thanks!
[18:30] <plars> sil2100: it looks like one of them is offline, but I'm not sure why. I haven't played with the claxeda pbuilders any
[18:30] <kdub> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-utopic-armhf/184/console
[18:30] <kenvandine> retoad, any idea who to talk to about gcovr?
[18:30] <plars> sil2100: let me dig at it a bit more
[18:31] <kdub> ^^is that message an out-of-space on jenkins message?
[18:31] <retoad> kenvandine, specifically no. I did mention it to Saviq earlier though
[18:31] <plars> retoad: or is this the same thing you are looking at?
[18:31] <plars> retoad: looks like you disabled the cyclops-node12 one
[18:32] <retoad> plars, I have been poking at quite a few things. cyclops-node13 was almost out of space earlier so I cleared that one up and yes, am working on node12 now.
[18:33] <retoad> plars, one thing that I have noted is that gcovr (v3.1) in the chrooted environment of all the pbuilder tests just hangs and never returns results.
[18:33] <retoad> which, in turn, leads to test failures.
[18:34] <plars> retoad: this is on the calxeda pbuilders?
[18:34] <retoad> plars, calxeda, genie, kinnara, the VMs on naartjie
[18:34] <retoad> etc ...
[18:34] <plars> sil2100: unless what retoad is talking about it will block them, it looks like it's just really busy right now
[18:34] <plars> retoad: where did the update come from?
[18:35] <retoad> plars, idk, haven't tried to dig through any of the code.
[18:35] <plars> retoad: I mean, did someone tell it to use that version, or was it just automatically pulled in because there was a new package?
[18:36] <retoad> plars, I know on the VMs v2.4 is installed on the systems but the chrooted env doesn't use the systems version
[18:36] <robru> sil2100, i have some spare cycles, anything I can do to help?
[18:36] <retoad> plars, on the calxeda nodes it isn't even installed at the system level so it must be told to install it somewhere.
[18:51] <tvoss> sil2100, around?
[18:53] <pmcgowan> he may have just left
[18:53] <pmcgowan> we were debating the merits of waiting for the camera with the test fix or just making an image
[18:53] <pmcgowan> since there seems to be builder contention
[18:54] <pmcgowan> tvoss, robru ^^
[18:54] <robru> pmcgowan, it seems like a reasonable plan to me. if we know the app is working but just the test itself will fail, why not build an image?
[18:54] <tvoss> pmcgowan, are you referring to the trust fixes?
[18:54] <pmcgowan> robru, right that was sil2100 proposal/question
[18:55] <pmcgowan> tvoss, yes
[18:55] <robru> pmcgowan, should we do it?
[18:55] <pmcgowan> right now the AP will fail but we know why and its fixed
[18:55] <pmcgowan> hey I want off of traincon
[18:56] <robru> pmcgowan, ok I'm gonna trigger it
[18:56] <pmcgowan> robru, check http://s-jenkins.ubuntu-ci:8080/job/camera-app-ci/251/console
[18:56] <pmcgowan> to see if its moving?
[18:56] <robru> pmcgowan, i'm having trouble getting on the vpn, can you pastebin that for me?
[18:57] <tvoss> pmcgowan, would we promote that image?
[18:57] <pmcgowan> robru, http://pastebin.ubuntu.com/7991081/
[18:57] <pmcgowan> still working it seems
[18:57] <pmcgowan> tvoss, yes aiui
[18:57] <robru> pmcgowan, does it seem like it'll finish soon?
[18:57] <robru> i'm not sure how long that job takes
[18:57] <kenvandine> i'd love to get off traincon-0!
[18:57] <pmcgowan> robru, I dunno where it was at earlier
[18:58] <robru> either do i
[18:58] <tvoss> pmcgowan, then we should wait for the fix. Otherwise, people using that promoted image and updating the camera app would suffer from the trust prompting issue
[18:58] <pmcgowan> tvoss, I thought the fix was only for the env var for tests?
[18:58] <tvoss> pmcgowan, oh ... not sure, I thought both landed together in one silo
[18:58] <tvoss> rsalveti, can you shed some light here
[18:58] <tvoss> ^
 pmcgowan: exactly, the camera click package that adds setting this env variable at beginning of a test is still building - seems like there are no available executors right now
 We just have to release the new click package, btu this seems to be stuck now
[18:59] <pmcgowan>  And I don't see any merit in waiting just for a test fix (if we know the tests are passing currently)
[19:00] <pmcgowan> tvoss, and I am unclear if the job will hang because of the other issue with gcovr
[19:00] <tvoss> pmcgowan, okay, then I'm +1 on building an image
[19:01] <pmcgowan> olli, rsalveti robru ok ?^^
[19:01] <robru> pmcgowan, ok, i'll do it
[19:02] <robru> tvoss, yeah, the *silo* landed, just the camera click-app isn't in the store yet
[19:03] <tvoss> robru, okay
[19:03] <pmcgowan> that job indicates its like 90% done if that progress can be trusted
[19:04] <robru> pmcgowan, ok I kicked a build. worst case, the next image built by cron (~8hrs) will have the click app.
[19:05] <robru> ToyKeeper, when you get online, image 179 should be ready for you to dogfood, it's a promotion candidate ;-)
[19:08] <sil2100> o/
[19:08] <sil2100> robru: thanks :)
[19:08] <sil2100> I'm still around, but AFKish
[19:08] <robru> sil2100, if you're AFK are you really around? if you don't respond to messages, can you even be said to really exist? ;-)
[19:09] <sil2100> I... I..!
[19:09] <imgbot> [19:10] <ToyKeeper> That explains a lot...  I was wondering how I had missed the bot's pings about it.
[19:12] <pmcgowan> robru, that job actually finished but it failed the final step
[19:13] <robru> pmcgowan, erk
[19:13] <pmcgowan> robru, it confuses me though
[19:13] <pmcgowan> seems to say it published
[19:13] <robru> ToyKeeper, oh, are you up early? I wasn't expecting you till later. maybe I'm time-confused.
[19:14] <pmcgowan> anyone can look at http://s-jenkins.ubuntu-ci:8080/job/camera-app-ci/251/console to see whats up
[19:15] <ToyKeeper> robru: I just have weird hours.
[19:16] <popey> robru: pmcgowan the next image wont have camera app unless someone (balloons) uploads it to the store and someone else (me) approves it...
[19:17] <pmcgowan> popey, hey I just work here
[19:17] <balloons> lol
[19:17] <robru> popey, yeah, the idea seems to be that the updated camera app just had AP fixes, nothing user-visible.
[19:17] <popey> ok
[19:17] <pmcgowan> but the one from the silo we need
[19:17] <balloons> popey, sil2100 camera app is STILL waiting believe it or not
[19:17] <robru> popey, so we're hoping in theory that image 179 is promotable despite camera-app AP failures.
[19:17] <pmcgowan> popey, balloons I think we may need to upload a new camera
[19:18] <popey> we cant till the click builds
[19:18] <pmcgowan> as the silo landing was the deb to the archive right?
[19:18] <balloons> we could build the click locally, that's the only other option.. or punt some jobs
[19:18] <pmcgowan> ok I dont know then if the previous one made it through
[19:18] <pmcgowan> popey, balloons if you didnt upload that means no one did?
[19:18] <robru> pmcgowan, yes the silo landing was just debs to the archive.
[19:19] <popey> nobody has yet
[19:19] <popey> last camera update in the store was 2 days back iirc
[19:19] <pmcgowan> well then
[19:19] <pmcgowan> crap
[19:20] <popey> http://s-jenkins.ubuntu-ci:8080/job/camera-app-click/ being the thing we're waiting on
[19:21] <pmcgowan> popey, what I dont know is whether the diff between 108 and 109 there is just the testing fix
[19:21] <pmcgowan> sil2100, ?^
[19:22] <pmcgowan> popey, in which case the 108 package would be good enough
[19:22] <popey> that and a couple of translations
[19:22] <popey> the store has r342
[19:23] <balloons> might free up soonish.. 4 nodes are being used by unity8 and they are in the results part
[19:24] <sil2100> We kicked an image now anyway, so the camera-app fails will be failing for this image on smoketesting
[19:24] <sil2100> But the application itself is completely fine
[19:24] <pmcgowan> sil2100, the one from the store?
[19:24] <sil2100> pmcgowan: the one that's in the store right now
[19:24] <pmcgowan> ok great
[19:25] <sil2100> pmcgowan: it's just a matter of tests being broken - broken in a known way, so no worries here
[19:25] <pmcgowan> popey, balloons seems we are good, but will want that next one loaded when its done
[19:25] <popey> k
[19:26] <sil2100> Can't wait for the image to finish building
[19:27] <popey> sil2100: we expecting to dogfood this image and hope to promote?
[19:27] <sil2100> popey: yes
[19:28] <sil2100> popey: as it has all the fixes we want (only missing the click camera-app with the AP test fix)
[19:28] <balloons> camera app is building now :-)
[19:30] <popey> is ToyKeeper lined up to dogfood?
[19:30] <sil2100> popey: she got pinged by me and robru
[19:30] <popey> k
[19:30] <sil2100> Can't wait!
[19:31] <popey> ETA 20:40 UTC ish?
[19:37] <robru> popey, i don't have a UTC clock handy, but I'd expect the image to finish building within an hour
[19:43] <ToyKeeper> I'll try to get back ASAP, anyway...  hopefully around the time the build finishes.
[19:43] <popey> robru:  date -u
[19:43] <robru> popey, what, you mean i have to open a terminal?? ;-)
[19:43] <popey> no
[19:44] <popey>  /exec -o date -u
[19:44] <popey> Fri Aug  8 19:44:04 UTC 2014
[19:44] <robru> (alternate response) popey, I'm flattered but I'm in a relationship already.
[19:44] <popey> good, it was "minus you"
[19:44] <robru> oh ok
[19:45] <robru> Fri Aug  8 19:45:04 UTC 2014
[19:45] <robru> oh look at that
[19:45] <popey> \o/
[19:45] <robru> Desktop
[19:45] <robru> Documents
[19:45] <robru> Downloads
[19:45] <robru> missed-#ubuntu-ci-eng.txt
[19:45] <robru> missed-#ubuntu-touch.txt
[19:45] <robru> Music
[19:45] <robru> pbuilder
[19:45] <robru> Pictures
[19:45] <robru> Projects
[19:45] <robru> Public
[19:45] <robru> semordnilap.py
[19:45] <robru> src
[19:45] <robru> Templates
[19:45] <robru> todo.txt
[19:45] <popey> hahah
[19:45] <popey> that was brave, could have gone badly wrong there
[19:45] <popey> .
[19:45] <popey> ..
[19:45] <popey> goat_porn
[19:46] <robru> yeah pwd would have been smarter than ls. wasn't sure what the active directory was
[19:46] <robru> popey, no the goat porn is on my other laptop, so it wasn't that brave
[19:54] <balloons> popey, https://myapps.developer.ubuntu.com/dev/click-apps/506/changerequest/
[19:54] <balloons> camera app is uploaded
[19:55] <popey> approved
[19:55] <popey> so it could sneak into this build...
[19:57] <racarr> robru: You asked about https://bugs.launchpad.net/ubuntu/+source/android/+bug/1351097 so maybe you are tasked with chasing it down? I don't know. Just wanted to let you know I've posted a patch
[19:57] <robru> racarr, oh thanks
[19:57] <robru> sil2100, still around? ^
[19:58] <alecu> hi trainguards! any ETA for landing of silo 008? (pay-service)
[19:58] <alecu> will that come after next image is built?
[19:58] <robru> alecu, yeah I can probably kick that now, we should be far enough into the build that it's safe to publish
[20:00] <alecu> great!
[20:02] <sil2100> robru: yeah, around
[20:02] <sil2100> robru: what's up?
[20:03] <robru> sil2100, racarr mentioned having a workaround for that bottom-edge-swipe-emulator issue
[20:03] <sil2100> racarr: excellent \o/
[20:03] <sil2100> racarr: thanks!
[20:03] <sil2100> As per discussions with olli we decided to whitelist this issue for this particular promotion
[20:03] <robru> racarr, can you take your pastebin and submit a branch for that?
[20:03] <sil2100> But it would stay as a blocker for the other
[20:04]  * rsalveti back
[20:05] <robru> brb, lunch
[20:06] <rsalveti> I'll check his workaround and push it if it works properly
[20:07] <rsalveti> seems we're still waiting for the new image to show up
[20:13]  * sil2100 pokes imgbot with a stick
[20:19] <racarr> sil2100: To ubuntu/android?
[20:20] <racarr> as distro patch
[20:26] <racarr> hmm
[20:26] <racarr> ubuntu/android has many less distro patches than apt-get source android
[20:28] <rsalveti> racarr: I can take care of that package patch once I'm done with my tests
[20:28] <racarr> rsalveti: Sounds good :) lemme know if there are any problems
[20:29] <rsalveti> racarr: sure
[20:29] <rsalveti> thanks
[20:33] <sil2100> racarr: yeah, best to consult with rsalveti ;)
[20:41] <sil2100> It's taking a bit longish to get this image built
[20:44] <imgbot> [20:45] <imgbot> [20:45] <robru> woop woop!
[20:45] <popey> woop woop!
[20:45] <sil2100> \o/
[20:45] <ToyKeeper> That was only 5 minutes late.
[20:45] <sil2100> ToyKeeper: can we ask you for dogfooding #179 promotion-wise?
[20:45] <ToyKeeper> sil2100: Already flashing it.
[20:45] <sil2100> ToyKeeper: thank you :)
[20:46] <ToyKeeper> Cancelled my other plans.
[20:46]  * olli crosses fingers
[20:46] <popey> awww, camera didnt make it
[20:46] <sil2100> popey: sadly
[20:46] <robru> hmmmm, is there a delay before it becomes available for krillin? usually I can flash as soon as the bot pings but just now i got 178...
[20:48] <robru> nm
[20:56] <rsalveti> robru: ping janimo
[20:56] <robru> rsalveti, nah it was just like a 1m delay, it's fine
[20:56] <rsalveti> oh, great, maybe he's already automatically importing everything
[21:07] <robru> ToyKeeper, popey: erk, uh, flashing 179 and then updating camera-app seems broken. like camera-app won't launch
[21:08] <sil2100> Impossible
[21:08] <sil2100> Blasphemy
[21:10] <ToyKeeper> Is that a blocker for the image, or just a broken app update that needs to be fixed?
[21:11] <sil2100> I don't know
[21:11] <sil2100> Depends if it's confirmed to be broken for others
[21:12] <rsalveti> we tested the silo for sure
[21:12] <sergiusens> robru: camera from click?
[21:12] <sil2100> Yes, and it shouldn't be broken as there is no logical reason for it to be broken
[21:12] <sil2100> If, of course, we didn't pull in some other changes along with the AP fix
[21:12] <sergiusens> sil2100: there is a reason for it to be broken if abi or api was broken and the click framework wasn't bumped
[21:13] <sil2100> sergiusens: it was not
[21:13] <sergiusens> then it should be good
[21:13] <sil2100> sergiusens: we didn't land anything that should have broken ABI, there were no UITK or similar uploads... all changes were purely from the backend
[21:13]  * sergiusens flashes
[21:15] <ToyKeeper> Well, "settings -> accounts -> back" still crashes and leaves the settings app unresponsive.
[21:15] <sil2100> ToyKeeper: that's a known bug, but not marked as a blocker
[21:15] <sil2100> ToyKeeper: it's on the 'visible issues' page though
[21:17] <popey> fyi camera opens with 179 _without_ updating camera from store
[21:17]  * popey updates the app
[21:19] <popey> confirmed it fails to launch after updating
[21:19] <sergiusens> popey: upstart logs for camera say anything?
[21:19] <popey> apparmor denials
[21:19] <rsalveti> did the trust-store dialog worked at least?
[21:19] <popey> [Fri Aug  8 22:16:56 2014] type=1400 audit(1407532617.491:129): apparmor="DENIED" operation="open" profile="com.ubuntu.camera_camera_<IP_ADDRESS>2" name="/dev/fb0" pid=4707 comm="camera-app" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=0
[21:19] <rsalveti> downloading and will test
[21:20] <sergiusens> ugh
[21:20] <sil2100> wtf
[21:20] <rsalveti> this is expected
[21:20] <rsalveti> known and always was there
[21:20] <sil2100> Ah, k
[21:20] <sergiusens> check ~/.cache/upstart/*camera*.log
[21:21] <popey> there isnt one
[21:21] <popey> com.ubuntu.camera	<IP_ADDRESS>7
[21:21] <popey> thats the version I have, and the only camera app log is for r342
[21:22]  * popey reboots phone
[21:22] <cjwatson> Setting up proposed-migration for ubuntu-rtm/14.09 now so that I can get a new ubuntu-keyring in so that I can build images
[21:22] <cjwatson> I've flushed out all the old data from the dogfood run
[21:24] <popey> works after a reboot ToyKeeper
[21:24] <sergiusens> UbuntuClientIntegration: connection to Mir server failed. Check that a Mir server is
[21:24] <sergiusens> running, and the correct socket is being used and is accessible. The shell may have
[21:24] <sergiusens> rejected the incoming connection, so check its log file
[21:24] <sergiusens> that's why
[21:24] <ToyKeeper> popey: Thanks.  Usually one of the first things I do is disable updates, so it won't change versions on me mid-test.
[21:25] <sergiusens> rsalveti: try and updating the camera before launching it for the first time
[21:25] <sil2100> popey, sergiusens: thanks for checking this out
[21:25] <sergiusens> rsalveti: if you haven't finished flashing yet
[21:25] <rsalveti> still flashing
[21:25] <rsalveti> so this updating issue might be different
[21:26] <sergiusens> does the trust store cache the state of the decision and bind it to a full app_id?
[21:26] <sergiusens> rsalveti: I bet it's a state issue
[21:26] <rsalveti> could be, question and bug for tvoss
[21:26] <sergiusens> so any app that is updated will fall into this potential problem
[21:26] <sergiusens> which uses this code path of course
[21:27] <sergiusens> which is not "all" apps
[21:27] <sil2100> When landing the trust-store update recently we didn't test how it reacts to app updates, so yeah...
[21:27] <ToyKeeper> Well, that's an issue...  after merging a couple calls and then hanging up, one of the callers was still active on the other side.
[21:27] <robru> sergiusens, yeah, updating the camera app from the click store stops it being able to launch. i'll reflash to confirm...
[21:28] <sergiusens> robru: well if you reboot it works; it should only fail if you launched the previous one and accepted the access in the pompt
[21:28] <sergiusens> theory still though
[21:29] <robru> sergiusens, wasn't prompted for anything
[21:29] <rsalveti> yeah, reverting was definitely the best option here
[21:29] <sergiusens> robru: not even the first time?
[21:29] <robru> sergiusens, nope
[21:29] <rsalveti> so many issues with this landing
[21:29] <sergiusens> robru: that's strange too
[21:32] <sil2100> Indeed... the scary thing was that it was signed off by QA, so even this doesn't completely protect us from issues
[21:32] <sil2100> robru: anyway, it was confirmed that a reboot helps
[21:39] <robru> sergiusens, sil2100: yeah, reflashing 179, the camera-app that comes with it prompts for location access and works.
[21:41] <ogra_> sil2100, the camera smoke test doesnt look so great either
[21:41] <ogra_> (i assume that is because there is no test handling of the promot ? )
[21:41] <ToyKeeper> Well, it still produces black images with the flash...
[21:42] <sil2100> ogra_: that's known
[21:42] <sil2100> ogra_: see backlog, but in short: the fix for this is in the store
[21:42] <ogra_> right
[21:42] <sil2100> ogra_: we didn't want to block the image build on the click package taking ages building
[21:43] <ogra_> yep, i see the backliog
[21:51] <rsalveti> flashed, updated, can't open app
[21:51] <rsalveti> even without trying it before
[21:52] <rsalveti> lemme reboot
[21:52] <ToyKeeper> Okay, had a couple issues I couldn't reproduce more than once...  the "settings -> reset" option took a few taps to launch, and before that it just toggled the button on and off at each tap.  Even stayed depressed when I went to another setting group and back.
[21:53] <ToyKeeper> The other was that hanging up on a merged call left one line open (on the other end only, no audio transfer, no sign of an ongoing call on the UT phone).
[21:54] <ToyKeeper> Settings -> Accounts -> Back still crashes and leaves the settings app unresponsive...  known long-standing issue.
[21:54] <ToyKeeper> I was asked twice to allow location access when going to google maps...  and the second one was shown as "an unconfined application".
[21:55] <ToyKeeper> And the app store still forgets what to display when the user changes views and back mid-install.  It shows "Install" instead of the install status.
[21:55] <ToyKeeper> However, the location indicators no longer uncheck themselves, and the music app can finally accept parameters from the dash again.
[21:56] <rsalveti> "an unconfined application" is unfortunately expected
[21:56] <rsalveti> so is the click name in camera-app
[21:56] <rsalveti> instead of the app name
[21:57] <ToyKeeper> The date/time picker in the calendar still doesn't work.
[21:58] <rsalveti> yeah, so no promotion still
[21:58] <ToyKeeper> That was the only current blocker I noticed.
[21:58] <ToyKeeper> We can't promote with that?  :(
[21:58] <rsalveti> well, not my call
[21:59] <rsalveti> sil2100: robru: ^
[21:59] <sil2100> ToyKeeper: huh?
[21:59] <sil2100> ToyKeeper: why?
[21:59] <sil2100> ToyKeeper: we tested, 3 people tested it and it worked
[21:59] <ToyKeeper> The last I heard was:
[21:59] <ToyKeeper> ** Date & Time picker is not working on device.
[21:59] <ToyKeeper> https://bugs.launchpad.net/bugs/1351024
[21:59] <ToyKeeper>  -> Seems like the issue has been caused by the QtCompositor landing.
[21:59] <ToyKeeper> Fix might take some time sadly, we might have to consider working around
[21:59] <ToyKeeper> it in case it takes too long.
[21:59] <sil2100> ToyKeeper: did you swipe down the keyboard?
[22:00] <ToyKeeper> sil2100: Oh, I see.  It was behind the keyboard.
[22:00] <sil2100> ToyKeeper: yes, it was like this in the last promoted image as well
[22:00] <ToyKeeper> If that's considered "working", I can live with that.  :)
[22:00] <sil2100> ToyKeeper: not a regression anyway ;)
[22:00] <sil2100> ;p
[22:01] <rsalveti> so no real blocker it seems?
[22:01] <sil2100> It's certainly something we'd want to get fixed, but since it was like this already, we didn't want to block on it
[22:02] <sil2100> ToyKeeper: checked your list, mostly non-critical issues I see there
[22:02] <sil2100> ToyKeeper: does this mean a +1 from the dogfooding side :D ?
[22:02] <ToyKeeper> At least with a quick set of tests, yes.
[22:02] <ToyKeeper> I'm sure I could find a dozen more issues if I keep poking it.
[22:03] <popey> the date picker one is in progress
[22:03] <ToyKeeper> Anyway, none of yesterday's blockers seem to be present.
[22:03] <sil2100> ToyKeeper: so, are you giving us a green light on promoting this image?
[22:04] <ToyKeeper> Go for it.  Nothing seems to be exploding.  :)
[22:04] <sil2100> ToyKeeper: I feel I need to hug you!
[22:04]  * sil2100 hugs ToyKeeper
[22:05]  * ToyKeeper explodes
[22:05] <jdstrand> popey: that denial is known, harmless and just noise. the next update will silence it
[22:05] <ToyKeeper> Hmm, I seem to have a bug.
[22:05] <sil2100> Ok, I'll just check the smoketesting still-running results
[22:05]  * rsalveti off for dinner, bbl
[22:06] <sil2100> ogra_: ok, so far the smoke test results look similar to 178, so I think it's time to just promote (tm)
[22:06] <sil2100> ogra_: could you promote image #179 ?
[22:06] <ToyKeeper> Hmm, my screen hasn't shut itself off since I stopped poking it a few minutes ago.
[22:06] <rsalveti> popey: had that earlier today
[22:07] <rsalveti> https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1354473
[22:07] <popey> not seen it on mako
[22:07] <ToyKeeper> This was on mako.
[22:07]  * popey unplugs and leaves phone alone to test
[22:08] <popey> dimmed
[22:08] <ToyKeeper> It was still plugged in though.
[22:08] <popey> locked
[22:11] <ToyKeeper> Hmm, still not shutting itself off even while unplugged.
[22:15] <ToyKeeper> Seems similar to an issue I had long ago but could never trigger on purpose...  except the proximity sensor doesn't blacken the screen now.
[22:15] <ToyKeeper> Probably the same bug, just hard to nail down.
[22:15] <popey> same here
[22:15] <popey> it does when dialer app is open
[22:16] <ToyKeeper> Yeah, or when it has been open at least...  doesn't need to still be open.
[22:16] <ToyKeeper> Anyway, biab.
[22:17] <sil2100> Thanks everyone
[22:18] <sil2100> ogra_: anyway, please promote #179 at all costs
[22:18] <sil2100> I am sending out the ANN's about that now since it's late and I have an early wake up tomorrow
[22:23] <sil2100> ogra_, robru: could you guys update the topic (image promoted part) once the actual promotion happens?
[22:23] <sil2100> robru: keep poking ogra_ about promotion while I'm away ;)
[22:23] <sil2100> It's time for me to go to sleep finally
[22:23] <popey> o/
[22:23] <sil2100> Goodnight everyone, have a nice weekend o/
[22:24] <sil2100> And thanks again for your hard work \o/
[22:28] <ogra_> [22:29]  * popey hugs ogra_
[22:30] <popey> was just going to update my #157 phone and thought "wow, this feels old!"
[22:30] <ogra_> :)
[22:31] <ogra_> yeah
[22:31] <ogra_> the new design is so gret
[22:31] <ogra_> *great
[22:36] <popey> got the sdcard popup on nexus 4 after updating
[22:36] <popey> "failed to initialise storage" or something
[22:36] <popey> where should I file that?
[22:55] <olli> congrats everyone to #179 !
[23:08] <kenvandine> woot
[23:08] <kenvandine> no more traincon-0!
[23:19] <rsalveti> awesome
[23:19] <rsalveti> :-)
[23:19] <rsalveti> jhodapp: now we can land camera :-)
[23:20] <rsalveti> popey: https://launchpad.net/ubuntu/+source/ciborium


[13:07] <olorton> Hey all, I've started a new mythtv build and am having a few problems with MythNetvision - can anyone help?
[20:26] <soren> Who handles mirrors for Mythbuntu? I have a server that's been a mythbuntu mirror for.. gosh,I don't know, probably 4 years or thereabouts... and it's being shut down. How can I make sure it gets pulled out of rotation?
[20:49] <dewman> soren, I would imagine that tgm4883, or rhpot1991 or superm1 would be able to take care of it or at least get the info passed along...;Heck they might even already know about it. ;-)
[22:04] <superm1> soren, tell daviey the details and he should be able to take care of it