[00:22] bfiller: sorry about that, was on lunch. done [00:28] robru: cheers, thanks [00:28] bfiller: you're welcome [00:42] 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 === chihchun_afk is now known as chihchun [01:17] robru: cool [01:18] robru: I'm around now? [01:18] cyphermox: heh, I'm back now ;-) [01:18] ok [01:37] bfiller: seeds updated === chihchun is now known as chihchun_afk [02:08] rsalveti: thank you [03:30] === IMAGE 97 DONE (finished: 20150213-03:30) === [03:30] === changelog: http://people.canonical.com/~ogra/touch-image-stats/97.changes === [03:36] robru: mind publishing ubuntu 13 if you're around still? [03:37] bfiller: yep, was just prepping dinner [03:37] robru: thanks man, sorry to bug you [03:37] bfiller: no worries, happy to help [04:41] 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] Mirv: nice, qt 5.4 packages are looking good for the emulator [05:11] nice work === chihchun_afk is now known as chihchun [05:59] rsalveti: great news! [06:00] that means I'll start ushing wih the ~test removed from version numbers [06:02] Mirv: I have a strange dependency error in the rtm silo14 withthe gles package [06:02] bzoltan_: "dea"? [06:03] oh, does :) [06:04] Mirv: it looks odd ... specially that Qt is rater stable on RTM ... there was no qt changes there as I know [06:05] 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] bzoltan_: as usual, it's not the train but your MP [06:14] 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] I can imagine that causing slight trouble when trying to dput the .dsc file [06:15] 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] Mirv: I understand that I am a very stupid person :) But please tell me what did I do wrong? [06:30] bzoltan_: copy-pasting the version number from terminal instead of web browser? [06:31] 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] 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] Mirv: OMG... LOL.. sorry... [07:00] * bzoltan_ needs coffee [07:04] bzoltan_: hehe [08:18] 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] 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] Mirv, is new qt planned to land? [08:19] seb128: yes, now that emulator was confirmed to be working and no critical bugs left [08:20] Mirv, was settings confirmed to work with it? [08:20] 3 bugs overall, one of them is the u-s-s [08:20] seb128: no, the about page bug is still open [08:20] since when do we accept that kind of regressions? [08:20] but I'm stalled because of Kubuntu so landing probably on Monday, not today [08:20] Mirv: joining a meeting now, I'll get to that in a few minutes [08:21] 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] 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] I'm surprised we consider that ok [08:21] seb128: --developer-mode works, but yes the bug could be raised to be Critical [08:22] 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] Mirv, what was the issue again? the move of the storage to qt proper? does that symbol conflict? [08:23] 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] so only C++ is there anymore [08:23] Mirv, but we don't update qtsystems, the old one stops working? [08:23] seb128: yes, it does [08:24] shrug [08:24] well, Laney looked at switching the code to the qt version [08:24] but it lacks apis that were in qtsystems and that we need [08:24] especially the one to filter storage to list only the internal ones [08:25] this was probably just the first step in upstream combined with the fact that they didn't support the previous feature. [08:26] well, what do we do meanwhile? [08:26] if we drop those checks the storage info are going to be wrong [08:27] I'd say the feature needs to be reimplemented in our component or offered to upstream qtbase + qtdeclarative for the QML part [08:27] they won't allow the same class back to qtsystems now that they started on it in qtbase [08:27] right [08:27] even if the qtbase lacks features and bindings [08:27] but meanwhile what do we do [08:27] do we accept wrong storage info as an ok regression? [08:27] hide the storage info temporarily until fix is there? [08:28] or do we block the qt5.4 landing on that to be resolved [08:28] urg [08:28] I didn't follow closely landing rules recently [08:28] that's alternative, but the push to get 5.4 in is quite big compared to one part of a page [08:28] but that seems a world different from previous cycle [08:28] where we had "never land with regressions" [08:28] now we consider ok to hide main feature from the product? [08:29] well davmor2 and others from QA could reconsider this and give their thoughts [08:29] davmor2, ^ please reconsider [08:30] Mirv, also why hasn't that be communicated on eg ubuntu-devel@ list? [08:30] it would have helped to give some perspective on the issues and when they need to be resolved [08:31] 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] the bug itself also says "targeted before Feature Freeze Feb 19" [08:32] Mirv, yeah, phablet is not a way to reach to everyone is Ubuntu [08:32] right [08:32] still that seems like a total shift in mindset from the high quality/no regression speech we had for some cycles [08:33] we had a time where we were speaking about fixing in some hours or reverting [08:33] now we just happily land regressions knowing that things are buggy before even landing [08:33] shrug, I should just stop there, I'm going in ranting mode [08:33] :) [08:34] I'm going to write an email asking wth happened to the quality standards we preached [08:34] seb128, its friday ... go ahead :) [08:34] 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] I might just go ahead and do that as well, while I'm at it :p [08:35] 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] ogra_, well, that's understandable [08:36] the prob here is clearly the lack of manpower in QA [08:36] 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] 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] imho we need more communiity involvement on the devel-release side [08:36] what* [08:36] 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] yeah, agreed [08:37] I felt the bug sounds like easily understandable technical problem instead of risky sounding regression like a crasher would be [08:37] 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] Mirv, sure is [08:37] but still the impact is that it blocks people to do work [08:37] no adb, no ssh [08:37] how do you even work on a device? [08:38] seb128: yeah the impact needs to mitigated before publishing [08:38] well, from what you said that was not going to happen [08:38] no ssh ? [08:38] ogra_, we don't install/enable ssh by default do we? [08:38] it is installed by default ... not enabled though [08:38] right [08:39] so it means a device without dev mode enabled and with a broken UI to access dev mode [08:39] what do you do from there? [08:41] you can boot into recovery and set the property to turn ssh on ... [08:41] it will start on next boot [08:41] prob is ... you indeed need working network [08:41] yeah, and you need how to do that [08:41] in the normal boot it is /userdata/android-data/property/persist.service.ssh [08:41] how many people are going to waste an hour or resolving that? [08:41] needs to have "true" with no newline [08:41] that's just wrong, we should fix the known regression before landing [08:41] seb128: we're not going to ship 5.4 with no dev mode in about page [08:41] sure [08:42] just pointing out that there are ways [08:42] Mirv, well, sounded like you were about to [08:42] not convenient ones ... but you can always get in somehow [08:42] 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] sure [08:43] 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] i didnt say everyone should do it :) [08:44] 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] 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] I though the hard line on no regression was to prevent ending up going that way [08:45] seb128: it's not being forgotten since it's known, unlike some of the other vivid regressions currently in there [08:45] seb128: we can't really not ship 5.4 either, so there's a balancing needed to be done at some poit [08:45] right, it's just that we diverge more and more from our goal on quality [08:45] it's going to be difficult to get back to the rtm quality if we keep doing that [08:45] right [08:46] 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] well, but that means we need someone to put more time into qality on that release ... [08:47] which is really hard if 98% of the QA engineers we have are focused on rtm [08:47] 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] 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] and the remaining 2% need to rush to get anything dones at all to keep up with our devlopment pace === chihchun is now known as chihchun_afk [08:47] ogra_, well, those are some of the cases where we know things are buggy, no need of QA to point it [08:48] it's just a mindset from the landing team [08:48] we need to get away from the 2 distro approach or we need to staff up QA [08:48] there is no requirement for QA testing on vivid silos [08:49] so the QA person testing the image will only see it far after it landed [08:49] right [08:49] but in this case we know about issues before landing [08:49] so we should block landing [08:49] how ? [08:49] no QA person tests the vivid silos [08:49] 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] well, we have a bug open saying that settings->about fails to open with qt5.4 [08:49] it has been reported by our landing team [08:50] ah [08:50] Mirv, thanks [08:50] 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] right, that shouldnt have happened === chihchun_afk is now known as chihchun [08:51] seb128, and thats what keeps you from adb/ssh ? [08:51] ogra_, yeah, no about page, no access to the dev mode switch, no adb [08:51] open the terminal: android-gadget-service enable ssh [08:51] 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] i thought you have no UI at all [08:52] ogra_, assuming you have it installed, which we don't by default on e.g krillin [08:52] (or, not having easy dev mode) [08:52] seb128, the same command above works with s/ssh/adb/ and enables dev mode [08:52] ogra_, but yeah, I guess you can install from the store [08:52] Mirv, thanks [08:52] anyway, enough discussed it [08:52] we talk about vivid [08:52] let's try to get the issue resolved [08:53] vivid always has the terminal by default ... wont go away ... even on krillin afaik [09:23] 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] man my back space skills suck [09:23] 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] 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] seb128, sadly we are not automatically gating on these tests [09:29] and talking about system-settings, only 2 tests pass on 124 [09:31] jibel, yeah, that's an issue [09:31] urg, what is the issue with the other ones? [09:45] 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] Mirv, or vice versa, whatever you prefer as long as it lands with the fix (I can reconfigure my silo) [09:46] Mirv, I think it will be faster on my side that yours [09:47] mandel: yes, please land asap and I'll just rebuild as soon as it's published [09:47] Mirv, ok, on it [09:54] 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] mandel: hmm, I did actually mean you would land the fix too, so I can rebuild without changes, is that ok? [09:54] I always prefer no-change rebuilds [09:55] Mirv, ok ok, sounds good [09:55] mandel: the only thing is that ciborium needs a rebuild since it uses private headers [09:55] mandel: ok! [09:56] 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] 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] ...after your landing with the 5.4 fix is in vivid [09:59] Mirv, ok, so line 58 is ok atm, correct? [09:59] Mirv, then, if I find where is rtm silo 000 line, I need to check that one out [09:59] Mirv, and line 59 should be removed [10:02] 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] 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] mandel: or, is it that you don't have rtm branch of ciborium, they are identical? [10:04] 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] 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] 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] Mirv, +1 to that [10:06] +1! [10:09] Mirv, can you remove line 59 then? I don't think I have the rights to do it === vrruiz_ is now known as rvr [10:11] mandel: yes [10:11] done [10:12] Mirv, superb, thx [10:12] zbenjamin: what's the chance you can fix bug 1418460? It's blocking a couple of core apps projects. [10:12] bug 1418460 in qtcreator-plugin-ubuntu (Ubuntu) "libconnectivity-qt1-dev un-installable in click chroot" [Undecided,Confirmed] https://launchpad.net/bugs/1418460 [10:27] Mirv, testing in vivid atm line 58 [10:33] popey: that looks to me like he forgot to add the :armhf suffix [10:33] popey: apt-get install libconnectivity-qt1-dev:armhf [10:36] is CI known to be unhappy atm? [10:36] settings results on mps look like the application exit on start or something [10:37] not sure what's going on [10:38] cihelp: ^ is there any known outage? [10:40] e.g https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/1188/ [10:44] seb128: system-settings crash during the AP testing [10:44] psivaa_, can we have a bt? [10:45] seb128: this could be seen in smoke too [10:45] seb128: http://ci.ubuntu.com/smokeng/vivid/touch/mako/97:20150213:20150210/12295/ubuntu_system_settings/2056866/ [10:45] the crash file is attached there [10:45] psivaa_, thanks [10:45] seb128: np [10:45] 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] Mirv, maybe you know too ^ [10:49] mandel: yeah [10:49] sil2100, sweet, thx [10:49] sil2100, I wanted to be 100% sure [10:50] mandel: although we might need to remove the packakages by hand from the PPA itself [10:50] Not sure if the new build job is fixed in regards of that [10:50] sil2100, ok, I''ll try and we'll see [11:00] 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] no [11:01] ok, so not bringing that [11:01] you might need to combine, my commit only gets the free space calculation working [11:01] oh, ok. well, I'll look at it. [11:01] it's a problem because they removed this storageType thing >:( [11:01] so one other bandaid is to copy that function somewhere [11:03] 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] Laney, Mirv: I'm assuming it will be longwinded but minor fixes to get everything else up and running right? [11:05] davmor2: I tested developer mode, testing reset too although I assume it doesn't use much Qt functionality what it's doing [11:05] davmor2: yes so the current bandaid is purely commenting out two sections in QML http://pastebin.ubuntu.com/10202733/ [11:06] so that the rest of the page that doesn't use removed Qt features can load [11:07] davmor2: so your usual about page sanity test is to switch developer mode + use reset? [11:07] 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] i.e. just turn off Storage.qml [11:07] ok Laney [11:07] but try it [11:07] trying [11:07] not sure I got as far as test building [11:07] ;-) [11:08] 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] yeah reset seems to have worked, back to the wizard now [11:43] * sil2100 off to lunch === marcusto_ is now known as marcustomlinson [12:11] 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] combined with only a single commenting out of the StorageInfo in the qml file this time [12:12] so the free space count is back [12:17] mandel: hey, trying to understand the landing then [12:17] mandel: we got a ciborium one for vivid and rtm [12:17] mandel: are you landing the vivid one now? [12:17] mandel: and also, are we ready to set the rtm one to needs qa? [12:27] Mirv: great, just let me know when you rebuild your packages again (removing the ~test) [12:27] so we can give another round of testing [12:28] rsalveti: it's done already, but Kubuntu is keeping us back so I'll wait for Monday anyhow [12:29] there are no changes in any package other than the version string change in changelog [12:32] Mirv: oh, great then [12:37] mandel: thanks, I'll rebuild it in the 5.4 PPA after that [12:47] rsalveti, yes, I'm going to test the rtm now and will set it ready for Qa to land [12:48] mandel: great, and for vivid? can't we just land it now? [12:48] bfiller: boiko: ping [12:48] rsalveti, yes, but we need to coordinate with Mirv AFAIK is ok, is that correct? [12:49] mandel: rsalveti: I landed it already and rebuild is ongoing in the Qt 5.4 PPA [12:49] perfect [12:49] since you marked it as tested [12:49] Mirv, yes, it was tested [12:50] bfiller: boiko: I'm testing silo 11. Taking a look to the silo diff, there is a change to factory-wipe.conf [12:50] bfiller: boiko: Line 69 https://pastebin.canonical.com/125629/ [12:51] bfiller: boiko: Can you confirm or deny? [12:51] mandel: Mirv: even better [12:52] rsalveti, I'm testing in rtm ciborium and will set it ready for qa in a few mins [12:54] hm, the citrain gives me a hard time assigning #92 (click). I get a fatal error [13:00] rvr: checking [13:01] rvr: hmm, that doesn't seem right [13:01] rvr: bfiller: it looks like something landed on rtm and was not committed to bzr [13:02] mandel: thanks [13:02] boiko: I'm using citrain-diff tool by brendand === alan_g is now known as alan_g|lunch [13:02] boiko: Do you think the diff is right? [13:03] 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] rvr: it seems the ubuntu-touch-session RTM bzr branch is outdated [13:05] boiko: As far as I remember, factory_wipe fix was done via device tarball, can that explain it? [13:07] rvr: yep, that probably explains it [13:07] rvr: let me compare the commit history with the changelog, just a sec [13:10] hey trainguards, I have trouble assigning a silo for #92 (new click release). am I doing something wrong? [13:10] I got this: https://ci-train.ubuntu.com/job/prepare-silo/4098/ [13:10] 2015-02-13 12:58:25,797 ERROR Could not find REQUEST_ID 1423832036072 in any silo. [13:11] rsalveti, set to be tested by QA [13:12] rvr: yep, ricmm's changes are not in bzr, we need to sync that somehow [13:12] rvr: I mean, before landing silo 11 [13:12] mandel: awesome [13:12] rsalveti, dealing with the udm stuff to get it landed today too [13:13] mandel: cool [13:13] landing day [13:14] rvr: I'll go for lunch now, but right after I'm back I will deal with that, ok? [13:20] boiko: Ok [13:23] trainguards, can I get a silo for line 93? === MacSlow is now known as MacSlow|lunch === chihchun is now known as chihchun_afk [13:29] sil2100, testing report sent. Same pass rate than previous run with more tests executed. [13:42] jibel: o/ [13:42] Thanks! [13:42] tvoss_: on it [13:43] sil2100, thx === alan_g|lunch is now known as alan_g [13:49] jibel, john-mcaleely, ogra_, pmcgowan: so it seems we're green on promoting 234 to the rc channel [13:49] The only problem I see now is... [13:49] uhoh [13:50] 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] I mean, we could have those in that channel too [13:50] But the name indicates 'bq-aquaris.en' - so I doubt anyone would actually see or use those images on mako [13:50] ;) [13:50] Since who would flash their mako with an aquaris channel? [13:50] hm. maybe we need a 14.09/rc ? [13:51] Yeah, what I would propose is creating an alias to the aquaris channel [13:51] so I will defer to john-mcaleely but we do not want the ota going to krillins in the field yet [13:51] I know it's a bit dirty, but would work for sure [13:52] sil2100, definately a bit dirty, but sure, why not [13:52] pmcgowan, yeah, it's all fine so long as we stay out of stable/ [13:53] and having a more generic name for people to flash makos from seems good [13:54] not sure we need another channel, folks can use proposed or wait? [13:54] sil2100, i would just leave these arches out [13:54] no one using stable would flash a special channel [13:54] isn't it a bit unfair to the mako folks? [13:55] I suspect few mako stable users? [13:55] but sure, mako is a dev tool, so stable or proposed might be all you need [13:55] indeed [13:55] do we need it for test coverage (ie only mako exercises some areas?) [13:56] We could leave them out, sure, but it does seem to be a little bit of a waste [13:56] dont think so, since mako has less stuff than krillin [13:56] 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] 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] so I think it has a bit somewhere that tracks the now obsolete MP related build number [13:57] 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] For me, this would be for an stable/ mako community of non-devs [13:57] probably very small, but perhaps important? [13:58] 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] 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] Mirv: but I remember we allowed things like that before at least [13:59] 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] 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] sil2100: I reconfigured (via prepare-silo) the silo after removing MP + adding manual source [14:11] 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] 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] hey trainguards, I have trouble assigning a silo for #92 (new click release). am I doing something wrong? [14:13] (sorry for re-asking, my network was down for some minutes) [14:13] has anyone seen this? [14:13] * jdstrand didn't see it mentioned on the list [14:16] looking at http://people.canonical.com/~ogra/touch-image-stats/rtm/, it is not immediately obvious what might've changed [14:16] that might cause this [14:16] you need to map the mako version against krillin [14:17] the rtm changelogs above are all against krillin version numbers [14:17] * jdstrand just went by the date [14:17] ah, k [14:17] yeah, that should be fine [14:17] went back for the last 5 changes [14:18] maybe I'll do all of Feb just to be tidy [14:18] mvo: hey! [14:18] mvo: let me look [14:19] mvo: hmm, #92 doesn't seem to look like your landing, can you refresh the spreadsheet? [14:19] mvo: I think it might be bugged on your side and it didn't register you entering the details [14:20] 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] mandel: Silo 0 has no associated bug in the spreadsheet [14:20] jgdx, i kicked a rebuild of silo 15 because we've had a bunch of landings since that [14:21] sil2100, ac [14:21] k [14:21] sil2100, +1 [14:22] kenvandine, thanks [14:22] jgdx, so what's the status of that stuff? have we nailed down the issues found in the rtm silo? [14:22] jgdx, sorry i haven't been following it lately [14:22] jdstrand, there is an open bug for edges not working, I have seen it [14:23] pmcgowan: ah, good to know [14:24] jdstrand, if you have more info https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1408263 [14:24] Launchpad bug 1408263 in android (Ubuntu) "Edge gestures still get lost" [Undecided,New] [14:25] kenvandine, it's blocked by https://bugs.launchpad.net/barajas/+bug/1378778 [14:25] Error: launchpad bug 1378778 not found [14:25] * jgdx adds that to spreadsheet [14:25] pmcgowan: that's it exactly. I'll subscribe and see if I can help with more info [14:26] kenvandine, ah- sorry. Bit late [14:26] jdstrand, and I have had them come back without a reboot, quite odd [14:26] jgdx, ah, bummer... so it's blocked by another bug :/ [14:29] sil2100: ok, let me try again with a different browser [14:29] 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] jdstrand, same, I launched dialer from the app scope to get to it, then after the call edges worked [14:32] yeah, unfortunately I didn't have the app scope up [14:32] I had the music player once and something else the other time (I don't remember) [14:33] mvo: I subscribed to your landing and I will help it with running the SDK's functional tests too [14:33] 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] sil2100: eh, I mean when I try to assign a silo [14:33]