[00:22] <robru> bfiller: sorry about that, was on lunch. done
[00:28] <bfiller> robru: cheers, thanks
[00:28] <robru> bfiller: you're welcome
[00:42] <robru> bfiller: so there's a new thing now: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-018-1-build/ you can get your packaging diffs at build time rather than waiting until the publish step. makes it easier to get packaging reviewed before it's too late
[01:17] <bfiller> robru: cool
[01:18] <cyphermox> robru: I'm around now?
[01:18] <robru> cyphermox: heh, I'm back now ;-)
[01:18] <cyphermox> ok
[01:37] <rsalveti> bfiller: seeds updated
[02:08] <bfiller> rsalveti: thank you
[03:30] <imgbot> [03:30] <imgbot> [03:36] <bfiller> robru: mind publishing ubuntu 13 if you're around still?
[03:37] <robru> bfiller: yep, was just prepping dinner
[03:37] <bfiller> robru: thanks man, sorry to bug you
[03:37] <robru> bfiller: no worries, happy to help
[04:41] <bzoltan_> Mirv: do you know what deas that mean? https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-014-1-build/66/console Sounds off in context of the RTM
[05:11] <rsalveti> Mirv: nice, qt 5.4 packages are looking good for the emulator
[05:11] <rsalveti> nice work
[05:59] <Mirv> rsalveti: great news!
[06:00] <Mirv> that means I'll start ushing wih the ~test removed from version numbers
[06:02] <bzoltan_> Mirv: I have a strange dependency error in the rtm silo14 withthe gles package
[06:02] <Mirv> bzoltan_: "dea"?
[06:03] <Mirv> oh, does :)
[06:04] <bzoltan_> Mirv:  it looks odd ... specially that Qt is rater stable on RTM ... there was no qt changes there as I know
[06:05] <Mirv> bzoltan_: I know I haven't had enough coffee yet, but isn't that dependency error _after_ the source package was already created?
[06:14] <Mirv> bzoltan_: as usual, it's not the train but your MP
[06:14] <Mirv> bzoltan_: or so I'd think. you have a version number that's bound to raise some eyebrows :D 1.1.1298+15.04.20150212~rtm-0ubuntu1.dsc
[06:14] <Mirv> I can imagine that causing slight trouble when trying to dput the .dsc file
[06:15] <Mirv> with "as usual" I mean that "CI Train outputs something really strange" usually means "you did something unusual, unless it looks like network is broken on the machines"
[06:27] <bzoltan_> Mirv:  I understand that I am  a very stupid person :) But please tell me what did I do wrong?
[06:30] <Mirv> bzoltan_: copy-pasting the version number from terminal instead of web browser?
[06:31] <Mirv> bzoltan_: so, it's quite visible once you spot it at the first line of https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/rtm-landing-1202-gles/+merge/249560 ...
[06:31] <Mirv> it's not that you couldn't have dots in your version number, but CI Train most probably does some cutting based on ".dsc"...
[07:00] <bzoltan_> Mirv: OMG... LOL.. sorry...
[07:00]  * bzoltan_ needs coffee
[07:04] <Mirv> bzoltan_: hehe
[08:18] <Mirv> mandel: are you landing ciborium vivid today? I've also it in my Qt silo (the fix), but I'm glad to remove the MP and just rebuild if you land it
[08:19] <Mirv> mardy: could you perhaps review https://code.launchpad.net/~timo-jyrinki/ubuntu-system-settings-online-accounts/fix_qt54_buildfail_new_function/+merge/249069 so I can land it today/Monday with Qt?
[08:19] <seb128> Mirv, is new qt planned to land?
[08:19] <Mirv> seb128: yes, now that emulator was confirmed to be working and no critical bugs left
[08:20] <seb128> Mirv, was settings confirmed to work with it?
[08:20] <Mirv> 3 bugs overall, one of them is the u-s-s
[08:20] <Mirv> seb128: no, the about page bug is still open
[08:20] <seb128> since when do we accept that kind of regressions?
[08:20] <Mirv> but I'm stalled because of Kubuntu so landing probably on Monday, not today
[08:20] <mardy> Mirv: joining a meeting now, I'll get to that in a few minutes
[08:21] <Mirv> seb128: well, it's clear it's not hard to fix, FF is approaching, and QA opinion was "no blockers". of course it'd be nice to get it fixed ASAP.
[08:21] <seb128> Mirv, you realize that without the about page there is no way to enable developer mode so no way to use adb/connec to the device?
[08:21] <seb128> I'm surprised we consider that ok
[08:21] <Mirv> seb128: --developer-mode works, but yes the bug could be raised to be Critical
[08:22] <Mirv> seb128: maybe one option is to not have that problematic Class usage as a workaround to have the rest of the page working, I can look at that
[08:22] <seb128> Mirv, what was the issue again? the move of the storage to qt proper? does that symbol conflict?
[08:23] <Mirv> seb128: the move of storage to qt proper without offering QML class anymore (...). maybe you could offer the QML class instead and use it.
[08:23] <Mirv> so only C++ is there anymore
[08:23] <seb128> Mirv, but we don't update qtsystems, the old one stops working?
[08:23] <Mirv> seb128: yes, it does
[08:24] <seb128> shrug
[08:24] <seb128> well, Laney looked at switching the code to the qt version
[08:24] <seb128> but it lacks apis that were in qtsystems and that we need
[08:24] <seb128> especially the one to filter storage to list only the internal ones
[08:25] <Mirv> this was probably just the first step in upstream combined with the fact that they didn't support the previous feature.
[08:26] <seb128> well, what do we do meanwhile?
[08:26] <seb128> if we drop those checks the storage info are going to be wrong
[08:27] <Mirv> I'd say the feature needs to be reimplemented in our component or offered to upstream qtbase + qtdeclarative for the QML part
[08:27] <Mirv> they won't allow the same class back to qtsystems now that they started on it in qtbase
[08:27] <seb128> right
[08:27] <Mirv> even if the qtbase lacks features and bindings
[08:27] <seb128> but meanwhile what do we do
[08:27] <seb128> do we accept wrong storage info as an ok regression?
[08:27] <Mirv> hide the storage info temporarily until fix is there?
[08:28] <seb128> or do we block the qt5.4 landing on that to be resolved
[08:28] <seb128> urg
[08:28] <seb128> I didn't follow closely landing rules recently
[08:28] <Mirv> that's alternative, but the push to get 5.4 in is quite big compared to one part of a page
[08:28] <seb128> but that seems a world different from previous cycle
[08:28] <seb128> where we had "never land with regressions"
[08:28] <seb128> now we consider ok to hide main feature from the product?
[08:29] <Mirv> well davmor2 and others from QA could reconsider this and give their thoughts
[08:29] <seb128> davmor2, ^ please reconsider
[08:30] <seb128> Mirv, also why hasn't that be communicated on eg ubuntu-devel@ list?
[08:30] <seb128> it would have helped to give some perspective on the issues and when they need to be resolved
[08:31] <Mirv> seb128: usually the bug reporting is enough. the Qt 5.4 plan states it's planned to land before FF, and also there have been e-mails on phablet stating it's coming soon.
[08:32] <Mirv> the bug itself also says "targeted before Feature Freeze Feb 19"
[08:32] <seb128> Mirv, yeah, phablet is not a way to reach to everyone is Ubuntu
[08:32] <seb128> right
[08:32] <seb128> still that seems like a total shift in mindset from the high quality/no regression speech we had for some cycles
[08:33] <seb128> we had a time where we were speaking about fixing in some hours or reverting
[08:33] <seb128> now we just happily land regressions knowing that things are buggy before even landing
[08:33] <seb128> shrug, I should just stop there, I'm going in ranting mode
[08:33] <Mirv> :)
[08:34] <seb128> I'm going to write an email asking wth happened to the quality standards we preached
[08:34] <ogra_> seb128, its friday ... go ahead :)
[08:34] <seb128> I'm already annoyed that we have indicator-sound displaying bubbles for nothing every time something happens, and that we didn't revert the buggy upload
[08:35] <seb128> I might just go ahead and do that as well, while I'm at it :p
[08:35] <ogra_> seb128, i think the issue is that vivid gets less attentiion and everything is handled more loosely since we have RTM with full QA focus
[08:35] <seb128> ogra_, well, that's understandable
[08:36] <ogra_> the prob here is clearly the lack of manpower in QA
[08:36] <Mirv> seb128: we don't have full regression testing in vivid, that's why there are some problems now. Qt 5.4 however has been tested better than probably anything else that's going in to vivid on average.
[08:36] <seb128> ogra_, was is less understandable is that we know that e.g qt5.4 landing is going to regress settings and make it impossible to enable dev mode and that we have hand like it was no big deal
[08:36] <ogra_> imho we need more communiity involvement on the devel-release side
[08:36] <seb128> what*
[08:36] <Mirv> seb128: I'm sorry you feel you were left out by not having your bug (about the only one left) considered as critical blocker from the beginning
[08:36] <ogra_> yeah, agreed
[08:37] <Mirv> I felt the bug sounds like easily understandable technical problem instead of risky sounding regression like a crasher would be
[08:37] <seb128> Mirv, I don't care much about my bug, but I got handed a devide with qt5.4 the other day and it was a brick to me, I couldn't enable adb and so connect to it to work on it
[08:37] <seb128> Mirv, sure is
[08:37] <seb128> but still the impact is that it blocks people to do work
[08:37] <seb128> no adb, no ssh
[08:37] <seb128> how do you even work on a device?
[08:38] <Mirv> seb128: yeah the impact needs to mitigated before publishing
[08:38] <seb128> well, from what you said that was not going to happen
[08:38] <ogra_> no ssh ?
[08:38] <seb128> ogra_, we don't install/enable ssh by default do we?
[08:38] <ogra_> it is installed by default ... not enabled though
[08:38] <seb128> right
[08:39] <seb128> so it means a device without dev mode enabled and with a broken UI to access dev mode
[08:39] <seb128> what do you do from there?
[08:41] <ogra_> you can boot into recovery and set the property to turn ssh on ...
[08:41] <ogra_> it will start on next boot
[08:41] <ogra_> prob is ... you indeed need working network
[08:41] <seb128> yeah, and you need how to do that
[08:41] <ogra_> in the normal boot it is /userdata/android-data/property/persist.service.ssh
[08:41] <seb128> how many people are going to waste an hour or resolving that?
[08:41] <ogra_> needs to have "true" with no newline
[08:41] <seb128> that's just wrong, we should fix the known regression before landing
[08:41] <Mirv> seb128: we're not going to ship 5.4 with no dev mode in about page
[08:41] <ogra_> sure
[08:42] <ogra_> just pointing out that there are ways
[08:42] <seb128> Mirv, well, sounded like you were about to
[08:42] <ogra_> not convenient ones ... but you can always get in somehow
[08:42] <seb128> ogra_, yeah, it's just that when you do that you make 15 engineers waste half an hour to resolve the issue and you lost a man-day of work
[08:43] <ogra_> sure
[08:43] <Mirv> seb128: no, it's just that I'm handling 50+ bugs and 50+ components and I trust upstream to shout too, like you just did. I didn't think the about page is important, but that's because I enabled the dev mode _before_ upgrading to 5.4. I'd be ok though in disabling storage info until you've fixed the core issue, since blocking the whole release on an understood problem could be overkill.
[08:43] <ogra_> i didnt say everyone should do it :)
[08:44] <Mirv> I think that was the QA opinion too, as long as problems are understood they are ok if there are very few of them
[08:44] <seb128> Mirv, it's a slippery path, you accept regression/to hide pages, and then everybody forgets about it, and you wake up later with omg vivid quality regressed so much
[08:45] <seb128> I though the hard line on no regression was to prevent ending up going that way
[08:45] <Mirv> seb128: it's not being forgotten since it's known, unlike some of the other vivid regressions currently in there
[08:45] <Mirv> seb128: we can't really not ship 5.4 either, so there's a balancing needed to be done at some poit
[08:45] <seb128> right, it's just that we diverge more and more from our goal on quality
[08:45] <seb128> it's going to be difficult to get back to the rtm quality if we keep doing that
[08:45] <seb128> right
[08:46] <seb128> I would expect that the answer to "something really needs to happen" is "the resources are allocated to make it happen", not "ok, we accept to lower quality to get it"
[08:46] <ogra_> well, but that means we need someone to put more time into qality on that release ...
[08:47] <ogra_> which is really hard if 98% of the QA engineers we have are focused on rtm
[08:47] <Mirv> seb128: isn't Laney allocated to it still? surely we can escalate the issue if he doesn't have resources for it, to see what can be done.
[08:47] <seb128> Mirv, he is, but he's off today, so I'm unsure he's going to get to it before you land qt5.4
[08:47] <ogra_> and the remaining 2% need to rush to get anything dones at all to keep up with our devlopment pace
[08:47] <seb128> ogra_, well, those are some of the cases where we know things are buggy, no need of QA to point it
[08:48] <seb128> it's just a mindset from the landing team
[08:48] <ogra_> we need to get away from the 2 distro approach or we need to staff up QA
[08:48] <ogra_> there is no requirement for QA testing on vivid silos
[08:49] <ogra_> so the QA person testing the image will only see it far after it landed
[08:49] <seb128> right
[08:49] <seb128> but in this case we know about issues before landing
[08:49] <seb128> so we should block landing
[08:49] <ogra_> how ?
[08:49] <ogra_> no QA person tests the vivid silos
[08:49] <Mirv> seb128: I'll look at the bandaid to have most of the page working, and talk with QA what they think of the bandaid
[08:49] <seb128> well, we have a bug open saying that settings->about fails to open with qt5.4
[08:49] <seb128> it has been reported by our landing team
[08:50] <ogra_> ah
[08:50] <seb128> Mirv, thanks
[08:50] <seb128> ogra_, it's just that landing is also happy to sit over and release qt5.4 without fixing the regression, which is what I'm ranting about
[08:50] <ogra_> right, that shouldnt have happened
[08:51] <ogra_> seb128, and thats what keeps you from adb/ssh ?
[08:51] <seb128> ogra_, yeah, no about page, no access to the dev mode switch, no adb
[08:51] <ogra_> open the terminal: android-gadget-service enable ssh
[08:51] <Mirv> seb128: the opinion was that as long as someone is working on it, it's not a blocker. but I do think not having dev mode is clearly a blocker.
[08:51] <ogra_> i thought you have no UI at all
[08:52] <seb128> ogra_, assuming you have it installed, which we don't by default on e.g krillin
[08:52] <Mirv> (or, not having easy dev mode)
[08:52] <ogra_> seb128, the same command above works with s/ssh/adb/ and enables dev mode
[08:52] <seb128> ogra_, but yeah, I guess you can install from the store
[08:52] <seb128> Mirv, thanks
[08:52] <seb128> anyway, enough discussed it
[08:52] <ogra_> we talk about vivid
[08:52] <seb128> let's try to get the issue resolved
[08:53] <ogra_> vivid always has the terminal by default ... wont go away ... even on krillin afaik
[09:23] <davmor2> seb128: I'm hoping not to throw petrol on the fire here, but from testing that is the only remaining issue and QT5.4 needs to land before feature freeze and the bug technically isn't one in qt5.4 so I see no reason not to land QT5.4 and
[09:23] <davmor2> man my back space skills suck
[09:23] <jibel> seb128, another option is to no rely exclusively on manual testing to prevent regression. It is not sustainable. Teams must start by looking at the results of automated tests and fix them. An 80% pass rate on vivid means something http://ci.ubuntu.com/smokeng/vivid/touch/mako/97:20150213:20150210/12295/
[09:23] <davmor2> seb128: I'm hoping not to throw petrol on the fire here, but from testing that is the only remaining issue and QT5.4 needs to land before feature freeze and the bug technically isn't one in qt5.4 so I see no reason not to land QT5.4 if it can have a bandaid it will just make it better
[09:24] <jibel> seb128, sadly we are not automatically gating on these tests
[09:29] <jibel> and talking about system-settings, only 2 tests pass on 124
[09:31] <seb128> jibel, yeah, that's an issue
[09:31] <seb128> urg, what is the issue with the other ones?
[09:45] <mandel> Mirv, yes, that is the intention, but if you have it in that silo with the qt fix, can you land yours first, then I'll land mine
[09:46] <mandel> Mirv, or vice versa, whatever you prefer as long as it lands with the fix (I can reconfigure my silo)
[09:46] <mandel> Mirv, I think it will be faster on my side that yours
[09:47] <Mirv> mandel: yes, please land asap and I'll just rebuild as soon as it's published
[09:47] <mandel> Mirv, ok, on it
[09:54] <mandel> Mirv, I have removed the qt mr but either I'm not yet awake or for some reason I cannot reconfigure the silo, can you take a look?
[09:54] <Mirv> mandel: hmm, I did actually mean you would land the fix too, so I can rebuild without changes, is that ok?
[09:54] <Mirv> I always prefer no-change rebuilds
[09:55] <mandel> Mirv, ok ok, sounds good
[09:55] <Mirv> mandel: the only thing is that ciborium needs a rebuild since it uses private headers
[09:55] <Mirv> mandel: ok!
[09:56] <mandel> Mirv, ok, so, let me get this clear, we land my silos with both fixes in rtm and vivid and you keep the mr for qt there so that ciborium is rebuilt because is using the private qt headers due to go-qml, is that correct?
[09:57] <Mirv> mandel: 1. rtm wouldn't need 5.4 fix at all, 2. I remove the MP from my landing and do a manual rebuild
[09:58] <Mirv> ...after your landing with the 5.4 fix is in vivid
[09:59] <mandel> Mirv, ok, so line 58 is ok atm, correct?
[09:59] <mandel> Mirv, then, if I find where is rtm silo 000 line, I need to check that one out
[09:59] <mandel> Mirv, and line 59 should be removed
[10:02] <Mirv> mandel: 58 is ok, 59 should be removed unless https://code.launchpad.net/~mandel/ciborium/remount-drives-take-2/+merge/248783 is a critical bug fix targeted to next milestone
[10:03] <Mirv> mandel: but it is, so 59 should stay with the rtm version of https://code.launchpad.net/~mandel/ciborium/remount-drives-take-2/+merge/248783 targeted towards rtm branch
[10:03] <Mirv> mandel: or, is it that you don't have rtm branch of ciborium, they are identical?
[10:04] <mandel> Mirv, I think 59 was an error since is pointing to trusty which was an error and in landing-000 rsalveti did the right thing, yet I cannot find the line where he configured it
[10:04] <mandel> Mirv, so I as saying, 58 ok, 59 out since was an error and we clear that silo, and I try to find where is the line for rtm-00 (google docs sucks at searching)
[10:05] <Mirv> mandel: ok, just make sure to fix the critical bug in rtm one way or another, but let's remove 59 for now, and let's land 58.
[10:05] <mandel> Mirv, +1 to that
[10:06] <Mirv> +1!
[10:09] <mandel> Mirv, can you remove line 59 then? I don't think I have the rights to do it
[10:11] <Mirv> mandel: yes
[10:11] <Mirv> done
[10:12] <mandel> Mirv, superb, thx
[10:12] <popey> zbenjamin: what's the chance you can fix bug 1418460? It's blocking a couple of core apps projects.
[10:27] <mandel> Mirv, testing in vivid atm line 58
[10:33] <zbenjamin> popey: that looks to me like he forgot to add the :armhf suffix
[10:33] <zbenjamin> popey: apt-get install libconnectivity-qt1-dev:armhf
[10:36] <seb128> is CI known to be unhappy atm?
[10:36] <seb128> settings results on mps look like the application exit on start or something
[10:37] <seb128> not sure what's going on
[10:38] <sil2100> cihelp: ^ is there any known outage?
[10:40] <seb128> e.g https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/1188/
[10:44] <psivaa_> seb128: system-settings crash during the AP testing
[10:44] <seb128> psivaa_, can we have a bt?
[10:45] <psivaa_> seb128: this could be seen in smoke too
[10:45] <psivaa_> seb128: http://ci.ubuntu.com/smokeng/vivid/touch/mako/97:20150213:20150210/12295/ubuntu_system_settings/2056866/
[10:45] <psivaa_> the crash file is attached there
[10:45] <seb128> psivaa_, thanks
[10:45] <psivaa_> seb128: np
[10:45] <mandel> sil2100, line 74 is syncing from another silo, but yet that is not what we want to do for rtm, removing the stuff under "additional source.." and reconfiguring should be neough, right?
[10:46] <mandel> Mirv, maybe you know too ^
[10:49] <sil2100> mandel: yeah
[10:49] <mandel> sil2100, sweet, thx
[10:49] <mandel> sil2100, I wanted to be 100% sure
[10:50] <sil2100> mandel: although we might need to remove the packakages by hand from the PPA itself
[10:50] <sil2100> Not sure if the new build job is fixed in regards of that
[10:50] <mandel> sil2100, ok, I''ll try and we'll see
[11:00] <Mirv> davmor2: seb128: there is u-s-s bandaid now in the PPA tested to be working - storage info commented out, all other parts work. Laney has another branch that I'll take a look which may bring us initially "storage info is there, but not yet correct"
[11:00] <Laney> no
[11:01] <Mirv> ok, so not bringing that
[11:01] <Laney> you might need to combine, my commit only gets the free space calculation working
[11:01] <Mirv> oh, ok. well, I'll look at it.
[11:01] <Laney> it's a problem because they removed this storageType thing >:(
[11:01] <Laney> so one other bandaid is to copy that function somewhere
[11:03] <davmor2> Laney, Mirv: the one important question is this, can you enable developer mode and reset the device?  As far as I am concerned those 2 items are the critical ones on the about page, Anything above that is a bonus for a bandaid till the full fix is in :)
[11:04] <davmor2> Laney, Mirv:  I'm assuming it will be longwinded but minor fixes to get everything else up and running right?
[11:05] <Mirv> davmor2: I tested developer mode, testing reset too although I assume it doesn't use much Qt functionality what it's doing
[11:05] <Mirv> davmor2: yes so the current bandaid is purely commenting out two sections in QML http://pastebin.ubuntu.com/10202733/
[11:06] <Mirv> so that the rest of the page that doesn't use removed Qt features can load
[11:07] <Mirv> davmor2: so your usual about page sanity test is to switch developer mode + use reset?
[11:07] <Laney> if you take my commit I think you'll be able to have the storage item there but you should make it un clickable
[11:07] <Laney> i.e. just turn off Storage.qml
[11:07] <Mirv> ok Laney
[11:07] <Laney> but try it
[11:07] <Mirv> trying
[11:07] <Laney> not sure I got as far as test building
[11:07] <Laney> ;-)
[11:08] <davmor2> Mirv: For sanity testing I just need to enable developer mode for the upgrade test, in the regression testing though it is deeper.   But it is good to know that they both work for that.  :)
[11:08] <Mirv> yeah reset seems to have worked, back to the wizard now
[11:43]  * sil2100 off to lunch
[12:11] <Mirv> Laney: seb128: made laney's branch a WIP MP and commented what I needed to do to get the portion of the functionality back: https://code.launchpad.net/~laney/ubuntu-system-settings/storageinfo-5.4/+merge/249630
[12:12] <Mirv> combined with only a single commenting out of the StorageInfo in the qml file this time
[12:12] <Mirv> so the free space count is back
[12:17] <rsalveti> mandel: hey, trying to understand the landing then
[12:17] <rsalveti> mandel: we got a ciborium one for vivid and rtm
[12:17] <rsalveti> mandel: are you landing the vivid one now?
[12:17] <rsalveti> mandel: and also, are we ready to set the rtm one to needs qa?
[12:27] <rsalveti> Mirv: great, just let me know when you rebuild your packages again (removing the ~test)
[12:27] <rsalveti> so we can give another round of testing
[12:28] <Mirv> rsalveti: it's done already, but Kubuntu is keeping us back so I'll wait for Monday anyhow
[12:29] <Mirv> there are no changes in any package other than the version string change in changelog
[12:32] <rsalveti> Mirv: oh, great then
[12:37] <Mirv> mandel: thanks, I'll rebuild it in the 5.4 PPA after that
[12:47] <mandel> rsalveti, yes, I'm going to test the rtm now and will set it ready for Qa to land
[12:48] <rsalveti> mandel: great, and for vivid? can't we just land it now?
[12:48] <rvr> bfiller: boiko: ping
[12:48] <mandel> rsalveti, yes,  but we need to coordinate with Mirv AFAIK is ok, is that correct?
[12:49] <Mirv> mandel: rsalveti: I landed it already and rebuild is ongoing in the Qt 5.4 PPA
[12:49] <mandel> perfect
[12:49] <Mirv> since you marked it as tested
[12:49] <mandel> Mirv, yes, it was tested
[12:50] <rvr> bfiller: boiko: I'm testing silo 11. Taking a look to the silo diff, there is a change to factory-wipe.conf
[12:50] <rvr> bfiller: boiko: Line 69 https://pastebin.canonical.com/125629/
[12:51] <rvr> bfiller: boiko: Can you confirm or deny?
[12:51] <rsalveti> mandel: Mirv: even better
[12:52] <mandel> rsalveti, I'm testing in rtm ciborium and will set it ready for qa in a few mins
[12:54] <mvo> hm, the citrain gives me a hard time assigning #92 (click). I get a fatal error
[13:00] <boiko> rvr: checking
[13:01] <boiko> rvr: hmm, that doesn't seem right
[13:01] <boiko> rvr: bfiller: it looks like something landed on rtm and was not committed to bzr
[13:02] <rsalveti> mandel: thanks
[13:02] <rvr> boiko: I'm using citrain-diff tool by brendand
[13:02] <rvr> boiko: Do you think the diff is right?
[13:03] <boiko> rvr: so, the diff for ubuntu-touch-session should only contain this: https://code.launchpad.net/~tiagosh/ubuntu-touch-session/rtm-14.09-fix-1413316/+merge/249230
[13:04] <boiko> rvr: it seems the ubuntu-touch-session RTM bzr branch is outdated
[13:05] <rvr> boiko: As far as I remember, factory_wipe fix was done via device tarball, can that explain it?
[13:07] <boiko> rvr: yep, that probably explains it
[13:07] <boiko> rvr: let me compare the commit history with the changelog, just a sec
[13:10] <mvo> hey trainguards, I have trouble assigning a silo for #92 (new click release). am I doing something wrong?
[13:10] <mvo> I got this: https://ci-train.ubuntu.com/job/prepare-silo/4098/
[13:10] <mvo> 2015-02-13 12:58:25,797 ERROR Could not find REQUEST_ID 1423832036072 in any silo.
[13:11] <mandel> rsalveti, set to be tested by QA
[13:12] <boiko> rvr: yep, ricmm's changes are not in bzr, we need to sync that somehow
[13:12] <boiko> rvr: I mean, before landing silo 11
[13:12] <rsalveti> mandel: awesome
[13:12] <mandel> rsalveti, dealing with the udm stuff to get it landed today too
[13:13] <rsalveti> mandel: cool
[13:13] <rsalveti> landing day
[13:14] <boiko> rvr: I'll go for lunch now, but right after I'm back I will deal with that, ok?
[13:20] <rvr> boiko: Ok
[13:23] <tvoss_> trainguards, can I get a silo for line 93?
[13:29] <jibel> sil2100, testing report sent. Same pass rate than previous run with more tests executed.
[13:42] <sil2100> jibel: o/
[13:42] <sil2100> Thanks!
[13:42] <sil2100> tvoss_: on it
[13:43] <tvoss_> sil2100, thx
[13:49] <sil2100> jibel, john-mcaleely, ogra_, pmcgowan: so it seems we're green on promoting 234 to the rc channel
[13:49] <sil2100> The only problem I see now is...
[13:49] <john-mcaleely> uhoh
[13:50] <sil2100> The idea was to promote those 2-week images to the ubuntu-touch/rc/bq-aquaris.en channel, but what about the emulator and mako images?
[13:50] <sil2100> I mean, we could have those in that channel too
[13:50] <sil2100> But the name indicates 'bq-aquaris.en' - so I doubt anyone would actually see or use those images on mako
[13:50] <sil2100> ;)
[13:50] <sil2100> Since who would flash their mako with an aquaris channel?
[13:50] <john-mcaleely> hm. maybe we need a 14.09/rc ?
[13:51] <sil2100> Yeah, what I would propose is creating an alias to the aquaris channel
[13:51] <pmcgowan> so I will defer to john-mcaleely  but we do not want the ota going to krillins in the field yet
[13:51] <sil2100> I know it's a bit dirty, but would work for sure
[13:52] <john-mcaleely> sil2100, definately a bit dirty, but sure, why not
[13:52] <john-mcaleely> pmcgowan, yeah, it's all fine so long as we stay out of stable/
[13:53] <john-mcaleely> and having a more generic name for people to flash makos from seems good
[13:54] <pmcgowan> not sure we need another channel, folks can use proposed or wait?
[13:54] <ogra_> sil2100, i would just leave these arches out
[13:54] <pmcgowan> no one using stable would flash a special channel
[13:54] <john-mcaleely> isn't it a bit unfair to the mako folks?
[13:55] <pmcgowan> I suspect few mako stable users?
[13:55] <john-mcaleely> but sure, mako is a dev tool, so stable or proposed might be all you need
[13:55] <john-mcaleely> indeed
[13:55] <john-mcaleely> do we need it for test coverage (ie only mako exercises some areas?)
[13:56] <sil2100> We could leave them out, sure, but it does seem to be a little bit of a waste
[13:56] <pmcgowan> dont think so, since mako has less stuff than krillin
[13:56] <Mirv> sil2100: robru: help! I removed ciborium MP from 005 and replaced it with manual upload to do a simple rebuild now that ciborium landed from another silo, and build job is failing https://ci-train.ubuntu.com/job/ubuntu-landing-005-1-build/108/console - I'd need fully succeeding build run of 005 (and publish later on) by Monday
[13:56] <bfiller> boiko: can you check with rsalveti or ricmm on that? looks like ubuntu-touch-session may have been sycned from vivid and the rtm branch not updated? maybe we should just be re-syncing if that is the case?
[13:57] <Mirv> so I think it has a bit somewhere that tracks the now obsolete MP related build number
[13:57] <sil2100> Mirv: uh oh! Might be something with the new build job, let me dive into that but robru would be the best person to poke
[13:57] <john-mcaleely> For me, this would be for an stable/ mako community of non-devs
[13:57] <john-mcaleely> probably very small, but perhaps important?
[13:58] <Mirv> sil2100: robru: this is also a situation that may not have happened before - removing MP and replacing it straight away with manual upload. I could workaround it of course by doing empty MP instead.
[13:58] <Mirv> sil2100: robru: because usually train packages are of course handled via MP:s, but the empty MP:s did not work too well in one previous Qt landing so I've chosen this track plus manual syncing of certain trunks instead
[13:59] <sil2100> Mirv: but I remember we allowed things like that before at least
[13:59] <Mirv> sil2100: it clearly remembers it used to do a build of ciborium from MP with a certain bumped version number, and is now confused since there's another direct upload instead
[14:03] <sil2100> A reconfigure should wipe his .project file in the normal case and re-create it, but let me check how it's right now
[14:09] <Mirv> sil2100: I reconfigured (via prepare-silo) the silo after removing MP + adding manual source
[14:11] <jdstrand> hey-- I'm on 14.09-proposed r194 mako and over the last two days I saw some bad behavior that I haven't seen in months and months
[14:12] <jdstrand> specifically, twice I had to reboot my phone because side edge gestures didn't work. I could swipe from the top for notifications, and swipe from the bottom to hide that, but I could not swipe from the left to reveal the launcher or from the right to switch apps
[14:13] <mvo> hey trainguards, I have trouble assigning a silo for #92 (new click release). am I doing something wrong?
[14:13] <mvo> (sorry for re-asking, my network was down for some minutes)
[14:13] <jdstrand> has anyone seen this?
[14:13]  * jdstrand didn't see it mentioned on the list
[14:16] <jdstrand> looking at http://people.canonical.com/~ogra/touch-image-stats/rtm/, it is not immediately obvious what might've changed
[14:16] <jdstrand> that might cause this
[14:16] <ogra_> you need to map the mako version against krillin
[14:17] <ogra_> the rtm changelogs above are all against krillin version numbers
[14:17]  * jdstrand just went by the date
[14:17] <ogra_> ah, k
[14:17] <ogra_> yeah, that should be fine
[14:17] <jdstrand> went back for the last 5 changes
[14:18] <jdstrand> maybe I'll do all of Feb just to be tidy
[14:18] <sil2100> mvo: hey!
[14:18] <sil2100> mvo: let me look
[14:19] <sil2100> mvo: hmm, #92 doesn't seem to look like your landing, can you refresh the spreadsheet?
[14:19] <sil2100> mvo: I think it might be bugged on your side and it didn't register you entering the details
[14:20] <sil2100> ogra_, jibel, pmcgowan, john-mcaleely: so for now I'll promote 234 to the rc channel for krillin and wait for Steve with the rest of the devices
[14:20] <rvr> mandel: Silo 0 has no associated bug in the spreadsheet
[14:20] <kenvandine> jgdx, i kicked a rebuild of silo 15 because we've had a bunch of landings since that
[14:21] <john-mcaleely> sil2100, ac
[14:21] <john-mcaleely> k
[14:21] <ogra_> sil2100, +1
[14:22] <jgdx> kenvandine, thanks
[14:22] <kenvandine> jgdx, so what's the status of that stuff?  have we nailed down the issues found in the rtm silo?
[14:22] <kenvandine> jgdx, sorry i haven't been following it lately
[14:22] <pmcgowan> jdstrand, there is an open bug for edges not working, I have seen it
[14:23] <jdstrand> pmcgowan: ah, good to know
[14:24] <pmcgowan> jdstrand, if you have more info https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1408263
[14:25] <jgdx> kenvandine, it's blocked by https://bugs.launchpad.net/barajas/+bug/1378778
[14:25]  * jgdx adds that to spreadsheet
[14:25] <jdstrand> pmcgowan: that's it exactly. I'll subscribe and see if I can help with more info
[14:26] <jgdx> kenvandine, ah- sorry. Bit late
[14:26] <pmcgowan> jdstrand, and I have had them come back without a reboot, quite odd
[14:26] <kenvandine> jgdx, ah, bummer... so it's blocked by another bug :/
[14:29] <mvo> sil2100: ok, let me try again with a different browser
[14:29] <jdstrand> pmcgowan: no reboot, that is odd. though in the moment I want to use the phone, I really want to use it (both cases needed to make a call)
[14:31] <pmcgowan> jdstrand, same, I launched dialer from the app scope to get to it, then after the call edges worked
[14:32] <jdstrand> yeah, unfortunately I didn't have the app scope up
[14:32] <jdstrand> I had the music player once and something else the other time (I don't remember)
[14:33] <bzoltan_> mvo:  I subscribed to your landing and I will help it with running the SDK's functional tests too
[14:33] <mvo> sil2100: indeed, none of the information I put there was there its there now (I think) in line #95 but still no cookie, i.e. I still get a jenkins error when I try to start the build
[14:33] <mvo> sil2100: eh, I mean when I try to assign a silo
[14:33] <sil2100> mvo: let me try it then
[14:33] <sil2100> mvo: it's for vivid, right? As the series wasn't assigned
[14:33] <mvo> oh, geeh
[14:33] <mvo> sorry
[14:34]  * mvo feels a bit silly now
[14:34] <sil2100> mvo: assigning :) No worries!
[14:34] <sil2100> ubuntu/landing-013 for you
[14:34] <mvo> \o/
[14:37] <sil2100> [14:37] <sil2100> (krillin #234, only to the rc channel)
[14:38] <sil2100> (images mako #194 and generic_x86 #188 wait for additional decision-making)
[14:44] <john-mcaleely> downloading and updating on my handset
[14:44] <john-mcaleely> I wonder if I'm the only user of that channel :-)
[14:44] <john-mcaleely> thanks sil2100
[14:44] <sil2100> Mirv: ok, digging deeper into your issue now, it seems the train didn't change the .project file, which is probably something that it should do ;p
[14:45] <sil2100> john-mcaleely: \o/ I might use it as well, but since I reflash my device like crazy between rtm and vivid, I guess I wouldn't really feel any merits of using this channel ;)
[14:46] <john-mcaleely> heh
[14:46] <sil2100> jibel, davmor2: thanks for the testing guys!
[14:46] <john-mcaleely> +1
[14:47] <sil2100> Mirv: I think there might be a small misconception regarding handling of the additional source uploads indeed
[14:49] <sil2100> pstolowski: oh, your landing seems to have found a small issue in our new build job ;)
[14:49] <sil2100> pstolowski: I'll be publishing as I suppose train-related uploads saw worse things, but it seems the train currently doesn't trim down the commit-message to the first newline
[14:50] <sil2100> Anyway, publishing
[14:53] <Mirv> sil2100: can the .project file be manually changed or should I simply opt for empty MP to get back on track?
[14:53] <pstolowski> sil2100, ah.. what was that? the remark about no abi breakage made in the commit msg?
[15:00] <Saviq> elopio, could we ask you for a review of https://code.launchpad.net/~josharenson/unity8/screenshot_ap_test/+merge/249542 please? :)
[15:00] <elopio> Saviq: of course. I'm on it.
[15:02] <sil2100> Mirv: I could hack the .project file, but maybe a cleaner way would be to include an empty MP for now, if that's fine with you of course
[15:03] <sil2100> Mirv: since I see the problem is that when a build is started as watch_only, all the steps that potentially re-generate the .project file are skipped
[15:04] <Mirv> sil2100: robru: empty MP for this one is ok to me
[15:05] <Saviq> trainguards, silo for line 96 please :)
[15:07] <sil2100> Saviq: o/
[15:15] <boiko> trainguards: can I please get a reconfigure on vivid silo 007?
[15:15] <sil2100> boiko: sure, what changed?
[15:15] <boiko> sil2100: I added a new component (address-book-app) there
[15:15] <sil2100> Ah, new component, on it
[15:16] <boiko> sil2100: yep :)
[15:16] <sil2100> boiko: should be good :)
[15:17] <boiko> sil2100: thanks!
[15:23] <Saviq> sil2100, sorries, can have reconfigure for vivid silo 18, somehow managed to miss a project+MP
[15:23] <sil2100> Saviq: sure thing
[15:25] <sil2100> Saviq: done
[15:29] <Saviq> sil2100, thanks
[15:31] <Saviq> ohnoes :?
[15:32] <boiko> rvr: where can I get that script that generates the packaging diff? I want to make sure it is ok now
[15:32] <rvr> boiko: One moment
[15:33] <rvr> boiko: https://code.launchpad.net/~brendan-donegan/phablet-tools/citrain-diff
[15:33] <rvr> boiko: http://bazaar.launchpad.net/~brendan-donegan/phablet-tools/citrain-diff/view/head:/citrain-diff
[15:34] <boiko> rvr: nice! thanks!
[15:38] <plars> kenvandine: regarding the system-settings ci issue, talking to fginther about it now so I wanted to move here...
[15:38] <plars> kenvandine: how are you running it when you try it locally? are you using phablet-test-run? That's all we do in CI
[15:38] <plars> so assuming you are running it the same way, we struggle to find anything that's different
[15:39] <kenvandine> yeah, phablet-test-run
[15:39] <boiko> rvr: I am doing a last test on silo 11, but the diff looks ok now at least
[15:39] <kenvandine> plars, i thought in CI there was a script run that does a bunch of restarts?
[15:39] <kenvandine> so it's a little different
[15:39] <plars> kenvandine: restarts?
[15:39] <rvr> boiko: Did you change anything?
[15:40] <kenvandine> maybe that's just smoke tests?
[15:40] <kenvandine> something that restarts the device between tests
[15:40] <kenvandine> it seemed much more complicated that just phablet-test-run on the whole thing
[15:40] <plars> kenvandine: the CI scripts for smoke and ci all just use the standard phablet tools for provisioning the device (ubuntu-device-flash), setting it up and running it
[15:41] <kenvandine> phablet-test-run -r 0000 ubuntu_system_settings
[15:41] <kenvandine> is all i did
[15:41] <plars> kenvandine: ah, right in smoke we reboot between test suites. But it's still just phablet-test-run each time
[15:41] <kenvandine> does that happen in CI too?
[15:41] <kenvandine> or just smoke?
[15:42] <plars> kenvandine: well it's just running one suite in ci, so no reboot between because there is no between
[15:42] <kenvandine> ok
[15:42] <kenvandine> i didn't flash my device right before
[15:42] <kenvandine> which i don't want to do on a friday, my mako is my daily driver right now :)
[15:42] <plars> kenvandine: well that's something we do differently
[15:43] <fginther> kenvandine, when running MP tests, there is a specific script that can be used: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/README-cli.rst#L81
[15:43] <plars> kenvandine: we always provision before and start with a fresh environment
[15:43] <fginther> kenvandine, I have a mako sitting here unused, I can give try to reproduce it locally
[15:43] <kenvandine> fginther, i'd appreciate it
[15:44] <Saviq> sil2100, aah, build job rewrote the silo metadata, please reconfigure again
[15:44] <kenvandine> we'd really like to figure out what caused it to start failing
[15:44] <kenvandine> it was reliable for weeks...
[15:44] <fginther> kenvandine, I'll let you know the results, at least try to make sure the problem is specific to a set of devices
[15:44] <fginther> err, s/is specific/is not specific/
[15:44] <rvr> boiko: bfiller: Approving silo 9.
[15:45] <bfiller> rvr: thanks
[15:45] <boiko> rvr: thanks, as soon as it lands I can rebuild silo 11
[15:59] <sil2100> davmor2, jibel: if we could get someone signing-off the oxide landing today it would be a very nice thing, since it would give us the whole weekend of dogfooding texting
[15:59] <sil2100> s/texting/testing
[16:00] <sil2100> It might be abit too much for QA in our TZ, but maybe it could be handed off to ToyKeeper somehow?
[16:00] <jibel> sil2100, davmor2 is on it but it's huge.
[16:07] <bzoltan_> Mirv: ^ what the hack is that?
[16:14] <om26er> bzoltan_, Hey!
[16:15] <sil2100> bzoltan_: uh oh, is that during build time?
[16:17] <rhuddie> boiko, I am testing silo 3, dialer-app autopilot tests. which tests should be fixed by this silo? I am seeing 4 failures.
[16:19] <sil2100> bzoltan_: hmmm, where does this message come from actually? Am I blind or did the build actually succeed?
[16:19] <boiko> rhuddie: you see 4 failures with the silo or without it?
[16:19] <rhuddie> boiko, both.
[16:20] <boiko> rhuddie: it was supposed to fix all failures, mind providing me some logs with the failures so that I check them?
[16:24] <rhuddie> boiko, here are the logs. I've just copied the call stacks: http://pastebin.ubuntu.com/10206746/
[16:29] <Saviq> sil2100, I'll need another reconfigure of vivid silo 18 please, the train rewrote the config, 'cause was building already...
[16:29] <Saviq> also, trainguards, I can has silo for line 97 please
[16:29] <sil2100> ogra_, jibel, davmor2, popey, robru: I might be a bit late for the meeting since I need to fetch my girl from the train station
[16:30] <sil2100> Saviq: assigned, now reconfiguring
[16:30] <Saviq> sil2100, faster than light!
[16:32] <bfiller> sil2100: can you publish rtm 9 please?
[16:46] <rsalveti> davmor2: jhodapp: kgunn: sil2100: https://bugs.launchpad.net/ubuntu/+source/mediaplayer-app/+bug/1421721
[16:46] <rsalveti> will check with some older images now
[16:46] <jhodapp> rsalveti, cool thanks
[16:50] <slangasek> is proposed-migration in place for 14.09-factory{-proposed,}, like it is for 14.09? wgrant, infinity, cjwatson?
[16:51] <cjwatson> slangasek: yes
[16:52] <slangasek> cjwatson: great, thanks
[16:52] <cjwatson> slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/ubuntu-rtm/ has the output
[16:55] <popey> zbenjamin: on a different pc than the one I usually use, I'm getting "Unable to find a shell" when I maintain my kit. We have seen this before haven't we?
[16:55] <sil2100> Ok, made it on time
 sil2100, faster than light!
[16:56] <ogra_> :D
[16:56] <kgunn> trainguards hey there, could i get a reconfig on vivid silo 0
[16:56] <sil2100> kgunn: on it
[16:56] <sil2100> bfiller: on it too!
[17:06] <boiko> rhuddie: ok, I will have to work on those, two of them I don't really know why they happen (the second and the third errors), but the other two I have seen happening once, I will work on those
[17:07] <rhuddie> boiko, alright thanks.
[17:21] <om26er> alexabreu, Hi!
[17:21] <alexabreu> om26er, hey
[17:21] <om26er> alexabreu, I have verified the fix in silo15. what part of the TestPlan I need to run ?
[17:21] <om26er> the testplan seems a bit different than most projects
[17:22] <alexabreu> om26er, only the 2 first bits (cordova is not related)
[17:23] <om26er> alexabreu, hmm, ok. So nothing to test on the device except to make sure apps start fine ?
[17:25] <alexabreu> om26er, mmh the TP can be expanded a bit (I'll do it), but otherwise yeah
[17:29] <om26er> alexabreu, it'll be helpful if you add a testcase for the bug fix in the silo.
[17:31] <alexabreu> om26er, it is there already, just running on the device didn't workw/o the fix
[17:35] <rsalveti> jhodapp: image 96 is fine
[17:36] <jhodapp> rsalveti, wow, so it broke just with 97
[17:36] <rsalveti> jhodapp: yeah
[17:36] <jhodapp> rsalveti, got a link to what changed? I never know how to find that lol
[17:36] <rsalveti> jhodapp: there was a mediaplayer-app update
[17:36] <rsalveti> jhodapp: just updated the bug
[17:36] <jhodapp> oh really
[17:37] <jhodapp> rsalveti, who committed it that we should talk to?
[17:37] <rsalveti> jhodapp: https://launchpad.net/ubuntu/+source/mediaplayer-app/0.20.5+15.04.20150213-0ubuntu1
[17:37] <rsalveti> but need to update it from 96 and see
[17:37] <rsalveti> will do that in a minute
[17:37] <jhodapp> k
[17:41] <alexabreu> om26er, I added 2 test cases if you want to run them
[17:42] <om26er> alexabreu, yes, I am in the process of setting up QtCreator.
[17:46] <charles> trainguards, line 62 (rtm silo 19) is in error, the wrong MPs were pasted into the spreadsheet. can they be cleared out and I'll redo
[17:47] <robru> charles: yeah just make sure the right MPs are in there and I'll update the silo.
[17:47] <charles> robru, ack
[17:48] <bzoltan_> om26er: who did you ping about that RTM branch?
[17:48] <om26er> bzoltan_, I pinged about silo 14
[17:48] <bzoltan_> om26er:  who did you ping?
[17:49] <om26er> bzoltan_, I pinged you
[17:50] <om26er> bzoltan_, I just wanted to know wanted to know is how do I verify the fix ? seems related to translations
[17:50] <bzoltan_> om26er: "No response from the Devs regarding a way to verify the fix. " != "Hey" :)
[17:51] <om26er> bzoltan_, Yeah, I had to put in a reason for why I was not testing that silo. Perhaps bad use of words from me.
[17:55] <bzoltan_> om26er:  I think you could go ahead and valiate the sile from the point of regression and general functionality check. Pete Woods and Andrew Hayzen  are the folks who should make the call based on this - https://bugs.launchpad.net/ubuntu-translations/+bug/1327419
[17:55] <fginther> kenvandine, I ran the tests for the packages associated with https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/982/testReport/junit/ubuntu_system_settings.tests.test_security/SecurityTestCase/test_locking_control_value/
[17:56] <fginther> kenvandine, I saw 109 failures when useing "phablet-test-run -r 0000 ubuntu_system_settings" and a few more using the run-mp script
[17:57] <fginther> kenvandine, Most of the failures log the message "Appears process has already exited"
[17:57] <kenvandine> fginther, humm... do you have python3-evdev installed?
[17:57] <kenvandine> at one point that wasn't getting installed as a dep
[17:57] <kenvandine> but that'll cause that number of failures
[17:57] <fginther> python-evdev is installed
[17:58] <kenvandine> python3-evdev?
[17:58] <fginther> oops, yes that too:
[17:58] <kenvandine> hmm
[17:58] <fginther> python3-evdev:
[17:58] <fginther>   Installed: 0.4.1-0ubuntu3
[17:58] <kenvandine> dunno
[17:58] <kenvandine> something's wrong there :)
[17:59] <kenvandine> that's worse than what happens in CI :)
[18:01] <bzoltan_> om26er: and if you would have checked the MR you could have seen that it is covered with unit tests -> https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/i18ntagRTM/+merge/249357
[18:01] <om26er> bzoltan_, sure, I'll do that. I am testing a silo, which take a few minutes.
[18:02] <om26er> bzoltan_, yeah, I saw the MR.
[18:02] <bzoltan_> om26er:  and the unit test results are available in the build logs -> https://launchpadlibrarian.net/197449045/buildlog_ubuntu-rtm-14.09-armhf.ubuntu-ui-toolkit_1.1.1298%2B15.04.20150212~rtm-0ubuntu1_UPLOADING.txt.gz
[18:02] <bzoltan_> om26er:  look for "tst_i18n: ********* Start testing of tst_I18n *********"
[18:04] <om26er> bzoltan_, thanks for the link. So I guess I'll just work on general checking around things for regressions.
[18:04] <bzoltan_> om26er:  But fundamentally I would love to see pete-woods's ack on the implementation. He was requesting that feature as dependency for fixing the #1327419
[18:05] <om26er> bug 1327419
[18:05] <om26er> _mup_ is missing.
[18:05] <bzoltan_> om26er: :) well, do not be soft on us. Give your most critical eyes ... it is an OTA release. Serious stuff.
[18:06] <om26er> Sounds like military training :D
[18:07] <fginther> kenvandine, let us know if there is any more info we could provide. At this time, the issues appears to be outside of how the test is being executed, so I'll leave it in your hands.
[18:07] <kenvandine> fginther, ok, thanks for trying
[18:07] <kenvandine> fginther, at least it works better in CI than it does on your device :)
[18:08] <fginther> kenvandine, the last two image tests don't look much better though :-( http://ci.ubuntu.com/smokeng/vivid/touch/mako/97:20150213:20150210/12295/ubuntu_system_settings/
[18:08] <kenvandine> fginther, could you try it one more time with what's in vivid?
[18:08] <kenvandine> oh my
[18:08] <fginther> kenvandine, do you mean just a standard image, no MPS?
[18:08] <kenvandine> yeah
[18:09] <fginther> kenvandine, sure
[18:09] <kenvandine> thx
[18:09] <kenvandine> that's what i was running the other day
[18:11] <kenvandine> fginther, the smoke test does include a crash file
[18:12] <kenvandine> jgdx, the smoke testing crash file shows that haptic feedback stuff too
[18:15] <robru> sil2100: what's up with rtm landings? ^
[18:15] <robru> can I land stuff? I thought gates were closed
[18:15] <sil2100> robru: yeah :)
[18:15] <sil2100> robru: as per topic, all is good, we're open
[18:16] <robru> sil2100: ok thanks
[18:16] <davmor2> sil2100, dbarth: oxide-qt passes all day and 2 minor issues, one of which is the ebay site itself and the other looks like it is a weather app issue \o/
[18:17] <robru> charles: oh sorry, did you put the right MPs in row 62 yet?
[18:20] <kenvandine> fginther, the smoke testing took a dive between the 10th and 12th
[18:20] <kenvandine> fginther, 90.9% pass on the 10th
[18:20] <kenvandine> and 6.3% on the 12th
[18:21] <om26er> alexabreu, Hey
[18:21] <alexabreu> om26er, hey
[18:21] <charles> robru, not yet, looks like ubuntu-themes didn't have an rtm branch yet so I'm setting that up
[18:21] <om26er> alexabreu, since I installed the silo on the device, I wonder why am I testing the Ubuntu SDK ?
[18:21] <robru> charles: ah ok, just ping me when you're ready then
[18:21] <fginther> kenvandine, it looks like there was a new version of ubuntu-system-settings, 0.3+15.04.20150211.1-0ubuntu1. But not sure if that coincides to the failures
[18:22] <kenvandine> the failures seem to be low in the stack
[18:22] <kenvandine> all starting with haptic feedback stuff
[18:22] <kenvandine> so i suspect one of the qt packages
[18:22] <om26er> alexabreu, also "Run HTML5 Application on Device" is greyed out due to some reason.
[18:22] <alexabreu> om26er, mmh not sure I get what you are saying, ... you are testing html5 apps, making sure that they run properly
[18:22] <kenvandine> which image 96 on the 12th had a bunch of qt related packages
[18:22] <kenvandine> and mir
[18:22] <kenvandine> etc
[18:23] <alexabreu> om26er, the TP needs an update, the option has been removed (and included in the usual "run")
[18:24] <kenvandine> jgdx, interesting, one thing that landed between the good smoke tests and bad smoke tests is the other vibrate branch
[18:24] <kenvandine> jgdx, which is hidden, so not even shown
[18:25] <kenvandine> but the crashes all seem to stem from haptic feedback related stuff
[18:27] <kenvandine> huge list of changes in image 96 http://people.canonical.com/~ogra/touch-image-stats/96.changes
[18:29] <kenvandine> the pass rate went from 90.9% in #95 to 6.3% in #96
[18:30] <om26er> alexabreu, when I run it, it always executes the app on the desktop
[18:30] <om26er> even I have my phone connected with adb enabled
[18:30] <alexabreu> om26er, you have to change the kit, and select the one associated w/ the device
[18:31] <sil2100> kenvandine: remember you can have changes with CI Train landing descriptions in http://people.canonical.com/~lzemczak/landing-team/ubuntu/vivid/96.commitlog
[18:31] <om26er> alexabreu, "there is currently no kit defined for your device"
[18:31] <kenvandine> sil2100, right, thanks!
[18:31] <om26er> I tried 'Autocreate' button that gives an error
[18:31] <alexabreu> om26er, go to the project> tab on the left and add one (Add kit)
[18:32] <alexabreu> om26er, if you need to create one, go to the device tab and click on the device connected and there is a way to create a kit for it
[18:34] <jhodapp> rsalveti, I bet it was revision 326 and 328 that broke mediaplayer-app: http://bazaar.launchpad.net/~phablet-team/mediaplayer-app/trunk/revision/326
[18:34] <jhodapp> http://bazaar.launchpad.net/~phablet-team/mediaplayer-app/trunk/revision/328
[18:34] <rsalveti> jhodapp: I noticed we're missing one package in this image
[18:34] <rsalveti> jhodapp: qtdeclarative5-ubuntu-ui-extras0.2
[18:34] <jhodapp> rsalveti, which one?
[18:35] <rsalveti> jhodapp: the image was built before the new seeds got published
[18:35] <jhodapp> rsalveti, well those changes supposedly remove the need for that package, so that's probably why it was removed
[18:35] <jhodapp> rsalveti, ah, that's probably why then
[18:35] <rsalveti> right, but then bill requested qtdeclarative5-ubuntu-ui-extras0.2 to be included in the seeds
[18:35] <rsalveti> but still didn't try
[18:36] <rsalveti> jhodapp: doing apt-get update/upgrade now and will see
[18:36] <jhodapp> rsalveti, ok, interesting that it requires qtdeclarative5-ubuntu-ui-extras0.2 but I don't see an include in the VideoPlayer.qml for that version
[18:36] <rsalveti> jhodapp: right
[18:36] <rsalveti> probably a bug indeed
[18:36] <rsalveti> bfiller: ^
[18:37] <rsalveti> jhodapp: but worked fine after apt-get update/upgrade
[18:37] <rsalveti> jhodapp: going to trigger a new image
[18:37] <jhodapp> oh really
[18:37] <jhodapp> nice
[18:37] <rsalveti> hm, http://iso.qa.ubuntu.com/qatracker/milestones/326/builds says rebuilding but I don't see that yet in https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/
[18:37] <rsalveti> but should show up soon
[18:37] <kenvandine> jhodapp, bfiller had said he missed an import that needed to be removed, in mediaplayer
[18:37] <kenvandine> and had a fix pending for it
[18:38] <jhodapp> kenvandine, I see that as revision 328 for mediaplayer-app
[18:38] <jhodapp> kenvandine, so he was saying it just hasn't landed?
[18:38] <bfiller> rsalveti: it's fixed in new mediaplayer-app
[18:38] <kenvandine> yeah
[18:38] <kenvandine> i missed it in this first branch
[18:39] <rsalveti> bfiller: great
[18:39] <bfiller> jhodapp, rsalveti : should be in next image, just apt-get install it
[18:39] <jhodapp> bfiller, so the fix is to just remove the qtdeclarative5-ubuntu-ui-extras0.1 dependency right, doesn't it require qtdeclarative5-ubuntu-ui-extras0.2 though?
[18:39] <kenvandine> rsalveti, we still need the image with the seed change though :)
[18:39] <bfiller> jhodapp: no
[18:39] <rsalveti> kenvandine: the seeds was changed already
[18:39] <kenvandine> rsalveti, yeah, but no images since
[18:39] <rsalveti> started a new one, waiting now :-)
[18:39] <bfiller> jhodapp: mediaplayer-app doesn't rely on extras at all anymore but you need the latest version of it
[18:40] <kenvandine> rsalveti, thanks!
[18:40] <jhodapp> bfiller, ok
[18:41] <bfiller> jhodapp: the fixed version of mediaplayer-app has landed but just not in the image yet
[18:41] <alexabreu> trainguards can you reconfigure RTM silo13  pls?
[18:41] <jhodapp> bfiller, makes sense, thanks
[18:47] <rsalveti> jhodapp: next image should be all good then
[18:47] <jhodapp> rsalveti, yeah, confirmed that it's working after an upgrade
[18:48] <om26er> alexabreu, I see this error when starting the app: http://i.imgur.com/hTlsspB.png
[18:48] <rsalveti> jhodapp: great
[18:48] <jhodapp> rsalveti, testing silo 17
[18:48] <om26er> alexabreu, am I using wrong version of Ubuntu or something
[18:48] <rsalveti> jhodapp: cool
[18:48] <jhodapp> rsalveti, is anyone debugging the vivid hanging issues?
[18:49] <alexabreu> om26er, mmmh you should be using the ubuntu-sdk-14.10 sdk
[18:49] <rsalveti> jhodapp: will jump on that later today I hope
[18:49] <robru> alexabreu: on it
[18:49] <jhodapp> rsalveti, awesome, let me know if you need any help
[18:49] <rsalveti> jhodapp: sure, thanks
[18:50] <alexabreu> om26er, but the debug one is fine (the debug policy is afaik automatically added by qtc, but has to be removed when uploading to the store)
[18:54] <om26er> alexabreu, thats not in the list: http://i.imgur.com/9YjxI2p.png
[18:55] <om26er> should I install 15.04 on my desktop
[18:55] <alexabreu> om26er, try the 14.10-dev2, or install 15.04
[18:56] <om26er> Hahaha, says : 14.10-dev2 is obsolete.
[19:30] <charles> robru, the branches in line 62 are fixed now
[19:32] <robru> charles: ok, silo is good to go
[19:32] <charles> robru, thanks
[19:32] <robru> charles: you're welcome
[19:56] <om26er> bzoltan_, where can I see the ui-toolkit test plan results ?
[20:25] <dobey> fginther: hey. so, my branch that adds the autopkgtest bits and makes the autopilot tests run is in trunk now. the tests still won't run under mir yet, but i wonder if we should enable them so they get run on MPs, and just not fail MPs for failed AP tests yet?
[20:33] <zbenjamin> popey: the could not find a shell thing wasn't it because you used terminator?
[20:45] <robru> charles: rtm silo 4
[20:46] <charles> robru, ack
[20:55] <rsalveti> bfiller: kenvandine: jhodapp: image 98 is out: http://people.canonical.com/~ogra/touch-image-stats/98.changes
[20:56] <kenvandine> rsalveti, thanks!
[20:56] <kenvandine> now i can worry less :)
[20:56] <bfiller> rsalveti: thanks
[20:57] <jhodapp> rsalveti, nice, thanks man
[20:57] <bfiller> rsalveti: will need to do the same thing next week on rtm, actually just the seed will need to be updated once my silo is synced
[20:57] <rsalveti> bfiller: sure, no worries
[20:57] <rsalveti> just let me know when you need it to be updated
[21:18] <bfiller> robru: fyi, seems to be an off by one error in the dashboard with the spreadsheet row
[21:18] <bfiller> robru: reports one row higher than where it really is
[21:19] <bfiller> damn 0's and 1's :)
[21:19] <robru> bfiller: looks right to me, but I did notice something like that earlier today. try reloading the spreadsheet.
[21:19] <bfiller> ok
[21:20] <bfiller> robru: yup it's fine now
[21:21] <robru> bfiller: hehe. amazingly the dashboard knows the spreadsheet row better than the spreadsheet does ;-)
[21:34] <fginther> dobey, that can be done, we'll let you know when it's ready
[21:38] <dobey> fginther: great thanks. i'm going to be heading out soon since it's about EOD here. but just ping me and i'll see it later.
[22:08] <charles> hurm?
[22:08]  * charles looks
[22:11] <charles> ah, it didn't get top approved, and dobey's already EODed.
[22:11] <charles> I'll be a little tacky and top-approve myself
[22:21] <rsalveti> bfiller: can't we make https://bugs.launchpad.net/barajas/+bug/1421091 part of silo rtm 11?
[22:21] <rsalveti> bfiller: it's also a critical factory issue
[22:43] <robru> kenvandine: around for a packaging ack? https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-019-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-themes_14.04+15.04.20150213~rtm-0ubuntu1.diff/*view*/ thanks
[22:58] <robru> kenvandine: https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.1+15.04.20150213-0ubuntu1.diff/*view*/ another one if you can
[23:33] <robru> Mirv: congrats: 11G	./silos/ubuntu/landing-005 13G	./silos
[23:44] <robru> awesome.