=== chihchun_afk is now known as chihchun === salem_ is now known as _salem [04:30] morning [06:55] hmm [07:15] davmor2: hey, seeing the e-mail about lost contacts on ubuntu-phone... you think that might be due to the buteo landing? [07:15] davmor2: if that's the case, I would say we need to revert [07:16] sil2100, it is [07:17] So much for Bill saying he's 'confident in it' [07:17] sil2100, but then if you revert do you recover your previous contact db since it has been converted? [07:17] cihelp: I believe there is something wrong with krillin-09 or mir-ci https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/6900/console [07:17] s/or/of [07:17] anpok: let me take a look [07:18] jibel: not sure, but it's all rc-proposed - that's the risk of using this channel [07:18] sil2100, I'd like to test the revert locally before reverting in the archive [07:18] jibel: ok [07:18] jibel: I'll prepare the revert in a silo then [07:18] I don't want this to go into a stable image [07:18] sil2100, which packages do I need to downgrade/uninstall to revert on my phone? [07:19] sil2100, agreed, it is not ready. He's the 3rd user with major issues [07:20] jibel: I would say: address-book-app, address-book-service, indicator-transfer and sync-monitor [07:20] Those 4 should be sufficient [07:20] Not all are required probably, but best to be sure [07:21] sil2100, there were packages added to the seed too? [07:22] anpok: that is a mako job running on krillin, that does not sound right. But I want to confirm if that has anything to do with the device shortage that we have. Will need to check. In the middle of debugging some other issue. will take a look at it a little later [07:30] jibel: no, there were other packages but those are pulled in as deps [07:31] okay [07:32] sil2100, seb128 any news on UITK and the problem with USS? [07:32] bzoltan_, ^ [07:33] jibel: Yes, I have an MR what hopefully fixes it. [07:33] bzoltan_, so we move forward and no revert? [07:33] bzoltan_, do you have the url of the merge request? [07:34] seb128: https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/fixThemingFallback/+merge/273497 [07:34] * sil2100 has enough reverts for today [07:34] uitk change, good :-) [07:34] jibel: let me first check that MR and understand the whole story [07:34] ;) [07:35] seb128: I have never had doubts that it was a version leakage ... [07:35] psivaa: ok .. we have a few krillins next to the makos at the moment.. and I believe krillin-09 is misbehaving.. or the mp causes that.. [07:35] bzoltan_, oh ok, I though you were considering it being settings' fault to import outdated versions [07:35] seb128: and mixing versions can provoke unexpected / untested issues [07:36] bzoltan_, that shows a design flow in the uitk imho, but that's a discussion for another day [07:36] seb128: Ohh, the USS is messy, that is no question either :D But last night I tested with various import changes and nothing solved the problem. [07:36] jibel: since upgrading your device won't auto-remove the unused packages, you can then try also removing those binaries: buteo-sync-plugins-contacts-google, buteo-syncfw, indicator-transfer-buteo, qtdeclarative5-buteo-syncfw0.1, libbuteosyncfw5-0 and libiphb0 [07:36] bzoltan_, if imports shouldn't be mixed then all components should have consistent versioning and be shipped/updated together and different versions should be co-installable [07:37] jibel: but I suspect with the main packages reverted, whose shouldn't be used at all [07:37] seb128: no shit Sherlock :D It is clearly a design fault... different versions should come from different packages IMO... but this model has benefits too. [07:37] right [07:38] it just feels flacky, it all work by luck when you start mixing versions and there is no guideline/easy way to avoid mixing versions [07:38] sil2100: can somebody motivate Jenkins to pick up this MR and build it? https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/fixThemingFallback/+merge/273497 [07:39] bzoltan_: I think cihelp would need to take a look [07:39] seb128: it is not flaky if we do proper separation in the UITK code ... but version separation is a fairly new feature... so it has bugs. Sorry, for that... and the USS is a perfect test animal [07:39] right [07:40] read: USS will keep importing all possible uitk versions [07:40] bzoltan_, I'm even unsure why u-s-s gets "new headers" (the back button at the top) while it imports 0.1, it should have the back at the bottom with that version (at least a standalone testcase suggests that's what 0.1 import leads to usually) [07:40] jgdx, ^ do you know? [07:41] jgdx: LOL... and it should have AP test for the "open page - go back" for all pages :D [07:42] bzoltan_, right :p [07:43] jgdx: importing all possible versions will also lead you to errors [07:43] jgdx: actually I will contribute that to the USS project [07:43] seb128, “at the top”? Not sure what you're referring to [07:43] jgdx: like if you try to use Page from 1.2 in a PageStack from 1.3, it will blow up [07:43] and that's not because of the versioning [07:43] zsombi, i kid, we need to move everything to $new [07:43] jgdx, the "<" chevron is in the header [07:43] but because the Page in 1.2 is a different type than in 1.3 [07:43] seb128, no, sorry, don't know about that [07:44] zsombi, uitk should either support versions mixes or make it impossible to mix them and bail out on start with an error [07:44] rather than doing like it was ok and hitting random bugs [07:45] seb128: there are components you cna mix, but there are others you cannot [07:45] zsombi, well, it shouldn't be up to the app writers to figure out by debugging weird things [07:45] seb128: the click-reviewers-tools or a forced code sanity check in the SDK should throw an error when imports are mixed [07:45] sil2100, where are previous builds of these packages? [07:46] seb128: believe me, if you mix the setup I wrote above, your app will crash big time [07:46] zsombi, k, still not a proper appdev experience [07:46] it should gently error out telling you to not mix components ;-) [07:46] seb128: wherever a UITK omponent si used as the type of the property, that will be impossible to mix with other versions of the toolkit [07:47] seb128: we cannot do anythign about that, it'll be QML compiler which will kick you out [07:47] jibel: you mean, sync-monitor etc.? [07:48] sil2100, yes [07:48] jibel: you probably need to use my quick package download tool - do bzr branch lp:landing-team-tools, cd into it and use overlay-ppa-dl-package [07:48] there is only latest build in the overlay [07:49] jibel: specifying the version number you want to download [07:49] I'll try that, thanks [07:49] jibel: yeah, I made a tool for that since digging in LP's PPA previous packages is almost impossible [07:50] You can of course get the previous version numbers of those packages from http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/141.commitlog [07:53] anpok: the latest job was running on krillin-08 [07:54] so i did not think it had to do with just krillin-09 [07:54] but will confirm [08:13] sil2100, do you know if there is an update of the watchdog for vivid? I found silo 57 but it's wily only [08:13] cyphermox, ^ [08:15] jibel: I suppose cyphermox wanted to first land in devel with that, but I'm sure Pat wanted the same change in overlay [08:15] We'd need cyphermox [08:18] sil2100, yeah, the immediate problem is with this release, not really devel-proposed [08:19] jibel: right, but still - cyphermox is following the overall process, that everything needs to land into wily first [08:20] sil2100, the silo should be dual not wily only, isn't it? [08:21] jibel: manual sources cannot be dual silos [08:22] jibel: since upstart-watchdog is not a CI Train package, it needs 2 silos currently [08:23] sil2100: the issue is lots of people are using own cloud that they have bastardised into the system and not google sync so that is when the errors kick in, there is a fix in the works for that so do you want to revert and re land with the fix or leave it and land the fix? [08:24] davmor2: how far is the fix from landing? Since today is final freeze already... [08:24] sil2100: one for renato [08:24] sil2100: one for renatu [08:24] renatu: ^ [08:26] davmor2, it was the case for the user on u-touch yesterday, but what about the guy on the ML? [08:26] sil2100, I downgraded address-book and friends but contact sync with my google account doesn't seem to be working [08:27] davmor2, with Pat it's 3 people who have major problems with this update, it is not even translated. Really I am not confident at all with this feature. [08:28] jibel: you removed the new packages as well? [08:29] sil2100, I did an autoremove, downgrade was a PITA, I had to uninstall/reinstall ubuntu-touch to downgrade sync-monitor which was blocking the removal of buteo [08:31] jibel: seb128: the fix works [08:31] great! [08:31] sil2100, ah interesting, there is no option 'contact sync' in google account [08:32] jibel: you sure that all the required packages are at the right versions? [08:32] bzoltan_, nice, thanks! [08:33] sil2100, sync-monitor-uoa is not, which would explain the missing option [08:34] jibel: okay so it sound like he has a mix of on the phone and in google and the on the phone ones got removed. [08:41] jibel, sil2100: so it sounds like the plan is to back out buteo retest everything with the fixes that renatu is looking to land and then what land it once ota8 opens? [08:43] davmor2: yeah [08:43] I don't want QA to waste time waiting for more fixes before this is bug-free [08:51] jibel: sil2100: I am pushing a new UITK landing ...I wish to see it in OTA7 as it has four serious bugfix [08:52] bzoltan_: ACK [09:03] sil2100, sync works fine after a downgrade, I just had to re-enable contact sync in google account settings [09:15] jibel: sil2100: the silo 014 is chewing on the fixed UITK build. It will take an hour or so to get the armhf binaries ready. I would suggest to take that for QA validation as quickly as possible. The code has super little change... but I will run the regular Test Plan, what takes 3-4 hours. So I think we still can make it to the OTA7 freeze [09:48] bzoltan_, how come it’s always staging that lands, instead of cherry-picking only a fix for the regression? [09:58] oSoMoN: because in my opinion cherry picking is generally not a good practice [10:00] oSoMoN: cherry picking four branch for four problems means four forks and four different set of possible side effects. No cherry picked branch is isolated... they all bring their own risk. So it is just better to treat them together and do proper testing regardless how small is the change. [10:01] bzoltan_, cherry-picking doesn’t imply less rigorous testing, but it avoids introducing new regressions when fixing a critical regression, which apparently is what happened with the latest UITK landing [10:02] oSoMoN: No, it is not what happened [10:02] oSoMoN: what happened was 1) QA and test plan does not cover makor 2) Settings app does not have AP tests for the page in/out scenario [10:03] oSoMoN: both issues were introduced by normal feature development not by colliding bugfixes [10:04] bzoltan_, well that would have caught the issue indeed, but I still fail to understand why the last landing had more stuff than just the fix for bug #1502093 [10:04] bug 1502093 in ubuntu-ui-toolkit (Ubuntu) "UbuntuShape crash with latest UITK on mako/flo" [Critical,Fix committed] https://launchpad.net/bugs/1502093 [10:04] oSoMoN: not to mention that cherry picking is a maintenance nightmare [10:04] dbarth: Silo 16 approved [10:06] oSoMoN: because I test and review each extra bits and make a call that they do not represent risk.. :) magic-magic... they do not. This Settings issue was introduced before the mako bug [10:06] dbarth, although I didn't see much improvements on memory consumption. [10:06] oSoMoN: it is a sensitive balance between fear driven development and keeping the development pace optimal [10:07] bzoltan_, it might have, but you’re still taking extra risks (even if you carefully review and assess risk personally) very close to the final freeze, that doesn’t sound very reasonable [10:08] there’s no such thing as "development pace" one day before final freeze, only critical bug fixes [10:08] dbarth, does silo 16 includes a fix for bug 1498953 ? [10:08] bug 1498953 in Canonical System Image "Lower the limit for base::DiscardableMemoryAllocator in the browser" [High,In progress] https://launchpad.net/bugs/1498953 [10:08] oSoMoN: no, I do not take at all any risk :) Each landing i run more and bigger tests than anybody else together in a year :D [10:08] bzoltan_, but as you pointed out earlier, our tests don’t (and cannot) cover every possible case [10:09] oSoMoN: Silo 16 landed, does 59 need a rebuild? [10:09] oSoMoN: I repeat ... both issues (mako/settings) were introduced before both reverts... the problem is the poor quality of AP tests and lack of on device tests [10:09] jibel, yes it does fix that bug [10:10] rvr, no need for a rebuild [10:10] oSoMoN, hm, I don't see much improvements then. Browse Euronews and it uses 30% of system's memory on krillin [10:10] oSoMoN, open a webapp and OOM starts killing processes [10:10] oSoMoN: So, you might suggest to take the paranoid landing polciy and slow done the thruput of the UITK... but in fact, all serious issues in the past happened for other reasons then bounded landings. _ALL_ [10:11] jibel, I can’t really comment on that as I didn’t test it myself, just saying that the patch that addresses the issue is part of 1.9.5 [10:12] bzoltan_, fair enough, I was only suggesting to be cautious the day before final freeze, not slow down the general pace of landings [10:13] bzoltan_, and given our history of regressions, maybe we should be a bit more conservative (or paranoid if you prefer) [10:13] oSoMoN: Point taken... beleive me :) I was furious both times and I am taking actions to prevent the same problem [10:13] oSoMoN: What regressions? [10:14] oSoMoN: catching a bug in a staging area is not a regression... [10:14] oSoMoN: we have not released regressing UITK for extreme long time... [10:15] bzoltan_, not saying that, but IIRC pretty much all our OTA’s have had regressions in the past (and not saying in the UITK, in the product in general) [10:15] oSoMoN: bugs we do :) like everybody else too [10:16] oSoMoN: You are right ... and I keep ranting about the solutions 1) staging channel with the trunk of each core component 2) ubuntu phone as primary device for all core component developer 3) regular AP testresulst for the staging version of all components. [10:17] oSoMoN: we should test what is about to come out ... not just hacking in our own silos and be surprised once they are put together === chihchun is now known as chihchun_afk [10:37] Mirv: I have a new entry in debian/changelog, is that why we don't have permission? [10:37] pete-woods: no, it's because of the debian/control and debian/rules changes https://ci-train.ubuntu.com/job/ubuntu-landing-046-2-publish/18/artifact/libqtdbusmock_packaging_changes.diff [10:37] and the fact that the package is in main (I thought it was universe that's why I tried to publish it) [10:38] right, so we need someone with moor power [10:38] so needs core-dev rights [10:38] yes [10:40] jibel: the silo14 is ready https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-014 [10:41] are there any core-dev members around with 5 minutes to look at a small diff (to fix a FTBFS)? https://ci-train.ubuntu.com/job/ubuntu-landing-046-2-publish/18/artifact/libqtdbusmock_packaging_changes.diff [10:42] It contains changes not explained in the changelog, so no. [10:52] okay, fixing that [10:52] and rebuilding [10:53] thanks! [10:57] well, at least attempting to rebuild [11:00] trainguards: I think I must have screwed something up with my silo: https://ci-train.ubuntu.com/job/ubuntu-landing-046-1-build/82/console [11:00] pete-woods: hey! [11:00] pete-woods: hm, I saw something like this once, a re-build helped as it was something transient on the train machine [11:01] sil2100: this is the second build [11:01] Not sure if that's the same thing, but maybe you could try before we investigate further [11:01] I can try a third, though [11:01] Ok then [11:01] Let me look deeper [11:01] I cancelled a build, though [11:01] and I think it could well be that [11:01] maybe some junk left behind [11:02] pete-woods: yeah, generally it's best if you never abort a build job before it's done with creating the packages - not sure if that's the thing that broke it, but that's never a good option [11:02] In the past it could bust the whole silo [11:03] :O [11:03] okay, will be more careful in future [11:03] I was trying to catch it before it uploaded the source package [11:03] mktemp: failed to create directory via template '/tmp/debsign.XXXXXXXX': No space left on device [11:04] This worries me a bit! [11:04] Let me try cleaning some space [11:06] pete-woods: ok, try now [11:06] The pbuilders wasting space gets a bit troublesome... [11:07] sil2100: thanks, I think you've spotted the right error there [11:08] sil2100: jibel: i have marked the silo14 for QA ready -> https://requests.ci-train.ubuntu.com/#/ticket/476 I will attach the relevant test logs in few hours, but it would be cool to start the QA process in the meantime [11:10] bzoltan_: ok [11:10] Thanks! [11:10] sil2100: that seems to have fixed it, thanks! [11:10] pete-woods: phew! yw! [11:11] bzoltan_, okay someone will take it [11:11] jibel: thank you [11:12] rvr, ^ do you fancy another testrun of uitk? [11:13] * rvr reads [11:14] rvr, this is the fix for the missing headers in system-settings [11:14] Ahh, good, good [11:14] I'll take it [11:20] rvr: Thank you! Please be as hard as you can :) It is the third attempt to land that piece of ... errrr ... art? [11:24] bzoltan_: lol [11:27] bzoltan_, no worries, rvr can reject it a 4th time. He seems to be really enjoying it ;) [11:28] jibel: :D I am sure he does [11:28] * rvr won't comment [11:35] ;) [11:47] jibel: yes, silo 16, oxide 1.9.5 includes a patch to deal with lowering those limits === _salem is now known as salem_ === alan_g is now known as alan_g|lunch [12:12] bah [12:18] davmor2, I have the fix already, just testing [12:22] renatu, did you see that nik says he lost his contacts? [12:23] pmcgowan, no, [12:23] pmcgowan: we're reverting buteo for OTA-7 [12:24] Too much risk... [12:24] pmcgowan, which channel? [12:24] renatu, in the mailing list [12:24] renatu, https://lists.launchpad.net/ubuntu-phone/msg16055.html [12:24] sil2100, oh? [12:24] sil2100, how do we revert the db update? [12:24] this sounds iffy [12:25] pmcgowan: well, rc-proposed is meant to be broken, I just don't want it to go to stable [12:25] sil2100, why are we reverting? [12:25] pmcgowan: because people are reporting lost contacts after the upgrade [12:25] sil2100, more than just nik? [12:25] pmcgowan: QA mentioned at least 3 people [12:26] And jibel also saw issues with it IIRC [12:26] he had never syned them to the cloud I think [12:26] pmcgowan, there is 1 user reporting data loss, you and another users had issues with the new sync yesterday [12:26] Even if this gets fixed, who knows what other problems pop up, this feature landed on Friday so really really late [12:26] jibel, I know what my issue was and renatu fixed that [12:27] pmcgowan, yesh nick problem was because he never synced the contacts in the cloud [12:27] renatu, but did you turn on sync or something? he said it was not enabled [12:28] renatu, then? he shouldn't lose his local contacts? [12:28] pmcgowan, yes we turn the sync on during the update. [12:28] renatu, we should not change the setting though right? [12:28] if user has it off [12:28] he was using it as a local store [12:28] jibel, contacts saved on google source that are not synced will be lost [12:28] renatu: at least I explicitly don't want my contacts to be synced into Google account [12:28] renatu: for privacy reasong, and I suspect I'm not alone [12:28] he must have set up the account though [12:29] Mirv, it wont sync without account info [12:29] Mirv, it will not sync contacts saved on your local source [12:29] or you could have account info with sync off [12:29] pmcgowan: right, I've set up Google account in order to read the e-mails from there [12:29] right [12:29] but I guess I could remove the account before upgrading [12:29] renatu, I think the error is turning sync on automatically [12:29] why do you need to do that? [12:29] renatu: oh, ok, so contacts in the Personal database won't get automatically synced? [12:29] no [12:30] Mirv, no [12:30] Niks were in the google db [12:30] but not using google [12:30] ok, then no big problem to check the settings again after upgrade [12:30] pmcgowan, it is a valid configuration, the user shouldn't lose his contacts in this case [12:30] jibel, I agree [12:31] yeah that's an user mistake if using wrong db than was meaning to [12:31] I think the contacts ui defaults to that account [12:31] so it just happens [12:31] pmcgowan, the problem is: we install a new online account service file and remove the old service file. [12:32] and? [12:32] pmcgowan, since the old service file was remove, there is no way to check if the old service was enable or not [12:33] renatu, well, we need to check before removing? [12:33] pmcgowan, maybe online account "db" keep track of that even after remove the service file [12:33] needs to yes [12:33] pmcgowan, it is a image update [12:33] Laney: if you have time to look again, I've rebuild with additional info in the changelog, and removed the cmake-extras change (it's not in main, it turns out) https://ci-train.ubuntu.com/job/ubuntu-landing-046-2-publish/19/artifact/libqtdbusmock_packaging_changes.diff [12:33] renatu, you understand that upon upgrade if you turn sync on by default you also upload data to an external provider without user agreement, there is a serious privacy issue here. [12:33] renatu, this is user data no? [12:34] pmcgowan, no, system service file [12:34] pmcgowan, /usr/share/accounts/service [12:34] jibel, yes I understand that [12:34] renatu, where is the info kept that the service is enabled [12:34] renatu, we cannot do that ,you have to preserve the settings [12:34] pmcgowan, on online account database on user db [12:34] yeah so honor that [12:35] pmcgowan, would be nice to have some online account expert help here [12:35] mardy, ^^ [12:35] * mardy reads the backlog [12:35] pmcgowan, the API does not return information about this service anymore, since the file was removed [12:35] hmm [12:36] pmcgowan, maybe we can workaround it for this specific case [12:37] trainguards: I’m not authorized to upload webbrowser-app (silo 59), I suppose this is because there are packaging changes that need a core-dev ack? [12:38] (if so the error message is not self-explanatory, it used to be clearer) [12:38] pmcgowan: and hence the talk of removing it and re-landing it at the start of ota8 instead [12:39] oSoMoN: yes, needs core-dev publishing (not just ack). for the message, you can file a bug at https://bugs.launchpad.net/bileto/ [12:39] will do [12:39] davmor2, I understand, just wanting the details [12:39] now to find a core-dev… [12:39] renatu: so, the information is still in the accounts DB, but there is no API to read it [12:40] cyphermox: there'd be multiple core-dev needing silos ready for publishing at https://requests.ci-train.ubuntu.com/#/trainguards - 016, 023, 046, 057 (your own) and 059 [12:40] renatu: can you point me at the source tree where the .service and .application files are? [12:41] renatu: I'm especially interested in the .application file [12:41] mardy, yes, let me chek that [12:42] sil2100, I would like bill to weigh in on this [12:42] mardy, in OTA6: /usr/share/accounts/applications/contacts-sync.application [12:43] Mirv, robru: https://bugs.launchpad.net/bileto/+bug/1503264 [12:43] Ubuntu bug 1503264 in Bileto "Error message when a core-dev ack is needed used to be more explicit" [Undecided,New] [12:43] mardy, we are replacing it in favor of: /usr/share/accounts/applications/address-book-app.application [12:43] pmcgowan: ACK [12:43] oSoMoN: thanks [12:44] renatu: do you have a link to the file in bzr? [12:44] mardy, sure, wait a minute [12:46] mardy, http://bazaar.launchpad.net/~phablet-team/sync-monitor/trunk/view/49/accounts/applications/contacts-sync.application.in?start_revid=51 [12:46] renatu: thanks. So, my suggestion is to keep the old .service file, don't delete it now [12:46] renatu: but you can delete the .application file [12:47] renatu: for the new service file(s), don't use "contacts" as type, but something else [12:47] renatu: like "buteo-contacts", maybe [12:47] renatu: so you can still read the setting from the old service file, yet it will be invisible from the UI [12:47] renatu: and you can remove it completely after a few months [12:48] mardy, can we access the db direct to get the old settings? [12:48] mardy, the updater is a unconfined app [12:49] renatu: well, you could, with sqlite, but I think you are complicating your life [12:49] mardy, I think it will be more complicated to revert the changes that we did already [12:49] quering the db should be very easy, no? [12:51] mardy, changing the service name will involve few changes on updater, address-book-app and buteo. [12:54] cyphermox, dobey is silo 57 ready for qa? [12:54] mardy, could you point me which table/field I need to read? [12:54] pmcgowan, silo 57 is only for wily, we need one for vivid [12:55] jibel, bah [12:55] I was hoping cyphermox will prepare one as soon as wily lands [12:55] renatu: I'll do in a second, but first it's important that you agree on renaming the type [12:55] renatu: especially for the convergence scenario [12:55] sil2100, I would have prefered to have that fix with the apport change [12:55] renatu: "contacts" is a generic type, also used by EDS [12:55] oh well [12:56] renatu: if you don't change it now, you'll cry later :-) [12:56] renatu: and this is the best (maybe only?) time to do it [12:57] pmcgowan, jibel, sil2100: shouldn't the silo be dual? [12:57] renatu: then, if you want remove the .service file and check the SQLite DB directly, you can do so, but in any case I strongly insist that you rename the type [12:57] dobey: it's not a CI Train package [12:58] sil2100: i know. but can it not have both wily and overlay packages in it? [12:58] renatu: the file is ~/.config/libaccounts-glib/accounts.db [12:58] mardy, renaming it at this point is very trick [12:58] renatu: I know, you might not make it for the OTA, but in that case I'd say you should not hurry, and postpone it [12:58] dobey: not sure how the train would handle it right now, there's a possibility it could, but it's not a standard procedure anyway [12:59] mardy, i do not know, we have solve the problem with the service name conflict with EDS [12:59] pmcgowan, sil2100, jibel : definitely not in favor of reverting, want to fully understand the issue here and see if we can fix it [13:00] bfiller, pmcgowan: ok, just remember today is the final freeze date which we need to obey, otherwise QA won't have time to test all the images [13:00] bfiller, the specific issue being disucssed is we sync'd contacts to google when the sync was disabled [13:00] pmcgowan: yup, I'm seeing that. sounds fixable [13:01] renatu: I think this should work: select account,value from Settings where service = (SELECT id from Services where type='contacts'); [13:01] sil2100, I think we can fix that today [13:01] renatu: just read the setting before doing the upgrade and then honor it? [13:01] And we need to be confident there's no other issues [13:01] bfiller, need to retain that settign somehow when changing servcies [13:01] sil2100: ok. i'm not sure why the wily landing wasn't a direct upload, and the silo only has the version to land in overlay. [13:01] bfiller, the service file is removed so the api cannot be queried [13:01] pmcgowan: read it before it gets removed [13:01] renatu: ^^ [13:01] its removed on the update [13:01] bfiller, yes this is what I am discussing with mardy [13:01] they have an idea [13:01] renatu: well, why should EDS fix the problem? they came first... :-) [13:02] mardy, they use "contacts" for the same reason as buteo , if we install both you will have duplicated contacts on your phone [13:02] mardy, one conflict with other [13:03] renatu: you are asking EDS to do the changes that you don't want to do now, with the difference that this is the perfect time for *you* to change the name, since you are changing backend [13:03] mardy, I am not saying that EDS should change the service name [13:03] renatu: what is status of silo 19, has QA tested that yet, pmcgowan that has fix for issues people were seeing yesterday like you and mterry [13:03] renatu: well, they must, if you don't [13:04] bfiller, it landed [13:04] mardy, I added a conflict on debian package control file [13:04] bfiller, er 23 landed [13:04] renatu: is 19 ready for QA, it's not marked so [13:04] bfiller, whats in 19? let me look [13:04] bfiller, I was planing to use it to fix this bug too [13:04] oh [13:05] bfiller, tony's fix was in 23 which landed [13:05] pmcgowan: ok, the problem you and mtery were seeing failed sync was because of other accounts you had configured somehow were getting included in the sync upgrade when they shouldn't this silo ignores all but google [13:05] mardy, we can not have both package installed otherwise you will have duplicated contacts [13:06] mardy, even with different service names [13:06] renatu: what if people will want to use both EDS and unity8 (in different desktop sessions)? [13:06] bfiller, oh another shared issue we had, right [13:06] renatu: we can have both installed and working fine, if you change the service type [13:07] mardy, both work in automatically way, as soon as you add your account eds create the sources (same for buteo) [13:07] mardy, having both services will cause a lot of problems [13:07] renatu: which files exactly are getting removed during the image upgrade? [13:08] bfiller, we have a solution already. I will check the db for the old settings [13:08] bfiller, this file is getting removed: http://bazaar.launchpad.net/~phablet-team/sync-monitor/trunk/view/49/accounts/applications/contacts-sync.application.in?start_revid=51 [13:08] renatu: again, it will cause problems only if you don't rename the service type [13:09] mardy, why? if I have both services even with different names. The sync with happen in both services [13:09] and you will have duplicate contacts [13:09] pmcgowan, I see you’ve marked bug #1356516 fixed, technically it hasn’t landed yet (although all it needs is a core-dev ack) [13:09] bug 1356516 in webbrowser-app (Ubuntu) "consider shipping apparmor profile for webbrowser-app" [Critical,In progress] https://launchpad.net/bugs/1356516 [13:09] mardy, eds will create source for his service, buteo will create source for it service, and both will download the contacts [13:10] oSoMoN, ah ok jumped the gun a bit on morning cleanup [13:10] I’m eager to mark it fixed too :) [13:10] renatu: well, if the same user is using both buteo and EDS, yes [13:10] mardy, exactly, [13:11] renatu: but if I'm using unity8 and my wife is using GNOME (she isn't but let's suppose :-) ), everything would work file [13:11] because of that buteo conflicts with eds-online-account service [13:11] *fine [13:11] renatu: it conflicts for the same user, but it shouldn't conflict at system level [13:12] renatu: can't we not delete the file but instead disable whatever service is using the file? then delete it after the upgrade is successful? then you don't have to use a non supporte api and directly query the db [13:12] not understanding why the file is deleted in first place [13:12] bfiller, the file is part of a debian package === alan_g|lunch is now known as alan_g [13:12] renatu: which package? [13:12] bfiller, sync-monitor [13:12] ogra_, would you have a moment to ack the packaging changes at https://ci-train.ubuntu.com/job/ubuntu-landing-059-2-publish/8/artifact/webbrowser-app_packaging_changes.diff ? [13:12] renatu: but we're not removing sync-monitor are we? [13:13]