[00:05] <slangasek> smoser, utlemming: how do the changes in cloud-init to cloudinit/sources/DataSourceSmartOS.py relate to the bugs in the changelog?
[00:07] <smoser> adjusting for the changes required for azure
[00:17] <slangasek> smoser: what does 'availability-zone' have to do with azure?
[00:18] <slangasek> smoser: also, isn't there a mismatch between 'availability-zone' and 'availability_zone'?
[00:55] <smoser> slangasek, crap. that isn't even necessary (as its taken care of elsehwere)
[00:55] <smoser> :-(
[00:56] <smoser> well, the availability-zone -> availabilty_zone. something else handles either or on that.
[00:56] <slangasek> smoser: so does this warrant a reupload?
[00:56] <smoser> well, i assume utlemming put that in for some reason.
[00:57] <smoser> he didn't need to put the 'availability_zone' portion in. the getter.
[00:57] <smoser> but he did add it to SMARTOS_ATTRIB_MAP . and i'm assuming that that solved a problem for him. which unfortunately is not documented.
[00:57] <smoser> if you want me to re-upload i'll bug utlemming and do that on monday.
[00:58] <smoser> or you can let this in and we'll get a bug for it anyway.
[00:58] <slangasek> well, since there's nothing about it in the changelog I'd rather not let it in as-is
[00:59] <smoser> i'll re-upload quikcly then with a changelog message.
[00:59] <smoser> please NAK that one
[00:59] <smoser> and i'll add changelog entry
[01:00] <slangasek> ok
[01:02] <slangasek> smoser: but, what will the changelog message say if you don't know what this change was needed for...?
[01:03] <smoser> i know what the insertion into the map will do
[01:03] <smoser> and why he'd do that.
[01:03] <smoser> but the other portion was not necessary
[01:04] <slangasek> ok. are you backing that bit out then?
[01:04] <slangasek> or do we just trust that it's a no-op?
[01:06] <smoser> it is a noop
[01:06] <smoser> but i'm backing out
[01:06] <smoser> and will upload
[01:06] <smoser> quickly
[01:07] <slangasek> okie
[01:08] <smoser> just pushed
[03:09] <slangasek> infinity: erm
[03:10] <slangasek> infinity: the change in -0ubuntu5 is not SRU-worthy and should not hold up the SRU of the rest of the critical fixes
[05:42] <infinity> slangasek: Oh.  Seemed to me you'd want sbsigntool to also be able to verify sanely, but sure.  I can re-review and accept ubuntu4 from rejected.
[06:50] <bkerensa> slangasek: Ubuntu Docs is ready for a upload if you would like to sponsor :)
[07:44] <ginggs> Hi all.  I've noticed some SRU bugs didn't get the usual message that they are in -proposed and needed verification e.g. LP: #1076414, LP: #1006988
[07:44] <ubot2> Launchpad bug 1076414 in nvidia-settings-updates (Ubuntu) "Transitioning between nvidia drivers (updates, 304, 310) results in install failure due to conflicting nvidia-settings" [High,Invalid] https://launchpad.net/bugs/1076414
[07:44] <ubot2> Launchpad bug 1006988 in inventor (Ubuntu Precise) "ivview application does not start" [Undecided,In progress] https://launchpad.net/bugs/1006988
[09:49] <lool> I've blocked unity8, unity-notifications, indicator-network to upload them together to saucy
[09:51] <lool> cjwatson: Not quite sure why the packageset is ubuntu-desktop here ^
[09:58] <lool> so we're reuploading unity-notifications + indicator-network + unity8, reverting the reverts for the first two and with proper fix for 3rd one
[10:15] <cjwatson> lool: dunno, not going to investigate now :)
[10:15] <lool> cjwatson: fair enough, do you have a sec to review it from unapproved though?
[10:16] <cjwatson> was just doing so
[10:16] <lool> awesome
[10:21] <cjwatson> lool: oh, it's in ubuntu-desktop because there's a manual exception, apparently
[10:22]  * cjwatson pokes at history
[10:22] <cjwatson> lool: http://bazaar.launchpad.net/~cjwatson/+junk/packageset/revision/66
[10:23] <cjwatson> lool: So that's fairly old and if kenvandine no longer thinks that's necessary I can undo the indicator-network part of it
[10:23] <cjwatson> Maybe it was in desktop installs at the time
[10:24] <cjwatson> Or maybe they just needed upload privileges to it
[10:25] <lool> cjwatson: I'll write him a mail asking about it
[10:28] <cjwatson> Ken joined core-dev since then which might make a difference :)
[10:28] <cjwatson> remember that it's an extremely recent thing to have being in a packageset have a negative effect (i.e. no auto-accept)
[10:29] <cjwatson> before that it was generally an unrestricting kind of thing
[10:35] <lool> cjwatson: yup; I don't particularly mind, it just seems inconsistent with reality
[10:36] <lool> thanks for looking into it
[10:45] <cjwatson> it does seem inconsistent - normally I only add that kind of manual exception when it widens permissions, e.g. when the package would otherwise be in core
[10:46] <cjwatson> but that isn't the case now for indicator-network, so the situation probably changed
[10:47] <cjwatson> for moving from unseeded to in a package set I would normally ask for a seed entry instead
[13:24] <smartboyhw> Please ACK Bug 1235651 for us
[13:24] <ubot2> Launchpad bug 1235651 in ubuntustudio-meta (Ubuntu) "[FFe] Include ardour3 in ubuntustudio-meta" [Undecided,New] https://launchpad.net/bugs/1235651
[16:54] <slangasek> infinity: we don't rely on sbverify anywhere in the archive, it's only used by some QA tests, and the SRU isn't going to happen quickly enough to be a reasonable solution for those currently-failing tests.  So, thanks for the un-reject. :)
[17:13] <lool> it looks like britney didn't run for a couple of hours?
[17:13] <lool> cjwatson: FYI ^
[18:01] <slangasek> lool: I fear that's probably related to the mail Larry just sent out about jenkins private IP changing and firewall rules getting in the way of jobs from snakefruit + nusakan
[18:01] <slangasek> if britney can't talk to jenkins, it can't get ADT results
[18:02] <slangasek> so, RT #65040
[18:03] <slangasek> retoaded: is there a committment from IS to work on this ticket over the weekend?  saucy development is dead in the water until that firewall rule is fixed
[18:04] <slangasek> retoaded: so if the firewall isn't getting fixed until Monday, I think we need britney to be able to continue to reach jenkins on the old IP until then
[18:08] <lool> Dropping him an email too to max chances of this being seen
[18:08] <lool> slangasek: it's a bit surprizing in terms of timing that it blocks now though
[18:09] <slangasek> I suspect this dependency was overlooked in the migration plan for magners, otherwise the RT would've been filed sooner than 9pm London time on a Friday
[18:10] <lool> I don't quite understand how when moving to a new IP we're not copying over all rules from the old IP
[18:10] <lool> perhaps because we're resplitting multiple services across different machines
[18:10] <lool> but seems like we should be tracking dependencies between services better
[18:10] <lool> anyway
[18:12] <lool> win 33
[18:12] <lool> ups
[18:17] <slangasek> hmm, but now I'm doubting that the firewall is the issue
[18:17] <slangasek> at least, direct connection to both old and new IPs fails, as does connecting via the proxy
[18:17] <lool> slangasek: it happened in the past that britney got stuck
[18:17] <slangasek> I don't see evidence of that
[18:17] <lool> but I think it's now running on a host that I'm not sure I have access to
[18:17] <slangasek> snakefruit
[18:18] <lool> yeah, my public key isn't accepted there
[18:18] <lool> if you can check whether there's a stale britney process running for a long time there
[18:19] <slangasek> there is not
[18:19] <slangasek> I think this *is* related to the jenkins move
[18:19] <slangasek> I just am not sure it's a firewall issue
[18:24] <slangasek> lool: so, running britney by hand appears to have succeeded
[18:24] <slangasek> but only the third time I ran it
[18:25] <slangasek> and that doesn't explain the lack of attempts over the past 3h
[18:25] <slangasek> it's possible that britney didn't run because there were no new packages accepted into -proposed?  the britney run is guarded by:
[18:25] <slangasek> if release_changed "$DEVEL" || release_changed "$DEVEL-proposed"; then
[18:25] <slangasek>         background pids run-proposed-migration
[18:26] <slangasek> fi
[18:26] <slangasek> anyway, evidently my manual test of jenkins availability from snakefruit was flawed somehow
[18:26] <slangasek> retoaded: ^^ seems we're not as blocked as I was afraid we were
[19:35] <lool> slangasek: ah cool, I thought of this at first because it seemed to run less frequently over the week-end, but then I discarded the idea because it seemed a poor choice considering a) people might upload hints at any time and b) transitions might be held by autopkgtests
[19:37] <infinity> Yeah, the 'if changed' logic stopped making sense when autopkgtesting was added to the mix.
[19:41] <infinity> We could change the trigger from "release_changed" to "germinate_changed", but then britney will run later in the publisher cycle and miss the window to promote before the next run.
[19:41] <infinity> The proper answer is to trigger it *from* ftpmaster, which we intend to do.
[19:42] <infinity> I guess we could run it on release_changed || germinate_changed.
[19:44] <infinity> There.  Done.
[19:51] <infinity> Wait, no.
[19:51]  * infinity undoes.
[19:51] <infinity> Having it promote twice in the same publisher cycle might be less than ideal.
[19:51] <infinity> I think we probably just want to fix this properly, with an SSH trigger.
[21:25] <stgraber> infinity: I think what we discussed at the sprint was triggering from ftpmaster + every 5 or 10 minutes (if no ftpmaster trigger in between)
[21:26] <stgraber> that was to workaround the case of a frozen archive with very little changes but required britney run to monitor autopkgtest and get things copied over
[21:29] <infinity> stgraber: A frozen archive still runs the publisher.
[21:29] <infinity> stgraber: So, it really just needs to trigger unconditionally, post-publish-attempt, even if no dirty pockets published.
[21:30] <stgraber> infinity: wouldn't that mean running britney basically continuously given how often we run the publisher nowadays?
[21:30] <infinity> stgraber: Ish, but not quite.  britney still runs much faster than the publisher.
[21:40] <slangasek> right, but the cron trigger is set up to run every minute... which may be excessive frequency
[22:03] <retoaded> slangasek, ack