[03:34] <hallyn> jjohansen1: stgraber: if i'm running an artful container on an artful host with aa namespaces, i should be able to load the lxc policies right?
[03:34] <hallyn> bc /lib/apparmor/profile-load skips that part when running in a container
[03:34] <hallyn> aa-status shows 0 policies
[03:35] <hallyn> and i'mw ondering whether that's expected
[03:35] <stgraber> you should be, yes, do you have the apparmor namespace and stacking setup?
[03:35] <stgraber> is that lxd or lxc?
[03:35] <hallyn> lxd
[03:36] <hallyn> hm, is my lxd way out of date?
[03:36] <hallyn> 2.18
[03:36] <stgraber> that should be fine
[03:36] <hallyn> but that shouldn't matter
[03:36] <hallyn> it's lxc in the container,
[03:36] <hallyn> and that's built from the source in ubuntu-lxc ppa
[03:36] <hallyn> oh, but that's not the problem either :)
[03:36] <stgraber> hallyn: what's /proc/<PID>/atttr/current for pid1 of the lxd container?
[03:36] <hallyn> /lib/apparmor/profile-load is the probem
[03:37] <hallyn> when I edit /lib/apparmor/profile-load to remove the contaienr check, then policies load
[03:37] <stgraber> hallyn: hmm, you're right that something's off with artful...
[03:37] <hallyn> lxd-alxc1_</var/lib/lxd>//&:lxd-alxc1_<var-lib-lxd>:unconfined (enforce)
[03:37] <stgraber> hallyn: no apparmor profiles loaded in there...
[03:37] <stgraber> hallyn: does a xenial container work?
[03:37] <hallyn> is that a case where artful is behind zesty
[03:37] <hallyn> uh, i'll check
[03:38] <hallyn> aa-status shows 0 policies there as well
[03:38] <stgraber> yeah, same here
[03:39] <stgraber> wth is going on
[03:40] <stgraber> we used to be getting profiles loading at some point
[03:40] <hallyn> nothing obvious in changelog
[03:41] <hallyn> i'm surprised no testcase barfed, if this is a regression
[03:42] <hallyn> what is is_container_with_internal_policy
[03:42] <stgraber> yeah, me too. I'm pretty sure I used to run into issues with tcpdump in containers, which meant that the tcpdump profile was loaded back then
[03:43] <stgraber> hallyn: hmm, I have another xenial system where I do have apparmor profiles loaded properly
[03:43] <hallyn> i'm guess /lib/apparmor/functions:is_container_with_internal_policy() regressed
[03:43] <hallyn> or rather, maybe apparmorfs in kernel regressed wrt to it
[03:44] <stgraber> yeah, that's what I'm wondering, I seem to remember us having pretty advanced logic not to trigger on kernels that shipped busted apparmor nesting
[03:44] <stgraber> I wonder if newer kernels changed that part and now we're not triggering when we should
[03:45] <hallyn> /sys/kernel/security/apparmor/.ns_name is empty
[03:45] <hallyn> that i believe is the problem,
[03:45] <hallyn> it expects to find the policy name in there
[03:46] <stgraber> stgraber@shell01:~$ cat /sys/kernel/security/apparmor/.ns_name
[03:46] <stgraber> lxd-shell01_<var-snap-lxd-common-lxd>
[03:46] <stgraber> on xenial 4.4 kernel
[03:46] <stgraber> and confirmed to be an empty string in bionic
[03:46] <stgraber> so yeah, that's the issue
[03:46] <stgraber> jjohansen1: ^
[03:47] <hallyn> dude!   stgraber: this is the first time i saw 'bionic' and realized you mean the release, not the android libc
[03:47] <hallyn> every single time someone has said "<...> bionic" i thought "why do they care so much about bionic now?"
[03:47] <stgraber> :)
[03:48] <stgraber> empty string rather than expected value would be something that bionic the C library would do too though ;)
[03:48] <hallyn> *sigh* so now..  i don't really wanna reinstall the lxd hosts with xenial just for this, wonder what the easiest short term remedy is :)
[03:48] <hallyn> heh :)
[03:48] <stgraber> installing the xenial 4.4 kernel on that host should work fine
[03:49] <stgraber> regardless of what the Ubuntu version on it actually is :)
[03:49] <hallyn> yeah - that's probably easiest.
[03:49] <hallyn> ok, thanks for the debug help :)  \o   (/me goes to sneak another girardelli chocolata)
[05:58] <jjohansen1> stgraber: yeah, bionic is a mess that I need to fix
[06:00] <stgraber> jjohansen1: hallyn was reporting this on artful though, is that known to be broken too?
[06:01] <jjohansen1> stgraber: no, I'll look into it
[06:23] <hallyn> cool, thanks guys.
[09:23] <rbasak> xnox: fancy tackling bug 1579695 for us? :)
[09:23] <ubottu> bug 1579695 in systemd (Ubuntu) "apport hook does not show the status of failed services" [Undecided,New] https://launchpad.net/bugs/1579695
[10:08] <xnox> rbasak, i will add it to the team backlog.
[10:09] <rbasak> Thanks!
[10:13] <andyrock> bdmurray: hey I need some help reviewing a software-properties MP
[10:13] <andyrock> https://code.launchpad.net/~azzar1/software-properties/canonical-livepatch/+merge/335219
[10:36] <Zahovay> Hello, I am a new programmer just about to join the ubuntu development team, may I ask here a few things? or this is not the chat room
[10:38] <sil2100> Zahovay: sure, ask away
[10:40] <Zahovay> sil2100: I was told that ubuntu makes no changes to the kernel. Other said they do make changes. I was wondering if laptop-mode-tools still exist and what is the purpose of that tools. Does it makes changes to the kernel? is it a laptop package of ubuntu?
[10:42] <sil2100> Zahovay: from what I see laptop-mode-tools still exists but it's in universe, so I don't have much knowledge about that tool - maybe someone else here would know
[10:43] <sil2100> Zahovay: as for the kernel, Ubuntu mostly ships what's upstream + some patches, so it's not completely vanilla
[10:43] <sil2100> You can check what Ubuntu changes are put on top of the kernel tree by fetching the Ubuntu linux source packages
[10:44] <Zahovay> Yes I know that it ships the upstream mainly, thou I think the upstream does not have a laptop specific project..
[10:46] <Zahovay> sil2100: do you happen to know who would be able to help me on this topic?
[10:50] <TJ-> sil2100: Zahovay told us yesterday in #ubuntu they want to get involved in improving power management on laptops. Had a long conversation with nacc and myself about it. We recommended finding a bug and working on it.
[10:51] <sil2100> I guess the best people to ask about this would be the kernel guys, but they're all *very* busy because of obvious reasons
[10:51] <sil2100> So I'd recommend just writing questions here and waiting for someone with the right knowledge set to see it and answer in his free time
[10:52] <Zahovay> Actually I think I need to find someone who manages the projects of ubuntu, since he can answer the question whether ubuntu plans laptop package or do not want to deal with that at all since the basics still have some troubles
[10:54] <rbasak> Ubuntu isn't developed that way.
[10:54] <rbasak> Nobody "manages" projects of Ubuntu.
[10:54] <TJ-> Zahovay: power control is mainly around the ACPI sub-system and is done in the mainline kernel
[10:54] <rbasak> Most of the time projects don't clash with each other. If you want to work on making power management better, you're welcome to do so.
[10:55] <TJ-> Zahovay: power management tools for adjusting power profiles are done mostly by desktop tooling in userspace
[10:55] <rbasak> In the rare case that there's some potential downside to your work and a decision needs to be made about the default, then we resolve that by speaking to each other, or deferring to the technical board if we cannot reach consensus.
[11:01] <Zahovay> Still I think the power management for desktops makes no sense since you have unlimited power. So I would only apply changes for laptops which means I should have a different package, shoudnt I?
[11:01] <rbasak> We try to not distinguish between the two.
[11:01] <rbasak> For example, what happens if I dock my laptop? :)
[11:02] <rbasak> Better to adjust power management behaviour based on power status, which I think tools already do?
[11:05] <Zahovay> well I think we could kill processes for laptops that do not need to run all the time. This is actually a kernel level implementation of longer battery life. Also hibernation on laptops differ from desktop hibernation (atleast I think, I may be wrong) am I wrong about these?
[11:05] <TJ-> Yes, and most DEs have power profile configuration for AC vs Battery too
[11:06] <TJ-> Zahovay: kill processes? that doesn't sound very user friendly. User's should choose to terminate processes if that is really necessary
[11:06] <TJ-> Zahovay: hibernation is identical; a swap partition or file large enough to store the RAM content
[11:10] <Zahovay> So what is the cause of shorter battery life on ubuntu compared to .. so called windows/macos ? as far as I read ubuntu misses power management implementations thats why forums suggets powertop. Are they wrong about it? or has it changed and I am out of date on this topic?
[11:10] <Zahovay> or is it hardware related problem?
[11:19] <TJ-> Zahovay: Sometimes it is related to the system firmware ACPI DSDT implementation. It is responsible for configuring devices and managing power. Many firmware's are tailored to Windows and do not activate all features when Linux is the OS.
[11:23] <Zahovay> TJ-: can we help this, or is it hardware manufacturers decision?
[11:26] <TJ-> Zahovay: there are always ways to hack around restrictions
[11:26] <Zahovay> I mean in a legal form
[13:42] <jibel> bdmurray, do you have the upgrade logs of the upgrade to bionic you mention in bug 1512322 ?
[13:42] <ubottu> bug 1512322 in dpkg (Ubuntu) "dpkg assert failure: dpkg: ../../src/packages.c:245: process_queue:" [High,Confirmed] https://launchpad.net/bugs/1512322
[14:59] <jibel> bdmurray, I added a test case to bug 1742147
[14:59] <ubottu> bug 1742147 in ubuntu-release-upgrader (Ubuntu) "upgrade from 17.10 to 18.04 fails with triggers looping" [High,Confirmed] https://launchpad.net/bugs/1742147
[15:03] <bdmurray> jibel: I added some more log info to bug 1512322
[15:03] <ubottu> bug 1512322 in dpkg (Ubuntu) "dpkg assert failure: dpkg: ../../src/packages.c:245: process_queue:" [High,Confirmed] https://launchpad.net/bugs/1512322
[15:04] <bdmurray> jibel: ah, that bug is helpful thanks
[15:08] <jibel> bdmurray, I'm trying to narrow down the packages involved but it seems the 3 additional pacakges are required to trigger the bug