[08:28] <oSoMoN> ubuntu-qa: the autopkgtests for qtcreator-plugin-ubuntu failed, blocking the migration of webbrowser-app from -proposed, and I have no clue why, could it be a flaky test/temporary failure, and if so can the test job be retried? (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#webbrowser-app)
[08:35] <jibel> oSoMoN, from the error it's a problem with the shutdown of the testbed, unrelated to the webbrowser obviously
[08:35] <jibel> oSoMoN, you can ping pitti he can retry the test
[08:36] <oSoMoN> thanks jibel, I’ll do that
[10:20] <morphis> sil2100, Mirv: hey! time for another upload?
[10:27] <sil2100> morphis: sure, in a moment though!
[10:27] <morphis> sil2100: ok
[10:46] <sil2100> morphis: piiing
[13:59]  * sil2100 off to lunch
[15:15] <kgunn> trainguards just trying not to "hurry up" for QA's sake at the end of the week...so can we get silo 21 landed so we can rebuild silo 10 on top?
[15:16] <kgunn> oops scratch "not"
[16:58] <kgunn> sil2100: just curious, u-s-c is still in proposed pocket for xenial...should we force merge so we can get on with rebase, rebuilding?
[16:59] <kgunn> excuses doesn't show anything concerning...
[16:59] <kgunn> afaict
[17:08] <cjwatson> kgunn: $ grep-aptavail -nsPackage -Pe '^u[^-]*-s[^-]*-c[^-]*$' | sort -u | wc -l
[17:08] <cjwatson> 8
[17:08] <cjwatson> your abbreviations are ambiguous :)
[17:08] <kgunn> sorry unity-system-compositor
[17:08] <kgunn> cjwatson: ^
[17:09] <cjwatson> kgunn: ok, it migrated a few minutes ago, see https://launchpad.net/ubuntu/+source/unity-system-compositor/+publishinghistory - I assume the train will catch up shortly
[17:10] <kgunn> cjwatson: hmm, so here if i do apt-cache policy unity-system-compositor, it still shows installed/available as the same?
[17:10] <kgunn> maybe i don't know how it all works
[17:11] <kgunn> more like...obviously i don't know how it all works :)
[17:12] <cjwatson> kgunn: publisher takes time to run
[17:12] <kgunn> cool
[17:13] <kgunn> right makes sense...i suspect my "apt-get update/apt-cache policy" method of checking will show it  when the train does
[17:15] <cjwatson> probably rather afterwards
[17:18] <cjwatson> the train checks the publication status using the LP API - it doesn't care about whether the publisher has put it all on disk in an aptable form
[17:19] <cjwatson> (AIUI)
[17:26] <cjwatson> kgunn: there, landed
[17:37] <kgunn> ta
[18:55] <robru> kgunn: you want silo 21 landed? That's webbrowser-app and was never published, and needs a rebuild. Not sure what you're talking about
[19:05] <boiko> alesage: hi, regarding silo 52, we found one problem about the confinement: reading mms group chat settings is not working
[19:05] <boiko> alesage: the fix is on its way, just letting you know because we will have to rebuild messaging-app
[19:06] <alesage> boiko ack thx
[19:15] <kgunn> robru: nope, no silo 21 interest from me
[19:17] <Saviq> jibel, is it a script that marks u-d-s-i bugs as fix committed on landings? should probably look at all tasks to see if others are > Invalid < Fix released
[19:24] <jibel> Saviq, you mean to close other tasks too?
[19:24] <Saviq> jibel, rather not close the top task if not all tasks are open
[19:25] <jibel> Saviq, the top task is closed when it's in the archive and there is a bug # in the changelog
[19:25] <jibel> Saviq, in which case it shouldn't be close since it'll be on the image?
[19:26] <Saviq> jibel, case in point - bug #1536383
[19:26] <Saviq> jibel, it got closed even though there's still outstanding tasks on some projects
[19:26] <Saviq> and it isn't always the case that we need/want to land altogether in one silo
[19:27] <jibel> Saviq, understood, but it seems more like a edge case than the rule, isn't it? in general when there is 'closes: ####' in the changelog it means the case is close
[19:28] <Saviq> jibel, for that particular project, not for other ones
[19:28] <Saviq> necessarily, I mean
[19:28] <robru> 7:15:42 <kgunn> trainguards just trying not to "hurry up" for QA's sake at the end of the week...so can we get silo 21 landed so we can rebuild silo 10 on top?
[19:28] <Saviq> jibel, which is why I'd check other tasks, and only close the "top" c-d-s-i task when all others are closed
[19:29] <Saviq> (automagically, that is)
[19:30] <jibel> Saviq, okay, point taken. I'll check if there are lot of cases where the top task should be closed but won't because other tasks are still open.
[19:45] <kgunn> robru: taken care of, it was usc
[19:47] <kgunn> robru: but yeah definitely wrong silo #...brain fart
[19:51] <robru> ok
[20:26] <boiko> robru: could you please trigger a rebuild of messaging-app xenial pc64el on silo 52?
[20:26] <robru> boiko: on it
[20:26] <boiko> robru: thanks!
[20:27] <robru> boiko: you're welcome!
[23:29] <robru> sil2100: you're still up?
[23:29] <sil2100> robru: yeah
[23:29] <sil2100> What's up?
[23:30] <robru> sil2100: oh, I a few hours ago I pushed a bug to production which will break silo auto-merges, I just pushed a fix now, but it won't reach production for 45 minutes. hopefully that silo you just published doesn't migrate for at least an hour or so to avoid the bug. it's a race now ;-)
[23:31] <robru> or maybe I'll get webops to roll it out faster...
[23:31] <sil2100> robru: but it's only for auto-merges for now, right?
[23:32] <sil2100> And, how does it break them: that they won't work or that they'll break trunks etc. ;p ?
[23:32] <robru> sil2100: yeah, why, is that silo only manual sources?
[23:32] <sil2100> No no, but I was just curious if we can force merge some that might seem blocked by auto-merges being down
[23:32] <robru> sil2100: the breakage is subtle, it'll probably push to trunk ok, but then it'll try to set the branch status and fail with an unhandled traceback. probably harmless actually
[23:32] <robru> sil2100: oh, no, all merging is broken
[23:33] <sil2100> Ah, ok, ACK ;) I hope proposed migration is slow today then!
[23:33] <robru> sil2100: I've got webops rolling out the fix soon
[23:33] <sil2100> \o/
[23:33] <sil2100> robru: thanks
[23:33] <robru> sil2100: heh, sorry for breaking things
[23:41] <robru> sil2100: ok, the fix is in production, hopefully it works ;-)