This bug was fixed in the package apparmor - 2.8.96~2652-0ubuntu3
---
apparmor (2.8.96~2652-0ubuntu3) utopic; urgency=medium
* 08-phpsysinfo-policy-updates.patch: update for new phpsysinfo on Ubuntu
14.10
* 09-apache2-policy-instructions.patch: update for recent Debian/Ubuntu
** No longer affects: apparmor
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1350673
Title:
System policy cache may become stale after a system image update
Status in “
** Tags added: touch-2014-09-11
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1350673
Title:
System policy cache may become stale after a system image update
Status in
** Also affects: apparmor
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1350673
Title:
System policy cache may become stale a
** Branch linked: lp:~tyhicks/apparmor/abstract-sockets
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1350673
Title:
System policy cache may become stale after a system
** Changed in: apparmor (Ubuntu)
Status: Triaged => In Progress
** Changed in: apparmor (Ubuntu)
Importance: High => Critical
** Tags added: rtm14
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
On which device are we at ~4 seconds per profile?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1350673
Title:
System policy cache may become stale after a system image
That said, if the hash operation was very fast, that would be a useful
improvement going forward (I don't think we could do that for rtm). I do
worry that if we compute hashes for all policy on every boot to see if
we need to recompile, that is going to be more costly for the average
user. What we
So, if done right, this should not affect average users since on desktop
during the upgrade process, the upstart job will be called after the
unpack, and we already unconditionally invalidate the cache and
recompile on upgrades. This will update the files such that the cache
won't be cleared on the
Clearing the cache is expensive; if this chain of events will only
affect 'developers', that's not ideal but tolerable. But if it'll affect
average users we should really try to avoid clearing the cache.
I haven't thought this through very far, but I wonder if we can do a
better job solving this i
10 matches
Mail list logo
