=== chihchun_afk is now known as chihchun [08:28] 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] oSoMoN, from the error it's a problem with the shutdown of the testbed, unrelated to the webbrowser obviously [08:35] oSoMoN, you can ping pitti he can retry the test [08:36] thanks jibel, I’ll do that [10:20] sil2100, Mirv: hey! time for another upload? [10:27] morphis: sure, in a moment though! [10:27] sil2100: ok [10:46] morphis: piiing === _salem is now known as salem_ === alan_g is now known as alan_g|lunch === chihchun is now known as chihchun_afk === alan_g|lunch is now known as alan_g [13:59] * sil2100 off to lunch [15:15] 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] oops scratch "not" [16:58] 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] excuses doesn't show anything concerning... [16:59] afaict [17:08] kgunn: $ grep-aptavail -nsPackage -Pe '^u[^-]*-s[^-]*-c[^-]*$' | sort -u | wc -l [17:08] 8 [17:08] your abbreviations are ambiguous :) [17:08] sorry unity-system-compositor [17:08] cjwatson: ^ [17:09] 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] cjwatson: hmm, so here if i do apt-cache policy unity-system-compositor, it still shows installed/available as the same? [17:10] maybe i don't know how it all works [17:11] more like...obviously i don't know how it all works :) [17:12] kgunn: publisher takes time to run [17:12] cool [17:13] right makes sense...i suspect my "apt-get update/apt-cache policy" method of checking will show it when the train does [17:15] probably rather afterwards [17:18] 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] (AIUI) === boiko__ is now known as boiko [17:26] kgunn: there, landed [17:37] ta [18:55] 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] alesage: hi, regarding silo 52, we found one problem about the confinement: reading mms group chat settings is not working [19:05] alesage: the fix is on its way, just letting you know because we will have to rebuild messaging-app [19:06] boiko ack thx [19:15] robru: nope, no silo 21 interest from me [19:17] 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] Saviq, you mean to close other tasks too? [19:24] jibel, rather not close the top task if not all tasks are open [19:25] Saviq, the top task is closed when it's in the archive and there is a bug # in the changelog [19:25] Saviq, in which case it shouldn't be close since it'll be on the image? [19:26] jibel, case in point - bug #1536383 [19:26] bug 1536383 in unity8 (Ubuntu) "Need to increase pointer speed/acceleration" [High,In progress] https://launchpad.net/bugs/1536383 [19:26] jibel, it got closed even though there's still outstanding tasks on some projects [19:26] and it isn't always the case that we need/want to land altogether in one silo [19:27] 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] jibel, for that particular project, not for other ones [19:28] necessarily, I mean [19:28] 7:15:42 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] 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] (automagically, that is) [19:30] 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] robru: taken care of, it was usc [19:47] robru: but yeah definitely wrong silo #...brain fart [19:51] ok [20:26] robru: could you please trigger a rebuild of messaging-app xenial pc64el on silo 52? [20:26] boiko: on it [20:26] robru: thanks! [20:27] boiko: you're welcome! === salem_ is now known as _salem === popey_ is now known as popey [23:29] sil2100: you're still up? [23:29] robru: yeah [23:29] What's up? [23:30] 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] or maybe I'll get webops to roll it out faster... [23:31] robru: but it's only for auto-merges for now, right? [23:32] And, how does it break them: that they won't work or that they'll break trunks etc. ;p ? [23:32] sil2100: yeah, why, is that silo only manual sources? [23:32] No no, but I was just curious if we can force merge some that might seem blocked by auto-merges being down [23:32] 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] sil2100: oh, no, all merging is broken [23:33] Ah, ok, ACK ;) I hope proposed migration is slow today then! [23:33] sil2100: I've got webops rolling out the fix soon [23:33] \o/ [23:33] robru: thanks [23:33] sil2100: heh, sorry for breaking things [23:41] sil2100: ok, the fix is in production, hopefully it works ;-) === jonas1 is now known as jgdx