=== peterm-u_ is now known as peter-meeting
[09:30] <jamespage> morning release team - I'm going to start uploading the OpenStack kilo-3 updates which have been tested in PPA last week; they require the python-oslo.* packages waiting for review in the vivid NEW queue
[09:31] <jamespage> infinity was going to review them last week during ISO testing for the beta, but I'm guessing did not manage to, so if any AA's are around this morning unwedging those would be great :-)
[10:23] <jamespage> just another point to note on the oslo packages in NEW - mterry has been good enough to review them from my staging PPA for the MIR that will be required for them
[10:23] <jamespage> https://bugs.launchpad.net/ubuntu/+source/python-semantic-version/+bug/1435937
[10:23] <ubot93> Launchpad bug 1435937 in python-semantic-version (Ubuntu) "[MIR] python-semantic-version, python-oslo.log, python-oslo.policy, python-oslo.versionedobjects" [High,Fix committed]
=== doko_ is now known as doko
[10:28] <doko> jamespage, can't help with these. I'm not -release
[10:29] <jamespage> doko, can you help with the NEW oslo packages?
[10:29] <jamespage> they have release team acks - just pending AA review.
[14:46] <infinity> jamespage: So, these python-oslo.* bits in NEW.  I've reviewed them, but I assume they also need to be in main for openstack to be happy?
[14:47] <jamespage> infinity, yes - mterry reviewed them from the PPA I've been testing in under https://bugs.launchpad.net/ubuntu/+source/python-semantic-version/+bug/1435937
[14:47] <ubot93> Launchpad bug 1435937 in python-semantic-version (Ubuntu) "[MIR] python-semantic-version, python-oslo.log, python-oslo.policy, python-oslo.versionedobjects" [High,Fix committed]
[14:48] <infinity> jamespage: Ahh, excellent, so I'll NEW directly to main.
[14:48] <jamespage> infinity, that would be super-awesome!
[14:48] <infinity> jamespage: Also, can you fix the broken Provides?  I noticed the same thing in my review. :P
[14:48] <jamespage> infinity, in oslo-config?
[14:49] <infinity> Yeah.
[14:49] <jamespage> infinity, I thought I had fixed that end of last week - lemme check
[14:49] <jamespage> yeah should be in 1:1.9.3-0ubuntu1
[14:49] <infinity> Oh, so you did.  Maybe the machine I'm doing this on is stale.
[14:50] <jamespage> infinity, no its stale lintian
[14:50] <jamespage> "# Last updated: 2014-09-06
[14:50] <jamespage> "
[14:50] <jamespage> uh-oh
[14:51] <infinity> Or that.
[14:52] <jamespage> infinity, I have a similar problem in dh-python - its pydist list is generate some time ago from debian
[14:52] <jamespage> Ubuntu is a bit different now
[14:53] <infinity> jamespage: Alright, all NEWed, and semantic-whatever promoted.
[14:53] <jamespage> infinity, thanks very much!
=== wxl_ is now known as wxl
[16:48] <infinity> rbasak: *poke*
[16:50] <infinity> rbasak: When can we expect the upstart/init-system-helpers uploads to move the apparmor wrapper around?  The apparmor upload is now landing/landed.
[16:51] <stgraber> I also just uploaded a new lxc with a workaround for that case (probably still worth keeping around even once we've got the situation fixed)
[16:52] <stgraber> (workaround is that if the helper script isn't around and apparmor is, then trigger an apparmor reload so should be a reasonable safety net to make sure we never end up running unconfined)
[16:52] <infinity> stgraber: An lxc that passes tests would be even nicer...
[16:53] <stgraber> well, I'm reasonably sure it'll still fail, but it should fail much less than it does today :)
[16:53] <stgraber> and then we can work on fixing whatever new failure we discover
[16:54] <infinity> stgraber: So, AIUI, you should be depending on init-system-helpers (>= version rbasak hasn't uploaded) and calling /lib/init/apparmor-profile-load in your postinst.  But I guess the workaround today is sort of okayish.
[16:55] <stgraber> ok, so we do call /lib/init/apparmor-profile-load and we're supposed to get the dependency automatically through dh-systemd, so in theory we're good
[16:55] <rbasak> stgraber: I think the plan is that you'll depend on init-system-helpers
[16:56] <rbasak> Then you definitely have the wrapper
[16:56] <rbasak> Oh, infinity said that. Sorry.
[16:56] <stgraber> gah, so I'll have to add more per-release control mangling... fun
[16:56] <stgraber> (we use the same packaging from precise all the way to vivid)
[16:57] <stgraber> rbasak: just checked. lxc does have a dependency on init-system-helpers
[16:57] <infinity> stgraber: Well, you already depend on init-system-helpers incidentally anyway.  The correct versioned dep is something you can probably handwave past, since it'll be right for vivid anyway.
[16:57] <stgraber> rbasak: which as I said, is generated by dh-systemd
[16:57] <stgraber> infinity: yeah, that's my plan :) and the workaround I uploaded will cover people running old init-system-helpers until they get the new one.
[16:58] <rbasak> stgraber: ah, I see. I didn't realise it was already done (and unconditionally too I guess?)
[16:58] <rbasak> There are upstart jobs that use it though, so technically they should explicitly depend on it though we probably don't care in Ubuntu.
[16:58] <infinity> rbasak: His dep on init-system-helpers is for other reasons.  You should still be adding the explicit versioned dep where it looks necessary for the apparmor thing.
[16:59] <stgraber> yeah, apparently anything using dh-systemd gets a dep on init-system-helpers
[17:01] <jdstrand> fyi the apparmor 2.9.1-0ubuntu8 that just got published has rbasak's update
[17:01] <jdstrand> well, the one going through proposed migration that is
[17:03] <rbasak> jdstrand: thanks. I need to sync with hallyn as to who is uploading the other pieces.
[17:12] <jdstrand> oh, actually they aren't making it through proposed migration, they are in unapproved
[17:13] <jdstrand> slangasek: would you mind looking at click-apparmor and apparmor in unapproved? click-apparmor is snappy-specific. apparmor is snappy and distro. both went through citrain
[17:40] <infinity> jdstrand: Eh?  They were both accepted ages ago.
[17:41] <infinity> jdstrand: One was auto-accepted, the other was reviewed and accepted by me, which is what led to the above conversation. :P
[17:41] <infinity> slangasek: Ignore Jamie. :P
[17:42] <jdstrand> oh, ha
[17:42] <jdstrand> sorry I missed that
[18:03] <slangasek> infinity: ignore who?
[18:05] <infinity> slangasek: Nobody.
[18:06]  * slangasek nods
[19:18] <jdstrand> hey, so the systemd autopkgtest failure for apparmor is unlrelated to the apparmor change
[19:18] <jdstrand> https://jenkins.qa.ubuntu.com/job/vivid-adt-systemd/lastBuild/ARCH=amd64,label=adt/console
[19:19] <sbeattie> jdstrand: yeah, it also predates the apparmor change, too.
[19:19] <sbeattie> jdstrand: https://jenkins.qa.ubuntu.com/job/vivid-adt-systemd/
[19:19] <sbeattie> I'm not sure why the excuses page lists it as a regression
[19:20] <jdstrand> reah
[19:20] <jdstrand> yeah
[19:20] <infinity> autopkgtest integration isn't terribly sophisticated in that regard.  "regression" means "it passed at some point in the past".
[19:20] <jdstrand> looks like lxc is still running, so I won't request anything other than to say that if we can mark that systemd one as non-blocking that's cool
[19:21] <jdstrand> (non-blocking for this time)
[19:21] <jdstrand> I can also come back later after lxc is done if that is easier
[19:22] <infinity> jdstrand: I'll keep an eye on it all.
[19:22] <jdstrand> infinity: thanks!
[20:09] <bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-updater-exclude-proposed/+merge/254436
[21:40] <jdstrand> infinity: hrm, lxc failed but I really don't understand the log: https://jenkins.qa.ubuntu.com/job/vivid-adt-lxc/62/console. It looks like the previous one failed too
[21:41] <jdstrand> maybe something is in the private one
[21:43] <infinity> jdstrand: Looking in a second.
[21:44] <jdstrand> seems I don't have a valid QA lab setup. I can't see to connect with my old qa lab vpn configuration and the new vpn doens't resolve www.d-jenkins.ubuntu-ci
[21:45] <infinity> jdstrand: You shouldn't need QA VPN magic if you're on the new and improved VPN.
[21:45] <jdstrand> yeah, but, doesn't seem to work
[21:45] <jdstrand> let me try again
[21:46] <jdstrand> name resolution isn't working
[21:46] <infinity> jdstrand: Ask #is, you probably need to be added to a group.
[21:47] <infinity> Oh, but if name resolution isn't working, your VPN setup might also be bust.
[21:47] <jdstrand> ok
[21:47] <jdstrand> well
[21:47] <jdstrand> host www.d-jenkins.ubuntu-ci <ip address in resolv.conf>
[21:47] <jdstrand> Host www.d-jenkins.ubuntu-ci not found: 3(NXDOMAIN)
[21:47] <jdstrand> I'll ask #is
[21:47] <infinity> Err, wait.
[21:48] <infinity> That's not a valid host.
[21:48] <infinity> Drop the www, for starters.
[21:48] <infinity> (base)adconrad@cthulhu:~$ host d-jenkins.ubuntu-ci
[21:48] <infinity> d-jenkins.ubuntu-ci is an alias for tachash.ubuntu-ci.
[21:48] <infinity> tachash.ubuntu-ci has address 10.100.0.2
[21:49] <jdstrand> oh, maybe firefox tacked on www. when it couldn't find the original
[21:50] <jdstrand> I seem to be in now
[21:50] <jdstrand> qemu: terminating on signal 15 from pid 23466
[21:50] <jdstrand> adt-run [20:32:42]: ERROR: testbed failed: timed out on command ...
[21:51] <infinity> Yeah.
[21:51] <jdstrand> ok, let's see about the previous one
[21:51] <jdstrand> yeah, same thing
[21:51] <jdstrand> (different pid of course :)
[21:51] <infinity> Well, slightly different, there was more output before the timeout.
[21:51] <infinity> Barely.
[21:51] <jdstrand> ah yes
[21:52] <infinity> But this test is obviously a sad panda, and it's hard to blame it on apparmor.
[21:52] <jdstrand> indeed
[21:52] <infinity> stgraber: Pretty please make your tests less sad? :)
[21:53] <stgraber> infinity: working on it :)
[21:53] <jdstrand> well, we have some high level tests for lxc in our test plan and I know it works
[21:53] <infinity> jdstrand: Righto.  Letting apparmor in.
[21:53] <jdstrand> thanks!
[21:54] <stgraber> infinity: I know what's wrong with the lxcfs one, we'll need a new cgmanager to fix it though, just waiting for hallyn to come back to work (he's got the flu or something like that)
[21:54] <infinity> stgraber: The lxc one seems entirely unhappy in general.
[21:55] <stgraber> other than that, we have 3 lxc tests that are still failing, that's all of the apparmor ones (they just hang indefinitely in the test environment but not on a desktop system, trying to figure out why) and a generic ubuntu container test which appears unhappy too but is likely caused by the broken lxcfs
[21:55] <infinity> juju-core's tests look pretty special too.  Whee.
[21:56] <infinity> stgraber: Huh, weird.  There's nothing really special about the test environment, it's just a kvm instance of a cloud image.
[21:56] <stgraber> I've also confirmed that the whole lxc testsuite runs very happily on a non-systemd system :)
[21:59] <stgraber> infinity: yeah, could be related to cgroup setup which does vary depending on how you get your session (ssh vs local, su vs sudo, ...) or some fun race condition going on somewhere
[22:01] <stgraber> technically I could let both lxc and lxcfs in because they're no worse than what we have currently in the archive (the existing packages passed their adt but that was pre-systemd, a rerun under systemd would fail) but having them stuck is a good incentive for us to look into those problems :)
[22:02] <infinity> Oh, juju-core's tests seem to rely on upstart-as-system-init, yay.
[22:41] <bdmurray> stgraber: Could you have a look at this merge proposal? https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-updater-exclude-proposed/+merge/254436
[22:42] <slangasek> oops just merged it
[22:43] <bdmurray> thanks!
[22:44] <infinity> Oh, well, that saves me the review I was about to do...
[22:45]  * infinity wonders who rejected it.