[08:56] <alf_> Hi! We want to disable s-jenkins jobs for Mir (since we are ready to fully transition to Mir Jenkaas). Any idea who can do this?
[09:11] <robru> alf_: i guess you need fginther if you're not able to delete the jobs yourself.
[09:12] <alf_> robru: ack, thanks
[09:14] <sil2100> alf_: I can try delete that job for you in a moment
[09:15] <alf_> sil2100: ah, great, perhaps better to just disable than delete? I don't mind either way, do what's easiest/best for you. We need to delete/disable both mir-ci and mir-autolanding, or perhaps remove the jobs that trigger them.
[09:16] <sil2100> alf_: ok, sure
[09:16] <sil2100> Just need to finish the OTA-9.1 stuff
[09:17] <alf_> sil2100: np
[09:24] <Saviq> sil2100, when you're at, I've a few to disable, too
[09:43] <sil2100> alf_: mir-ci is currently running - should I disable it nevertheless?
[09:45] <sil2100> alf_: maybe you want to disable all mir jobs in s-jenkins?
[09:48] <sil2100> Saviq: which jobs would you need disabling?
[09:51] <Saviq> sil2100, disabling the triggers is probably enough in our case - for qtmir, qtubuntu, unity-api, unity-notifications atm
[09:51] <Saviq> unity8 and ubuntu-settings-components to follow soon
[10:11] <alf_> sil2100: mir-ci and mir-autolanding are the top level jobs, so disabling them essentially disables everything (I think), feel free to disable everything mir related though
[10:16] <dbarth_> hey there; i can't remember if it's normal or not, but i don't have merge/clean rights to finalize https://requests.ci-train.ubuntu.com/#/ticket/976 now that it has been approved
[10:16] <dbarth_> should i request that auth. level, or is that and automated process now?
[10:17] <dbarth_> (just want to avoid keeping the burden on trainguards to clean up our landings)
[10:17] <sil2100> dbarth_: it will auto-clean itself once the xenial landing goes out of proposed
[10:21] <Saviq> sil2100, can you please restart https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+build/9055044 - not sure what the failure here was ??
[10:21] <sil2100> Saviq: restarted
[10:21] <Saviq> sil2100, also, if you could please copy xenial oxide-qt from ppa:saviq/train to silo 10
[10:23] <alf_> sil2100: also, if mir-ci or mir-autolanding are currently running feel free to stop them
[10:24] <sil2100> Saviq: copied
[10:24] <sil2100> alf_: ok
[10:24] <sil2100> alf_, Saviq: disabled the jobs (or at least most of them)
[10:24] <abeato> sil2100, would it be possible to publish https://requests.ci-train.ubuntu.com/#/ticket/1027 ?
[10:25] <Saviq> sil2100, thanks
[10:26] <sil2100> abeato: ah, hm, one thing that worried me in this silo: this fix is only made for vivid, didn't see the same thing for xenial (at least not obviously)
[10:26] <abeato> sil2100, there is a patch attached to https://bugs.launchpad.net/canonical-devices-system-image/+bug/1526264 , I am not even sure we can land ntp in xenial using citrain
[10:27] <abeato> sil2100, I was following the sponsor ubuntu thing for landing in xenail
[10:27] <abeato> sil2100, but if you prefer I can get a silo for xenial
[10:27] <sil2100> abeato: ok, let's do it like this, in a moment I'll check it and publish for vivid + sponsor for xenial
[10:27] <abeato> sil2100, somebody else will have to upload anyway  :)
[10:28] <sil2100> abeato: we can use silos for ntp too, but it's not necessary ;)
[10:28] <sil2100> Anyway, on it in a minute
[10:28] <abeato> sil2100, awesome, thanks :)
[10:32] <Saviq> sil2100, did you see my question yesterday about why the default rc-proposed channel is hidden: true?
[10:34] <sil2100> Saviq: I guess I missed it - not sure, I suppose it was like that when slangasek set it up
[10:34] <sil2100> Saviq: strangely bq-aquaris.en is not
[10:34] <sil2100> Anyway, I guess we need to decide one way or another - either hide all rc-propsoed channels (not to tempt users to use those) or make all of them visible
[10:35] <alf_> sil2100: thanks!
[10:38] <Saviq> sil2100, well, even devel-proposed channels are not hidden
[10:39] <Saviq> sil2100, and TBH only people that ~know what they're doing will ever see the list of channels, so IMO we should show all those that are "working"
[10:42] <Saviq> it is just confusing now when you go u-d-f --channels and rc-proposed isn't there ;)
[10:44] <sil2100> Agreed ;)
[10:44] <sil2100> Let me clean that up later today
[10:57] <Mirv> sil2100: abeato asked yesterday publishing https://requests.ci-train.ubuntu.com/#/ticket/1027 but it's a main package, can you check it?
[10:58] <sil2100> Mirv: yes, it's on my plate :)
[11:16] <sil2100> abeato: did you forward that upstream? I don't see the change in the upstream branch for ntp
[11:17] <abeato> sil2100, http://bugs.ntp.org/show_bug.cgi?id=3023
[11:17] <sil2100> Excellent
[11:23] <abeato> \o/
[12:07] <bzoltan> jibel: hi, I have a new UITK in the silo50. All the tests are good. But the s390x build on xenial fails... would it be possible to take the silo on the QA queue while I try to figure about the s390x xenial build issue?
[12:19] <jibel> bzoltan, the queue is quite long, you have time to figure it out before we can take it. Once it's ready we can always put it at the top of the queue
[12:36] <bzoltan> jibel: I would be happy to land this UITK on the Overlay PPA as soon as technically possible, so applications will have time to adopt if they need to. Some applications might use colors in a wrong way. AP testing does not pop these color issues out.
[12:37] <bzoltan> jibel: note that the build issue is a xenial specific one.. so I could simple remove the xenial target from the silo too :)
[12:38] <Saviq> sil2100, ubuntu-settings-components jobs can be disabled on s-jenkins now, too, thanks
[12:41] <jibel> bzoltan, I understand, OTOH pushing packages without a good understanding what is really going on potentially results in situations difficult to untangle
[12:43] <jibel> bzoltan, you can of course land without xenial but I wouldn't advise it, we'll have to reconcile vivid and xenial at some point and doing so will make the work more painful.
[12:43] <bzoltan> jibel:  it  took a month to get this silo in shape :) so i know something about pain
[12:44] <bzoltan> jibel:  my proposal is to get this UITK in the hands of the app developers as soon as possible.. because delaying the UITK landing will increase the risk of some magical breakage in apps.
[12:45] <bzoltan> jibel:  earlier apps adopt easier it gets... and to be frank :) the s390x build is not exactly something what should hold us back IMO
[12:46] <bzoltan> jibel: specially that I have no access to s390x hw and we have no internal competence on what that hack is going on there
[12:46] <jibel> bzoltan, it's a supported arch
[12:46] <bzoltan> jibel: I know
[12:47] <bzoltan> jibel: I am just more worries about the Overlay landing than about Xenial s390x
[16:35] <rvr> renatu: ping
[17:16] <Saviq> robru, hey, how does train find out if a package is published in the PPA? I've seen it a few times now that bileto said something was built, but it wasn't actually published for another 10 or 15 mins
[17:23] <kgunn> sil2100: can you please help anpok get a new android release landed? he's got a reviewed/approved bug fix for ubuntu emulator...
[17:23] <kgunn> no idea how to land it
[17:27] <anpok> sil2100: https://code-review.phablet.ubuntu.com/#/c/431/
[18:07] <cjwatson> Saviq: LP publication status routinely lags behind the files actually hitting disk for about that length of time; but for many purposes the important thing is that the publication is committed
[18:09] <Saviq> cjwatson, yeah, I thought train was actually checking Packages to confirm whether it's published or not
[18:18] <cjwatson> Saviq: I expect it's using the LP API
[18:20] <robru> Saviq: cjwatson: yes it uses the api. It does download the package index file but only britney inspects that
[19:04] <renatu> rvr, pong
[19:31] <slangasek> sil2100, Saviq: because -proposed channels are not meant to be dogfooded by end users, and we don't want a huge list of channels in the ubuntu-device-flash output
[19:35] <rvr> renatu: Hi approved 29, but I found a couple of issues
[19:35] <rvr> renatu: https://bugs.launchpad.net/address-book-app/+bug/1549362
[19:35] <rvr> renatu: https://bugs.launchpad.net/ubuntu/+source/address-book-app/+bug/1549352
[19:36] <rvr> renatu: https://bugs.launchpad.net/ubuntu/+source/address-book-app/+bug/1549349
[19:36] <rvr> renatu: I think the template may need an update, because I found other strings not localized
[19:54] <renatu> rvr, thanks
[19:55] <renatu> rvr, I changed the bug #1549362 to affect dialer app, since this is a bug on the dialer not in ab
[19:55] <renatu> boiko, could you confirm that ^^
[20:09] <renatu> rvr, pot file updated for address-book-app
[21:06] <boiko> renatu: let me check
[21:20] <karni> davmor2: around :)?
[21:21] <boiko> renatu: I can confirm the bug, there is no back button there anymore
[21:44] <dobey> ToyKeeper: hi. are you around yet?
[21:47] <ToyKeeper> dobey: Hi, sorry, have been stuck on other tasks but I think that's finally done now.
[21:48] <ToyKeeper> I've been using the fake card / fake account, but they're old and might need to be reconfigured.
[21:49] <dobey> ToyKeeper: ah yeah, the staging server automatically deactivates cards after some time, so you likely need to add a new one. i think your "pay-ui sits at loading forever" might be caused by that
[21:50] <dobey> there might be an existing bug or two related to the getting stuck at loading
[21:52] <dobey> ToyKeeper: i had to rebuild ubuntu-system-settings in that silo yesterday, because of another silo having landed; in case you need to re-install stuff
[21:53] <ToyKeeper> I figured I needed to reinstall anyway, so I can use a new base image.
[21:54] <dobey> ToyKeeper: can you test now? or how soon? it's near my end of day, but i can stick around to answer questions or help you understand so we can get this landed.
[22:18] <bregma> trainguards, is there a way to copy an existing package from xenial into the vivid overlay via a silo?
[22:19] <robru> bregma: yes that's called doing a sync.
[22:20] <bregma> well, at least it has a name
[22:20] <bregma> robru, I can do that myself?
[22:20] <dobey> bregma: are the binaries all arch: all?
[22:20] <bregma> dobey, no, it's xorg-server
[22:20] <dobey> oh
[22:21]  * dobey falls away in fear
[22:21] <robru> bregma: oh, well the train only supports doing it for train-managed packages, so you can't do it for xorg
[22:21] <bregma> ah
[22:21] <robru> bregma: you can assign yourself a manual silo though, then prepare the package in a ppa somewhere, and I'll copy it in
[22:21] <dobey> you can make a backport to vivid in a PPA, and ask someone to copy it into a silo; and land it via silo that way
[22:21] <dobey> heh
[22:22] <bregma> we'll just do a manual upload like the last few times
[22:22] <bregma> I'd feel better going through a silo for testing, but......
[22:23] <dobey> xorg is a pretty big surface to break
[22:26] <robru> bregma: yes, so in this case to get a silo, assign yourself a silo, prepare a package, and I will upload the package into the silo.
[22:27] <robru> bregma: you just don't get to use the automated tools for copying the xenial package into a vivid silo.
[22:27] <ToyKeeper> dobey: Just starting my day, but it's first on my list.
[22:28] <dobey> ToyKeeper: ok, great. please ping me (or mup sms or something) if you have any questions