[04:49] <anpok_> fginther, robru: can I see the logs from boottest?
[04:50] <robru> anpok_: if you're looking at http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-004 you can click on "x is in the proposed pocket" and then from there it'll say "boottest regression" and you can click on "public" to get the log
[04:51] <anpok_> i see
[04:51] <anpok_> I know what is causing this
[04:51] <robru> anpok_: excellent! good luck ;-)
[04:52] <anpok_> mir libraries do not depend on any particular driver package
[04:52] <anpok_> bootest only updates the involved mir libraries .. and not the driver package..
[07:24] <anpok_> robru: boottest for usc should work now.. now trying bootest for mir
[07:29] <robru> anpok_: OK, please ask sil2100 to publish when you're ready, it's midnight here ;-)
[07:34] <seb128> veebers, hey
[07:34] <seb128> veebers, what's the status of the fix for bug #1477233 ?
[07:35] <seb128> that's making tests fail and blocking things
[07:35] <veebers> seb128: hey, I have an MP sitting there that needs ack & approve then we'll release
[07:35] <seb128> veebers, who does autopilot reviews?
[07:35] <veebers> the original MP that kenvandine proposed was marked needs fixing
[07:35] <seb128> did you ping people?
[07:36] <veebers> seb128: well, for this I need kenvandine and Laney to ack
[07:36] <veebers> seb128: I have emailed
[07:36] <seb128> k
[07:36] <seb128> well, they are not part of the autopilot team
[07:36] <seb128> you have nobody in your team to do reviews?
[07:36] <seb128> also ken's change was easy to review/just packaging, yours has more
[07:36] <veebers> seb128: I do, but they raised specific concerns which need to be OK'd
[07:37] <seb128> k
[07:37] <veebers> seb128: right, Laney had concerns that the packaging was too much for everyone to shoulder as well as point out that using the gsetting binary was heavyweight. Hence the extra code
[07:38] <seb128> k
[07:38] <seb128> I also notice that you self reviewed the change that created the issue
[07:38] <seb128> we don't have anyone to do peer reviews on that project?
[07:38] <veebers> seb128: Not as many as I would like.
[07:39] <veebers> seb128: although that was a little odd as I had acks from other people, just not via the MP (which is in bad taste, I know)
[07:41] <seb128> hum, k
[07:41] <veebers> seb128: so to follow up, I've pinged the people to approve/whatever the MP and I plan to have someone in the qateam to do the release when that happens (i.e. during my night)
[07:41] <seb128> veebers, anyway having something to land today would be nice, since that bugs tests and block things to migrate
[07:42] <seb128> k, good to read
[07:42] <seb128> can you give a qa person name to nag?
[07:42] <seb128> I don't want that to block things for another full day
[07:42] <veebers> seb128: sure, ping jibel or nuclearbob
[07:42] <seb128> k
[07:42] <seb128> thanks
[07:43] <veebers> seb128: no worries. Sorry it was an issue, I wasn't aware until this morn that it was an issue and blocking things
[07:43] <seb128> no worry, bugs happen
[07:43] <seb128> tz also don't make it easy to have quick resolutions sometime :-/
[07:44] <veebers> yeah :-\
[07:47] <jgdx> do we have a 'get started with silos' doc? :S
[07:47] <jibel> seb128, sorry there was a bus factor of 1 on autopilot releases. We'll use this release to share the knowledge.
[07:47] <seb128> jibel, no worry, thanks
[07:48] <seb128> jgdx, https://wiki.ubuntu.com/citrain/LandingProcess
[07:53] <jgdx> seb128, right.. how about a 'installing my first silo' :P
[07:59] <seb128> jgdx, installing?
[08:00] <seb128> jgdx, silos builds in ppa, are you asking how to enable a ppa?
[08:00] <seb128> jgdx, https://help.launchpad.net/Packaging/PPA
[08:01] <jgdx> Wellark, not as straight forward on a phone
[08:02] <jgdx> seb128, well… ^
[08:02] <jgdx> :)
[08:03] <seb128> just add-apt-repository <ppa>
[08:03] <seb128> to add it to your sources
[08:03] <seb128> then apt-get update & install
[08:04] <jgdx> seb128, before then, enable developer mode, download and install phablet-tools, make the device writable
[08:05] <jgdx> easy to forget
[08:23] <mandel> sil2100, do you no anyone who could approve the following => https://code.launchpad.net/~mandel/unity-scope-click/recompile-new-udm-client/+merge/257959
[08:23] <mandel> sil2100, is just a rebuild
[08:31] <sil2100> mandel: I can force it I suppose, you can self-approve it if you have the permissions
[08:32] <mandel> sil2100, did so
[08:32] <mandel> sil2100, let me rebuild the silo and we can publish
[08:32] <sil2100> Rebuild?
[08:32] <mandel> sil2100, added a new version of udm with --unchanged but linking to a bug
[08:33] <sil2100> ah, ok
[08:33] <mandel> sil2100, I'm a little anal, but I like to have the --fixes comment in th ehistory ;)
[08:34] <sil2100> anpok_: is it cool to publish 004 again?
[08:35] <anpok_> sil2100: no
[08:59] <Laney> jibel: can you/someone (review and) approve https://code.launchpad.net/~canonical-platform-qa/autopilot/depends_for_gsettings/+merge/265621 ?
[09:00] <sil2100> mandel: hmmm
[09:01] <mandel> sil2100, what?
[09:08] <mandel> sil2100, the suspense is killing me... ;)
[09:09] <mandel> sil2100, oh, is it due to this => Can't publish: Packaging changes need manual ACKing
[09:09] <mandel> weird
[09:09] <sil2100> mandel: one moment, in a meeting
[09:09] <mandel> sorry
[09:18] <jibel> Laney, done
[09:19] <Laney> ta
[09:19] <Laney> I'm scared about uploading this
[09:20] <Laney> I don't know about the dual rules
[09:20] <Laney> can someone help?
[09:22] <sil2100> mandel: ok ;p
[09:23] <sil2100> mandel: sooooo, I know you're already getting really irritated because of this landing
[09:24] <sil2100> mandel: but looking at the packaging changes, I see two things:
[09:25] <sil2100> mandel: first: uh oh the commit/changelog message of the ubuntu-download-manager is "Test build" <- is this really a test build? We're releasing a test build to the archive ;p ?
[09:25] <sil2100> mandel: second: I see some symbols changed, won't this break the ABI/API?
[09:25] <sil2100> https://ci-train.ubuntu.com/job/ubuntu-landing-009-2-publish/102/artifact/ubuntu-download-manager_packaging_changes.diff
[09:25] <sil2100> Here's the list of changes
[09:26] <seb128> Laney, dual rules? dual landing you mean?
[09:26] <Laney> yeah
[09:26] <sil2100> mandel: are those symbols that got changed used somewhere besides in u-d-m itself?
[09:26] <seb128> Laney, what do you want to know? basically it does 2 sources packages/uploads in the ppa, one targetting to vivid and one to wily
[09:27] <Laney> seb128: Like if you're allowed to just do it or who needs to sign off
[09:27] <seb128> well, I think vivid needs qa signoff
[09:27] <seb128> jibel can help I'm sure
[09:35] <mandel> sil2100, really? I did not see the test build comment, ups!
[09:35] <mandel> sil2100, the symbols are just changed in udm client lib, used by the other projects
[09:36] <mandel> sil2100, updated the changelog to not have that test comment
[09:38] <sil2100> mandel: it will require a rebuild... but regarding the symbols - so those symbols are not used anywhere outside of the library, right?
[09:38] <sil2100> mandel: since if they are used, then we need to bump the so-name too
[09:39] <mandel> sil2100, you are right, we do need to bump the version numbers, good catch, I'll take care
[09:40] <sil2100> mandel: sorry for that, I know you'd like to just land it already
[09:40] <mandel> sil2100, no no no, things have to be done right the first time
[09:40] <mandel> sil2100, mea culpa
[09:41] <mandel> sil2100, I prefer to land 5 times all of them correct than 20 wrong ones
[09:41] <sil2100> mandel: you'll have to bump the lib name to libudm-common1 probably, do a major version bump etc.
[09:41] <sil2100> mandel: indeed! Less trouble then
[09:41] <sil2100> Thanks!
[09:41] <mandel> sil2100,  ouch, I reach 1 already bummer :-/
[09:41] <mandel> sil2100, I wanted to be like emacs..
[09:42] <sil2100> hah ;)
[10:11] <seb128> Laney, did you plan to put that autopilot fix in a silo?
[10:13] <Laney> seb128: hoped jibel would respond to your ping ...
[10:13] <Laney> I guess I can build it now at least?
[10:17]  * Laney cries
[10:20] <Laney> I guess https://code.launchpad.net/~ci-train-bot/autopilot/autopilot-ubuntu-wily-proposed needs merging in
[10:20] <Laney> or add this MP to the original silo
[10:21]  * Laney does that instead
[10:22] <jibel> seb128, Laney sorry I missed your ping.
[10:22] <seb128> Laney, right, qa validation is needed beofre publishing, not before building
[10:22]  * Laney screms again
[10:23] <Laney> https://ci-train.ubuntu.com/job/prepare-silo/5485/console
[10:23] <jibel> Laney, seb128 yes vivid needs sign off if it was the question
[10:24] <seb128> hum
[10:24] <seb128> unsure if we should dual land
[10:24] <seb128> or just land to wily to unblock proposed
[10:25] <seb128> and let qa deal with vivid
[10:25] <seb128> Laney, ^ opinion?
[10:25] <seb128> I don't want wily to be blocked on qa to have to valid vivid updates
[10:25] <jibel> seb128, yes do that, and nuclearbob will deal with the landing in vivid
[10:25] <Laney> seb128: is it easy to fix that up later?
[10:26] <Laney> don't want to give someone a hard time if possible
[10:27] <seb128> Laney, unsure, I'm close from suggesting we just dput the fix in wily and let them deal with vcs and landings
[10:28] <Laney> I messed the silo config up a bit already
[10:29] <seb128> trainguards should be able to help
[10:33] <seb128> Laney, the other alternative is that I deleted the version currently in wily-proposed and we let qa deal with the dual landing
[10:34] <Laney> seb128: either thing wfm but I think that the fix was needed for some tests
[10:34] <Laney> maybe not wily autopkgtests though
[10:35] <seb128> right, I think it's more for some CI on mps issues
[10:36] <Laney> do it
[10:36] <seb128> deleting?
[10:36] <Laney> ya
[10:36] <Laney> It should be ok for nuclearbob or whoever to fix it later on I think
[10:36] <seb128> right
[10:38] <seb128> Laney, jibel, done ^ (deleted the autopilot update in wily-proposed since it was buggy, so we can wait for the new fixes to be dual landed and validated by qa the way it should be)
[10:39] <Laney> ty
[10:39] <seb128> yw
[10:39] <seb128> next to unblock is mir
[10:47] <mandel> sil2100, whenever you have some time, can you confirm this is correct => http://paste.ubuntu.com/11924616/
[10:48] <mandel> sil2100, the other packages do not use the new symbols so they do not need to change the dep AFAIK, right?
[10:55] <jibel> seb128, thanks
[10:55] <seb128> jibel, yw!
[11:08] <sil2100> mandel: one moment
[11:25] <sil2100> mandel: looks okayish to me
[11:25] <sil2100> But it would certainly need some testing after it's built
[11:45] <popey> pmcgowan: davmor2 has passed clock app to upload to the store. do I need a +1 from you also to upload it? https://trello.com/c/FFDKp0Qm/2074-click-ubuntu-clock-app-popey
[11:45] <pmcgowan> popey, no you guys are good
[12:05] <popey> thanks pmcgowan
[12:24] <Laney> jibel: sorry to ping you a lot today... since pitti is out - do you know how the adt VMs are built?
[12:24] <Laney> when is adt-buildvm-ubuntu-cloud called and how can I get a change to be effective there?
[12:25] <jibel> Laney, no problem. The VMs that run on HW or the cloud instances?
[12:25] <Laney> jibel: the HW ones
[12:25] <sil2100> popey: when the gates are not closed, after QA sign-off it's all good to publish
[12:25] <popey> sil2100: is now good? :)
[12:25] <jibel> Laney, I'll tell you as soon as NM stops crashing and I can bring the VPN up
[12:25] <sil2100> Good good :)
[12:25] <Laney> jibel: to fix https://jenkins.qa.ubuntu.com/view/Wily/view/AutoPkgTest/job/wily-adt-udisks2/ARCH=amd64,label=adt/48/console I need to make a change to the setup script
[12:26] <jibel> Laney, 1 min, I restart my session
[12:30] <sil2100> anpok_: tell me once silo 004 is good to land
[12:30]  * sil2100 off to lunch
[12:31] <jibel> Laney, there is a job called wily-adt-setup-testbed which calls autopkgtest/tools/adt-buildvm-ubuntu-clound
[12:31] <jibel> Laney, it is currently running.
[12:32] <jibel> Laney, I've an appointment now, but I can have a look when I'm done.
[12:37] <Laney> jibel: I found it, just need to know where/how it gets its copy of autopkgtest now
[12:37] <jibel> Laney, from git trunk I guess
[12:38] <Laney> I assume so, just can't see that
[12:39] <Laney> and can't change it if that is true :P
[12:43] <Laney> unless we can temporariliy point it to another url
[13:12] <kenvandine> mandel, i reconfigured silo 9 again, the content-hub branch was against 15.04
[13:12] <kenvandine> so i used your other MP that was against trunk
[13:40] <dobey> trainguards: can i land a silo into another silo (ie, have the "target ppa" be another silo)?
[13:41] <sil2100> dobey: hey! Yes, but remember that the upload to the other silo won't be auto-noticed by the trian
[13:41] <sil2100> dobey: the silo will just clean itself after doing a copy-package to the target PPA (in this case, the silo)
[13:42] <dobey> sil2100: is that how it works for the ovleray ppa?
[13:42] <sil2100> So the target silo needs to then know what to do with those packages
[13:42] <sil2100> dobey: yes
[13:42] <sil2100> It's the very same mechanism
[13:42] <dobey> ok
[13:43] <sil2100> ogra_: eeeenndoorrrssssmeeennnnt
[13:43] <sil2100> ogra_: a quick one would be enough ;)
[13:44] <ogra_> sil2100, i'll try today
[13:44] <dobey> cool, that will make dealing with the gcc5 silo at least slightly easier
[13:44] <sil2100> Thanks! Fingers crossed ;) Would like to submit my application soonish
[13:45] <sil2100> dobey: be sure to keep track of which branches you merge into
[13:45] <sil2100> So that there's no chaos later on with the trunk != archive
[13:46] <balloons> cihelp, can you remove the utopic jobs from ubuntu-calendar-app on core apps jenkins?
[13:48] <dobey> sil2100: yeah. idea would be to just land stuff into the gcc5 silo now, and then when it's copied to archive next week, things will just fall into place
[13:52] <psivaa> balloons: will do in a little bit
[13:54] <balloons> ty!
[13:57] <sil2100> dobey: many teams simply release their gcc-5 changes to the normal archives and then just get no-change rebuilds copied to silo 16
[13:57] <dobey> sil2100: too much rebuilding. really i'd rather just wait until stuff is copied to archive and just fix everything there
[13:58] <mandel> kenvandine, ok, I have to ensure that the udm bum works
[13:58] <mandel> kenvandine, we need to retest the silo
[14:09] <jibel> sil2100, can you give nuclearbob access to the spreadsheet so he can proceed with the landing of autopilot?
[14:09] <nuclearbob> jibel: just got it
[14:10] <jibel> ok
[14:10] <jibel> thanks
[14:10] <sil2100> Done :)
[14:27] <nuclearbob> sil2100: the job to build for the silo failed, could you help me figure out what I'm doing wrong?
[14:28] <sil2100> nuclearbob: let me take a look, but it seems the trunk for this project is missing one version that seems released to the archive
[14:28] <nuclearbob> sil2100: yes, I've just heard it was released to wily to unblock landings, I can get an mp to get that back in sync
[14:30] <sil2100> nuclearbob: all the changes from 1.5.1+15.10.20150716-0ubuntu1 need to be in the trunk you are merging into, along with the changelog entry for that version
[14:30] <nuclearbob> sil2100: okay, I'll work on getting that merged
[14:30] <sil2100> You can either add this MP to the landing or simply merge those changes to that trunk and rebuild
[14:30] <sil2100> Both approaches should be fine
[14:30] <sil2100> nuclearbob: ok :)
[14:33] <nuclearbob> sil2100: since I'm new at this, do you know the best place to grab the branch or mp that was merged into the archive? I see all the merges to trunk, but I'm not sure which branch was used to push to wily
[14:33] <rvr> mzanetti: Silo 6 approved
[14:34] <sil2100> nuclearbob: strange that it wasn't merged in... let me take a look
[14:34] <sil2100> nuclearbob: ah! Ok, I see now what's going on
[14:34] <sil2100> nuclearbob: so generally, I would recommend waiting a little bit for the merge to get merged in automatically by the train
[14:35] <nuclearbob> sil2100: okay
[14:35] <kenvandine> autopilot is stuck in proposed
[14:35] <sil2100> Any chance of it migrating?
[14:35] <kenvandine> sil2100, the branch nuclearbob is trying to land should fix that
[14:35] <rvr> davmor2: Silo 6 is landing, so 7 can be rebuilt
[14:35] <sil2100> Ok
[14:35] <kenvandine> sil2100, not without the fix he's trying to land :)
[14:35] <kenvandine> maybe silo 51 should be force merged
[14:35] <sil2100> Then hmmmm, let's force merge silo 51
[14:35] <sil2100> Indeed
[14:36] <kenvandine> he's trying to land a fix from me to fix the migration blocking a bunch of packages :)
[14:36] <sil2100> Force merging - nuclearbob you should be able to build in a moment
[14:36] <nuclearbob> sil2100: cool, thanks
[14:38] <mzanetti> rvr, yay!
[14:38] <mzanetti> rvr, next one coming in a minute :D
[14:38] <davmor2> greyback, mzanetti: can you please rebuild silo007 and not land any more unity8's till I get this one tested thanks ;)
[14:38] <sil2100> nuclearbob: you can build now :)
[14:38] <nuclearbob> sil2100: cool, saw that :)
[14:38] <mzanetti> davmor2, I think 7 can't land atm because of some Mir things
[14:39] <greyback> davmor2: silo7 blocked until silo4 lands
[14:40] <davmor2> greyback: I'll remove the card then :( sorry dude we keep trying to test it and people keep breaking it for you :(
[14:41] <greyback> davmor2: yeah. I've not been lucky.
[14:41] <sil2100> Today looks like a bad landing day
[14:41] <sil2100> Not the first package that can't land
[14:51] <anpok_> sil2100: the reason why usc-boottest failed for silo004, was because do not have explicit dependencies to any of the mir drivers
[14:52] <anpok_> and that is on purpose because on the phone we do not want to pull in both drivers as the mesa driver adds a lot of runtime dependencies
[14:52] <anpok_> and in earlier version we could not probe during startup (that part is solved now)
[14:52] <anpok_> so within the usc boottest usc used the new mir libraries it depends on, but those had no drivers to use.
[14:53] <anpok_> sil2100: I tried removing the ABI bump of the driver package this morning, but it turned out that the driver ABI bump was necessary
[14:56] <anpok_> sil2100: to solve bootest of usc, we could add usc meta packages one for desktop and one for android phablet, which contain explicit (and versioned) dependencies to mirs driver packages.
[14:56] <kenvandine> mandel, for some reason that content-hub branch is reverting previous landings...
[14:57] <sil2100> anpok_: hm, I guess that could be good, but I would consult this with an archive admin
[14:59] <anpok_> sil2100: hm who could that be in the current timezone?
[15:01] <sil2100> slangasek should be up soon, infinity might be able to help also since he uses a very fuzzy timezone
[15:01] <kenvandine> mandel, thankfully it was easy to spot in the packaging review :)
[15:01] <sil2100> Non-discreet
[15:01] <mandel> kenvandine, is it? how? weird...
[15:01] <mandel> kenvandine, I'm in a meeting can you fix that?
[15:01] <kenvandine> yes
[15:01] <kenvandine> i really don'
[15:01] <kenvandine> t understand why though
[15:02] <kenvandine> you had a no change branch
[15:02] <kenvandine> mandel, anyway, i fixed
[15:02] <kenvandine> mandel, i'll handle getting it landed
[15:03] <mandel> kenvandine, oh, thx, sorry in a meeting, is that silo 09?
[15:03] <mandel> kenvandine, I bumped the version of udm as per sil2100 request
[15:03] <kenvandine> mandel, yes
[15:03] <kenvandine> that's good too
[15:09] <mandel> kenvandine, perfect
[15:27] <psivaa> balloons: http://91.189.93.70:8080/job/ubuntu-calendar-app-ci/configure does not have utopic jobs now
[15:33] <sil2100> robru: do you know when wendigo will be back up?
[15:47] <balloons> psivaa, are you sure? I still see them: http://91.189.93.70:8080/job/ubuntu-calendar-app-ci/
[15:48] <balloons> psivaa, generic-mediumtests-utopic and ubuntu-calendar-app-utopic-amd64-ci
[15:48] <psivaa> balloons: those listed are the old ones,
[15:48] <psivaa> balloons: any new job will not execute them
[15:48] <balloons> psivaa, ok, executing :-)
[15:48] <balloons> psivaa, did you fix ubuntu-calendar-app-autolanding also?
[15:53] <psivaa> balloons: that should have been fixed as well, http://91.189.93.70:8080/job/ubuntu-calendar-app-autolanding/configure doesn't now have utopic jobs
[16:28] <anpok_> sil2100: we discussed further in the team.. and concluded that the solution outlined above just moves the problem..
[16:30] <anpok_> sil2100: can we instead have an excemption for the usc-boottest? and land the next finished build of silo004
[16:47] <sil2100> anpok_: hm, since this is about proposed migration, also the decision here should be made by the archive admins or even the release team
[16:47] <sil2100> I heard what this means more or less so I understand why you would like this skipped
[17:08] <anpok_> sil2100: ack .. i am off for a bit .
[17:25] <robru> sil2100: uh, are you able to load the train? i can't seem to connect
[17:26] <sil2100> robru: you mean citrain jenkins? Loads here for me
[17:26] <sil2100> Spreadsheet as well
[17:26] <robru> sil2100: yeah, I can't connect, it just spins...
[17:26] <robru> sil2100: spreadsheet is fine for me
[17:27] <sil2100> https://ci-train.ubuntu.com/ works fine here
[17:27] <robru> grrr
[17:36] <davmor2> robru: is your vpn up?
[17:37] <robru> davmor2: never needed a VPN to access citrain before.
[17:37] <sil2100> hm, right, I'm on VPN
[17:38] <sil2100> Let me disconnect
[17:38] <davmor2> robru: just trying to rule stuff out as I can access it too
[17:38] <robru> davmor2: well, I just connected to VPN and now I can load
[17:38] <sil2100> robru: still working here
[17:38] <robru> davmor2: sil2100: also downforeveryoneorjustme.com shows it as up
[17:39] <davmor2> robru: You ISP is stopping you from working, hate them :)
[17:39] <robru> davmor2: sil2100: OOOOOOOOOOOOOOHHHHHHHHHHHHHHHHHHHHH lol I'm dumb. My /etc/hosts munges those domains to point at the new deployment I'm supposed to be verifying, I forgot about that from last night
[17:40] <sil2100> hah
[17:40] <sil2100> ;)
[17:40] <davmor2> robru: that'll do it :)
[18:09] <jgdx> trainguards: could I have a silo for row 61?
[18:10] <robru> jgdx: you can assign your own silos now. just click the row and then click 'landing tools > assign/reconfigure' menu
[18:11] <jgdx> robru, man, that's out of the ballpark
[18:11] <robru> jgdx: heh, you're welcome. it's a little experimental, let me know if you have any problems
[18:11] <jgdx> thanks!
[18:11] <robru> jgdx: you're welcome
[18:27] <dobey> trainguards: the spreadsheet won't let me enter ci-train-ppa-service/ubuntu/landing-016 in column L :(
[18:28] <robru> dobey: why would you want to do that?
[18:28] <dobey> robru: because it's just a gcc5 build fix, and i don't want to have to deal with maintaining 2 conflicting copies of the same package until the end of next week
[18:29] <robru> dobey: I'm not really following. why not just build in silo 16 in the first place?
[18:29] <robru> dobey: what are you expecting to happen by having a separate silo that publishes into silo 16?
[18:29] <dobey> robru: because it's not a normal silo, so i can't just add a branch to it and then reconfigure and rebuild the silo, as i understand it
[18:30] <robru> dobey: it's a normal silo, but somebody decided it would be a great idea to add thousands of packages to it without configuring it properly.
[18:30] <dobey> robru: i expect it to commit the MP to the target branch and publish the package in that silo; and next week the contents of that silo will be pushed into the archive
[18:30] <robru> dobey: you can add an MP to the silo 16 config and then build it if you want.
[18:31] <robru> dobey: ok what row are you doing?
[18:31] <dobey> robru: and my doing that won't cause the archive to blow up by deleting all the packages in it alrady?
[18:31] <robru> dobey: no the train never deletes packages from PPAs unless it's doing merge & clean, after publication
[18:32] <robru> dobey: hang on. is your goal to merge your merge before silo 16 gets published?
[18:33] <dobey> my goal is to fix the issue in silo 16, without having to maintain two versions of the same package to do so
[18:34] <dobey> and i don't want to have to manually resolve the differences in the trunk, when silo 16 gets published
[18:39] <dobey> robru: is that not possible?
[18:39] <robru> dobey: I don't know what you mean by "two versions". what scenario will cause two versions of the same package?
[18:42] <dobey> robru: the existance of silo 16 for the gcc5 migration. if i land directly into the archive, i'll have to get someone to upload a no-change rebuild to silo16. then, when that gets merged to the archive, i'd have to resolve the conflicts by hand in trunk, to add the new revisions from debian/changelog
[18:42] <robru> dobey: ok, so how does publishing to silo 16 fix that? you just won't publish to archive at all, and wait for 16 to publish?
[18:43] <anpok_> infinity, slangasek: ping
[18:43] <dobey> but if i understand correctly, i should just be able to land by publishing to silo 16, and then that will satisfy the rebuild, and it will go in the archive when silo 16 publishes
[18:43] <infinity> ?
[18:43] <anpok_> infinity: hi
[18:43] <dobey> robru: i think so, yes
[18:43] <anpok_> infinity: we have a problem with boottest of unity-system-compositor
[18:43] <robru> dobey: ok well it should be possible to put silo 16 as a publish target, just right click on the cell and click 'data validation' and change it from 'refuse invalid' to 'show warning' or something
[18:44] <infinity> anpok_: Indeed you do.
[18:44] <dobey> robru: ah ok
[18:44] <anpok_> the boottest updates unity-system-compositor, and thus also the server librariers of mir which it uses.
[18:44] <anpok_> but it does not install any drivers required by libmirserver32
[18:44] <anpok_> hence launching usc and greeter fails
[18:45] <infinity> anpok_: So, nothing depends on a driver?
[18:45] <anpok_> we decided against making the drivers a dependency of libmirserver or one of ther shells that user libmirserver
[18:46] <anpok_> instead this is handled by other meta packages during image generation
[18:46] <anpok_> i.e. if we made both a dependency we would always pull in x and wayland libararies because of mesa..
[18:46] <infinity> anpok_: Okay, but those metapackages are installed in the image, so what's breaking here?  An ABI break in the drivers or something?
[18:47] <anpok_> infinity: with that mir release we have an abi break between server and drivers so the driver package gets a bumped abi - and not a new version since we want to support having multiple driver abis installed
[18:47] <infinity> anpok_: Anyhow, if this is something that needs hacking around in the boottest infra to fake things up better, that's not my code.  I think jibel owns it (or knows who does).
[18:48] <anpok_> infinity: we wondered if we could get an exemption for silo004 landing
[18:48] <infinity> anpok_: Well, an exemption is only sane if you're positive that all the failures are false negatives (ie: people have tested this all by hand with the right package combinations and you're sure boottest is lying).
[18:49] <infinity> anpok_: And, more importantly, we need to be sure this problem goes away once all that stuff promotes and a new base image happens.
[18:49] <anpok_> well thats what the boottest log tells us
[18:50] <infinity> anpok_: Sure, "this is what the log is hinting at" isn't the same as "I reproduced the issue locally, then upgraded/installed a few more packages, and everything was good again".
[18:50] <anpok_> ok.. then again
[18:50] <infinity> anpok_: Is it a question of packages not being installed at all, or not upgraded?
[18:50] <anpok_> I know this happens because of that because I reproduced it locally
[18:50] <anpok_> and tried different ways to circumvent the problem
[18:50] <dobey> robru: ah, i guess i can't do this after all :-/
[18:50] <dobey> 2015-07-23 18:48:58,290 ERROR pay-service 2.0.0+15.10.20150721-0ubuntu2~gcc5.1 is missing from the changelog, which has up to 2.0.0+15.10.20150702-0ubuntu1. Please sync destination version back to trunk.
[18:50] <jibel> infinity, I'm happy to not own boottest. I think psivaa or at least someone in cihelp can help
[18:50] <anpok_> but I cannot find a solution that makes boottest-mir and boottest-usc run successfull
[18:51] <anpok_> .. well the only solution is explicit dependencies that we decided against some time ago
[18:51] <infinity> jibel: I don't want to own it either. :P
[18:51] <robru> dobey: so that implies that there's already a pay-service in silo 16.
[18:51] <robru> dobey: FORCE_REBUILD will steamroll over that as long as you're ok with clobbering whatever is in silo 16.
[18:51] <dobey> robru: yeah, there is. will force rebuild work around that?
[18:51] <dobey> ok, great
[18:51] <infinity> anpok_: Asking again, is it a question of packages not being installed at all, or not upgraded?
[18:52] <anpok_> not being installed at all.
[18:52] <infinity> anpok_: If it's packages not installed *at all*, how will the be installed on "correct" images?
[18:52] <fginther> jibel, infinity, anpok_, catching up
[18:52] <infinity> s/the/they/
[18:52] <anpok_> infinity: through the seed package
[18:52] <anpok_> hmm
[18:52] <infinity> anpok_: livecd-rootfs hacks, or a metapackage that pulls them in?
[18:52] <infinity> anpok_: If it's a metapackage, why isn't that updated yet?  That would fix the test failure.
[18:53] <anpok_> because bootest does not work that way
[18:53] <anpok_> boottest takes wily .. and just installed one of the packages of the silo
[18:53] <anpok_> and no upgrade
[18:53] <anpok_> *installs
[18:53] <infinity> Oh, fair point.
[18:53] <infinity> It's a bit broken in that regard for special cases like this.
[18:54] <infinity> Or any case where an "unrelated" package causes a failure.
[18:54] <infinity> anpok_: Alright, well.  If you can assure me that this is all reproduced locally, that installing the right packages fixes it, *and* that images/metapackages will be correct and sane once this all promotes, I can give it a big override hammer.
[18:54] <anpok_> I can!
[18:54] <infinity> anpok_: But you're also implicitly taking responsiblity for fixing whatever mess that causes.  Deal?
[18:55] <anpok_> deal
[18:55] <anpok_> i am in mess mode since a few weeks already.. what bad can happen?
[18:55] <anpok_> ^ i said that last week
[18:55] <infinity> anpok_: Alright, I'll iterate through landing-004 and override as needed.
[18:55] <anpok_> thanks
[19:00] <fginther> anpok_, is this going to happen again the next time there is a mir landing?
[19:00] <anpok_> fginther: the next time when we have a driver bump - yes.
[19:01] <infinity> anpok_: So, we should work out a hack for that in boottest itself, to install the right drivers in the base if required.
[19:01] <anpok_> i think boottest showed us real problems last week
[19:01] <infinity> anpok_: ie: whatever you had to do to manually validate it, the infra should be doing that.
[19:02] <fginther> anpok_, indeed, I'd like to know what would resolve this and see if it can be added before the next bump
[19:02] <anpok_> infinity: yes - we should add something for mir server related boottest runs
[19:02] <infinity> anpok_: If you and fginther can figure out what that "something" is, that would be great.
[19:03] <infinity> anpok_: I'm backing away from it now. :P
[19:03] <anpok_> ok
[19:03] <anpok_> fginther: hm something like if [ $package = unity-system-compositor && $device == android ] ; then apt-get install mir-graphics-drivers-android ; fi
[19:04] <anpok_> fginther: boottest always uses a phone or emulator for that?
[19:05] <anpok_> apt-get install with the same options so that it takes what is in proposed
[19:06] <fginther> anpok_, does this just apply to ?
[19:06] <fginther> sorry to unity-system-compositor?
[19:07] <anpok_> hm i think this problem is only prone to unity-system-compositor
[19:07] <anpok_> it might also happen with qtmir ...
[19:07] <anpok_> but i doubt it
[19:07] <fginther> qtmir has also been failing, but I have no idea why
[19:07] <anpok_> where?
[19:09] <fginther> anpok_, here's a recent one: https://jenkins.qa.ubuntu.com/job/wily-boottest-qtmir/11/artifact/results/log/*view*/
[19:09] <fginther> anpok_, the log indicates that the unity greeter never came up
[19:10] <anpok_> 0 upgraded, 0 newly installed, 0 to remove and 111 not upgraded.
[19:11] <anpok_> so it did nothing and tried to boot the plain wily image?
[19:13] <fginther> anpok_, that's a result of having to retry the actual install and test multiple times, here's a better log that shows the packages being installed: https://jenkins.qa.ubuntu.com/job/wily-boottest-qtmir/10/artifact/results/log/*view*/
[19:15] <anpok_> fginther: ah - of course we have to load a driver in nested mode too!
[19:16] <anpok_> fginther: so for both mir based servers we would have to install the android drivers from -proposed
[19:17] <fginther> anpok_, ack, let me try to fix this while the packages are still in proposed (if they are still there...)
[19:17] <robru> brb
[19:18] <anpok_> thx
[19:31] <dobey> trainguards: can someone please hit rebuild on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-043/+build/7719435 ?
[19:40] <robru> dobey: one sec
[19:48] <dobey> robru: how did you only rebuild the armhf version via jenkins?
[19:48] <dobey> robru: is that what watch only does?
[19:49] <robru> dobey: nope, jenkins does nothing. I rebuilt via lp ppa page. then I triggered a WATCH_ONLY build, solely for the purpose of getting you an IRC ping when the build is finished.
[19:49] <dobey> ah ok
[19:49] <robru> dobey: there's some talk about making jenkins able to do this for you but it's all theoretical at this point and there's other priorities.
[19:50] <dobey> sure. was just curious since i saw the new job run :)
[20:14] <dobey> anpok_: hmm, is mir 0.14.0 landing in wily now? it seems to be in proposed but the silo status doesn't seem to indicate it's there?
[20:25] <anpok_> dobey: yes because I rebuilt stuff in the mean time trying to workaround the boottest issue - see discussion above
[20:26] <anpok_> O_O
[20:26] <anpok_> wily
[20:28] <dobey> anpok_: will there be uploads of that into the gcc5 silo as well?
[20:28] <anpok_> i thought we would take the most recent silo004 build instead
[20:28] <anpok_> because it has the most recent gcc5 fixes
[20:29] <dobey> anpok_: but it still must be rebuilt against gcc5