[01:37] robru: ping [02:36] michi__: hey what's up? === chihchun_afk is now known as chihchun [02:56] robru: Thanks for your reply, all sorted out. (Sorry, didn't see your message earlier). === chihchun is now known as chihchun_afk [05:00] robru: I really like the change in color scheme when a silo is dirty. Thanks for that, nice touch! [05:42] michi: you're welcome === chihchun_afk is now known as chihchun [07:53] robru, hi, would it be possible to clean the wily packages in silo 13? [07:53] abeato: sure one sec [07:53] robru, ok, thanks [07:54] abeato: done! you're welcome [07:54] great [08:21] robru, hey, can I reset the dirty flag somehow https://requests.ci-train.ubuntu.com/#/ticket/445 ? we've reverted the commit that caused it to go dirty (was a trunk merge anyway) [08:21] robru, otherwise, will this cause us trouble on publish? [08:21] Saviq: hmmm [08:23] Saviq: the file that tracks commit IDs would indeed match again if you reverted the commit, but the dirty flag can officially only be removed by doing an actual rebuild. however I can go in and surgically remove the flag from the silo [08:25] robru, no need if it will allow us to publish [08:26] Saviq: I cleared the flag manually and I'm doing a WATCH_ONLY build to make sure that the commits all match expectations [08:26] robru, tried a watch_only yesterday and it didn't work, it was, though, before the revert [08:27] Saviq: yes, but I waved my magic wand prior to running WATCH_ONLY though. [08:27] robru, ah ;) [08:27] robru, I think it'd make sense for watch_only to re-check the commit ids [08:28] Saviq: yeah this needs a bit of work. the problem is that dirtiness can be created either by new commits or by other silos being published and it's not currently possible to tell which is which. [08:28] robru, ack [08:28] Saviq: I'll file a bug for now [08:30] * Saviq waiting for brendand to rise from the dead and give some feedback on silo 22, shame it won't merge/clean until migration for xenial is on anyway... [08:31] sil2100: ok, we were here :) [08:33] Saviq: here you go https://bugs.launchpad.net/cupstream2distro/+bug/1509250 [08:33] Launchpad bug 1509250 in CI Train [cu2d] "Allow people to uncommit new commits." [Medium,Triaged] [09:34] brendand, morning! any news on silo 22, you've been awfully quiet :) [09:36] Saviq, i spoke to kgunn yesterday. i had some unrelated issues, then found out i had the wrong citrain version [09:36] Saviq, testing it now [09:46] ack [09:47] brendand, no pressure at this point, as we're blocked by lack of proposed migration for xenial [09:47] +anyway === oSoMoN_ is now known as oSoMoN [10:00] ubuntu-qa: is silo 16 on someone’s plate? ToyKeeper wasn’t able to confirm the desktop fixes === lan3y is now known as Laney === rsalveti_ is now known as rsalveti === plars_ is now known as plars [10:24] rvr, thanks for the comment. One of the fixes in silo 16 is desktop-specific (fixes a crash). Of course I verified it myself, is that enough? If so can you/someone please approve the silo? [10:25] the fix in question is for bug #1508054 [10:25] bug 1508054 in webbrowser-app (Ubuntu) "[desktop] Crashes on startup" [Critical,In progress] https://launchpad.net/bugs/1508054 [10:35] oSoMoN: Yes, I think so [10:51] oSoMoN_: Silo 16 approved === davmor2_ is now known as davmor2 [11:04] trainguards: when building against xenius+vivid, i get that pep8 isn't installed: https://launchpadlibrarian.net/222250573/buildlog_ubuntu-xenial-amd64.ubuntu-system-settings_0.3%2B16.04.20151023-0ubuntu1_BUILDING.txt.gz [11:05] rvr, thanks [11:06] trainguards: sorry, it's not installable, rather. [11:09] coincidentally I was just upgrading my chroot:s and lxc:s to xenial [11:09] jgdx: it says to me that pep8 depends on python3-pep that is no longer available, so it errors out [11:10] can I land using vivid+wily? [11:10] Mirv: jgdx looks like there's already a fix in xenial-proposed, not sure when that'll land [11:10] jgdx: well, it's fixed actually in this https://launchpad.net/ubuntu/+source/pep8/1.6.2-0.1ubuntu1 that is in xenial-proposed, and our PPA:s should be using prpoposed [11:10] jgdx: no, wily is no more, other than SRU:s [11:10] robru: shouldn't our PPA:s build with proposed anyway? [11:10] (weird way of adding plural to these things, Mirv :P) [11:10] but it might be xenial is not completely "running" yet [11:11] Mirv: hmm, I think so... [11:11] Mirv, is there a way to know for sure if that's fix is in? [11:11] Maybe let me know/enable me to know so I can start another build? [11:12] robru: hey Mr. 4am, haven't we talked about this? [11:12] jgdx: what silo? [11:12] Mirv: shush you [11:12] The builders are probably not using -proposed [11:13] ;-) [11:13] I mean, the builder build-envs, as it seems to die out on very early stages of the build [11:13] robru, the silo's under your pillow! Go get it ;P [11:13] robru, 39 [11:13] 039 it'd seem [11:13] it has proposed enabled [11:13] We might need to wait for it to migrate [11:16] Hmm I don't have my lp login on this tablet... [11:16] OK I'll let you guys figure it out ;-) [11:17] Goodnight [11:21] Goodnight [11:21] I didn't create a xenial chroot yet as I know it's a bit early yet [11:33] Saviq, can you clarify how to test this ? https://bugs.launchpad.net/ubuntu-translations/+bug/1372061 [11:33] Launchpad bug 1372061 in unity8 (Ubuntu) "SMS notification: time format not translatable" [High,In progress] [11:33] Saviq, the notifications indicator no longer seems to use date stamps [11:33] Saviq, it just says x minutes/hours ago [11:58] brendand, yeah, we've just deleted a bunch of code and reverted to what SDK now provides === alan_g is now known as alan_g|lunch [11:58] brendand, so if it looks right... it's right [11:58] dednick, unless you have an idea to test ↑↑ [11:59] Saviq: no, it should just be the same [12:02] brendand, basically, the fix comprised of implementing The Right Thing™ in the UITK, now we've switched to using it - if it's in the UITK, it has to be good, right? :) [12:03] and the translation comes from there as well [12:03] Saviq, yeah it seems good [12:03] Saviq, i had to adjust the clock manually to make it show a date === popey_ is now known as popey [12:06] ack === _salem is now known as salem_ [12:44] kenvandine, hey, would you mind acking the packaging changes in silo 16? https://ci-train.ubuntu.com/job/ubuntu-landing-016-2-publish/121/artifact/webbrowser-app_packaging_changes.diff [12:45] sure [12:45] +1 from me [12:45] oSoMoN, want me to publish it? [12:46] kenvandine, if you don’t mind [12:47] oSoMoN, published [12:47] thanks! [12:47] np === alan_g|lunch is now known as alan_g [13:01] Mirv, how we doing wrt the pep8 package? [13:11] jgdx: please join #ubuntu-devel , there might be related discussion soon [13:12] kenvandine, renatu : re: silo 19, does this need to be dual landing? I wasn't sure whether buteo was in wily or not and it's status in x [13:13] bfiller, i think it's in xenial now [13:13] so dual landing would be xenial+vivid [13:13] so should be fine [13:13] kenvandine: ok thanks [13:13] np [13:15] jgdx: I just figured something when I was about to ask there... just a moment [13:16] sil2100: FYI bug #1509356 [13:16] bug 1509356 in pep8 (Ubuntu) "pep8 depends on python3-pep, not python3-pep8" [Undecided,New] https://launchpad.net/bugs/1509356 [13:17] I figured out when I stared at the diff again.. the builders _are_ using proposed correctly, and that's the problem [13:39] dbarth: Approving silo 56 [13:39] trainguards: is it expected that packages for the X series are landing in the overlay PPA, not in the distro? [13:40] oSoMoN: that's an error in ticket configuration if that happens [13:41] the target PPA field should be empty [13:41] Mirv, well I had silo 16 that was awaiting QA validation before robru enabled X in bileto, so I asked him to manually binary-copy the wily packages to retarget xenial in the silo, and I was expecting they would land in the correct place [13:42] Mirv, it was a dual silo, initially targetting vivid and wily, then modified to target vivid and xenial [13:42] oSoMoN: the binary-copy is needed, but so is ensuring the PPA field is empty so it does the normal dual thing ie vivid to PPA, devel to archive [13:42] oSoMoN: so yes https://requests.ci-train.ubuntu.com/#/ticket/547 had the field [13:43] oSoMoN: we'd need a core-dev to copy it from the overlay to archive and then we can delete the overlay version [13:43] ah, I didn’t know that, I thought the field was needed for the vivid packages to go to the PPA [13:43] kenvandine, could you do that for us? ^^ [13:43] oSoMoN: no, the behavior is "known" but I agree not obvious. [13:43] ah, right it's the time when Ken is around :) [13:48] oSoMoN, which silo? [13:52] kenvandine, the one you published an hour ago :) I didn’t know but it was targetted at the overlay PPA for the X series, so we need to copy it from the silo to the distro proper, and delete the X packages in the overlay PPA [13:53] kenvandine: so copy-package webbrowser-app from overlay xenial to archive xenial [13:53] s/archive xenial/archive xenial-proposed/ [13:53] ah [13:56] rvr: \o/ thanks [14:00] oSoMoN, Mirv: done [14:01] Mirv, should i delete the xenial build from the ppa? [14:02] kenvandine, thanks! [14:14] kenvandine: thanks! and thanks for also deleting it from the ppa. [14:14] np [14:15] see you in a week, everyone [14:17] robru: sil2100: the 024 xenial is still in abyss, not sure what happened, rsync seems correct [14:22] Mirv: have a nice holiday! [14:29] sil2100: thanks! === salem_ is now known as _salem === _salem is now known as salem_ [14:56] Saviq, all clear [14:59] brendand, \o/ [15:00] kgunn, greyback ↑ [15:00] trainguards, we'll need to transition silo 22 to xenial, please [15:00] greatness [15:01] * kgunn sheds a tear and whispers "good bye" silo0 [15:01] right :D [15:01] it took us under a year to go from silo0 to release :D [15:03] hmmmm [15:03] Saviq: ok, performing the binary package copy [15:03] Saviq: kgunn woooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo [15:03] oh if only I didn't have to drive now [15:06] Saviq: has it really been a year? [15:08] greyback: almost...10 mo for sure [15:08] almost like a baby [15:16] greyback, MWC last year [15:16] erm *this* year [15:16] blimey [15:56] bfiller, Kaleo ^ camera app approved you can publish. It won't break on devices running stable? [15:57] jibel: it shouldn't but we'll test, there is problems with that silo though won't build on xenial [15:57] bfiller, stable has 1.3 right? [15:57] Kaleo: yes it does [15:57] cool [15:58] bfiller, I'm sanity testing on stable [15:58] Kaleo, it does, it shouldn't be a problem, but I just want ot make sure [15:58] Kaleo, jibel: we need to get that silo built correctly first then we can publish the deb and click [15:59] Kaleo filed a bug on it already https://bugs.launchpad.net/ubuntu/+source/python-flake8/+bug/1509396 [15:59] Launchpad bug 1509396 in python-flake8 (Ubuntu) "Missing dependency on python-setuptools" [High,New] [16:17] Kaleo, bfiller it's fine on stable too === alan_g is now known as alan_g|EOW [17:11] trainguards: is it possible to land in xenial via train yet? [17:11] dobey: yes [17:12] awesome [18:18] barry, hey, what's the plan for ota versioning from s-i's end? [18:19] jgdx: from client's end, nothing once 3.0.2 lands. everything needed is already supported there. sil2100 was working on server support iirc [18:20] Yes, it's in the works now [18:20] barry, what are the eta for the former? [18:20] is [18:20] I would say I should be done by feature freeze [18:20] sil2100, really. Okay [18:20] Monday I hope to give barry something to review [18:21] awesome [18:21] could we share a silo? [18:21] i think it's waiting for qa sign-off. rvr was doing qa [18:21] okay, great [18:22] I'll make one now then [18:22] barry: I approved silo 23 yesterday [18:22] rvr: rock on! i was just going to ask since i didn't see it on requests [18:22] rvr: is there anything more you need from me for that? [18:22] QA Signoff Status QA Granted [18:22] Status Landed [18:22] barry: Seems done [18:23] \o/ [18:23] thanks [18:23] Yeah, saw it in the vivid-overlay changes [18:23] sil2100, do you know anything re: the pep8 situation? Any change? [18:24] jgdx: packages still in -proposed [18:25] jgdx: I saw some autopkgtest regressions, but those should be resolved soon with a new upload of pyflakes [18:25] jgdx: all caused by some package renames [18:25] sil2100, okay, will it be resolved before tuesday? [18:26] I'm sure it would, if not we'll consider giving a bit more time for landers that were blocked because of that [18:26] jgdx: silo 39 has built now [18:27] bfiller, great [18:27] jgdx: that issue was resolved apparently [18:27] huh okay [18:27] seb128 told me doko fixed it [18:27] rvr: how's silo 11 testing coming? [18:29] bfiller: Hope to finish soon [18:34] sil2100, could you given an example of what the tag key would contain as value? [18:34] sil2100, re: ota [18:35] jgdx: it will append something like this to the version_detail - "tag=OTA-6", so e.g. "version_detail": "ubuntu=20151015,device=20150911,custom=mako-1.1,version=26,tag=OTA-6" [18:35] sil2100, +1 [18:36] jgdx: I can't guarantee the ordering though, so don't take that for granted of course [18:37] sil2100, sure thing. [18:38] rvr: how is silo 11 going? === boiko_ is now known as boiko [18:44] boiko: I'm checking an issue with the messages scope [18:45] I've received some messages and the scope is blank [18:46] rvr: ah yes, those are not really landing together with the silo, so, bugs in there should not block the landing really, I still have to fix a couple issues bfiller found in the new scopes implementation [18:46] boiko: I see === fginther` is now known as fginther [19:09] boiko: bfiller: Approving silo 11 [19:10] rvr: great! thanks! [19:12] rvr: ty [19:12] kenvandine: mind publishing silo 11? [19:14] sure [19:15] bfiller, that's alot of branches :) [19:15] bfiller, so that's set to "dual" [19:15] and built for wily and vivid [19:16] kenvandine: crap [19:16] so what does that mean? [19:16] already qa granted [19:16] i can do the same thing i did last night [19:17] kenvandine: sorry [19:18] kenvandine: silo has been around for a long time :) [19:22] kenvandine: Silo 39 is targeted for xenial+vivid [19:22] rvr, i'm doing 11 [19:22] what's wrong with 39? [19:22] kenvandine: Shouldn't it land directly, or it is incorrectly targeted? [19:23] kenvandine: https://requests.ci-train.ubuntu.com/#/ticket/546 [19:23] it should be xenial+vivid [19:23] kenvandine: Does it mean dual land? [19:23] yes [19:23] Ah, I see, thanks [19:23] we don't land for wily anymore [19:23] np [19:48] barry, 3.0.2 is deprecating or removing Info altogether? === chihchun is now known as chihchun_afk [20:05] jgdx: silently deprecated :) [20:06] barry, :))) very good [20:17] robru, ping [20:25] alexabreu: pong [20:26] robru, sorry again on that copyright issue w/ jenkins, this is insane, ... I added the headers but ... https://jenkins.qa.ubuntu.com/job/unity-js-scopes-wily-amd64-ci/37/console [20:26] robru, I am at a loss [20:26] robru, the copyright seems fine http://bazaar.launchpad.net/~abreu-alexandre/unity-js-scopes/doc/view/head:/debian/copyright [20:27] robru, & the targetted files have headers e.g. http://bazaar.launchpad.net/~abreu-alexandre/unity-js-scopes/doc/view/head:/doc/docbuild/api.js [20:27] I must be missing something [20:28] alexabreu: that's a different error though isn't it? [20:28] alexabreu: didn't it say before it couldn't find the license? seems like now it says the license is not an acceptable license. [20:29] robru, yes, I progressed [20:29] from unknown to this [20:29] so it picks it up [20:30] alexabreu: as I said I'm not familiar with this copyright checker you're using here. I'm not sure who would know more about this. [20:31] ok [20:32] alexabreu: maybe ask slangasek [20:33] trainguards: May I have a silo assigned for https://requests.ci-train.ubuntu.com/#/ticket/561 please? [20:34] ChrisTownsend: you have the ability to assign your own these days [20:34] robru: Oh wow, I did not know that (obviously):) [20:34] robru: Thanks [20:34] ChrisTownsend: you're welcome. feel free to ask for help if something goes wrong but it should be pretty smooth [20:35] robru: Thanks again [20:35] you're welcome again [20:37] robru: I assume we do not have the ability to publish though, right? [20:38] alexabreu, any idea (see my comments above) ^ [20:38] ChrisTownsend: you can publish as long as there's no changes under debian/ and all your packages are prepared by merges (you can't publish manual sources) [20:39] robru: Ok. If there are changes in debian/ do we ping a trainguard or is it queued up for review? [20:40] ChrisTownsend: you'd have to ping either a core dev or a MOTU depending on if your package is in main or universe. [20:40] robru: Ok, thanks for the lessons:) [20:40] ChrisTownsend: you're welcome [21:20] robru, alexabreu: sorry, I don't know anything about this license checker either. But it appears to be getting called as part of pbuilder itself? [21:20] /var/cache/pbuilder/build//24503/tmp/hooks/A10checklicenseheaders doesn't look like a package build directory [21:27] slangasek: yes it does? build/nnnn [21:27] really? that's a strange convention [21:28] slangasek: i think that's a cowbuilderism [21:28] I rest my case [21:29] slangasek: alexabreu no wait, that log is from s-jenkins, not train Jenkins [21:29] I officially have no idea what's going on there [21:30] alexabreu: you should really poke cihelp for this [21:32] alexabreu, looking [21:33] fginther: thanks [21:39] slangasek: actually though I thought you might be more knowledgable about policy, eg, is there some reason that "BSD 3 clause" wouldn't be acceptable in ubuntu or something. [21:39] robru: no, that's perfectly acceptable in Ubuntu, but it's possible this is a license checker that tries to verify that debian/copyright matches the source [21:40] slangasek: k, I dunno then. the headers and the debian/copyright appear to match to me [21:40] thanks [21:41] * robru --> lunch [21:47] robru, this is just a case of using an overly restrictive license check. There's nothing really wrong with the files [21:47] robru, in case you were curious [22:11] alexabreu, should be fixed now, and your MP is being re-run. [22:16] fginther: haha, thanks. where's the documentation on that license checker? === salem_ is now known as _salem