[06:29] <pitti> rbasak: init-system-helpers shouldn't have apparmor-profile-load, it should go back to upstart; see bug 1432683
[06:29] <pitti> rbasak: but of course the breaks/replaces are missing, that was a merge error; thanks for pointing out! fix uploaded
[06:35] <FourDollars> Hi, is anyone able to review my patch of https://code.launchpad.net/~fourdollars/ubuntu/trusty/efibootmgr/1460521/+merge/260676?
[06:39] <ricotz> doko__, hi, jfyi, happing on wily as well: https://bugzilla.redhat.com/show_bug.cgi?id=1155273
[07:28] <dholbach> good morning
[07:30] <seb128> hey dholbach
[07:32] <dholbach> hey seb128
[07:47] <rbasak> pitti: "as it's only being used in upstart jobs" I'm not sure this is true. That's why we moved it.
[07:47] <rbasak> pitti: it belongs in something generic as it's not upstart-specific.
[07:48] <pitti> rbasak: IMHO it belongs into (and is in) apparmor
[07:48] <rbasak> pitti: the problem with it being in apparmor is that apparmor is optional.
[07:48] <pitti> how is that a problem?
[07:49] <rbasak> pitti: so we can't depend on apparmor for the wrapper to exist if we want to unconditionally call the wrapper.
[07:49] <rbasak> hallyn_: ^^
[07:49] <pitti> right, you shouldn't unconditionally call the wrapper :)
[07:50] <rbasak> IIRC hallyn wanted a way to unconditionally call *something*, so that had to go somewhere generic that can be depended on.
[07:50] <pitti> init.d scripts/systemd units always need to check for that, as this wrapper is ubuntu specific
[07:50] <pitti> and if they need to check for it anyway, they can just as well work on other distros and call the apparmor loader right away
[07:51] <pitti> rbasak: LXC checks for it (and checks for the apparmor scirpt, not the i-s-h helper)
[07:51] <pitti> https://github.com/lxc/lxc/blob/master/config/init/systemd/lxc-apparmor-load
[07:52] <infinity> pitti: I'm down with the argument that perhaps all references to the sciprt/wrapper should be conditionalised to avoid the dep altogether, but it's still probably true that we need to ship the wrapper and keep the breaks/replaces for 14.04->16.04 upgrades.
[07:52] <rbasak> pitti: if everyone is fine to always [ -x /lib/apparmor/profile-load ] first, then I'm fine with the wrapper going away.
[07:53] <pitti> infinity: right; I added back the breaks/replaces for the time being, until that gets cleaned up
[07:53] <infinity> The only way to make sure people always call it right, though, is to turn it into a debhelper snippet or something.
[07:53] <pitti> and we only ever called /lib/init/apparmor-profile-load in upstart jobs, so let's clean this up over time
[07:54] <infinity> (Well, for the maintainer script invocations, people are on their own for init jobs)
[08:01] <infinity> bdmurray: Oh, and regarding your comment in LP: #1458630, I wouldn't discourage people filing bugs on current-LTS to current-non-LTS upgrades, since even if we don't officially support that, they're beta-testing current-LTS to next-LTS for us.
[08:53] <cjwatson> seb128: I was on vacation.  Merged now
[08:53] <seb128> cjwatson, hey, thanks ;-)
[08:53] <seb128> wb!
[08:55] <cjwatson> Anyone know why there's unmerged azure.device.tar.gz stuff on nusakan's cdimage deployment?
[11:18] <FourDollars> Hi, does anyone have time to review my patch of https://code.launchpad.net/~fourdollars/ubuntu/trusty/efibootmgr/1460521/+merge/260705 ?
[11:22] <FourDollars> There are some OEM projects blocked by https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1460521. :-(
[12:32] <pitti> uh, what kind of disaster struck our buildds?
[13:06] <cjwatson> pitti: Not clear what happened, perhaps some kind of network blip.  Re-enabling
[13:08] <pitti> cjwatson: cheers
[13:52] <smoser> teward, slow response to ping
[13:52] <smoser> but here now
[14:57] <pitti> hallyn: ah, I followed xnox's unified hierarchy work on the upstream ML
[14:57] <bdmurray> infinity: I thought the recommended path in this case was from T-U-V-W or T->X not T->W.
[14:57] <pitti> hallyn: that's also nice work, it should allow us to simplify/drop the unpriv LXC hacks/patches, right?
[14:58] <pitti> bdmurray: right, but ideally we want last LTS -> today's devel series upgrade to always work
[14:58] <pitti> bdmurray: as we need that for last LTS -> next LTS anyway
[14:58] <xnox> pitti: i'm trying for it to work with name=systemd mount and unified mount at the same time.... e.g. do runtime detection. cause we will need that for live upgrade / re-exec.
[14:58] <pitti> bdmurray: so it's true that we don't officially support it, but we appreciate bug reports anyway
[15:01] <bdmurray> pitti: understood
[15:22] <hallyn> pitti: we'll see :)
[15:22] <hallyn> pitti: which unpriv lxc hacks?
[15:23] <pitti> hallyn: this one mostly: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/core-Put-session-scopes-into-all-cgroup-controllers.patch?h=ubuntu
[15:23] <hallyn> xnox: but i haven't looked closely yet - were you saying you were able to mount freezer in both unified and non-unified hierarchy at the same time?
[15:23] <hallyn> pitti: oh, not at all.
[15:23] <xnox> hallyn: that is possible with extra kernel command line which might not be desirable.
[15:24] <hallyn> xnox: that's a step up - i thought the docs said it wasn't possible at all
[15:24] <pitti> hallyn: it's what caused that cpu hotplug "I need my cpuset controller back" bug report, and it generally seems unfriendly to have to pre-allocate all controllers for upriv LXC that way
[15:24] <xnox> hallyn: what i was doing so far is, mount legacy controllers where they are. mount unified hierchy in /sys/fs/cgroup/systemd and get benefit of the cgroup.populated file
[15:24] <pitti> hallyn: i. e. that still smells like an userspace workaround for "we want proper cgroup namespaces" to me?
[15:25] <hallyn> pitti: well there's more to it than that.  cgroupns may let us drop cgmangaer, but unpriv users still would need for systemd to set them up so that they can create a new cgroupns inthe frest place
[15:25] <hallyn> i think
[15:26] <hallyn> xnox: if we're going to support 12.04 and 14.04 containers under 16.04, we'll need all current controllers mounted non-hierarchy (along side hierachical)
[15:26] <hallyn> uh, non-unified that is
[15:27] <hallyn> pitti: but i think we can work together to make it all more seamless (for unpriv containers).
[15:28] <hallyn> of course, the stumbling block will be lxc using systemd's api
[15:28] <pitti> hallyn: right, that'd be nice; aside from that "I stomp over all controllers" unfriendliness didn't cause much trouble, but it's a bit of a tech debt
[15:28] <hallyn> anyway first i'll look at xnox's patchset :)  and by first i mean first by way of systemd stuff, not first thing i'm working on :)
[15:28] <pitti> hallyn: hehe
[15:29] <hallyn> pitti: couldn't quite parse that
[15:29] <pitti> hallyn: anyway, I'm happy to give you a tour through the debian git, how we maintain patches etc., if/once you want; just let me know if/when you want to start with something
[15:29] <hallyn> (missing comma somewhere?  or i'm misreading)
[15:29] <hallyn> pitti: thanks, sounds good!
[15:30] <pitti> hallyn: ... unfriendliness "the patch" didnt' cause much trouble
[15:30] <pitti> hallyn: eek :) -- (but it's time to make dinner anyway, bbl)
[15:30] <hallyn> \o