[04:57] <Mirv> 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] <robru> 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] <sil2100> robru: sure, thanks for the notice :)
[06:56] <robru> sil2100: you're welcome! Goodnight
[07:03] <Mirv> robru: yeah, I was thinking about that already
[07:04] <Mirv> robru: goodnight
[07:04] <Mirv> it's just that at early EU hours not too many core devs are around
[07:05] <Mirv> 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] <Mirv> 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] <Mirv> it has failed SRU verification but still these cases might bite us at some point
[07:23] <sil2100> Mirv: yeah, I think in this case we might need to start using some overlay-specific versioning scheme
[07:23] <sil2100> Mirv: otherwise there's always a way it would bite us
[08:13] <mzanetti> sil2100, hey, can you reconfig silo4 please? I've added a tiny branch for the address book app to not allow rotating
[08:13] <sil2100> mzanetti: on it :)
[08:13] <sil2100> The silo is dual-landing, right?
[08:14] <mzanetti> yes
[08:14] <mzanetti> all the dependencies should be ok now
[08:14] <mzanetti> I *really* hope
[08:15] <sil2100> I think everything should be in place indeed
[08:17] <mzanetti> 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] <sil2100> mzanetti: exactly
[08:17] <mzanetti> ack. doing
[08:18] <mzanetti> let's get this beast landed today!
[08:18] <sil2100> mzanetti: if the others were clean before that is! i.e. nothing made the silo 'dirty'
[08:18] <mzanetti> yep
[08:18] <mzanetti> the last rebuild was yesterday night after the apps landed, nothing else landed
[08:30] <mandel> Mirv, sorry, I'm out today, I'm full of drugs after my wisdom teeth were removed
[08:42] <Mirv> mandel: ok!
[10:15] <mzanetti> sil2100, is it normal that the silo build log says "Dependency wait" while the ppa says "failure because of the dep wait"?
[10:15] <mzanetti> https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/197/console
[10:15] <mzanetti> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+packages
[10:15] <sil2100> mzanetti: looking
[10:16] <sil2100> mzanetti: eh... looks like vivid is missing another thing
[10:16] <sil2100> hmmm
[10:16] <mzanetti> sil2100, libunity-api-dev, right?
[10:16] <sil2100> But that's REALLY strand
[10:16] <cjwatson> 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] <sil2100> *strange
[10:16] <mzanetti> that's in the silo too
[10:17] <cjwatson> mzanetti: Not Only as of recently
[10:17] <sil2100> mzanetti: let me retry, maybe it didn't pick up the dep appearing
[10:17] <mzanetti> I think the armhf build just gave up too quickly because it needed to build unity-api
[10:17] <cjwatson> It hasn't given up
[10:17] <cjwatson> dep-waits are auto-retried when the dep is available
[10:18] <cjwatson> But out of cron, so there's a delay
[10:18] <sil2100> Yeah, sometimes it can take a while, so I usually poke it manually then
[10:18] <mzanetti> oh... now it builds
[10:18] <cjwatson> It would have sorted itself out, but retrying manually is fine
[10:18] <sil2100> I poked it manually, should be fine now
[10:18] <mzanetti> ah ok... yeah, just the red cross confused me
[10:19] <sil2100> No worries, it's a normal thing, I was worried we didn't have the right libunity-api-dev version in vivid
[10:19] <mzanetti> sil2100, same for unity8 armhf btw... if you can poke that too, otherwise I'll just wait, no prob
[10:19] <sil2100> mzanetti: done, let's say how it goes
[10:19] <mzanetti> ta
[10:27] <mzanetti> sil2100, erm... which version do I pick for the gles-sync in a dual landing silo?
[10:27] <sil2100> mzanetti: the upstream one I would suppose, why do you ask?
[10:28] <mzanetti> because there are two, 14.10 and 15.04
[10:30] <mzanetti> erm. 15.04 and 15.10
[10:31] <sil2100> 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] <sil2100> This means you'll have to bump the upstream version number whenever the API changes or there's something distinctive
[10:33] <mzanetti> ah ok. thanks
[10:33] <john-mcaleely> sil2100, what's the status of the ota-4 build?
[10:34] <sil2100> ogra_: ping :)
[10:34] <sil2100> john-mcaleely: we need to publish silo 31, on it now
[10:34] <john-mcaleely> so, QA is all done?
[10:35] <sil2100> 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] <sil2100> 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] <john-mcaleely> ah, yes, makes sense
[10:35] <john-mcaleely> good to know, thanks
[10:36] <ogra_> sil2100, ACK
[10:36] <sil2100> \o/
[10:36] <sil2100> THanks
[10:40] <Mirv> 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] <Mirv> 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] <sil2100> jibel: do you know if Pat wanted anything else in OTA-4?
[10:58] <sil2100> Or is it ok for me to start doing magic tricks to build an image?
[11:21] <sil2100> ogra_: I'll be doing some build related magic for OTA-4 now
[11:21] <ogra_> fine
[11:22] <sil2100> 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] <sil2100> I did that for a one-time run
[11:22] <sil2100> 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] <sil2100> We will use it as the final OTA-4 candidate
[11:23] <sil2100> 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] <sil2100> 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] <sil2100> ogra_: sounds fine? (and overly unnecessarily complicated?)
[11:25] <ogra_> sinds fine, yes
[11:25] <ogra_> *sounds
[11:25] <ogra_> not sure it is overly compilcated :)
[11:25] <sil2100> Ok then, double-checking everything and running the build
[11:35] <sil2100> Build running
[11:41] <jibel> popey, are you not allowed to add lines to the spreadsheet?
[11:43] <popey> not last time i tried jibel
[11:43] <sil2100> jibel: I usually help out and fill in the info as needed as well
[11:43] <sil2100> I think popey has access
[11:44] <popey> \o/
[11:44] <popey> now, what's the url :)
[11:44] <sil2100> popey: https://wiki.ubuntu.com/citrain has always the latest ;)
[11:44] <popey> thanks!
[11:45] <jibel> popey, add requests for click apps to the 'Tarballs and Clicks' tab
[11:45] <popey> sweet, will do that from now on thanks!
[11:45] <sil2100> I added this one entry already :)
[11:46] <sil2100> 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] <popey> k
[11:50] <sil2100> pmcgowan: hey! I'm building the final OTA-4 candidate
[11:50] <sil2100> 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] <sil2100> 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
[11:52] <davmor2> jibel: I'm assuming once sil2100 has finished this we need to cover the ota tests right?
[11:53] <sil2100> davmor2: I suppose the OTA tests will have to be done once we copy it to rc
[11:53] <sil2100> 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] <davmor2> sil2100: yeah I think that is plan
[11:53] <jibel> davmor2, as sil2100 once it's in RC
[11:53] <jibel> +said
[11:54] <jibel> 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] <jibel> s/MMS is default/MMS group chat is not default/
[11:55] <davmor2> jibel: indeed
[11:59] <mzanetti> 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] <mzanetti> looking at my vivid+overlay powered device, all seems to be fine
[12:00] <mzanetti> not sure why the silo won't install it
[12:07] <pmcgowan> sil2100, awesome, I see the MMS receive fix queued up, would have been nice to get as well but need to ship sometime
[13:03] <popey> sil2100: added calendar to spreadsheet \o/
[13:04] <kenvandine> is anyone familiar with the boottest jobs, specifically for lxc-android-config?
[13:05] <kenvandine> it's failing to install the deb, which can't work since that package has to be installed from recovery
[13:07] <kenvandine> cihelp: ^^
[13:07] <kenvandine> actually, fginther i see you've kicked a few of these jobs, any clue how to make them pass?
[13:08] <fginther> kenvandine, looking
[13:09] <kenvandine> 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] <pstolowski> jibel, hello! what's the situation with silos 29, 40, 13, any chance to land that stuff this week?
[13:12] <fginther> 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] <fginther> I can't do it directly
[13:13] <kenvandine> Laney, ^^ can you do that?  push lxc-android-config through?
[13:13] <kenvandine> Laney, from proposed to release that is
[13:13] <kenvandine> fginther, can't we drop the boottest for it?
[13:16] <fginther> 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] <fginther> kenvandine, ok, lets see if this works
[13:31] <fginther> kenvandine, that did it
[13:31] <kenvandine> woot
[13:31] <kenvandine> thanks!
[13:31] <kenvandine> fginther, so future jobs won't need massaging?
[13:32] <kenvandine> not that i hope to land lxc-android-config... it isn't exactly fun :)
[13:32] <fginther> 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] <kenvandine> ok
[13:33] <kenvandine> fginther, it's had passing runs before though
[13:33] <kenvandine> which is just odd...
[13:33] <kenvandine> unless those were faked :)
[13:33] <kenvandine> dunno
[13:33] <jibel> 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] <jibel> s/an/and/
[13:35] <fginther> kenvandine, there was a regression in the boottest that was causing packages to not actually be installed for a while
[13:35] <pstolowski> jibel, ok, thanks. 13' MR was approved yesterday
[13:35] <fginther> kenvandine, which would explain those passes
[13:35] <kenvandine> ah
[14:06] <kgunn> sil2100: just checking, silo 4 having trouble on unity8 due to libconnectivity-qt1, any update on that one ?
[14:06] <kgunn> i was disconnected for a bit
[14:08] <sil2100> 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] <slangasek> 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] <sil2100> slangasek: uh, ok, too late, but I think everything was fine I suppose...
[14:18] <sil2100> 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] <Laney> kenvandine: fginther: Can you fix boottest to skip this package if it's never going to work?
[14:18] <sil2100> And since there was no change in tarballs, I thought no new image with junk would appear
[14:19] <slangasek> 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] <sil2100> Ouch
[14:19] <slangasek> sil2100: I've marked the channel manual for the moment, and we'll need to delete the image to clean it up
[14:19] <sil2100> Yeah, once we actually get a real image to this channel
[14:19] <slangasek> 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] <slangasek> sil2100: no, immediately; I'll work on it now
[14:20] <sil2100> Anyway, we seem to have the snapshot image in 14.09-factory-proposed now, just confirming it has the right parts
[14:22] <sil2100> Ok, image looks fine, device and custom bits are correct + the ubuntu parts correct
[14:23] <sil2100> 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] <sil2100> Not a big deal, but I didn't want them to have strange images (but they already did get that, eh)
[14:24] <sil2100> slangasek: next time I'll make it manual, just this seemed quicker to me ;)
[14:24] <sil2100> Didn't expect it to fetch anything
[14:24] <slangasek> sil2100: 'manual' is a one-line change ;)
[14:24] <sil2100> slangasek: well, I wasn't sure it didn't require removing all the other lines
[14:24] <sil2100> I feel bad deleting so many good lines
[14:24] <sil2100> ;)
[14:25] <slangasek> broken images removed from all devices, rerunning importer
[14:26] <sil2100> slangasek: thanks, sorry about that, as I said I didn't expect anything to be pulled in since why would it
[14:30] <kenvandine> fginther, couldn't you just return success if the package is lxc-android-config?
[14:30] <kenvandine> hopefully it's truely a one-off case
[14:30] <kenvandine> we don't want to skip it for most packages
[14:31] <fginther> 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] <kenvandine> Laney, ^^
[14:31] <fginther> kenvandine, Laney, but yeah, whitelisting this package is probably the right approach here
[14:31] <Laney> I think so
[14:31] <Laney> do you need a bug or anything to track the work to do it?
[14:33] <fginther> Laney, sure, you can file them here: https://launchpad.net/ubuntu-touch-boottest
[14:35] <Laney> done, thanks
[14:36] <sil2100> kgunn: still looking into that, will have to experiment in a chroot
[14:37] <kgunn> mzanetti: ^
[14:38] <kgunn> full shell rotation==snake bit
[14:38] <mzanetti> as soon as that's landed I'll probably be drunk for a day or two
[14:39] <sil2100> 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] <sil2100> I mean, in unity8 basically, but due to connectivity-api
[14:40] <sil2100> unity8 depends on libconnectivity-qt1, that depends on indicator-network and that depends on unity8 o_O
[14:40] <sil2100> That's not healthy at all
[14:40] <mzanetti> uh oh
[14:40] <mzanetti> I don't think that has changed in a long time tho...
[14:41] <sil2100> It changed in the latest connectivity-api
[14:41] <mzanetti> oh, I see
[14:41] <sil2100> I checked and the vivid version does not depend on indicator-network
[14:41] <sil2100> The one in the overlay that's shipped with indicator-network starts having that dep ;/
[14:41] <sil2100> That smells like serious trouble to me
[14:42] <sil2100> Need to check if that can be the cause here as well
[14:42] <mzanetti> Wellark, ^^
[14:44] <sil2100> Damn, this is really bad right now
[14:45] <sil2100> When I check the amd64 unity8 build logs it's actually INSTALLING UNITY8 as a build dep during building
[14:45] <sil2100> :O
[14:50] <sil2100> Wellark: ping
[14:58] <kgunn> sil2100: just wondering, how'd this only happen in vivid+overlay? is connectivity-api diverged ?
[14:59] <sil2100> 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] <sil2100> Since you can't depend on unity8 when building unity8
[14:59] <sil2100> But I'm still looking, now prepared the chroot
[14:59] <cjwatson> Well
[14:59] <cjwatson> You can
[15:00] <cjwatson> It's not necessarily a good idea, but it's not fatal
[15:00] <slangasek> sil2100: should the importer be re-enabled now?
[15:00] <cjwatson> That sort of thing is more to be expected from toolchain-type stuff, though
[15:01] <sil2100> slangasek: I was thinking - is rc-proposed still manual? Since I woudln't want the snapshot image to generate a new image
[15:01] <sil2100> slangasek: maybe we should build a new overlay-based rootfs?
[15:05] <mzanetti> 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] <sil2100> hm, still, a bit strange it would break like this
[15:06] <sil2100> mzanetti, kgunn: I'll keep investigating, but we have a team meeting now :)
[15:06] <sil2100> So much slooower than usual
[15:06] <sil2100> But my chroot will certainly make thins easier
[15:11] <sil2100> Ok, getting somewhere
[15:12] <sil2100> Found the root cause
[15:15] <ogra_> this is ubuntu, we only have sudo causes
[15:17] <davidbarth> hey trainguards, are you guys still creating silos for oldies? like an rtm14-09 missing backport ? (see line 65)
[15:18] <ogra_> davidbarth, what for ?
[15:18] <robru> davidbarth: uh, no, rtm support was ripped out of the train
[15:18] <ogra_> all users will be on vivid soon ... no need to care for 14.09
[15:19] <mzanetti> sil2100, fix is in spreadsheet row 66
[15:19] <sil2100> mzanetti: anyway, the bug is oxide ;/
[15:19] <mzanetti> wat?
[15:19] <sil2100> I mean, not exactly, let me clear out everything in a minute
[15:19] <sil2100> Too many stuff going on
[15:20] <mzanetti> 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] <mzanetti> so I backported that commit to their 15.04 branch
[15:22] <sil2100> mzanetti: so, the problem is in qtdeclarative5-ubuntu-web-plugin which is one of the big chain dependencies
[15:23] <sil2100> hm, no, wait
[15:23] <sil2100> Oh
[15:24] <robru> 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] <sil2100> robru: uh, I reconfigured one silo at least, it seemed to be ok
[15:25] <robru> sil2100: yeah but how long ago?
[15:25] <sil2100> robru: in the morning I think, so around 7 hours ago?
[15:25] <sil2100> Damn, stupid google
[15:26] <robru> 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] <sil2100> uuh
[15:26] <mzanetti> oh dear...
[15:27] <kenvandine> robru, close it and reopen
[15:27] <kenvandine> it happened to me earlier today
[15:27] <rvr> pstolowski: Approving silo 29
[15:27] <kenvandine> robru, at least that worked for me
[15:27] <kenvandine> like 30m ago
[15:29] <robru> kenvandine: oh weird, indeed reloading worked
[15:29] <kenvandine> robru, yeah... i freaked out about it earlier... spent a few minutes swearing about the damn spreadsheet
[15:30] <robru> kenvandine: it's really pathetic. luckily the replacement is really close ;-)
[15:30] <kenvandine> robru, yeah yeah... heard that before :)
[15:30]  * kenvandine ducks
[15:31]  * kenvandine gets a red bull for robru, code faster!
[15:31] <robru> 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] <sil2100> mzanetti: ok it's actually a very absurd thing, I'm starting to think it was just some hiccup :|
[15:32] <pstolowski> rvr, great, thanks for the update!
[15:49] <slangasek> sil2100: the rc-proposed channel is still manual, yes
[15:50] <slangasek> 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] <sil2100> slangasek: ok, so we can re-enable the importer, disable the 14.09-factory-proposed and build a new rootfs
[15:50] <sil2100> Right :)
[15:50]  * slangasek nods
[15:51] <sil2100> Ok, on it
[15:52] <mzanetti> sil2100, so that branch I proposed, is that no good?
[15:52] <sil2100> Building the rootfs
[15:53] <mzanetti> https://code.launchpad.net/~mzanetti/indicator-network/backport-dep-loop-fix/+merge/261742
[15:53] <sil2100> mzanetti: I'll check it in a moment, I'm still looking for the reason of the issues
[15:54] <sil2100> 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
[15:58] <popey> sil2100: we having a landing call today?
[15:58] <popey> (just checking)
[15:59] <ogra_> oh, thats what the harps in my pocket watend to tell me !
[16:00] <sil2100> popey: yeah
[16:01] <sil2100> robru: ping pong
[16:17] <mzanetti> lol... "the harps in my pocket"
[16:17] <mzanetti> so true
[16:21] <sil2100> mzanetti: this build failure is still a mystery for me, cannot reproduce the issue in a similarily configured chroot
[16:22] <mzanetti> sil2100, same here... can't repro on the phone with the same archive configuration
[16:22] <mzanetti> sil2100, anyhow, pete-woods seems to have broken it for wily
[16:22] <mzanetti> shouldn't we just land that backport to vivid?
[16:22] <mzanetti> by broken I mean "broken the dependency loop"
[16:22] <mzanetti> aka fixed it :D
[16:24] <sil2100> Yeah, probably a good idea :) It *might* help, but... there's no guarantee
[16:24] <sil2100> We'll assign a silo, we had spreadsheet issues
[16:24] <john-mcaleely> sil2100, any story on an ota-4 build?
[16:25] <sil2100> Ah, forgot robru assigned it already
[16:25] <sil2100> john-mcaleely: it's done, the build at least, now QA is making sure all is cool
[16:25] <sil2100> Then we copy to RC
[16:25] <john-mcaleely> sil2100, aha. perfect
[16:25] <robru> sil2100: mzanetti: yep silo 18 is ready to go
[16:26] <sil2100> Good you reminded me, with all the things going on I almost forgot I need to fix up a generic image...
[16:26] <sil2100> hmmm, problem is, we already have another one
[16:26] <sil2100> Damn
[16:26] <mzanetti> thanks robru, thanks sil2100. Really appreciate your help
[16:28] <robru> mzanetti: you're welcome
[16:33] <sil2100> Ok, generic image stuffed in
[16:33] <sil2100> That was so close...
[16:34] <sil2100> 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] <mzanetti> yep
[16:36] <mzanetti> building right now
[16:38] <jhodapp> sil2100, silo27 is ready for publishing
[16:41] <sil2100> ogra_: hey! We'd need some packaging ACKs for really easy changes:
[16:41] <sil2100> 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] <ogra_> sil2100, ACK
[16:43] <sil2100> ogra_: thanks!
[16:43] <sil2100> :)
[16:45] <sil2100> 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] <sil2100> robru: while the actual change was just a small code change
[16:45] <sil2100> robru: (see https://ci-train.ubuntu.com/job/ubuntu-landing-011-2-publish/56/ )
[16:46] <sil2100> robru: will you need the PPA contents for debugging or can I publish it?
[16:46] <sil2100> (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] <sil2100> Ah, I see the reason for that
[16:46] <sil2100> robru: actually, it seems the problem here was the version number in the latest package
[16:47] <robru> sil2100: wait
[16:47] <sil2100> robru: somehow 1.4+15.10.20150521-0ubuntu8 was not in trunk...
[16:47] <robru> sil2100: do not publish
[16:47] <robru> sil2100: the reason it thinks it's a new package is because dest is set as overlay ppa.
[16:47] <sil2100> It got hm, overriden by 1.4+15.04.20150521-0ubuntu1, strange stuff
[16:47] <robru> sil2100: not a train bug, silo is misconfigured.
[16:47] <sil2100> Ah, uuuh!
[16:47] <robru> sil2100: nuntium really isn't in overlay ppa
[16:47] <jhodapp> thanks sil2100
[16:47] <sil2100> Duh
[16:48] <sil2100> robru: right, not for wily at leaset
[16:48] <robru> sil2100: reconfigure for wily and watch only build,should fix it
[16:48] <sil2100> *least
[16:48] <robru> sil2100: I mean reconfigure without dest ppa set
[16:48] <sil2100> Right
[16:51] <sil2100> robru: ok, updated the MR, if you could later top-approve it it would be awesome
[16:51] <sil2100> :)
[16:51] <sil2100> Thanks for noticing the invalid target btw.!
[16:52] <robru> sil2100: you're welcome
[17:05] <robru> boiko: you got silo 20, note telephony-service conflict in silo 43
[17:07] <sil2100> robru: publishing still broken...
[17:07] <sil2100> robru: it would require a rebuild probably
[17:07] <sil2100> robru: as it has the wrong information in the upload, but I suppose the package itself is good
[17:08] <robru> 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] <robru> sil2100: I say just force publish it, should be fine
[17:08] <robru> sil2100: the package is definitely fine, this is just an issue with train barfing on the diff
[17:09] <sil2100> -nuntium (1.4+15.10.20150521-0ubuntu8) wily; urgency=medium
[17:09] <sil2100> +nuntium (1.4+15.04.20150521-0ubuntu1) vivid; urgency=medium
[17:09] <sil2100> This is a bit worrying but still
[17:09] <sil2100> I guess it's ok to publish
[17:09] <sil2100> I'll go on ahead since we need this package badly now
[17:09] <robru> 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] <robru> oh, the previous release. weird.
[17:11] <robru> 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] <sil2100> hah, yeah...
[17:43] <popey> pmcgowan: I know how much you love bugs - this is annoying https://bugs.launchpad.net/ubuntu/+source/qtcreator-plugin-ubuntu/+bug/1454210
[17:43] <popey> 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] <popey> pmcgowan: will hit everyone once we OTA-4
[17:44] <pmcgowan> that is annoying
[17:44] <pmcgowan> oh
[17:44] <pmcgowan> popey, so its not a developer thing only?
[17:44] <popey> nope
[17:45] <popey> if a user updates an app which has an OA plugin inside (reminders/notes) it will hit them
[17:45] <popey> mzanetti: right? ^
[17:45] <pmcgowan> popey, sounds like you need to uninstall
[17:45] <mzanetti> erm... it is a developer thing only
[17:45] <pmcgowan> not update
[17:45] <popey> mzanetti: how so?
[17:46] <mzanetti> because update doesn't remove it, only if the account is uninstalled
[17:46] <popey> mzanetti: if I pkcon install-local a new reminders, it does it to me.
[17:46] <popey> I have to re-auth each time
[17:46] <mzanetti> oh really
[17:46] <mzanetti> well, I only tried with qtcreator which does indeed a remove + install
[17:46] <popey> maybe the wording of that bug doesn't cover my use case exactly
[17:47] <mzanetti> however, I don't think we're affected if an app is just updated in the store
[17:47] <popey> how so?
[17:47] <mzanetti> at least I wouldn't have noticed it yet... we are releasing a reminders update now, are we?
[17:47] <mzanetti> I will watch out if it happens
[17:47] <popey> soon
[17:47] <popey> let me test on my device here
[17:48] <popey> you dont think it happens from store, but does from pkcon?
[17:48] <popey> can't see how
[17:48] <mzanetti> fair point
[17:48] <popey> lemme confirm anyway
[17:52] <popey> ok, so all works as expected on rtm... upgraded and didn't lose the account
[17:52]  * popey tries vivid
[17:55] <mzanetti> I only have this issue as of vivid
[17:59] <popey> mzanetti: confirmed
[17:59] <mzanetti> popey, what is the situation then?
[17:59] <popey> 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] <popey> (on vivid)
[18:00] <mzanetti> popey, erm... does it affect us throught the store too?
[18:00] <popey> I don't see how it wont
[18:00] <mzanetti> O_o
[18:01] <mzanetti> 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] <popey> i can do that, yes
[18:01] <popey> i can pluck any old version from jenkins. will do that now, to confirm
[18:04] <popey> mzanetti: confirmed
[18:05] <mzanetti> :(
[18:05] <popey> 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] <popey> mzanetti: updated bug
[18:16] <popey> 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] <pmcgowan> sh*t
[18:16] <pmcgowan> popey, tagging it up
[18:16] <popey> So only affects apps which have an online account component where the user has logged in.
[18:16] <popey> It's an inconvenience.
[18:17] <popey> thanks
[18:18] <davmor2> pmcgowan: did this get fixed in rtm maybe the fix was never ported to vivid
[18:18] <davmor2> pmcgowan: we had it for the u1 account
[18:18] <popey> It certainly doesn't happen in RTM
[18:18] <popey> (now)
[18:19] <pmcgowan> davmor2, not sure
[18:20] <davmor2> popey: good catch though. we wouldn't of picked it up as we start from a fresh base and then install the stuff to test everytime.  So the account was only created after the app was installed :(
[18:28] <om26er> pedronis, pinh
[18:28] <om26er> ping
[18:28] <om26er> pedronis, re: silo38 -- I am not sure if the proposed package really fixes the issue.
[18:40] <pedronis> om26er: do you still see the issue in the bug?
[18:40] <om26er> pedronis, yes, after clearing the messages, I quickly sent another email, after 15 minutes that email never showed up in notifications
[18:40] <om26er> pedronis, I did however see a later email
[18:44] <pedronis> om26er: did you restart ubuntu-push-client after installing (I'm not sure the package does that atm)
[18:44] <pedronis> ?
[18:44] <om26er> pedronis, i rebooted
[18:49] <pedronis> om26er: ok, I'm not sure what to do, either there is a bug in account-polld or the timing is such that is really an easy problem to trigger even with the fix and that means we need a better interface for this from the messaging-indicator
[18:52] <om26er> pedronis, :/
[18:53] <pedronis> om26er: and the client and account is moving to another team soon, so I won't work on it anymore, not sure if to revert the change (the change is better than before but may be useless) or we should land it anyway
[18:54] <pedronis> s/and account/and account-polld/
[19:02] <om26er> pedronis, it it didn't fix the bug, I don't think it makes sense to lad it
[19:03] <pedronis> om26er: ok, I will revert and it goes back to the todo list of who picks up the project
[19:13] <robru> kenvandine: around for a packaging ack? https://ci-train.ubuntu.com/job/ubuntu-landing-013-2-publish/lastSuccessfulBuild/artifact/unity-scopes-api_packaging_changes.diff/*view*/
[19:13] <kenvandine> robru, sure
[19:13] <robru> thanks
[19:14] <robru> alex-abreu: https://code.launchpad.net/~abreu-alexandre/webbrowser-app/saml-url-persistence/+merge/260248 need this top approved before I can publish
[19:14] <alex-abreu> robru, done
[19:15] <robru> alex-abreu: thanks
[19:15] <kenvandine> robru, the build depends change for g++ looks a little odd based on the comment that was there before
[19:15] <kenvandine> -               g++-4.9:native,
[19:15] <kenvandine> +               g++,
[19:15] <kenvandine> but
[19:16] <kenvandine> the fact that the comment was removed too, makes me think this was intentional
[19:16] <kenvandine> so... ack :)
[19:16] <robru> kenvandine: yeah that concerned me. but I mean, it's not like they changed that by accident right?
[19:16] <kenvandine> right
[19:16] <robru> kenvandine: k, thanks
[19:16] <kenvandine> so... ack
[19:16] <kenvandine> np
[19:19] <sil2100> ToyKeeper: hey! Are you around? :)
[19:20] <sil2100> jibel: hey, image 10 in -factory-proposed should have all the right changes
[19:30] <ToyKeeper> sil2100: Hmm?
[19:32] <ToyKeeper> I've got an appointment in a few minutes but should be around all day afterward...
[19:45] <pmcgowan> sil2100, finally?
[19:47] <sil2100> ToyKeeper: could you check image 10 from the ubuntu-rtm/14.09-factory-proposed channel?
[19:47] <sil2100> ToyKeeper: it's our new OTA-4 candidate, it basically only needs checking if MMS group chat is disabled by default and some hm, nuntium fix
[19:56] <sil2100> alesage: hey! :)
[19:56] <alesage> sil2100, hiya
[19:56] <sil2100> alesage: maybe you could help out as well with validating an image?
[19:56] <alesage> sil2100, ok what's needed?
[19:57] <sil2100> alesage: so, channel ubuntu-rtm/14.09-factory-proposed has a new release candidate for OTA-4
[19:57] <sil2100> alesage: davmor2 already tested image 9, but we missed a few fixes so I build image 10
[19:58] <sil2100> alesage: so, image 10 now needs to be checked if MMS group-chat is disabled by default and there's also fix for LP: #1459995
[19:59] <alesage> sil2100, ok acknowledged
[19:59] <sil2100> alesage: thank you! :)
[20:19] <robru> mzanetti: https://ci-train.ubuntu.com/job/ubuntu-landing-018-2-publish/lastSuccessfulBuild/artifact/indicator-network_packaging_changes.diff/*view*/ hm? why are you dropping the dep on unity8?
[20:20] <robru> mzanetti: oh is it cyclic?
[20:23] <mzanetti> robru, there's a circular dependency between this and unity8
[20:23] <robru> mzanetti: ok
[23:17]  * ToyKeeper wonders if image 10 still needs validation