[00:12] <sergiusens> robru-sick, hey, are you the only one doing slots? Given that you are sick
[00:15] <fginther> kgunn, looks like it merged on it's own, and yes I should be eod
[00:22] <sergiusens> robru-sick, can I cancel sot 3 (as it's blocked) and get a slot for L47?
[00:28] <robru-sick> sergiusens, sure
[00:30] <sergiusens> robru-sick, one more for l48 as well; which is desktop as well
[00:30] <robru-sick> sergiusens, can they be in the same silo? we're a little short right now
[00:30] <sergiusens> robru-sick, I guess; even if not related
[00:30] <sergiusens> but also not exclusive
[00:30] <robru-sick> sergiusens, yeah, would be easier for us.
[00:31] <sergiusens> want me to bundle?
[00:31] <robru-sick> sergiusens, yes please
[00:32] <sergiusens> robru-sick, done
[00:33] <robru-sick> sergiusens, thanks. just waiting for silo 3 to finish purging
[00:34] <sergiusens> robru-sick, going to retry that one once unity8 can land again, should I leave that comment?
[00:35] <robru-sick> sergiusens, sorry what?
[00:35] <sergiusens> robru-sick, what used to be in silo 3 is going to get retried as soon as stuff can land freely again
[00:36] <robru-sick> sergiusens, oh right, yeah you can change the comment to be more meaningful. thanks.
[00:37] <robru-sick> sergiusens, ok, you got silo 3, please build.
[00:37] <sergiusens> thanks
[00:38] <robru-sick> you're welcome
[00:49] <sergiusens> robru-sick, btw, do you have perms to mark https://code.launchpad.net/~ps-jenkins/goget-ubuntu-touch/trusty-proposed as abandoned or mature?
[00:49] <sergiusens> oh wait
[00:49] <sergiusens> that's train
[00:50] <sergiusens> no former daily release
[00:50] <sergiusens> nvm
[01:15] <robru-sick> sergiusens, yeah, and I don't have permissions on that account ;-)
[01:30] <bfiller_afk> robru-sick: I need to drop one of the MR's from silo 2 request, what's the best way to do that?
[01:32] <bfiller_afk> robru-sick: I've taken it out of line 36 already
[02:17] <robru-sick> bfiller_afk, sorry, i can do that now
[02:20] <robru-sick> bfiller_afk, rebuilding for you since you're afk
[03:19] <asac> bfiller_afk: yeah dropping is a reconfigure with a complete rebuild as robru-sick did
[03:19] <asac> or is doing
[05:14] <bzoltan> asac: ping
[05:15] <bzoltan> asac: I have dropped a mail to you and to a bunch of people... not a big drama, but I would like to understand what I do wrong.
[05:16] <bzoltan> robru-sick:  hello there... what was with the linenumber 35 landing ask? I marked it "No" and I commented there why I do not like it ... why it was processed?
[05:19] <bzoltan> asac: at the same time I have an MP with 13 branches
[08:02] <sil2100> brb, need to jump out for a moment
[08:06] <bzoltan> didrocks: ping
[08:06] <didrocks> bzoltan: pong
[08:07] <bzoltan> didrocks: I put you to the To: in my mail... I am confused and so worried a bit
[08:07] <bzoltan> didrocks: no big drama, but I wish to understand what just happened
[08:07] <didrocks> bzoltan: there is nothing new, I'm not sure why you are raising the same thing again
[08:07] <didrocks> apparently, you already pinged asac at the time
[08:08] <didrocks> he and I sent an email to robert about it
[08:08] <bzoltan> didrocks: because an MR landed without our approval
[08:08] <didrocks> and he excused and understood what happens
[08:08] <didrocks> bzoltan: right, what you raised 3 days ago?
[08:08] <didrocks> bzoltan: but it was already landed
[08:08] <bzoltan> didrocks: yes... and the MR is merged now.
[08:08] <didrocks> bzoltan: yeah, it was already pushed
[08:08] <didrocks> as I told you
[08:08] <bzoltan> didrocks: without testing?
[08:08] <didrocks> (or if you read the phone ML emails)
[08:08] <didrocks> apparently he did the sdk testing
[08:09] <didrocks> so yeah, appart from emergency, this shouldn't happen, as told 3 days ago
[08:09] <didrocks> but it was already too late
[08:09] <didrocks> already in proposed
[08:09] <didrocks> as my 3 last emails on the phone ML is telling
[08:10] <bzoltan> didrocks: How did it land? The tests were not marked as "done" on the Silo sheet
[08:10] <didrocks> the only thing that changed is that it reached the release pocket (because of beta freeze)
[08:10] <didrocks> bzoltan: right, again, same thing than 3 days ago
[08:10] <didrocks> not sure why you reraise the same issue as it's the one that happened 3 days ago
[08:10] <bzoltan> didrocks: I still do not get it... how and why an MR lands what is not tested?
[08:11] <didrocks> grumble
[08:11] <didrocks> do you read the phone ML?
[08:11] <didrocks> or not?
[08:11] <didrocks> seems not :/
[08:11] <bzoltan> didrocks: I do
[08:11] <didrocks> well, so as told there
[08:11] <didrocks> 3 days ago, robert did land a renato's fix for alarm clock
[08:11] <didrocks> you raised it then
[08:12] <didrocks> asac and I poke him to get more details
[08:12] <didrocks> and he apologized to not have followed the process
[08:12] <didrocks> but the thing was already published
[08:12] <didrocks> and stuck in proposed
[08:12] <didrocks> (as told in my emails)
[08:12] <didrocks> the only thing which changed since yesterday is that it reached the release pocket
[08:13] <bzoltan> didrocks: I still do not understand why robru-sick lands anything from renato and what do we do to avoid it in the future?
[08:13] <didrocks> bzoltan: human error, he thought that was proposed by a sdk team member
[08:13] <didrocks> and he tested it before landing
[08:14] <bzoltan> didrocks: Human error to land an MP without tests?
[08:14] <didrocks> bzoltan: seems so
[08:14] <bzoltan> didrocks: the Silo sheet said that "testing done" - No
[08:14] <didrocks> bzoltan: yeah, and I raised it
[08:14] <didrocks> he didn't flip the switch
[08:14] <didrocks> which is an issue
[08:15] <bzoltan> didrocks: Human error to create a silo for for an MP not requested by the lander?
[08:15] <didrocks> bzoltan: any lander can land other components in case of emergency and the primary lander isn't there
[08:15] <bzoltan> didrocks: human error not to check if the MR is approved?
[08:15] <didrocks> but they are taking the risk and accept responsability
[08:15] <didrocks> bzoltan: yeah
[08:16] <bzoltan> didrocks: this is 3 human errors with one case.
[08:16] <didrocks> and?
[08:16] <didrocks> what's your point?
[08:17] <bzoltan> didrocks: what do we do to avoid it in the future... you made a very strict and riggid (and so good)  CI process. What good it is if people can just do shortcuts whenever they need so?
[08:17] <didrocks> bzoltan: we need then to educate people
[08:17] <didrocks> so that it doesn't reproduce
[08:17] <didrocks> rather than arguing on the same issue than happened 3 days ago
[08:17] <didrocks> nice you have time for that, I don't though
[08:17] <bzoltan> didrocks: I am not arguing
[08:17] <didrocks> I've already take actions
[08:17] <didrocks> as told
[08:17] <didrocks> 3 days ago
[08:18] <didrocks> the landing didn't create regressions, hopefully
[08:18] <didrocks> (or we would have revert)
[08:18] <didrocks> and fixed an issue
[08:18] <bzoltan> didrocks: it did for us
[08:18] <didrocks> bzoltan: which regression, do you have a bug? do we need to revert?
[08:20] <bzoltan> didrocks: I pull zsombi|afk in to explain
[08:20] <didrocks> just point me to a bug report
[08:20] <didrocks> and tell me if I need to revert
[08:20] <didrocks> but then, you have to fix the alarm quickly
[08:20] <didrocks> and only the alarm
[08:20] <didrocks> or I'll have to revert sdk even more
[08:20] <didrocks> as your latest landing created that regression
[08:21] <bzoltan> didrocks: what regression was created by what?
[08:21] <zsombi> didrocks: I don't get this...
[08:21] <didrocks> bzoltan: https://bugs.launchpad.net/ubuntu/+source/qtorganizer5-eds/+bug/1282129
[08:21] <didrocks> bzoltan: that's what they tried to fix apparently
[08:22] <zsombi> didrocks: yes, but it WASN'T a regression!
[08:22] <didrocks> zsombi: it was, we didn't get the crash before and we got it then
[08:23] <zsombi> didrocks: they wanted to increase the performance as alarms fetching was slow
[08:23] <didrocks> seems that some tests started to fail because of that
[08:23] <didrocks> zsombi: so, what regression did it create to you?
[08:23] <zsombi> didrocks and you haven't seen the crash before? that code in SDK wasn't changed for ages, so how was it a regression?
[08:23] <didrocks> zsombi: no, we haven't seen the crash before in the daily testing at least
[08:24] <zsombi> didrocks: with the fix you cannot fetch alarms that are created to a due date > 7 days
[08:24] <didrocks> zsombi: hum, but you did approve yesterday the MP?
[08:24] <didrocks> so you approved (even if it was after it landed) a regression?
[08:24] <bzoltan> didrocks: my previous MP was tested against the calendar_app and it gave green light.
[08:25] <zsombi> didrocks: but for the Clock app this is NOT a regression, because there you cannot create > 7 days alarm anyway
[08:25] <didrocks> zsombi: what on the image is creating a 7 days alarm and have tests?
[08:25] <zsombi> didrocks I approved so the fix can go to MWC if needed, and we are already working on the fix
[08:25] <didrocks> ok, so sounds you know how to fix it
[08:26] <didrocks> and no urgency to revert that one
[08:26] <didrocks> as nothing on the image is using the > 7 days, right?
[08:26] <zsombi> didrocks yes, I know... believe me approving the MR was a compromise I had to take... I was completely against it, but we had to do this... so no App should be affected, maybe test cases are.
[08:27] <didrocks> you have tests that are failing?
[08:27] <zsombi> didrocks: what bothers me was that the MR wasn't top-approved, and was still taken.
[08:27] <didrocks> zsombi: this is what I discussed with bzoltan 3 days ago
[08:27] <didrocks> happy that the SDK team can talk about the same issue for 3 days
[08:27] <didrocks> but meanwhile, there is an image that I need to go back to green, so I don't have the luxury
[08:28] <didrocks> and speaking of which, the Qt crash raised 4 weeks ago to your team
[08:28] <zsombi> didrocks: we do not have any tests failing, atm
[08:28] <didrocks> and dimissed by "we are going to switch to 5.2" is now hitting us badly
[08:28] <didrocks> zsombi: you should probably then test that
[08:28] <zsombi> and how can we speek for 3 days on teh same topic if the whole stuff got landed today?
[08:29] <didrocks> zsombi: it was already in 3 days ago
[08:29] <didrocks> read the phone ML
[08:29] <zsombi> didrocks: yes, I'm adding more tests to alarms now as we speek
[08:29] <didrocks> great
[08:29] <didrocks> from 25.02.14:
[08:29] <didrocks> 10. The alarm creating issues on clock apps (Robert).
[08:29] <didrocks> -> Half of the fix is in the release pocket, the other half (the sdk part) is stuck in proposed due to beta-freeze. Robert is looking if that can goes to the release pocket.
[08:29] <zsombi> didrocks: I did... and I found the first occurrence about this MP yesterday, on the 25.02.14 landing mail...
[08:30] <didrocks> zsombi: it was posted 2 days ago
[08:30] <didrocks> as the fix landed 3 days ago
[08:30] <zsombi> today is 27th, so only 2 days are gone since then :)
[08:30] <didrocks> (well 2.5)
[08:30] <didrocks> zsombi: right, but this is a recap email
[08:30] <didrocks> and bzoltan started to speak about it at the 25 in the morning
[08:31] <didrocks> when it was already landed
[08:31] <zsombi> didrocks: and still went in...
[08:31] <didrocks> zsombi: it WAS in
[08:31] <bzoltan> didrocks: I have flagged out the problem with that MP before 25.02 and before that mail...
[08:31] <zsombi> and you say that landing caused image not to be green?
[08:31] <didrocks> bzoltan: ?
[08:32] <didrocks> 2014-02-25 08:44:47     bzoltan didrocks: In the Self service CI (CI train) I watched the line nro 38 with some surprise. Does robru know that the UITK
[08:32] <didrocks>  releasing belong to me and my team? He was about to release an MR what was not even approved yet.
[08:32] <didrocks> bzoltan: ?
[08:32] <didrocks> I hope you don't infer I'm changing the dates on my logs?
[08:32] <didrocks> oh, let's take public logs even
[08:32] <bzoltan> didrocks: the sheet did not say that it was landed ... the mail did not say it was landed.
[08:32] <didrocks> if you don't trust me
[08:32] <didrocks> bzoltan: it said it was migating to destination
[08:33] <didrocks> so in the proposed pocket
[08:33] <bzoltan> didrocks: I do trust you... I wish to understand where from I should have known that it was landed?
[08:33]  * didrocks looses time for prooving bzoltan that he spoke on the 25
[08:33] <didrocks> no no
[08:33] <didrocks> seems you don't agree
[08:33] <didrocks> so, let's get public logs
[08:33] <zsombi> didrocks: m,an, I branched the trunk yesterday, and the FIX wasn't there... how come it landed on 25th then?
[08:33] <didrocks> zsombi: you should learn how ubuntu is working…
[08:33] <bzoltan> didrocks: dude, I remember I talked to you... I just wonder why my words were ignored.
[08:34] <didrocks> bzoltan: they were not
[08:34] <didrocks> man
[08:34] <didrocks> bzoltan: http://irclogs.ubuntu.com/2014/02/25/%23ubuntu-ci-eng.html#t07:44
[08:34] <didrocks> so do you still say "09:31:37  bzoltan | didrocks: I have flagged out the problem with that MP before 25.02 and before that mail..."?
[08:34] <didrocks> or do you infer I cheated on the public logs as well?
[08:35] <didrocks> I don't have access to irclogs.ubuntu.com if you ask me
[08:36] <bzoltan> didrocks: I still do not get how something can land when the Silo tests are not done. My only problem is that I see the CI Train sheet and I see the IRC ... and it seems that an MR just landed on a shortcut without giving me any visibility
[08:37] <didrocks> bzoltan: you don't answer the question…
[08:37] <didrocks> when did you flag it BEFORE the 25?
[08:37] <bzoltan> didrocks: I meant that line what you just linked
[08:37] <dbarth_> asac: (about your questions yesterday evening): 001 is CSS files and removing some private APIs for HTML5 apps; very self-contained if you want to land/purge the silo
[08:37] <didrocks> bzoltan: ok, so, it was the 25
[08:37] <didrocks> not before the 25
[08:37] <sil2100> Back
[08:37] <didrocks> so now, let's get back in time
[08:37] <didrocks> and rehash again
[08:38] <didrocks> as it seems you don't know what a pocket is and don't read the phone mailing list
[08:38] <didrocks> in the european night, between the 24 and 25
[08:38] <didrocks> robert did land that MP
[08:38] <didrocks> without flipping the testing done to yes
[08:38] <didrocks> then, it was in the proposed pocket
[08:38] <bzoltan> didrocks: I read the mails and yes I have no idea what the pocket is... I take that an MP is not landed before the Silo sheet has green cell on the testing line.
[08:38] <didrocks> "migrating to destination"
[08:38] <didrocks> in the spreadsheet
[08:38] <didrocks> once it's in proposed, it's in ubuntu
[08:38] <didrocks> it's too late
[08:39] <didrocks> the package was blocked in proposed due to beta freeze
[08:39] <didrocks> (not just for a couple of hours, but a day)
[08:39] <didrocks> then, you raised it to me
[08:39] <didrocks> asac and I sent an email to robert
[08:39] <didrocks> and he apologized and thought renato was on the sdk team
[08:39] <didrocks> testing was done by him and nicholas
[08:40] <didrocks> I reported that the component was blocked in proposed in my 25.02.14 email
[08:40] <didrocks> then, it was unblocked from proposed and so migrated to the release pocket
[08:40] <didrocks> and lands into an image
[08:41] <didrocks> what I reported on the 26.02.14 email
[08:41] <didrocks> so again, nothing was pushed/changed since you raised it
[08:41] <seb128> s!
[08:41] <didrocks> as I'm explaining it to you for the past 35 minutes…
[08:41] <bzoltan> didrocks: I admit I did not pay attention to "migrating to destination" because I thought that if an MP line has no testing plan and not asked by the lander and the tests are not flipped inthe Silo  ... then it does not land.
[08:41] <didrocks> bzoltan: not if you force the publication
[08:41] <didrocks> bzoltan: people has to push "publish"
[08:42] <didrocks> then, if they do not follow rules…
[08:42] <didrocks> so that was part of that email we sent as well
[08:43] <didrocks> all clear now?
[08:43] <bzoltan> didrocks: from the mail I understood that the SDK part is "stucked" due to the freez ... and I was happy to see that, because the MP was bogus anyway
[08:43] <didrocks> bzoltan: stuck in proposed
[08:43] <didrocks> but it means, already in distro
[08:44] <bzoltan> didrocks: I do not know what is "proposed" sorry for that
[08:44] <didrocks> bzoltan: yeah, you should learn after working on ubuntu for months now how the distro is working
[08:44] <bzoltan> didrocks: That is true... I should
[08:45] <bzoltan> didrocks: sorry, by watching the sheet and reading the mails I was under the impression that this MR is not landed yet.
[08:46] <didrocks> bzoltan: they had "migrating to destination" is when things are moving to distro
[08:46] <bzoltan> didrocks: I do admit that I am not fully at home with the distro lingo
[08:46] <didrocks> that's what I didn't use the pocket name in that "migration" sentence
[08:46] <didrocks> so the sheet was telling it was already published (just didn't hit the final destination)
[08:46] <bzoltan> didrocks: "migrating to destination" I ignored because I could not imagine something landing on the distro without tests and without the lander
[08:47] <didrocks> bzoltan: well, as told, other people can land your work, that's why you have a wiki page
[08:47] <didrocks> but that should be in coordination with the primary landers
[08:47] <didrocks> and the landing team shouldn't take that decision apart from extreme cases
[08:47] <didrocks> and testing was done
[08:47] <didrocks> the switch wasn't flipped
[08:48] <didrocks> (4th time…)
[08:48] <bzoltan> didrocks: I am not that stupid :)
[08:48] <bzoltan> didrocks: sorry if you think I waste your time...
[08:48] <didrocks> why are you repeating the same sentence over and over then?
[08:48] <didrocks> bzoltan: well, you can help getting us back to green now
[08:49] <didrocks> bzoltan: remember that qmlscene crash that was dismissed because rare 4 weeks ago (crash in v8 engine)?
[08:49] <bzoltan> didrocks: what can I do for you?
[08:49] <didrocks> seems (as you probably saw on the phone mailing list), that it's all over the place now
[08:49] <bzoltan> didrocks: yes
[08:49] <didrocks> I'm afraid of adding on top of the android 4.4 migration the Qt 5.2 ones
[08:50] <didrocks> so I guess we should really invest in a wokaround at least
[08:50] <didrocks> workaround*
[08:50] <didrocks> so any help to get that one down will be really a tremendous gain
[08:50]  * didrocks adds this example on his "I told you to not ignore it, it will strike us back" bag :)
[08:51] <didrocks> (bzoltan: last word on the sdk landing, I archived it in case you are looking for it as everything landed, it's in the archive tab, same spreadsheet)
[08:53] <bzoltan> didrocks: OK, I will see what can I do with that qmlscene... thanks for explaining the whole story of the mess ...
[08:54] <didrocks> bzoltan: no worry, just trust me for next time that I don't try to do anything on your back. If I told you I dealt with it, it's really that I dealt with it :)
[08:54] <bzoltan> didrocks:  you I do trust ...
[08:54] <didrocks> and if you see a landing you didn't expect, just poke me, not sure we need to "escalate" or whatever before gathering further infos
[08:55] <didrocks> bzoltan: to come back on this qmlscene crash (in the V8 engine), I only see the multithreading/scheduler changing in android 4.4 getting us into that situation way more…
[09:31] <didrocks> popey: where are you? we miss you! :)
[10:05] <popey> sil2100: yeah, invite me if you have a hangout pls
[10:10] <sil2100> popey: hi! psivaa will just send me the test-executing script from the dashboard for now
[10:14] <popey> sil2100: ok
[10:32] <tvoss> sil2100, hey there :)
[10:35] <Mirv> didrocks: oh, one thing I forgot - the idea was to do direct syncs from Debian for the majority of Qt modules - this clashes with the PPA preparation idea..
[10:35] <seb128> sil2100, is l22 not getting a silo due to the freeze? (indicator-datetime bugfixes, for issues that impacts mostly the desktop though)
[10:35] <Mirv> didrocks: the list is at https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AjuCdq68GSyVdFI4QzNQdWpfME5aMEV2VXo0cUpOMkE#gid=19
[10:36] <Mirv> didrocks: the alternative is not to do so but use ubuntu1 for everything like I've done in the current PPA already
[10:36] <Laney> you can sync to PPAs
[10:36] <Mirv> Laney: \o/
[10:36] <seb128> Mirv, please don't do that, what Laney said
[10:36] <Laney> lp:ubuntu-archive-tools copy-package
[10:36] <didrocks> Mirv: yeah, if it's ready already from debian side, please do that :)
[10:36] <Mirv> excellent
[10:36] <didrocks> Mirv: is it already in?
[10:36] <Mirv> thank you, thank you
[10:37] <Mirv> didrocks: yes, I checked today that everything we need was put to Debian experimental during my vacation
[10:37] <didrocks> excellent
[10:37] <didrocks> so yeah, start the sync :)
[10:37] <didrocks> tell me if you need any help with copy-package
[10:37] <Laney> is the no landing rule still on?
[10:38] <didrocks> Laney: for stuff in touch? yep
[10:38] <didrocks> Laney: see the ML ;)
[10:38] <Laney> it's too hard to keep track
[10:38] <Mirv> yeah, so I upload qtbase and then four syncs, one upload, sync, two uploads, 10 syncs.. something around that
[10:38] <Laney> because the status updates are just in random emails
[10:38] <didrocks> Laney: random emails?
[10:38] <Laney> can you put it in a /topic somewhere?
[10:38] <didrocks> Laney: all my emails start with it?
[10:38] <Laney> "Landing team xx.yy.zz" is pretty random to me
[10:38] <seb128> didrocks, is l22 blocked by your freeze?
[10:38] <didrocks> Laney: date of the day
[10:39] <didrocks> seb128: desktop bug reports, I would say no
[10:39] <seb128> good
[10:39] <seb128> thanks
[10:39]  * seb128 waits for sil2100 to be around
[10:39] <didrocks> Laney: read at least the first 3 lines, I've been careful to state it as the beginning of each email
[10:39] <didrocks> "Not a lot to add compared to this morning status email, we still hold the line on touch landings which are not targeting fixing the current image issues. "
[10:40] <didrocks> " Some desktop only update are still flowing in through CI Train, however, we are still blocked by not being able to get one image promotable."
[10:40] <Laney> 'we are still blocked' is the key there?
[10:40] <sil2100> seb128: I can assign it ;)
[10:40] <seb128> didrocks, I think his point is that having to catch emails is not as convenient as a dashboard/topic
[10:40] <seb128> sil2100, thanks
[10:40] <sil2100> seb128: when I saw it I was thinking 'uhh, ok, desktop only but still - indicators'
[10:40] <didrocks> Laney: yeah
[10:40] <didrocks> seb128: well, we need a web ui for the landing
[10:40] <didrocks> stating that
[10:41] <didrocks> but we need to have the CI work on it
[10:41] <Laney> /topic in here or touch would be ok for me
[10:41] <seb128> right
[10:41] <didrocks> I don't have /topic rights here I think
[10:41] <Laney> here isn't locked
[10:41] <Laney> touch is, don't know why
[10:41] <Laney> not any more!
[10:42] <didrocks> hum
[10:42] <sil2100> !
[10:42] <Laney> haha
[10:42] <sil2100> Ooooo
[10:42] <sil2100> Didier broke the topic!
[10:42] <sil2100> RUN FOR YOUR LIVES
[10:42] <sil2100> Oh, it's back again
[10:42] <sil2100> Nevermind
[10:42] <seb128> no fun :p
[10:42] <sil2100> ;)
[11:25] <davmor2> didrocks: so it looks like unity8 is locking up randomly, also shutting down bluetooth from the indicator kills the phone reboot into unity8 which I though was a qt5.2.1 issue but it seems not.  There is a bug assinged to qt5.2.1 for the bluetooth issue and the random lock ups is being worked on already I think
[11:25] <davmor2> didrocks: other than that 210 seems okay
[11:27] <davmor2> didrocks: I'm assuming that the unity8 random locks ups won't help the autopilot tests either so if you get some that fail on ci but pass on rerun/local that might be a cause
[11:28] <didrocks> davmor2: do you have a bug for the random locks up (which happens even with qt 5.2.1), and who is working on it?
[11:29] <didrocks> om26er: psivaa: any news on the screen unlock? :)
[11:30] <davmor2> didrocks: no this isn't on qt5.2.1 this is on standard, I didn't see the lock up on qt5.2.1.  But I'm assuming it would effect 5.2.1 I just didn't hit it.  Let me dig into it I'm sure I have heard talk of it though
[11:30] <psivaa> didrocks: just saw om26er :)
[11:31] <davmor2> didrocks: https://bugs.launchpad.net/bugs/1277206 this is the bluetooth bug
[11:31] <ogra> davmor2, does it only crach the UI or the phone as a whole ?
[11:32] <davmor2> ogra: it only seems to relaunch unity8
[11:32] <ogra> phew, fine then :)
[11:32] <davmor2> ogra, didrocks: it looks like it only happens on a first run after a fresh flash too
[11:33] <davmor2> I couldn't reproduce after re-enabling bluetooth
[11:33] <ogra> hmm, interesting
[11:34] <davmor2> I'm going to reflash it so I have a clean slate and see what info I can get about it
[11:37] <didrocks> davmor2: ok, so maybe your lock up is linked to the crash we have :)
[11:37] <didrocks> phew
[11:37]  * didrocks was afraid of another issue
[11:38] <davmor2> didrocks: could be
[11:38] <ogra> well, might be intersting to see if an extra reboot in the test runs would fix it
[11:39] <ogra> probably something in the session isnt completely set up on first boot that causes this
[11:39] <ogra> i assume we immediately start testing without any additional reboot
[12:00] <davmor2> didrocks: so on initial start up there is a crash for _usr_lib_arm_linux_gnueabihf_upstart-app-launch_desktop-hook.32011.crash  I'm guessing that isn't the start you want.  However I've cleared that off as I want a nice clean slate for the bluetooth killer
[12:01] <davmor2> didrocks: I'm assuming it might be the start guide
[12:01] <didrocks> davmor2: can you retrace that one?
[12:02] <davmor2> didrocks: no I killed it but I can reflash in a minute and do it then
[12:02] <didrocks> davmor2: that would be awesome!
[12:02] <psivaa> ogra: on flo the screen unlocking for ubuntu-system_settings had failed on my rerun as well. so kicked it again.
[12:03] <ogra> thanks
[12:03] <psivaa> the frequency of screen unlock issues appears to be more on flo
[12:03]  * sil2100 fights his phone
[12:06] <didrocks> psivaa: so, the plan is om26er to add more debug infos and running it? (or give the utah script so that he can reproduce?)
[12:06] <psivaa> didrocks: still waiting to hear from om26er. just received an email from him saying starting late today
[12:07] <didrocks> ok
[12:17] <ogra> psivaa, flo is faster and more responsive than mako
[12:17] <ogra> i actually assume that many of these issues we see are because android 4.4 is also significantly more responsive than 4.2 was
[12:18] <ogra> so timing critical things that didnt race before might now ...
[12:18] <psivaa> ogra: yea that would make sense.
[12:19] <ogra> so indirectly didrocks is right in blaming android 4.4 ... but after all it only exposes breakage in our tests that didnt show up due to slowness before
[12:20] <didrocks> ogra: yeah, see why we shouldn't never give up on races :)
[12:20] <ogra> it would help if we could ask unity8 if the screen is actually unlocked and get a proper response for this
[12:20] <didrocks> right
[12:20] <davmor2> didrocks: is there a wiki page/documentation on how to get a good traceback my google-fu seems to be off this morning
[12:21] <ogra> "Debugging" on the ubuntu wiki ?
[12:21] <didrocks> davmor2: https://wiki.ubuntu.com/DebuggingProgramCrash
[12:21] <ogra> iirc thats the top level page
[12:21] <ogra> yeah
[12:21] <davmor2> didrocks: cheers
[12:22] <didrocks> davmor2: for using gdb itself, maybe pair with sil2100?
[12:22] <didrocks> that will be way faster :)
[12:22] <didrocks> sil2100: mind helping davmor2 to retrace a crash?
[12:23] <sil2100> What's up?
[12:23]  * sil2100 reads up
[12:23] <davmor2> sil2100: I get this on a fresh flash _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash
[12:25] <ogra> isnt that just a script ?
[12:25] <davmor2> didrocks: looks like the bluetooth issue might be a race issue.  I'm assuming to do with what needs to be displayed and removing the indicator from the top bar.
[12:25] <ogra> you should be able to read it with an editor
[12:25] <didrocks> ok ;)
[12:32] <didrocks> psivaa: do you think ogra should try the unlock screen script? I don't have flo, tried unlocking 10 times the screen for mako without success
[12:32] <didrocks> in case:
[12:32] <didrocks> http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/files/head:/utils/target/
[12:33] <didrocks> download unlock_*
[12:33] <didrocks> chmod +x both
[12:33] <didrocks> and run the .sh as root
[12:33] <psivaa> didrocks: I think the freq is high in flo. so it would help
[13:18] <rsalveti> morning
[13:18] <ogra> hey hey
[13:19] <rsalveti> ogra: so in the end the crash has nothing to do with 4.4.2
[13:19] <rsalveti> good and bad news
[13:20] <ogra> well, it seems to expose some races due to 4.4 being more snappy i think
[13:20] <rsalveti> good is that this is not happening with qt 5.2, bad is that we got another crash there
[13:20] <rsalveti> ogra: yeah, I believe so
[13:20]  * ogra curses his maguro 
[13:20] <ogra> it endlessly reboots ...
[13:20] <rsalveti> was able to get the crash with manta quite frequently as well, with 4.2.2
[13:20] <ogra> with the popping sound during the boot process
[13:20] <rsalveti> might be because manta is really fast anyway
[13:20] <ogra> yeah
[13:22] <ogra> ARGH !!!!
[13:22] <ogra> MAGURO !!!!
[13:23]  * ogra gives up after watching the device doing its 10th reboot in a row ... and re-flashes losing 2h of work 
[13:23] <ogra> damned
[13:24] <ogra> i cant even get it into recovery now
[13:24] <ogra> just reboots as soon as it loads the kernel it seems
[13:27] <rsalveti> yeah, might be that old sound related kernel crash when booting
[13:30] <asac> Mirv: didrocks: hangout crashed
[13:30] <asac> lets continue after the meeting
[13:30] <didrocks> asac: which meeting?
[13:30] <asac> 5.2 ... dont worry :)
[13:30] <asac> there is a daily standup now
[13:31] <didrocks> should I get there as it's linked to the hot topic?
[13:31] <asac> didrocks: dont think you can do much there
[13:31] <asac> didrocks: unless you have time to fix bugs
[13:31] <didrocks> asac: ok, so the decision won't be taken into that meeting?
[13:31] <didrocks> about what we are doing?
[13:32] <asac> didrocks: the decision was already be done
[13:32] <asac> didrocks: its about tracking and driving the bugs down
[13:32] <didrocks> asac: yeah, but about the current image state and when we throw it in
[13:32] <asac> didrocks: do you want to propose to throw it in today?
[13:33] <asac> if so you should join
[13:33] <didrocks> asac: not today, but maybe tomorrow, once the base qt + first rebuild of some components are done
[13:33] <didrocks> if we go that road
[13:33] <asac> didrocks: yeah, then join tomorrow
[13:33] <didrocks> ok
[13:33] <didrocks> let's do that
[13:33] <asac> today i want to see what people think about breaking apps :P
[13:33] <asac> but i might even take that offline
[13:34] <didrocks> ok
[13:34] <asac> didrocks: if you say we should flush the toilet tomorrow i will try to talk to rick today
[13:34] <didrocks> asac: yeah, tomorrow (or monday depending on how we are in the build progress) at the latest I guess
[13:36] <didrocks> asac: in that case, I'm going for a run now :)
[13:45] <asac> didrocks: yeah do that.
[13:46] <om26er> psivaa, didrocks hey
[13:46] <om26er> I am up now, might need to wash my face
[13:47] <sil2100> Phew
[13:47] <sil2100> An I might have my device working again
[13:59] <psivaa> om26er: this is about any updates on screen_unlock failures. saw that today as well about 4 times in mako and 6 times on flo in about 20 times each
[14:02] <om26er> psivaa, yes so the issue was with unity8 not starting due to some reasons, I reported a bug for that
[14:03] <psivaa> om26er: do you have that bug handy?
[14:03] <om26er> psivaa, bug 1285215
[14:08] <sergiusens> sil2100, hey, can you rerun l23?
[14:17] <sil2100> sergiusens: sure
[14:17] <sil2100> hm, actually you can re-run it yourself, right? ;)
[14:17] <sil2100> Or maybe you want me to reconfigure?
[14:18] <sergiusens> sil2100, reconfigure
[14:18] <sergiusens> :-)
[14:22] <sil2100> sergiusens: done!
[14:23] <sergiusens> sil2100, ppa still has the packages, is that expected?
[14:23]  * sergiusens keeps forgetting
[14:35] <bfiller> asac, sil2100: silo 2 ready to be released (line 18 on sheet). tested and ready to go
[14:36] <asac> bfiller: tested == all green?
[14:36] <asac> bfiller: is this a regrssion fix or the ones we discussed yesterday?
[14:36] <bfiller> asac: the tests all pass on my device
[14:37] <bfiller> asac: these are other ones that were pending, not regression fixes
[14:37] <davmor2> didrocks: I've come to the conclusion that apport hates me and this crash hates me more, Apparently the word Core doesn't exist in the crash file so apport does nothing with it grrrrr  I have forwarded a copy to sil2100 as requested I'll let him bang his head against it while I carry on for a bit :)
[14:37] <asac> bfiller: ok. give us some time. we are talking about the qmlscene crash and how to best handle things until 5.2 is landing
[14:37] <bfiller> asac: ok
[14:40] <asac> if i could send mails that would help :)
[14:57] <om26er> cjohnston, hey! do you review cupstream2distro-config changes ?
[14:57] <om26er> I have this one https://code.launchpad.net/~om26er/cupstream2distro-config/uss_disable_otto/+merge/208619
[14:58] <cjohnston> fginther: please ^
[14:59] <fginther> om26er, cjohnston approved
[15:00] <om26er> fginther, cool, francis is there :)
[15:00] <fginther> om26er, will deploy when it merges
[15:05] <sil2100> davmor2, didrocks: there's not much to retrace there ;)
[15:06] <davmor2> sil2100: fsckin thing
[15:35] <ogra> didrocks, om26er, so one thing that strikes me ... did you ever notice that after a fresh boot the greeter sometimes needs multiple attempts to actually unlock ? it only slides by a few pixels and snaps back, i wonder if the unlock script simply experiences the sam here
[15:35] <ogra> *same
[15:36] <didrocks> ogra: yeah, I got that bug, but since saucy
[15:36] <ogra> right
[15:36] <didrocks> so maybe this is what happens
[15:36] <ogra> but probably it got worse now
[15:37] <om26er> ogra, didrocks I have seen the problem happen on my phone, Unity8 never started to begin with
[15:37] <ogra> i wonder what would happen if we let the whell script simply repeat the unlock attempt ... say 3 times instead of one
[15:37] <om26er> ogra, it already tries twice
[15:38]  * ogra doesnt have issues with unity starting on his devices ... weird
[15:39] <ogra> it can take long on first boot after a fresh flash, but it usually comes up after a while
[15:39] <ogra> (because of the apparmor-click registration)
[15:40] <didrocks> ogra: did you get anything on your flo?
[15:40] <ogra> like what ?
[15:41] <didrocks> ah, you didn't see my pings
[15:41] <didrocks> or I didn't see your answers :)
[15:41] <didrocks> one sec
[15:41] <ogra> didrocks, oh, sorry, i was in the garden for 1h ... had to chop two trees
[15:41]  * ogra is still dizzy ... so much sport 
[15:41] <didrocks> ogra: ahah, interesting "break" :)
[15:42] <ogra> yeah, the allowed time to chop them ends on sat ... so i have to do it today and tomorrow
[15:42] <didrocks> waow, so strict rules :)
[15:42] <ogra> (bird nesting time etc)
[15:42] <didrocks> ah found it:
[15:42] <ogra> yeah
[15:42] <didrocks> didrocks | http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/files/head:/utils/target/
[15:42] <didrocks> didrocks | download unlock_*
[15:42] <didrocks> didrocks | chmod +x both
[15:42] <didrocks> didrocks | and run the .sh as root
[15:42] <didrocks> this is to test unlock
[15:42] <ogra> yeah
[15:43] <ogra> i got that open
[15:43] <didrocks> ok ;)
[15:43] <didrocks> I couldn't get it after 10 runs on mako
[15:43] <ogra> but that need AP installed, no ?
[15:43] <didrocks> but it's already installed on the image!
[15:43] <didrocks> remember :)
[15:46] <ogra> didrocks, properly unlocked
[15:46] <didrocks> ogra: I think do that in loop if possible
[15:46] <ogra> and repeatable
[15:47] <didrocks> if you can't reproduce either that won't be fun :/
[15:48] <ogra> for i in $(seq 1 10); do ./unlock_screen.sh; done
[15:48]  * ogra twiddles thumbs 
[15:48] <didrocks> ogra: shouldn't you relock it in between? :p
[15:48] <ogra> didrocks, it restarts unity
[15:48] <ogra> so it comes up locked every time
[15:49] <didrocks> and shutting down the screen?
[15:49] <ogra> didrocks, hmm
[15:49] <ogra> you mean via powerd ?
[15:49] <didrocks> yep
[15:50] <didrocks> just trying to think what happens in the CI system when we start it
[15:50] <didrocks> I guess the screen is off
[15:50] <ogra> i guess it just booted and the screen is still on
[15:50] <ogra> but yeah, i can try
[15:50] <didrocks> ogra: it booted, but then, we have system settle
[15:50] <ogra> the ten runs seem to work fine though
[15:50] <didrocks> so it's waiting a lot
[15:51] <ogra> it was off when since 2h i ran the first (single) iteration
[15:52] <ogra> that worked fine
[15:52] <didrocks> ok, if you can try hammer with screen off in between
[15:52] <didrocks> "just in case" :p
[15:52] <didrocks> (not sure where the Tm is on this layout)
[15:53] <ogra> hmm
[15:53] <ogra> powerd-cli display off doesnt seem to exist
[15:53] <ogra> despite the help talking about it
[15:54] <ogra> oh
[15:54] <ogra> "powerd-cli display on" actually switches it off
[15:54] <ogra> ah, only after i ctrl-c out of the blocking
[15:56] <didrocks> oh? :/
[15:56]  * ogra has a meeting now ... i'll let it sit and time out during the meeting 
[15:56] <didrocks> yeah ;)
[15:56] <ogra> and also try after a fresh boot
[15:57] <didrocks> it's another plan
[15:59] <didrocks> sil2100: any luck on the terminal?
[15:59] <Saviq> didrocks, yes
[16:02] <sil2100> didrocks: not really ;< I even re-prepared my phone to make sure I'm using the right versions and nothing, not even one failure... I tried using the scripts from smoketesting for running the tests and the result (along with the unlock_* bits even) is the same. But I have a slightly re-written version of the test now which I think might give us some additional clues
[16:03] <didrocks> sil2100: did you try to bring eliopo to this? He's awesome at finding those kind of issues
[16:03] <didrocks> sil2100: like, don't block for 3 days on it
[16:03] <didrocks> sil2100: or just get published your information with more debugs
[16:08] <ogra> didrocks, so it doesnt really matter if the initial unlock after a boot doesnt work, since we restart unity afresh
[16:08] <didrocks> ok
[16:08] <ogra> and there the unlock seems to be just fine
[16:09]  * ogra just rean the same sequence with adb reboot added between the unlocks ... no issues 
[16:09] <ogra> and also leaving it sitting doesnt change it
[16:11] <sil2100> didrocks: our all data is on the bug, but we'll also include eliopo in the loop
[16:12] <sil2100> *into
[16:12]  * sil2100 didn't know we had such a convinient person ;)
[16:13] <didrocks> ogra: ok :(
[16:21] <ogra> so now i left it for 10min ... still fine
[16:22] <ogra> (and i'm now actually running "adb shell ./unlock_screen.sh" to be as close to the UTAH setup as i can here)
[16:24] <ogra> hmm
[16:24] <ogra> what i notice is that the touchscreen is dead after running the unlock
[16:24] <ogra> i cant actually tap on anything or interact with the UI
[16:24] <ogra> (though i guess thats because all input is redirected to AP)
[16:32] <seb128> sil2100, can I get a slot for l25 (indicator-keyboard fixes, desktop only)
[16:35] <sil2100> seb128: sure, doing
[16:35] <seb128> sil2100, thanks
[16:39] <sil2100> seb128: assigned
[16:39] <sil2100> np :)
[16:39] <seb128> thanks
[16:49] <sil2100> balloons: commented on your MP
[16:57] <balloons> sil2100, I responded :-) We have a couple ways of dealing with OSK. And yes, I had to stop myself from changing the test around completely, heh. Just need to get it to work, then we can tweak it
[16:58] <sil2100> balloons: disabling OSK would be awesome ;) Can we do that somehow in AP itself?
[16:59] <sil2100> Like, for instance, just for this test?
[16:59] <balloons> sil2100, yes, if we disabled it, I would push only for this test
[16:59] <balloons> and yes we can
[16:59] <bfiller> sil2100: the osk is disabled in all the address-book-app tests I believe
[17:00] <sil2100> \o/
[17:00] <bfiller> (which I don't think it should be, but it is)
[17:00] <bfiller> so you can find an example there
[17:00] <bfiller> just have to stop maliit-server
[17:02] <balloons> sil2100, likely if we simply tap in the top 1/6 of the screen we'll never hit the osk
[17:03] <sil2100> balloons: right, that's actually what I was experimenting with locally - the problem is that I though of that being a bit hacky
[17:04] <balloons> we actually have an open bug for the core apps to remove all the osk disabling as we can; it's not ideal to do that
[17:04] <sil2100> didrocks: meeting!
[17:04] <cjwatson> pmcgowan: would you or somebody on your team be available to attend https://blueprints.launchpad.net/ubuntu/+spec/core-1403-qt5-versioning as a UDS session?
[17:05] <pmcgowan> cjwatson, yes, in fact I could attend
[17:05] <cjwatson> cool
[17:11] <balloons> sil2100, yes, I'll try tapping the top of the screen for now
[17:22] <sil2100> balloons: thanks! I commented on the bug the way I did it ;)
[17:22] <sil2100> balloons: but it was hacky - I'm sure you'll find a better way
[17:22] <balloons> sil2100, I actually pushed the new version.. it uses globalrect property of the page
[17:23] <balloons> I tweaked the assert as well. It should fail better now
[17:23] <sil2100> balloons: globalRect, hah! With this it looks much better ;) My AP knowledge got a bit old it seems
[17:24] <sil2100> Let me do a quick spin of your latest branch and let's get it landed!
[17:28] <kgunn> didrocks: ...we suddenly have ci faililng....
[17:28] <kgunn> https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/1066/console
[17:28] <kgunn> but we noticed nothing changed on our dev branch
[17:28] <didrocks> kgunn: I guess this is a question for doanac` (the CI team)
[17:28] <didrocks> ah
[17:29] <kgunn> alan_g: do you happen to know when the last passing CI was on an MP up for review ?
[17:29]  * alan_g goes to look...
[17:29]  * doanac` looks
[17:29] <didrocks> kgunn: diffing the installed package would help to know what changed
[17:30] <didrocks> doanac`: you do have that on your artefacts?
[17:30] <alan_g> kgunn: 	Failing since 27-Feb-2014 16:16:06 was working at 11:44:53
[17:31] <doanac`> looks like a legitimate issue in log.h
[17:31] <balloons> sil2100, I put the device under load and it seems to hold up fine.. I'm happy with it
[17:32] <sil2100> Yep, me too - approving
[17:32] <robru-sick> didrocks, sil2100: anything you guys want me to hit publish on?
[17:32]  * sil2100 cannot top approve
[17:32] <balloons> sil2100, no worries, I did it
[17:33] <didrocks> robru-sick: I think there is nothing to publish until tomorrow midday (apart desktop-only feature)
[17:33] <kgunn> doanac`: can you share what changed there ? per  Failing since 27-Feb-2014 16:16:06 was working at 11:44:53
[17:33] <kgunn> i have to step away for a bit
[17:33] <robru-sick> didrocks, oh ok. I thought you said we would publish some and then build images, didn't catch that you were talking about tomorrow
[17:33] <doanac`> kgunn: i'll take a look
[17:33] <didrocks> robru-sick: once we get an image with only the crash
[17:34] <didrocks> robru-sick: my email will try to clarify that out :)
[17:34] <robru-sick> didrocks, ok, thanks
[17:34] <didrocks> robru-sick: you can assign silos though (but testing should only start tomorrow)
[17:34] <didrocks> kgunn: oh, before you leave
[17:34] <didrocks> kgunn: the screen unlock issue seems to be a Mir issue
[17:35] <didrocks> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1285215
[17:35] <didrocks> (I'll mention it in the landing email)
[17:38] <sil2100> didrocks: so, the terminal workaround fix is ouuun \o/ With the modifications done, we should have it in soon
[17:40] <didrocks> sweeeeeet
[17:41] <sil2100> Lets now just hope that it really works around that strange path causing the failure
[17:42] <doanac`> kgunn: looks like libglm has been updated from 0.9.4.6-2 to 0.9.5.1-1 and there's a new compile error as a result
[17:43] <doanac`> look for: /mir/partial-armhf-chroot/usr/include/glm/detail/type_vec3.inl:86:33 in https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/1065/consoleFull
[17:44] <elopio> ping cihelp, can somebody give me permissions to rebuild the autopilot release job in http://q-jenkins:8080 ?
[17:44] <cjohnston> elopio: please use the vanguard
[17:44] <elopio> ah, sorry, I always do it wrong
[17:44] <elopio> ping doanac` ^
[17:45] <doanac`> elopio: looking
[17:46] <asac> cjohnston: yeah, was my wrong guidance :)
[17:46] <asac> (on ci help)
[17:46] <asac> hope that didnt highlight :)
[17:46] <cjohnston> :-)
[17:47] <elopio> actually, on my last three pings the vanguard was c-i-h-e-l-p. This time, I just assumed it would be it too.
[17:47] <elopio> from now on, I'll just start pinging the wrong word just to annoy cjohnston :)
[17:49] <doanac`> elopio: i'm checking to make sure i can grant this for you.
[17:50] <elopio> thanks doanac`
[18:05] <didrocks> cyphermox: robru-sick: sil2100: FYI, commented on line #17. I think it's the kind of landing we are going to wait post Qt 5.2
[18:06] <didrocks> Saviq: FYI ^
[18:06] <jdstrand> I popped into the meeting earlier today, but I couldn't stay for long. I just wanted to point out an unfortunate consequence of the blocked landings recently
[18:06] <robru-sick> jdstrand, oh?
[18:06] <Saviq> didrocks, you mean the switch to py3?
[18:06] <jdstrand> right before all this, the click update manager was dropped so that we could use system settings
[18:07] <Saviq> didrocks, let xnox know
[18:07] <didrocks> xnox: ^
[18:07] <jdstrand> but the system settings functionality wasn't there
[18:07] <jdstrand> so the change was reverted
[18:07] <jdstrand> that's all fine
[18:07] <jdstrand> the problem is, the click update manager change made it to a promoted image, but the reversion never did
[18:07] <xnox> didrocks: hm?
[18:08] <didrocks> xnox: I would appreciate, as we have to land Qt 5.2 now, that we decouple the python3 switch for AP once we can repromote an image
[18:08] <didrocks> sorry for the delay, but sounds the safest for now
[18:08] <xnox> didrocks: re:python3 planning, in the light of the new planning. The proper way to decouple switch to python3 is to block landing phablet-tools update.
[18:08] <didrocks> (we are resuming some degraded mode for landing, see my email I just posted on ubuntu phone)
[18:09] <xnox> didrocks: but keep python3 unity8 and ubuntu-ui-toolkit.
[18:09] <didrocks> xnox: hum, nothing will activate it, you mean?
[18:09] <xnox> didrocks: this way, all tests will be executed with python2.
[18:09] <jdstrand> it isn't a *major* issue. perhaps we can just chalk it up to bad timing, but for dogfooders we haven't gotten app updates in a while. I'm not sure how to fix the process, but it would be nice if that revert had made it in to a prompted image before the churn happened
[18:09] <didrocks> xnox: sounds legit to me
[18:09] <xnox> didrocks: but myself and barry will be unblocked testing all clicks and apps under python3, locally, with changed phablet-tools.
[18:09] <didrocks> xnox: there is no landing slot/demand for phablet-tools yet, right?
[18:10] <jdstrand> anyhoo, I don't need any attention, I just wanted to bring up the point
[18:10] <xnox> didrocks: the branch you want to deconfigure is the phablet-tools py32 from me, and one that depends on it.
[18:10] <xnox> didrocks: or just kick phablet-tools out of it's landing slot / silo.
[18:10] <didrocks> jdstrand: yeah, we know about it, we even tried to resurect image #202
[18:11] <didrocks> jdstrand: we have some mitigation plan, look at the phone ML
[18:11] <xnox> didrocks: sergiousens is not online thought to confirm.
[18:11] <xnox> didrocks: it's tainted anyway, since it has my py32ap branch and another one which depends on it.
[18:11] <didrocks> jdstrand: the plan was that the revert was before android 4.4
[18:11] <didrocks> jdstrand: but the CI infra had issues (see my email on Monday)
[18:12] <didrocks> xnox: line 16?
[18:12] <xnox> didrocks: blacklist: https://code.launchpad.net/~xnox/phablet-tools/py2-3/+merge/205608.
[18:12] <xnox> didrocks: let me check the spreadsheet.
[18:13] <didrocks> xnox: hum
[18:13] <didrocks> https://code.launchpad.net/~doanac/phablet-tools/ptr-support-subunit
[18:14] <didrocks> contains your change
[18:14] <xnox> didrocks: yeah, line 16 kick-out, there are branches that depend on mine, and shouldn't land.
[18:14] <xnox> didrocks: they need rebase / restructuring, if they want to land without my changes.
[18:15] <didrocks> xnox: ok, just added a comment for now, I'll let you and sergio talk
[18:15] <didrocks> removed the comment on the other one
[18:15] <xnox> didrocks: but do keep line 17 as is.
[18:15] <didrocks> yep :)
[18:16] <xnox> didrocks: and ditto ubuntu-ui-toolkit, which i believe was ready to land as well. the py32ap branch.
[18:16] <didrocks> xnox: yeah, as long as your change isn't active, I'm good :)
[18:16] <xnox> didrocks: are we out of landing slots, or is ubuntu-ui-toolkit not planned yet?
[18:16] <didrocks> xnox: we will start resume landing tomorrow
[18:16] <didrocks> once the remaining issues (apart from the crash and unlock screen) are fixed on the image
[18:17] <xnox> bzoltan: ping, about reviewing https://code.launchpad.net/~xnox/ubuntu-ui-toolkit/py32ap/+merge/207757 did you get a chance to look into it?
[18:17] <didrocks> so tomorrow, they should have a slot
[18:17] <xnox> didrocks: ack.
[18:17] <xnox> bzoltan: hoping for https://code.launchpad.net/~xnox/ubuntu-ui-toolkit/py32ap/+merge/207757 to land with a next ubuntu-ui-toolkit landing.
[18:18] <seb128> didrocks, so, if indicator-datetime has 2 bugfixes pending, 1 for desktop and 1 for touch, can I land both, or should I let touch fixes out?
[18:18] <didrocks> seb128: today -> out. Tomorrow after next image -> in
[18:18] <bzoltan> xnox:  what is the "need fixing" from Barry Warsaw ?
[18:19] <seb128> didrocks, ok, let me do 2 landings then, thanks
[18:19] <didrocks> yw ;)
[18:19] <bzoltan> didrocks: did I read right? We have a chance to land our MRs tomorrow? That would be fantastic.
[18:19] <didrocks> bzoltan: yeah
[18:19] <didrocks> bzoltan: we'll need to be extra careful though
[18:19] <bzoltan> didrocks: of course
[18:19] <didrocks> bzoltan: see the "Special landing mode process" email
[18:20] <bzoltan> didrocks:  it is open in front of me
[18:20] <didrocks> :)
[18:21] <xnox> bzoltan: see comment below it, i've addressed the issue he raised.
[18:22] <bzoltan> xnox: OK
[18:23] <didrocks> ogra: pffff, only one sharing
[18:23] <didrocks> you missed one! :)
[18:23] <ogra> oh ?
[18:23] <ogra> still reading marks interview
[18:23] <didrocks> You can't multi-task :)
[18:25] <om26er> fginther, can you tell whats wrong here https://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-ci/664/ seems all the child jobs passed but still its not succeeding
[18:25] <ogra> there
[18:25] <ogra> :P
[18:27] <didrocks> ogra: ah, finally! :)
[18:27]  * didrocks hugs ogra
[18:27]  * ogra hugs didrocks 
[18:27] <fginther> om26er, the job is trying to pull test results from the generic-mediumtests-trusty job that was removed. I'll do a fix
[18:28] <om26er> fginther, thanks
[18:30] <fginther> om26er, I'm updating the job, but it will have to wait for the current one to finish running
[18:30] <om26er> fginther, sure
[18:32] <balloons> terminal fix is in the store, one down, 2 to go :-)
[18:32] <sil2100> Wooshaaa
[18:33] <fginther> om26er, updated, I've retriggered the last two jobs that failed
[18:34] <sil2100> balloons: awesome, thanks :)!
[18:35] <om26er> fginther, we can also re-enable otto for it once the upstart override is added
[18:35] <fginther> om26er, right, I'm still testing that
[18:36] <bzoltan> xnox: I am running the standard tests on your MR, Kaleo is fine with it, i am fine with it... once my teste give green I will add to the MP in the CI sheet
[18:36] <xnox> bzoltan: thanks.
[18:38] <robru-sick> seb128, your desktop=only landing got silo 13, please build
[18:38] <seb128> robru-sick, thanks
[18:54] <fginther> om26er, http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty-debug-fjg/60. Tests passed and it still hit the system-image-dbus crash
[18:55] <fginther> om26er, if the tests look good, I'll work on re-enabling the job
[18:55] <om26er> fginther, great so the apport window finally didn't ruin the party
[18:55] <om26er> fginther, looks good to me now
[18:55] <fginther> om26er, thanks for the fix
[18:56] <om26er> ;)
[19:52] <asac> kgunn: is this pre-start you talk about in the test or in MIR itself?
[19:53] <kgunn> no, in the test...team doesn't agree that mir should be deleting sockets as they might belong (in theory) to another mir instance..
[19:53] <kgunn> Saviq: ^
[19:53] <asac> multiple mir instances?
[19:54] <kgunn> right
[19:54] <asac> kgunn: curious what the case for having multiple mir instances is... is that for multi-user support?
[19:54] <kgunn> i'm not done hashing it out w the team, surely there's a way to take care of the case (e.g. determine its stale)
[19:59] <asac> balloons: anything we can do to help getting your weather and clock fixes done and/or in?
[20:00] <asac> rsalveti: voice call and camera are on track you believe? are both on you or is one of the ricardo's ricmm?
[20:00] <rsalveti> asac: working on them right now :-)
[20:00] <rsalveti> yup
[20:00] <asac> kgunn: so yeah, i guess lets get pre-start fix into test if you can't find a better way and just ensure we dont forget to drop that bandaid once the real fix arrives
[20:01] <kgunn> we won't we gotta bug
[20:01] <asac> ok will wait for update then
[20:01] <asac> oh thought you said we wont land the pre-start fix :)
[20:01] <asac> (but you said we wont forget)
[20:01] <asac> cool
[20:02] <asac> cyphermox: robru-sick: will you be around later for help kgunn and friends?
[20:03] <robru-sick> asac, yep, i'm lying in bed but have my laptop and can respond to pings
[20:03] <robru-sick> asac, for at least 6 more hours
[20:03] <asac> robru-sick: do you know whats up with the spreadsheet? looks buggy to me
[20:04] <robru-sick> asac, yeah, just noticed that. I guess just leave it. worst case, I can fiddle the backend directly
[20:04] <asac> robru-sick: does that look familiar to what we had before (e.g. google bustage?)
[20:04] <balloons> asac, working with the upstream devs for clock and weather, so ...
[20:05] <robru-sick> asac, yeah, it's just google spreadsheet limitations, seems it doesn't scale very well.
[20:05] <asac> robru-sick: but saw something like this and it auto recovered?
[20:06] <robru-sick> asac, yeah, i saw this before... i dunno if it "auto recovered", but it went away while i was sleeping so probably didrocks fixed it. but it's ok, I can do things manually in the backend to override this brokenness
[20:06] <asac> robru-sick: good. still would love to see the pending requests etc.
[20:07] <robru-sick> asac, yeah, people can add requests still, just the status column will only say #ERROR
[20:07] <robru-sick> asac, oh, actually it looks fine already ;-)
[20:07] <asac> yay
[20:07] <asac> perfect
[20:08] <robru-sick> asac, yeah, just some hiccups from google, i guess they are trying to sabotage us ;-)
[20:09] <asac> of course they do... always :)
[20:19] <Saviq> kgunn, duflu himself wrote
[20:20] <Saviq> kgunn, that they can check if the socket responds, and delete if it's dead
[20:20] <kgunn> Saviq: mterry and i converged to that very point just now :)
[20:21] <Saviq> kgunn, k, I can add the removal in unity8's pre-start in the mean time
[20:26] <kgunn> Saviq: ta
[20:35] <Saviq> kgunn, fwiw I already had a MP up since November ;) https://code.launchpad.net/~saviq/unity8/drop-stale-socket/+merge/196917
[20:36] <kgunn> hold out :)
[20:36] <kgunn> ta
[21:24] <robru-sick> seb128, i published silo 8 for you since it's desktop only
[21:25] <seb128> robru-sick, thanks, I would have done it earlier but ppc had some backlog and delayed builds
[21:26] <robru-sick> seb128, no worries
[22:00] <veebers> plars: hey, would you know anything about the maguros being offline on "Ashes"?
[22:01] <plars> veebers: they shouldn't be, let me check. Where are you seeing this?
[22:01] <veebers> plars: when we're trying torun this job: http://q-jenkins:8080/job/autopilot-release-gatekeeper/
[22:02] <veebers> specifically maguro-07
[22:02] <plars> veebers: oh, that's something different, I didn't think it was tied to any maguro
[22:05] <plars> veebers: ok, it's online now
[22:05] <veebers> plars: awesome, thanks
[22:25] <plars> rsalveti: asac: manta is starting to show up on http://ci.ubuntu.com/smokeng/trusty/touch/ now
[22:26] <rsalveti> plars: awesome!
[23:52] <asac> plars: nice!
[23:52] <asac> almost full house :P
[23:52] <asac> house full of emulators would be great :)