[00:05] smoser, utlemming: how do the changes in cloud-init to cloudinit/sources/DataSourceSmartOS.py relate to the bugs in the changelog? [00:07] adjusting for the changes required for azure [00:17] smoser: what does 'availability-zone' have to do with azure? [00:18] smoser: also, isn't there a mismatch between 'availability-zone' and 'availability_zone'? [00:55] slangasek, crap. that isn't even necessary (as its taken care of elsehwere) [00:55] :-( [00:56] well, the availability-zone -> availabilty_zone. something else handles either or on that. [00:56] smoser: so does this warrant a reupload? [00:56] well, i assume utlemming put that in for some reason. [00:57] he didn't need to put the 'availability_zone' portion in. the getter. [00:57] 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] if you want me to re-upload i'll bug utlemming and do that on monday. [00:58] or you can let this in and we'll get a bug for it anyway. [00:58] well, since there's nothing about it in the changelog I'd rather not let it in as-is [00:59] i'll re-upload quikcly then with a changelog message. [00:59] please NAK that one [00:59] and i'll add changelog entry [01:00] ok [01:02] smoser: but, what will the changelog message say if you don't know what this change was needed for...? [01:03] i know what the insertion into the map will do [01:03] and why he'd do that. [01:03] but the other portion was not necessary [01:04] ok. are you backing that bit out then? [01:04] or do we just trust that it's a no-op? [01:06] it is a noop [01:06] but i'm backing out [01:06] and will upload [01:06] quickly [01:07] okie [01:08] just pushed [03:09] infinity: erm [03:10] 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] 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] slangasek: Ubuntu Docs is ready for a upload if you would like to sponsor :) [07:44] 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] 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] Launchpad bug 1006988 in inventor (Ubuntu Precise) "ivview application does not start" [Undecided,In progress] https://launchpad.net/bugs/1006988 === brainwash_ is now known as brainwash [09:49] I've blocked unity8, unity-notifications, indicator-network to upload them together to saucy [09:51] cjwatson: Not quite sure why the packageset is ubuntu-desktop here ^ [09:58] 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] lool: dunno, not going to investigate now :) [10:15] cjwatson: fair enough, do you have a sec to review it from unapproved though? [10:16] was just doing so [10:16] awesome [10:21] lool: oh, it's in ubuntu-desktop because there's a manual exception, apparently [10:22] * cjwatson pokes at history [10:22] lool: http://bazaar.launchpad.net/~cjwatson/+junk/packageset/revision/66 [10:23] 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] Maybe it was in desktop installs at the time [10:24] Or maybe they just needed upload privileges to it [10:25] cjwatson: I'll write him a mail asking about it [10:28] Ken joined core-dev since then which might make a difference :) [10:28] 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] before that it was generally an unrestricting kind of thing [10:35] cjwatson: yup; I don't particularly mind, it just seems inconsistent with reality [10:36] thanks for looking into it [10:45] 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] but that isn't the case now for indicator-network, so the situation probably changed [10:47] for moving from unseeded to in a package set I would normally ask for a seed entry instead [13:24] Please ACK Bug 1235651 for us [13:24] Launchpad bug 1235651 in ubuntustudio-meta (Ubuntu) "[FFe] Include ardour3 in ubuntustudio-meta" [Undecided,New] https://launchpad.net/bugs/1235651 [16:54] 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] it looks like britney didn't run for a couple of hours? [17:13] cjwatson: FYI ^ [18:01] 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] if britney can't talk to jenkins, it can't get ADT results [18:02] so, RT #65040 [18:03] 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] 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] Dropping him an email too to max chances of this being seen [18:08] slangasek: it's a bit surprizing in terms of timing that it blocks now though [18:09] 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] 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] perhaps because we're resplitting multiple services across different machines [18:10] but seems like we should be tracking dependencies between services better [18:10] anyway [18:12] win 33 [18:12] ups [18:17] hmm, but now I'm doubting that the firewall is the issue [18:17] at least, direct connection to both old and new IPs fails, as does connecting via the proxy [18:17] slangasek: it happened in the past that britney got stuck [18:17] I don't see evidence of that [18:17] but I think it's now running on a host that I'm not sure I have access to [18:17] snakefruit [18:18] yeah, my public key isn't accepted there [18:18] if you can check whether there's a stale britney process running for a long time there [18:19] there is not [18:19] I think this *is* related to the jenkins move [18:19] I just am not sure it's a firewall issue [18:24] lool: so, running britney by hand appears to have succeeded [18:24] but only the third time I ran it [18:25] and that doesn't explain the lack of attempts over the past 3h [18:25] 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] if release_changed "$DEVEL" || release_changed "$DEVEL-proposed"; then [18:25] background pids run-proposed-migration [18:26] fi [18:26] anyway, evidently my manual test of jenkins availability from snakefruit was flawed somehow [18:26] retoaded: ^^ seems we're not as blocked as I was afraid we were [19:35] 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] Yeah, the 'if changed' logic stopped making sense when autopkgtesting was added to the mix. [19:41] 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] The proper answer is to trigger it *from* ftpmaster, which we intend to do. [19:42] I guess we could run it on release_changed || germinate_changed. [19:44] There. Done. [19:51] Wait, no. [19:51] * infinity undoes. [19:51] Having it promote twice in the same publisher cycle might be less than ideal. [19:51] I think we probably just want to fix this properly, with an SSH trigger. [21:25] 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] 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] stgraber: A frozen archive still runs the publisher. [21:29] stgraber: So, it really just needs to trigger unconditionally, post-publish-attempt, even if no dirty pockets published. [21:30] infinity: wouldn't that mean running britney basically continuously given how often we run the publisher nowadays? [21:30] stgraber: Ish, but not quite. britney still runs much faster than the publisher. [21:40] right, but the cron trigger is set up to run every minute... which may be excessive frequency [22:03] slangasek, ack