[00:07] <robru> camako: oh were you having trouble with device-upgrade? can you tell me what happened? was there an error message?
[02:21] <veebers> cihelp, what's the easiest way to check the difference complained by this error? https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-008-1-build/84/console as far as I'm aware the branch I'm proposing for rtm is the most up to date and rtm shouldn't contain anything not in it
[02:21] <veebers> unless I missunderstood the error message
[02:22] <thomi> veebers: I believe it just goes by version numbers?
[02:22] <thomi> I don't think it actually compares contents, but I could be wrong
[02:22] <thomi> so, check version number in RTM, and version number in d/changelog
[02:22] <veebers> thomi: ah, I think you;re right
[02:22] <thomi> my bet is that someone has (yet again) uploaded a version of ap without contributing it to lp:autopilot
[02:22] <veebers> thomi: the message is a clue :-P A version (1.5.0+14.10.20141022~rtm-0ubuntu1) is available at the destination archive for that component but is not in the destination branch which is still at 1.5.0+14.10.20140806-0ubuntu1
[02:22] <thomi> which... grrrrr...
[02:23] <thomi> there you go
[02:23] <veebers> thomi: I need to grab the change for RTM so I can see what happened (and merge them in I guess
[02:23] <veebers> )
[02:23] <thomi> exactly
[02:24] <thomi> then find o0ut who uploaded it and ask them not to do that again
[02:25] <veebers> thomi: ack
[02:30] <veebers> thomi: ugh, I'm pretty sure it's because I screwed it up. I took it from trunk and not the 1.5 release (which is what was released into RTM originally anyway)
[02:30] <veebers> thomi: I'll fix that up right now
[02:31] <thomi> ahhh well, at least it's not another case of someone else uploading for you
[02:31] <veebers> thomi: aye
[02:51] <veebers> Ugh, screwed it up again
[02:56] <veebers> cihelp/trainguards: For the error of generating an empty changelog file, I should be able to force that through (or use a different option) right? I'm trying to sync what was released into vivid into RTM: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-008-1-build/85/console
[03:05] <imgbot> [03:12] <robru> veebers: no you can't force that one. You need to either fix your changelog or not touch changelog in your mp. Why are you even doing an mp? Shouldn't it be a sync silo?
[03:13] <veebers> robru: um, oh. I'm doing a MP as that's what I thought I needed to do :-P What's the process for a sync silo? :_)
[03:15] <robru> veebers: well I'm not sure, it depends on the project and what you're doing. If you're cherry picking, you need an mp. If you've done mps before then i guys you breed to keep doing mps. Has rtm diverged from vivid?
[03:16] <robru> Ugh, phone. "I guess you need"
[03:16] <veebers> robru: as far as I'm aware rtm hasn't diverged. I'm trying to get changes into RTM that went into vivid at the end of the year but only went into vivid
[03:18] <veebers> No, rtm hasn't diverged
[03:19] <robru> veebers: is there an rtm branch that has different versions than the trunk branch?
[03:19] <robru> In the Debian/changelog
[03:20] <veebers> robru: no, up until this release what was in rtm is what was in the release branch. (I created an rtm branch in an attempt to do the MP release into rtm)
[03:21] <robru> veebers: oh OK, if you creatures the rtm branch just now, i don't think it's necessary ;-)
[03:21] <veebers> robru: heh creatures. RIght so you're saying the rtm branch isn't needed and we should do a sync of some sort for rtm?
[03:22] <robru> veebers: change your spreadsheet row, blank out the mp, set the sources as "sync:ubuntu,vivid autopilot" then I'll reconfigure
[03:22] <veebers> robru: ack, awesome thanks
[03:24] <veebers> robru: sources as in "Additional source packages to land"?
[03:24] <robru> veebers: yeah
[03:24] <veebers> robru: awesome, done :-)
[03:26] <robru> veebers: ok try building now
[03:26]  * veebers does so
[03:54] <veebers> robru: ugh, perhaps I screwed something else up again? https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-008-1-build/86/console
[03:54] <veebers> 2015-01-08 03:49:51,226 ERROR Versions in PPA did not match our expectations.
[03:56] <robru> Well shit
[03:56] <robru> The build job uploaded two different versions... Wtf? The build job is supposed to delete crap before building new crap
[03:57] <veebers> heh
[03:58] <robru> veebers: i can't fix this... At least not anytime soon. The only thing to do is dump the silo and start a new one. Hang on, and sorry.
[03:58] <veebers> robru: no worries, thanks for sorting it out
[04:02] <robru> veebers: ok you're in rtm 9 now, please try again
[04:02] <veebers> robru: coolio will do now
[04:10] <robru> veebers: and, bug filed https://bugs.launchpad.net/cupstream2distro/+bug/1408543
[04:11] <veebers> robru: sweet thanks
[04:11] <robru> veebers: not sure when I'll have time to get to that one, lots of other stuff going on right now. but I do intend to rewrite the build job Soon-ish(TM) and that would get fixed along the way.
[04:12] <veebers> robru: heh, awesome. Well hopefully next time I do something similar I won't screw up the first couple of attempts to I won't trigger this bug again :-)
[04:22] <veebers> robru: sweet, looks like that's worked this time
[04:25] <imgbot> [04:25] <imgbot> [04:27] <robru> veebers: sweet, glad that works
[04:39] <veebers> robru: hey one more silly question, if I'm testing this for rtm I should use the channel 'ubuntu-touch/stable' as opposed to 'ubuntu-touch/vivid-proposed' right?
[04:41] <veebers> ugh nvm answered my own question. Time for food I think
[05:41] <Mirv> mornings
[06:34] <camako> cihelp, is there a way to delete the older version of a package in a silo? I.e. I only want the most recently build version of mir ---> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-017
[06:37] <Mirv> camako: that's a trainguards question, and those will disappear from sight automatically after that "Published" column gets filled in a few minutes
[06:38] <Mirv> technically the older versions are still there, but after the archive information gets updated about 20 minutes after build is ready, only the latest version is available to PPA users
[06:39] <camako> Mirv, which published column?
[06:40] <camako> And the newer version has been available for hours now but the older version is still visible
[06:42] <Mirv> camako: oh, sorry, on the "View package details page"
[06:43] <Mirv> camako: but you're right, there's something wrong
[06:43] <Mirv> so, that's what normally happens. I believe something is now truly broken in that PPA or in general
[06:43] <camako> Mirv, ok I see
[06:43] <Mirv> basically the publisher run does not seem to happen
[06:44] <Mirv> I can't help with that level of infrastructure, so calling out a bit..
[06:45] <camako> Mirv, thanks for your help
[06:59] <camako> Mirv, I'm about to go to bed.. Will you be following this up? If not, who do you think I should talk to tomorrow to get this fixed?
[07:23] <Mirv> camako: I will be looking at this, since it probably affects others too. I'm currently building myself in a silo so first I'll see if all silos are affected.
[07:37] <Mirv> confirming that the PPA:s are broken at the moment and filed an issue ticket
[08:51] <mardy> I'm a bit confused, why are the tests run twice here? (and why do they fail the second time?) https://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-online-accounts-vivid-amd64-ci/3/consoleFull
[09:15] <Mirv> mvo: how did it go with the oxide/clickchroot?
[09:16] <Mirv> mardy: you'd need cihelp for that - the other run is after package building, some coverage related job that probably doesn't use xvfb-run for its tests
[09:17] <vila> mardy, Mirv : looking
[09:17] <mvo> Mirv: finished last night successfully, I will publish
[09:18] <Mirv> mvo: \o/
[09:18] <Mirv> hey vila! :)
[09:19] <vila> Mirv: o! (<- holding a pen)
[09:20] <Mirv> vila: oh, right..
[09:21] <vila> Mirv: They can't kill humor (and now I'm armed too which is nice ;)
[09:30] <Mirv> uh, what's up with hangouts..
[09:30] <vila> mardy: the history for that job shows the last succesfull run was on 12 November last year. Then on 24 November, I see a commit in the branch that control those jenkins jobs: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/1216
[09:31] <vila> mardy: so in addition to Mirv comment above, you may get more feedback from envandine and seb128 ? I'll talk to fginther when he comes online too.
[09:31] <vila> *kenvandine
[09:31] <seb128> ?
[09:31] <Mirv> just some multiaccount problem
[09:32] <vila> seb128: Disable the desktop tests for lp:ubuntu-system-settings as the test environment no longer appears to support this (agreement from kenvandine and seb128). Want to get a better desktop environment in place before spending more effort on this.
[09:32] <vila> seb128: that's the commit message so I thought you may know something ;) Sorry for the noise if I'm wrong
[09:32] <seb128> vila, I'm not sure what we are talking about
[09:33] <seb128> but yeah we disabled desktop tests since there is no proper desktop testing infrastructure and those were creating noise rather than being useful
[09:33] <vila> http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-online-accounts-vivid-amd64-ci/3/consoleFull
[09:34] <vila> seb128: may be I'm misleading by mixing ubuntu-system-settings-online-accounts and ubuntu-system-settings ...
[09:34] <seb128> vila, yeah, probably, those are different components
[09:34] <seb128> dunno about the online accounts
[09:35] <mardy> vila: but anyway, that commit seems rather harmless; it's disabling tests, not adding them
[09:36] <mardy> vila: what I see, is that those tests are run with QPA_PLATFORM=minimal, and the qml tests raise some kind of GL error...
[09:36] <mardy> vila: I'm not doing anything fancy with GL myself, but maybe it's required in order to run the QML tests; in that case, using QPA_PLATFORM=minimal is probably wrong
[09:37] <vila> mardy: yeah, sorry for the mix.
[09:40] <vila> mardy: is this something that is under your control ? I'm having trouble understanding if the issue exist *before* your MP
[09:41] <vila> this == QPA_PLATFORM=minimal
[09:44] <mardy> vila: I don't think that my MP chaned anything... I'd expect that trunk fails in the same way
[09:45] <vila> mardy: ha, thanks, capital information ;)
[09:47] <Mirv> vila: mardy: for me it looked like the coverage job thing has its own "make check" run separate from anything mardy is doing, ie it's running it manually and then fails
[09:48] <Mirv> that's only a guess though
[09:49] <Mirv> vila: mardy: FWIV my latest "correct" way of doing it is xvfb-run -a -s "-screen 0 1024x768x24" dh_auto_test -- QT_PLUGIN_PATH=$(CURDIR)/plugins LD_LIBRARY_PATH=$(CURDIR)/lib QML2_IMPORT_PATH=$(CURDIR)/qml
[09:49] <Mirv> inside packaging, though
[09:49]  * vila pulls hairs
[09:49] <Mirv> QPA_PLATFORM=minimal tests "less" as it doesn't actually draw anything
[09:51] <vila> Mirv: I'm way behind your understanding ;) Is there something ci can/should do here or is it defined inside the package ?
[09:52] <Mirv> vila: looking at the log that's happening by a ci jenkins job unrelated to the packaging. the packaging finishes, then something related to coverage counting runs make check by itself.
[09:52] <Mirv> and mardy's original question was of course if it's relevant to rerun the same tests that the package anyway runs
[09:54] <Mirv> but somehow they're run and they're run differently from what the packaging is running, and fail
[09:55] <vila> Mirv: so ubuntu-system-settings-online-accounts shouldn't require coverage ? (Or something along those lines)
[09:55]  * vila stills tries to find *where* the "second" run starts in the log...
[09:57] <vila> I: user script /var/cache/pbuilder/build//24619/tmp/hooks/B09qmakecoverage starting ?
[09:59] <Saviq> trainguards, can I have a silo for line 65 please
[10:00] <Mirv> Saviq: you can, but PPA:s are currently broken
[10:00] <vila> Mirv, mardy: I'll followup with fginther later today and keep you posted
[10:01] <cjwatson> Mirv: They should be fixed now/shortly
[10:01] <cjwatson> cron.ppa is catching up on the backlog
[10:01] <Mirv> \o/
[10:01] <cjwatson> (was a crash due to a librarian outage overnight, and squid helpfully cached the 500 error for us)
[10:02] <Saviq> nice :)
[10:03] <cjwatson> Giant backlog though.
[10:05] <mardy> vila, Mirv: thanks
[10:05] <cjwatson> Mirv,camako: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-017/+packages has published now
[10:06] <Mirv> nice
[10:44] <dbarth> trainguards, hi i'm checking silo 14 which doesn't seem necessary
[10:45] <dbarth> ie, silo rtm 000 is only a backport, and the rest of the changes are already in vivid
[10:58] <Mirv> dbarth: so, vivid 014 could be freed?
[11:02] <dbarth> Mirv: yes
[11:02] <dbarth> Mirv: we already landed things on vivid
[11:03] <dbarth> Mirv: sorry my comment implied we needed a sync, but it had been done already
[11:05] <satoris> ping trainguards, could someone check that I filled line 55 correctly and get it siloed if I did?
[11:31] <Mirv> satoris: one comma too much, now assigned
[11:31] <satoris> Cool, thanks.
[11:52] <Saviq> Ursinha, hey, I filed bug #1408626 so that it's not lost, and also bug #1408627
[11:53] <Ursinha> thanks Saviq
[11:53] <Ursinha> that helps
[11:54] <Mirv> cjwatson: were you able to kick vivid image builds or is that completely in the past for you? we might try one now.
[11:57] <cjwatson> Mirv: I can
[11:58] <cjwatson> Mirv: Have the build failures been fixed then?
[12:02] <Mirv> cjwatson: they should, by a oxide-qt revert that now could be done with click better handling the chroot creation
[12:02] <Mirv> so the apt conflict/replaces are back to the state before the problems started
[12:04] <cjwatson> Mirv: ok, it's running
[12:05] <Mirv> thanks, let's see
[13:26] <om26er> dbarth, around ?
[13:29] <Saviq> trainguards, rtm silo for line 67 please?
[13:31] <Mirv> Saviq: rtm-003
[13:31] <Saviq> Mirv, thanks!
[13:31] <om26er> mardy, Hi!
[13:32] <mardy> om26er: hi!
[13:32] <om26er> mardy, regarding silo 0, there is one bug that is not approved by Olli
[13:32] <dbarth> om26er: yes
[13:33] <dbarth> om26er: i'm brining the absent bug on the radar, clear the way for the landing
[13:33] <dbarth> bringing
[13:33] <om26er> dbarth, ok, once the bug gets approved we can proceed further.
[13:34] <dbarth> ok
[13:34] <om26er> dbarth, also... the changelog on the silo ppa is not enough, it should perhaps mention the bug numbers
[13:34] <om26er> right now all it says is: 'Backport of two bugfixes:'
[13:35] <imgbot> [13:35] <imgbot> [13:36] <popey> ooh!
[13:36] <popey> oh, no changes ☹
[13:37] <rsalveti> how could, we didn't have image for days
[13:37] <rsalveti> for vivid
[13:37] <Mirv> yeah! I'm upgrading.
[13:37] <rsalveti> diff is probably wrong
[13:37] <Mirv> the diff is broken, but the image is now there
[13:37] <rsalveti> Package changes between 20150108.1 and 20150108.1
[13:37] <rsalveti> yeah
[13:37] <rsalveti> awesome
[13:38] <rsalveti> right on time
[13:38] <Mirv> the oxide think worked
[13:38] <Mirv> s/think/thing/
[13:38] <dbarth> mardy: ^^ can you update the chnage log for silo 000 please?
[13:39] <Mirv> bzoltan: we're good now on vivid, and according to mvo's testing you should (still) be as well
[13:49] <mardy> om26er: isn't the changelog automatically generated?
[13:50] <om26er> mardy, not really familiar with citrain.
[13:54] <dbarth> om26er: afaik the changelog will be updated by the landing process
[13:54] <Mirv> I'm e-mailing the mailing list with a bit of summary for this week
[13:55] <mardy> om26er, dbarth: OK, just to be sure I'll write a changelog into the MP
[13:55] <pmcgowan> om26er, silo 0 fixes fine to land
[13:55] <om26er> pmcgowan, thanks
[13:56] <dbarth> pmcgowan: thanks
[13:59] <mardy> dbarth: done, I guess you'll have to rebuild the silo
[14:01] <Mirv> I'm doing a quick landing e-mail
[14:07] <om26er> mardy, can you help me identifying bug fixes ?
[14:08] <om26er> mardy, except for bug 1384314 I am not sure how to verify other bugs.
[14:13] <om26er> dbarth, ^ can you help ?
[14:15] <mardy> om26er: the steps for another bug are here: https://bugs.launchpad.net/ubuntu-system-settings-online-accounts/+bug/1394232
[14:18] <mardy> om26er: as for the password prompt, it's the "password-query" step from https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-settings-online-accounts
[14:22] <om26er> mardy, re: 1394232 I see the dialog that says 'youtube wants to access...' but when i tap authorize, in the background I see the google login page again.
[14:22] <om26er> is that old bug ?
[14:25] <mardy> om26er: no, that's expected: the first question is about our policy, the google login page is google's requirement
[14:27] <om26er> mardy, what about bug 1380914 is that covered by a unittest ?
[14:31] <mardy> om26er: yes, that's the testRequestDelay unit test; unfortunately it's not very easy to verify that bug, otherwise
[14:32] <mardy> om26er: marcustomlinson might be able to give you steps to verify it in real life
[14:34] <om26er> well I guess we can trust our engineering with a unittest :p
[14:38]  * Mirv waits for om26er move the card to "Passed" :)
[14:38] <ogra_> popey, rsalveti, Mirv, the changelog diff mechanism uses the old manifest from cdimage ... these are only kept for 3 weeks or so ...
[14:38] <om26er> Mirv, now I did :)
[14:38] <Mirv> ogra_: ack.
[14:39] <ogra_> (so there is no old manifest to diff against anymore on cdimage ... with a bit of fiddling i can pull it from the librarian though)
[14:41] <bzoltan> Mirv: \o/
[14:42] <Mirv> mardy: since rtm, please (get) top-approve(d) https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/rtm-fixes/+merge/243134
[14:43] <Mirv> or dbarth ^
[14:57] <rsalveti> ogra_: right, you're alive :-)
[14:57] <ogra_> nah, i'm a bot :P
[15:07] <dbarth> Mirv: yes
[15:32] <bregma> cihelp, my s-jenkins jobs have been failing miserably for months now, most recently due to what looks like a network configuration error, can anyone take a look?
[15:37] <fginther> bregma, can you point us to an example to use as a starting point?
[15:41] <bregma> fginther, gladly, https://jenkins.qa.ubuntu.com/job/compiz-0.9.11-trusty-amd64-ci/74/console
[15:45] <camako> trainguards, ubuntu-vivid silo 17 (mir 0.10) is now fully tested, package issues addressed (by RAOF, a core dev). Please publish.
[15:45] <camako> or was that for cihelp ^^
[15:46] <Ursinha> camako: that is trainguards :)
[15:47] <camako> Ursinha, thanks the title of this IRC chatroom makes you think trainguards only assign silos  :-)
[15:49] <davmor2> john-mcaleely: Mirv: custom tarball is good
[15:49] <john-mcaleely> davmor2, \o/ Mirv
[15:49] <john-mcaleely> who do I ping about making sure there's a good time to push it for a build?
[15:50] <john-mcaleely> ogra_, still?
[15:50] <davmor2> john-mcaleely: Mirv/robru
[15:50] <john-mcaleely> aha
[16:00] <rsalveti> just push it, don't need to be in sync with the rootfs
[16:01] <Ursinha> camako: I was never able to phrase it in a way it's clear what a trainguard does :)
[16:02] <john-mcaleely> rsalveti, the issue is whether the machines are busy making a build
[16:02] <john-mcaleely> robru, Mirv ? is there an image being built already?
[16:29] <rvr> Is there any problem with the image server? 2015/01/08 16:28:36 Get https://system-image.ubuntu.com/gpg/image-master.tar.xz: http: can't write HTTP request on broken connection
[16:36] <rvr> fginther: Hey, happy new year. Is image server down?
[16:38] <camako> trainguards, anyone around to land vivid silo 17 (mir 0.10)? It's good to go.
[16:48] <fginther> rvr, happy new year to you as well. Appears to be working, I can get to https://system-image.ubuntu.com/channels.json
[16:49] <rvr> fginther: 2015/01/08 16:46:54 Get https://system-image.ubuntu.com/gpg/image-master.tar.xz: EOF
[16:51] <fginther> rvr, I can't help you there, perhaps ogra_ knows if something is broken
[16:51] <rvr> ogra_: ^^
[16:51] <rvr> fginther: Thanks anyway
[16:54] <popey> rvr: 2015-01-08 16:53:28 ERROR 404: Not Found.
[16:54] <popey> oh, hang on
[16:54] <popey> yeah, fine here
[16:56] <rvr> popey: On channel=ubuntu-touch/ubuntu-rtm/14.09-proposed?
[16:56] <popey> i just did a wget of that file
[16:56] <popey> to prove its there
[17:00] <popey> Uh, I just got an alarm with no buttons in it
[17:00] <popey> seems to have broken since updating to latest image
[17:19] <rvr> Ok, the problem is the ubuntu-device-flash available in the ubuntu-sdk ppa
[17:23] <camako> trainguards, anyone around to land vivid silo 17 (mir 0.10)? It's good to go.
[17:23] <camako> robru ^^
[17:44] <bzoltan> rvr: is there an ubuntu-device-flash in the SDK PPA?
[17:45] <bzoltan> rvr:  of course there is ...
[17:45] <rvr> bzoltan: Yes, there is
[17:45] <bzoltan> let me see the version
[17:45] <rvr> bzoltan: 0.4+15.04.20141125-0ubuntu1
[17:45] <bzoltan> rvr:  sorry I forget that it comes from the goget-ubuntu-touch
[17:48] <bzoltan> rvr:  we have the same version in the SDK PPA as in the phablet tools .. for Utopic and Trusty. It seems that the Vivid release was not yet backported ... let me see
[17:50] <bzoltan> rvr:  in Vivid we have 0.8-0ubuntu1
[17:53] <Mirv> john-mcaleely: no image being built, next automated ones in 10h or so
[17:55] <Mirv> camako: done, based on RAOF having given the packaging acks for those that I cannot myself give
[17:55] <camako> Mirv, Thanks. Much appreciated.
[18:10] <john-mcaleely> Mirv, thanks. will push now then
[18:11] <john-mcaleely> Mirv, pushed. should be a new build on rtm shortly
[19:47] <boiko> trainguards: can I get a silo for row 62?
[19:48] <robru> boiko: ah yes, I saw that earlier but I was waiting for silo 18 to merge. one sec
[19:51] <boiko> robru: thanks!
[19:52] <robru> boiko: you're welcome!
[20:03] <jdstrand> pmcgowan: hey, so regarding bug #1392368. Please read this comment for rtm: https://bugs.launchpad.net/camera-app/+bug/1392368/comments/3
[20:04] <jdstrand> pmcgowan: Kaleo tells me that is for rtm. do you approve this for rtm?
[20:04] <pmcgowan> jdstrand, indeed, although do we know why the "real" approach wasnt possible
[20:04] <jdstrand> pmcgowan: this means the custom tarball will need to be regenerated
[20:05] <jdstrand> pmcgowan: I do not. Kaleo, can you comment? ^
[20:05] <pmcgowan> oh right, crap
[20:06] <jdstrand> pmcgowan: does that 'crap' mean I should not proceed?
[20:06]  * jdstrand isn't sure what is going on with the custom tarball these days
[20:07] <Kaleo> jdstrand, pmcgowan, the API to retrieve the path to the SD card does not exist yet
[20:07] <Kaleo> jdstrand, pmcgowan, there is one in Qt5.4 that should work when we switch to it
[20:08] <pmcgowan> Kaleo, so no way to implement something short term? or just as easy to make the profile change
[20:09] <Kaleo> pmcgowan, the short term cheap solution is the profile change
[20:09] <jdstrand> I don't see cwayne here. he is who normally regenerates the custom tarball
[20:10] <pmcgowan> ok lets go ahead then
[20:10] <Kaleo> pmcgowan, thanks
[20:10] <jdstrand> pmcgowan: do you know who should regenerate the custom tarball?
[20:11] <jdstrand> (in cwayne's absence)
[20:11] <pmcgowan> jdstrand, no but he was arround earlier
[20:11] <pmcgowan> john-mcaleely, might know
[20:15] <jdstrand> ah, ok, if he was around that's ok. I wasn't sure if he was still on holiday
[20:34] <jdstrand> Kaleo: I took over your initial bug and am using it to remove this rule now
[20:35] <jdstrand> Kaleo: also, you will see a vivid upload with the fix, the 14.09 one won't be until later
[22:57] <tedg> trainguards, Can I get a vivid silo for line 72 please?
[23:05] <robru> tedg: ok silo 3
[23:05] <tedg> robru, Cool, thanks!
[23:11] <robru> tedg: you're welcome
[23:22] <jdstrand> pmcgowan, Kaleo: ok, uploaded the fix for bug #1392368 to vivid and it is in rtm silo 10. tests passed. Needs QA signoff and custom tarball rebuilt.
[23:23] <jdstrand> pmcgowan, Kaleo: I'll followup with cwayne tomorrow to make sure he is aware (I did note ir in the landing spreadsheet)