| === chihchun_afk is now known as chihchun | ||
| === salem_ is now known as _salem | ||
| Mirv | morning | 04:30 |
|---|---|---|
| Mirv | hmm | 06:55 |
| sil2100 | davmor2: hey, seeing the e-mail about lost contacts on ubuntu-phone... you think that might be due to the buteo landing? | 07:15 |
| sil2100 | davmor2: if that's the case, I would say we need to revert | 07:15 |
| jibel | sil2100, it is | 07:16 |
| sil2100 | So much for Bill saying he's 'confident in it' | 07:17 |
| jibel | sil2100, but then if you revert do you recover your previous contact db since it has been converted? | 07:17 |
| anpok | 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 |
| anpok | s/or/of | 07:17 |
| psivaa | anpok: let me take a look | 07:17 |
| sil2100 | jibel: not sure, but it's all rc-proposed - that's the risk of using this channel | 07:18 |
| jibel | sil2100, I'd like to test the revert locally before reverting in the archive | 07:18 |
| sil2100 | jibel: ok | 07:18 |
| sil2100 | jibel: I'll prepare the revert in a silo then | 07:18 |
| sil2100 | I don't want this to go into a stable image | 07:18 |
| jibel | sil2100, which packages do I need to downgrade/uninstall to revert on my phone? | 07:18 |
| jibel | sil2100, agreed, it is not ready. He's the 3rd user with major issues | 07:19 |
| sil2100 | jibel: I would say: address-book-app, address-book-service, indicator-transfer and sync-monitor | 07:20 |
| sil2100 | Those 4 should be sufficient | 07:20 |
| sil2100 | Not all are required probably, but best to be sure | 07:20 |
| jibel | sil2100, there were packages added to the seed too? | 07:21 |
| psivaa | 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:22 |
| sil2100 | jibel: no, there were other packages but those are pulled in as deps | 07:30 |
| jibel | okay | 07:31 |
| jibel | sil2100, seb128 any news on UITK and the problem with USS? | 07:32 |
| jibel | bzoltan_, ^ | 07:32 |
| bzoltan_ | jibel: Yes, I have an MR what hopefully fixes it. | 07:33 |
| jibel | bzoltan_, so we move forward and no revert? | 07:33 |
| seb128 | bzoltan_, do you have the url of the merge request? | 07:33 |
| bzoltan_ | seb128: https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/fixThemingFallback/+merge/273497 | 07:34 |
| * sil2100 has enough reverts for today | 07:34 | |
| seb128 | uitk change, good :-) | 07:34 |
| bzoltan_ | jibel: let me first check that MR and understand the whole story | 07:34 |
| sil2100 | ;) | 07:34 |
| bzoltan_ | seb128: I have never had doubts that it was a version leakage ... | 07:35 |
| anpok | 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 |
| seb128 | bzoltan_, oh ok, I though you were considering it being settings' fault to import outdated versions | 07:35 |
| bzoltan_ | seb128: and mixing versions can provoke unexpected / untested issues | 07:35 |
| seb128 | bzoltan_, that shows a design flow in the uitk imho, but that's a discussion for another day | 07:36 |
| bzoltan_ | 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 |
| sil2100 | 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 |
| seb128 | 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:36 |
| sil2100 | jibel: but I suspect with the main packages reverted, whose shouldn't be used at all | 07:37 |
| bzoltan_ | 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 |
| seb128 | right | 07:37 |
| seb128 | 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 |
| bzoltan_ | 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:38 |
| sil2100 | bzoltan_: I think cihelp would need to take a look | 07:39 |
| bzoltan_ | 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 |
| seb128 | right | 07:39 |
| jgdx | read: USS will keep importing all possible uitk versions | 07:40 |
| seb128 | 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 |
| seb128 | jgdx, ^ do you know? | 07:40 |
| bzoltan_ | jgdx: LOL... and it should have AP test for the "open page - go back" for all pages :D | 07:41 |
| jgdx | bzoltan_, right :p | 07:42 |
| zsombi | jgdx: importing all possible versions will also lead you to errors | 07:43 |
| bzoltan_ | jgdx: actually I will contribute that to the USS project | 07:43 |
| jgdx | seb128, “at the top”? Not sure what you're referring to | 07:43 |
| zsombi | jgdx: like if you try to use Page from 1.2 in a PageStack from 1.3, it will blow up | 07:43 |
| zsombi | and that's not because of the versioning | 07:43 |
| jgdx | zsombi, i kid, we need to move everything to $new | 07:43 |
| seb128 | jgdx, the "<" chevron is in the header | 07:43 |
| zsombi | but because the Page in 1.2 is a different type than in 1.3 | 07:43 |
| jgdx | seb128, no, sorry, don't know about that | 07:43 |
| seb128 | zsombi, uitk should either support versions mixes or make it impossible to mix them and bail out on start with an error | 07:44 |
| seb128 | rather than doing like it was ok and hitting random bugs | 07:44 |
| zsombi | seb128: there are components you cna mix, but there are others you cannot | 07:45 |
| seb128 | zsombi, well, it shouldn't be up to the app writers to figure out by debugging weird things | 07:45 |
| bzoltan_ | seb128: the click-reviewers-tools or a forced code sanity check in the SDK should throw an error when imports are mixed | 07:45 |
| jibel | sil2100, where are previous builds of these packages? | 07:45 |
| zsombi | seb128: believe me, if you mix the setup I wrote above, your app will crash big time | 07:46 |
| seb128 | zsombi, k, still not a proper appdev experience | 07:46 |
| seb128 | it should gently error out telling you to not mix components ;-) | 07:46 |
| zsombi | 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:46 |
| zsombi | seb128: we cannot do anythign about that, it'll be QML compiler which will kick you out | 07:47 |
| sil2100 | jibel: you mean, sync-monitor etc.? | 07:47 |
| jibel | sil2100, yes | 07:48 |
| sil2100 | 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 |
| jibel | there is only latest build in the overlay | 07:48 |
| sil2100 | jibel: specifying the version number you want to download | 07:49 |
| jibel | I'll try that, thanks | 07:49 |
| sil2100 | jibel: yeah, I made a tool for that since digging in LP's PPA previous packages is almost impossible | 07:49 |
| sil2100 | 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:50 |
| psivaa | anpok: the latest job was running on krillin-08 | 07:53 |
| psivaa | so i did not think it had to do with just krillin-09 | 07:54 |
| psivaa | but will confirm | 07:54 |
| jibel | 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 |
| jibel | cyphermox, ^ | 08:13 |
| sil2100 | 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 |
| sil2100 | We'd need cyphermox | 08:15 |
| jibel | sil2100, yeah, the immediate problem is with this release, not really devel-proposed | 08:18 |
| sil2100 | jibel: right, but still - cyphermox is following the overall process, that everything needs to land into wily first | 08:19 |
| jibel | sil2100, the silo should be dual not wily only, isn't it? | 08:20 |
| sil2100 | jibel: manual sources cannot be dual silos | 08:21 |
| sil2100 | jibel: since upstart-watchdog is not a CI Train package, it needs 2 silos currently | 08:22 |
| davmor2 | 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:23 |
| sil2100 | davmor2: how far is the fix from landing? Since today is final freeze already... | 08:24 |
| davmor2 | sil2100: one for renato | 08:24 |
| davmor2 | sil2100: one for renatu | 08:24 |
| sil2100 | renatu: ^ | 08:24 |
| jibel | davmor2, it was the case for the user on u-touch yesterday, but what about the guy on the ML? | 08:26 |
| jibel | sil2100, I downgraded address-book and friends but contact sync with my google account doesn't seem to be working | 08:26 |
| jibel | 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:27 |
| sil2100 | jibel: you removed the new packages as well? | 08:28 |
| jibel | 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:29 |
| bzoltan_ | jibel: seb128: the fix works | 08:31 |
| seb128 | great! | 08:31 |
| jibel | sil2100, ah interesting, there is no option 'contact sync' in google account | 08:31 |
| sil2100 | jibel: you sure that all the required packages are at the right versions? | 08:32 |
| jibel | bzoltan_, nice, thanks! | 08:32 |
| jibel | sil2100, sync-monitor-uoa is not, which would explain the missing option | 08:33 |
| davmor2 | 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:34 |
| davmor2 | 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:41 |
| sil2100 | davmor2: yeah | 08:43 |
| sil2100 | I don't want QA to waste time waiting for more fixes before this is bug-free | 08:43 |
| bzoltan_ | jibel: sil2100: I am pushing a new UITK landing ...I wish to see it in OTA7 as it has four serious bugfix | 08:51 |
| sil2100 | bzoltan_: ACK | 08:52 |
| jibel | sil2100, sync works fine after a downgrade, I just had to re-enable contact sync in google account settings | 09:03 |
| bzoltan_ | 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:15 |
| oSoMoN | bzoltan_, how come it’s always staging that lands, instead of cherry-picking only a fix for the regression? | 09:48 |
| bzoltan_ | oSoMoN: because in my opinion cherry picking is generally not a good practice | 09:58 |
| bzoltan_ | 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:00 |
| oSoMoN | 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:01 |
| bzoltan_ | oSoMoN: No, it is not what happened | 10:02 |
| bzoltan_ | 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:02 |
| bzoltan_ | oSoMoN: both issues were introduced by normal feature development not by colliding bugfixes | 10:03 |
| oSoMoN | 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 |
| ubot5` | 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 |
| bzoltan_ | oSoMoN: not to mention that cherry picking is a maintenance nightmare | 10:04 |
| rvr | dbarth: Silo 16 approved | 10:04 |
| bzoltan_ | 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 |
| jibel | dbarth, although I didn't see much improvements on memory consumption. | 10:06 |
| bzoltan_ | oSoMoN: it is a sensitive balance between fear driven development and keeping the development pace optimal | 10:06 |
| oSoMoN | 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:07 |
| oSoMoN | there’s no such thing as "development pace" one day before final freeze, only critical bug fixes | 10:08 |
| jibel | dbarth, does silo 16 includes a fix for bug 1498953 ? | 10:08 |
| ubot5` | 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 |
| bzoltan_ | 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 |
| oSoMoN | bzoltan_, but as you pointed out earlier, our tests don’t (and cannot) cover every possible case | 10:08 |
| rvr | oSoMoN: Silo 16 landed, does 59 need a rebuild? | 10:09 |
| bzoltan_ | 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 |
| oSoMoN | jibel, yes it does fix that bug | 10:09 |
| oSoMoN | rvr, no need for a rebuild | 10:10 |
| jibel | oSoMoN, hm, I don't see much improvements then. Browse Euronews and it uses 30% of system's memory on krillin | 10:10 |
| jibel | oSoMoN, open a webapp and OOM starts killing processes | 10:10 |
| bzoltan_ | 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:10 |
| oSoMoN | 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:11 |
| oSoMoN | bzoltan_, fair enough, I was only suggesting to be cautious the day before final freeze, not slow down the general pace of landings | 10:12 |
| oSoMoN | bzoltan_, and given our history of regressions, maybe we should be a bit more conservative (or paranoid if you prefer) | 10:13 |
| bzoltan_ | oSoMoN: Point taken... beleive me :) I was furious both times and I am taking actions to prevent the same problem | 10:13 |
| bzoltan_ | oSoMoN: What regressions? | 10:13 |
| bzoltan_ | oSoMoN: catching a bug in a staging area is not a regression... | 10:14 |
| bzoltan_ | oSoMoN: we have not released regressing UITK for extreme long time... | 10:14 |
| oSoMoN | 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 |
| bzoltan_ | oSoMoN: bugs we do :) like everybody else too | 10:15 |
| bzoltan_ | 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:16 |
| bzoltan_ | 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 | 10:17 |
| === chihchun is now known as chihchun_afk | ||
| pete-woods | Mirv: I have a new entry in debian/changelog, is that why we don't have permission? | 10:37 |
| Mirv | 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 |
| Mirv | and the fact that the package is in main (I thought it was universe that's why I tried to publish it) | 10:37 |
| pete-woods | right, so we need someone with moor power | 10:38 |
| Mirv | so needs core-dev rights | 10:38 |
| Mirv | yes | 10:38 |
| bzoltan_ | jibel: the silo14 is ready https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-014 | 10:40 |
| pete-woods | 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:41 |
| Laney | It contains changes not explained in the changelog, so no. | 10:42 |
| pete-woods | okay, fixing that | 10:52 |
| pete-woods | and rebuilding | 10:52 |
| Laney | thanks! | 10:53 |
| pete-woods | well, at least attempting to rebuild | 10:57 |
| pete-woods | 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 |
| sil2100 | pete-woods: hey! | 11:00 |
| sil2100 | pete-woods: hm, I saw something like this once, a re-build helped as it was something transient on the train machine | 11:00 |
| pete-woods | sil2100: this is the second build | 11:01 |
| sil2100 | Not sure if that's the same thing, but maybe you could try before we investigate further | 11:01 |
| pete-woods | I can try a third, though | 11:01 |
| sil2100 | Ok then | 11:01 |
| sil2100 | Let me look deeper | 11:01 |
| pete-woods | I cancelled a build, though | 11:01 |
| pete-woods | and I think it could well be that | 11:01 |
| pete-woods | maybe some junk left behind | 11:01 |
| sil2100 | 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 |
| sil2100 | In the past it could bust the whole silo | 11:02 |
| pete-woods | :O | 11:03 |
| pete-woods | okay, will be more careful in future | 11:03 |
| pete-woods | I was trying to catch it before it uploaded the source package | 11:03 |
| sil2100 | mktemp: failed to create directory via template '/tmp/debsign.XXXXXXXX': No space left on device | 11:03 |
| sil2100 | This worries me a bit! | 11:04 |
| sil2100 | Let me try cleaning some space | 11:04 |
| sil2100 | pete-woods: ok, try now | 11:06 |
| sil2100 | The pbuilders wasting space gets a bit troublesome... | 11:06 |
| pete-woods | sil2100: thanks, I think you've spotted the right error there | 11:07 |
| bzoltan_ | 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:08 |
| sil2100 | bzoltan_: ok | 11:10 |
| sil2100 | Thanks! | 11:10 |
| pete-woods | sil2100: that seems to have fixed it, thanks! | 11:10 |
| sil2100 | pete-woods: phew! yw! | 11:10 |
| jibel | bzoltan_, okay someone will take it | 11:11 |
| bzoltan_ | jibel: thank you | 11:11 |
| jibel | rvr, ^ do you fancy another testrun of uitk? | 11:12 |
| * rvr reads | 11:13 | |
| jibel | rvr, this is the fix for the missing headers in system-settings | 11:14 |
| rvr | Ahh, good, good | 11:14 |
| rvr | I'll take it | 11:14 |
| bzoltan_ | rvr: Thank you! Please be as hard as you can :) It is the third attempt to land that piece of ... errrr ... art? | 11:20 |
| rvr | bzoltan_: lol | 11:24 |
| jibel | bzoltan_, no worries, rvr can reject it a 4th time. He seems to be really enjoying it ;) | 11:27 |
| bzoltan_ | jibel: :D I am sure he does | 11:28 |
| * rvr won't comment | 11:28 | |
| sil2100 | ;) | 11:35 |
| dbarth | jibel: yes, silo 16, oxide 1.9.5 includes a patch to deal with lowering those limits | 11:47 |
| === _salem is now known as salem_ | ||
| === alan_g is now known as alan_g|lunch | ||
| Mirv | bah | 12:12 |
| renatu | davmor2, I have the fix already, just testing | 12:18 |
| pmcgowan | renatu, did you see that nik says he lost his contacts? | 12:22 |
| renatu | pmcgowan, no, | 12:23 |
| sil2100 | pmcgowan: we're reverting buteo for OTA-7 | 12:23 |
| sil2100 | Too much risk... | 12:24 |
| renatu | pmcgowan, which channel? | 12:24 |
| pmcgowan | renatu, in the mailing list | 12:24 |
| jibel | renatu, https://lists.launchpad.net/ubuntu-phone/msg16055.html | 12:24 |
| pmcgowan | sil2100, oh? | 12:24 |
| pmcgowan | sil2100, how do we revert the db update? | 12:24 |
| pmcgowan | this sounds iffy | 12:24 |
| sil2100 | pmcgowan: well, rc-proposed is meant to be broken, I just don't want it to go to stable | 12:25 |
| pmcgowan | sil2100, why are we reverting? | 12:25 |
| sil2100 | pmcgowan: because people are reporting lost contacts after the upgrade | 12:25 |
| pmcgowan | sil2100, more than just nik? | 12:25 |
| sil2100 | pmcgowan: QA mentioned at least 3 people | 12:25 |
| sil2100 | And jibel also saw issues with it IIRC | 12:26 |
| pmcgowan | he had never syned them to the cloud I think | 12:26 |
| jibel | pmcgowan, there is 1 user reporting data loss, you and another users had issues with the new sync yesterday | 12:26 |
| sil2100 | Even if this gets fixed, who knows what other problems pop up, this feature landed on Friday so really really late | 12:26 |
| pmcgowan | jibel, I know what my issue was and renatu fixed that | 12:26 |
| renatu | pmcgowan, yesh nick problem was because he never synced the contacts in the cloud | 12:27 |
| pmcgowan | renatu, but did you turn on sync or something? he said it was not enabled | 12:27 |
| jibel | renatu, then? he shouldn't lose his local contacts? | 12:28 |
| renatu | pmcgowan, yes we turn the sync on during the update. | 12:28 |
| pmcgowan | renatu, we should not change the setting though right? | 12:28 |
| pmcgowan | if user has it off | 12:28 |
| pmcgowan | he was using it as a local store | 12:28 |
| renatu | jibel, contacts saved on google source that are not synced will be lost | 12:28 |
| Mirv | renatu: at least I explicitly don't want my contacts to be synced into Google account | 12:28 |
| Mirv | renatu: for privacy reasong, and I suspect I'm not alone | 12:28 |
| pmcgowan | he must have set up the account though | 12:28 |
| pmcgowan | Mirv, it wont sync without account info | 12:29 |
| renatu | Mirv, it will not sync contacts saved on your local source | 12:29 |
| pmcgowan | or you could have account info with sync off | 12:29 |
| Mirv | pmcgowan: right, I've set up Google account in order to read the e-mails from there | 12:29 |
| pmcgowan | right | 12:29 |
| Mirv | but I guess I could remove the account before upgrading | 12:29 |
| pmcgowan | renatu, I think the error is turning sync on automatically | 12:29 |
| pmcgowan | why do you need to do that? | 12:29 |
| Mirv | renatu: oh, ok, so contacts in the Personal database won't get automatically synced? | 12:29 |
| pmcgowan | no | 12:29 |
| renatu | Mirv, no | 12:30 |
| pmcgowan | Niks were in the google db | 12:30 |
| pmcgowan | but not using google | 12:30 |
| Mirv | ok, then no big problem to check the settings again after upgrade | 12:30 |
| jibel | pmcgowan, it is a valid configuration, the user shouldn't lose his contacts in this case | 12:30 |
| pmcgowan | jibel, I agree | 12:30 |
| Mirv | yeah that's an user mistake if using wrong db than was meaning to | 12:31 |
| pmcgowan | I think the contacts ui defaults to that account | 12:31 |
| pmcgowan | so it just happens | 12:31 |
| renatu | pmcgowan, the problem is: we install a new online account service file and remove the old service file. | 12:31 |
| pmcgowan | and? | 12:32 |
| renatu | pmcgowan, since the old service file was remove, there is no way to check if the old service was enable or not | 12:32 |
| pmcgowan | renatu, well, we need to check before removing? | 12:33 |
| renatu | pmcgowan, maybe online account "db" keep track of that even after remove the service file | 12:33 |
| pmcgowan | needs to yes | 12:33 |
| renatu | pmcgowan, it is a image update | 12:33 |
| pete-woods | 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 |
| jibel | 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 |
| pmcgowan | renatu, this is user data no? | 12:33 |
| renatu | pmcgowan, no, system service file | 12:34 |
| renatu | pmcgowan, /usr/share/accounts/service | 12:34 |
| renatu | jibel, yes I understand that | 12:34 |
| pmcgowan | renatu, where is the info kept that the service is enabled | 12:34 |
| jibel | renatu, we cannot do that ,you have to preserve the settings | 12:34 |
| renatu | pmcgowan, on online account database on user db | 12:34 |
| pmcgowan | yeah so honor that | 12:34 |
| renatu | pmcgowan, would be nice to have some online account expert help here | 12:35 |
| pmcgowan | mardy, ^^ | 12:35 |
| * mardy reads the backlog | 12:35 | |
| renatu | pmcgowan, the API does not return information about this service anymore, since the file was removed | 12:35 |
| pmcgowan | hmm | 12:35 |
| renatu | pmcgowan, maybe we can workaround it for this specific case | 12:36 |
| oSoMoN | 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:37 |
| oSoMoN | (if so the error message is not self-explanatory, it used to be clearer) | 12:38 |
| davmor2 | pmcgowan: and hence the talk of removing it and re-landing it at the start of ota8 instead | 12:38 |
| Mirv | 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 |
| oSoMoN | will do | 12:39 |
| pmcgowan | davmor2, I understand, just wanting the details | 12:39 |
| oSoMoN | now to find a core-dev… | 12:39 |
| mardy | renatu: so, the information is still in the accounts DB, but there is no API to read it | 12:39 |
| Mirv | 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 |
| mardy | renatu: can you point me at the source tree where the .service and .application files are? | 12:40 |
| mardy | renatu: I'm especially interested in the .application file | 12:41 |
| renatu | mardy, yes, let me chek that | 12:41 |
| pmcgowan | sil2100, I would like bill to weigh in on this | 12:42 |
| renatu | mardy, in OTA6: /usr/share/accounts/applications/contacts-sync.application | 12:42 |
| oSoMoN | Mirv, robru: https://bugs.launchpad.net/bileto/+bug/1503264 | 12:43 |
| ubot5` | Ubuntu bug 1503264 in Bileto "Error message when a core-dev ack is needed used to be more explicit" [Undecided,New] | 12:43 |
| renatu | mardy, we are replacing it in favor of: /usr/share/accounts/applications/address-book-app.application | 12:43 |
| sil2100 | pmcgowan: ACK | 12:43 |
| Mirv | oSoMoN: thanks | 12:43 |
| mardy | renatu: do you have a link to the file in bzr? | 12:44 |
| renatu | mardy, sure, wait a minute | 12:44 |
| renatu | mardy, http://bazaar.launchpad.net/~phablet-team/sync-monitor/trunk/view/49/accounts/applications/contacts-sync.application.in?start_revid=51 | 12:46 |
| mardy | renatu: thanks. So, my suggestion is to keep the old .service file, don't delete it now | 12:46 |
| mardy | renatu: but you can delete the .application file | 12:46 |
| mardy | renatu: for the new service file(s), don't use "contacts" as type, but something else | 12:47 |
| mardy | renatu: like "buteo-contacts", maybe | 12:47 |
| mardy | renatu: so you can still read the setting from the old service file, yet it will be invisible from the UI | 12:47 |
| mardy | renatu: and you can remove it completely after a few months | 12:47 |
| renatu | mardy, can we access the db direct to get the old settings? | 12:48 |
| renatu | mardy, the updater is a unconfined app | 12:48 |
| mardy | renatu: well, you could, with sqlite, but I think you are complicating your life | 12:49 |
| renatu | mardy, I think it will be more complicated to revert the changes that we did already | 12:49 |
| renatu | quering the db should be very easy, no? | 12:49 |
| renatu | mardy, changing the service name will involve few changes on updater, address-book-app and buteo. | 12:51 |
| pmcgowan | cyphermox, dobey is silo 57 ready for qa? | 12:54 |
| renatu | mardy, could you point me which table/field I need to read? | 12:54 |
| jibel | pmcgowan, silo 57 is only for wily, we need one for vivid | 12:54 |
| pmcgowan | jibel, bah | 12:55 |
| sil2100 | I was hoping cyphermox will prepare one as soon as wily lands | 12:55 |
| mardy | renatu: I'll do in a second, but first it's important that you agree on renaming the type | 12:55 |
| mardy | renatu: especially for the convergence scenario | 12:55 |
| pmcgowan | sil2100, I would have prefered to have that fix with the apport change | 12:55 |
| mardy | renatu: "contacts" is a generic type, also used by EDS | 12:55 |
| pmcgowan | oh well | 12:55 |
| mardy | renatu: if you don't change it now, you'll cry later :-) | 12:56 |
| mardy | renatu: and this is the best (maybe only?) time to do it | 12:56 |
| dobey | pmcgowan, jibel, sil2100: shouldn't the silo be dual? | 12:57 |
| mardy | 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 |
| sil2100 | dobey: it's not a CI Train package | 12:57 |
| dobey | sil2100: i know. but can it not have both wily and overlay packages in it? | 12:58 |
| mardy | renatu: the file is ~/.config/libaccounts-glib/accounts.db | 12:58 |
| renatu | mardy, renaming it at this point is very trick | 12:58 |
| mardy | 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 |
| sil2100 | 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:58 |
| renatu | mardy, i do not know, we have solve the problem with the service name conflict with EDS | 12:59 |
| bfiller | pmcgowan, sil2100, jibel : definitely not in favor of reverting, want to fully understand the issue here and see if we can fix it | 12:59 |
| sil2100 | 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 |
| pmcgowan | bfiller, the specific issue being disucssed is we sync'd contacts to google when the sync was disabled | 13:00 |
| bfiller | pmcgowan: yup, I'm seeing that. sounds fixable | 13:00 |
| mardy | renatu: I think this should work: select account,value from Settings where service = (SELECT id from Services where type='contacts'); | 13:01 |
| renatu | sil2100, I think we can fix that today | 13:01 |
| bfiller | renatu: just read the setting before doing the upgrade and then honor it? | 13:01 |
| sil2100 | And we need to be confident there's no other issues | 13:01 |
| pmcgowan | bfiller, need to retain that settign somehow when changing servcies | 13:01 |
| dobey | 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 |
| pmcgowan | bfiller, the service file is removed so the api cannot be queried | 13:01 |
| bfiller | pmcgowan: read it before it gets removed | 13:01 |
| bfiller | renatu: ^^ | 13:01 |
| pmcgowan | its removed on the update | 13:01 |
| renatu | bfiller, yes this is what I am discussing with mardy | 13:01 |
| pmcgowan | they have an idea | 13:01 |
| mardy | renatu: well, why should EDS fix the problem? they came first... :-) | 13:01 |
| renatu | mardy, they use "contacts" for the same reason as buteo , if we install both you will have duplicated contacts on your phone | 13:02 |
| renatu | mardy, one conflict with other | 13:02 |
| mardy | 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 |
| renatu | mardy, I am not saying that EDS should change the service name | 13:03 |
| bfiller | 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 |
| mardy | renatu: well, they must, if you don't | 13:03 |
| pmcgowan | bfiller, it landed | 13:04 |
| renatu | mardy, I added a conflict on debian package control file | 13:04 |
| pmcgowan | bfiller, er 23 landed | 13:04 |
| bfiller | renatu: is 19 ready for QA, it's not marked so | 13:04 |
| pmcgowan | bfiller, whats in 19? let me look | 13:04 |
| renatu | bfiller, I was planing to use it to fix this bug too | 13:04 |
| pmcgowan | oh | 13:04 |
| pmcgowan | bfiller, tony's fix was in 23 which landed | 13:05 |
| bfiller | 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 |
| renatu | mardy, we can not have both package installed otherwise you will have duplicated contacts | 13:05 |
| renatu | mardy, even with different service names | 13:06 |
| mardy | renatu: what if people will want to use both EDS and unity8 (in different desktop sessions)? | 13:06 |
| pmcgowan | bfiller, oh another shared issue we had, right | 13:06 |
| mardy | renatu: we can have both installed and working fine, if you change the service type | 13:06 |
| renatu | mardy, both work in automatically way, as soon as you add your account eds create the sources (same for buteo) | 13:07 |
| renatu | mardy, having both services will cause a lot of problems | 13:07 |
| bfiller | renatu: which files exactly are getting removed during the image upgrade? | 13:07 |
| renatu | bfiller, we have a solution already. I will check the db for the old settings | 13:08 |
| renatu | 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 |
| mardy | renatu: again, it will cause problems only if you don't rename the service type | 13:08 |
| renatu | mardy, why? if I have both services even with different names. The sync with happen in both services | 13:09 |
| renatu | and you will have duplicate contacts | 13:09 |
| oSoMoN | 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 |
| ubot5` | bug 1356516 in webbrowser-app (Ubuntu) "consider shipping apparmor profile for webbrowser-app" [Critical,In progress] https://launchpad.net/bugs/1356516 | 13:09 |
| renatu | mardy, eds will create source for his service, buteo will create source for it service, and both will download the contacts | 13:09 |
| pmcgowan | oSoMoN, ah ok jumped the gun a bit on morning cleanup | 13:10 |
| oSoMoN | I’m eager to mark it fixed too :) | 13:10 |
| mardy | renatu: well, if the same user is using both buteo and EDS, yes | 13:10 |
| renatu | mardy, exactly, | 13:10 |
| mardy | 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 |
| renatu | because of that buteo conflicts with eds-online-account service | 13:11 |
| mardy | *fine | 13:11 |
| mardy | renatu: it conflicts for the same user, but it shouldn't conflict at system level | 13:11 |
| bfiller | 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 |
| bfiller | not understanding why the file is deleted in first place | 13:12 |
| renatu | bfiller, the file is part of a debian package | 13:12 |
| === alan_g|lunch is now known as alan_g | ||
| bfiller | renatu: which package? | 13:12 |
| renatu | bfiller, sync-monitor | 13:12 |
| oSoMoN | 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 |
| bfiller | renatu: but we're not removing sync-monitor are we? | 13:12 |
| renatu | bfiller, sync monitor is not sync contact anymore | 13:13 |
| bfiller | renatu: I know, but we're not removing that package, still need it for calendar sync so why is the file being removed | 13:13 |
| renatu | mardy, in your exaple you will never be able to create one online account. otherwise you (using unity8) will have duplicate contacts | 13:13 |
| pmcgowan | bfiller, renatu mardy you guys may need to hangout | 13:14 |
| mardy | pmcgowan: agreed, but I'm currently in another hangout | 13:14 |
| pmcgowan | ah right | 13:14 |
| bfiller | renatu, mardy : https://plus.google.com/hangouts/_/canonical.com/system-apps?authuser=0 | 13:14 |
| renatu | bfiller, yes, but if we keep that the service will appear duplicated on online accounts | 13:14 |
| bfiller | lets discuss on hangout, I'm on | 13:15 |
| mardy | pmcgowan: and I've to leave after that, so I'm afraid it won't be today | 13:15 |
| pmcgowan | mardy, can we excuse yourself from the weekly? | 13:15 |
| pmcgowan | s/you/we | 13:15 |
| oSoMoN | trainguards: actually, jdstrand already acked the packaging changes when he reviewed the MR: https://code.launchpad.net/~osomon/webbrowser-app/apparmor-profile/+merge/272850/comments/688199 , so can silo 59 be published, please? | 13:16 |
| sil2100 | oSoMoN: we need someone with proper permissions to press the button... | 13:16 |
| oSoMoN | right | 13:18 |
| oSoMoN | I almost forgot the permissions are really enforced, not mere paperwork :) | 13:18 |
| pmcgowan | mterry, is a core dev | 13:19 |
| pmcgowan | sil2100, how is it you are not? | 13:19 |
| sil2100 | Didn't happen, I got rejected last time | 13:19 |
| sil2100 | Since I didn't have enough main-package work documented | 13:19 |
| pmcgowan | bah | 13:19 |
| pmcgowan | also surprised Mirv is not | 13:20 |
| Mirv | I also didn't apply yet since sil2100 got rejected and I haven't handled the same things yet they asked sil2100 to handle :) | 13:21 |
| pmcgowan | is ogra_ around to push the publish button | 13:22 |
| * sil2100 pokes mterry | 13:22 | |
| Mirv | I poked cyphermox earlier, but he's not yet around | 13:22 |
| * mterry looks startled | 13:23 | |
| mterry | sil2100, what's up? | 13:23 |
| Mirv | mterry: "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 " | 13:23 |
| sil2100 | mterry: \o/ https://ci-train.ubuntu.com/job/ubuntu-landing-059-2-publish/ <- could you? :) | 13:23 |
| Mirv | well 057 is not "your" but I copy-pasted the message to Mathieu | 13:23 |
| sil2100 | uuh | 13:28 |
| cyphermox | Mirv hey | 13:29 |
| Mirv | cyphermox: hey, just some core-dev reviewing+publishing needed | 13:30 |
| cyphermox | yep | 13:30 |
| mterry | Sorry had internet problems | 13:31 |
| mterry | <mterry> OK, will look | 13:31 |
| mterry | Mirv, sil2100: so again, not used to trainguard work -- do any of these need packaging acks (which I look for by clicking on "build" and going through latest artifacts, right?) or is it just that they are going to main? | 13:31 |
| mterry | I guess it wouldn't hurt to glance at regular diff anyway too | 13:31 |
| sil2100 | Mirv: all of them need ACKs, the silo 59 already got approved by jdstrand, but the others probably not | 13:32 |
| mterry | cyphermox, you're back! want to split the silos? | 13:33 |
| cyphermox | sure | 13:34 |
| sil2100 | ;) | 13:34 |
| Mirv | mterry: ^ + many of them are manually uploaded to the PPA so they always need core-dev to do the publishing nowadays, whether they have packaging ack or not. and the rest then have packaging changes in their MP:s and are going to main. | 13:34 |
| Mirv | so oxide, upstart-watchdog and network-manager are main packages manually uploaded, and webbrowser-app libqtdbusmock have packaging changes. | 13:34 |
| cyphermox | so mterry,you take the top? | 13:35 |
| mterry | cyphermox, heh, you must have a wider screen than me. I'll take 16, 28, and 57? | 13:35 |
| cyphermox | ahah, yeah, sorry :) | 13:36 |
| mterry | cyphermox, hold up on silo 23 | 13:37 |
| cyphermox | ok | 13:37 |
| mterry | sil2100, how come silo 16 doesn't have a destination ppa? | 13:41 |
| sil2100 | mterry: uh, nice catch! | 13:42 |
| sil2100 | mterry: hm | 13:42 |
| sil2100 | mterry: actually I see the version number is not modified | 13:42 |
| sil2100 | Mirv: ^ ? | 13:42 |
| sil2100 | Mirv: did you follow silo 16? | 13:42 |
| sil2100 | Mirv: since the version doesn't have ~overlay1 appended, is this supposed to go to -updates? | 13:43 |
| sil2100 | Mirv: I think not | 13:43 |
| sil2100 | Mirv: since if it did, then I wouldn't use a silo for it as we build against the overlay | 13:43 |
| mterry | Guh my internet! | 13:48 |
| mterry | <mterry> sil2100, doesn't it update to 1.9.5 vs 1.9.3? | 13:49 |
| mterry | but you mean it has no ~overlay1 | 13:49 |
| cyphermox | pete-woods: I'm reviewing silo 46; could you explain to me why you removed dh_makeshlibs -V; and whether this is really what you want, as this will have an effect on the dependencies on your packages | 13:49 |
| sil2100 | mterry: yeah, generally anything that lands only to the overlay we append with some ~overlay1 tag in version etc. to make sure no one publishes the same version to standard vivid | 13:50 |
| sil2100 | mterry: so I'd like this to be resolved before we publish | 13:50 |
| mterry | sil2100, ok | 13:52 |
| pete-woods | cyphermox: the reason I (probably wrongly) removed it, is because I thought you weren't supposed to use it in packages in main, and that it'd somehow slipped through the review cracks when my package was MIR'ed | 13:52 |
| mterry | abeato, for silo 28, with the fd fixes... | 13:52 |
| mterry | abeato, the gst-plugins-bad update. I see most of it was pulled from wily. But the last commit that fixes ref handling in gstreamer, was that ever released to wily? | 13:53 |
| abeato | mterry, not yet, but it is in a MP | 13:53 |
| pete-woods | cyphermox: if it's normal to just keep it in there, I'll remove that change and rebuild | 13:53 |
| abeato | mterry, https://code.launchpad.net/~alfonsosanchezbeato/ubuntu/+source/gst-plugins-bad1.0/+git/gst-plugins-bad1.0/+merge/273509 | 13:53 |
| cyphermox | pete-woods: not sure | 13:53 |
| cyphermox | sil2100: ^ | 13:53 |
| abeato | mterry, but it is not exactly the same fix because there was a previous change in wily | 13:54 |
| cyphermox | sil2100: also, I'm just noticing webbrowser-app looks like it was a dual-landing, but landed wily and vivid in the stable-ppa-overlay, that seems wrong | 13:55 |
| mterry | abeato, ok... I'm just leery of creating future regressions because this never landed in wily, in the case that there are problems with landing this in wily | 13:55 |
| cyphermox | now the same bug fixes won't be in wily-release. | 13:55 |
| sil2100 | cyphermox: we land all touch things to overlay now | 13:55 |
| cyphermox | mmkay | 13:55 |
| sil2100 | cyphermox: it's a global switch now | 13:55 |
| cyphermox | what about wily? | 13:55 |
| sil2100 | cyphermox: as for the previous issue... | 13:55 |
| mterry | sil2100, what's the policy on landing something to the overlay ppa when the same changes are in flight for wily (a filed MP exists), but haven't landed yet? | 13:55 |
| sil2100 | cyphermox: I generally hate dh_makeshlibs -V, but if it was there already, I'm not sure about removing it without making sure it's not required anymore | 13:56 |
| cyphermox | *shrugs* | 13:56 |
| cyphermox | pete-woods: let me look at it a bit harder, perhaps removing will be fine. | 13:57 |
| pete-woods | sil2100: it was only there in the first place due to me copying and pasting it | 13:57 |
| pete-woods | if that information is useful | 13:57 |
| sil2100 | pete-woods: ah, ok | 13:58 |
| sil2100 | mterry: it's good, as long as the wily changes are staged somewhere | 13:58 |
| mterry | sil2100, ok. I worry that there is a possible chance for regression if the staged landing never makes it for whatever reason. But I guess it's "close enough". Wish we could have a whiteboard somewhere where we listed all those loose threads | 13:59 |
| mterry | abeato, ^ it's ok to be in flight. will publish | 14:02 |
| abeato | mterry, cool, thanks | 14:02 |
| oSoMoN | Mirv, the additional build dep for silo 59 on silo 31 can now be removed | 14:04 |
| jibel | pmcgowan, bfiller is there really no silo ready for QA required for OTA7 | 14:04 |
| jibel | bfiller, silo 11 is not ready? | 14:06 |
| bfiller | jibel: checking, in standup atm | 14:06 |
| Mirv | oSoMoN: thanks, I removed it earlier already (and commented on the silo) | 14:07 |
| oSoMoN | ok | 14:07 |
| cyphermox | pete-woods: so what this does is it will make any package that builds against libqtdbusmock depend on at least that version of libqtdbusmock; without it they'll just want any version. if you're not changing the ABI much I suppose it's not much of an issue | 14:08 |
| bfiller | jibel: silo 49 ready | 14:09 |
| mterry | cyphermox, why is silo 57 set to publish without qa? | 14:09 |
| mterry | cyphermox, oh because you are core dev and it's a sync?... but your versions are messed up | 14:09 |
| mterry | cyphermox, you'll be publishing a version higher than wily to vivid's overlay | 14:10 |
| cyphermox | ah, my fault, it should be going to both | 14:10 |
| mterry | cyphermox, oh right. missed that the silo is a wily one. | 14:10 |
| mterry | cyphermox, but it should be dual I guess | 14:10 |
| cyphermox | leave it wily for now | 14:11 |
| jibel | bfiller, none of the bugs it fixes is for OTA7. | 14:11 |
| cyphermox | people can request another landing for the vivid overlay | 14:11 |
| bfiller | jibel: silo 15 | 14:12 |
| mterry | cyphermox, ok | 14:13 |
| mterry | cyphermox, well you can push the publish button then. :) it's your upload | 14:13 |
| mterry | cyphermox, I'll take one of your other silos if you have one left | 14:13 |
| jibel | bfiller, okay | 14:14 |
| cyphermox | mterry: what's your opinion on libqtdbusmock? | 14:14 |
| cyphermox | (silo 46) | 14:14 |
| bfiller | jibel: probably silo 41 as well, which will have a revert. not done yet working on it | 14:14 |
| mterry | cyphermox, haven't looked at it yet, but can take | 14:14 |
| mterry | cyphermox, why is that one set to publish without qa? pete-woods? | 14:14 |
| cyphermox | a second look wouldn't hurt | 14:15 |
| sil2100 | seb128: hey! Since I just found the branch you proposed for u-c-d -> https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client-data/+bug/1503291 | 14:24 |
| ubot5` | Ubuntu bug 1503291 in ubuntuone-client-data (Ubuntu) "FTBFS on amd64 due to pep8 errors" [Undecided,New] | 14:24 |
| seb128 | sil2100, hey, yes | 14:24 |
| sil2100 | seb128: there was no bug for the FTBFS so I started working on it, didn't know you were on it :) | 14:24 |
| seb128 | sil2100, now you know ;-) | 14:25 |
| seb128 | I would have landed, but I'm waiting for an ack on another fix from dobey | 14:25 |
| seb128 | to the apport hook | 14:25 |
| sil2100 | Ok, so my debdiff for the distro-patch won't be necessary then, right? | 14:25 |
| seb128 | I guess not | 14:25 |
| sil2100 | Anyway, I generally fill in bugs for anything I work on, that's not the general process? | 14:25 |
| seb128 | that should go through CI landing | 14:25 |
| sil2100 | It was never released through the train though | 14:26 |
| seb128 | well, for things where we need mps I tend to assume that a merge proposal record the intend as well | 14:26 |
| seb128 | oh, it was not | 14:26 |
| seb128 | well as said I was waiting for another fix to get the ack | 14:26 |
| sil2100 | It wasn't, that's why I distropatched it | 14:26 |
| sil2100 | Ok | 14:26 |
| seb128 | then going to nag dobey for a landing | 14:26 |
| Laney | you can still talk to upstream before distro patching :P | 14:27 |
| seb128 | well it's not like that one was a lot of work | 14:27 |
| seb128 | it's moving some imports earlier in the source | 14:27 |
| seb128 | so not a lot of work wasted I guess | 14:27 |
| Laney | I'm talking about "no CI train -> distro patch" | 14:28 |
| sil2100 | Laney: I wanted to do a merge for that then ;) | 14:28 |
| * Laney nods | 14:28 | |
| sil2100 | Laney: I first made a distro-patch, then wanted to get it upstream but saw seb128's branch | 14:28 |
| seb128 | that's because you worked backward :p | 14:28 |
| seb128 | get it fixed upstream first | 14:28 |
| sil2100 | I was checking for bugs, but I forgot to check for MPs | 14:28 |
| seb128 | then backport | 14:28 |
| seb128 | it could have been fixed in trunk as well already | 14:29 |
| sil2100 | Yeah, probably ;) Just want to get the number of failures down | 14:29 |
| seb128 | always a good idea to start by checking trunk/pending mps | 14:29 |
| dobey | sil2100, seb128: is it only an issue in wily? | 14:29 |
| sil2100 | I checked trunk, but not MPs though! | 14:29 |
| seb128 | dobey, is it? | 14:29 |
| sil2100 | dobey, seb128: yeah | 14:29 |
| seb128 | dobey, I didn't try on older serie, maybe it has always be | 14:29 |
| sil2100 | pep8 didn't report anything on my vivid machine | 14:29 |
| seb128 | dobey, or maybe python or apport changed | 14:29 |
| seb128 | dobey, sil2100, oh, you mean the pep8? | 14:30 |
| seb128 | pep8 got updated and is stricter | 14:30 |
| seb128 | dobey, I though you meant the import | 14:30 |
| dobey | seb128: i mean the ubuntuone-client-data issues in general. is it an issue on the phone | 14:30 |
| dobey | in the stable overlay ppa | 14:30 |
| seb128 | dobey, I don't know? the pep8 issue is a ftbfs in wily | 14:30 |
| dobey | ok | 14:30 |
| seb128 | I don't think it impacts vivid | 14:30 |
| seb128 | pep8 was updated in wily only | 14:31 |
| jibel | bfiller, jgdx what is the status of bug 1475568, any silo ready for qa expected soon ? | 14:37 |
| ubot5` | bug 1475568 in ubuntu-system-settings (Ubuntu) "Use OTA terminology in system settings" [Undecided,In progress] https://launchpad.net/bugs/1475568 | 14:37 |
| dobey | seb128: seems like apport just broke API with no warning, but i'm not sure when it happened | 14:42 |
| seb128 | dobey, you can try asking pitti I guess ;-) | 14:43 |
| dobey | seb128: anyway, it's approved, so feel free to silo those two changes | 14:44 |
| seb128 | dobey, ubuntuone-client-data is landing through CI train? | 14:44 |
| bfiller | jibel: server side changes need to be made for that bug to get fixed, jgdx is preparing the system-settings changes but not sure who is doing the server work, sil2100 or barry is that on your plate? https://launchpad.net/bugs/1475568 | 14:45 |
| dobey | yes | 14:45 |
| ubot5` | Ubuntu bug 1475568 in ubuntu-system-settings (Ubuntu) "Use OTA terminology in system settings" [Undecided,In progress] | 14:45 |
| dobey | seb128: it's on the phone | 14:45 |
| seb128 | dobey, I'm going to do a landing for wily only, is that ok? or do you want dual landing? | 14:45 |
| dobey | seb128: wily only sounds fine | 14:46 |
| dobey | if sil2100 did a manual upload though, i guess i might have to manually fix something too | 14:46 |
| sil2100 | I don't have permissions over this package, I just made a debdiff | 14:47 |
| dobey | sil2100: oh, so an upload wasn't made into the archive yet? | 14:49 |
| sil2100 | No, it's a main package, I'm only a MOTU ;) | 14:49 |
| dobey | oh ok :) | 14:49 |
| barry | bfiller: the server work is not on my plate. not sure if sil2100 is planning on tackling it. if he does i will be happy to review a merge | 15:02 |
| bfiller | barry: ok thanks | 15:02 |
| sil2100 | barry: what server work needs to be done? :) | 15:02 |
| * sil2100 is all ears | 15:02 | |
| barry | sil2100: LP: #1475568 | 15:02 |
| ubot5` | Launchpad bug 1475568 in ubuntu-system-settings (Ubuntu) "Use OTA terminology in system settings" [Undecided,In progress] https://launchpad.net/bugs/1475568 | 15:02 |
| sil2100 | barry: oh, I thought the solution was on the client side | 15:03 |
| * sil2100 dives into that | 15:03 | |
| barry | sil2100: i think the client has all the moving pieces it needs to eventually provide the information over its .Information() api. the information has to get into one of the ini files though, so that requires a server change. imho of course, and happy to discuss | 15:04 |
| sil2100 | barry: you want the OTA numbering to be hosted on the s-i server side? Like, attached to each image .json config file? | 15:04 |
| barry | sil2100: that's what i believe the OP wants | 15:05 |
| sil2100 | hm, ok, we could do that, we could include a notion of image tags for instance | 15:05 |
| barry | sil2100: well, the OP wants the data. i am opposed to the client downloading that from some site other than system-image.ubuntu.com. so to me it makes the most sense to have it included in the version_details string that the server already writes to the .ini files in the new images | 15:05 |
| sil2100 | Then it wouldn't be touch specific as anyone could use it then | 15:06 |
| barry | sil2100: so the question then is, where does the mapping between images and "OTA numbers" come from? istm that makese sense to have it as a mapping on the server side | 15:06 |
| barry | sil2100: yep | 15:06 |
| sil2100 | barry: those come from manager decision, it can't be something that's stored on the rootfs | 15:07 |
| sil2100 | Since we can never know during build time what OTA number it gets | 15:07 |
| barry | sil2100: hmm. that's a decision made after the image is published? | 15:07 |
| sil2100 | It's something that we need to be able to tag after the image is built and gets copied around, also needs to be per-channel | 15:07 |
| sil2100 | Yes | 15:07 |
| barry | okay, that complicates things then ;/ | 15:08 |
| sil2100 | Since we can have multiple candidates built and only like the 3rd or 4th can be the real thing | 15:08 |
| sil2100 | That's why I temporarily made a mapping file and thought that the client might need to fetch it on update download | 15:09 |
| rvr | bzoltan_: Silo 14 waiting for automated test results. | 15:09 |
| sil2100 | We could add it to what s-i server exports, but we would still need the client to acknowledge it and somehow parse it | 15:09 |
| barry | sil2100: what about putting it in the index.json file? | 15:09 |
| barry | sil2100: i have another thought on how that could work, but it won't work for si 2.5, only si 3.0 | 15:10 |
| barry | that idea is: when the manager decides which image will be which ota#, another ini file is created and added to the image's files. that would set an override of the version_details in say 03_ota.ini and then everything would just work | 15:11 |
| sil2100 | barry: yeah, as I said, but we'll need the client to somehow fetch it | 15:11 |
| barry | i.e. the files list in the index.json would grow another .tar.xz{,.asc} | 15:11 |
| sil2100 | barry: yeah, we could have that, and as I said above we could do it as a 'tag' mechanism, allowing images in channels getting tagged | 15:12 |
| sil2100 | barry: still! You would need to add something to s-i client to do that work on the image ;) | 15:12 |
| sil2100 | barry: I can work on the server side parts if you can review those afterwards | 15:14 |
| barry | sil2100: for sure, but i want to get the design right first. | 15:14 |
| barry | sil2100: the other option is to use the image description, or add another key to the index.json which would be the ota# | 15:15 |
| barry | those would require client work to expose, but no new machinery | 15:15 |
| sil2100 | barry: image description? | 15:15 |
| sil2100 | barry: we have something like that? | 15:15 |
| barry | sil2100: e.g. http://system-image.ubuntu.com/ubuntu-touch/rc/bq-aquaris.en/krillin/index.json | 15:16 |
| sil2100 | Ah, in the index | 15:16 |
| sil2100 | hmm, right, never noticed that | 15:16 |
| sil2100 | barry: isn't the description field just a mirror of version_detail ? | 15:16 |
| barry | sil2100: let me do a little research to see if another key in the index.json would work. can you think about how the index.json would get regen'd when an ota# decision was made? | 15:17 |
| barry | sil2100: it was originally supposed to be human readable, and i18n'd but that never happened | 15:17 |
| barry | there's even a long-deferred bug about it | 15:17 |
| sil2100 | barry: oh, nice | 15:17 |
| barry | sil2100: there's a version_detail key in there too, but the client doesn't actually use that one. it uses the one in the .ini file | 15:19 |
| barry | "use" == .Information() | 15:19 |
| bzoltan_ | rvr: cool... soon sharing | 15:20 |
| sil2100 | barry: ok, anyway I think either using the description field of another field to index.json could work - this could be simply generated on the s-i server by another small bin/ script there, something like with the phased-percentages | 15:20 |
| mterry | cyphermox, you never landed silo 57? | 15:20 |
| sil2100 | I'd have to check the code to see that in details | 15:20 |
| sil2100 | (in a meeting right now) | 15:20 |
| cyphermox | mterry: going to do it... | 15:21 |
| mterry | cyphermox, prove it | 15:21 |
| mterry | :) | 15:21 |
| mterry | cyphermox, no worries, just refreshed the tab to make sure I hadn't forgotten anything | 15:21 |
| barry | sil2100: ah, but the downside of doing it in the index.json file is that we actually have to calculate a winning upgrade path to get that information. you won't be able to know the ota# from information only on the device. unless we cache that if we find it. | 15:21 |
| barry | sil2100: but it might be worse. what if the ota# is assigned after the image is published and devices upgrade to it? | 15:22 |
| barry | the device will never know | 15:22 |
| sil2100 | barry: yeah... but this could be done during image copy even | 15:22 |
| barry | sil2100: let me think a bit more and ping me when you're done with your meeting | 15:24 |
| sil2100 | barry: like, you could do copy-image and give the tag there, since the decision happens when copying to stable - for all the other non-stable cases, maybe we could make u-s-s parse it from remote when user is online | 15:25 |
| sil2100 | Let me get back to you a bit later :) | 15:25 |
| barry | sil2100: cool | 15:26 |
| barry | sil2100, bfiller, jibel i added a comment with a bunch of questions to LP: #1475568 | 15:35 |
| ubot5` | Launchpad bug 1475568 in ubuntu-system-settings (Ubuntu) "Use OTA terminology in system settings" [Undecided,In progress] https://launchpad.net/bugs/1475568 | 15:36 |
| sil2100 | barry: let me follow up on that | 15:38 |
| sil2100 | brb | 15:38 |
| fginther | nerochiaro, I've had a look at the mako autopilot runs for https://code.launchpad.net/~uriboni/webbrowser-app/topsite-previews/+merge/269771 and other webbrowser-app MPs. In the past 2 days, there have been 6 other autopilot runs, all with 0 or 1 test failures. The high number of webbrowser_app.tests failures have only been seen with this MP. Have you been able to reproduce the test locally? | 15:39 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| nerochiaro | fginther: not with the full environment setup that you suggested. haven't had time for that yet, sorry | 15:48 |
| fginther | nerochiaro, ok, let us know if you have any questions regarding that setup. | 15:49 |
| dbarth | jibel: do i need to do anything for silo 16 to go into ota-7? | 15:51 |
| dbarth | btw | 15:51 |
| nerochiaro | fginther: i will try to get it done tomorrow | 15:52 |
| bzoltan_ | sil2100: how much time do I have to land the silo14 UITK? | 15:57 |
| bzoltan_ | sil2100: for OTA7 | 15:57 |
| jibel | cyphermox, what is the ETA for a vivid silo for the watchdog? | 16:22 |
| cyphermox | jibel: someone should request one, and then we do the shipping | 16:26 |
| cyphermox | jibel: preferably somebody other than me, I've got plenty to do already. I can still do the upload to the silo, would just rather not drive the landing | 16:26 |
| jibel | sil2100, ^ who can do it? | 16:27 |
| pat__ | alecu, can you get a vivid silo | 16:27 |
| === pat__ is now known as pmcgowan | ||
| jibel | thanks pat__ | 16:27 |
| alecu | pmcgowan: sure, I'll ask dobey to handle that landing | 16:28 |
| dobey | what now? | 16:30 |
| dobey | oh | 16:30 |
| dobey | uhm | 16:30 |
| dobey | cyphermox: can you just upload the fix for wily straight to the wily archive then? | 16:30 |
| cyphermox | I suppose you mean https://launchpad.net/ubuntu/+source/upstart-watchdog/0.4? | 16:31 |
| dobey | cyphermox: ah ok. i didn't realize you'd got into wily already | 16:39 |
| sil2100 | jibel: what is it about? | 16:40 |
| jibel | sil2100, it's okay, it was about the watchdog fix in vivid | 16:41 |
| dbarth | sorry again, do i need to publish silo 16 with oxide, or you guys prefer to control the process of injecting into the image? | 16:43 |
| dobey | sil2100: i guess you can just copy upstart-watchdog from wily (including binaries) into https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-059 ? | 16:44 |
| bzoltan_ | pmcgowan: what time the ota7 gate is closing? | 16:52 |
| pmcgowan | bzoltan_, soon, tonight | 16:54 |
| bzoltan_ | pmcgowan: OK | 16:54 |
| dobey | sil2100: oh, nevermind, i managed to do it :) | 16:55 |
| dobey | jibel: there, ready for qa now :) | 16:56 |
| jibel | dobey, thanks! | 16:56 |
| === alan_g is now known as alan_g|EOD | ||
| anpok | cihelp: any news on the krillin builders? | 17:12 |
| anpok | in mir-ci | 17:13 |
| anpok | .. sorry test runners | 17:13 |
| anpok | according to the scripts krillin-08 tried to send an email to chris.gagnon@canonical.com | 17:13 |
| psivaa | anpok: right, but that wasn't the reason for the failures | 17:14 |
| anpok | ok | 17:14 |
| anpok | .. this time the failure looked different than this morning.. http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-touch/6917/console | 17:14 |
| psivaa | anpok: yea, that's what confusing. | 17:14 |
| psivaa | anpok: first it looked like it failed to add overlay ppa in a couple of runs, but our test runs were successful on that | 17:15 |
| psivaa | anpok: now it's a different failure. i'd need to take a look | 17:16 |
| anpok | ah it failed to pull the result logs | 17:17 |
| psivaa | anpok: '/bin/bash: line 1: 6436 Segmentation fault mir_demo_server --test-client /usr/bin/mir_demo_client_fingerpaint | 17:29 |
| psivaa | + mir_rc=-1' | 17:29 |
| psivaa | does that look troubling? | 17:29 |
| anpok | psivaa: yes! | 17:30 |
| psivaa | anpok: ack, i'll leave that to you then? | 17:30 |
| psivaa | :) | 17:30 |
| anpok | hm hm i just changed a comment | 17:31 |
| psivaa | anpok: the issue only happens on krillin. | 17:32 |
| pmcgowan | did silos 16 and 59 get published? | 17:49 |
| pmcgowan | oh browser did | 17:49 |
| pmcgowan | trainguards silo 16? | 17:50 |
| sil2100 | pmcgowan: I know mterry had some doubts about that one, I wanted Mirv to comment... dbarth are you still around? | 17:51 |
| sil2100 | And I have doubts about that too | 17:51 |
| sil2100 | Since it's targetting the main archive, and the version number has no ~overlay tag | 17:51 |
| sil2100 | dbarth: ping | 17:51 |
| pmcgowan | sil2100, can we fix it to target the overlay? | 17:53 |
| pmcgowan | or does it go into updates | 17:53 |
| sil2100 | pmcgowan: we can, but if it goes to the overlay, it would need either a version change or at least a guarantee that no one releases the same version number to updates | 17:54 |
| sil2100 | I would like someone to comment first | 17:54 |
| sil2100 | Since maybe it was supposed to be an SRU..? | 17:54 |
| pmcgowan | sil2100, 1.9.3 is in the overlay so I assume thats where this should go | 17:56 |
| pmcgowan | oSoMoN, around? | 17:56 |
| oSoMoN | pmcgowan, yes | 17:56 |
| pmcgowan | silo 16 is not targeted for the overlay | 17:56 |
| pmcgowan | so it didnt land yet | 17:57 |
| sil2100 | I re-targetted it now | 17:57 |
| pmcgowan | oSoMoN, want to make sure we are doing it right | 17:57 |
| sil2100 | mterry, cyphermox: can one of you two land silo 16 maybe? | 17:57 |
| oSoMoN | pmcgowan, it should go to the overlay indeed | 17:57 |
| pmcgowan | it wants an overlay version? | 17:57 |
| mterry | sil2100, I can land if you're happy with target and version | 17:58 |
| pmcgowan | oSoMoN, is the version string ok as is? | 17:58 |
| sil2100 | oSoMoN: any reason why the version is not for overlay? | 17:58 |
| robru | sil2100: silo 16's lack of diff terrified me but apparently they silo had the vivid version so there's really no diff. That's why the version had no overlay tag because it looks like a direct copy from vivid | 17:58 |
| oSoMoN | sil2100, not that I know of, please note that oxide 1.9.5-0ubuntu0.15.04.1 is already in vivid-updates, will that conflict if the same version gets pushed to the overlay? | 17:59 |
| sil2100 | robru: still it needs a version change, as otherwise we have 2 binaries with the same version but different contents | 17:59 |
| sil2100 | Although for the overlay it *should* be ok | 17:59 |
| robru | sil2100: the contents are the same | 17:59 |
| pmcgowan | oSoMoN, sil2100 if its in vivid updates then we already get it right? | 17:59 |
| sil2100 | robru: source contents, yes, binary contents - no, different dependencies | 17:59 |
| oSoMoN | pmcgowan, no, the overlay PPA has priority | 18:00 |
| robru | Bah | 18:00 |
| sil2100 | hm | 18:00 |
| sil2100 | Oh, wait | 18:00 |
| pmcgowan | I mean the build already plls from vivid updates | 18:00 |
| pmcgowan | so do we need it in the overlay ? | 18:00 |
| sil2100 | Well, anyway, it's good as it is | 18:00 |
| sil2100 | mterry: can you press the publish buttonz? | 18:00 |
| pmcgowan | sil2100, ^^ | 18:00 |
| oSoMoN | pmcgowan, yes, but 1.9.3 is in the overlay so it’s going to take precedence over 1.9.5 in the archive, as the PPA has a higher score | 18:01 |
| sil2100 | pmcgowan: yeah, we need it in overlay | 18:01 |
| sil2100 | pmcgowan: due to pin priorities | 18:01 |
| pmcgowan | oh, hrm | 18:01 |
| sil2100 | But it's good | 18:01 |
| pmcgowan | ok | 18:01 |
| oSoMoN | sil2100, so the fact that we don’t have an ~overlay suffix in the version is not going to cause conflicts? | 18:02 |
| sil2100 | oSoMoN: no, in this case we should be ok | 18:02 |
| sil2100 | I just double checked | 18:02 |
| oSoMoN | ok | 18:03 |
| mterry | sil2100, oSoMoN, pmcgowan: no... the versioning for oxide-qt is all messed up. silo 16 and vivid-updates have 1.9.5, but wily only has 1.9.1 | 18:05 |
| mterry | And silo 16 has the same version as vivid-updates... | 18:05 |
| oSoMoN | mterry, 1.9.5 will go to wily-updates as soon as it opens up | 18:06 |
| oSoMoN | but the updates pocket is not open yet as wily hasn’t been released | 18:07 |
| mterry | oSoMoN, should it be a dual landing then? so we don't forget about it | 18:09 |
| pmcgowan | sil2100, do we have the wily overlay yet? | 18:09 |
| robru | mterry: dual silos don't support manual packages, only MPs | 18:09 |
| robru | pmcgowan: yes | 18:09 |
| pmcgowan | can't we land it there? | 18:09 |
| robru | oSoMoN: wily packages in the overlay will be copied to X, not wily-updates | 18:09 |
| robru | pmcgowan: yes but somebody would have to prepare that package manually | 18:10 |
| oSoMoN | mterry, well we could add a wily build to the silo, but at this stage I think what really matters is getting 1.9.5 in the vivid build in time for OTA7, wily is secondary | 18:10 |
| mterry | oSoMoN, this is how we forget about packages and get regressions later :) | 18:10 |
| mterry | oSoMoN, I can publish | 18:10 |
| mterry | oSoMoN, but it's not clear to me that we have a way to not forget to update wily later | 18:11 |
| oSoMoN | mterry, I could promise we won’t forget about it, but you’d have to take my word for it :) and the release of 1.10 is just around the corner, so 1.9.5 will be short-lived anyway | 18:11 |
| mterry | I thought our dual landing in the PPA was to not forget things | 18:11 |
| mterry | oSoMoN, right but we had a system for it... the dual landings | 18:12 |
| mterry | I mean that's for X, but same deal. Not forgetting | 18:12 |
| robru | mterry: dual landing is to enforce the process of releasing to wily before releasing to vivid. but when I implemented it I didn't anticipate manual packages so it only supports MPs for now | 18:13 |
| mterry | robru, right but we can have two silos :) | 18:14 |
| robru | mterry: sure can | 18:14 |
| mterry | robru, how we get there doesn't matter to me, I just want the update sitting in a wily pocket somewhere that we know about it | 18:14 |
| oSoMoN | mterry, I can request a silo for 1.9.5 in wily, would that make you feel better about publishing now? | 18:15 |
| robru | mterry: I agree, but seeing as the ota7 deadline is looming I think it's reasonable to just publish this vivid one now and get them to do wily immediately after | 18:15 |
| mterry | oSoMoN, that would be sufficient for me, yes | 18:16 |
| Mirv | sil2100: no I wasn't involved with the newest 1.9.5 landing. I guess whoever uploaded it was just not aware of the need to repackage with version number change to ~ | 18:16 |
| Mirv | I handled the previous one | 18:16 |
| mterry | oSoMoN, just knowing that you're making a silo is enough, but please do actually make it :) | 18:16 |
| oSoMoN | mterry, excellent, so I’ll do that right away | 18:16 |
| * mterry goes to publish | 18:17 | |
| oSoMoN | mterry, note that there is already a 1.9.5 build for wily in https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages, so I’ll simply request a source copy to the silo PPA from there | 18:17 |
| oSoMoN | mterry, got silo 57 for it | 18:20 |
| mterry | oSoMoN, so fast :) 16 is middle of publishing | 18:20 |
| oSoMoN | sil2100: can you please do a source copy of oxide-qt 1.9.5-0ubuntu1 from https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages (wily only) to silo 57, with an added ~overlay suffix if necessary? | 18:21 |
| jhodapp | robru, hey, can you please dput qtmultimedia from ppa:jhodapp/ubuntu/ppa to silo 55 | 18:25 |
| robru | jhodapp: sure one sec | 18:26 |
| jhodapp | thanks | 18:26 |
| robru | jhodapp: ok done. you can do a WATCH_ONLY build in the silo to get pinged when it finishes building | 18:27 |
| jhodapp | thanks man | 18:27 |
| robru | jhodapp: you're welcome | 18:30 |
| sil2100 | Mirv: no worries, that case was a binary copy anyway | 18:32 |
| * sil2100 ready with the source packages for the buteo revert but needs to jump out for a min | 18:32 | |
| bzoltan_ | sil2100: robru: jibel: I am happy with the silo14, let's push it once more. | 18:58 |
| jibel | rvr, ^ are you happy too ? | 18:59 |
| bzoltan_ | jibel: [18:09:25] <rvr> bzoltan_: Silo 14 waiting for automated test results. | 18:59 |
| bzoltan_ | jibel: rvr: please keep me posted about how the rest of the process goes... | 19:00 |
| jibel | bzoltan_, I believe he just wanted to check that the results of the automated tests are green | 19:02 |
| bzoltan_ | jibel: they were green on the last two attempts :) So I watch this landing with extra attention ... | 19:04 |
| bzoltan_ | jibel: i am not happy for the flakyness all over the AP tests | 19:05 |
| jibel | bzoltan_, I'll trust rvr's judgement. | 19:19 |
| bzoltan_ | jibel: me too :) | 19:20 |
| bzoltan_ | jibel: so let's unleash this beast | 19:20 |
| === fginther` is now known as fginther | ||
| charles | what now | 20:00 |
| * robru -> lunch | 20:39 | |
| oSoMoN | trainguards: can you please do a source copy of oxide-qt 1.9.5-0ubuntu1 from https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages (wily) to silo 57, with an added ~overlay suffix if necessary? | 20:43 |
| sil2100 | oSoMoN: I could still do it potentially | 20:43 |
| sil2100 | Ok, on it, will take a bit as unpacking/repacking the source takes some time on my PC | 20:43 |
| oSoMoN | sil2100, thanks, that’d be great! it’s not super urgent, but as mterry pointed out earlier, better to get it done now so that we don’t forget | 20:44 |
| sil2100 | Downloading the source now | 20:46 |
| sil2100 | bzoltan_, rvr, jibel: is silo 14 good to go? It's not switched as ready for publish | 21:08 |
| ssweeny | trainguards, I've taken over some of mandel's responsibilities at Canonical, so I'd like to get permissions setup for landing and reassign his silos to me if possible | 21:12 |
| robru | ssweeny: there's nothing really to "reassign", as anybody can edit any request at this point. The only thing to do is change his name for your name in the "landers" field so that you get IRC pings when things happen | 21:13 |
| robru | ssweeny: are you in the right LP teams to be able to use the train at all? | 21:13 |
| ssweeny | robru, great | 21:13 |
| ssweeny | robru, I've not used the train yet so I doubt it | 21:13 |
| robru | ssweeny: ok, what's your lp id? | 21:13 |
| ssweeny | robru, ssweeny | 21:13 |
| robru | ssweeny: ok I'll add you | 21:13 |
| ssweeny | robru, great, thanks! | 21:14 |
| robru | ssweeny: ok, if you go to https://requests.ci-train.ubuntu.com/#/user/mandel and log in with SSO you should be able to edit mandel's requests and put your name in | 21:14 |
| robru | ssweeny: and the documentation for using the train is here: https://wiki.ubuntu.com/citrain/LandingProcess but it's probably difficult to read, feel free to ask if you're unsure about anything | 21:15 |
| ssweeny | robru, perfect. Looks like it works | 21:16 |
| ssweeny | thanks again | 21:16 |
| ssweeny | I'm sure I'll be bugging you soon :) | 21:16 |
| robru | ssweeny: you're welcome! | 21:17 |
| robru | ssweeny: oh man, https://requests.ci-train.ubuntu.com/#/ticket/70 this one is *super* old (the "original requestid" thing means it was migrated from the old system way back). if you could get that one moving that'd be super ;-) | 21:19 |
| ssweeny | robru, yeah, that's near the top of my list :) | 21:19 |
| robru | sweeet | 21:20 |
| === salem_ is now known as _salem | ||
| rvr | sil2100: I was waiting for bzoltan_'s automated test results for silo 14 | 22:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!