=== masACC is now known as maswn
=== maswn is now known as maswan
=== negronjl is now known as negronjl-afk
[08:31] <dholbach> good morning
[08:35] <LocutusOfBorg1> hi dholbach
[08:35] <LocutusOfBorg1> :)
[08:35] <dholbach> hi LocutusOfBorg1
=== mfisch is now known as Guest12671
[09:29] <seb128> lamont`, hey, could you review the changes on https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/583216 ?
[09:30] <ubottu> Launchpad bug 583216 in postfix (Ubuntu) "inet_protocols can't be preseeded" [Medium,In progress]
[09:39] <seb128> mvo, hey, is https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1274466 something you still plan to work on? apparently your previous sru has been supperseeded by a security update
[09:39] <ubottu> Launchpad bug 1274466 in apt (Ubuntu Trusty) "apt-ftparchive on-disk cache format changed between lucid and precise, results in Packages files with silently corrupted checksums fields" [High,In progress]
[09:40] <seb128> mvo, (it's in the sponsoring queue)
[09:40] <mvo> seb128: yeah, I need to look at this, but not right now, snappy is taking precedence
[09:41] <seb128> mvo, does it need sponsors or is that on your list?
[09:41] <mvo> seb128: its on my list, I don't know why its on the sponsoring queue
[09:45] <seb128> mvo, ok, unsubscribing sponsors then, danke ;-)
[09:45] <seb128> mvo, oh and happy new year! :-)
[09:46] <mvo> seb128: thanks, happy new year to you as well :)
[09:49] <seb128> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
[09:55] <Odd_Bloke> I'm looking at making changes to live-build for CPC; is the source for Ubuntu's version kept in version control anywhere?
[09:59] <cjwatson> Odd_Bloke: not afaik
[09:59] <cjwatson> just use the source package
[10:03] <Odd_Bloke> Ack.
[10:03] <Odd_Bloke> Thanks.
=== MasterPieceF is now known as MasterPiece
[10:39] <seb128> is errors.ubuntu.com working for others?
[10:39] <seb128> oh, it works, the "loading..." just takes a while
[10:39] <seb128> ignore that
[10:45] <lamont`> seb128: in my pre-awake state, that patch looks beautiful. (583216)
[10:45] <seb128> lamont`, hey, happy new year ;-)
[10:46] <lamont`> seb128: I'll look again in more detail after I wake up, but it does seem to clearly be an oversight with a trivial fix
=== lamont` is now known as lamont
[10:47] <seb128> lamont, great, thanks
=== apachelogger is now known as sitter
=== vrruiz_ is now known as rvr
=== _salem is now known as salem_
=== MacSlow is now known as MacSlow|lunch
[12:18] <flexiondotorg> Does anyone know if multilib gir support is planned for 15.04?
[12:26] <cjwatson> flexiondotorg: It's already there
[12:27] <flexiondotorg> cjwatson, Excellent! When did it land?
[12:28] <cjwatson> flexiondotorg: 2014-10-28
[12:28] <flexiondotorg> cjwatson, Thanks for the info. Brilliant.
=== MacSlow|lunch is now known as MacSlow
[13:14] <xnox> infinity: sysdeps/*/multiarch/* in glibc source code have nothing to do with Debian-multiarch term, right?
[13:14]  * xnox is slowly going mad here
[13:25] <highvoltage> someone please take some cheesecake to xnox
[13:31] <xnox> hhhmmmm cheesecake
[14:09] <tedg> jodh, Yesterday seb128 was pinging me about using UAL with systemd as PID 1, specifically replacing cgmanager calls.
[14:09] <tedg> jodh, How is session upstart making cgroups in that case?
[14:09] <tedg> jodh, I don't see any generic cgroups functionality in systemd interfaces.
[14:10] <jodh> tedg: upstart calls cgmanager directly for cgroup handling.
[14:12] <tedg> jodh, So then if we're using Upstart sessions we still need cgmanager running?
[14:13] <jodh> tedg: if we want cgroup support for those sessions, yes.
[14:14] <tedg> jodh, Does that work? Or do cgmanager and systemd fight?
[14:15] <jodh> tedg: I thought hallyn made them tolerate each other, but best to check with him on the specifics.
[14:16] <hallyn> so far they tolerate each other.  cgmanager is disabled under systemd by default though, you have to enable it
[14:16] <tedg> They each sit in the corner and stare angrily at each other. :-)
[14:16] <hallyn> well mor elike they try to give each other the cold shoulder :)
[14:17] <tedg> Okay, so I guess the next question is whether we expect for 15.04 to have a systemd session for Unity8.
[14:17] <tedg> If we expect it to be Upstart, there's no UAL changes, but if we want to be systemd, we need *all* the changes.
[14:18] <tedg> seb128, ^
[14:19] <hallyn> I think we expect systemd and cgmanager both in 14.04
[14:19] <hallyn> uh, 15.04
[14:19] <hallyn> by 16.04 hopefully well have cgroupns in the kernel and maybe not need cgmanager.
[14:19] <seb128> tedg, systemd is going to be pid1 in vivid, I don't think we should ask users to change init system to try unity8 desktop
[14:21] <tjaalton> there's no partner repo for vivid? my adobe-flashplugin is out-of-date because of that..
[14:23] <tedg> seb128, I don't think they need to change init systems, just start the cgmanager unit.
[14:23] <tedg> seb128, Are you guys migrating the Unity7 session management to systemd?
[14:23] <seb128> tedg, you expect normal users to have to deal with command line to be able to log into a working unity8 session?
[14:23] <seb128> tedg, there is session management migration planned for this cycle
[14:23] <tedg> seb128, No, I expect us to make it work :-)
[14:24] <tedg> Don't we need cgmanager for things like lxc as well? Why is it off by default?
[14:25] <seb128> tedg, it's written in the bug I pointed you at yesterday
[14:25] <seb128> tedg, https://bugs.launchpad.net/ubuntu/+source/cgmanager/+bug/1400394/comments/8
[14:26] <ubottu> Launchpad bug 1400394 in ubuntu-app-launch (Ubuntu) "Unity8 fails to start applications under systemd init (cgmanager issue?)" [Undecided,New]
[14:29] <tedg> Hmm, so if we can't have cgmanager, then Upstart needs to be able to create cgroups with systemd.
[14:30] <tedg> UAL only queries the groups, Upstart creates them.
[14:31] <tedg> seb128, Is there a reason we're not just migrating all the sessions?
[14:31] <tedg> I hate flag days, but I kinda feel like supporting both is going to be tricky.
[14:31] <seb128> tedg, needs resources
[14:31] <seb128> no other reason than "1 step at the time"
[14:31] <seb128> if we have people wanting to do it properly this cycle sure
[14:32] <seb128> but I'm unsure we do have anyone with slots to work on that, the pid1 transition is already going to require shared efforts
[14:32] <seb128> didrocks, pitti, ^ opinion?
[14:32] <tedg> To be clear, I don't *want* to, but it might be the path of least resistance.
=== negronjl-afk is now known as negronjl
[14:35] <seb128> tedg, it feels like we are going to need to make u-a-l talk to systemd's cgroup manager anyway, so we have to write that code
[14:35] <seb128> shouldn't be that much work to have new code/old code in if blocks depending on the cgmanager running?
[14:35] <seb128> rather than replacing one by the other
[14:38] <tedg> seb128, UAL I don't think is as much the issue as we'd need to port Upstart as well.
[14:38] <seb128> tedg, how so?
[14:38] <tedg> seb128, Upstart creates the cgroups, so it's the one that does all the initial cgmanager work there. UAL only queries them once created.
[14:38] <tedg> seb128, Upstart can't create them without cgmanager.
[14:39] <Riddell> procps broken in vivid launchpad builds? https://launchpad.net/ubuntu/+source/kbookmarks/5.6.0-0ubuntu1
[14:41] <seb128> Riddell, it's likely the sysvinit upload from didrocks earlier, I'm deleting it from proposed
[14:41] <seb128> Laney found a typo in it
=== Guest12671 is now known as mfisch
[14:45] <arges> hallyn: hey! heads up, i see a couple of uploads from you of libvirt in trusty queue, I'm going to have to reject one since they have different changes but are the same version
[14:49] <xnox> infinity: doh - enable single DSO with optimizations for multiple architectures
[15:15] <didrocks> seb128: tedg: sessions were never used in prod in any distro yet, I think we would need to devote a whole cycle just for this
[15:16] <didrocks> so not coupling the 2 transitions at the same time IMHO
[15:16] <seb128> +1
[15:17] <tedg> didrocks, ? Upstart session were used in 14.04.
[15:17] <didrocks> tedg: systemd session
[15:17] <tedg> Oh, yes. But if systemd and cgmanager don't get along...
[15:17] <tedg> We either need to port Upstart to systemd or switch.
[15:18] <didrocks> not sure what it will take to have upstart session working properly on systemd
[15:19] <didrocks> but seems a saner approach to me
[15:19] <hallyn> arges: grrr.
[15:19] <tedg> jodh, Thoughts? ^
[15:19] <didrocks> tedg: I guess we don't see that on the desktop because we don't use cgmanager there?
[15:19] <tedg> didrocks, It feels to me like pushing Upstart in a direction that isn't truly useful.
[15:20] <jodh> tedg: the point of upstart using cgmanager was to abstract the cgroup handling to a 3rd party, so maybe cgmanager could detect if systemd is running and proxy the calls to pid 1? hallyn?
[15:20] <didrocks> tedg: right, but having both transitions at the same time seems risky as well
[15:20] <tedg> didrocks, Well, apparently with systemd as PID 1 we don't end up being able to use cgmanager. Read pitti's comment on the bug above.
[15:21] <tedg> You think of it wrong. It's just one transition from upstart to systemd, just two instances of it. ;-)
[15:21] <hallyn> arges: trying to grab the sources before they get deleted so i can combine them
[15:21] <arges> hallyn: yup that's why i pinged you first : )
[15:21] <tedg> I don't disagree, just not sure that supporting the Upstart user sessions is worth it.
[15:22] <didrocks> tedg: well, we don't already have the ressources in migrating all upstart services (system) to systemd
[15:22] <didrocks> tedg: so, not that I disagree, but as seb128 told, "it's work" :)
[15:22] <didrocks> and flag days, well…
[15:25] <hallyn> arges: got them, thanks
[15:25] <xnox> seb128: didrocks: systemd user sessions where used on MeeGo 1.3 I believe.... but that was a while back and not the current state of affairs.
[15:25] <xnox> tedg: we have working cgmanager under systemd.
[15:25] <didrocks> xnox: yeah, I wouldn't call that "production" though :p
[15:25] <xnox> didrocks: true.
[15:25] <arges> hallyn: ok i'll reject the later upload for (1403648/8), and you can rebase off that then?
[15:25] <didrocks> xnox: see https://bugs.launchpad.net/ubuntu/+source/cgmanager/+bug/1400394/comments/8 for what tedg is refering to
[15:25] <ubottu> Launchpad bug 1400394 in ubuntu-app-launch (Ubuntu) "Unity8 fails to start applications under systemd init (cgmanager issue?)" [Undecided,New]
[15:25] <xnox> didrocks: ah, bugs. ok =)
[15:26] <xnox> didrocks: converting desktop to systemd-usersession should be easy.
[15:26] <xnox> didrocks: converting phone is not that easy, however I have good thought on how to implement it.
[15:27] <didrocks> xnox: we already don't have the resources the migrate all system services (look at the progress we got), and seb128 was talking about the unity8 session on desktop, so basically converting phone
[15:27] <didrocks> xnox: clearly not achievable this cycle looking at the remaining WI
[15:28] <xnox> didrocks: wrt. to the bug report -> ubuntu-app-launch should be converted to use systemd. Isn't snappy using systemd to launch things?!
[15:28] <xnox> didrocks: and the bug is with click app launching, rather than unity8.
[15:29] <didrocks> xnox: that would be for mvo, but I guess it's only system service, so easy ;)
[15:29] <didrocks> xnox: under an unity8 session on the unity8 preview desktop
[15:29] <xnox> didrocks: we have a big chunk on the phone of "things in the container, exported to upstart, jobs launched on the system"
[15:29] <didrocks> xnox: we don't use click on the unity7 session
[15:29] <xnox> didrocks: i have a thought of generating units for those, and having the bridge start & stop those units, and everything else binding to them.
[15:29] <xnox> pitti: ogra_ ^
[15:30] <xnox> jodh: ^
[15:30] <xnox> it should be simple enough to implement inside the current upstart socket bridge.
[15:30] <didrocks> interesting
[15:30] <xnox> xnox: well the socket bridge may need a rename as it's: upstart-events or systemd-generator
[15:31] <hallyn> arges: I pushed a new one that combines the two
[15:31] <arges> hallyn: even better.
[15:32] <hallyn> arges: thanks, ttyl :)
[15:34] <arges> later
=== dholbach_ is now known as dholbach
[15:53] <arges> hallyn: for bug 1403648 chiluk says the current patch is not acceptable for SRU
[15:53] <ubottu> bug 1403648 in libvirt (Ubuntu Utopic) "Apparmor denies qemu access to a number of important directories." [High,New] https://launchpad.net/bugs/1403648
[15:53] <arges> hallyn: so we may  need another upload for just the one fix instead of combining them
[15:53] <arges> chiluk: can you update the bug so that its clear the fix as it stands isn't ready and why?
[15:54] <chiluk> arges basically I wanted to investigate why qemu needs access to /tmp....
[15:55] <chiluk> as security doesn't like giving access to /tmp for security reasons.
[15:55] <chiluk> arges it might be better solved by patching libvirt to use something like /tmp/qemu or /tmp/libvirt for tmp files and giving it write access to that.
[15:56] <arges> chiluk: ok makes sense, i'll reject it. sorry hallyn ...
[15:58] <chiluk> arges also one of the permitted directories will likely need to be added to the ceph charm.
[15:59] <hallyn> i'll just wait for chiluk's patch
[15:59] <hallyn> chiluk: i was going based on jdstrand's comments
[15:59] <hallyn> note that for vivid libvirt simply denys the access
[16:00] <arges> hallyn: ok to reject? (haven't done it yet)
[16:00] <chiluk> hallyn... I haven't reviewed your patch.
[16:00] <hallyn> only for SRU does it allow it, to prevent breakges
[16:00] <chiluk> I'm currently in a meeting.
[16:00] <hallyn> arges: yeah i have the source.  i'll re-upload without that particular fix
[16:00] <chiluk> I'll take a look right after this.
[16:00] <hallyn> \o
[16:00] <arges> hallyn: ok cool. what a fun morning
[16:01] <lamont> seb128: after more review, yeah, +1.  adding a comment to the bug
[16:02] <seb128> lamont, hey, thanks!
[16:02] <seb128> lamont, do you plan to handle uploads as well?
=== G4MBY is now known as PaulW2U
[16:05] <hallyn> arges: oh, so you should reject the utopic libvirt one for the same reason
[16:05] <chiluk> hallyn arges, really the question should be why does libvirt /qemu try to access /tmp... And if it really shouldn't be accessing /tmp why not patch libvirt/qemu to not do so in the first place.
[16:06] <arges> hallyn: ok done
[16:06] <hallyn> chiluk: i don't believe libvirt is doing it
[16:06] <hallyn> chiluk: i believe that's on your end.  we're jsut trying to accomodate what you want.  i could be wrong...
[16:06] <chiluk> yeah I'm pretty sure it's just qemu
[16:07] <hallyn> ok
[16:07] <chiluk> silencing the messages is pretty important... as it's filling up logs for anyone running even a moderately sized cloud
[16:07] <lamont> seb128: it's committed for 2.11.3-2.  There's even a chance that I'll upload it within 7-10 days... :(
[16:07] <hallyn> chiluk: for vivid those are now silenced
[16:08] <hallyn> arges: ok, new trusty upload without the /tmp junk pushed
[16:08] <seb128> lamont, ok, I guess we can unsubscribe the sponsors at least, it's going to make it in one way or another ;-)
[16:08] <chiluk> hallyn I was hoping to get feedback from the customer on this before proceeding with the SRU as well.
[16:09] <lamont> seb128: when I upload it to debian, it will be merged with ubuntu (hopefully with no -1s...), to make the merge easier
[16:09] <hallyn> FEH
[16:09] <chiluk> crap you guys are working too fast..
[16:09] <chiluk> ok I'm out of my meeting now.
[16:09] <hallyn> arges: please delete them all, i should have kept the cpeh.conf perms
[16:09] <hallyn> chiluk: it's a context switch thing, i want this put aside before i lose data
[16:09] <seb128> lamont, k, anyway I unsubscribe the sponsors, you are in charge of it now ;-)
[16:09] <lamont> seb128: ack
[16:09] <arges> hallyn: ok
[16:10] <hallyn> arges: sorry.
[16:10] <hallyn> chiluk: i think we should have a separate bug about the /tmp access stuff
[16:10] <arges> hallyn: its no problem
[16:10] <didrocks> jamespage: hey! small question on radosgw-agent: nothing (no UI/web) is changing ENABLED=yes/no in /etc/default/radosgw-agent right? I can replace that with an upstart override on upgrade?
[16:10] <hallyn> chiluk: unless you think i should put the 'deny /tmp/** r" stuff in SRU, to silcence the denials?
[16:10] <hallyn> chiluk: and then we fix any resulting breakages in anew bug?
[16:10] <chiluk> hallyn I'm not following... so a bug for libvirt apparmor profile , and for one to patch qemu accessing /tmp?
[16:11] <hallyn> chiluk: right the current bug is  mostly about /**/ceph.conf denial right?  and /tmp is a secondary issue
[16:11] <chiluk> well it's really more about silencing apparmor than anything else.
[16:11] <chiluk> or it should be.
[16:12] <hallyn> so you're ok with SRU for now deniying the /tmp access silently?
[16:13] <chiluk> hallyn according to jdstrand comment #12   the SRU should be permissive of those directories..
[16:13] <chiluk> if I'm reading it correctly.
[16:13] <jamespage> didrocks, I'd need to refresh my memory
[16:13] <hallyn> chiluk: that's what my original sru did
[16:13] <chiluk> hallyn... I never said to reject the sru... nor did anyone give me a chance to review it.
[16:14] <hallyn> so if you're ok with that i can re-upload :)
[16:14] <didrocks> jamespage: the upstart service is disabled by default and you control the enablement state thanks to this setting. As we try to get read of those ENABLED=yes/no when switching to systemd, I want to ensure I'm not going to break you :)
[16:15] <chiluk> yeah I'm ok with permissive for the sru to silence apparmor ... I think that's what jdstrand intended...
[16:15] <hallyn> right
[16:15] <chiluk> so yeah go ahead and re-upload.
[16:15] <chiluk> hallyn .. I'll write the SRU template
[16:16] <hallyn> thx
[16:16] <hallyn> left hand is holding a phone, right a coffee;  i'll upload it in a bit
[16:17] <chiluk> hallyn am I correct in my apparmor understanding that without an explicit rule apparmor is permissive ?
[16:17] <hallyn> no
[16:17] <hallyn> it by default denies, noisily
[16:17] <chiluk> hmm so we are changing the original behavior
[16:17] <hallyn> yes
[16:17] <jamespage> didrocks, ah right
[16:17] <hallyn> that's why jdstrand was hesitant
[16:17] <chiluk> hallyn that makes me wonder why jdstrand suggested making it permissive then.
[16:18] <jamespage> didrocks, the problem there is that there is no good default configuration
[16:18] <hallyn> chiluk: bc not breaking users is important
[16:18] <didrocks> jamespage: that's fine, I can ship an .override by default to disable the job
[16:18] <hallyn> (for sru)
[16:18] <jamespage> didrocks, awesome
[16:18] <didrocks> jamespage: and handling upgrade with removing it if the previous version was "yes"
[16:18] <didrocks> ok, doing that then, thanks!
[16:18] <jamespage> didrocks, right
[16:18] <hallyn> chiluk: so i'd appreciate you running your workloads on vivid so we can track down what failures the denials cause :)
[16:18] <chiluk> hallyn, but if apparmor denies by default, then the /tmp has always been getting denied.
[16:19] <hallyn> yes, it's just noisy
[16:19] <chiluk> so why not make it an explicit denial for the SRU?
[16:19] <chiluk> I'm not arguing one way or the other.
[16:19] <chiluk> hallyn just a little confused.
[16:20] <hallyn> let's see if jdstrand has a comment on that.  maybe he thought you were having to work around it by adding the permission?
[16:20] <chiluk> maybe..
[16:20] <jdstrand> what is the bug number?
[16:20] <smoser> anyone else use chromium on vivid? once i do a hangout i lose keyboard input entirely to chromium.
[16:20] <chiluk> jdstrand, 1403648
[16:21] <jdstrand> "However I also don't want to break existing setups by adding an explicit deny rule that would block all access to /tmp and /var/tmp if the user updated policy for that or is putting disks in /tmp for testing environments"
[16:21] <jdstrand> yes, it was denied before
=== roadmr is now known as roadmr_afk
[16:21] <jdstrand> but, if the user adjusted their policy to allow it, I was saying I didn't want to break that
[16:21] <hallyn> i see
[16:21] <chiluk> wouldn't dpkg resolve user updated policys?
[16:22] <smoser> it sounds like https://code.google.com/p/chromium/issues/detail?id=360388 or http://askubuntu.com/questions/457541/unable-to-type-anything-on-chromium
[16:22] <jdstrand> it would show the difference, yes
[16:22] <arges> smoser: i've had that happen to me on chromium, but not on chrome. could be 1307648 resurfacing?
[16:23] <chiluk> hallyn jdstrand, so wouldn't it be better to keep the behavior as it is then, and let the user resolve the config difference on upgrade?
[16:23] <jdstrand> it is a very tricky thing modifying config files in SRUs
[16:23] <jdstrand> people sometimes do the wrong thing
[16:23] <smoser> right.l thats the other link.
[16:23] <smoser> arges, you just run 'ibus exit' ?
[16:23] <smoser> that does seem to fix it, but i'm not sure what other fallout there would be.
[16:24] <jdstrand> note that the access I granted was very small-- read on the directory, not on the files in the directory
[16:24] <arges> smoser: yea seems like there should be a better solution. branded chrome works fine, so maybe there is a patch that hasn't made it to chromium to fix this
[16:24] <jdstrand> it is just enough access to remove confusion as opposed to adding something that could potentially break people
[16:25] <jdstrand> imo, that is a reasonable SRU compromise
[16:25] <chiluk> arges hallyn ^^^^ ... how do you guys feel about that.
[16:26] <jdstrand> it weighs the confusion caused by the bug against the slight additional access of VMs being able to ls /tmp and /var/tmp
[16:26] <jdstrand> without adding a possibility for regression
[16:27] <arges> I think if jdstrand is happy with any security implications then it seems reasonable.
[16:28] <chiluk> ok.. so the original upload sounds good to me then http://launchpadlibrarian.net/194182873/libvirt_1.2.2-0ubuntu13.1.8_1.2.2-0ubuntu13.1.9.diff.gz
[16:30] <chiluk> hallyn arges jdstrand I'll do some testing today on this... hopefully I don't find anything interesting.
[16:30] <jdstrand> I am. I don't like the access, but the denial leads to confusion. the access is very limited and guarantees no chance of regression. with what is in vivid, all future releases properly deny it
[16:31]  * smoser installs chrome
[16:31] <hallyn> arges: so do you magically have what you need to accept the right one? :)
[16:31]  * hallyn waves his hands  "magic"
[16:31] <chiluk> hah.
[16:32] <arges> hallyn: well since i went on a rejection rampage, there isn't anything in teh queue, can you re-upload the version that chiluk requests?
[16:32] <chiluk> arges... too fast..
[16:33] <jdstrand> hallyn: actually, before you upload
[16:33] <jdstrand> hallyn: can you add a comment above the accesses that it only allows read access to the directory to workaround the bug (and reference the bug number)?
[16:33] <hallyn> arges: https://launchpad.net/ubuntu/trusty/+queue?queue_state=4&queue_text=libvirt  ?
[16:34] <hallyn> jdstrand: i did reference the bug#
[16:34] <hallyn> " # avoid spurious denials (see lp#1403648)"
[16:34] <jdstrand> hallyn: eg: # workaround LP: #1403648 by allowing read access to the directory. This will be removed in future releases
[16:34] <ubottu> Launchpad bug 1403648 in libvirt (Ubuntu Utopic) "Apparmor denies qemu access to a number of important directories." [High,New] https://launchpad.net/bugs/1403648
[16:34] <hallyn> ok
[16:34] <jdstrand> hallyn: well, something like that. whatever you think
[16:35] <hallyn> i'm taking your text and pushing
[16:35] <hallyn> (in a few mins)
[16:35] <jdstrand> hallyn: thanks. I think that will make things clearer for 14.10 to 15.04 and LTS to LTS upgrades too
[16:35] <jdstrand> (for people who did modify the poolicy and are seeing the diff)
[16:36] <arges> i'll check it in a bit... brb
=== roadmr_afk is now known as roadmr
[16:52] <infinity> xnox: multiarch in the glibc world means GNU IFUNC.
[16:53] <hallyn> jdstrand: chiluk: arges: https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=libvirt  and https://launchpad.net/ubuntu/utopic/+queue?queue_state=1&queue_text=libvirt . hopefully those do what you guys wanted
[16:54] <jdstrand> the apparmor changes lgtm
[16:55] <hallyn> thanks!  ttyl
[16:57] <jdstrand> thank you! :)
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
=== salem_ is now known as _salem
=== marcoceppi_ is now known as marcoceppi