[00:56] <coreycb> nacc, i think everything's been sponsored for bug 1664203.  dosaboy, does trusty need a patch for that bug?
[05:20] <nacc> coreycb: thanks, was just doing the sponsorship queue cleanup, if you can verify and unsub sponsors?
[06:24] <smb> rbasak, Yes thanks, all apparmor/yakkety needs re-opening (or needed). The changes accidentally included the references again due to ripples in space-time continuum (the release it is based was not in updates at the time of creation but had to be treated as if it hadwill happened in the past by the time it got released)
[11:29] <rbasak> nacc: seen http://paste.ubuntu.com/24280631/ before? I wonder if it's a package version issue on Xenial.
[14:05] <nacc> rbasak: no i have not see gbp fail like that before -- is it reproducible (gbp-import-orig should be runnable on its own)
[14:06] <rbasak> nacc: it did it for every import around that time, so I'd say yes.
[14:06] <rbasak> I will need to check though.
[14:06] <nacc> rbasak: strange
[16:31] <bdmurray> jamespage: in bug 1668313 you say "trusty-mitaka-proposed" and "xenial-mitaka-proposed" I don't see any "xenial-proposed" test results.
[16:31] <jamespage> bdmurray: xenial-mitaka-proposed == xenial-proposed
[16:31] <jamespage> xenial shipped with mitaka openstack
[16:31] <bdmurray> jamespage: okay its not the Ubuntu Cloud Archive
[16:32] <jamespage> bdmurray: nope that's trusty-mitaka-proposed
[16:32] <jamespage> which is a backport of xenial packages to trusty in the UCA
[16:32] <bdmurray> Having mitaka in both words seems confusing to me.
[16:36] <bdmurray> jamespage: I just think it could be clearer which archive you are testing when you post test results.
[16:50] <jamespage> bdmurray: ok I can clarify that
[16:51] <bdmurray> jamespage: that'd be great thanks
[16:53] <jamespage> bdmurray: noted on the bug above - I'll make sure that zul and coreycb know to detail that in future as well
[16:57] <jamespage> bdmurray: two tasks are still not released on https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1664306
[16:57] <jamespage> nova and swift  - anything blocking those?
[17:04] <bdmurray> jamespage: there's an autopkgtest failure for the old nova with the new libvirt...
[17:21] <jamespage> bdmurray: lookling now
[19:41] <nacc> mapreri: thanks for the extra bug and link(s). I hope to update my MR tmrw
[20:03] <smoser> hey, i'd appreciate it if someone could take a look at
[20:03] <smoser>  https://code.launchpad.net/~smoser/ubuntu/+source/resolvconf/+git/resolvconf/+merge/321203
[20:03] <smoser> and give thoughts.
[20:04] <smoser> the referenced bug has more information, but essentially dns-* entries on ENI interfaces fight/race each other in a deathmatch
[20:04] <smoser> this is one way out of it. in a not-break-stuff manner
[22:01] <mapreri> nacc: yw.  I was kinda wanting to switch everything to git over there, but before flipping it over (or, better, contextually), I wanted to merge (or reject) everything pending and do some bug triaging.  Considering how otherwise busy I am it will take time, so nvm :)
[22:53] <nacc> mapreri: i'm happy to retool to git anytime, just let me know :)
[23:04] <mapreri> nacc: if you are like me on this (knowing that several others are), you probably would actually prefer to "retool" in git right now, rather than way :P
[23:18] <nacc> mapreri: yeah :)
[23:52] <nacc> rbasak: do you have any advice for LP: #1322264 -- there is not a clear test case, but it's an obvious fix from upstream
[23:52] <nacc> rbasak: mostly because you'd have to configure munin in order to test this