=== chihchun_afk is now known as chihchun [04:57] mandel: so doko reported the ciborium problem is about porting it to the next qml go version (this might be obvious to you, but not to me since I didn't understand the build failure..) [06:40] Mirv: sil2100 during your shift today can you find a core dev to ack 31? Happened right at my EOD and all US was gone by then. [06:55] robru: sure, thanks for the notice :) [06:56] sil2100: you're welcome! Goodnight [07:03] robru: yeah, I was thinking about that already [07:04] robru: goodnight [07:04] it's just that at early EU hours not too many core devs are around [07:05] sil2100: uh oh, possible complication. there's a vivid-proposed upload with same version number https://launchpad.net/ubuntu/+source/network-manager/0.9.10.0-4ubuntu15.2 [07:06] it does not affect the images immediately, especially as it has been in -proposed for a month already, so we can publish the current package to overlay [07:06] it has failed SRU verification but still these cases might bite us at some point === chunsang is now known as chunsang-away [07:23] Mirv: yeah, I think in this case we might need to start using some overlay-specific versioning scheme [07:23] Mirv: otherwise there's always a way it would bite us [08:13] sil2100, hey, can you reconfig silo4 please? I've added a tiny branch for the address book app to not allow rotating [08:13] mzanetti: on it :) [08:13] The silo is dual-landing, right? [08:14] yes [08:14] all the dependencies should be ok now [08:14] I *really* hope [08:15] I think everything should be in place indeed [08:17] sil2100, I only need to build address-book-app right, no need to rebuild all the others because of the reconfig if they weren't dirty? [08:17] mzanetti: exactly [08:17] ack. doing [08:18] let's get this beast landed today! [08:18] mzanetti: if the others were clean before that is! i.e. nothing made the silo 'dirty' [08:18] yep [08:18] the last rebuild was yesterday night after the apps landed, nothing else landed [08:30] Mirv, sorry, I'm out today, I'm full of drugs after my wisdom teeth were removed [08:42] mandel: ok! [10:15] sil2100, is it normal that the silo build log says "Dependency wait" while the ppa says "failure because of the dep wait"? [10:15] https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/197/console [10:15] https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+packages [10:15] mzanetti: looking [10:16] mzanetti: eh... looks like vivid is missing another thing [10:16] hmmm [10:16] sil2100, libunity-api-dev, right? [10:16] But that's REALLY strand [10:16] mzanetti: It's normal that that shows up with an X icon; whether it's a failure or not depends on your point of view [10:16] *strange [10:16] that's in the silo too [10:17] mzanetti: Not Only as of recently [10:17] mzanetti: let me retry, maybe it didn't pick up the dep appearing [10:17] I think the armhf build just gave up too quickly because it needed to build unity-api [10:17] It hasn't given up [10:17] dep-waits are auto-retried when the dep is available [10:18] But out of cron, so there's a delay [10:18] Yeah, sometimes it can take a while, so I usually poke it manually then [10:18] oh... now it builds [10:18] It would have sorted itself out, but retrying manually is fine [10:18] I poked it manually, should be fine now [10:18] ah ok... yeah, just the red cross confused me [10:19] No worries, it's a normal thing, I was worried we didn't have the right libunity-api-dev version in vivid [10:19] sil2100, same for unity8 armhf btw... if you can poke that too, otherwise I'll just wait, no prob [10:19] mzanetti: done, let's say how it goes [10:19] ta [10:27] sil2100, erm... which version do I pick for the gles-sync in a dual landing silo? [10:27] mzanetti: the upstream one I would suppose, why do you ask? [10:28] because there are two, 14.10 and 15.04 [10:30] erm. 15.04 and 15.10 [10:31] Yeah, but just always target the upstream versions, i.e. if there's a version of 1.2+15.10.20150606-0ubuntu1, simply be sure to target the main upstream part, 1.2 [10:32] This means you'll have to bump the upstream version number whenever the API changes or there's something distinctive [10:33] ah ok. thanks [10:33] sil2100, what's the status of the ota-4 build? [10:34] ogra_: ping :) [10:34] john-mcaleely: we need to publish silo 31, on it now [10:34] so, QA is all done? [10:35] john-mcaleely: for silo 31 yes, then we copy it to snapshot, build an image, QA do some checks and I suppose we're good to go [10:35] ogra_: could you take a look at https://ci-train.ubuntu.com/job/ubuntu-landing-031-2-publish/lastSuccessfulBuild/artifact/network-manager_packaging_changes.diff ? [10:35] ah, yes, makes sense [10:35] good to know, thanks [10:36] sil2100, ACK [10:36] \o/ [10:36] THanks [10:40] mandel: holy ... I may have accidentally been able to port ciborium to go qml.v1 .. https://code.launchpad.net/~timo-jyrinki/ciborium/port_to_qml.v1/+merge/261707 could you take a look when you are back in ranks? [10:44] if it's anywhere near what should have been done, I will be surprised. I was also surprised when bzr bd ran, unit tests passed and package was created [10:44] * Mirv is very trusting in his Go skills [10:58] jibel: do you know if Pat wanted anything else in OTA-4? [10:58] Or is it ok for me to start doing magic tricks to build an image? [11:21] ogra_: I'll be doing some build related magic for OTA-4 now [11:21] fine [11:22] ogra_, slangasek: just so you're aware... what I did is, disabled the importer, reconfigured the 14.09-factory-proposed channel to look for the vivid cdimage builds (and use tarballs from the respectful rc-proposed channels) and disabled the rootfs part of the rc-proposed/ubuntu channel [11:22] I did that for a one-time run [11:22] This way, once I build now an image from the snapshot PPA, the rootfs will only be picked up by 14.09-factory-proposed [11:22] We will use it as the final OTA-4 candidate [11:23] Once it's built, I'll run the importer, then modify the config back to the previous state and build a new rc-proposed image [11:23] I did all this mambo-jumbo so that we don't have a strange image in rc-proposed and that we can have the snapshotted one only in 14.09-factory-proposed [11:24] ogra_: sounds fine? (and overly unnecessarily complicated?) [11:25] sinds fine, yes [11:25] *sounds [11:25] not sure it is overly compilcated :) [11:25] Ok then, double-checking everything and running the build [11:35] Build running === _salem is now known as salem_ [11:41] popey, are you not allowed to add lines to the spreadsheet? [11:43] not last time i tried jibel [11:43] jibel: I usually help out and fill in the info as needed as well [11:43] I think popey has access [11:44] \o/ [11:44] now, what's the url :) [11:44] popey: https://wiki.ubuntu.com/citrain has always the latest ;) [11:44] thanks! [11:45] popey, add requests for click apps to the 'Tarballs and Clicks' tab [11:45] sweet, will do that from now on thanks! [11:45] I added this one entry already :) [11:46] Normally just copy-paste the info to the right places as what you sent out by e-mail and poke us, we'll approve it as a landing [11:46] k [11:50] pmcgowan: hey! I'm building the final OTA-4 candidate [11:50] pmcgowan: I set 14.09-factory-proposed as the target for this image, it's being built from the stable-snapshot PPA - we have the 2G->3G fix in it [11:51] I'll take a bit to finish, I'll be jumping out for lunch as well but I suppose it'll finish around when I'm back === MacSlow is now known as MacSlow|lunch [11:52] jibel: I'm assuming once sil2100 has finished this we need to cover the ota tests right? [11:53] davmor2: I suppose the OTA tests will have to be done once we copy it to rc [11:53] I would like you guys to check if all is ok in the image before that happens ;) Maybe a quick look if it boots or something [11:53] * sil2100 lunch [11:53] sil2100: yeah I think that is plan [11:53] davmor2, as sil2100 once it's in RC [11:53] +said [11:54] davmor2, but first check that languages are ok, MMS is default, 2G->3G is fixed on the new build then promote to rc [11:55] s/MMS is default/MMS group chat is not default/ [11:55] jibel: indeed [11:59] sil2100, I'm afraid I need your help again: https://launchpadlibrarian.net/208833921/buildlog_ubuntu-vivid-armhf.unity8_8.10%2B15.04.20150611.1-0ubuntu1_BUILDING.txt.gz [11:59] looking at my vivid+overlay powered device, all seems to be fine [12:00] not sure why the silo won't install it === alan_g is now known as alan_g|lunch [12:07] sil2100, awesome, I see the MMS receive fix queued up, would have been nice to get as well but need to ship sometime === MacSlow|lunch is now known as MacSlow [13:03] sil2100: added calendar to spreadsheet \o/ [13:04] is anyone familiar with the boottest jobs, specifically for lxc-android-config? [13:05] it's failing to install the deb, which can't work since that package has to be installed from recovery [13:07] cihelp: ^^ [13:07] actually, fginther i see you've kicked a few of these jobs, any clue how to make them pass? [13:08] kenvandine, looking [13:09] fginther, the deb has to be installed in recovery, or at least after doing some manual unmounts... so the job would require some special handling [13:09] jibel, hello! what's the situation with silos 29, 40, 13, any chance to land that stuff this week? [13:12] kenvandine, ah, so this simple can't be handled by the current test. We should be able to just ask one of the archive-admins to pass it [13:12] I can't do it directly [13:13] Laney, ^^ can you do that? push lxc-android-config through? [13:13] Laney, from proposed to release that is [13:13] fginther, can't we drop the boottest for it? [13:16] kenvandine, There's a dependency between the proposed migration service and boottest, I can't just tell it not to run the test, but I may be able to fake a response [13:20] kenvandine, ok, lets see if this works [13:31] kenvandine, that did it [13:31] woot [13:31] thanks! [13:31] fginther, so future jobs won't need massaging? [13:32] not that i hope to land lxc-android-config... it isn't exactly fun :) [13:32] kenvandine, no, I had to just manually create a passing result for this. Getting it to automatically pass in the future will take more work [13:32] ok [13:33] fginther, it's had passing runs before though [13:33] which is just odd... [13:33] unless those were faked :) [13:33] dunno [13:33] pstolowski, rvr is verifying 29, 40 is next in the queue, and if you can find someone to review an approve the MR on 13 it'll move to ready for testing. [13:34] s/an/and/ [13:35] kenvandine, there was a regression in the boottest that was causing packages to not actually be installed for a while [13:35] jibel, ok, thanks. 13' MR was approved yesterday [13:35] kenvandine, which would explain those passes [13:35] ah === chihchun is now known as chihchun_afk [14:06] sil2100: just checking, silo 4 having trouble on unity8 due to libconnectivity-qt1, any update on that one ? [14:06] i was disconnected for a bit [14:08] kgunn: hey, didn't look at it, I was out for lunch when I got the ping and missed it sadly, let me look [14:16] sil2100: thanks for the info. I don't think you actually want to disable *just* the Ubuntu part on rc-proposed however; I think you want to mark rc-proposed 'manual' so that it doesn't import some crazy set of files that excludes the ubuntu tarball entirely [14:17] slangasek: uh, ok, too late, but I think everything was fine I suppose... [14:18] slangasek: I remember I once asked stgraber and he mentioned that if there is no section (for instance, no ubuntu_file), nothing will be imported at for that [14:18] kenvandine: fginther: Can you fix boottest to skip this package if it's never going to work? [14:18] And since there was no change in tarballs, I thought no new image with junk would appear [14:19] sil2100: in fact, if you look at the rc-proposed channel, you'll see that there is now an image on the channel with no 'ubuntu' part [14:19] Ouch [14:19] sil2100: I've marked the channel manual for the moment, and we'll need to delete the image to clean it up [14:19] Yeah, once we actually get a real image to this channel [14:19] sil2100: even if stgraber said this was supposed to work, it's a weird way to do it, as opposed to just disabling imports for the channel :) [14:19] sil2100: no, immediately; I'll work on it now [14:20] Anyway, we seem to have the snapshot image in 14.09-factory-proposed now, just confirming it has the right parts [14:22] Ok, image looks fine, device and custom bits are correct + the ubuntu parts correct [14:23] slangasek: I guess we can revert the setting now, I would build a standard overlay image though as I don't want the rc-proposed channel to pull in the snapshot release [14:23] Not a big deal, but I didn't want them to have strange images (but they already did get that, eh) [14:24] slangasek: next time I'll make it manual, just this seemed quicker to me ;) [14:24] Didn't expect it to fetch anything [14:24] sil2100: 'manual' is a one-line change ;) [14:24] slangasek: well, I wasn't sure it didn't require removing all the other lines [14:24] I feel bad deleting so many good lines [14:24] ;) [14:25] broken images removed from all devices, rerunning importer [14:26] slangasek: thanks, sorry about that, as I said I didn't expect anything to be pulled in since why would it [14:30] fginther, couldn't you just return success if the package is lxc-android-config? [14:30] hopefully it's truely a one-off case [14:30] we don't want to skip it for most packages [14:31] kenvandine, the test has to also determine the version of the package to promote, thats really the only thing that's complicated here [14:31] Laney, ^^ [14:31] kenvandine, Laney, but yeah, whitelisting this package is probably the right approach here [14:31] I think so [14:31] do you need a bug or anything to track the work to do it? [14:33] Laney, sure, you can file them here: https://launchpad.net/ubuntu-touch-boottest [14:35] done, thanks [14:36] kgunn: still looking into that, will have to experiment in a chroot [14:37] mzanetti: ^ [14:38] full shell rotation==snake bit [14:38] as soon as that's landed I'll probably be drunk for a day or two [14:39] kgunn, mzanetti: anyway, not sure if it's related as otherwise this would lead to all archs to fail, but there's a somewhat of a loop-dependency in connectivity-api right now... [14:39] I mean, in unity8 basically, but due to connectivity-api [14:40] unity8 depends on libconnectivity-qt1, that depends on indicator-network and that depends on unity8 o_O [14:40] That's not healthy at all [14:40] uh oh [14:40] I don't think that has changed in a long time tho... [14:41] It changed in the latest connectivity-api [14:41] oh, I see [14:41] I checked and the vivid version does not depend on indicator-network [14:41] The one in the overlay that's shipped with indicator-network starts having that dep ;/ [14:41] That smells like serious trouble to me [14:42] Need to check if that can be the cause here as well [14:42] Wellark, ^^ [14:44] Damn, this is really bad right now [14:45] When I check the amd64 unity8 build logs it's actually INSTALLING UNITY8 as a build dep during building [14:45] :O [14:50] Wellark: ping [14:58] sil2100: just wondering, how'd this only happen in vivid+overlay? is connectivity-api diverged ? [14:59] Not sure, still checking if it's related, maybe it's just a race that causes it to fail - all in all, this is NOT the correct behavior anyway and will lead to problems sooner or later [14:59] Since you can't depend on unity8 when building unity8 [14:59] But I'm still looking, now prepared the chroot [14:59] Well [14:59] You can [15:00] It's not necessarily a good idea, but it's not fatal [15:00] sil2100: should the importer be re-enabled now? [15:00] That sort of thing is more to be expected from toolchain-type stuff, though [15:01] slangasek: I was thinking - is rc-proposed still manual? Since I woudln't want the snapshot image to generate a new image [15:01] slangasek: maybe we should build a new overlay-based rootfs? [15:05] sil2100, kgunn: I guess this is the reason why it only fails on vivid: https://launchpad.net/ubuntu/+source/indicator-network/0.5.1+15.10.20150604-0ubuntu1 [15:06] hm, still, a bit strange it would break like this [15:06] mzanetti, kgunn: I'll keep investigating, but we have a team meeting now :) [15:06] So much slooower than usual [15:06] But my chroot will certainly make thins easier [15:11] Ok, getting somewhere [15:12] Found the root cause [15:15] this is ubuntu, we only have sudo causes === chihchun_afk is now known as chihchun [15:17] hey trainguards, are you guys still creating silos for oldies? like an rtm14-09 missing backport ? (see line 65) [15:18] davidbarth, what for ? [15:18] davidbarth: uh, no, rtm support was ripped out of the train [15:18] all users will be on vivid soon ... no need to care for 14.09 [15:19] sil2100, fix is in spreadsheet row 66 [15:19] mzanetti: anyway, the bug is oxide ;/ [15:19] wat? [15:19] I mean, not exactly, let me clear out everything in a minute [15:19] Too many stuff going on [15:20] sil2100, I found out that pete-woods dropped the dep to unity8 from indicator-network in wily, with the commit message describing this issue [15:20] so I backported that commit to their 15.04 branch [15:22] mzanetti: so, the problem is in qtdeclarative5-ubuntu-web-plugin which is one of the big chain dependencies [15:23] hm, no, wait [15:23] Oh [15:24] sil2100: when was the last time you assigned or reconfigured a silo today? it seems the spreadsheet has been updated to new spreadsheet API which breaks a lot of our code (in particular the menu for assigning and reconfiguring is gone). I'm not sure if a person did that or if google is just forcibly deprecating the old api. [15:24] robru: uh, I reconfigured one silo at least, it seemed to be ok [15:25] sil2100: yeah but how long ago? [15:25] robru: in the morning I think, so around 7 hours ago? [15:25] Damn, stupid google [15:26] sil2100: k, I don't know when this switch happened, but I just tried to assign a silo and google was like "welcome to the new google sheets! btw all your scripts are broken" [15:26] uuh [15:26] oh dear... [15:27] robru, close it and reopen [15:27] it happened to me earlier today [15:27] pstolowski: Approving silo 29 [15:27] robru, at least that worked for me [15:27] like 30m ago [15:29] kenvandine: oh weird, indeed reloading worked [15:29] robru, yeah... i freaked out about it earlier... spent a few minutes swearing about the damn spreadsheet [15:30] kenvandine: it's really pathetic. luckily the replacement is really close ;-) [15:30] robru, yeah yeah... heard that before :) [15:30] * kenvandine ducks [15:31] * kenvandine gets a red bull for robru, code faster! [15:31] kenvandine: the difference is, last time I said that i was waiting for another team that had other priorities. this time, I'm writing it myself and I have a working demo that i'm iterating on ;-) [15:32] mzanetti: ok it's actually a very absurd thing, I'm starting to think it was just some hiccup :| [15:32] rvr, great, thanks for the update! [15:49] sil2100: the rc-proposed channel is still manual, yes [15:50] sil2100: and if you're done with the snapshot build, yes we should probably kick off another overlay rootfs with the regular config - but since rc-proposed is still set to manual it should be ok to re-enable the importer [15:50] slangasek: ok, so we can re-enable the importer, disable the 14.09-factory-proposed and build a new rootfs [15:50] Right :) [15:50] * slangasek nods [15:51] Ok, on it [15:52] sil2100, so that branch I proposed, is that no good? [15:52] Building the rootfs [15:53] https://code.launchpad.net/~mzanetti/indicator-network/backport-dep-loop-fix/+merge/261742 [15:53] mzanetti: I'll check it in a moment, I'm still looking for the reason of the issues [15:54] mzanetti: it's strange as it almost looks as if it didn't see packages in -updates - if I enable updates in my chroot, everything works fine... but actually, let me try one more thing === alan_g|lunch is now known as alan_g [15:58] sil2100: we having a landing call today? [15:58] (just checking) [15:59] oh, thats what the harps in my pocket watend to tell me ! [16:00] popey: yeah === chihchun is now known as chihchun_afk [16:01] robru: ping pong [16:17] lol... "the harps in my pocket" [16:17] so true [16:21] mzanetti: this build failure is still a mystery for me, cannot reproduce the issue in a similarily configured chroot [16:22] sil2100, same here... can't repro on the phone with the same archive configuration [16:22] sil2100, anyhow, pete-woods seems to have broken it for wily [16:22] shouldn't we just land that backport to vivid? [16:22] by broken I mean "broken the dependency loop" [16:22] aka fixed it :D [16:24] Yeah, probably a good idea :) It *might* help, but... there's no guarantee [16:24] We'll assign a silo, we had spreadsheet issues [16:24] sil2100, any story on an ota-4 build? [16:25] Ah, forgot robru assigned it already [16:25] john-mcaleely: it's done, the build at least, now QA is making sure all is cool [16:25] Then we copy to RC [16:25] sil2100, aha. perfect [16:25] sil2100: mzanetti: yep silo 18 is ready to go [16:26] Good you reminded me, with all the things going on I almost forgot I need to fix up a generic image... [16:26] hmmm, problem is, we already have another one [16:26] Damn [16:26] thanks robru, thanks sil2100. Really appreciate your help [16:28] mzanetti: you're welcome [16:33] Ok, generic image stuffed in [16:33] That was so close... [16:34] mzanetti: so, since I'm currently out of ideas, let's try landing the change from silo 18 and see if that helps - if not, we'd have to re-check that ;/ [16:36] yep [16:36] building right now [16:38] sil2100, silo27 is ready for publishing [16:41] ogra_: hey! We'd need some packaging ACKs for really easy changes: [16:41] ogra_: https://ci-train.ubuntu.com/job/ubuntu-landing-029-2-publish/lastSuccessfulBuild/artifact/ubuntuone-credentials_packaging_changes.diff and https://ci-train.ubuntu.com/job/ubuntu-landing-029-2-publish/lastSuccessfulBuild/artifact/unity-scope-click_packaging_changes.diff [16:43] sil2100, ACK [16:43] ogra_: thanks! [16:43] :) [16:45] robru: ok, so I'm approving and publishing silo 11, but it seems the train invalidly built the package - it thought there was no previous version in wily and included all the history in the upload (and requested a packaging ACK saying it's a NEW package) [16:45] robru: while the actual change was just a small code change [16:45] robru: (see https://ci-train.ubuntu.com/job/ubuntu-landing-011-2-publish/56/ ) [16:46] robru: will you need the PPA contents for debugging or can I publish it? [16:46] (this is the actual change: https://launchpadlibrarian.net/208269342/nuntium_1.4%2B15.10.20150521-0ubuntu8_1.4%2B15.10.20150604-0ubuntu1.diff.gz ) [16:46] Ah, I see the reason for that [16:46] robru: actually, it seems the problem here was the version number in the latest package [16:47] sil2100: wait [16:47] robru: somehow 1.4+15.10.20150521-0ubuntu8 was not in trunk... [16:47] sil2100: do not publish [16:47] sil2100: the reason it thinks it's a new package is because dest is set as overlay ppa. [16:47] It got hm, overriden by 1.4+15.04.20150521-0ubuntu1, strange stuff [16:47] sil2100: not a train bug, silo is misconfigured. [16:47] Ah, uuuh! [16:47] sil2100: nuntium really isn't in overlay ppa [16:47] thanks sil2100 [16:47] Duh [16:48] robru: right, not for wily at leaset [16:48] sil2100: reconfigure for wily and watch only build,should fix it [16:48] *least [16:48] sil2100: I mean reconfigure without dest ppa set [16:48] Right [16:51] robru: ok, updated the MR, if you could later top-approve it it would be awesome [16:51] :) [16:51] Thanks for noticing the invalid target btw.! [16:52] sil2100: you're welcome === alan_g is now known as alan_g|EOD [17:05] boiko: you got silo 20, note telephony-service conflict in silo 43 [17:07] robru: publishing still broken... [17:07] robru: it would require a rebuild probably [17:07] robru: as it has the wrong information in the upload, but I suppose the package itself is good [17:08] sil2100: that's weird, before the content diff was null now it has something, which is expected. I'm not sure why the packging diff still thinks it's a new package [17:08] sil2100: I say just force publish it, should be fine [17:08] sil2100: the package is definitely fine, this is just an issue with train barfing on the diff [17:09] -nuntium (1.4+15.10.20150521-0ubuntu8) wily; urgency=medium [17:09] +nuntium (1.4+15.04.20150521-0ubuntu1) vivid; urgency=medium [17:09] This is a bit worrying but still [17:09] I guess it's ok to publish [17:09] I'll go on ahead since we need this package badly now [17:09] sil2100: https://ci-train.ubuntu.com/job/ubuntu-landing-011-2-publish/lastSuccessfulBuild/artifact/nuntium_content.diff/*view*/ what diff you looking at? package is still a wily package [17:10] oh, the previous release. weird. [17:11] sil2100: I blame trunk, check the diff on the MP: https://code.launchpad.net/~alfonsosanchezbeato/nuntium/fix-mms-rx/+merge/260678 it shows 521 as vivid. [17:11] hah, yeah... [17:43] pmcgowan: I know how much you love bugs - this is annoying https://bugs.launchpad.net/ubuntu/+source/qtcreator-plugin-ubuntu/+bug/1454210 [17:43] Launchpad bug 1454210 in qtcreator-plugin-ubuntu (Ubuntu) "accounts are lost each time the app is ran on the device" [High,New] [17:43] pmcgowan: if you're on vivid and you update an app which has an account plugin, the plugin is removed and re-added, losing settings [17:44] pmcgowan: will hit everyone once we OTA-4 [17:44] that is annoying [17:44] oh [17:44] popey, so its not a developer thing only? [17:44] nope [17:45] if a user updates an app which has an OA plugin inside (reminders/notes) it will hit them [17:45] mzanetti: right? ^ [17:45] popey, sounds like you need to uninstall [17:45] erm... it is a developer thing only [17:45] not update [17:45] mzanetti: how so? [17:46] because update doesn't remove it, only if the account is uninstalled [17:46] mzanetti: if I pkcon install-local a new reminders, it does it to me. [17:46] I have to re-auth each time [17:46] oh really [17:46] well, I only tried with qtcreator which does indeed a remove + install [17:46] maybe the wording of that bug doesn't cover my use case exactly [17:47] however, I don't think we're affected if an app is just updated in the store [17:47] how so? [17:47] at least I wouldn't have noticed it yet... we are releasing a reminders update now, are we? [17:47] I will watch out if it happens [17:47] soon [17:47] let me test on my device here [17:48] you dont think it happens from store, but does from pkcon? [17:48] can't see how [17:48] fair point [17:48] lemme confirm anyway [17:52] ok, so all works as expected on rtm... upgraded and didn't lose the account [17:52] * popey tries vivid [17:55] I only have this issue as of vivid [17:59] mzanetti: confirmed [17:59] popey, what is the situation then? [17:59] the act of installing a new version of reminders onto a system that has an online account setup will delete that online account entry [17:59] (on vivid) [18:00] popey, erm... does it affect us throught the store too? [18:00] I don't see how it wont [18:00] O_o [18:01] do you have an old package of reminders floating on your hard disk? could install it, set up the account and then upgrade from store [18:01] i can do that, yes [18:01] i can pluck any old version from jenkins. will do that now, to confirm [18:04] mzanetti: confirmed [18:05] :( [18:05] installed com.ubuntu.reminders_0.5.429_armhf.click, created evernote account, opened reminders, worked. upgrade to 434 (from store) and it disappears [18:06] * popey adds to the bug [18:15] mzanetti: updated bug [18:16] pmcgowan: so basically yes, on vivid, _any_ app update via the store, where the app has an online accounts plugin (reminders, untapped - dunno how many others? scopes?) the account will be deleted. [18:16] sh*t [18:16] popey, tagging it up [18:16] So only affects apps which have an online account component where the user has logged in. [18:16]