[00:02] <cjwatson> sergiusens: ok, that's all sorted for you now
[00:47] <sergiusens> cjwatson: thanks
[01:13]  * ToyKeeper biab, lunch
[01:24] <sergiusens> rsalveti: http://people.canonical.com/~platform/citrain_dashboard/#?q=sergiusens
[01:24] <sergiusens> robru: is that publishable? ^^
[01:25] <robru> sergiusens, does it fix anything i care about?
[01:25] <sergiusens> robru: nothing in list
[01:25] <robru> sergiusens, then I guess it needs ToyKeeper to review it & sign off.
[01:25] <sergiusens> ok
[01:26] <sergiusens> robru: it's translations mostly to enable translators
[01:26] <sergiusens> but fine I'm fine wth extra reviews
[01:26] <robru> sergiusens, ok, sounds good, but yeah, due to traincon we need ToyKeeper to review that
[01:42] <Wellark> could I have a rebuild on silo 1
[01:43] <Wellark> I think all the people with $ultimate_power have eod'ed in my team already
[01:43] <Wellark> oh, it's 5am
[01:43] <Wellark> ...
[01:43] <Wellark> tedg: around? --^
[01:44] <tedg> Wellark, Sure
[01:44] <Wellark> thanks
[01:44] <tedg> Wellark, Everything or just one package?
[01:44] <Wellark> let me check
[01:45] <Wellark> tedg: seems unity8 was build with large enough version number date
[01:45] <Wellark> tedg: indicator-network is enough
[01:46] <tedg> Wellark, Started
[01:46] <Wellark> tedg: thanks
[01:47] <Wellark> tedg: feel free to test when done ;)
[01:48] <Wellark> tedg: https://code.launchpad.net/~unity-api-team/indicator-network/modeminfo/+merge/225160
[01:49] <Wellark> those things look beautiful on a dual sim device
[02:05] <imgbot> [03:22] <ToyKeeper> Weird.  I kept checking and saw nothing...  checked again now and I see pings which didn't show up earlier.
[03:35] <sergiusens> ToyKeeper: and now you have a queue :-)
[03:40] <imgbot> [03:40] <imgbot> [03:42] <ToyKeeper> sergiusens: Any idea if it should still work on 176?
[03:43] <sergiusens> ToyKeeper: that's the new one, right? It should but since it recently built; I would say, it would as long as unity and networking work
[03:43] <kenvandine> yay... my silo is buildable!
[03:43] <ToyKeeper> ... need to get all flashed, now that 176 is out.  Kind of odd that 24 hours passed between builds.
[03:44] <sergiusens> ToyKeeper: given that it contains no moving parts and if it doesn't; them what is currently there won't either... put in other words :-)
[03:45] <sergiusens> ToyKeeper: in other words, I expect it to work on 176
[03:45]  * sergiusens feels tired and uses lots of words to answer simple questions
[03:53] <bzoltan> are  QA folks around?
[03:57] <thomi> bzoltan: what's up? I was about to EOD...
[03:58] <bzoltan> thomi:  I wonder if you know if the rev175 image has the tests fixed not to use the UbuntuShape objecttype
[03:59] <bzoltan> thomi: but maybe it is not really QA domain
[03:59] <thomi> bzoltan: I have no idea what you're talking about, sorry. ToyKeeper might know, if she's still around
[03:59] <thomi> or elopio
[03:59] <thomi> otherwise, the European contingent should start coming online soon
[03:59] <bzoltan> thomi: elopio would be the best...
[04:00] <thomi> unless he's working crazy hours, he should be asleep I guess
[04:00] <bzoltan> thomi: :) I know the  European contingent, I am one of the most easter of them :)
[04:00] <bzoltan> thomi: Mirv will join soon, he might now these details too
[04:00] <thomi> ack
[04:00] <thomi> cool, thanks - I'm off for a nap.
[04:08] <ToyKeeper> bzoltan: Sorry, I don't know the state of the AP tests.
[04:12] <bzoltan> ToyKeeper:  It might not be the solution for all failure, but when I landed the UITK last time I had to fix the shorts app tests not to select object by the UbuntuShape object type. I have seen that since many apps introduced the very same select_single("UbuntuShape", objectName="messageArea") when the select_single(objectName="messageArea") is perfectly enough.
[04:14] <bzoltan> ToyKeeper:  and now I see that the addressbook-app has for example fixed that but the messaging app not yet
[04:16] <bzoltan> ToyKeeper:  sorry, the messaging app is good too.. the share app has still that objct type reference
[04:16] <ToyKeeper> bzoltan: I think you need the automation part of QA...  which I'm not.
[04:18] <bzoltan> ToyKeeper:  OK, I will just make MRs for those apps
[04:21] <bzoltan> Mirv: I do not know who could take this MR https://code.launchpad.net/~bzoltan/share-app/no_ubuntu_shape/+merge/229893
[04:29] <bzoltan> Mirv: rsalveti: what do I do wong? https://ci-train.ubuntu.com/job/landing-015-1-build/148/console
[04:30] <rsalveti> bzoltan: same as we told you yesterday
 bzoltan: you need to change the changelog header to match the upstream version
[04:30] <bzoltan> rsalveti:  Sorry I must have missed that
 bzoltan: https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/sync_landing_0608/+merge/229827
 bzoltan: see you're trying to sync with 1.1.1181+14.10.20140806-0ubuntu1, but the version for this package is 1.1.1181+14.10.20140804-0ubuntu3
 bzoltan, you need `dch -v  1.1.1181+14.10.20140806-0ubuntu1 ""`
 bzoltan, the part before -0ubuntu1 has to be the same as the non-gles package
[04:31] <rsalveti> bzoltan: no worries
[04:33] <bzoltan> rsalveti:  I had the habit of caring about the version number before the + sign.
[04:36] <ToyKeeper> Well, fun.  Trying to test things that I've never actually gotten to work.
[04:36] <ToyKeeper> Like MTP, or facebook notifications.
[04:58] <Mirv> bzoltan: it sounds like there's a mismatch between the changelog version number and the tarball... somehow
[04:58] <Mirv> ah, resolved
[04:59] <bzoltan> Mirv:  I was helped :)
[05:00] <Mirv> bzoltan: 176 (the one that just finished) has most of the apps updates
[05:01] <bzoltan> Mirv:  The share app is still using the Ubuntu Shape there https://code.launchpad.net/~bzoltan/share-app/no_ubuntu_shape/+merge/229893
[05:01] <bzoltan> Mirv:  is in the 176 new shorts app?
[05:03] <Mirv> bzoltan: camera, clock, dropping-letters, filemanager, reminders, shorts, sudoku, terminal (=yes)
[05:03] <Mirv> bzoltan: I don't think share-app is in use anymore?
[05:03] <Mirv> bzoltan: the last update to share-app was done a year ago :)
[05:04] <bzoltan> Mirv:  it is on my test plan :)
[05:04] <bzoltan> Mirv:  Sure I can drop it :)
[05:04] <Mirv> yes, please do
[05:05] <bzoltan> Mirv: OK, so the 176 will be a cleaner image
[05:06] <Mirv> hopefully, and the year 1970 fix too
[05:07] <Mirv> #176 should have much, much, better results, then
[05:45] <cjwatson> ok, good, all the packages affected by last night's systemd breakage have resolvable build-deps against -proposed now
[05:51] <elopio> plars: results from #176 seem a lot more promissing. Thanks man.
[05:51] <plars> elopio: cool :)
[05:58] <bzoltan> Mirv:  Got a question... hopefully not a problem
[05:58] <plars> elopio: are the apparmor DENIED errors expected still with calendar_app? http://ci.ubuntu.com/smokeng/utopic/touch/mako/176:20140807:20140805.2/9544/calendar_app/1499446/
[05:59] <plars> elopio: hmm, still seeing some with camera also :(
[05:59] <plars> elopio: I wonder if the workaround didn't work completely
[05:59] <plars> I'll have to wait for the run to finish to see the full syslog I'm afraid
[06:00] <elopio> plars: on the calendar we are trying to patch the home directory.
[06:00] <elopio> I always thought those errors come from failing to patch it properly. But I'm not sure.
[06:01] <plars> elopio: yeah, I'm going to have to be more clever about it I'm afraid. I'm seeing a few instances so far where it didn't manage to set the ntpdate
[06:01] <bzoltan> Mirv:  I have changed the development focus of the UITK to the staging branch ... will the CI landing machinary land to the lp:ubuntu-ui-toolkit/trunk  or to the lp:ubuntu-ui-toolkit  ... what is the staging in fact
[06:01] <plars> elopio: in the one I'm looking at now, it would have been ok, but that may not always be the case
[06:01] <Mirv> bzoltan: it'd be lp:ubuntu-ui-toolkit
[06:02] <bzoltan> Mirv:  uhh... and that makes me reverting this  otherwise cool change
[06:02] <Mirv> bzoltan: yes, indeed...
[06:02] <elopio> Mirv: and can't CI land lp:ubuntu-ui-toolkit/trunk ?
[06:03] <plars> elopio: well, it looks like 2 of the 3 mako runs failed to get ntpdate successfully, but in all three cases I log the current date on the device and what hwclock reads, and all 3 were good (not 1970)
[06:03] <Mirv> elopio: possibly, with some exception? the default I guess always is lp:project
[06:04] <elopio> I think on the autopilot case, they are releasing something like lp:autopilot/1.5
[06:04] <bzoltan> elopio:  yes, as pitti just said
[06:05] <elopio> plars: so, we just got lucky ?
[06:05] <plars> elopio: well, sorta
[06:06] <plars> elopio: in this case, we are ok on the date/time, but we still see errors. So there still could be problems, just maybe not as many to sort through
[06:06] <plars> elopio: but clearly I'll have to retry the workaround if the initial call to ntpdate fails (it shouldn't)
[06:06] <plars> elopio: this reeks of the old issues we used to have where the network is up, but it's not *really* up
[06:07] <plars> elopio: i.e. we can ping the ip of the device, but we can't resolve hostnames from the device
[06:17] <elopio> plars: oh well, I'm glad we have you. I have no clue of how to make it more reliable.
[06:17] <elopio> but I'm happy that tomorrow I'll know where to start looking at the failures.
[06:18] <ToyKeeper> Hmm...  No sergiusens.
[06:18] <plars> elopio: I can make it more reliable, I'm just saying that I don't think really making sure the call to ntpdate would have helped us in this case
[06:18] <ToyKeeper> I can't make the features he changed work with or without the silo, so it's a bit hard to get any meaningful test results.
[06:18] <plars> elopio: so we would have seen the same failures, because ntpdate didn't really have any date problem to fix
[06:18] <ToyKeeper> A test plan would be helpful.
[06:20] <elopio> plars: the apparmor=DENIED messages on the calendar date back to at least #120
[06:21] <plars> elopio: yeah, that's what I'm hoping - I knew there were some of these that were failing for other reasons
[06:21] <plars> elopio: so they might be expected
[06:24] <tvoss> good morning
[06:48] <bzoltan> Mirv:  both the ubuntu_clock_app.tests.test_clock.TestClock.test_delete_world_city_must_delete_saved_world_city_list and the ubuntu_clock_app.tests.test_clock.TestClock.test_add_city_button_must_add_world_city are falky
[06:51] <Mirv> bzoltan: ok, but at least 100% on #176 and #175 http://ci.ubuntu.com/smokeng/utopic/touch/mako/176:20140807:20140805.2/9544/ubuntu_clock_app/
[06:51] <Mirv> bzoltan: #176 starts to look back to ok again http://ci.ubuntu.com/smokeng/utopic/touch/mako/176:20140807:20140805.2/9544/
[06:52] <Mirv> a raise from 84.1% to 96.1%. still some way to go, but should help.
[06:52] <bzoltan> Mirv:  It is ok for me too... after the 3rd attempt
[07:03] <tvoss> robru, could you reconfigure silo 14 for me?
[07:05] <tvoss> trainguards, could you reconfigure silo 14 for me?
[07:06] <Mirv> tvoss: sure
[07:08] <Mirv> tvoss: done
[07:23] <Saviq> davmor2, FWIW, silo 1 is now ready for QA
[07:26] <brendand> davmor2, do you want extra eyes testing silo1? i can give a hand
[07:43] <Saviq> brendand, since davmor2's not around, go ahead :)
[07:43] <Saviq> brendand, it's fixing two blockers, btw: dash header colours and edge demo
[07:45] <bzoltan> Mirv:  I am done with the UITK testing... I see same or even less failures with the UITK than on the CI dash
[07:46] <Mirv> bzoltan: has landing team agreed it's only isolated bug fixes that are included?
[07:46] <bzoltan> Mirv: sil2100: I have flipped the tested switch of the UITK. I have run 23 test suites with all the 800+ tests. At first it was yet again horror.. then on the second round it was only the galley-calendar-music to fail. I verified thatthe failures are the same as on the CI dash.
[07:47] <brendand> Saviq, there's also a pretty big feature in there
[07:47] <bzoltan> Mirv:  this landing contains two isolated bug fix. One of them is critical. Without that fix all UbuntuShapes will be wrongly sized.
[07:47] <Saviq> brendand, that's why we need QA sign-off on top of our normal testing
[07:48] <bzoltan> Mirv: sil2100: I am not pushing it... it is there :) feel free to take it or put it on hold if you wish so. The fix for two bugs are there.
[07:50] <Mirv> bzoltan: sil2100: my initial interpretation of TRAINCON-0 is that we can't release UITK since UITK has a non-fixed blocker bug assigned to it (bug #1351024)
[07:50] <Mirv> on the other hand, the fixed bugs are also high priority, although not blockers, and isolated
[07:50] <sil2100> Mirv, bzoltan: we'll discuss this on the meeting, but I would prefer to have a QA sign-off in this case :)
[07:52] <bzoltan> sil2100:  I am absolutely happy with that. More eyes see more.
[07:53] <bzoltan> Mirv:  just be clear... that bug is _not_ a UITK bug... the datepicker was not touched for ages and nothing around it was changed. It is zsombi who was kind enough to volunteer to attemp to fix it from the UITK.
[07:55] <bzoltan> Mirv: sil2100: but I am fine with the decision  to hold back the UITK if that is what you think as best. I am not in hurry.. this lanidng contains two MRs from kalikiana and from Kaleo to fix two important bugs. One I though is one of the blockers
[07:55] <zsombi> bzoltan: Mirv: question: if you don't release UITK, will the previous "released" one work with the Calendar app?
[07:56] <sil2100> bzoltan: ok, so did the application break somehow by using the components invalidly?
[07:56] <sil2100> bzoltan: well, we're holding this landing off because in any case it's something bigger anyway, so even with this I try to be double safe
[07:56] <bzoltan> sil2100:  no idea
[07:57] <bzoltan> sil2100: the datepicker issue is more likely a Qt problem, not a UITK neither app
[08:02] <zsombi> sil2100: no, it's not about that. I sense the Qt5.3 transition caused the problem
[08:02] <sil2100> bzoltan: ACK, anyway, we might assert the risks on the meeting and release it without QA sign-off even
[08:02] <sil2100> zsombi: hmmm
[08:03] <zsombi> sil2100: so far I saw the following: QuickUtils.rootItem() returns null in the PickerPanel on phone, but returns the valid MainView instance elsewhere
[08:03] <zsombi> sil2100: the same function returns the MainView instance on desktop everywhere
[08:04] <zsombi> sil2100: so the panel is there, but it had not been parented anywhere, thus its size is also 0
[08:04] <zsombi> sil2100: which makes it invisible :/
[08:05] <zsombi> sil2100: as we don't have AP tests for the PickerPanel (only for the DatePicker) this had not picked up in the transition to Qt5.3
[08:06] <zsombi> sil2100: PickerPanel is anyway provides a custom solution, on the phone the DatePicker should appear in the OSK, not as it does now
[08:07] <zsombi> sil2100: anyway, I'm trying to figure out a workaround so this gets unblocked, but will take time :(
[08:07] <Saviq> brendand, it's +1 from me on two devices, is in your hands now
[08:09] <brendand> Saviq, i wasn't planning on being the sole tester for it, so i'll want davmor2's ack too
[08:10] <brendand> Saviq, unless it happens that he's not in today
[08:10] <Saviq> k
[08:12] <sil2100> zsombi: ok, thanks o/
[08:15] <sil2100> popey, Mirv: hi guys! Could you somehow publish the new music-app to the store?
[08:16]  * sil2100 also wonders why we suddenly have 8 failures in camera-app
[08:18] <sil2100> brendand, ogra_`: so, the camera-app test failures might be related to the new camera-app upload, might be something constantly broken as those seem to fail for both mako and flo
[08:18] <brendand> sil2100, i can look at it
[08:18] <brendand> sil2100, there seem to be some new calendar app failures too
[08:19] <brendand> sil2100, and some not so new
[08:22] <brendand> remember how we used to have so many issues with filemanager :)
[08:22] <brendand> barely notice it these days
[08:23] <brendand> something positive
[08:23] <davmor2> Morning all
[08:23] <davmor2> brendand: did you make a start testing or silo1 or did you want me too, or how far did you get?
[08:23] <Mirv> sil2100: sil2100 new as in latest trunk? I can kick a build, someone can test it, and I can upload it.
[08:24] <brendand> davmor2, not yet - i've been investigating some of the CI failures. after the meeting i'll start
[08:24] <davmor2> Saviq: silo1 deals with the colours and guide right?
[08:24] <brendand> davmor2, i particularly want to test the dual sim stuff
[08:24] <brendand> davmor2, btw do you have a locked sim?
[08:25] <Mirv> sil2100:: camera was asked to be uploaded by Florian yesterday
[08:25] <davmor2> brendand: no my sim is open
[08:25] <sil2100> Mirv: yes, latest from trunk
[08:25] <brendand> davmor2, maybe we want to rope jibel in then
[08:25] <brendand> davmor2, he has been waiting for this for a while
[08:26] <jibel> brendand, for what?
[08:26] <brendand> jibel, silo001 contains some changes that add the sim unlocking feature
[08:26] <sil2100> brendand: if you could take a look at those it would be awesome
[08:26] <brendand> sil2100, which :) silo001 or camera app failures?
[08:26] <brendand> sil2100, i plan to look at both in due course
[08:26] <jibel> brendand, I can do that but not right now in 90min would be okay?
[08:27] <sil2100> brendand: camera-app, as 001 has davmor2 and maybe jibel will help as well ;)
[08:27] <sil2100> brendand: well, camera-app and calendar ;p
[08:27] <sil2100> Mirv: thanks!
[08:27] <brendand> sil2100, sure
[08:28] <davmor2> sil2100: hang on why is silo1 adding features it was meant to be fixes only
[08:28] <sil2100> davmor2: it's not fixes only, that's why it needs QA sign-off
[08:28] <davmor2> grrrrrrrr
[08:30] <brendand> davmor2, that's what i said
we really shouldn't mix the two</grumble>
[08:33] <Mirv> sil2100: music-app built at http://s-jenkins.ubuntu-ci:8080/job/music-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.music_1.3.558_all.click
[08:34] <sil2100> ogra_`: meeting!
[08:34] <ogra_`> sil2100, yeah, sorry, stuck in mail discussions, on my way
[09:13] <brendand> sil2100, yeah so calendar_app was switched to use the new test code
[09:13] <brendand> sil2100, doesn't look like it was really tested though
[09:13] <brendand> sil2100, it might have been, but in the wrong way
[09:18] <brendand> i'll file a bug for this and then go look at silo001
[09:20] <sil2100> brendand: uh oh
[09:20] <sil2100> brendand: thanks ;)
[09:20] <sil2100> brendand: did you ahve a moment to look at camera-app already?
[09:21] <brendand> sil2100, https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1353921
[09:22] <brendand> sil2100, yes - i reproduced the failures, but now i need to look closer and file a bug
[09:22] <brendand> THEN i can work on silo001 :)
[09:26] <sil2100> Thanks ;)
[09:40] <cjwatson> anyone mind if I publish click (4)?
[09:41] <sil2100> cjwatson: it looks like test additions and bugfixes only, right?
[09:42] <cjwatson> Yup
[09:42] <sil2100> cjwatson: ok, then it should be safe to publish during traincon even
[09:43] <tvoss> sil2100, silo 10 is good to go, no change rebuild, just stripping unneeded build deps
[09:44] <sil2100> tvoss: ACK, let me take a look at that in some moments
[09:44] <sil2100> davmor2: how's silo 001 going?
[09:44] <tvoss> sil2100, ack
[09:46] <cjwatson> sil2100: ok, thanks
[09:47] <davmor2> sil2100: full dog fooding remember I'll get back to you by Lunch,  so far the guide is fixed, the ui change for which scope you are in works, the orange downloading stuff indicator at the bottom of the page works and the colours seem correct on scopes but there is lots of other stuff to test before I get to the dogfooding bit to makes sure it didn't break anything
[09:47] <tvoss> cjwatson, powerpc publishing seems to be slow today, is that a known issue?
[09:47] <jgdxx> plars, ping
[09:49] <brendand> sil2100, so the camera problem is a user facing issue
[09:50] <brendand> sil2100, it takes a stupid long time to launch
[09:50] <brendand> sil2100, then when it finally does it hides itself immediately
[09:50] <sil2100> brendand: oh?
[09:50] <brendand> davmor2, if you're on 176 can you confirm?
[09:50] <sil2100> Ok, I wonder how 'reverts' work for click apps in the store, probably not as smooth
[09:51] <brendand> davmor2, say yes so i can go help with silo1
[09:51] <brendand> davmor2, just nod and smile
[09:52] <davmor2> brendand: looks like it
[09:52] <brendand> \o/
[09:52] <brendand> but also :(
[09:53] <brendand> silo001 here i come!
[09:54] <cjwatson> tvoss: no reason why *publishing* on any given architecture would ever be any different - they're all published at once
[09:54] <cjwatson> tvoss: example?
[09:55] <tvoss> cjwatson, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-014/+packages
[09:55] <davmor2> brendand: can you try something too please,  add a contact to an sms and see if the first letters are cut off when it is added
[09:56] <davmor2> brendand: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-08-07-105558.png
[09:56] <sil2100> popey: hello!
[09:57] <cjwatson> tvoss: I would assume that it just built slightly later and will publish in the next pass, which are usually only 5 or 10 minutes apart
[09:57] <cjwatson> Can't look at the PPA publisher logs right now
[09:57] <tvoss> cjwatson, ah okay
[09:58] <cjwatson> Builders don't look particularly busy, so it was probably just adare being itself
[09:58] <cjwatson> https://launchpad.net/builders/ <- basically empty
[09:59] <Saviq> davmor2, brendand, is there anything in silo1 that looks like would make you say NACK by now?
[09:59] <davmor2> Saviq: I'm still finding all the hidden jems you added :P
[10:00] <ogra_`> ugh you are still wrangling with silo 1 ?
[10:00] <ogra_`> poor Saviq
[10:05] <brendand> Saviq, i'm just starting
[10:05] <cjwatson> Does anyone know if there's a contact e-mail address for the app store?
[10:05] <cjwatson> Stupid things to be blocked on during key signing ...
[10:11] <brendand> sil2100, in its current state i'm not sure how any of the camera-app tests worked
[10:12] <sil2100> brendand: that worries me a bit, someone requested a new camera app yesterday and I'm afraid the tests weren't ran properly for those before publishing
[10:12] <sil2100> ogra_`: do you remember who requested the new camera?
[10:12] <brendand> sil2100, seems to be a theme these days
[10:12] <ogra_`> sil2100, nope, no idea
[10:12] <ogra_`> sil2100, if in doubt, ask Kaleo i guess
[10:12] <brendand> sil2100, i've heard before of click package tests not being run on device
[10:13] <sil2100> Oh, Kaleo
[10:13] <ogra_`> he owns the majority of MPs for it
[10:13] <brendand> sil2100, i would certainly hope they would be for camera-app
[10:13] <sil2100> brendand: damn... at least I know that popey is running all AP tests always before publishing to the store
[10:14] <popey> 11:13:37 < sil2100> brendand: damn... at least I know that popey is running all AP tests always before publishing to the store
[10:14] <popey> nope
[10:14] <popey> The AP tests run on jenkins. I no longer run them locally.
[10:15] <sil2100> Oh? Ah, right, but at least you don't allow normally applications that fail tests on jenkins, right?
[10:16] <sil2100> But do the jenkins tests run on real devices like mako?
[10:16] <popey> no, they run on desktops
[10:16] <brendand> !!!!!!!!!!!!!!!
[10:16] <popey> AIUI
[10:16] <popey> I do not run the lab, this is what I am told, anyway.
[10:16] <sil2100> Crap... ok, good to know
[10:17] <popey> What's the problem?
[10:17] <brendand> i really hope this isn't true
[10:17] <brendand> popey, camera app is completely borked
[10:17] <popey> oh dear.
[10:17] <popey> on the dashboard?
[10:17] <popey> it worked yesterday ☻
[10:18] <sil2100> Yeah ;) THere was a release of camera-app and the tests look bad (on all our devices)
[10:18] <popey> so who tested it on devices before uploading to the store?
[10:18] <popey> I can revert the store back to the previous version in the meantime if that helps?
[10:19] <brendand> popey, i can't imagine that anyone did
[10:19] <brendand> popey, basically what happens is that camera takes 30+ seconds to open
[10:20] <popey> do you want me to revert the store version?
[10:20] <popey> (I am on vacation today, and am about to go afk for most of the day)
[10:21] <Saviq> sil2100, can we get a silo for line 32 please?
[10:22] <Saviq> ↑ that one ;)(
[10:22] <popey> sil2100: in my absence dholbach can also revert apps back
[10:22] <bzoltan> sil2100: Mirv: can somebody tell us when this datepicker problem appeared? I think it is a problem for longer time..
[10:25] <sil2100> brendand: you think a revert might help? If this would fix the issues then I would be +1 for tit
[10:25] <sil2100> *it
[10:25] <sil2100> Damn, 'tit'...
[10:25] <sil2100> My typos are getting more vulgar every moment
[10:26] <brendand> sil2100, let's keep it clean, this is a family channel
[10:29] <davmor2> Saviq: what the hell is a collapsing preview widget
[10:29] <Saviq> davmor2, nothing that you can see yet
[10:29] <popey> bzoltan: i think balloons answered that question when zsombi asked it yesterday... maybe here or --app-devel
[10:30] <sil2100> popey: ok, anyway you go and enjoy your holiday, we'll poke dholbach for the revert
[10:30] <Saviq> davmor2, only difference you'll see is that long text in previews won't be collapsed temporarily
[10:30] <bzoltan> popey:  I just asked zsombi and he does not know
[10:30] <Saviq> davmor2, until scopes start using the new collapsing pattern
[10:30] <davmor2> Saviq: ah yes I noticed that
[10:30] <Saviq> davmor2, but just FYI https://sites.google.com/a/canonical.com/unity8dash/toolkit/14-previews
[10:30] <sil2100> bzoltan: not entirely sure, but I think we noticed it last week during dogfooding - davmor2 ^ ?
[10:31]  * popey is now afk
[10:31] <davmor2> bzoltan: 15x I think let me check
[10:32] <bzoltan> sil2100:  because it is not something new and it did not come with the UITK. Something got broken on the  Qt layer.
[10:37] <Saviq> sil2100, sorry, can we get a reconfigure on silo 11 please, forgot to add u-s-shell
[10:38] <sil2100> Saviq: no problem
[10:39] <sil2100> Saviq: done
[10:39] <Saviq> sil2100, thank you
[10:39] <tvoss> sil2100, nagging ping for silo 10
[10:40] <Mirv> sil2100: brendand: I don't have a delay in starting camera app, even after reboot. maybe it only happens after clean wipe or something, and that's why it wasn't noticed? Kaleo tested the new commit before I uploaded it. and like I said, I also have all AP:s passing locally.
[10:42] <Kaleo> Mirv, sil2100, brendand, I'll try a clean install too after testing an upgrade to 176
[10:43] <Mirv> hey, we have Kaleo! :) great.
[10:43] <Kaleo> Mirv, discussion is happening on #ubuntu-touch
[10:43] <Mirv> I see
[10:45] <sil2100> It might have been broken by something else then
[10:45] <Mirv> bzoltan: re: when date&time picker stopped working, the bug says "Sadly due to https://code.launchpad.net/bugs/1328600 the test for this is disabled, which means we didn't get to see exactly when or why this stopped working.". so only bisecting by flashing earlier images would help
[10:46] <bzoltan> Mirv:  I can do that if I know more or less the range
[10:59] <Mirv> bzoltan: maybe start with something from end of June like #105
[10:59] <Mirv> bzoltan: if it works, skip to middle of July like #133
[11:00] <bzoltan> Mirv:  OK
[11:01] <bzoltan> Mirv:  binary search algorithm is cool
[11:04] <davmor2> sil2100: Saviq: okay so this is looking pretty good
[11:04] <sil2100> \o/
[11:04] <Saviq> \o/
[11:04] <brendand> davmor2, can you check that the Cellular settings and Wi-Fi settings entries on indicator-network don't work
[11:05] <ogra_`> stop doing these suggestive questions ... !
[11:05] <Saviq> lol
[11:05] <Saviq> brendand, works fine here
[11:05] <ogra_`> davmor2, can you make sure that you do not fine any bugs in indicator-network ?
[11:05] <ogra_`> :)
[11:06] <sil2100> brendand: don't try adding new blockers!
[11:06] <davmor2> ogra_`: no and what's with the back tick
[11:06] <ogra_`> (if you use suggestive questions, phrase them more positively )
[11:06] <ogra_`> davmor2, hmm, good question
[11:06] <ogra_> thanks for pointing it out, hadnt noticed
[11:10] <Saviq> brendand, what happens for you, the setting app doesn't launch? can you check it launches from launcher/dash?
[11:11] <Saviq> brendand, maybe it's launched already?
[11:21] <dpm> hi psivaa, would it be possible to trigger the autolanding job for this music-app branch? Not sure why it didn't run: https://code.launchpad.net/~vthompson/music-app/prevent-incorrect-no-music-screen/+merge/228972
[11:22] <psivaa> dpm: just a sec pls
[11:22] <dpm> np, thanks
[11:22] <Saviq> sil2100, can I please have another reconf on silo 11... needed to pull a change from silo 1 in (unity-api)
[11:22] <Saviq> until that one lands
[11:22] <Mirv> sil2100: I can do that
[11:22] <sil2100> Saviq: ACK :)
[11:23] <sil2100> Oh, ok
[11:23] <sil2100> Mirv was faster!
[11:23] <Mirv> ;)
[11:23] <Mirv> and even tab-completed [s]il instead [s]aviq
[11:24] <Mirv> Saviq: done
[11:24] <Saviq> ;)
[11:25] <sil2100> ;)
[11:33] <psivaa> dpm: i've just triggered the autolanding job manually.. i see it's been done the same was in the past by fginther too..
[11:33] <dpm> awesome, thanks psivaa
[11:33] <psivaa> yw :)
[11:37] <sil2100> davmor2: so, you give a sign-off for 001? :)
[11:37] <davmor2> sil2100: not finished I said it looked good so far :P
[11:38] <Saviq> davmor2, nasty!
[11:45] <sil2100> Ah ;)
[11:48] <dpm> psivaa, thanks for running that job. It seems it failed with a bzr error. Any ideas why or how to fix it? -> http://91.189.93.70:8080/job/generic-land/1859/console
[11:50] <psivaa> dpm: ohh, i triggered http://s-jenkins.ubuntu-ci:8080/job/music-app-autolanding/4/console in fact.. let me see what's happening with ^ job
[11:50] <dpm> ahayzen, ^
[11:50] <ahayzen> dpm, thanks :)
[11:51] <ahayzen> dpm, ah thts s-jenkins don't think we can see that...i'll wait and see wht u guys discover :)
[11:57] <sil2100> Ok, time for lunch o
[11:57] <sil2100> o/
[12:05] <psivaa> dpm: could probably be the uploader was not in the allowed_users list in that jenkins.. let me see if adding fixes
[12:06] <dpm> psivaa, he should be in the list already, but perhaps he used another e-mail address? I don't know.
[12:16] <tvoss> Kaleo, brendand the camera app issue is likely caused by https://bugs.launchpad.net/qtmir/+bug/1352977
[12:17] <Kaleo> sil2100, ^
[12:28] <psivaa> dpm: sorry, i'm not sure whats going on.. may be some lp experts could help?
[12:29] <psivaa> cjohnston: would you mind looking at why https://code.launchpad.net/~vthompson/music-app/prevent-incorrect-no-music-screen/+merge/228972 is throwing:
[12:29] <psivaa> http://91.189.93.70:8080/job/generic-land/1861/console
[12:30] <olli> sil2100, where are we at in  resolving TC-0
[12:31] <psivaa> cjohnston: the revnumbers in the revision dropdown list talks about 548, but i cant see that in the revision list
[12:34] <Saviq> davmor2, I'm gonna be annoying and ask once more: how you doinn'?!
[12:35] <Wellark> would it be possible to have to ci train speadsheet to automatically collect a list of all the attached bugs from the individual branches part of a landing?
[12:35] <Wellark> would be cool
[12:35] <cjwatson> better in the dashboard I'd have thought
[12:36] <Wellark> Saviq: what should I be looking?
[12:36] <Wellark> cjwatson: well, somewhere :)
[12:42] <brendand> Kaleo, can we try and find out how this was missed?
[12:42] <Kaleo> brendand, well, first we need to figure what package/upload created the issue no?
[12:42] <brendand> Kaleo, was camera-app always trying to prompt for location?
[12:43] <Kaleo> brendand, camera app never does that exactly, it just uses the location API to retrieve location
[12:43] <Kaleo> brendand, no UI attached to it, something else is doing it
[12:43] <Kaleo> tvoss, what's the package doing that? and do you know since when?
[12:43] <brendand> Kaleo, right so location service changed somehow maybe
[12:44] <brendand> tvoss, Kaleo - ubuntu-location-service-bin from 2.0.1+14.10.20140731-0ubuntu1 to 2.0.1+14.10.20140806-0ubuntu1
[12:44] <brendand> in 176
[12:44] <tvoss> Kaleo, it's the location service and the trust store introducing the prompt
[12:45] <brendand> tvoss, does location service have a test plan?
[12:45] <tvoss> brendand, the location service is a trusted helper now, prompting the user for granting trust whenever an application tries to access it for the first time
[12:45] <tvoss> brendand, sure, does not include the trust store, yet. Will update
[12:45] <tvoss> brendand, however, we know the underlying issue. Shows up for osmtouch, too
[12:46] <brendand> tvoss, ok
[12:46] <brendand> tvoss, please look at what test plans need to be updated to prevent this happening again
[12:46] <tvoss> brendand, what happening exactly?
[12:47] <brendand> tvoss, camera app requests the location but the user never sees the dialog (i guess). Kaleo knows more
[12:47] <brendand> tvoss, then when a timeout is reached the app disappears into the background
[12:47] <tvoss> brendand, see the pasted bug report before. Not sure we should do a manual test for that
[12:47] <Kaleo> sil2100, you around?
[12:47] <Saviq> Wellark, I pung davmor2, he's not around though
[12:48] <brendand> tvoss, well if you're confident an automated test can catch the same issues, that's even better
[12:48] <tvoss> brendand, sure
[12:48] <Wellark> Saviq: ok.
[12:48] <brendand> Saviq, indicator-network still has broken settings links
[12:48] <brendand> Saviq, i don't have a SIM card in mako, this could be a factor
[12:49] <Wellark> brendand: what where?
[12:49] <Saviq> brendand, and you reliably see that?
[12:49] <Wellark> which link?
[12:49] <brendand> Saviq, yes. after reboot too
[12:49] <brendand> Wellark, link to Cellular settings and Wifi settings
[12:49] <Saviq> brendand, install url-dispatcher-tools please
[12:49] <brendand> Wellark, are both broken, at least with silo001
[12:49] <Saviq> brendand, and go `url-dispatcher settings://`
[12:50] <Wellark> brendand: your phone is broken. works for me. bug resolution: invalid
[12:50] <Wellark> ;)
[12:51] <Saviq> brendand, no SIM here either, two devices, links work just fine
[12:51] <Saviq> brendand, are you sure settings app isn't open already?
[12:52] <brendand> Saviq, did you mean just 'url-dispatcher settings://' with nothing after?
[12:52] <Saviq> brendand, yeah, that should work just fine
[12:53] <Wellark> verified: if settings is already open the links don't seem to do nothing
[12:53] <brendand> Wellark, that itself is a bug
[12:53] <Saviq> Wellark, yes, that's a bug, but not a silo 1 bug
[12:53] <Wellark> but that's system-settings/unity8? bug
[12:53] <brendand> Wellark, but even with it closed it doesn't work
[12:54] <cjohnston> psivaa: AIUI, the MP has to be approved by someone in Canonical
[12:54] <Saviq> brendand, so if you go `url-dispatcher settings://`, does setting app launch?
[12:54] <brendand> Saviq, nope - there is an error
[12:54] <Saviq> brendand, your url dispatcher got b0rked
[12:54] <brendand> Saviq, fresh image + silo001
[12:55] <Saviq> brendand, doesn't mean it's not happening outside of silo 1
[12:55] <Saviq> brendand, rm -R .cache/url-dispatcher
[12:55] <Saviq> brendand, reboot, and it should work again
[12:56] <davmor2> Saviq: I'm back
[12:57] <Saviq> brendand, somehow sometimes the url dispatcher database gets b0rked, upgrading settings app caused it for me once
[12:57] <Saviq> brendand, don't think there's a bug actually
[12:57] <Saviq> I mean a filed one
[12:57] <davmor2> Saviq: sil2100: I'm happy with silo1 unless anyone else found anything brendand ?
[12:57] <Saviq> brendand, in any case, that's unrelated to silo 1, which doesn't touch url-dispatcher or settings app
[12:58] <cjohnston> dpm: AIUI, the MP has to be approved by someone in Canonical
[13:00] <dpm> cjohnston, this hasn't been the case for core apps. So far anyone in the development team, be it employees or other contributors have been able to top-approve branches
[13:02] <cjohnston> dpm: hrm.. dpm what changed between the failure on the 4th and now that the bot approved it now?
[13:06] <brendand> davmor2, i'll just play about a little bit more
[13:06] <davmor2> brendand: I granted already ;)  Seems pretty solid to me
[13:06] <dpm> cjohnston, I don't know tbh
[13:06] <Saviq> brendand, did removing the url-dispatcher cache help?
[13:06] <sil2100> Kaleo: I'm around now
[13:07] <cjohnston> dpm: I'm wondering if the person did an --overwrite when pushing an update
[13:07] <davmor2> sil2100, Saviq: silo001 granted by me brendand wants to break it some more though :D
[13:07] <Saviq> davmor2, \o/
[13:07] <Kaleo> sil2100, so the culprit is ubuntu-location-service-bin from 2.0.1+14.10.20140731-0ubuntu1 to 2.0.1+14.10.20140806-0ubuntu1
[13:07] <brendand> Saviq, yeah it did. i did next to nothing with the phone apart from installing the silo, so no idea how it managed to get borked
[13:07] <Kaleo> sil2100, according to brendand
[13:07]  * sil2100 gives tvoss an evil eye
[13:07] <dpm> cjohnston, I don't know, he's not online atm. Is there anything he can do to undo that, if that were the case?
[13:07] <Saviq> brendand, must be the url db generation is racy, worth a bug in itself for sure
[13:08] <brendand> sil2100, your evil eye is getting tired this week i think
[13:09] <sil2100> Yeah, it's all red now from overuse
[13:09] <cjohnston> dpm: I'm not familiar enough with the processes... balloons you about?
[13:09] <sil2100> tvoss: anyway, once you're around, could you take a look at camera-app regression caused by yesterday's location-service landing?
[13:13] <Saviq> Kaleo, sil2100, I think there's a known bug there
[13:13] <tvoss> sil2100, known and in the works: https://bugs.launchpad.net/qtmir/+bug/1352977
[13:13] <Saviq> Kaleo, ↑
[13:13] <Kaleo> Saviq, I know
[13:13] <Saviq> oh ok
[13:14] <sil2100> Nice
[13:14] <Saviq> PUSH THE BUTTON, PUSH THE BUTTON, PUSH THE BUTTON! (on silo 1 please)
[13:14] <sil2100> dednick: hey! How's it going with bug LP: #1352977 ? I guess it's pretty critical now...
[13:14] <davmor2> sil2100: moving onto to silo015 and now after that I need to look at silo 20 for sergiusens
[13:15] <davmor2> but right now I need to step out for about 30minutes or so
[13:15] <sil2100> davmor2: ok, thanks :)
[13:15] <dednick> sil2100: working on it
[13:16] <sil2100> dednick: any ETA for it?
[13:17] <dednick> sil2100: nope. hopefully be done with the patches by eod or tomorrow.
[13:17] <sil2100> hmm, then we might have to revert then
[13:18] <tvoss> sil2100, frankly, that's really a bad idea
[13:18] <tvoss> sil2100, we are landing a massive feature critical to rtm, we have one bug open, know what is causing the issue ... not sure reverting is the right measure here
[13:19] <tvoss> olli, ^
[13:20] <olli> is this in reference to https://bugs.launchpad.net/qtmir/+bug/1352977
[13:20] <tvoss> olli, yup
[13:20] <ogra_> tvoss, well, then fix it asap ...
[13:20] <ogra_> the prob is that it keeps us in traincon-0
[13:20] <ogra_> which makes landing things slower and harder
[13:20] <tvoss> ogra_, we have whitelisted worse issues before
[13:20] <tvoss> ogra_, also: dednick is working on it
[13:21] <ogra_> sil2100, we need to stop that whitelisting business ... see, people start to use it as argument
[13:21] <tvoss> sil2100, Kaleo the camera app is running unconfined?
[13:21] <Kaleo> tvoss, I don't think so
[13:21] <Saviq> tvoss, no, is click
[13:21] <tvoss> Kaleo, okay
[13:23] <olli> sil2100, what other promotion blockers are left?
[13:23] <tvoss> sil2100, Kaleo as an immediate measure, I can just whitelist the camera app in the location service
[13:23] <sil2100> We have a few... we need to land silo 001 to get rid of two, but besides that we're blocked on the date-time picker
[13:23] <tvoss> sil2100, what is the eta for the fix?
[13:23] <olli> sil2100, what's the plan for date-time picker
[13:24] <olli> bug didn't seem to be overly promising
[13:24] <sil2100> tvoss, olli: zsombi and bzoltan are looking into it, they're trying to get the issue fixed in UITK (since it seems to be a problem introduced by Qt)
[13:24] <olli> sil2100, ok, do we have an eta from them?
[13:25] <sil2100> tvoss: I guess whitelisting might be the best solution here, but only if it gets done temporarily - i.e. that we keep pushing on the real fix
[13:25] <sil2100> olli: sadly no...
[13:25] <tvoss> sil2100, well, sure
[13:25] <sil2100> olli: but we would really need a promotable image today or at max tomorrow morning
[13:25] <olli> sil2100, so, when talking about reverting... doesn't seem like there is anything defined to revert for the date time issue
[13:26] <olli> what's your plan forward then on that one? whitelist?
[13:27] <sil2100> olli: no, we wait for date-time as much as we can, there's not much we can do there... in case it can't be done by UITK then we'll have to poke calendar app developers to maybe somehow workaround it at least
[13:30] <sil2100> tvoss: could you prepare a branch for the whitelisting then? This would basically mean that camera-app will not prompt for the location permission, right?
[13:30] <sil2100> brendand: how's 001? Can I publish? Do I have your blessing as well?
[13:31] <brendand> davmor2, did we get any ack on sim unlocking?
[13:32] <psivaa> cjohnston: ack, thank you.
[13:33] <cjohnston> psivaa: there is other info in the scrollback.. I think it may be possible the user pushed the branch with --overwrite...
[13:33] <psivaa> cjohnston: ohh, that appears more inline with the ghost prev version info thrown by bzrlib
[13:34] <cjohnston> yup.. I'm just not really sure how to handle it with cu2d stuff
[13:36] <tvoss> sil2100, vice versa, the location service will not prompt when the camera app tries to access it.
[13:36] <sil2100> ACK
[13:41] <Saviq> brendand, yeah, davmor2 tested SIM unlocking, dual and single, so did I
[13:41] <Saviq> davmor3, !
[13:43] <davmor3> jibel brendand location is working on 176 and the toggles in the indicator do nothing by the look of it. . Tracking myself in here maps now
[13:44] <sil2100> brendand: are you still testing silo 001?
[13:45] <davmor3> sil2100 silo16 fixes the things its meant to now to see if it broke anything
[13:45] <sil2100> davmor3: you mean, silo 15 right?
[13:45] <sil2100> brendand: ok, I see it's signed off so I publish!
[13:46] <davmor3> Testing on 3g while off to get my car ubuntu ftw
[13:46] <davmor3> sil2100 yeah sorry the uitk fixes
[13:46] <Wellark> brendand: what about sim unlocking?
[13:49] <rsalveti> Kaleo: sil2100: tvoss: does it mean nobody can't use the camera-app? or just when location is enabled?
[13:49] <Kaleo> rsalveti, nobody
[13:50] <sil2100> rsalveti: what I think it means is that camera app can use location service whenever it wants
[13:50] <sil2100> Without prompting for permission
[13:50] <rsalveti> that was before
[13:51] <rsalveti> not being able to use the camera-app is a huge blocker
[13:51] <rsalveti> how did we land this with trainco-0?
[13:51] <rsalveti> or was it before we got into trainco?
[13:51] <sil2100> rsalveti: it got signed off by QA
[13:52] <rsalveti> hm, no good
[13:52] <Wellark> davmor3: is somebody manyally acking the stuff in silo1 ?
[13:52] <sil2100> Not sure if davmor3 was aware of camera-app using location service, but also maybe it's not always a problem, maybe sometimes it worked...
[13:52] <rsalveti> but well, do we have a fix coming in the next couple of hours?
[13:52] <Wellark> as queuebot said somebody should
[13:52] <rsalveti> otherwise please revert
[13:53] <rsalveti> we need to unblock trainco-0 asap
[13:53] <sil2100> Wellark: I'm reviewing the changes
[13:53] <tvoss> rsalveti, please see backlog, we are working on an actual fix, and I'm preparing a hotfix to unblock traincon 0
[13:53] <sil2100> rsalveti: a workaround is being prepared, that will whitelist camera-app from prompting
[13:54] <tvoss> rsalveti, please also note that we have other promotion blockers around
[13:54] <rsalveti> but it affects other apps as well
[13:54] <rsalveti> https://bugs.launchpad.net/qtmir/+bug/1352977
[13:54] <rsalveti> tvoss: right, I'm asking for an ETA
[13:54] <tvoss> rsalveti, sure, a known bug, we are working on it. I really don't think that the introduced regressions in relation to the importance of the feature justify a revert
[13:55] <rsalveti> sil2100: that's not going to fix the entire issue
[13:55] <tvoss> rsalveti, why wouldn't that fix the issue?
[13:55] <rsalveti> well, anything can justify a revert if that means we're closer to get out of trainco-0
[13:55] <rsalveti> tvoss: the whitelist sil2100 said
[13:55] <Saviq> sil2100, need someone to sign off packaging changes in silo 1?
[13:55] <sil2100> Saviq: no, I did that already
[13:55] <Saviq> kk
[13:55] <sil2100> Saviq: (all packages are from universe)
[13:55] <sil2100> ;)
[13:56] <tvoss> rsalveti, sorry, but traincon0 is a state we are imposing ourselves. I see your point, but I think a revert of the trust-store landing is not the right approach here
[13:56] <Wellark> sil2100: <3
[13:56] <Saviq> \o\ /o/ \o/ \o\ /o/
[13:56] <rsalveti> tvoss: well, there are really only two answers for that
[13:56] <rsalveti> 1) we revert it
[13:56] <rsalveti> 2) we fix it
[13:56] <Wellark> now, I need a new silo for the remaining commits
[13:56] <rsalveti> do we have time to fix it?
[13:56] <tvoss> rsalveti, I think we have
[13:56] <Wellark> pete-woods: can you fill in the paper work?
[13:56] <rsalveti> would the fix land soon, like over the next few hours?
[13:56] <brendand> tvoss, did the trust store change land during traincon-0?
[13:56] <sil2100> tvoss, rsalveti: I was considering a revert, I'm just still looking at the risks of that, as it was a bigger landing, so I actually hoped for a workaround instead
[13:57] <pete-woods> Wellark: details plz
[13:57] <tvoss> brendand, might be, probably slightly before
[13:57] <davmor3> sil2100 I don't get the popup to enable location service in camera
[13:57] <rsalveti> tvoss: if the fix is landing today still, that would be fine, otherwise let's just revert
[13:58] <rsalveti> not much we can do, really
[13:58] <brendand> sil2100, do we have records of which silo that landed in and when?
[13:58] <tvoss> rsalveti, so the promotion blocker is the camera app. we can fix that with whitelisting it
[13:58] <tvoss> rsalveti, dednick is working on the actual fix
[13:58] <rsalveti> blocking osmtouch is also a big thing
[13:58] <tvoss> brendand, silo 10, not much use in post mortem
[13:58] <brendand> tvoss, whitelisting it?
[13:59] <tvoss> brendand, whitelisting as in?
[13:59] <brendand> tvoss, 'so the promotion blocker is the camera app. we can fix that with whitelisting it'
[13:59] <tvoss> brendand, yup
[13:59] <sil2100> brendand: http://people.canonical.com/~lzemczak/landing-team/176.commitlog <- here
[13:59] <tvoss> rsalveti, not a promotion blocker, htough
[14:00] <rsalveti> right, but still
[14:00] <rsalveti> a regression caused by a feature we landed in the location-service itself
[14:00] <brendand> tvoss, my understanding of whitelisting it in this context is that we give it a pass because it doesn't impact the user
[14:00] <balloons> cjohnston, so let's talk https://code.launchpad.net/~vthompson/music-app/prevent-incorrect-no-music-screen/+merge/228972
[14:00] <tvoss> rsalveti, that's actually not exactly correct. It is caused by a bug in qtmir
[14:01] <rsalveti> sil2100: if qa didn't know that it needed to test camera-app, that means camera-app testing is not included in the landing wiki for location-service
[14:01] <tvoss> brendand, sure. I think we should whitelist the camera app in the location service to keep it usable
[14:01] <rsalveti> tvoss: sure, but the one that triggered it is the location-service, you know how things work
[14:01] <Saviq> is it the biggest silo or what!
[14:01] <rsalveti> sil2100: and we clearly need to fix that :-)
[14:01] <Saviq> and in TRAINCON-0 no less!
[14:01] <brendand> tvoss, ok we're overloading terms here
[14:02] <brendand> tvoss, you mean the way to fix camera-app quickly is to whitelist it in location-service so there is no need for a prompt
[14:02] <tvoss> brendand, yup
[14:02] <brendand> tvoss, that's fine
[14:02] <sil2100> rsalveti: right'o, let me take a look at the testing plan then - and talk with davmor2 once he's back
[14:02] <tvoss> Saviq, I would agree but we have other promotion blockers around
[14:03] <Saviq> tvoss, I just fixed mine :P
[14:03] <cjohnston> balloons: ok.. have you seen that before?
[14:03] <tvoss> Saviq, I'm talking about the date-time indicator
[14:03] <Saviq> tvoss, think I'm out of the loop, what about it?
[14:03] <balloons> cjohnston, I see autolanding job just started for it: http://91.189.93.70:8080/job/music-app-autolanding/561/parameters/?
[14:04] <balloons> ahh.. it just keeps trying to land
[14:04] <tvoss> rsalveti, sil2100 as agreed with brendand: I will add an automatic test for the prompting to work correctly
[14:04] <tvoss> rsalveti, sil2100 no need to add even more manual tests here
[14:05] <rsalveti> well, when QA needs to sign something, they need to know what other stuff to validate
[14:05] <balloons> so cjohnston no I've never seen that bzr error before, but sounds like we need to fix the bzr tree
[14:05] <rsalveti> camera-app was clearly something that wasn't included in the qa validation script when landing location
[14:06] <brendand> davmor2, isn't testing camera-app part of standard dogfooding?
[14:06] <tvoss> rsalveti, sure, but we shouldn't limit ourselves to camera app here, as you pointed out earlier, to
[14:06] <balloons> so cjohnston I think the fix is simple enough, redo the MP.. It's very small
[14:06] <rsalveti> tvoss: yup
[14:07] <rsalveti> just ask for anyone using utouch as their personal phone
[14:07] <rsalveti> osmtouch is the map app used
[14:07] <tvoss> rsalveti, sure, that's why I'm saying we should have an automated test covering all apps
[14:08] <rsalveti> if we can automate, even better
[14:08] <cjohnston> balloons: so that user should just push a new branch?
[14:09] <sil2100> dednick: just know that there's some pressure on the real fix ;)
[14:09] <tvoss> sil2100, we have to mp's up for review
[14:10] <sil2100> tvoss: for the real fix or the hot-fix?
[14:10] <tvoss> sil2100, for the real fix
[14:10] <sil2100> tvoss: excellent..!
[14:11] <balloons> cjohnston, yes, but starting from trunk.. As far as actually fixing the issue, i'm not sure, and since the MP is so small, I don't think it's worth digging into. We might get more info by asking victor how he committed
[14:11] <cjohnston> dpm: ^
[14:19]  * tvoss looks at the topic and wonders if there is such a thing as non-forceful traincon 0
[14:20] <davmor3> sil2100 I've open most of the apps and I see no fallout from uitk
[14:26] <sil2100> tvoss: there's a timely traincon-0, one that's acting according to nature!
[14:26] <sil2100> (by acting according to nature I mean no promotion for 7 biz days)
[14:29] <dpm> balloons, cjohnston, sounds like a plan
[14:29] <pmcgowan> kenvandine, brendand any progress?
[14:29] <sil2100> davmor2: ok, is that a +1?
[14:32] <sil2100> bzoltan: do you have any progress update from zsombi on the date-time Qt regression? Will we be able to work-around it on UITK somehow?
[14:33] <tvoss> sil2100, can I get a silo for line 33 assigned?
[14:33] <Mirv> sil2100: brendand: I'm EODish, but what about the music-app? I built the bzr558 in jenkins as mentioned. shall I just upload it, or will someone do further testing on it? AP:s seemed to pass locally
[14:33] <kenvandine> pmcgowan, jibel is looking at it
[14:34] <sil2100> tvoss: \o/ Ok, so, unity8 is still migrating from -proposed, so you guys will have to rebuild once it reaches the archive
[14:34] <pmcgowan> kenvandine, good thanks
[14:34] <sil2100> Mirv: do you have the powa to publish that to the store?
[14:34] <tedg> sil2100, Can you publish silo 8 please?
[14:34] <Mirv> sil2100: there are two steps, and I have the power to do the first step of that
[14:35] <sil2100> Mirv: if you see that the AP tests passed on a local run, I guess it would be awesome to get it out
[14:35] <Mirv> sil2100: ok. Ran 17 tests in 840.159s, OK. I'll upload it then.
[14:35] <tvoss> sil2100, ack
[14:36] <sil2100> tedg: ok, this one will require a QA sign-off though before it can land, sadly
[14:36] <Mirv> sil2100: com.ubuntu.music_1.3.558_all.click uploaded, now up to popey or someone else (balloons?) to approve on the store side.
[14:37] <sil2100> Maybe dholbach can help
[14:37] <sil2100> Let me try
[14:39] <balloons> Mirv, popey is out, but daniel can approve
[14:39] <Saviq> tvoss, sil2100, FYI don't look back on silo 11 for unity8, it's still a day away or so
[14:40] <sil2100> ACK
[14:40] <Saviq> tvoss, it does look like you have a superseded branch in the silo
[14:40] <Mirv> balloons: ok, thanks
[14:42] <tvoss> Saviq, ack
[14:43] <davmor2> sil2100: yeap I can do it myself now :)
[14:44] <davmor2> sil2100: granted it :)
[14:45] <sil2100> davmor2: thanks :)
[14:45] <davmor2> sil2100: back home now it's much nicer using irc on a screen this size, the phone works but you wouldn't want it all day :)
[14:46] <davmor2> tvoss: here and location tracked me accurately all the way there on foot and all the way back in the car :)
[14:47] <tvoss> davmor2, thanks :)
[14:50] <Wellark> brendand: did you have some problem with the sim unlocking or something?
[14:53] <brendand> Wellark, i don't have any locked sims
[14:53] <Wellark> 16:31 < brendand> davmor2, did we get any ack on sim unlocking?
[14:53] <Wellark> oh, so you just wanted to verify that the sims can be unlocked?
[14:53] <Wellark> ack
[14:54] <sil2100> plars: I prepared this branch here to fix our calendar-app test issues:
[14:54] <sil2100> plars: https://code.launchpad.net/~sil2100/ubuntu-test-cases/touch-fix-address-book/+merge/229950
[14:54] <brendand> Wellark, i think davmor2 confirmed it
[14:54] <Wellark> yep, he did
[14:54] <sil2100> plars: could you take a look and see if it makes sense?
[14:54] <sil2100> plars: the bug is https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1353921
[14:55] <kenvandine> sil2100, so landing features in traincon-0, do i need to get davmor2 to check to make sure it doesn't add to the promotion blockers?
[14:55] <kenvandine> pmcgowan, i created a silo for the reset feature and a couple bug fixes
[14:55] <plars> sil2100: seems straightforward enough. Have you tried it? Want me to give it a try here before we merge it?
[14:56] <pmcgowan> kenvandine, thanks
[14:56] <sil2100> kenvandine: yes, generally we allow for 'small no-risk features' to go through without testing, but during this traincon we're generally more strict ;p
[14:56] <kenvandine> sil2100, i understand strict :)
[14:56] <kenvandine> sil2100, so i just ping davmor2 to get an ack?
[14:56] <sil2100> plars: if you could give it a quick spin then it would be great, but from what brendand mentioned this fixes the issue - but at the end of running the test suite we're removing this package, right?
[14:56] <sil2100> kenvandine: yeah, let's switch it on the spreadsheet
[14:56] <plars> sil2100: yes
[14:57]  * kenvandine does 
[14:57] <sil2100> plars: then it should be ok, but I would indeed prefer a double-check on a live system
[14:57] <sil2100> We will still have one test failure at least though
[14:58] <plars> sil2100: same here, will have results on it shortly
[15:07] <bzoltan1> sil2100: Mirv: I have just heard from mhall119 that the datepicker was working on the image 157... I am checking that
[15:08] <Wellark> ugh.. stuff from silo1 have not yet been merged ;(
[15:08] <sil2100> bzoltan1: since we might consider thinking of an application-side workaround (if possible) if hotfixing that in UITK doesn't work
[15:08] <sil2100> Wellark: no, it's still migrating...
[15:11] <sil2100> Wellark: it's still running autopkgtests
[15:11] <mhr3> sil2100, reconf 011 pls? added unity-scope-scopes
[15:11] <mhr3> Saviq, fyi ^
[15:11] <sil2100> mhr3, Saviq: sure
[15:11] <Saviq> tx
[15:11] <bzoltan1> sil2100:  I am sure that it is possible to refactor  the app
[15:13] <mhr3> Saviq, started rebuild of the scopes
[15:13] <sil2100> bzoltan1: do you think that refactoring the application would be hard to do and seem 'hacky'? Since it would be strange to push on a refactoring if the application does things 'the right way', but it simply stopped working
[15:13] <Saviq> mhr3, thanks, will need that...
[15:14] <bzoltan1> sil2100: I think it would better to make the datepicker deal with that Qt bug on the SDK side. I am sure we can provide you a fix early next week. Maybe already tomorrow.
[15:14] <bzoltan1> sil2100:  zsombi is full time on this issue
[15:15] <sil2100> uh
[15:15] <sil2100> Ok, but it seems a bit more time consuming then, all the other blockers seem to be getting resolved already
[15:15] <pmcgowan> sil2100, if calendar is the only app affected, and its not preinstalled, do we block on it?
[15:16] <sil2100> pmcgowan: it's preinstalled on ubuntu-touch devel images, isn't it?
[15:16] <pmcgowan> sil2100, I thought we removed it
[15:16] <mhall119> it used to be, I havne't heard of that changing
[15:16] <sil2100> pmcgowan: whenever I flash my phone clean it has calendar-app preinstalled, so it would be a regression if it's broken
[15:17] <pmcgowan> popey, will remember
[15:17] <pmcgowan> its not on my mako
[15:18] <bzoltan1> mhall119:  I just flashed the 157 and The datepicker does not show up in in the new event
[15:18] <mhall119> popey is out today
[15:18] <sil2100> Strange
[15:18] <mhall119> bzoltan1: is the OSK visible?
[15:18] <bzoltan1> mhall119:  it is
[15:18] <mhall119> bzoltan1: hide the OSK and you should see the picker
[15:18] <bzoltan1> mhall119:  a second...
[15:18] <bzoltan1> mhall119:  it does show up
[15:19] <bzoltan1> mhall119: but as you said the OSK might cover it
[15:19] <sil2100> davmor2: when you flash a clean image, do you have calendar-app preinstalled?
[15:19] <davmor2> sil2100: yes
[15:20] <davmor2> sil2100: 3rd icon on the top row  below the top 6
[15:20] <pmcgowan> ok my mistake then, we spoke about removing it
[15:20] <pmcgowan> I must have uninstalled it
[15:21] <bzoltan1> mhall119:  the OSK stays on top ... but if I put the app in background and bring it back I can tap on the dat field and the datepickes shows up .. that is with the rev157
[15:21] <davmor2> pmcgowan: it moved from the top 6 to under it
[15:21] <pmcgowan> well now I wish we had removed it ;)
[15:22] <davmor2> pmcgowan: but then how would you know what you were doing all day without the harps to annoy you?
[15:23] <mhall119> bzoltan1: not only does the OSK stay on top, but the Event Name field retains they keyboard focus even after the date or time elements are triggered
[15:23] <mhall119> which is, I assume, why the OSK doesn't go away when it should
[15:25] <sil2100> bzoltan1: do you have any particular ideas on how to refactor the calendar-app to work-around this? We might propose such a solution before we get the right fix
[15:25] <sil2100> bzoltan1: the calendar developer is available, so if you have any ideas we can pass them over
[15:29] <mhall119> sil2100: if the calendar app can hook into the date or time elements being triggered, it can possibly force-remove keyboard focus from other fields to try and hide the keyboard
[15:29] <brendand> sil2100, is the fix for calendar-app short term?
[15:29] <sil2100> brendand: which fix? ;)
[15:29] <brendand> sil2100, it won't fix running it locally with phablet-test-run will it?
[15:30] <brendand> sil2100, http://bazaar.launchpad.net/~sil2100/ubuntu-test-cases/touch-fix-address-book/revision/268#jenkins/testconfig.py
[15:30] <plars> sil2100, brendand: I still see one failure in calendar_app with that: http://q-jenkins.ubuntu-ci:8080/job/plars-smoke-daily-test/19/testReport/junit/calendar_app.tests.test_yearview/TestYearView/test_current_day_is_selected_with_touch_/
[15:30] <sil2100> brendand: you mean the additional dependency? No, that's a temporary fix, the real fix would be migrating to autopkgtests
[15:30] <brendand> plars, yes that's the one reported a few builds back
[15:30] <brendand> plars, because it's august now
[15:31] <brendand> plars, all you need to do is go back in time 8 days and it will work
[15:31] <sil2100> brendand: since we have no means to get dependencies pulled in when click app tests are being ran locally noramlly...
[15:31] <plars> ok, in that case, +1 for your change sil2100
[15:31] <sil2100> plars: yeah, that's known - let's merge the workaround then :)
[15:31] <sil2100> Thanks!
[15:31] <brendand> sil2100, you don't have a time machine to fix it?
[15:31] <plars> brendand: do we really have a test that needs to be updated every month?
[15:32] <sil2100> plars, brendand: ;)
[15:32] <brendand> plars, no - once it's fixed it should be fixed for good. i think elopio was working on something
[15:32] <plars> ok, cool
[15:32] <sil2100> mhall119: hmm
[15:33] <brendand> sil2100, plars - here: https://code.launchpad.net/~canonical-platform-qa/ubuntu-calendar-app/fix1351319-swipe_to_get_current_day/+merge/229356
[15:33] <brendand> sil2100, plars - it's blocked by uitk dependencies
[15:33] <sil2100> mhall119: that sounds a bit hacky, but I also don't know the exact problem details - but maybe we could indeed try that? Could you contact mihir or someone else regarding that?
[15:34] <mhall119> sil2100: bzoltan1 pmcgowan if the devel-proposed behavior of the pickerpanel is the same as the devel channel behavior, then it probably shouldn't block promotion since that wouldn't technically be a refression, right?
[15:34] <sil2100> Since I don't want us to be blocked for another few days
[15:34] <plars> sil2100: that's merged, and will be pulled in for 177
[15:34] <Saviq> tvoss, rekicked silo 4 for you (with IGNORE_MISSING_TWINS)
[15:34] <mhall119> sil2100: ideally the UITK components for date and time would take keyboard focus when activated
[15:35] <sil2100> plars: \o/
[15:35] <mhall119> sil2100: but like I said, if its not a change from r157, then it shouldn't be blocking should it?
[15:35] <sil2100> mhall119: hm, but I thought that davmor2 didn't notice it being broken in the last promoted image?
[15:35] <pmcgowan> mhall119, you're saying the bahavior is in promoted?
[15:35] <sil2100> davmor2, ogra_: is callendar broken in the last promoted image? :/
[15:35] <mhall119> pmcgowan: the picker being hidden by the OSK is in r157, yes
[15:36] <plars> sil2100: what about camera?
[15:36] <alecu> hi trainguards: What are the steps to get the QA sign off needed on some silos? should we chase the QA people to do it, or do you guys handle that too?
[15:36] <mhall119> if that's the behavior being seen in devel-proposed, then there is no change
[15:36] <kenvandine> davmor2,  silo 17 is ready to land, it should be safe.  just adds a property that nothing else is using yet, but blocking work in camera and gallery
[15:36] <ogra_> sil2100, havent used that in a while, but i think it worked
[15:36] <sil2100> mhall119: but it's usable, right? As currently you cannot add any events at all
[15:36] <kenvandine> sil2100, ^^
[15:36] <mhall119> if something different is happening in devel-proposed, then it's a regression
[15:36] <mhall119> sil2100: r157 is usable, you just have to hide the keyboard manually
[15:36] <mhall119> so, "usable but not great"
[15:37] <kenvandine> oh, and it's needed for the test peer i'm working on for QA :)
[15:37] <sil2100> mhall119: ok, then it's a bit more broken, since now you can't set the date at all
[15:37] <mhall119> bzoltan1: can you confirm or deny that devel and devel-proposed are experiencing the same problem?
[15:37] <davmor2> sil2100: no in promoted the behaviour is that the date time appears behind the keyboard if a text field is highlighted.  However in proposed it just doesn't show or it shows under the app
[15:37] <sil2100> mhall119: on my #172 for instance the date picker does not appear at all
[15:37] <mhall119> sil2100: ah, ok, that is a regression then
[15:38] <tvoss> Saviq, thank you
[15:38] <robru> alecu, yeah, poke om26er or ToyKeeper for that review
[15:38] <alecu> robru: great, thanks
[15:38] <robru> alecu, you're welcome
[15:38] <sil2100> alecu: usually QA people also scan the spreadsheet themselves when it's marked 'needs QA signoff'
[15:38] <alecu> tedg: ^^^
[15:39] <om26er> alecu, robru I can look into that in 15mins if thats fine ?
[15:39] <alecu> om26er: great, thanks. it's silo-008 with pay-service
[15:39] <bzoltan1> mhall119:  the rev165 has the same problem in a different way... when you create an event the focus is on the text input so the text OSK comes up. But changing the focus to the date field does not hide the text OSK and does not bring the up the date picker. When the app is put in bckground the OSK hides and when itis pulled back and the date field is focused then the date picker comes up.
[15:40] <bzoltan1> mhall119:  on 176 the date picker never comes up
[15:40] <mhall119> thanks bzoltan1
[15:40] <bzoltan1> mhall119:  I am flashing the rev165 ... binary search rulez
[15:41] <mhall119> bzoltan1: so was r165 the last image where the picker comes up at all?
[15:41] <bzoltan1> mhall119: sil2100: question.. does this problem exist on emulator
[15:41] <sil2100> bzoltan1: hm, not sure, it's a problem on at least a few of our supported devices, not sure about the emulator
[15:42] <sil2100> At least 2 platforms are affected
[15:42] <bzoltan1> sil2100:  I am creating now few emulators
[15:42] <sil2100> Ok, unity8 should be migrating pretty soon
[15:44] <mhall119> bzoltan1: don't know, I created a new emulator this morning but it's stuck at a black screen :(
[15:55] <Mirv> mhall119: bzoltan1: I quickly joined the reflashing party, and r173 seems to be also similar to 176, ie. the r165 trick doesn't work
[15:59] <sil2100> I have 172 on my other device and it's b0rken there as well
[16:00] <bzoltan1> mhall119: Mirv: sil2100: the 165 is as busted as the 176 from the point of calendar
[16:00] <sil2100> bzoltan1: no picker appearing, that is?
[16:03] <sil2100> robru: meeting!
[16:04] <robru> sil2100, sorry, hangouts plugin broke, had to restart
[16:09] <nik90> mhall119: which channel did you choose for the emulator?
[16:09] <nik90> mhall119: afaik only emulator >175 work without the black screen issue
[16:10] <imgbot> [16:11] <nik90> mhall119: sry >176
[16:11] <nik90> mhall119: confirmed by rsalveti
[16:15] <bzoltan1> sil2100:  exactly
[16:16] <bzoltan1> sil2100:  rev161 no picker
[16:17] <davmor2> Kaleo, tvoss: re: camera app.  Why is location requested before the app starts when location in camera settings defaults to off?
[16:18] <davmor2> sil2100: ^ here is the chat to follow :)
[16:18] <Kaleo> davmor2, is it really the cse?
[16:18] <davmor2> Kaleo: yes
[16:18] <mhall119> nik90: devel, so r157
[16:18] <mhall119> I used to have r119 that worked
[16:18] <Kaleo> davmor2, so, no good reason, it's a bug
[16:19] <nik90> mhall119: 157 was broken as well for me the last time I checked. The emulator images have been through a rough time
[16:19] <mhall119> nik90: ok, I'll make one with devel-proposed
[16:19] <Kaleo> davmor2, maybe a bug in camera or in our QtPositioning plugin
[16:20] <davmor2> Kaleo: in that case when you turn on location in settings the window would exist and location service could be selected correctly :)
[16:20] <davmor2> hmm could be
[16:20] <Kaleo> davmor2, yes  although from a UX standpoint that window shoulds not even show at that point
[16:20] <Kaleo> -s
[16:21] <davmor2> Kaleo: hmm true
[16:21] <tvoss> davmor2, Kaleo I think the one-time prompt is still fine
[16:22] <davmor2> tvoss: oh yes being asked once can I add this app to location service I don't think is a hardship
[16:22] <davmor2> Kaleo: this is a one time ask per app
[16:23] <Kaleo> davmor2, I see
[16:23] <Kaleo> still an ugly regression for the camera
[16:23] <Kaleo> and not seen in any other OS
[16:24] <tvoss> Kaleo, well, prompting the user for trust when the access happens is certainly better than just displaying a list of permission requests on app installation
[16:25] <davmor2> Kaleo: do we see trusted helpers in other os's?
[16:26] <Kaleo> davmor2, tvoss, point is, if the user says: "location" please by tapping the camera location on button, it makes no sense to have an extra popup
[16:27] <tvoss> Kaleo, sure, and I agree with that. But we have no good way of knowing what the user wants at that point, with the assumption that the app is evil, obviously
[16:27] <Kaleo> davmor2, it probably does for other apps that might be not telling you they are trying to access the GPS
[16:27] <Kaleo> but for an app we write part of the default OS, not really
[16:27] <tvoss> Kaleo, then it should be unconfined and you won't see a prompt
[16:27] <tvoss> jdstrand, ^
[16:28] <Kaleo> tvoss, it is a trusted app, let's say
[16:28] <Kaleo> since I wrote it :)
[16:28] <tvoss> Kaleo, which means unconfined in terms of profiles
[16:28] <Kaleo> tvoss, can it still be click?
[16:28] <Kaleo> please say yes
[16:28] <tvoss> Kaleo, not sure, would think so
[16:29] <Kaleo> then that sounds like a fair deal
[16:30] <Kaleo> maybe making the UI of the trusted helper less annoying/ugly/invasive would help also for 3rd party apps
[16:30] <tvoss> Kaleo, well, beautifying it is the next step. But it's invasive on purpose :)
[16:30] <tvoss> Kaleo, and it's happening only once
[16:30] <Kaleo> tvoss, one time experiences must be beautiful :)
[16:31] <tvoss> Kaleo, feel free ;)
[16:31] <Kaleo> tvoss, ;)
[16:32] <bzoltan1> sil2100: mhall119: the rev 159 is busted too
[16:33] <mhall119> so 158 or 159 introduced the regression
[16:34] <Mirv> 159 was no-op http://people.canonical.com/~ogra/touch-image-stats/159.changes, so 158 it is http://people.canonical.com/~ogra/touch-image-stats/158.changes
[16:34] <om26er> alecu, does testing pay-service mean I need to perform a real purchase ?
[16:34] <Mirv> there was a Mir related input fix that might be it:
[16:35] <Mirv> https://code.launchpad.net/~andreas-pokorny/mir/fix-1346952-0.5/+merge/228098
[16:35] <alecu> om26er: purchases are only enabled on the staging server for now, so you don't need a real credit card
[16:35] <bzoltan1> mhall119:  I am flashing the 158
[16:35] <alecu> om26er: the testplan has details on how to setup a fake card
[16:35] <Mirv> so if the "working" of date/time picker relied on the ability to be racy in some way, and now that it was prevented the hiding of keyboard doesn't bring it back anymore
[16:35] <om26er> alecu, ok, thanks
[16:36] <alecu> om26er: also, the testing of purchases is hidden behind a switch, so normal users would not see apps with prices just yet
[16:37] <bzoltan1> Mirv: zsombi mumbled something about that actually it was a bug that it worked before
[16:38] <alecu> om26er: the plan for the beta is to have some volunteers of the second wave of testers (18/8) running a script that will enable the purchase of some apps in production, and with real credit cards.
[16:38] <Mirv> bzoltan1: yes, and it might be that the bug was fixed by mir, thus "breaking" calendar that accidentally semi-worked before
[16:39] <bzoltan1> Mirv: Wunderbar
[16:42] <sil2100> bzoltan1: do you think it would be possible to have this fixed in UITK for tomorrow?
[16:43] <bzoltan1> sil2100:  I can not promise. zsombi said that fo rthe ultimate solution he need to refactor the datepicker in C++ or in JS. the JS would be faster to deliver but it will be less performant... b
[16:43] <bzoltan1> sil2100:  but the main thing is that most likely we cought the problem
[16:44] <bzoltan1> sil2100: between rev157-158 it was this https://code.launchpad.net/~andreas-pokorny/mir/fix-1346952-0.5/+merge/228098
[16:45] <bzoltan1> sil2100: read what Mirv wrote ^^^^^
[16:45] <sil2100> tvoss: how's the camera-app-and-not-only qtmir fix going?
[16:45] <Mirv> bzoltan1: just wait a sec, I'm just checking it for real
[16:45] <Mirv> by downgrading only that
[16:45] <tvoss> sil2100, resolving a build issue in the silo
[16:45] <bzoltan1> Mirv:  OK, I am flashing the 158 in th meantime ... booting already
[16:46] <sil2100> bzoltan1: you think this fix caused the regression?
[16:47] <bzoltan1> sil2100:  in few minutes we can tell
[16:47] <bzoltan1> sil2100: Mirv: the rev158 is as busted as rev176
[16:48] <Mirv> bzoltan1: sil2100: mhall119: news flash. #158 is broken (bzoltan will give 2nd confirmation in a minute), but downgrading mir to what #157 had does _not_ see to solve problem for me. so, something else in http://people.canonical.com/~ogra/touch-image-stats/158.changes but not mir!
[16:48] <sil2100> Oh!
[16:48] <bzoltan1> Mirv: I can confirm that the  #158 is broken
[16:49] <sil2100> http://people.canonical.com/~lzemczak/landing-team/158.commitlog <- looking here the only thing landing from 'our' side was the QtCompositor
[16:50]  * robru -> lunch
[16:50] <rsalveti> lol, google is giving me -ebusy when opening the spreadsheet
[16:51] <rsalveti> boiko: mind if I land the approver crash separately?
[16:51] <rsalveti> boiko: that can land easily even with trainco-0
[16:52] <rsalveti> as it's just a bugfix
[16:52] <boiko> rsalveti: sure, that's fine
[16:53] <rsalveti> boiko: guess we can land the fixes and then the tone generator support separately
[16:54] <boiko> rsalveti: yep, there are two crash fixes in there, want me to create a separate silo for those?
[16:54] <rsalveti> boiko: let me do it, trying to get a free silo first
[16:55] <rsalveti> Kaleo: jhodapp: we have 2 silos for qtubuntu-camera changes
[16:55] <rsalveti> Kaleo: jhodapp: we want to land camera-recording today still, so can I free silo 12?
[16:55] <boiko> rsalveti: ok, thanks
[16:55] <rsalveti> or do we want to land Kaleo's changes first?
[16:55] <rsalveti> like, now :-)
[16:56] <rsalveti> that's fine as well
[16:57] <rsalveti> minor fix, Kaleo's changes can land fist
[16:58] <Kaleo> rsalveti, I have  changes?
[16:58] <rsalveti> Kaleo: silo 12
[16:58] <rsalveti> Kaleo: https://code.launchpad.net/~fboucault/qtubuntu-camera/ensure_directories_exist/+merge/229106
[16:58] <Kaleo> ah yes
[16:58] <ogra_> Kaleo, to late, you are already landing now
[16:58] <ogra_> :)
[16:58] <Kaleo> :)
[16:58] <rsalveti> let's land this
[16:58] <Kaleo> good
[16:58] <ogra_> should we seed Kaleo too after his fixes landed ?
[16:58] <ogra_> :)
[16:59] <rsalveti> might get stuck in proposed though
[16:59] <Kaleo> I don't like flying
[16:59] <sil2100> bzoltan1: argh ;p https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/sync_landing_0608/+merge/229827 needs approval ;)
[16:59] <rsalveti> sil2100: done
[16:59] <sil2100> uh oh!
[16:59] <sil2100> What a fast review ;)
[16:59] <sil2100> ;p
[17:00] <sil2100> j/k
[17:00] <rsalveti> really simple one
[17:00] <rsalveti> no packaging changes in the original mr
[17:00] <rsalveti> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/landing-06-08/+merge/229826
[17:03] <rsalveti> sil2100: mind getting me a silo for line 37? quick bug-fix one
[17:03] <rsalveti> only one silo remaining but you just landed ui-toolkit
[17:03] <rsalveti> and I'm landing another camera-fix in a minute
[17:04] <Mirv> bzoltan1: sil2100 mhall119: reverting the whole Qt Compositor landing from #158 to their #157 versions (including removal of those new packages and adding unity-mir back) fixes calendar
[17:04] <sil2100> Mirv: *sigh*
[17:04] <Mirv> so there you have it
[17:04] <sil2100> Mirv: thanks!
[17:04] <Mirv> no problem, too bad there's nothing simple to fix :(
[17:05] <sil2100> :|
[17:05]  * Mirv back to eod
[17:05] <mhall119> thanks Mirv
[17:07] <pmcgowan> so now what
[17:07] <rsalveti> pmcgowan: what's up?
[17:07] <pmcgowan> just reading backlog about the calendar issue
[17:07] <olli> I guess Unity/Mir will look into that
[17:07] <rsalveti> oh, ok
[17:07] <olli> Saviq, ^
[17:09] <olli> hey greyback
[17:10] <greyback> olli: hi
[17:10] <olli> Mirv, found that .... <Mirv> bzoltan1: sil2100 mhall119: reverting the whole Qt Compositor landing from #158 to their #157 versions (including removal of those new packages and adding unity-mir back) fixes calendar
[17:11] <alecu> om26er: did you have any luck with the purchase testing? let me know if I can help with any questions you might have.
[17:11] <olli> greyback, any thoughts?
[17:11] <om26er> alecu, I am waiting the 10 minutes for the token to expire
[17:11] <pmcgowan> olli, acc to bzoltan1 we can fix it on the sdk side, but might take a bit
[17:11] <olli> greyback, https://bugs.launchpad.net/bugs/1351024 that's the bug in question
[17:12] <greyback> olli: seems rather heavy-handed. QtComp been landed over a week, how is it noticed calendar broken only now?
[17:12] <ogra_> greyback, dues to a week without any proper test results caused by other issues
[17:12] <olli> greyback, in all fairness, the bug is from 7/31
[17:13] <ogra_> greyback, one could also ask, how could it land without being noticed though ...
[17:13] <olli> I guess nobody regressed down to 157/158 until now
[17:13] <ogra_> sh*t happens is the answer i guess :)
[17:13] <olli> was just about to say
[17:13] <pmcgowan> murphy hard at work
[17:13] <olli> I think we agree that reverting qtcomp would be bad
[17:13] <ogra_> yeah, murphy had a busy week :)
[17:13] <greyback> olli: it's the first I've seen of that bug. Having some time to dig into it would be nice, as opposed to immediately reverting
[17:13] <olli> greyback, ack
[17:14] <pmcgowan> yeah, a broken calendar is better than a revert
[17:14] <olli> I guess that's what I am proposing to sil2100 et al...
[17:14] <olli> sil2100, is it feasible for greyback to get until tomorrow AM to look into that and then make a decision
[17:15] <ogra_> we wont promote anything before tomorrow morning (EU TZ)
[17:15] <ogra_> or even consider promotion
[17:15] <plars> slangasek: I hear you need something for that whoopsie test failure? I can reproduce it on any device in the lab, and at home
[17:16] <olli> ogra_, bien
[17:16] <ogra_> olli, which means greyback has that time ;)
[17:17] <olli> love it how things come together naturally
[17:17] <bzoltan1> pmcgowan: I called zsombi. He will make a C++ wrapper for the pickerpanel tomorrow to avoid the whole problem. He will send the MR tomorrow.
[17:18] <pmcgowan> olli, ^^
[17:18] <bzoltan1> greyback: so nobody reverts nothing, understood? :)
[17:19] <ogra_> lol
[17:19] <olli> k, still good for greyback to look into the root cause
[17:19] <ogra_> on ubuntu thats not a root cause ... its a sudo cause
[17:19] <ogra_> ;)
[17:19] <pmcgowan> omg so bad
[17:19] <pmcgowan> lol
[17:19] <bzoltan1> olli:  sure, that is the best. But to be confident we will fix that bloody calendar.
[17:19] <ogra_> *g*
[17:19] <olli> ogra_, ...
[17:20] <greyback> l
[17:20] <bzoltan1> ogra_:  that was good :D
[17:20] <olli> our comic relief ogra_
[17:20] <olli> I'll send you a jester hat
[17:20] <ogra_> i got one already !
[17:24] <sil2100> olli, ogra_, greyback: right, we don't promote anything till tomorrow anyway, we're blocked on another blocker as well still
[17:24] <sil2100> But the plan would be to have something for tomorrow
[17:24] <sil2100> One of the other ways is to actually apply a workaround in calendar-app itself
[17:24] <greyback> sil2100: which blocker is that btw?
[17:25] <sil2100> greyback: https://bugs.launchpad.net/bugs/1351024
[17:25] <sil2100> Ah
[17:25] <sil2100> greyback: you mean the other blocker?
[17:25] <greyback> the other blocker
[17:26] <sil2100> greyback: it's this: https://bugs.launchpad.net/camera-app/+bug/1353956
[17:26] <greyback> sil2100: ack
[17:26] <tvoss> greyback, it's caused by the same issue that is affecting osmtouch
[17:26] <sil2100> greyback: which is caused by https://bugs.launchpad.net/qtmir/+bug/1352977 actually... and I guess tvoss and dednick are actually trying to fix the root cause
[17:27] <greyback> tvoss: sil2100: ack
[17:27] <om26er> alecu, I am failing to understand, whats the main issue/feature this branch adds ? is that the 10 minutes wait expiry of the token ?
[17:27] <tvoss> sil2100, in case we need it: https://code.launchpad.net/~thomas-voss/location-service/hot-fix-for-camera-app-and-osmtouch/+merge/229975
[17:27] <Wellark> hmm.. this was in silo 1 with unity8 branches
[17:27] <Wellark> https://code.launchpad.net/~unity-api-team/indicator-network/modeminfo
[17:27] <om26er> alecu, also is there any other paid app than delta ?
[17:27] <Wellark> the unity8 branches got merged but that did not
[17:28] <Wellark> any idea what could be causing that?
[17:28] <ogra_> Wellark, not gotten out of -proposed yet perhaps ?
[17:28] <Wellark> oh. ok.
[17:28] <alecu> om26er: the other apps with prices are: qr code, tv stalker, evil app.
[17:28] <ogra_> Wellark, hmm, no, looks like it migrated a while ago
[17:29] <pmcgowan> any QA around to bless silo 10?
[17:29] <Wellark> ogra_: ok. if it was just a while ago maybe the merger has not ran yet
[17:29] <ogra_> yeah
[17:29] <ogra_> could be
[17:29] <alecu> om26er: this branch adds opening the pay dialogs in a trusted prompt session. It previously was shown as a separate app that would be launched with the "Pay UI" title
[17:29] <sil2100> tvoss: excellent! Let's keep that as a fail-safe in case the actual fix has issues, I would prefer the correct fix but we might decide tomorrow that we want this in instead
[17:29] <sil2100> tvoss: thanks for all your hard work!
[17:29] <alecu> om26er: and that pay ui app would show up on the list of open apps, and it could be closed
[17:29] <tvoss> sil2100, sure, happy to help
[17:30] <sil2100> bzoltan1: you as well, thanks for all your involvement!
[17:30] <alecu> om26er: with this branch, it's shown inside the dash
[17:30] <sil2100> You guys rock
[17:30] <ogra_> yeah
[17:31] <pmcgowan> sil2100, which QA is on duty for blessing silos?
[17:31] <ogra_> whom ever you can grab :)
[17:31] <sil2100> pmcgowan: in the US timezone it's usually ToyKeeper
[17:31] <sil2100> She's the 'designated person' usually
[17:31] <tvoss> balloons, so I'm digging into the date time picker issue, too. The bug points to https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1328600, preventing automating testing of the functionality
[17:31] <sil2100> I mean usually, as I don't know if she's up already
[17:31] <ToyKeeper> om26er should still be around for a little while too.  I *just* woke up.
[17:32] <kenvandine> i'd like a QA ack for silo 17 as well :)
[17:32] <balloons> tvoss, yes, I have an MP to fix the autopilot side of the bug, I simply need to finish it
[17:32] <balloons> needs some more tests :-)
[17:32] <pmcgowan> om26er, ToyKeeper silo 10 ack?
[17:32] <tvoss> balloons, okay, could you link the branch on the bug report, please?
[17:33] <balloons> tvoss, it's there
[17:33] <tvoss> balloons, oh sorry, yeah, seeing it now
[17:33] <balloons> I updated the status properly though
[17:34] <om26er> alecu, when I purchase an app it never installs it automatically. the app is purchased but the label is not updated i.e. the button keeps showing the price. I have to go back and close the Ubuntu Store and when I come back I see the 'install' button
[17:34] <om26er> so I assume the silo was not tested by anyone ?
[17:35] <sil2100> The lander needs to test the silo
[17:35] <alecu> om26er: both tedg and I tested the silo yesterday
[17:35] <sil2100> ToyKeeper: good morning then! Have some coffee and breakfast in the meantime then ;)
[17:35] <om26er> pmcgowan, I can do that once's I am done with 008
[17:35] <pmcgowan> om26er, thanks much
[17:35] <balloons> tvoss, on the bug zsombi differentiates between the datepicker and the picker panel. I found the fact the existing tests work odd
[17:36] <kenvandine> om26er, and 17 if you have a chance? it should be pretty easy
[17:36] <om26er> alecu, then I guess I have found a bug. testcase: 'pay-service/purchase-application' https://wiki.ubuntu.com/Process/Merges/TestPlan/pay-service fails
[17:36] <pmcgowan> kenvandine, can we queue up the rest of jgdx's stuff ?
[17:37] <kenvandine> pmcgowan, trying to
[17:37] <pmcgowan> ok I will leave you to it
[17:37] <ToyKeeper> om26er: Do you know how to get push notifications working for social media on Touch?
[17:37] <kenvandine> i kicked CI
[17:37] <alecu> tedg: it seems that we've not updated the test plan with the need to restart the pay-service
[17:37] <alecu> om26er: I'm sorry, we've forgot to add an interim step to the test plan, to work around a known bug
[17:37] <ToyKeeper> om26er: I tried the obvious things with no luck...  like attaching an account, logging in, generating events to be notified about...  but all I got was crickets.
[17:37] <om26er> ToyKeeper, been trying to get that working but never worked for me, I did however see a mail notification from gmail.
[17:38] <alecu> om26er: I'm adding it now, with a link to the bug, and will ping you in a minute.
[17:38] <ToyKeeper> I failed at testing a change to it because I couldn't get it working with or without the silo.
[17:38] <om26er> alecu, ok, thanks.
[17:39] <ToyKeeper> For personal use, I think no-facebook-notifications is actually a feature, not a bug.  But that's just me.
[17:40] <tvoss> davmor2, https://wiki.ubuntu.com/Process/Merges/TestPlan/location-service#preview
[17:40] <tvoss> sil2100, ^
[17:46] <alecu> om26er: I've added the extra step (running restart pay-service) to the testplan: https://wiki.ubuntu.com/Process/Merges/TestPlan/pay-service
[17:47] <om26er> alecu, ok
[17:55] <imgbot> [17:55] <imgbot> [17:55] <ToyKeeper> Woot, was waiting for that.
[17:55] <sil2100> tvoss: oh, thanks :)
[18:00] <om26er> alecu, the 'NO ACCOUNT' part of the test plan is not upto date. Whats written there is not exactly what I am seeing
[18:02] <alecu> om26er: gatox do you know what's the status of the 'NO ACCOUNT' part of the testplan?
[18:02] <alecu> gatox: https://wiki.ubuntu.com/Process/Merges/TestPlan/pay-service
[18:03] <gatox> om26er, what are you seeing?
[18:04] <alecu> om26er: (for this landing we've only been testing pay-service, not pay-ui. The testplan for pay-ui is very new, and probably only gatox has written and followed it completely)
[18:05] <gatox> alecu, om26er i wrote the test plan while i was actually testing that...
[18:05] <om26er> alecu, gatox the part which says 'Verify the Payment page is shown.' the payment dialog does not appear
[18:06] <gatox> om26er, alecu i assume that's the same issue i was having with trsuted sessions here after adding the ppa8
[18:06] <om26er> gatox, alecu not sure here, was it working previously ? i.e. before this change ? asking as I dont want things to regress.
[18:07] <gatox> alecu, i mentioned yesterday that after online accounts i was back in the dash and payui was not opened
[18:07] <gatox> alecu, but it was after adding ppa8
[18:07] <gatox> which doesn't include any changes in payui... just in pay-servce and trusted sessions
[18:10] <alecu> gatox: that was before ted's fixes to the branch. Can you try with what's currently on silo 8?
[18:11] <gatox> alecu, i'm trying... i'll test that in a while... trying to get unity8 to build here
[18:11] <alecu> tedg: can you verify what om26er found?
[18:30] <om26er> kenvandine, hey! the test plan for system-settings needs love. you need to add some manual tests for resetting the phone here: https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-settings
[18:31] <kenvandine> om26er, jgdx is doing that
[18:31] <kenvandine> om26er, sorry it's a bit outdated
[18:31] <robru> ToyKeeper, hey, any chance I can get QA signoff for silos 10, 17, and 20
[18:31] <kenvandine> robru, om26er's question just now was irt 10
[18:32] <kenvandine> robru, he's looking at that one
[18:32] <robru> kenvandine, oh ok. anything I can do to help?
[18:32] <kenvandine> i'm still anxious for sile 17 :)
[18:32] <kenvandine> silo even
[18:35] <tedg> robru, If I drop an MR, do I need a reconfigure?
[18:35] <robru> tedg, yes, but you should be able to do it yourself
[18:35] <tedg> robru, Ah, okay.
[18:36] <tedg> om26er, I'm a bit confused from the backlog. Are you saying the price didn't switch to "Install" after purchasing?
[18:38] <om26er> tedg, with no account added, I tried to purchase an app, it added my account and I came back to the Dash instead of a pay dialog.
[18:38] <tedg> om26er, Ah, yes. That's a known bug, not a regression. There's a fix in queue for that.
[18:39] <om26er> tedg, but gatox says thats working without the ppa
[18:39] <gatox> om26er, tedg alecu i think what the problem is
[18:39] <ToyKeeper> robru: Sure, it'll just take a little while...
[18:40] <robru> ToyKeeper, no worries ;-)
[18:40] <tedg> om26er, bug 1348231
[18:40] <robru> ToyKeeper, i guess om26er is doing 10, so if you can 17 or 20
[18:40] <ToyKeeper> BTW, image 177 has a fun error...  on the welcome tutorial, start by sliding from the right and then...  the screen just stays black except for the indicators!
[18:41] <gatox> om26er, alecu tedg if you press the button with the price in the dash (now it takes a while to open any ui),  so, after a while online accounts is started..... if you enter your user+pass and everything is ok, after that pay-ui is opened..... but if you press the button with the price and you think nothing is going on and you keep pressing that button until something opens, when online accounts is closed, you are back in the preview and
[18:41] <gatox> although pay-ui seems to be open, you can't see it
[18:41] <gatox> (and also the preview seems to be unresponsive, probably because it's behind a trusted session dialog that you can not see)
[18:43] <gatox> om26er, alecu tedg my unity8 branch should get rid off that.... but i need to be able to test it locally first and i was having issues building it (it's already in launchpad)... i'll keep working on that
[18:43] <ToyKeeper> Okay, looks like first boot only or maybe a race condition.
[18:43] <om26er> tedg, that's probably could be related given we are adding a new account.
[18:44] <alecu> gatox: I think this should be fixed also with ted's fix for the pay-service branch
[18:44] <gatox> alecu, sure
[18:45] <alecu> so, tedg: should you go ahead and add your branch with this fix to the silo?
[18:46] <tedg> alecu, Well, I think someone should review it first :-)
[18:46] <alecu> tedg: seems the CI jenkins is not building that branch yet, so I guess I can review it by using the packages from the silo
[18:47] <tedg> Not sure what's up with Jenkins there.
[18:48] <tedg> alecu, Sure, now that robru told me I can reconfigure, I'm all powerful.
[18:48] <robru> tedg, you can only reconfigure as long as you don't add any new source packages. it's been that way for a while
[18:48] <tedg> robru, You've been hiding my powers from me.
[18:49]  * tedg feels like there should be a good xmen reference here, but can't find it.
[18:54] <sil2100> Ok, time for me to EOD finally
[18:54] <sil2100> See you tomorrow o/
[19:00]  * popey looks in
[19:14] <om26er> kenvandine, two of the autopilot tests are failing http://paste.ubuntu.com/7982146/ they are not really related to this MR.
[19:14] <om26er> now if the TestPlan is updated to include the reset, this silo is ready to land
[19:14] <kenvandine> jgdx, ^^
[19:14] <kenvandine> om26er, i expected more failures than that :)
[19:15] <kenvandine> i guess my depends fix really fixed the otto problems :)
[19:15] <kenvandine> yaya
[19:15] <kenvandine> we had all 32 cellular tests failing for everything
[19:15] <om26er> kenvandine, but those failures are on my phone.
[19:15] <kenvandine> i think this failure happens when there is an update available, the ui scrolls
[19:15] <kenvandine> ah... so doesn't prove otto is fixed :/
[19:16] <om26er> kenvandine, so I gave a QA +1
[19:16] <kenvandine> om26er, just want th test plan updated before publishing?
[19:16] <kenvandine> om26er, out of curiousity, do you have updates available on your phone?
[19:17] <om26er> kenvandine, yes there is a pending update
[19:17] <kenvandine> yeah, ok
[19:17] <kenvandine> thanks
[19:17] <om26er> kenvandine, and yes, please update the TestPlan.
[19:17] <kenvandine> we'll get it done
[19:18]  * om26er brb
[19:20] <rsalveti> kenvandine: can we publish silo 10 then?
[19:20] <kenvandine> we can, i'm adding the test plan right now...
[19:20] <kenvandine> it won't get forgotten :)
[19:20] <kenvandine> jgdx, ^^ i'll add it
[19:20] <rsalveti> great
[19:21] <Wellark> any change of getting these in during traincon0 ?
[19:21] <Wellark> https://code.launchpad.net/~unity-api-team/indicator-network/modeminfo/+merge/229992
[19:21] <rsalveti> tvoss: can you change https://code.launchpad.net/~thomas-voss/location-service/hot-fix-for-camera-app-and-osmtouch/+merge/229975 to avoid including the version id in the app string?
[19:21] <Wellark> it's two commits that did not make it to the landing today
[19:22] <rsalveti> tvoss: otherwise next camera-app upload will break your hack
[19:22] <Wellark> of silo 1
[19:23] <Wellark> robru: should I request a silo? --^
[19:24] <Wellark> don't want to take one if there is no chance of landing
[19:24] <robru> Wellark, request away! there aren't any to be had, though. ;-)
[19:24] <Wellark> ok. that resolves it then
[19:31] <robru> om26er, ToyKeeper qa signoff in silo 8 please ;-) ^
[19:31] <kenvandine> om26er, test plan updated
[19:37] <Saviq> tvoss, you still have a MP that's marked superseded in silo 4
[19:37] <Saviq> tvoss, https://code.launchpad.net/~nick-dedekind/unity8/lp1352977/+merge/229943 vs. https://code.launchpad.net/~nick-dedekind/unity8/lp1352977/+merge/229945
[19:38] <Saviq> it shouldn't matter much any more since the superseded's prerequisite got merged by now, still that's the MP status
[19:40] <ToyKeeper> kenvandine: silo 017 approved
[19:40] <kenvandine> ToyKeeper, thx!
[20:04] <tvoss> Saviq, spreadsheet shows the new one ...
[20:04] <tvoss> Saviq, reconfigured
[20:13] <rsalveti> tvoss: are you still working on https://code.launchpad.net/~thomas-voss/location-service/hot-fix-for-camera-app-and-osmtouch/+merge/229975
[20:13] <rsalveti> tvoss: tested with latest image and still didn't work for me
[20:20] <sergiusens> webchat ftw
[20:21] <sergiusens> ogra_: rsalveti  do you know anything about my landing?
[20:21] <rsalveti> sergiusens: hey
[20:21] <rsalveti> sergiusens: which landing?
[20:21] <sergiusens> rsalveti: ciborium
[20:21] <sergiusens> rsalveti: http://people.canonical.com/~platform/citrain_dashboard/#?q=ciborium
[20:21] <rsalveti> sergiusens: waiting qa
[20:21] <rsalveti> ToyKeeper: can you take that one?
[20:21] <rsalveti> silo 20
[20:21] <sergiusens> I'm seeing many things land without QA signoff
[20:22] <sergiusens> this is irritating
[20:22] <ToyKeeper> rsalveti: Already did.  Or tried, anyway.
[20:22] <rsalveti> ToyKeeper: +1, 0 or -1? :-)
[20:22] <ToyKeeper> sergiusens: There's no test plan for either component in that silo, and I couldn't get them to work with or without the silo...  so, no useful test result.
[20:22] <rsalveti> then 0
[20:23] <ToyKeeper> sergiusens: I think om26er tried it too, and also couldn't get the functions to work.
[20:23] <sergiusens> ToyKeeper: if they don't regress, that should be good enough; I also added a testplan for ciborium
[20:23] <sergiusens> it's in the silo information
[20:23] <rsalveti> sergiusens: it seems it's not there
[20:23] <rsalveti> sergiusens: have the link?
[20:23] <ToyKeeper> I did at least see it automount, but that's about it.  Didn't see any UI of any sort for it, or see it visibly exposed anywhere for use.
[20:24] <tvoss> rsalveti, nope, just looking at silo 4
[20:24] <rsalveti> ToyKeeper: yeah, that's kind of all it does atm
[20:24] <sergiusens> ToyKeeper: no; this is a building block for everything else to start working
[20:24] <sergiusens> traincon 0 means no regressions
[20:24] <ToyKeeper> sergiusens: So, ciborium at least looks good.  The social media push notifications didn't seem to work either way.
[20:24] <sergiusens> https://wiki.ubuntu.com/Process/Merges/TestPlans/ciborium
[20:25] <sergiusens> ToyKeeper: that's weird as many people are using it now
[20:25] <rsalveti> tvoss: ok, would like to have the workaround landing for the next image
[20:25] <ToyKeeper> Presumably, the social media notifications work if configured correctly, but nothing I tried worked.
[20:26] <ToyKeeper> sergiusens: Oh, er, there was no visual indication that the device was mounted.  Just the log entries and I verified via a shell that it was there.
[20:26] <slangasek> plars: ok, I was unable to reproduce the failure.  Can you get me remote access to a reproducer environment?
[20:27] <sergiusens> ToyKeeper: visual indication is only possible if insertion is done after boot, not prior
[20:27] <ToyKeeper> I tried it before and after boot.
[20:27] <sergiusens> ToyKeeper: logs?
[20:28] <ToyKeeper> sergiusens: Yes, it showed up in the logs...  just not onscreen.
[20:28] <sergiusens> ToyKeeper: do other notifications show up?
[20:28] <plars> slangasek: sure, or if you have a mako connected to your system, I can show you how. How are you trying to reproduce it?
[20:29] <ToyKeeper> sergiusens: Yes, things like incoming calls/text work.
[20:29] <slangasek> plars: I have tested on my mako and not encountered the behavior shown on the dashboard - please give me remote access to the environment where it's been reproduced :)
[20:29] <sergiusens> ToyKeeper: what about push notifications for image upgrades?
[20:29] <ToyKeeper> sergiusens: No idea; that's hard to test on demand.
[20:30] <ToyKeeper> sergiusens: I don't think I've ever actually seen a push notification for a new image...  but then, I usually reflash like 5 times a day.
[20:30] <sergiusens> ogra_: do you get notifications when you add the device?
[20:31] <plars> slangasek: sure, one moment
[20:31] <sergiusens> I'll just wait for traincon to end and take some time off
[20:33] <ToyKeeper> sergiusens: I didn't see anything new break, so if that's the criteria then I guess it should be approved.
[20:33] <ToyKeeper> But it was more of a null result for account-polld.
[20:34] <ToyKeeper> sergiusens: Not sure what the issue was last night, but re-testing ciborium today I see the notifications as expected.
[20:34] <ToyKeeper> (even at boot)
[20:34] <rsalveti> great
[20:34] <rsalveti> guess we can land this silo then
[20:34] <rsalveti> ToyKeeper: +1?
[20:35] <ToyKeeper> rsalveti: Well, it's not a -1...  but if you're okay landing with a null result on account-polld, then sure.
[20:35] <rsalveti> sure, I approved both mrs
[20:36] <rsalveti> let me land then
[20:36] <sergiusens> ToyKeeper: can you show me your account-polld logs in .cache/upstart? Want to know what's going on
[20:37] <ToyKeeper> sergiusens: That could probably explain a few things...  there is no account-polld log there.
[20:37] <ToyKeeper> sergiusens: I see account-polld running though.
[20:37] <sergiusens> ToyKeeper: after you add either a gmail account or twitter account; you need to enable them in account settings
[20:38] <sergiusens> ToyKeeper: the Notifications toggle
[20:38] <ToyKeeper> sergiusens: Yes, I tried that.  Does it work for Facebook?
[20:38] <sergiusens> ToyKeeper: no facebook; we are still waiting for a backend change that is is doing for us
[20:39] <tvoss> trainguards, could you reconfigure silo 14 for me?
[20:39] <sergiusens> is meaning #is
[20:39] <ToyKeeper> Ah, okay.  With no context or test plan, I used the package's description...  which lists facebook first, which is what I mostly focused on since it's the most popular service.
[20:40] <sergiusens> ToyKeeper: sorry about that, was announced in lucio's emails; I guess it's easily missed
[20:40] <sergiusens> ToyKeeper: I'll write a testplan today; but it won't be stable; there are many moving parts still
[20:40] <ToyKeeper> sergiusens: Well, now I know why nothing I tried produced any results...  what I was testing wasn't implemented.
[21:00] <robru> Wellark, ah, some silos freed up if you want one
[21:01] <tedg> robru, Can I have one? Line 31 please.
[21:01] <robru> yep ^
[21:01] <tedg> Heh
[21:01] <tedg> Stupid google spreadsheets :-)
[21:01] <tedg> Thanks robru!
[21:01] <robru> tedg, you're welcome!
[21:05] <ToyKeeper> tedg: I see "QA testing FAILED" on silo 008.  Do you know who put that there, and if it has been fixed since then?
[21:05] <tedg> ToyKeeper, om26er did, and we added a MR which should fix his issue, but I'm verifying that now.
[21:06] <tedg> Uhm, my phone is requiring a password now.
[21:06] <tedg> What is it?
[21:06] <ToyKeeper> Okay, then I'll bbiab...  need to do some things before places close, and it appears the queue is empty at the moment.
[21:07] <tvoss> tedg, reflash
[21:08] <tedg> tvoss, Didn't work
[21:08] <tedg> Ah, I see.
[21:37] <brendand> robru, any chance of a landing this hour?
[21:37] <robru> brendand, yeah, if it's fixes ;-)
[21:37] <brendand> hmmm, technically :)
[21:37] <brendand> it's not my landing - i'm just giving the QA ack on it
[21:39] <robru> brendand, which one?
[21:41] <brendand> robru, 20
[21:41] <robru> brendand, but 20 is already in proposed... ;-)
[21:42] <robru> brendand, was published by rsalveti an hour ago
[21:45] <tvoss> Laney, ping
[21:46] <brendand> robru, so we aren't in traincon-0?
[21:47] <robru> brendand, yes we are...
[21:47] <robru> rsalveti, did you have qa signoff when you published silo 20?
[21:48] <rsalveti> robru: yup
[21:48] <brendand> rsalveti, did davmor2 take care of it?
[21:48] <rsalveti> ToyKeeper tested it, then I also validated and decided to land
[21:49] <rsalveti> not affecting anything
[21:49] <brendand> ah cool - last communication i got was serguisens bugging me to test it
[21:49] <brendand> anyway it looks good
[21:50] <rsalveti> yup, all good
[21:50] <rsalveti> will trigger a new image once everything is published
[22:07] <Wellark> robru: still have free silos?
[22:07] <rsalveti> Wellark: 6
[22:07] <robru> Wellark, yeah, that many
[22:08] <robru> brendand, silo 8 needs qa signoff but i'm not sure if anybody is currently working on that, maybe coordinate with ToyKeeper
[22:09] <Wellark> ok, I need tedg to do the paper work for https://code.launchpad.net/~unity-api-team/indicator-network/modeminfo/+merge/229992 then
[22:10] <ToyKeeper> robru, brendand: I think we're waiting on tedg to verify a fix for issues om26er found.
[22:10] <brendand> ToyKeeper, need to sleep now - if you need to you can sending me an email handing it over and i'll look at it in the morning
[22:11] <brendand> 'you can sending me an email'
[22:11] <brendand> this much i need to sleep
[22:13] <robru> Wellark, what do you mean paperwork? I thought we gave you access to the spreadsheet to request silos?
[22:38] <Wellark> robru: oh, did you?
[22:38] <Wellark> didn't know
[22:47] <tedg> Wellark, robru, added on line 29
[22:47]  * tedg reads backlog and realize he shouldn't have done that :-)
[22:47] <Wellark> robru: where exactly should I be able to request a silo?
[22:48] <robru> Wellark, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&pli=1#gid=0
[22:49] <Wellark> robru: can't write to that
[22:49] <robru> Wellark, sorry will add you soon, on phone
[22:49] <Wellark> robru: that would be great! :)
[22:50] <tedg> robru, Thanks! Wellark, kicked build in silo 1
[22:50] <rsalveti> robru: it seems something bad is happening with the publisher
[22:50] <rsalveti> robru: location-service shows itself in proposed at https://launchpad.net/ubuntu/+source/location-service for 46 min already
[22:51] <rsalveti> robru: and rmadison doesn't even see it still
[22:53] <robru> rsalveti, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#location-service yeah publisher hasnt run
[22:53] <rsalveti> https://launchpad.net/ubuntu/+source/ciborium, published to release 49 minutes ago
[22:53] <rsalveti> but nothing yet
[22:53] <rsalveti> robru: yeah
[22:53] <robru> infinity, ^
[22:53] <Wellark> tedg: thanks!
[23:00] <rsalveti> have to wait next image then, wanted to trigger a new one now but with latest location-service =\
[23:00] <rsalveti> bbl, dinner
[23:08] <robru> rsalveti, yeah I have no idea why that publication run was so delayed (it's usually like every 15 minutes I think, but last one was an hour pause), but anyway looks like it's gone now and location-service is valid candidate.
[23:10] <robru> Wellark, ok sorry for the delay. gave you write access on the spreadsheet and added you in the launchpad team that has permission to trigger builds and stuff.
[23:11] <robru> Wellark, you can trigger builds from http://people.canonical.com/~platform/citrain_dashboard/#?q=
[23:11] <robru> Wellark, and add requests in that spreadsheet
[23:15] <jgdx> kenvandine, aargh, forgot. Thanks though
[23:49] <alecu> hi! is there somebody around that we can ping to do QA of silo 8? ToyKeeper perhaps?
[23:49] <alecu> the QA verification, that is.
[23:58] <alecu> I've updated the test plan with known bugs after the latest fixes to that silo.