[10:43] Saviq, I supposed we don't have to verify silo 48, it is xenial only, right? === _salem is now known as salem_ === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g === karni is now known as karni-lunch === karni-lunch is now known as karni [12:50] trainguards, what is happening with this silo? https://requests.ci-train.ubuntu.com/#/ticket/570 [12:51] all bug reports was marked as fix-released bug the silo still on "Proposed pocket" and the mr was not merged yet. [12:54] renatu: not all, address-book-service is still in proposed and the bug is not set to fixed http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#address-book-service [12:54] renatu: it might be stuck due to evolution-data-server transition [12:55] yeah looks like so according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt - uninstallable packages ie rebuilds needed, desktop team probably knows about it [12:57] Mirv, renatu, you should probably force merge in that case, e-d-s is in a new soname transition with poppler gnome-desktop libgtop etc and that's all blocked on a binutils issue making webkit fails to be build on arm64 [12:58] seb128: ok then [12:59] seb128, Mirv , ok thanks, I will try that [12:59] renatu: it's now up to trainguards only so that each case like this gets discussed [12:59] renatu: so I'm running it now [12:59] Mirv, thanks === alan_g is now known as alan_g|lunch [13:19] jibel, didn't know what the approach there was, if you don't verify xenial, yes, silo 48 can go [13:19] marked "Publish without QA" now [13:48] Mirv: hmm. who do we need to get to publish silo 26? [13:50] dobey: any core-dev https://launchpad.net/~ubuntu-core-dev/+members - kenvandine for example starts to be around at this time [13:50] dobey: the only change requiring core-dev rights is also in the apparmor, and done by _a core-dev_ (jamie), but it still means the silo publishing needs to be done by a core-dev [13:51] right; i just wasn't aware it was validating it at that level for landings to the overlay PPA === alan_g|lunch is now known as alan_g [14:01] yes it's the same rules for overlay nowadays === alesage_ is now known as alesage [15:40] oSoMoN: ping [15:46] robru: what is up with that one? ^ [15:47] boiko: you're not authorized because of a packaging diff [15:47] robru: ah ok, yeah, I was expecting a "packaging changes need ack" :) [15:47] robru: I'll ask kenvandine to review those [15:47] kenvandine: would you mind checking the packaging diff on silo 000? [15:47] boiko: "packaging changes requiring ack" is only shown to people who are authorized to give the ack [15:48] will do [15:48] robru: ok, it is just that the error message is not precise, as I am authorized to upload it as long as there are no packaging changes :) [15:48] kenvandine: thanks! [15:49] boiko: it's perfectly precise. you are not authorized when there are packaging changes, and there are packaging changes, therefore you are not authorized. also non-mp sources require authorization [15:51] I don't understand why this is so confusing. if you're not authorized you need to find somebody who is. [15:51] rvr, pong, sorry was in a UOS session [15:51] what’s up? [15:51] silo 6? [15:52] robru:well, as UI developer I got used to provide error messages that explicitly tell what went wrong, but doesn't matter much in this case, just wanted to check if it was just the packaging changes or something else [15:52] boiko, done [15:52] kenvandine: thanks [15:52] np [15:53] boiko: but I feel like this is being explicit, you are not authorized. it's not like the error message is "failed: 1" or something, we have seen that in the train in the past ;-) [15:53] oSoMoN: Yes [15:54] oSoMoN: First thing, Siete app doesn't turn off the screen [15:54] oSoMoN: I just open the app, without starting the exercises [15:54] rvr, let me check that [15:55] robru: maybe it was just not clear for me, but doesn't matter, I really just wanted to check what was going on [15:56] boiko: ok [15:58] rvr, siete is a pure QML app that doesn’t embed a webview, and it has ScreenSaver { screenSaverEnabled: false } in its main QML file [15:59] rvr, the fix that’s in oxide only affects browser and webapps [15:59] oSoMoN: Yeah, I was confused, but there was a change related to this bug https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1502145 [15:59] Ubuntu bug 1502145 in Canonical System Image "Apps can keep screen lit permanently" [Critical,Confirmed] [16:01] rvr, the use case that is fixed in oxide is that one: https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1502145/comments/14 [16:01] Ubuntu bug 1502145 in Canonical System Image "Apps can keep screen lit permanently" [Critical,Confirmed] [16:03] oSoMoN: Ah, checking [16:06] oSoMoN: Ok, works fine [16:07] oSoMoN: I was checking the fix for volume while loading. It mostly works, but sometimes the browser freezes and starts playing the music, but doesn't show the video for a while [16:09] rvr, the volume thing is a red herring, the real issue was playing a youtube video from a google search result page [16:10] oSoMoN: Yes, the video is played [16:10] rvr, that’s enough to validate the fix then :) [16:13] oSoMoN: Is there a test case for this? https://bugs.launchpad.net/oxide/+bug/1488102 [16:13] Ubuntu bug 1488102 in Canonical System Image "Soundcloud not working with the media-hub integration" [High,In progress] [16:15] oSoMoN: Soundcloud tracks play fine in the browser [16:19] rvr, what’s interesting to test is the soundcloud webapp (in the store, by alex abreu) [16:19] oSoMoN: Ok, let me check [16:20] rvr, it should continue playing while in the background, and it should also allow seeking in the track [16:21] oSoMoN: what's the name of the app? [16:21] There are not results for "souncloud" [16:21] meh [16:21] soun*d*cloud :) [16:21] Bad typing [16:21] Thanks [16:23] oSoMoN: Cool, it plays on the background. Although it cannot be paused/played with the MPRIS controls in the sound indicator. [16:24] rvr, that’s probably a bug elsewhere in the stack, maybe in the sound indicator? [16:25] rvr, I gotta go offline very soon, I’ll be back online in the evening, in the meantime if you have questions about silo 6 dbarth should be able to help [16:27] oSoMoN: Cool === ara is now known as ara_afk === ara_afk is now known as ara [16:39] kenvandine: can you publish silo 26 please? [16:40] sil2100: were you trying to get cordev btw? [16:40] dobey, i'll look [16:40] kenvandine: it has apparmor-easyprof-ubuntu in it, which requires coredev to publish it seems. thanks [16:41] dobey: yeah, will re-try shortly [16:41] there are several packaging changes though [16:41] kenvandine: to? [16:42] pay-service? [16:42] yeah [16:42] and ubuntu-push [16:42] o/ [16:42] did a core-dev review those already? [16:42] pay-service was rewritten in go [16:42] (for silo 6 and what oSoMon said) [16:43] kenvandine: i haven't pinged anyone to ack the packaging changes. you can do that too if it's needed :) [16:43] ok [16:43] oh yeah, the packaging changes in ubuntu-push are to make it build with gccgo [16:43] those like simple [16:43] anything up with the train? [16:43] pay-service is a much bigger change ;) [16:43] cant log int [16:43] yeah, pay-service is mostly a lot of deps changes [16:44] dobey, i need to pop out for lunch, i'll review when i get back [16:44] because of rewriting it in go [16:44] understood [16:44] kenvandine: ok, i'm heading out to lunch too :) [16:44] trainguards: I can't log into https://requests.ci-train.ubuntu.com/ -- I'm never taken to sso [16:45] jgdx: works for me, just tested it right now. can you sign in to other SSO sites? [16:45] robru, /me tries [16:46] robru, okay, now it works. Don't I feel stupid [16:46] jgdx: hehe, no worries === lan3y is now known as Laney === kyrofa_ is now known as kyrofa [17:02] jibel: we'll be ther ein a minute [17:02] rvr, davmor2: ^ [17:03] robru: why telephony-service is listed as "Not considered" in the excuses page? [17:03] robru: is it related to the unity8 tests that are running? [17:03] Probably [17:04] jibel: we're there === ev_ is now known as ev [17:05] boiko: yeah, the autopkgtests are still running [17:05] Once those are done it might become a Valid Candidate [17:07] sil2100: cool! thanks === balloons is now known as Guest9062 === alan_g is now known as alan_g|EOD === Guest9062 is now known as balloons === ljp is now known as lpotter [18:58] dobey, why change the dir for pay-service? [18:58] -usr/lib/*/pay-service/pay-service [18:58] +usr/lib/*/pay-service/pay-service-2 [18:59] it's not a versioned lib [19:00] kenvandine: huh? the dir isn't changed [19:00] kenvandine: that's the binary name [19:01] oh, well why change the binary name? [19:01] kenvandine: i didn't change it back yet. we started doing some of this work in wily a couple months ago. it currently has both versions in wily (but the go version is incomplete so not really used there) [19:02] (and we don't ship wily phones anyway) [19:06] dobey, so it was renamed for wily? but it doesn't need to be? [19:07] kenvandine: well, really it doesn't matter what the name is. it's a dbus activated service, not something people run by hand [19:07] dobey, understood [19:08] just being picky :) [19:08] but yes, it was named -2 for the time being, so we could keep both versions building/working [19:08] dobey, i started out being concerned that it was expected to be parallel installed, etc [19:08] nah, nothing that complex :) [19:08] ok [19:08] it's fine then [19:08] both versions are in the same package in wily === jdstrand_ is now known as jdstrand === salem_ is now known as _salem [21:25] trainguards: silo 6 has been validated by QA and is ready for landing, it’s targetted at vivid only but there are leftover wily packages in the silo, is that gonna be a problem? [21:30] oSoMoN: no, packages in the ppa for a different series than what bileto is configured for will be ignored. that's a relatively new change, before a few weeks ago, any packages in a series other than what was configured in bileto would be copied to overlay ppa. [21:38] robru, excellent, so I’ll trigger publication [21:38] oSoMoN: be my guest! [21:38] robru, did I ever thank you for your work on bileto? [21:38] in any case, thanks again :) [21:39] oSoMoN: haha probably, I've come a long way since pyexiv huh? ;-) [21:39] so have I :) [21:40] oSoMoN: yeah! [21:41] oSoMoN: oh god, it's oxide. let's see if it diffs correctly ;-) [21:41] oSoMoN: will probably take 15 minutes to diff [21:42] oSoMoN: ah the build job has a successful diff. crazy how hard it's been to keep oxide diffing consistently. [22:09] mterry, kenvandine: I need a core-dev to upload oxide to the overlay PPA (silo 6), could one of you guys handle it? [22:11] oSoMoN, looking [22:13] oSoMoN, do you know if there are packaging changes? [22:13] it'll take a while to get the diff here :) [22:14] kenvandine, no packaging changes [22:14] cool [22:14] i clicked publish [22:14] :) [22:48] kenvandine, thanks! [22:51] robru, huh, oxide went to the vivid archive (and is now sitting in the unapproved queue) instead of the overlay PPA [22:51] I guess the PPA field of the request wasn’t set [22:51] oSoMoN: correct [22:51] robru, can we undo this, and publish again to the PPA? [22:52] oSoMoN: publishing to overlay ppa is only automatic for duals. [22:52] oSoMoN: you'll have to ask in #ubuntu-release to have the -proposed version deleted [22:52] ugh [22:52] need me to publish again? [22:52] not very consistent, but it makes sense [22:52] oSoMoN: but if you change the ticket then kenvandine can publish again [22:52] ok, let me do those two things [22:53] oSoMoN, i need to step away for a bit... but i can hang out long enough to click publish again [22:53] oSoMoN: yeah it's tricky. duals have to be more automatic because two different packages go to two different places. if you're just publishing to vivid though, it's possible that you really do want to SRU into vivid proper, so we can't just say "vivid is always overlay" [22:53] kenvandine, I updated the ticket, can you publish again? [22:53] oSoMoN, done! [22:53] now i need to run... i'll check in later [22:53] kenvandine: thanks [22:53] oSoMoN, but hopefully you'll be gone by then... it's late for you! [22:53] robru, yeah that makes sense, I should have checked the request first (was initially filed by dbarth) [22:54] kenvandine, thanks! that’s ok, my daughter is sick so I’m not gonna sleep much anyway… [22:54] oSoMoN: please file a bug against lp:bileto that says something like "display giant warning when dest ppa field is blank" [22:54] robru, will do [22:55] oSoMoN: thanks [23:02] robru, https://bugs.launchpad.net/bileto/+bug/1513649 [23:02] Ubuntu bug 1513649 in Bileto "Warn when publishing to vivid and destination PPA field is left blank" [Undecided,New] [23:12] oSoMoN: thanks [23:20] robru, what does "Migration: oxide-qt is in the silo (not yet published)." mean? I’m not seeing oxide-qt 1.10.4-0ubuntu1~overlay1 in the overlay PPA [23:21] oSoMoN: publish failed because kenvandine forgot to check ACK_PACKAGING on the second run [23:21] darn, publishing this silo is like the neverending story [23:21] kenvandine, still around? [23:22] oSoMoN: it seems that there are packaging changes vs. overlay ppa even if there weren't for vivid SRU [23:22] which strikes me as a bit odd... [23:26] oSoMoN: https://ci-train.ubuntu.com/job/ubuntu-landing-006-2-publish/117/artifact/oxide-qt_packaging_changes.diff/*view*/ does this look right to you? oxide 1.9 -> 1.10? and stuff vendored in three levels deep? [23:27] checking [23:29] robru, aha, those packaging changes are inside the chromium source tree, they could probably be excluded when creating the source tarball, but they are meaningless in any case [23:30] and unused [23:30] the code that generates the diff and checks for packaging changes should probably discard changes to directories named "debian/" if they are not at the root of the tree [23:32] oSoMoN: it's horrifying that chromium source tree contains a debian package. [23:32] agreed [23:33] the chromium source tree contains the entire known universe, and more [23:33] oSoMoN: http://e.lvme.me/pzv5j7l.jpg [23:33] :) [23:34] I’m gonna go get some rest if I can, hopefully kenvandine can publish again when he’s back [23:35] ’night all