On 2012-04-09 21:58, Adam D. Barratt wrote:
> Policy section 9.3.2:
>
> Files and directories under `/run', including ones referred to via the
> compatibility paths `/var/run' and `/var/lock', are normally stored on
> a temporary filesystem and are normally not persistent across a
> reboot. The `
On Mon, 2012-04-09 at 20:50 +0200, René Mayrhofer wrote:
> The subdirectory under /var/lock is used to restrict its permissions for
> more secure locking, and upstream will most probably not change it. I do
> not currently agree that this is in violation to Debian Policy, so
> unless you can con
On Mon, 2012-04-09 at 20:50 +0200, René Mayrhofer wrote:
> On 06.04.2012 17:32, Aristov Max wrote:
> > According to DP "/run is cleared at boot", so some changes should be made
> > to the upstream code, for example strongswan could keep files directly in
> > /run/lock directory.
> > I noticed the
On 06.04.2012 17:32, Aristov Max wrote:
According to DP "/run is cleared at boot", so some changes should be made to
the upstream code, for example strongswan could keep files directly in /run/lock
directory.
I noticed the problem, when configuration of base-files failed in multistrapped
envir
Package: strongswan-starter
Version: 4.5.2-1.3
Severity: serious
Justification: Policy 9.1.4
According to DP "/run is cleared at boot", so some changes should be made to
the upstream code, for example strongswan could keep files directly in
/run/lock directory.
I noticed the problem, when config
5 matches
Mail list logo
