slangasek | smoser, utlemming: how do the changes in cloud-init to cloudinit/sources/DataSourceSmartOS.py relate to the bugs in the changelog? | 00:05 |
---|---|---|
smoser | adjusting for the changes required for azure | 00:07 |
slangasek | smoser: what does 'availability-zone' have to do with azure? | 00:17 |
slangasek | smoser: also, isn't there a mismatch between 'availability-zone' and 'availability_zone'? | 00:18 |
smoser | slangasek, crap. that isn't even necessary (as its taken care of elsehwere) | 00:55 |
smoser | :-( | 00:55 |
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:56 |
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:57 |
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:58 |
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 | 00:59 |
slangasek | ok | 01:00 |
slangasek | smoser: but, what will the changelog message say if you don't know what this change was needed for...? | 01:02 |
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:03 |
slangasek | ok. are you backing that bit out then? | 01:04 |
slangasek | or do we just trust that it's a no-op? | 01:04 |
smoser | it is a noop | 01:06 |
smoser | but i'm backing out | 01:06 |
smoser | and will upload | 01:06 |
smoser | quickly | 01:06 |
slangasek | okie | 01:07 |
smoser | just pushed | 01:08 |
slangasek | infinity: erm | 03:09 |
slangasek | infinity: the change in -0ubuntu5 is not SRU-worthy and should not hold up the SRU of the rest of the critical fixes | 03:10 |
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. | 05:42 |
bkerensa | slangasek: Ubuntu Docs is ready for a upload if you would like to sponsor :) | 06:50 |
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 | 07:44 |
=== brainwash_ is now known as brainwash | ||
lool | I've blocked unity8, unity-notifications, indicator-network to upload them together to saucy | 09:49 |
lool | cjwatson: Not quite sure why the packageset is ubuntu-desktop here ^ | 09:51 |
lool | so we're reuploading unity-notifications + indicator-network + unity8, reverting the reverts for the first two and with proper fix for 3rd one | 09:58 |
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:15 |
cjwatson | was just doing so | 10:16 |
lool | awesome | 10:16 |
cjwatson | lool: oh, it's in ubuntu-desktop because there's a manual exception, apparently | 10:21 |
* cjwatson pokes at history | 10:22 | |
cjwatson | lool: http://bazaar.launchpad.net/~cjwatson/+junk/packageset/revision/66 | 10:22 |
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:23 |
cjwatson | Or maybe they just needed upload privileges to it | 10:24 |
lool | cjwatson: I'll write him a mail asking about it | 10:25 |
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:28 |
cjwatson | before that it was generally an unrestricting kind of thing | 10:29 |
lool | cjwatson: yup; I don't particularly mind, it just seems inconsistent with reality | 10:35 |
lool | thanks for looking into it | 10:36 |
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:45 |
cjwatson | but that isn't the case now for indicator-network, so the situation probably changed | 10:46 |
cjwatson | for moving from unseeded to in a package set I would normally ask for a seed entry instead | 10:47 |
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 | 13:24 |
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. :) | 16:54 |
lool | it looks like britney didn't run for a couple of hours? | 17:13 |
lool | cjwatson: FYI ^ | 17:13 |
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:01 |
slangasek | so, RT #65040 | 18:02 |
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:03 |
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:04 |
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:08 |
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:09 |
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:10 |
lool | win 33 | 18:12 |
lool | ups | 18:12 |
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:17 |
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:18 |
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:19 |
slangasek | lool: so, running britney by hand appears to have succeeded | 18:24 |
slangasek | but only the third time I ran it | 18:24 |
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:25 |
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 | 18:26 |
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:35 |
infinity | Yeah, the 'if changed' logic stopped making sense when autopkgtesting was added to the mix. | 19:37 |
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:41 |
infinity | I guess we could run it on release_changed || germinate_changed. | 19:42 |
infinity | There. Done. | 19:44 |
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. | 19:51 |
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:25 |
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:26 |
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:29 |
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:30 |
slangasek | right, but the cron trigger is set up to run every minute... which may be excessive frequency | 21:40 |
retoaded | slangasek, ack | 22:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!