intrigeri:
> intrigeri:
>> 1. ensure the blocking kernel bug is fixed:
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883703#32
> That's now done in stretch-backports: linux-latest was updated and for
> example linux-image-amd64 now pulls linux-image-4.14.0-0.bpo.3-amd64
> (version 4.14.1
intrigeri:
> 1. ensure the blocking kernel bug is fixed:
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883703#32
That's now done in stretch-backports: linux-latest was updated and for
example linux-image-amd64 now pulls linux-image-4.14.0-0.bpo.3-amd64
(version 4.14.13-1~bpo9+1).
So the
Hi,
for the record I think the next steps are:
1. ensure the blocking kernel bug is fixed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883703#32
2. adjust the Stretch packaging branch so it uses the same
implementation as testing/sid (#879585)
3. update the stretch-pu request (#8826
Hi,
Fabian Grünbichler:
> I am not sure whether the features file itself would really need to be a
> conf file though, if it is already pointed to by a conf file directive?
> putting the features file itself somewhere into /usr/share would at
> least allow a sane divertion without having to touch
On Tue, Dec 05, 2017 at 11:37:51AM +0100, intrigeri wrote:
> Hi Fabian!
>
> Fabian Grünbichler:
> > is there a particular reason for not putting this into the (included by
> > default) /usr/share/apparmor, but into parser.conf directly?
>
> Does "this" refers to the features file itself or to the
Hi Fabian!
Fabian Grünbichler:
> is there a particular reason for not putting this into the (included by
> default) /usr/share/apparmor, but into parser.conf directly?
Does "this" refers to the features file itself or to the
features-file= directive?
What do you mean with /usr/share/apparmor bei
On Mon, Oct 23, 2017 at 08:34:58AM +0200, intrig...@debian.org wrote:
> Package: apparmor
> Version: 2.11.0-3
> Severity: important
>
> This is about supporting Stretch users who have enabled AppArmor
> and run a new kernel, e.g. from stretch-backports.
>
> Similarly to #879584, let's pin the App
Control: severity -1 important
> It'll become more important once Linux 4.13+ lands in
> stretch-backports,
… which is now the case.
> but even then IMO that'll remain a normal severity bug because
> a combination of 2 non-default settings is required to trigger
> any problem.
Now that AppArmor
Control: severity -1 normal
1. AppArmor is not enabled by default in Stretch
2. Currently stretch-backports has Linux 4.12 that's compatible with
the policy shipped in Stretch, without need for any pinning
⇒ lowering priority. It'll become more important once Linux 4.13+
lands in stretch-backp
intrig...@debian.org:
> This is about supporting Stretch users who have enabled AppArmor
> and run a new kernel, e.g. from stretch-backports.
> Similarly to #879584, let's pin the AppArmor feature set to the one
> supported by the Stretch stock kernel, i.e. the one the AppArmor
> policy shipped in
Package: apparmor
Version: 2.11.0-3
Severity: important
This is about supporting Stretch users who have enabled AppArmor
and run a new kernel, e.g. from stretch-backports.
Similarly to #879584, let's pin the AppArmor feature set to the one
supported by the Stretch stock kernel, i.e. the one the A
11 matches
Mail list logo
