[01:55] <bfiller> robru: around to publish ubuntu silo 13? and make silos for line 49 and 50?
[01:56] <robru> bfiller: one sec
[02:29] <robru> bfiller: sorry about that, everything's exploding.
[02:29] <robru> 4 and 9
[02:30] <bfiller> robru: no worries, thank you
[04:12] <dobey> ToyKeeper: sorry. all the fix committed bugs at https://bugs.launchpad.net/pay-ui (plus translations updates). revisions 83-90 at https://code.launchpad.net/~unity-api-team/pay-ui/first-branch
[04:24]  * dobey goes off to other things again
[05:46] <ToyKeeper> dobey: I'm not sure how we officially mark click packages as approved, but yours is tested and looks good.
[05:46] <ToyKeeper> (we're hoping to develop the process for this more in the near future, but for now it's mostly ad-hoc)
[05:48] <Mirv> morning
[09:15] <satoris> Anyone know why system-image-cli -i says I run version 0 but the flasher log says it pushed version 56? This is on mako, on krillin it worked fine.
[09:45] <satoris> Who would have the necessary powers to approve packaging changes? Line 19 needs an ack for that. Thanks.
[09:49] <Mirv> satoris: we'd need an archive admin to preNEW approve the new binary package, and I've asked for it on #ubuntu-release. normal core-dev ack not enough in such cases.
[09:52] <satoris> Mirv: cool. Is there anything else that I can/need do to for this issue?
[09:52] <Mirv> satoris: if you have a friendly archive admin you can ping someone directly, otherwise no.
[09:59] <sil2100> ;)
[10:52] <sil2100> hmmm
[10:52] <sil2100> I wonder what we should do with the lack of changes/commitlogs now that imgbot is down
[10:55] <davmor2> sil2100: I'm surprised at ogra_ not putting imgbot on the stack
[10:55] <sil2100> That was one of the few things we had on a TODO list, but I guess that never happened
[10:56] <sil2100> My commitlog generation scripts are on canonistack
[10:56] <sil2100> (with an RT still waiting to enable auto-synchronization of that)
[10:57] <davmor2> sil2100: muhahahahahahaha
[10:58] <sil2100> Yeah, the RT is actually waiting there for months already
[11:29] <davmor2> sil2100: silo011 just failed
[11:29] <sil2100> davmor2: aw come on
[11:29] <sil2100> Regressed?
[11:30] <davmor2> sil2100: nope just didn't fix the bug in the steps that john-mcaleely added in the description
[11:30] <john-mcaleely> davmor2, did i? which bug?
[11:31] <davmor2> john-mcaleely: https://bugs.launchpad.net/barajas/+bug/1399769
[11:31] <john-mcaleely> davmor2, just read. shame silo11 doesn't fix it :-(
[11:31] <davmor2> sil2100: I added how I tested so the dev can hopefully reproduce it
[11:36] <davmor2> john-mcaleely: by the way bug only happens if the sims are unlocked so I added that as a step as most European countries lock the sims by default.  Might be wht the dev couldn't reproduce it initially maybe.
[11:37] <john-mcaleely> davmor2, maybe, although I thought joc had seen it with locked SIMs as well. Presumably with different repro steps
[11:38] <davmor2> john-mcaleely: possibly but it only listed lock on open and wifi enabled I didn't see sim lock.
[11:39] <john-mcaleely> ok
[11:41] <davmor2> john-mcaleely: the sim unlock on both sims takes an age and therefore leaves you in the state of it working :)
[11:42] <john-mcaleely> possibly so :-)
[12:05] <Mirv> chrisccoulson: would you have time for https://code.launchpad.net/~timo-jyrinki/oxide/arch_specific_replaces_lp1400275/+merge/244307 at some point? I couldn't get the adt-run to work for me so it's not certain if it keeps the autopkgtest fixed, but of course it would again fix your problem of having the intended dependency order.
[12:05] <Mirv> the oxide has been sitting in silo 017 since last week
[12:26] <joc_> davmor2: john-mcaleely: i have not been convinced this is a race condition (see my last comment on that bug), and I have definitely seen it with locked SIMs in
[12:27] <joc_> and by race I mean getting through the wizard really quickly
[12:27] <davmor2> joc_: nice I miss read it then
[12:28] <ogra_> sil2100, sorry, i messed up big time while doing a backup of the imgbot dir (note: tar czvf is *not* tar xzvf ... i unpacked an old version instead of rolling a new upgraded tarball from teh workdir) ... it should be back later today
[12:28] <john-mcaleely> I agree joc - from cold start (only possible with flash tool, it seems), this seems to occur sometimes 'at normal pace' in the wizard
[12:30] <sil2100> ogra_: \o/ :)
[12:30] <sil2100> ogra_: heh, no worries
[12:34] <ogra_> sil2100, note that only the linking is broken ... the changelogs get still produced http://people.canonical.com/~ogra/touch-image-stats/rtm/20141216.changes is 178
[12:45] <ogra_> and here is the linked one http://people.canonical.com/~ogra/touch-image-stats/rtm/180.changes ... seems there were a few tarballs actually
[13:12] <davmor2> joc_: hmm fair enough I can confirm using john-mcaleely steps lead me to the issue though, were you using 2 sims too I wonder if the dev is only using one?
[13:17] <sil2100> ogra_: thanks!
[13:17]  * sil2100 goes to lunch
[13:19] <jibel> bfiller, Hey, in silo 6 the version of gallery-app you ask us to test is 2.9.1.1049 (jenkins build #184) but 2.9.1.1101 is in the store. Is it correct?
[13:37] <Mirv> bregma: I haven't found a core-dev to ack your compiz multi-arch changes so far, hopefully better luck during US Timezone. (if a core-dev reads this, https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141210.2-0ubuntu1.diff )
[13:37] <bregma> people become core devs and immediately become lazy and stop contributing to Ubuntu :)
[13:37] <bregma> maybe I should apply
[13:37] <Mirv> pstolowski: pete-woods: not top-approved https://code.launchpad.net/~stolowski/unity-scopes-shell/partner-id-rtm/+merge/240746
[13:38] <Mirv> :)
[13:38] <pete-woods> hmm, I don't seem to have the right to top-approve
[13:38] <pete-woods> oh wait
[13:38] <pete-woods> wrong browser
[13:38] <Mirv> pete-woods: thanks!
[13:59] <rsalveti> ogra_: sil2100: got a meta change at silo 2, adding missing gstreamer0.10-pulseaudio
[13:59] <rsalveti> no other side effect, should we still require qa sign off?
[14:00] <sil2100> rsalveti: what was the side effect of this package missing from the seeds?
[14:01] <rsalveti> sil2100: unable to record audio from a qml/qt app (using qtmultimedia)
[14:01] <sil2100> rsalveti: I would say no sign-off required, as any regression there is still better than no feature at all - but let's ask jibel for a final word
[14:01] <sil2100> jibel: ^ ?
[14:02] <dobey> ToyKeeper: great, thanks
[14:03] <jibel> sil2100, rsalveti +1 for no sign-off if it adds a package to the seed.
[14:06] <rsalveti> alright, thanks
[14:07] <bfiller> jibel: yes it's correct, it's from the rtm branch not from trunk
[14:07] <bfiller> jibel: not sure how we will upload it with a lower version number though
[14:09] <joc_> davmor2: really you have to be using 2 SIMs - you don't need to seleect which SIM you want to use if there is only 1 SIM
[14:09] <jibel> bfiller, okay. Then 1049 introduces regression and makes the gallery-app crashes
[14:10] <jibel> bfiller, see my comment in bug 1381583
[14:14] <bfiller> jibel: ok, there is no core file in the error. Can you list the exact steps to reproduce in the bug please. Also does this bug exist in previous versions?
[14:15] <jibel> bfiller, it doesn't exist with the version in 180, I'll add more details.
[14:15] <bfiller> jibel: thanks
[14:23] <dobey> cihelp: can we get someone to upload https://jenkins.qa.ubuntu.com/job/generic-click-builder-vivid-armhf/75/artifact/output/com.canonical.payui_0.4.3_armhf.click to the store please?
[14:24] <fginther> dobey, I can help with that
[14:27] <dobey> fginther: ah, i wasn't expecting you to be around yet. that would be great, thanks
[14:38] <sil2100> bfiller: hey!
[14:39] <sil2100> bfiller: I had a question - what's the current release workflow for gallery-app? Do you always first release the .deb version and then create the click package and upload?
[14:39] <sil2100> bfiller: or are there cases when you released a new click package without the .deb package?
[14:41] <bfiller> sil2100: we release the deb and then upload a new click once the changes land in trunk. in the case of rtm, we'll do the same thing. deb then once changes land in rtm branch create and upload a click
[14:43] <sil2100> bfiller: remember that there's only one store right now, so basically what you release to the store is == (vivid && 14.09)
[14:43] <sil2100> bfiller: but I heard from QA that they had some issues with the gallery-app silo, did they get back to you?
[14:43] <bfiller> sil2100: I know
[14:44] <bfiller> sil2100: we've been landing on trunk and only releasing debs and not updating the click because of this limitation
[14:44] <bfiller> sil2100: will only update the click once QA signs off on the silo
[14:46] <renatu> sil2100, do you know what could cause this error: process 31428: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory
[14:46] <renatu> sil2100, full log: https://launchpadlibrarian.net/192784269/buildlog_ubuntu-rtm-14.09-armhf.address-book-app_0.2%2B15.04.20141216~rtm-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:49] <jibel> bfiller, I added a test case in comment 9
[14:50] <jibel> there is probably a shorter test, but with this one it's easy to reproduce.
[14:53] <davmor2> bfiller: https://bugs.launchpad.net/barajas/+bug/1399769 this bug in silo 11 when I tested this morning it wasn't fixed at all, then there was an update to the silo now it changes the label to sim1 sim2 however if I select one I still have an unusable phone it sends nothing and receives nothing till I reboot
[14:55] <davmor2> bfiller: reset and wiped the phone 3 times to confirm it is reproducible and it is
[14:56] <bfiller> davmor2: huh? the silo hasn't been updated since yesterday
[14:57] <davmor2> bfiller: got updated about an hour ago
[14:57] <bfiller> davmor2: shouldn't have
[14:57] <sil2100> jibel, davmor2: I need to skip today's evening landing meeting - in case there are some things (updates) related to image promotion, use bug LP: #1402601 to keep track
[14:57] <davmor2> bfiller: or our ticketing system is lying to us
[14:57] <bfiller> davmor2: looks like boiko_ rebuilt it but not sure why
[14:58] <davmor2> bfiller: well it added the telephony stuff
[14:58] <boiko_> bfiller: silo 11? tiago asked me to rebuild that one
[14:59] <bfiller> davmor2: let me find out what's going on. I tested it yesterday so not sure what changed since then
[14:59] <boiko> salem_`: can you tell davmor2 and bfiller what changed on silo 11?
[15:00] <salem_`> davmor2, hey, I was able to reproduce the problem with the steps you provided and pushed a fix this morning to silo 11. can you try updating the packages?
[15:01] <davmor2> salem_`: I did a fresh install and installed the silo afresh, now the labels read sim1 sim2 however if I select one and try sending a message it does nothing, also if I try sending to the number it does nothing until  I reboot
[15:02] <salem_`> davmor2, ok, let me look into it.
[15:02] <davmor2> salem_`: thanks
[15:02] <davmor2> salem_`: same steps but you just select one and then send a message
[15:03] <salem_`> davmor2, ok, let me try
[15:18] <mzanetti> ffs
[15:21] <renatu> hey guys I am getting this error on rtm silo 0: process 22576: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory
[15:21] <renatu> who can help me with that?
[15:24] <sil2100> renatu: looks strange - if it's an internal problem then we would really need someone that manages the build machines to look into that
[15:24] <sil2100> renatu: maybe we should try a re-build? Or did you ask someone for that already?
[15:26] <renatu> sil2100, in the first build it fails on amd64 and arm. the second one fails only on arm
[15:26] <renatu> sil2100, lets try again
[15:26] <sil2100> renatu: oh, ok, wait
[15:26] <sil2100> Let me re-run it in the PPA
[15:27] <sil2100> Let's not waste resources
[15:27] <sil2100> renatu: which silo is that in?
[15:27] <renatu> sil2100, the same code was already merged on vivid
[15:27] <renatu> sil2100, rtm 0
[15:28] <sil2100> renatu: ok, it's rebuilding, let's see how it goes
[15:28] <sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-000/+build/6653160
[16:03] <sil2100> renatu: hm, failed again
[16:03] <sil2100> renatu: strange, it failed on 2 different machines even
[16:35] <sil2100> robru, jibel, davmor2, rvr: remember that today we don't have the landing meeting
[16:35] <sil2100> Please use the LP bug I pasted above in case of some promotion-related talks
[16:36] <jibel> sil2100, k, thanks.
[16:36] <rvr> sil2100: Ack
[16:36] <davmor2> sil2100: no we are just going to ignore completely ;)
[16:37]  * sil2100 will be back in ~2h
[17:36] <renatu> sil2100, do you want me to disable the failing test?
[17:39] <bfiller> fginther: you around?
[17:39] <fginther> bfiller, yes
[17:40] <bfiller> fginther: getting this failure in ubuntu-rtm ppa, looks like something in the env https://launchpadlibrarian.net/192794818/buildlog_ubuntu-rtm-14.09-armhf.address-book-app_0.2%2B15.04.20141216.2~rtm-0ubuntu1_FAILEDTOBUILD.txt.gz
[17:41] <bfiller> fginther: process 17066: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory
[17:41] <bfiller> See the manual page for dbus-uuidgen to correct this issue.
[17:41] <bfiller> only happens on armhf
[17:45] <fginther> bfiller, this is more of a question for the trainguards or perhaps cjwatson. This build is taking place on launchpad.
[17:45] <robru> bfiller: fginther: yep not me, it's in lp, not in the train. ;-)
[17:46] <alesage> ci-help finding that kenvandine's branch is still executing a test that's he's trying to explicitly skip: the MP is here https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/less_flaky/+merge/242957 , adding this commit on the eleventh http://bazaar.launchpad.net/~ken-vandine/ubuntu-system-settings/less_flaky/revision/1223 , here's a recent run with that test failed https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-
[17:46] <alesage> mako/497/
[17:47] <alesage> I've double-checked the test name just to be sure :)
[17:47] <fginther> bfiller, I'm assuming this test is setting up it's own dbus as that wouldn't otherwise be part of the build environment
[17:47] <bfiller> renatu: ^^ is that the case?
[17:48] <fginther> alesage, looking
[17:48] <bfiller> renatu: maybe it's a problem how you are setting up dbus?
[17:48] <renatu> bfiller, fginther, let me check
[17:48] <fginther> renatu, bfiller, this error also looks interesting: "libEGL warning: GLX/DRI2 is not supported"
[17:49] <fginther> although it may not be a factor
[17:49] <renatu> fginther, bfiller I am not setting any dbus session just importing onlineaccount that uses dbus
[17:50] <renatu> fginther, it is already integrated on vivid and this is a old test, have been running for a while
[17:54] <fginther> alesage, I'll take a closer look in a bit
[17:55] <alesage> fginther, FWIW finding we're unable to skip locally as well, CI may not be implicated :)
[17:55] <fginther> renatu, The only other advice I have right now is to find the last time this test passed under ubuntu-rtm in launchpad and compare the build logs. Perhaps a dependency changed and introduced a regression.
[17:56] <fginther> alesage, ok, I'll sync up with you after my lunch
[17:58] <cjwatson> renatu: shouldn't you be using dbus-test-runner or something?
[17:58] <cjwatson> I don't think LP promises that a machine-id is set up
[17:59] <dbarth> hello trainguards; i have a desktop sru candidate on line 63 (starting with vivid though)
[17:59] <renatu> cjwatson, since I am only importing the module and not using it , I was trying to avoid that
[17:59] <cjwatson> well, I'm not aware that anything has changed in LP build chroots here anyway
[18:00] <renatu> cjwatson, it fails on amd64 in the first build
[18:00] <renatu> cjwatson, now is faling only on armhf
[18:00] <robru> dbarth: vivid 7
[18:00] <cjwatson> renatu: *shrug* could be a racy test
[18:00] <cjwatson> renatu: please tell me you aren't repeatedly hitting Build in CI Train
[18:01] <renatu> cjwatson, we are trying one last time
[18:01] <cjwatson> renatu: stop it
[18:01] <cjwatson> bah
[18:01] <cjwatson> renatu: don't do it like that in future, please, it's a waste of resources
[18:02] <cjwatson> renatu: anyone in ~ci-train-ppa-service can retry builds for *individual* architectures in the PPA, and then you can do a watch-only build once they've all passed
[18:02] <cjwatson> renatu: your approach wastes shared resources and has a lower probability of succeeding :)
[18:03] <renatu> cjwatson, ok I will do that next time, sorry
[18:03] <renatu> cjwatson, do you think that dbust-test-runner could fix the problem?
[18:04] <renatu> cjwatson, I think it will need to read "/etc/machine-id"too
[18:04] <cjwatson> renatu: don't know
[18:04] <cjwatson> just a guess
[18:04] <cjwatson> since it's racy you probably have an ordering problem somewhere, but not my field
[18:05] <cjwatson> you should probably try it repeatedly in clean chroots outside of LP
[18:05] <renatu> cjwatson, dbus-test-runner just create a individual dbus instance but uses the same files
[18:05] <renatu> cjwatson, how I can create a chroot without the "/etc/machine-id" file
[18:05] <renatu> I do not know how to prevent this file to be created
[18:06] <cjwatson> renatu: mk-sbuild
[18:06] <cjwatson> https://wiki.ubuntu.com/SimpleSbuild
[18:06] <cjwatson> <cjwatson@amber ~ (master)>$ ls -l /var/lib/schroot/chroots/vivid-*/etc/machine-id
[18:06] <cjwatson> ls: cannot access /var/lib/schroot/chroots/vivid-*/etc/machine-id: No such file or directory
[18:08] <dbarth> robru: thanks! did you recognize that old bug fix; now the packagekit issue has been fixed by justin
[18:08] <cjwatson> renatu: oh, or you could just build-depend on dbus
[18:08] <cjwatson> renatu: you apparently don't, and it's dbus.postinst that runs "dbus-uuidgen --ensure", thereby creating /etc/machine-id
[18:09] <robru> dbarth: haha, very nice
[18:10] <cjwatson> renatu: if I were you I'd still want to understand the race though ...
[18:13] <cwayne> cihelp ping!
[18:14] <Ursinha> cwayne: what's up
[18:15] <cwayne> Ursinha: wondering if somethings up with calxeda-pbuilder, or if it's just busy? went to build a custom tarball and it says waiting for next available executor
[18:16] <Ursinha> cwayne: let me check..
[18:16] <john-mcaleely> cihelp, new device tarball for vivid
[18:16] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20141216-4061a26.tar.xz
[18:16] <renatu> cjwatson,thanks, I will add dbus as build dep. But I still confuse why this is working for other builds (i386 and amd64)
[18:16] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20141216-4061a26.changes
[18:16] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20141216-4061a26.ods
[18:16] <cjwatson> renatu: well, it didn't work for amd64 before as you said, so it's not about the architecture, you have a race
[18:16] <john-mcaleely> want to do any sign off or can I push on the basis that it passes my usual testing?
[18:16] <john-mcaleely> sil2100, ^
[18:17] <cjwatson> renatu: if your test suite is non-deterministic then it will indeed sometimes pass on some architectures and not others just as a matter of probability ...
[18:20] <john-mcaleely> rsalveti, ^ vivid tarball with tip of master should land soon
[18:32] <bfiller> robru: can you kick off an arm only build on rtm 000 please?
[18:32] <bfiller> I don't know how to do that
[18:33] <robru> bfiller: citrain doesn't have any way to do that, unless you want to just rebuild the last arm build that was done (eg, without any new commits since the last build)
[18:34] <bfiller> robru: we added a build-dep
[18:34] <robru> bfiller: yeah, new commit will need to be rebuilt on all arches.
[18:35] <bfiller> robru: ok
[18:38] <rsalveti> john-mcaleely: thanks
[18:39] <rsalveti> sil2100: can I publish rtm silo 12? or are you waiting to coordinate a new image or a new landing first?
[18:44] <Ursinha> cwayne: do you have the link to the job that is hanging?
[19:00] <robru> pstolowski: you got silo 3 but just be aware you have conflicts in silo 7. whoever publishes first will force the other to rebuild and retest.
[19:00] <robru> silo rtm 3 I mean
[19:01] <pstolowski> robru, yes, i'm aware of that. thanks
[19:01] <robru> pstolowski: you're welcome
[19:42] <salem_`> davmor2, hey, could you update your phone with silo 11 and try again?
[19:43] <davmor2> salem_`: just testing another silo but I can look after that
[19:45] <salem_`> davmor2, sure, thanks!
[20:12] <davmor2> mzanetti: you about dude?
[20:12] <mzanetti> davmor2: hey
[20:15] <davmor2> mzanetti: I have question for silo7 now that camera has removed the permissions requirement is there another way to trigger this that isn't a script, which I think is how the dev has fixed it? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1381292
[20:18] <pmcgowan> davmor2, check the dupes for that bug, webapps show it as well
[20:18] <davmor2> pmcgowan: ah fantastic thanks
[20:18] <davmor2> mzanetti: as you were :)
[20:19] <mzanetti> davmor2: here's an app: https://code.launchpad.net/~josharenson/+junk/trustStoreDialogFocusTest
[20:22] <fginther> cwayne, your builds are ready now
[20:24] <cwayne> fginther: thank you
[20:36] <sil2100> oooh! Silo 007 can be published?
[20:36]  * sil2100 publishes
[20:37] <pmcgowan> woot
[20:40] <pmcgowan> oh can't publish
[20:41] <sil2100> Yeah, need a core dev to check those
[20:41] <sil2100> slangasek: hey! Are you still around? :)
[20:42] <slangasek> sil2100: hi there
[20:42] <slangasek> what silo?
[20:42] <sil2100> slangasek: could you help out and do a packaging ACK on silo 007? https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-007-2-publish/26/ <- the packaging diffs are here
[20:42] <sil2100> (only the latest version of each package)
[20:43] <slangasek> reviewing
[20:44] <sil2100> Thanks!
[20:44] <davmor2> salem_`: that fixed it \o/
[20:45] <slangasek> why does https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-007-2-publish/26/artifact/packaging_changes_unity-scopes-api_0.6.9+15.04.20141216~rtm-0ubuntu1.diff have doubled-up contents?
[20:45] <salem_`> davmor2, awesome! thanks!
[20:45] <salem_`> bfiller, ^
[20:45] <slangasek> (or more)
[20:45] <robru> slangasek: uh....
[20:46] <robru> slangasek: oh that's probably some rubbish regression. i can't imagine why it would be appending that diff rather than truncating. or even why it would be generating that diff more than once. anyway I think you can trust that the diff is good, just ignore the duplicated bits. I'll fix that after we can deploy to production again
[20:47] <bfiller> salem_`: nice
[20:47] <slangasek> robru: I am ignoring the duplicated bits, yes.  Do you want a bug report about this?
[20:47] <robru> slangasek: yes please, and assign it to me
[20:47] <slangasek> robru: remind me what project I should use? launchpad/ubuntu-lt?
[20:48] <robru> slangasek: please file that against cupstream2distro
[20:49]  * robru -> lunch
[20:50] <slangasek> sil2100: how did unity-scopes-shell successfully build in this ppa?  It adds a versioned build-dependency on libunity-api-dev (>= 7.94~), but the version of libunity-api-dev in ubuntu-rtm/14.09 is 7.92
[20:51] <sil2100> slangasek: the PPA has the new libunity-api in it
[20:51] <sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-007
[20:51] <slangasek> ah, but that version has no packaging diff, ok
[20:51] <sil2100> It's just has no packaging changes, so the diff didn't appear
[20:52] <cwayne> sil2100: ping!
[20:52] <sil2100> cwayne: pong! Hi! What's up?
[20:53] <cwayne> sil2100: heya, so I'm hoping to have a new custom (with a really small delta) ready in about 30 mins or so -- is that too late to try to get it in for this week's promotion?
[20:53] <slangasek> sil2100, pmcgowan: packaging approved and published
[20:53] <pmcgowan> awesome
[20:54] <sil2100> cwayne: I think it should be good - does it fix some of our criticals? I suppose QA might have the capacity for that today still
[20:54] <sil2100> davmor2: do you know who we have around in the US?
[20:54] <sil2100> davmor2: for silo/tarball sign-off>?
[20:55] <davmor2> sil2100: ToyKeeper at a guess and maybe iahmad for a while too
[20:55] <cwayne> sil2100: it fixes two hanloon criticals :)
[20:55] <sil2100> cwayne: excellent o/
[20:55] <ToyKeeper> If it's higher priority than the waiting silos, I can start on it.
[20:55] <sil2100> davmor2: when you EOD? Pretty soon I guess, right?
[20:57] <cwayne> i'm happy to have it punted to tomorrow morning if you guys are, just thought that might technically be post-freeze :)
[20:58] <ToyKeeper> cwayne: What does it fix/change?
[20:59] <cwayne> ToyKeeper: it adds the ability to login to online accounts from a result in the scope, which fixes bug 1394217, bug 1402664, and bug 1402661
[21:00] <ToyKeeper> cwayne: That'll be customized image 254?
[21:01] <cwayne> ToyKeeper: yeah should be, tarball should be done in about 8 minutes or so
[21:01] <cwayne> so unless a rootfs drops int he next 8 minutes then yep :)
[21:02] <ToyKeeper> cwayne: Sounds good, lemme know when it's ready in the custom feed.
[21:03] <cwayne> ToyKeeper: will do, I'll also send out an email to qa-team (as suggested by davmor2) with the complete changelog
[21:03] <davmor2> cwayne: thanks
[21:03] <davmor2> sil2100: an hour ago
[21:03] <cwayne> would need someone to check over the es image too (it has the exact same changelog though)
[21:04] <davmor2> cwayne: yes
[21:04] <cwayne> yep, just making sure we're all on the same page :)
[21:04] <davmor2> cwayne: best person for that would be Victor who won't be on now till the morning
[21:04] <cwayne> davmor2: well, no strings or anything have changed, so it'd really just be making sure nothing's obviously broken
[21:15] <sil2100> slangasek: thank you! :)
[21:16] <cwayne> ToyKeeper: it seems to be ready, but I'd like to flash it first just to verify to ensure I don't waste anyone's time :)
[21:23] <cwayne> ToyKeeper: okay so there's an issue, need a quick rebuild :/  Ill send out the email soon as I verify its working as I expect it to
[21:25] <pmcgowan> davmor2, silo 11 is approved then?
[21:27] <ToyKeeper> cwayne: Okay, I'll be expecting it.  :)
[21:33] <sil2100> pmcgowan: btw.! Just so you know, we might have issues with commitlogs
[21:33] <sil2100> pmcgowan: I mean, ogra_'s bot was down so there are some vivid ones missing
[21:33] <sil2100> But I hope no more will be lost
[21:36] <pmcgowan> sil2100, ack
[21:37] <pmcgowan> sil2100, that probably needs to become a more formal CI tool
[21:38] <sil2100> pmcgowan: yeah, I already have an RT for part of it... but we would need to get ogra_'s bits somewhere public as well
[21:40] <bfiller> davmor2: we are good on silo 11, so I think it's ready to be publish if you are good with it
[21:57] <cwayne> ToyKeeper: email sent, 255 is the one :)
[21:57] <cwayne> oh a mod needs to approve my qa-team email :/
[21:57] <ToyKeeper> cwayne: Thanks!
[21:58] <ToyKeeper> Not sure if I can approve the message, but I'll try.
[21:58] <cwayne> ToyKeeper: if not I can just explictly email you victor and dave for now
[21:59] <ToyKeeper> cwayne: Nope, I don't have moderator access.
[21:59] <cwayne> ToyKeeper: no worries, will resend
[22:00] <cwayne> re-sent
[22:01] <cwayne> now I need to go run some errands, will have my phone with email though, so feel free to shoot me an email if there's an issue
[22:28] <davmor2> bfiller: silo 11 works but has had a full test I left a note on the ticket in the kanban board that says as much
[22:28] <davmor2> has not had even
[22:29] <davmor2> bfiller: I ran out of day unfortunately
[22:29] <bfiller> davmor2: no worries, thanks
[22:30] <davmor2> bfiller: it should just need a quick test tomorrow by whoever picks it up and should be able to land then
[22:31] <davmor2> I'm not in tomorrow tjough so it might be brendand or rvr
[22:32] <davmor2> goes back offline
[22:51] <pstolowski> hey cihelp, can somebody help me understand what's wrong (if anything) with build in rtm silo 01?
[22:53] <fginther> trainguards, is this ^ something you can answer?
[22:54] <fginther> pstolowski, I'm not seeing any errors or failures, do you have a link?
[22:55] <pstolowski> fginther, trainguards nvm, it looks like status wasn't picked up correctly by both spreadsheet and dashboard for a bit longer than usual
[22:55] <pstolowski> fginther, so yes, looks ok now. thanks
[22:55] <fginther> psivaa_, ack
[22:55] <fginther> pstolowski, ack
[22:55] <fginther> psivaa_, oops, please ignore
[23:47] <cwayne-afk> ToyKeeper: thanks for testing! you did not do the spanish, correct?