/srv/irclogs.ubuntu.com/2015/03/30/#ubuntu-release.txt

=== peterm-u_ is now known as peter-meeting
jamespagemorning 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 queue09:30
jamespageinfinity 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 :-)09:31
jamespagejust 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 them10:23
jamespagehttps://bugs.launchpad.net/ubuntu/+source/python-semantic-version/+bug/143593710:23
ubot93Launchpad bug 1435937 in python-semantic-version (Ubuntu) "[MIR] python-semantic-version, python-oslo.log, python-oslo.policy, python-oslo.versionedobjects" [High,Fix committed]10:23
=== doko_ is now known as doko
dokojamespage, can't help with these. I'm not -release10:28
jamespagedoko, can you help with the NEW oslo packages?10:29
jamespagethey have release team acks - just pending AA review.10:29
infinityjamespage: 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:46
jamespageinfinity, yes - mterry reviewed them from the PPA I've been testing in under https://bugs.launchpad.net/ubuntu/+source/python-semantic-version/+bug/143593714:47
ubot93Launchpad bug 1435937 in python-semantic-version (Ubuntu) "[MIR] python-semantic-version, python-oslo.log, python-oslo.policy, python-oslo.versionedobjects" [High,Fix committed]14:47
infinityjamespage: Ahh, excellent, so I'll NEW directly to main.14:48
jamespageinfinity, that would be super-awesome!14:48
infinityjamespage: Also, can you fix the broken Provides?  I noticed the same thing in my review. :P14:48
jamespageinfinity, in oslo-config?14:48
infinityYeah.14:49
jamespageinfinity, I thought I had fixed that end of last week - lemme check14:49
jamespageyeah should be in 1:1.9.3-0ubuntu114:49
infinityOh, so you did.  Maybe the machine I'm doing this on is stale.14:49
jamespageinfinity, no its stale lintian14:50
jamespage"# Last updated: 2014-09-0614:50
jamespage"14:50
jamespageuh-oh14:50
infinityOr that.14:51
jamespageinfinity, I have a similar problem in dh-python - its pydist list is generate some time ago from debian14:52
jamespageUbuntu is a bit different now14:52
infinityjamespage: Alright, all NEWed, and semantic-whatever promoted.14:53
jamespageinfinity, thanks very much!14:53
=== wxl_ is now known as wxl
infinityrbasak: *poke*16:48
infinityrbasak: When can we expect the upstart/init-system-helpers uploads to move the apparmor wrapper around?  The apparmor upload is now landing/landed.16:50
stgraberI 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:51
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
infinitystgraber: An lxc that passes tests would be even nicer...16:52
stgraberwell, I'm reasonably sure it'll still fail, but it should fail much less than it does today :)16:53
stgraberand then we can work on fixing whatever new failure we discover16:53
infinitystgraber: 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:54
stgraberok, 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 good16:55
rbasakstgraber: I think the plan is that you'll depend on init-system-helpers16:55
rbasakThen you definitely have the wrapper16:56
rbasakOh, infinity said that. Sorry.16:56
stgrabergah, so I'll have to add more per-release control mangling... fun16:56
stgraber(we use the same packaging from precise all the way to vivid)16:56
stgraberrbasak: just checked. lxc does have a dependency on init-system-helpers16:57
infinitystgraber: 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
stgraberrbasak: which as I said, is generated by dh-systemd16:57
stgraberinfinity: 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:57
rbasakstgraber: ah, I see. I didn't realise it was already done (and unconditionally too I guess?)16:58
rbasakThere 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
infinityrbasak: 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:58
stgraberyeah, apparently anything using dh-systemd gets a dep on init-system-helpers16:59
jdstrandfyi the apparmor 2.9.1-0ubuntu8 that just got published has rbasak's update17:01
jdstrandwell, the one going through proposed migration that is17:01
rbasakjdstrand: thanks. I need to sync with hallyn as to who is uploading the other pieces.17:03
jdstrandoh, actually they aren't making it through proposed migration, they are in unapproved17:12
jdstrandslangasek: would you mind looking at click-apparmor and apparmor in unapproved? click-apparmor is snappy-specific. apparmor is snappy and distro. both went through citrain17:13
infinityjdstrand: Eh?  They were both accepted ages ago.17:40
infinityjdstrand: One was auto-accepted, the other was reviewed and accepted by me, which is what led to the above conversation. :P17:41
infinityslangasek: Ignore Jamie. :P17:41
jdstrandoh, ha17:42
jdstrandsorry I missed that17:42
slangasekinfinity: ignore who?18:03
infinityslangasek: Nobody.18:05
* slangasek nods18:06
jdstrandhey, so the systemd autopkgtest failure for apparmor is unlrelated to the apparmor change19:18
jdstrandhttps://jenkins.qa.ubuntu.com/job/vivid-adt-systemd/lastBuild/ARCH=amd64,label=adt/console19:18
sbeattiejdstrand: yeah, it also predates the apparmor change, too.19:19
sbeattiejdstrand: https://jenkins.qa.ubuntu.com/job/vivid-adt-systemd/19:19
sbeattieI'm not sure why the excuses page lists it as a regression19:19
jdstrandreah19:20
jdstrandyeah19:20
infinityautopkgtest integration isn't terribly sophisticated in that regard.  "regression" means "it passed at some point in the past".19:20
jdstrandlooks 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 cool19:20
jdstrand(non-blocking for this time)19:21
jdstrandI can also come back later after lxc is done if that is easier19:21
infinityjdstrand: I'll keep an eye on it all.19:22
jdstrandinfinity: thanks!19:22
bdmurrayslangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-updater-exclude-proposed/+merge/25443620:09
jdstrandinfinity: 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 too21:40
jdstrandmaybe something is in the private one21:41
infinityjdstrand: Looking in a second.21:43
jdstrandseems 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-ci21:44
infinityjdstrand: You shouldn't need QA VPN magic if you're on the new and improved VPN.21:45
jdstrandyeah, but, doesn't seem to work21:45
jdstrandlet me try again21:45
jdstrandname resolution isn't working21:46
infinityjdstrand: Ask #is, you probably need to be added to a group.21:46
infinityOh, but if name resolution isn't working, your VPN setup might also be bust.21:47
jdstrandok21:47
jdstrandwell21:47
jdstrandhost www.d-jenkins.ubuntu-ci <ip address in resolv.conf>21:47
jdstrandHost www.d-jenkins.ubuntu-ci not found: 3(NXDOMAIN)21:47
jdstrandI'll ask #is21:47
infinityErr, wait.21:47
infinityThat's not a valid host.21:48
infinityDrop the www, for starters.21:48
infinity(base)adconrad@cthulhu:~$ host d-jenkins.ubuntu-ci21:48
infinityd-jenkins.ubuntu-ci is an alias for tachash.ubuntu-ci.21:48
infinitytachash.ubuntu-ci has address 10.100.0.221:48
jdstrandoh, maybe firefox tacked on www. when it couldn't find the original21:49
jdstrandI seem to be in now21:50
jdstrandqemu: terminating on signal 15 from pid 2346621:50
jdstrandadt-run [20:32:42]: ERROR: testbed failed: timed out on command ...21:50
infinityYeah.21:51
jdstrandok, let's see about the previous one21:51
jdstrandyeah, same thing21:51
jdstrand(different pid of course :)21:51
infinityWell, slightly different, there was more output before the timeout.21:51
infinityBarely.21:51
jdstrandah yes21:51
infinityBut this test is obviously a sad panda, and it's hard to blame it on apparmor.21:52
jdstrandindeed21:52
infinitystgraber: Pretty please make your tests less sad? :)21:52
stgraberinfinity: working on it :)21:53
jdstrandwell, we have some high level tests for lxc in our test plan and I know it works21:53
infinityjdstrand: Righto.  Letting apparmor in.21:53
jdstrandthanks!21:53
stgraberinfinity: 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
infinitystgraber: The lxc one seems entirely unhappy in general.21:54
stgraberother 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 lxcfs21:55
infinityjuju-core's tests look pretty special too.  Whee.21:55
infinitystgraber: Huh, weird.  There's nothing really special about the test environment, it's just a kvm instance of a cloud image.21:56
stgraberI've also confirmed that the whole lxc testsuite runs very happily on a non-systemd system :)21:56
stgraberinfinity: 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 somewhere21:59
stgrabertechnically 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:01
infinityOh, juju-core's tests seem to rely on upstart-as-system-init, yay.22:02
bdmurraystgraber: Could you have a look at this merge proposal? https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-updater-exclude-proposed/+merge/25443622:41
slangasekoops just merged it22:42
bdmurraythanks!22:43
infinityOh, well, that saves me the review I was about to do...22:44
* infinity wonders who rejected it.22:45

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!