Your message dated Thu, 07 Jan 2016 18:39:10 +0000
with message-id <[email protected]>
and subject line Bug#809502: Removed package(s) from unstable
has caused the Debian Bug report #739290,
regarding snooper: Replace use of lockdev with flock
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
739290: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739290
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libcec
Version: 2.0.3-1
Severity: normal
Dear maintainer,
I'm writing to you as the maintainer of lockdev (liblockdev1). I've
opened this bug because your package either has a build-depends on
liblockdev1-dev or is building binary packages with a dependency on
liblockdev1.
lockdev implements a library interface around the SYSV-style UUCP
device locks for TTY devices. However, this type of locking is
deprecated and unnecessary, at least on Linux; I'm not sure of the
status on kFreeBSD. The recommended alternative is direct use of
flock(2) on the corresponding device node. This will ensure that
locking will work properly with other programs also locking the device
node, and since the locks are implemented in the kernel, there's no
need for racy creation and deletion of lockfiles with the owner PID,
and no possibility of PID clashes or failure to reclaim lost locks if
the PID is reused. That is to say, the flock(2) interface is
guaranteed to be robust, while lockdev is not. For users not using
the C API (for example scripts), flock(1) from util-linux provides a
wrapper.
I'd like to remove lockdev entirely for jessie, providing that it's
possible to do so without breakage. Likewise I'd also like to convert
packages using UUCP-style locks which don't use lockdev. We currently
have at least three methods of device locking (UUCP-with-lockdev,
UUCP-without-lockdev and direct-flock), all of which have overlapping
or completely orthogonal semantics, which will result in not
respecting the other lock types if used in combination. Hence the
need to reduce this to a single robust locking strategy: just locking
the device directly.
It would be greatly appreciated if you could disable/remove lockdev
support from your package and remove it from the source build-depends
and/or package depends as appropriate, replacing this with flock(2)
calls instead of dev_lock and dev_unlock.
Many thanks,
Roger Leigh
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (550, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.11-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Version: 19991202-7.2+rm
Dear submitter,
as the package snooper has just been removed from the Debian archive
unstable we hereby close the associated bug reports. We are sorry
that we couldn't deal with your issue properly.
For details on the removal, please see https://bugs.debian.org/809502
The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].
Debian distribution maintenance software
pp.
Luca Falavigna (the ftpmaster behind the curtain)
--- End Message ---
