[07:27] <morphis> robru: ping
[07:35] <robru> morphis: pong
[07:36] <morphis> robru: I am wondering if I can mix a MP supposed to dual land a package and a vivid-only package in a silo
[07:37] <robru> morphis: nope, silos are either entirely dual or entirely one series. You can mix an mp with two manual packages though
[07:38] <robru> morphis: like a manual xenial copy and a manual vivid copy of the same package
[07:38] <morphis> ok
[07:38] <morphis> robru: I've replayed with that a bit at the weekend: https://requests.ci-train.ubuntu.com/#/ticket/708
[07:39] <morphis> where wpa is a vivid only upload
[07:39] <morphis> but I must say I switched the silo to vivid+xenial after adding the settings app MP
[07:41] <robru> morphis: right so the three listed under "ready to build" means "you need this"
[07:41] <morphis> ok
[07:41] <morphis> then I need to start over
[07:42] <robru> morphis: start over? Just make xenial packages
[07:42] <morphis> robru: for wds, ubuntu-touch-meta that is possible yes
[07:42] <morphis> but the wpa package wont change for xenial
[07:43] <morphis> or I am doing just a version bump for the xenial one of wpa
[07:43] <robru> morphis: it's not clear to me why you would want to have some changes only on vivid, one of the requirements is landing stuff in xenial first then vivid. Doing stuff in vivid without also on xenial is bad
[07:44] <morphis> robru: yes, but in this case its the way to go
[07:44] <morphis> wpa is 2.1 in vivid
[07:44] <morphis> and 2.4 in xenial
[07:44] <morphis> 2.4 has CONFIG_WIFI_DISPLAY already set
[07:44] <morphis> 2.1 in vivid don't
[07:44] <robru> morphis: so you're just syncing the xenial version to vivid?
[07:44] <morphis> so I am only adding CONFIG_WIFI_DISPLAY for 2.1 in vivid and xenial is fine
[07:45] <morphis> robru: we don't want to do this right now as bumping from 2.1 to 2.4 might introduce other regressions we don't want to look for yet
[07:45] <robru> morphis: you're just changing one variable and that's the whole diff?
[07:47] <morphis> yes
[07:47] <robru> morphis: then I'd do a separate silo for wpa in just vivid, and once that lands the other silo that's a dual will have it
[07:48] <robru> Should be a quick landing with such a small diff
[07:49] <morphis> robru: ok, any chance I get wpa out of that silo or do you have to run the assign-job again?
[07:50] <robru> morphis: not sure what you mean. You want to copy the package to a new silo? Or delete it? Train wing do either but i can do it manually
[07:50] <morphis> robru: copying it to a new silo would be the easiest way
[07:51] <robru> morphis: yeah. Make a new request, assign it, and I'll copy it over and delete the original
[07:51] <morphis> thanks
[07:51] <robru> morphis: let me know what new silo number you get
[07:52] <morphis> robru: silo 40
[07:52] <robru> OK one sec
[07:56] <robru> morphis: OK, wpa copied and deleted
[07:56] <morphis> robru: thanks a lot!
[07:56] <robru> morphis: you're welcome
[08:01] <robru> Good god, why is bzr missing such a dog?
[08:06] <robru> uh
[08:06] <robru> morphis: did you do anything to the previous silo? u-s-s in xenial seems to have lost it's .bzr: https://ci-train.ubuntu.com/job/cyphermox-test/1474/console
[08:07] <morphis> I removed the MP temporarily and added it again now
[08:08] <morphis> let me force a rebuild of everything
[08:09] <robru> morphis: alright, that's very strange though, I'm not aware of any train code that would delete just the .bzr directory from the source tree. also it shouldn't have deleted anything just by changing the MPs
[08:10] <morphis> robru: I did something like: 1. Add the uss MP 2. build everything 3. Drop uss MP 4. eventually rebuild again (not sure)
[08:10] <robru> morphis: no but I mean like, the .bzr directory disappeared within the last 20 minutes.
[08:12] <morphis> robru: oh really
[08:12] <robru> morphis: anyway I guess it'll fix itself if you're rebuilding anything, but that's really weird
[08:12] <robru> morphis: check the audit log on the ticket. the thing about "not a branch" is super new, and before that it was "successfully built", which means the .bzr would have been there and everything was good
[08:17] <robru> morphis: in case this happens again it's possible to recover the branch from https://code.launchpad.net/~ci-train-bot/ubuntu-system-settings/ubuntu-system-settings-ubuntu-xenial-landing-000 but you'll need either me or sil to be able to copy it back into the train
[08:17] <morphis> robru: ok
[08:17] <morphis> good to kno
[08:36] <sil2100> jibel, Mirv, davmor2_: anything to discuss? I suppose we would have more after the RTM meeting and more details about OTA-8.5
[08:42] <Mirv> sil2100: mostly that I'd plan to land Qt 5.5 to xenial this week. we've a sprint in Helsinki too this week.
[08:42] <robru> Mirv: were you doing anything in Jenkins on the last 20 minutes?
[08:42] <Mirv> robru: no, haven't touched
[08:43] <robru> Mirv: sil2100: something goofy if happening in the train and deleting branches
[08:43] <robru> Like when jobs attend even running
[08:43] <robru> Aren't*
[08:44] <robru> sil2100: Mirv second incident in the last hour or so
[08:44] <robru> Look at the most recent queuebot ping, about "not a branch"
[08:45] <robru> I have no idea why it would do that. It was a branch 15 minutes ago otherwise it would've said so earlier
[08:47] <robru> Mirv: https://ci-train.ubuntu.com/job/cyphermox-test/1475/console source tree is there but .bzr is just gone. totally bizarre
[08:48] <robru> Mirv: you'll have to rebuild appmenu-qt5 I guess.
[08:49] <robru> Mirv: the code should be pushed to https://code.launchpad.net/appmenu-qt5 but I guess you last built appmenu-qt5 10 million years ago, before I switched it to pushing branches at build time
[08:52] <Mirv> robru: oh right I didn't touch jenkins but I added a branch in bileto
[08:52] <Mirv> robru: so this was the first time I added that branch
[08:53] <robru> Mirv: oh you changed it from a manual source to a merge?
[08:53] <Mirv> robru: right, exactly that! :)
[08:53] <Mirv> robru: same for the two others
[08:53] <robru> Mirv: that would explain it
[08:53] <robru> morphis: sorry earlier when I was asking about jenkins, did you say you added a merge to something that wasn't a merge at all before?
[08:54] <morphis> robru: yes
[08:54] <robru> morphis: oh ok, I misunderstood. I thought it was already a merge and you just added another merge
[08:54] <morphis> robru: silo 0 was a silo with only manual uploaded packages first but when got two MPs added
[08:54] <robru> but that makes more sense
[08:55] <robru> morphis: Mirv: sil2100: ok false alarm, train isn't deleting .bzr dirs randomly, but changing something from a manual source to an MP isn't something I ever anticipates so it gives that error "not a branch", just rebuild to fix
[08:55] <morphis> robru: great
[08:56] <Mirv> robru: ticket 20 is good about stress testing the Train. let's see later this week when I'm about to publish it :)
[08:57] <robru> Mirv: I'll try not to claw all my hair out ;-)
[08:57] <sil2100> robru: phew
[08:57] <sil2100> Mirv: yay for Qt 5.5, go for it - we don't have anything planned for xenial
[08:57] <robru> very strange that two different people caused the same issue within one hour of each other!
[08:57] <sil2100> And we already promoted a devel image last week
[08:58] <robru> but not really an issue at all since presumably you want to build the new MP you just added anyway
[08:59] <sil2100> Mirv, jibel, robru: I'm thinking of making the landing team meetings just once a week, I'll try to figure out the best day for those so that we can use it the best for milestone preps
[08:59] <sil2100> We can always schedule additional meetings if needed
[08:59] <robru> sil2100: +1000
[08:59] <sil2100> Better than having to cancel those all the time
[09:00] <robru> sil2100: let's say once per week and change it to an email. one weekly email ;-)
[09:11] <Elleo> trainguards: heya, can anyone point out what I'm doing wrong with silo 17 to cause these "not in PPA" errors for a bunch of MRs? (https://requests.ci-train.ubuntu.com/#/ticket/236)
[09:13] <sil2100> Elleo: hmmm
[09:14] <jibel> sil2100, 1 meeting a week works for me
[09:19] <davmor2> jibel, sil2100, once a week sounds good, I would suggest keeping the monday morning one on release weeks as it acts as the game plan meeting then the thursday afternoon one as the results meeting
[09:37] <robru> Elleo: sil2100: "not in ppa" means that the version in Jenkins doesn't match the ppa, so either the upload failed for some reason or the ppa contents gave been deleted. Check the version numbers in the message against what's in the ppa, they may be lower (most common reason for upload rejections)
[09:41] <Elleo> robru: ah, yeah, the ppa packages have a lower version number, what do I need to do to fix that?
[09:41] <Elleo> robru: since it's all the autogenerated part of the version that's different (i.e. the build date)
[09:44] <robru> Elleo: well i would look at the last build job log and see what it was trying to do. The error would most likely happen if the ppa versions were *higher*
[09:44] <robru> Elleo: generally i would try rebuilding everything
[09:47] <Elleo> robru: hmm, the lastBuild artifacts give a 404; I'll do a rebuild and see what happens
[09:53] <Elleo> robru: aha, now I'm getting an error from the indicator-transfer MR with its version number going backwards, I think because we forgot to create a vivid only branch for that now that we're doing separate vivid and xenial landings
[09:57] <robru> Elleo: oh yeah sorry Jenkins lost all the logs before some recent point. But yeah fix that changelog and then rebuild everything and it should work
[09:57]  * robru not really here
[09:58] <Elleo> robru: I'm wondering if it might be best for us to just land ubuntu-download-manager in vivid and xenial as two separate landings, then land everything else in that silo via dual landings afterwards
[10:38] <robru> Elleo: dual landings are generally preferred, please email me with a summary of the challenges your having with dual and I'll look over it in the morning
[11:52] <diwic> hi, a question, can one get the ci train to start with a git branch, in this case http://anonscm.debian.org/cgit/pkg-pulseaudio/pulseaudio.git/?h=ubuntu
[11:52] <diwic> it seems to only offer "merge proposals" or "raw tarballs"
[11:54] <sil2100> diwic: hey! Sadly the train right now only supports bzr for merge proposals
[11:55] <sil2100> diwic: for others you would need to create a manual source and ask someone to upload to the silo
[11:55] <diwic> sil2100, ok, so that essentially makes dual landings impossible, right?
[11:55] <sil2100> (either a core-dev or a trainguard, if you're not a core-dev yourself)
[11:55] <sil2100> diwic: well, yeah, you would have to create two source packages for that in the dual silo
[11:56] <diwic> sil2100, I'm not a core-dev but I have upload rights to pulseaudio so I could upload to xenial and ask the ci train to sync to the vivid ppa
[12:01] <diwic> sil2100, that at least is what I'm going to try next
[12:02] <sil2100> diwic: yeah, that could work
[12:02] <diwic> sil2100, ok, thanks
[12:05] <Elleo> sil2100: any ideas what's causing the xenial build error on silo 2? vivid builds fine buy xenial claims the version is missing from the changelog? https://requests.ci-train.ubuntu.com/#/ticket/712
[12:05] <sil2100> Elleo: looking now
[12:06] <Elleo> sil2100: thanks
[12:06] <sil2100> Elleo: ah, yeah, since there is one version missing from the changelog indeed
[12:07] <sil2100> Elleo: nothing to worry about though
[12:07] <sil2100> Elleo: so, slangasek made a no-change rebuild in xenial
[12:07] <Elleo> sil2100: ah, okay; that won't cause issues landing then?
[12:08] <sil2100> Elleo: from what I see the current train is smarter so it should be fine
[12:08] <Elleo> sil2100: okay, cool, thanks :)
[13:17] <tvoss> sil2100, o/
[13:18] <sil2100> tvoss: o/
[13:22] <tvoss> sil2100, could you remove trust-store packages from https://requests.ci-train.ubuntu.com/#/ticket/657
[13:25] <sil2100> tvoss: on it!
[13:25] <sil2100> tvoss: you mean, xenial trust-store packages only? Or both?
[13:28] <tvoss> sil2100, both, please
[13:29] <sil2100> tvoss: done
[13:29] <tvoss> sil2100, thx
[14:04] <diwic> hi, can anyone tell me what I'm doing wrong in https://requests.ci-train.ubuntu.com/#/ticket/720 - I'm trying to sync from xenial to the vivid ppa
[14:06] <diwic> I just uploaded a new version of PulseAudio in xenial, waited for it to migrate from proposed to main, and now I want to see if I can land that on ubuntu touch as well
[14:06] <sil2100> diwic: hey! You need to include the source package name in the Source Package Names field
[14:08] <diwic> sil2100, thanks, that then went to complain about a different error...
[14:08] <diwic> "1:7.1-1ubuntu2 does not seem to be a CI Train generated version number"
[14:08] <sil2100> Hah, yeah, you seem to be hitting the train limitations ;)
[14:09] <sil2100> Yeah, it's as the output says, sadly train-syncs are only supported for CI Train released packages (with the citrain versioning) as otherwise we weren't be able to guess how to modify the version number to make it not collide with anything
[14:10] <sil2100> diwic: you just want to sync what's in xenial to the silo for testing by QA, right?
[14:10] <sil2100> diwic: let me fetch the sources and dput to the PPA with the version changed
[14:10] <diwic> sil2100, well, that's part of it, but part of it is also learning how this entire ci train thing works
[14:11] <sil2100> diwic: so the CI Train thingy works well for things where we're upstream, so projects that are hosted on LP with bzr - then everything is easy as all can be dealt with merges and the train does all the work for you
[14:12] <sil2100> diwic: but yeah... currently git support is not there (wasn't a priority since almost none of our projects are using git) and for manual sources it requires some manual work
[14:15] <diwic> sil2100, ok, not sure where that leaves me and pulseaudio though
[14:17] <sil2100> diwic: I suppose for pulseaudio it can be a bit hard to use the train, normally it would have to be handled by manual source-packages here
[14:17] <diwic> john-mcaleely, ^ fyi
[14:17] <sil2100> diwic: meaning you'd need to team up with someone that could upload the packages for you to the train PPAs for QA to test...
[14:17] <sil2100> diwic: we *could* figure something out though to make it a bit easier
[14:18] <sil2100> diwic: I would need to think if we could use some temporary bzr branch for this and use the debian/control flag not to overwrite the version number
[14:18] <diwic> sil2100, and that someone needs to be a...
[14:18] <sil2100> diwic: a core-dev or a trainguard
[14:18] <diwic> okay
[14:18] <john-mcaleely> does that need to be pushed to the ppa direct then?
[14:18] <john-mcaleely> after some sort of approval/qa pass?
[14:19] <john-mcaleely> (or not, whatever the process would be)
[14:19] <sil2100> john-mcaleely: well, it can still be released through the train, we handle publishing manual sources too
[14:19] <sil2100> The problem is that it'll be a bit troublesome for diwic
[14:19] <john-mcaleely> yuk
[14:19] <john-mcaleely> there was me thinking it would be 'easy'
[14:19] <john-mcaleely> ha
[14:19] <sil2100> john-mcaleely, diwic: using the train is nice as QA has easy access to test that and sign-it-off
[14:20] <sil2100> john-mcaleely, diwic: the short-coming is that diwic would have to prepare source packages and ask someone to copy them to the silo PPAs
[14:22] <diwic> john-mcaleely, do we have trainguards and/or core-devs on our team to help with that?
[14:23] <john-mcaleely> diwic, none I'm aware of
[14:24] <john-mcaleely> well, tseliot & tjaalton are core devs. Might be unfair to land it on them tho
[14:24] <john-mcaleely> not sure
[14:24] <john-mcaleely> maybe ask them, see if they feel they could?
[14:25] <john-mcaleely> (ie no is a reasonable answer)
[14:25] <john-mcaleely> diwic, ^
[14:26] <sil2100> You can always just ping trainguard with that, in the UE timezone usually me or Mirv are around to help
[14:26] <diwic> john-mcaleely, ok. Tend to agree with you on that; they're not that much into ci train stuff either AFAIK
[14:26] <diwic> sil2100, okay
[14:26] <sil2100> So an upload takes a moment
[14:26] <sil2100> diwic: should I upload that xenial sync to your silo?
[14:27] <diwic> sil2100, sure, let's do that just for me to learn the process
[14:34] <sil2100> diwic: done, I also pressed the 'Build' button so that the train picks up the new package pushed to the PPA
[14:44] <diwic> sil2100, thanks - so now my next step is to wait for the build to either success or fail?
[14:49] <sil2100> diwic: yes, once that's finished, you can test it on a phone and if you're happy with it - switch the silo to Ready for QA
[14:49] <sil2100> https://wiki.ubuntu.com/citrain/LandingProcess#The_QA_Signoff_Status_field
[14:50] <diwic> sil2100, I've attached a test plan (which somebody else wrote), am I supposed to follow that test plan myself and mark "ready for QA" when I'm done, or is it QA that'll follow the submitted test plan?
[14:51] <sil2100> diwic: usually we leave that up to the lander, but QA expects that you made sure that the package has been tested properly, so therefore assuming the test plan has been also executed
[14:52] <sil2100> QA is just a gatekeeper that makes sure that the lander didn't miss anything during their testing and/or didn't skip anything during testing
[14:52] <davmor2> diwic: both
[14:53] <diwic> sil2100, davmor2 ok, so the test plan is being executed twice, first by me, then by QA team
[14:54] <davmor2> diwic: we try and discover edge cases that might not be covered too etc, the testplan should be the essentials to a successful landing effectively
[14:55] <diwic> davmor2, ok..
[14:57] <sil2100> The end idea was that QA just does some base testing, but then they noticed that some landers didn't really properly execute their test plans ;)
[14:58] <dobey> Mirv: can you get qtpurchasing-opensource-src through NEW so it makes it into xenial archive?
[15:12] <Mirv> dobey: that needs to be approved by https://launchpad.net/~ubuntu-archive/+members
[15:15] <dobey> Mirv: ok, i didn't know if you had permissions for that or not
[15:15] <Mirv> dobey: those permissions are in pretty rare hands unfortunately
[15:15] <dobey> yeah
[16:10] <bfiller> jibel, popey : just uploaded new gallery app to store with fixes that were approved by QA last week, need approval in store
[16:17] <popey> bfiller, jibel approved
[16:19] <bfiller> popey: thanks
[16:19] <popey> np
[16:25] <diwic> sil2100, I've got an updated source package in https://launchpad.net/~diwic/+archive/ubuntu/temp - could you take the just pushed pulseaudio package from there and build it in both my silo and silo 47 ?
[16:27] <pmcgowan> whats up with the trello board
[16:31] <diwic> sil2100, sorry, no need to do that today.
[17:39] <dobey> cihelp: can any of you do manual ack of autopkgtest issues that have "always" existed? or we need coredev, or just pitti, for that?
[17:40] <ev> dobey: foundations owns proposed-migration these days
[17:40] <ev> kitsune (cihelp) doesn’t operate it anymore
[17:40] <ev> so I believe pitti is your guy :)
[17:43] <dobey> ev: thanks
[17:43] <dobey> fginther_, plars: hi, can one of you upload a new payui click to the store for me please? https://jenkins.qa.ubuntu.com/job/generic-click-builder-14.09-armhf/55/artifact/output/com.canonical.payui_15.01.137_armhf.click thanks.
[18:25] <boiko> trainguards: can someone please trigger a telephony-service rebuild for vivid i386 on silo 52?
[18:25] <sil2100> boiko: on it
[18:25] <boiko> sil2100: thanks!
[18:26] <boiko> sil2100: are we low on arm64 builders or something?
[18:27] <sil2100> boiko: done
[18:27] <sil2100> boiko: yeah, it usually takes a while to get those building sadly
[18:27] <boiko> sil2100: ok, thanks
[18:36] <fginther> dobey, sure
[18:41] <dobey> fginther: great, thanks
[18:46] <fginther> dobey, uploaded
[18:46] <dobey> popey: ^^ care to approve the new payui please? :)
[18:47]  * popey looks
[18:51] <popey> dobey, done
[18:54] <dobey> popey: awesome. thanks much!
[18:54] <popey> np
[20:12] <dobey> slangasek, infinity: can either of you manually ack autopkgtests issues, to push things along through proposed migration?
[20:30] <slangasek> dobey: anyone on the release team can if there's cause to, yes
[20:32] <dobey> slangasek: can you ack ubuntu-push please? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html shows it failing install unity-scope-click on arm64/ppc/ppc64el, where unity-scope-click has never existed.
[20:34] <dobey> i'm not sure why those aren't just being flagged as [always failed] though
[20:34] <slangasek> dobey: that's not an autopkgtest failure, that's you building an uninstallable binary
[20:34] <dobey> oh
[20:34] <slangasek> you should fix the build to not build an uninstallable package, then it'll go through clean :)
[20:34] <dobey> that's not new though, it's been that way for over a year :-/
[20:36]  * dobey wonders how unity8 and ubuntu-push have been getting through
[20:36] <slangasek> dobey: it's new because previous versions of ubuntu-push did not build at all on these architectures; now they are building uninstallable packages
[20:37] <dobey> oh, right :-/
[20:40] <dobey> i wonder if unity-scope-click will even build on those archs now
[20:45] <dobey> bah
[20:45] <dobey> ubuntu-touch-meta isn't available there, so will still be left with uninstallable binaries :(
[20:48] <dobey> and unity8 doesn't build on those archs
[20:48] <dobey> gah
[20:52] <dobey> slangasek: i wonder how i should fix this? change the ubuntu-push-autopilot package to only build on [amd64 armhf i386] ?
[20:52] <anpok> cihelp: we have a strange failure on unity-system-compositor(again?) https://jenkins.qa.ubuntu.com/job/unity-system-compositor-xenial-amd64-ci/12/console
[20:54] <fginther> anpok, looking
[20:57] <dobey> robru: is it possible to rebuild a silo that's been published, but is stuck in proposed-migration, and then publish again, to fix an issue?
[20:57] <robru> dobey: yes
[20:57] <fginther> anpok, Looks like there is something wrong with an individual builder node. I've pulled it and will retry those two recent failures
[20:57] <dobey> ok
[20:58] <robru> dobey: publishing will only publish bits that weren't already published, so you can safely rebuild just one package in a silo that has many
[20:59] <dobey> robru: ok, great, thanks
[21:00] <robru> yw
[21:03] <slangasek> dobey: yes, you can mark the package as Architecture: amd64 armhf i386 instead of Architecture: any in debian/control
[21:22] <anpok> fginther: thx
[21:38] <dobey> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-015/+build/8359782
[21:38] <dobey> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-015/+build/8359781
[21:38] <dobey> robru: ^^ can you retry those please?
[21:40] <robru> dobey: done
[21:41] <dobey> thanks
[21:41] <robru> yw
[22:17] <dobey> hmm
[22:29] <robru> dobey: it can still be published with that "error"
[22:29] <dobey> robru: can you publish it?
[22:29] <robru> well, no
[22:30] <robru> dobey: I have the same publish power you do... only if it's a merge and theres' no packaging diff.
[22:33] <dobey> robru: ah, for some reason i thought maybe you were motu
[22:33] <robru> dobey: maybe one day ;-)
[22:34] <dobey> kenvandine, slangasek: can one of you click publish on https://requests.ci-train.ubuntu.com/#/ticket/616 please? :)
[23:11] <dobey> well, i have to go. hopefully someone can publish