[06:56] <Mirv> jgdx: seb128 is asking for revert of indicator-datetime from https://requests.ci-train.ubuntu.com/#/silo/054 because it's crashing on login screen on Unity 7. a revert is currently building at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-017/+packages
[06:56] <Mirv> ideas/fixes welcome
[06:58] <Mirv> jgdx: duflu discovered it on #ubuntu-desktop http://pastebin.ubuntu.com/20008534/
[06:58] <Mirv> so bug #1604251
[07:01] <bzoltan> cjwatson: I could not figure anything out with chdits about this - https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-019/xenial/ppc64el/u/ubuntu-system-settings-online-accounts/20160718_054019@/log.gz
[07:53] <Mirv> sil2100: indicator-datetime possible revert needed http://pastebin.ubuntu.com/20011634/
[07:53] <sil2100> Mirv: ACK, are you using the train revert function for this?
[07:54] <Mirv> sil2100: yes
[07:54] <Mirv> the silo is ready, just not sure if it's safe to revert only that either, but at least is ready
[07:55] <sil2100> I'm thinking if we shouldn't just revert it for yakkety
[07:56] <sil2100> Oh, no, actually not
[07:56] <jgdx> Mirv, ugh okay.
[08:04] <jgdx> Mirv, seb128: okay, I'll bump the version
[08:06] <seb128> jgdx, Mirv, I think the issue is that the key is in the touch schemas which isn't installed on the desktop and not in the depends
[08:07] <jgdx> seb128, okay
[08:07] <seb128> jgdx, Mirv, ignore that, looks like we merged the schemas (which makes sense) so it's likely just the version that needs to be updated
[08:08] <jgdx> seb128, okay, there's a dep there, on gsettings-ubuntu-schemas (>= 0.0.7)
[08:09] <jgdx> but the change was in -touch-schemas
[08:09] <seb128> that's not new enough
[08:10] <seb128> http://launchpadlibrarian.net/273763407/gsettings-ubuntu-touch-schemas_0.0.7+16.10.20160615.1-0ubuntu1_0.0.7+16.10.20160701-0ubuntu1.diff.gz
[08:10] <seb128> it was not there in 0.0.7+16.10.20160615.1-0ubuntu1
[08:10] <seb128> which is > 0.7
[08:10] <seb128> you want >= 0.0.7+16.10.20160701
[08:10] <jgdx> okay
[08:11] <jgdx> gsettings-ubuntu-schemas == gsettings-ubuntu-touch-schemas, though right?
[08:13] <seb128> yeah
[08:13] <seb128> gsettings-ubuntu-touch-schemas is a dummy transational binary
[08:14] <jgdx> seb128, the whole silo was reverted?
[08:14] <seb128> dunno
[08:14] <seb128> Mirv ^
[08:16] <jgdx> seems so
[08:24] <jgdx> Mirv, sil2100: okay, I'm waiting for the word on what happened to the silo, if we need to land that again with the deps in order or what. :)
[08:25] <Mirv> jgdx: no the https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-017/+packages currently just has indicator-datetime
[08:25] <Mirv> jgdx: and it's only a silo, nothing is really reverted yet
[08:25] <Mirv> jgdx: but ubuntu-system-settings and gsettings-ubuntu-touch-schemas are stuck in proposed from the original landing https://requests.ci-train.ubuntu.com/#/silo/054
[08:29] <jgdx> Mirv, not sure what you're saying. I'm thinking maybe I could help fix this in Arthur's absence, but it's not clear to me what I need to do.
[08:33] <Mirv> jgdx: you were asking about what happened to the silo - it's still landed. there's another silo with just indicator-datetime revert in it, but I don't know if it is safe to revert just indicator-datetime alone.
[08:34] <Mirv> jgdx: and additionally regarding the silo, the two packages are stuck in proposed so not really in yakkety
[08:36] <seb128> which ones?
[08:37] <seb128> because the indicator is not stucked in proposed
[08:37] <seb128> which is why users hit the issue
[08:49] <Mirv> https://requests.ci-train.ubuntu.com/#/silo/054 -> Proposed pocket ( gsettings-ubuntu-touch-schemas/yakkety, ubuntu-system-settings/yakkety).
[11:47] <cjwatson> bzoltan: Nor can I.  I've asked pitti to help
[12:01] <ogra_> sil2100, can your pending livecd-rootfs chnages be uploaded ?
[12:01] <ogra_> (happy to do it, just want to make sure )
[12:27] <sil2100> ogra_: yes, we have the same bits in vivid already released and nothing exploded
[12:28] <sil2100> I didn't want to unnecessarily release those since they weren't needed in yakkety instantly
[12:29] <rvr> renatu: ping
[12:31] <Mirv> sil2100: any silo to follow regarding xenial not booting (on my krillin)?
[12:32] <sil2100> Mirv: we didn't check unbootability on xenial recently
[12:32] <Mirv> I'm trying to figure out what's reported and what's not, since I'd need working xenial base in order to try out Qt 5.6.1 soon
[12:32] <Mirv> sil2100: yeah something would seem to be up
[12:33] <Mirv> crashalot http://pastebin.ubuntu.com/20030881/
[12:33] <bzoltan> cjwatson: thanks
[13:15] <renatu> trainguards, any idea what is happening on silo 73? It was building nice last week. This week is not building and we did not change any code
[13:16] <renatu> rvr, hey victor
[13:16] <rvr> renatu: Hi
[13:16] <rvr> renatu: You already answered my question :)
[13:16] <renatu> rvr, I am trying to solve the build problem with trainguards
[13:16] <rvr> renatu: Ack
[13:16] <Mirv> renatu: account-polld fails with dh_auto_build: go install -v launchpad.net/account-polld/... returned exit code 1
[13:16] <renatu> rvr, it is not a code problem. Something has changed on the build system
[13:17] <Mirv> renatu: go build error on all three (yakkety, xenial, vivid), but I think you need to try to build it locally to find out what's wrong as there's not much error output. on vivid it's "dh_auto_build: go install -v launchpad.net/account-polld/accounts launchpad.net/account-polld/cmd/account-polld launchpad.net/account-polld/cmd/account-watcher-test launchpad.net/account-polld/cmd/qtcontact-test launchpad
[13:17] <Mirv> .net/account-polld/gettext launchpad.net/account-polld/plugins launchpad.net/account-polld/plugins/gcalendar launchpad.net/account-polld/plugins/gmail launchpad.net/account-polld/plugins/twitter launchpad.net/account-polld/plugins/twitter/oauth launchpad.net/account-polld/pollbus launchpad.net/account-polld/qtcontact returned exit code 1"
[13:18] <Mirv> see log at https://launchpadlibrarian.net/273920282/buildlog_ubuntu-vivid-amd64.account-polld_0.1+15.04.20160719-0ubuntu1_BUILDING.txt.gz
[13:19] <renatu> Mirv, yes something changed on the build environment. I will check with go experts what I can do to fix that.
[13:21] <Mirv> ok, thanks
[13:22] <rvr> renatu: Another question. I have a "Reminders" calendar in Google Calendar, that I cannot see in the calendar app. Do you know whether "reminders" is a special calendar in Google?
[13:22] <renatu> rvr, yes "reminders" as a special kind not supported by calendar-app
[13:23] <rvr> renatu: Ok
[13:23] <renatu> we should have a reminder app or implement integration on our calendar-app
[13:23] <renatu> not defined yet
[13:24] <rvr> renatu: Related... How can I reproduce "Reminders synced from google does not appear on the app"?
[13:25] <renatu> rvr, create a notification on your event.
[13:26] <renatu> rvr, maybe I should rephrase that it could cause confusions :D
[13:26] <renatu> rvr, edit you event and add a reminder/notification on it (like 10 mins before the event)
[13:26] <renatu> make sure that appear on the calendar-app
[13:27] <rvr> Ok
[13:27] <renatu> Mirv, it builds nice on my machine
[13:30] <renatu> Mirv, this error: rc/launchpad.net/account-polld/cmd/account-polld/account_manager.go:27:2: cannot find package "launchpad.net/ubuntu-push/click/cblacklist" in any of:
[13:30] <renatu> 	/usr/lib/go/src/pkg/launchpad.net/ubuntu-push/click/cblacklist (from $GOROOT)
[13:30] <renatu> looks strange
[13:31] <renatu> since this file is part of "golang-ubuntu-push-dev" and it is already in the build dep list
[13:33] <renatu> Mirv, oh, wait the version of that package used by the build system is not the same version that I have in my machine
[13:34] <Mirv> renatu: since it's failing consistently on all three series, it's at least not eg yakkety devel specific problem but a general one
[13:34] <renatu> Mirv, yes it is using a version from overlay ppa
[13:35] <renatu> this version changed something that broken the build
[13:39] <renatu> Mirv, I think I found the problem: https://requests.ci-train.ubuntu.com/#/ticket/1378
[13:39] <renatu> Mirv, this silo needs to land
[13:40] <Mirv> renatu: it has landed for xenial + vivid already, so it can't be the reason for xenial/vivid builds landing
[13:42] <renatu> Mirv, the mr did not merged
[13:42] <Mirv> renatu: ah right, yes, that would be a problem. because the yakkety packages are stuck, the merge is not happening.
[13:42] <sil2100> It seems this one landing causes various issues everywhere
[13:43] <renatu> it contains the necessary changes for account-polld to build again
[13:43] <Mirv> well at least the fact that it hasn't really landed
[13:43] <Mirv> it seems ubuntu-system-settings is stuck in yakkety-proposed for the same mysterious problem on ppc64el that UITK can't get to QA queue: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/u/ubuntu-system-settings-online-accounts/20160718_185637@/log.gz
[13:44] <Mirv> bzoltan and cjwatson were talking about it earlier, and that looks similar
[14:21] <kenvandine> Mirv, i've confirmed that indicator-datetime bug seems to be caused by the schema package being held in yakkety-proposed
[14:21] <kenvandine> so no need to revert it... we just need to get that package promoted :)
[14:22] <kenvandine> Mirv, jgdx has a branch bumping the depends version, which is good but won't actually fix it for anyone that has updated until that package is promoted
[14:27] <dbarth> hey trainguards; could you remove the signon-ui packages in silo 062 please?
[14:27] <sil2100> dbarth: on it
[14:27] <dbarth> i have reconfigured the silo to exclude a broken merge proposal
[14:27] <dbarth> thanks
[14:27] <sil2100> dbarth: removed :) yw!
[14:28] <dbarth> cool
[15:10] <seb128> Mirv, you didn't land the indicator-datetime revert?
[15:17] <kenvandine> seb128, hey
[15:17] <kenvandine> seb128, please don't revert that ;)
[15:18] <seb128> grrrr
[15:18] <kenvandine> once the schema gets migrated to release it'll be fine
[15:18] <seb128> wth people
[15:18] <seb128> right
[15:18] <seb128> meanwhile everybody is broken in yakkety
[15:18] <kenvandine> we have a branch that bumps the depends
[15:18] <kenvandine> but that won't actually fix anything
[15:18] <seb128> if it had been reverted 10 hours it would be already fixed for users
[15:18] <kenvandine> since it'll get blocked as well
[15:18] <seb128> right
[15:18] <kenvandine> yeah... but now we'll know in an hour or so if it'll migrate
[15:18] <seb128> which is why I wanted a revert this morning
[15:18] <seb128> best path to fix users
[15:18] <kenvandine> waiting for those flaky unity8 tests
[15:18] <seb128> then figure out the screwups
[15:19] <seb128> right
[15:19] <kenvandine> the autopkgtests passed for yakkety in the silo
[15:19] <seb128> meanwhile we just screwed all the users who updated since this morning
[15:19] <kenvandine> yeah
[15:19] <kenvandine> i know
[15:19] <kenvandine> but we're close now
[15:19] <seb128> we should have reverted
[15:19] <kenvandine> or if we could force the migration?
[15:19] <seb128> yeah, classic "it's going to be fixed soon"
[15:19] <bfiller> seb128, kenvandine : quickest solution would be to get those packages held in proposed from silo 54 landed
[15:19] <seb128> and one day later users are still screwed
[15:19] <kenvandine> we know the tests passed in the silo
[15:19] <bfiller> and not wait for the autopackage tests to run again
[15:19] <bfiller> https://requests.ci-train.ubuntu.com/#/silo/054
[15:20] <seb128> that silo is not going to fix anything
[15:20] <kenvandine> seb128, no, that shows the tests passed there
[15:20] <seb128> it's going to block the silo version in proposed with the schemas until that one migrates
[15:20] <kenvandine> can we force the migration?
[15:20] <bfiller> kenvandine, seb128: yes that's what I'm saying, force migration as we know the tests alaready passed
[15:20] <seb128> I guess pitti or such could
[15:20]  * kenvandine hates those flaky unity8 tests
[15:20] <seb128> also who approved that landing?
[15:21] <kenvandine> rvr
[15:21] <seb128> was that reviewed by somebody with upload rights?
[15:21] <seb128> it has packaging changes
[15:21] <seb128> it should have gone through a coredev ack
[15:21] <kenvandine> oh... me :)
[15:21] <seb128> ha
[15:21] <seb128> oh...
[15:21] <kenvandine> you can yell at me :)
[15:21] <seb128> well errors happens :p
[15:21] <seb128> happen
[15:21] <seb128> I'm going to rent at you for arguing against reverting in case of regressions
[15:21] <kenvandine> 8	-               gsettings-ubuntu-schemas,
[15:21] <kenvandine> 9	+               gsettings-ubuntu-schemas (>= 0.0.7),
[15:21] <kenvandine> i saw that
[15:22] <kenvandine> and thought it was good enough
[15:22] <kenvandine> but it wasn't
[15:22] <seb128> yeah, honest mistake, don't worry
[15:22] <seb128> still when there is a regression that hits users we should revert
[15:22] <kenvandine> i should have checked the archive
[15:22] <seb128> not wait half a day that u.s wake up to start figuring out to fix
[15:22] <seb128> and have another half a day to land a fix
[15:23] <kenvandine> the revert silo failed to build
[15:23] <seb128> next time I guess I just dput a revert
[15:23] <seb128> screw buggy ci processes :p
[15:23] <kenvandine> for vivid only
[15:23] <kenvandine> a revert to yakkety only would have been harmless
[15:23] <seb128> right
[15:23] <seb128> I should have done that
[15:24] <kenvandine> yeah
[15:24] <seb128> Mirv also didn't tell me he was stucked on not acting on it
[15:24] <seb128> annoying
[15:27] <bfiller> kenvandine, seb128: so options I see at this point  to fix broken yakety 1) force migration of silo 54 2) revert changes 3) wait until autopackage tests (hopefully) pass so migration of silo 54 can continue. My pref is 1). thoughts?
[15:27] <kenvandine> i'd prefer 1 as well
[15:28] <kenvandine> but a manual dput of indicator-datetime reverting the change to yakkety only would be harmless too
[15:28] <bfiller> fine with that
[15:28] <kenvandine> but we'd have to wait for it to get through the proposed migration as well
[15:28] <kenvandine> forced migration would be quicker
[15:28] <seb128> let me poke pitti
[15:28] <kenvandine> seb128, thx!
[15:33] <seb128> kenvandine, bfiller, pitti is letting it through but somebody needs to fix the unity8 tests
[15:33] <kenvandine> thx
[15:33] <kenvandine> seb128, we've complained about it
[15:34] <kenvandine> they said someone is looking into it
[15:34] <kenvandine> it's been a problem for quite a while
[15:34] <bfiller> seb128: ack
[15:35] <seb128> right, pitti and L_aney pointed out that, next time not forcing over because apparently it has been like that for a while and skipping removes the incensitive the fix things
[15:35] <kenvandine> seb128, these tests cause me to spend days clicking retry ever 3 hours :(
[15:35] <seb128> why isn't anyone in the unity8 team dealing with it?
[15:35] <kenvandine> s/ever/every
[15:35] <seb128> it's stupid
[15:35] <kenvandine> Saviq said someone is working on it
[15:36] <seb128> where is Saviq? ;-)
[15:36] <kenvandine> a couple weeks ago
[15:36] <seb128> hidding?
[15:36] <kenvandine> hanging out in germany :)
[15:36] <kenvandine> he's at the sprint
[15:37] <rvr> renatu: Silo 73 approved
[15:37] <ogra_> he said he is on vacation til tomorrow (i met him in the hotel restaurant/garden)
[15:37] <ogra_> :)
[15:37] <renatu> rvr, thanks, bfiller ^^
[15:39] <rvr> mardy: dbarth: I need the test scope and credentials for silo 59
[15:41] <dbarth> rvr: ack; on a call, brb
[15:41] <Mirv> seb128: I mentioned it was unclear to me whether it's safe to revert just indicator-datetime while 054 had many related packages in it. there were too many cooks handling this soup.
[15:42] <seb128> when in doubt revert it all :-)
[15:42] <seb128> oh well, it's forced though now
[15:42] <Mirv> yeah I read the backlog
[15:42] <rvr> Mirv: What is the problem with 54?
[15:43] <kenvandine> rvr, the gsettings schema was held in proposed and broke indicator-datetime in yakkety
[15:43] <kenvandine> held because of the flaky unity8 autopkgtests
[15:44] <kenvandine> which passed in the silo, but get rerun for proposed migration
[15:44] <rvr> kenvandine: I see
[15:44]  * kenvandine needs to step out for lunch, bbiab
[15:44] <sil2100> seb128: hey! I know I overused your trust through the repowerd preNEW thing (;p), but maybe you could take a look in some spare time at the binNEW of https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1037/2016-07-19_14:11:37/yakkety_address-book-service_packaging_changes.diff from silo 73? ;)
[15:46] <popey> sil2100: when is ota-12 due?
[15:46] <seb128> sil2100, hey, don't worry about that, miscommunication can happen ... looking ;-)
[15:46] <sil2100> popey: next week, hopefully early next week - worst case around Wednesday
[15:47] <popey> sil2100: thanks, hope it goes well!
[15:47] <rvr> jgdx: Silo 37 merge proposal needs approval.
[15:48] <seb128> sil2100, usr/lib/evolution-data-server/registry-modules/module-ubuntu-sources.so is moved between binaries, that needs a N
[15:48] <seb128> B,R
[15:48] <seb128> sil2100, the binary naming doesn't seem really great, e-d-s-ubuntu?
[15:49] <seb128> I've no clue even from the description how that's ubuntu specific
[15:49] <seb128> is that of ubuntuone accounts?
[15:52] <sil2100> Right, didn't look into the packaging yet, this needs to be fixed before we can push that out! For the descriptions, it's ubuntu specific I guess because it deals with apps for the Ubuntu app store
[16:08]  * sil2100 needs to get back to the habbit of checking packages first before giving them to preNEW review
[16:09] <ogra_> pffft ... just wait til you get bug reports from users ...
[16:43] <dobey> seb128, sil2100: what the heck is that?
[16:43] <seb128> "that"?
[16:43] <dobey> the e-d-s-ubuntu thing
[16:44] <seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1037/2016-07-19_14:11:37/yakkety_address-book-service_packaging_changes.diff
[16:44] <seb128> I don't really understand it from the description
[16:44] <dobey> yeah, that oesn't make much sense to me either
[16:47] <dobey> https://code.launchpad.net/~renatofilho/address-book-service/create-eds-extension-package/+merge/296447 doesn't tell me anything more either really
[16:48] <kenvandine> Broken ubuntu-system-settings:ppc64el Depends on powerd:ppc64el < none | 2016.06+16.10.20160706.1-0ubuntu1 @un uH > (>= 0.15)
[16:48] <kenvandine> seb128, ^^ does that make any sense to you?
[16:48] <seb128> kenvandine, is that yakkety?
[16:49] <kenvandine> i guess it's just the lack of powerd for ppc64el
[16:49] <kenvandine> yes
[16:49] <kenvandine> the system-settings migration is held up because of the ubuntu-system-settings-online-accounts autopkgtest failure on yakkety ppc64el
[16:50] <seb128> kenvandine, unsure, but powerd is built from repowerd there now
[16:50] <kenvandine> which is failing to resolve depends
[16:50] <seb128> but that was reverted in the overlay
[16:50] <seb128> so yakkety and overlay are out of sync on that
[16:50] <seb128> unsure how that works with landings
[16:50] <kenvandine> the depends it's missing is actually system-settings
[16:51] <dobey> the problem is repowerd isn't build on ppc
[16:51] <seb128> you mean?
[16:51] <seb128> right
[16:51] <kenvandine> uss-oa depends on uss, uss depends on powerd
[16:51] <seb128> well powerd wasn't either
[16:51] <dobey> then how would it have passed before?
[16:52] <kenvandine> maybe the lack of passing tests for ppc64el didn't used to hold up proposed migration?
[16:52] <seb128> britney blocks regressions
[16:52] <kenvandine> right
[16:52] <seb128> it doesn't require you to build on all arches
[16:52] <seb128> just to not build on less than you used to build on
[16:52] <kenvandine> so it must have passed on this arch before
[16:52] <dobey> right, but if it's blocking, then it must have regressed
[16:52] <seb128> so if it never existed there it's fine
[16:52] <seb128> well https://launchpad.net/ubuntu/+source/powerd/0.16+16.04.20160204.1-0ubuntu2~xenial1
[16:52] <seb128> britney compare pockets
[16:52] <seb128> and it doesn't exist there
[16:53] <seb128> what page are you looking at?
[16:53] <dobey> hmm, weird
[16:53] <seb128> oh
[16:53] <kenvandine> http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-system
[16:53] <seb128> ?
[16:53] <dobey> kenvandine: i see s390x was marked ignored
[16:54] <kenvandine> autopkgtest for ubuntu-system-settings-online-accounts/0.7+16.10.20160628.2-0ubuntu1: amd64: Pass, armhf: Pass, i386: Pass, ppc64el: Regression ♻ , s390x: Ignored failure
[16:54] <seb128> it fails the autopkgtest for online accounts on ppc64el
[16:54] <kenvandine> yes
[16:54] <dobey> maybe it need to be flagged
[16:54] <kenvandine> the failure is that it can't install system-settings
[16:54] <kenvandine> because of missing powerd
[16:54] <kenvandine> so powerd must have been built there at one point
[16:54] <kenvandine> and deleted?
[16:55] <cjwatson> I'm sceptical that it's just that
[16:55] <cjwatson> ubuntu-system-settings depends on powerd | gnome-settings-daemon, and gnome-settings-daemon is installable on ppc64el
[16:55] <kenvandine> ah
[16:55] <dobey> oh
[16:55] <kenvandine> so maybe i'm going down the wrong rabbit hole
[16:56] <cjwatson> You might be.  I'd suggest looking at old successful test logs and seeing which set of packages they managed to install
[16:56] <cjwatson> If they installed gnome-settings-daemon, then powerd is very likely the wrong rabbit-hole
[16:56] <kenvandine>   Holding Back ubuntu-system-settings:ppc64el rather than change gnome-settings-daemon:ppc64el
[16:57] <cjwatson> Yeah, but why :)
[16:57] <cjwatson> I couldn't reproduce in chdist when I tried earlier
[16:57] <cjwatson> But I didn't have quite the same setup, and I ran out of time to dig
[16:57] <kenvandine> Setting up gnome-settings-daemon (3.18.2-0ubuntu3) ...
[16:57] <kenvandine> from the last pass
[16:57] <kenvandine> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/u/ubuntu-system-settings-online-accounts/20160711_105452@/log.gz
[16:59] <dobey> ugh what a mess
[16:59] <dobey> (this silo)
[16:59] <kenvandine> indeed
[16:59] <kenvandine> actually i was asking mardy about this a few days ago
[16:59] <kenvandine> i saw this failure in a silo
[17:00] <kenvandine> not silo 54 :)
[17:00] <kenvandine> but 54 does seem cursed
[17:00] <dobey> right, but either way, it's the same issue
[17:00] <kenvandine> yeah
[17:00] <kenvandine> and these logs are very confusing
[17:01] <dobey> well, this issue is the same issue. all the other issues i have with that silo are different from this one :)
[17:01] <cjwatson> kenvandine: If you have a recent-ish successful log, diffing against the latest failure is sometimes a helpful approach
[17:02] <kenvandine> diff the logs?
[17:02] <kenvandine> doubt that will help, the successful one installs the deps :)
[17:02] <kenvandine> never get to that point on the failing log
[17:02] <jgdx> kenvandine, do you have acc to set [1] as approved too? [1] https://code.launchpad.net/~jonas-drange/ubuntu-settings-components/tap-not-swipe/+merge/299798
[17:02] <jgdx> kenvandine, I don't
[17:02] <kenvandine> jgdx, i'll check
[17:03] <kenvandine> cjwatson, the passing log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/u/ubuntu-system-settings-online-accounts/20160711_105452@/log.gz
[17:03] <kenvandine> jgdx, done
[17:04] <jgdx> kenvandine, thanks!
[17:04] <jgdx> rvr, it's done (silo 37 mp approved)
[17:04] <cjwatson> kenvandine: I'm not going to look in more detail, but the reason I think it might help is that perhaps the packages installed earlier on in the log will differ
[17:04] <kenvandine> ok
[17:05] <dobey> kenvandine: i think the issue is related to the gnome-settings-daemon/gnome-control-center vs unity-settings-daemon/unity-control-center stuff
[17:08] <dobey> cjwatson: since your here, might you have any idea why when building a package with sbuild, a dep like "pyflakes3 | pyflakes (>= M.N)" would not be falling back to the or-depends (ie, it wants to always intall pyflakes3)?
[17:09] <dobey> it seems to work fine on lp builders, but is failing in jenkins
[17:09] <cjwatson> dobey: sbuild --resolve-alternatives
[17:09] <dobey> ah
[17:09] <dobey> i wonder if it's not doing that. thanks
[17:10] <kenvandine> only obvious difference is binutils
[17:10] <kenvandine> -Get:3 http://ftpmaster.internal/ubuntu yakkety/main ppc64el binutils ppc64el 2.26.1-1ubuntu1 [2,324 kB]
[17:10] <kenvandine> +Get:3 http://ftpmaster.internal/ubuntu yakkety/main ppc64el binutils ppc64el 2.26.1-1ubuntu2 [2,322 kB]
[17:11] <cjwatson> mkay, so maybe not
[17:11] <kenvandine> yeah :/
[17:11] <kenvandine> worth a shot though
[17:12] <cjwatson> something is probably not coinstallable - may even be worth running autopkgtest on this locally with qemu-system-ppc64 (which I've never tried but maybe it will work?) to get an environment where you can poke interactively
[17:12] <dobey> well, the difference probably won't be obvious in a diff when you're looking at that, since the dependencies didn't resolve
[19:09] <robru> kenvandine: https://requests.ci-train.ubuntu.com/log/1378/finalize/1/info/ Holy hell
[19:10] <kenvandine> yeah... what the heck was that?
[19:10] <kenvandine> it succeeded though
[19:11] <robru> kenvandine: some experimental code to delete dangling bzr tags that don't point at real commits, but I'm also amazed by the sheer number of packages being deleted
[19:12] <kenvandine> i think there was many rebuilds
[19:12] <kenvandine> that silo has been around for weeks
[19:12] <kenvandine> i'm not all that familiar with it
[19:12] <robru> kenvandine: yeah, compounded by trio
[19:13] <kenvandine> it took ages to finalize too
[19:13] <kenvandine> i guess that was all the deletion of tags?
[19:13] <kenvandine> nice to keep it tidy though :)
[19:14] <kenvandine> 2016-07-19 19:11:15,178 ERROR This ticket is busy. Try again later.
[19:14] <kenvandine> robru, what's up with that?
[19:14] <kenvandine> still shows it as building
[19:14] <robru> kenvandine: yeah each tag to delete is a round-trip to the server so quite slow. It parallelizes between packages at least
[19:16] <robru> kenvandine: looking at a cached page? There's no evidence that anything has run since the finalize
[19:16] <robru> On that ticket
[19:16] <kenvandine> different ticket
[19:17] <kenvandine> https://requests.ci-train.ubuntu.com/log/1037/build/latest/
[19:17] <robru> kenvandine: which one?
[19:17] <kenvandine> oh wait
[19:17] <kenvandine> yeah, ticket 1037
[19:18] <kenvandine> latest log says it failed
[19:18] <kenvandine> but it's also currently building
[19:18] <robru> kenvandine: https://requests.ci-train.ubuntu.com/log/1037/ 77 still running when 78 attempted, should work now
[19:18] <kenvandine> oh... maybe someone else kicked a rebuild right before me :)
[19:20] <robru> kenvandine: actually yours is the one that worked, just a race condition that you were shown the log from renatu 's failed attempt
[19:22] <kenvandine> ah
[20:29] <robru> slangasek: not much to say since the meeting yesterday, want to skip?
[20:29] <slangasek> robru: can do
[20:29] <robru> slangasek: great, thanks
[22:41] <camako> robru, any idea why britney is failing on silo 69? ppc64el arch failure... https://requests.ci-train.ubuntu.com/static/britney/ticket-1693/landing-069-yakkety/excuses.html
[22:44] <robru> camako: I'm not familiar with that error,  no. kenvandine is this the same thing you were seeing earlier? ☝
[22:45] <kenvandine> robru, camako: yes
[22:45] <kenvandine> and i'm still clueless
[22:45] <robru> Ouch
[22:45] <camako> kenvandine, thanks..... at least not my fault
[22:45] <kenvandine> i think we're down to thinking either powerd, gnome-settings-daemon or unity-control-center is uninstallable
[22:46] <robru> kenvandine: weird that it's just one arch?
[22:46] <kenvandine> cjwatson suggested i try to run ppc64el autopkgtest locally to poke at it
[22:46] <kenvandine> yes
[22:46] <kenvandine> but i can't get it to build a freaking qemu image for it
[22:46] <robru> Argh
[22:47] <kenvandine> adt-buildvm-ubuntu-cloud just keeps timing out
[22:47] <kenvandine> it downloads the ppc64el image
[22:47] <kenvandine> boots it to run cloud-init
[22:47] <kenvandine> then times out
[22:47]  * kenvandine has about had it!
[22:47] <robru> kenvandine: camako: I guess just poke QA to override britney and add to the queue?
[22:47] <kenvandine> got feature work with deadlines!
[22:47] <kenvandine> not a great idea...
[22:48] <kenvandine> it'll still get stuck in the yakkety proposed migration
[22:48] <robru> Right
[22:48] <kenvandine> so it's just moving the problem to later
[22:48] <kenvandine> anyway, i'm late... gotta jet
[22:48] <robru> kenvandine: night
[22:48] <camako> thanks take care
[22:51] <camako> sil2100, just FYI... ^^ since you were interested in this silo...
[22:53] <camako> and kgunn ^^
[22:53] <kgunn> ta