Bug#571771: Couldn't configure pre-depend ... probably a dependency cycle
On Sun, Mar 07, 2010 at 11:00:45PM +0100, Rene Engelhard wrote: And dist-upgrade (or full-upgrade I think is what aptitude calls it)? apt-get dist-upgrade, aptitude dist-upgrade and aptitude full-upgrade all give the same error as safe-upgrade. Who said that safe-upgrade will work in all dependency cases? apt-get dist-upgrade and aptitude dist-upgrade also want to do crazy things from time to time... IMHO giving an explicit list of packages to apt-get install is still the most reliable way to upgrade, but this is getting off topic. Gabor -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551158: Libc6: exim4 Segfault in libc-2.7.so
Hi, On Tue, Oct 27, 2009 at 06:21:24AM +0100, Fabio Rosciano wrote: thanks for helping out. Here it is, I can't see anything funny: [...] Yes, the logs are pretty much the same as when I did the upgrade, except I did not have libc6-dev-i386 installed and I went to 2.10.1-1 from 2.9-27. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551158: Libc6: exim4 Segfault in libc-2.7.so
On Mon, Oct 26, 2009 at 09:02:22AM +0100, Fabio Rosciano wrote: On Mon, 2009-10-26 at 08:10 +0100, Aurelien Jarno wrote: Do you have the list of packages that have been upgraded? I wish I did, but as soon as debconf asked would you like to upgrade libc6 now? and I answered yes, the system became completely unusable. Do you have /var/log/dpkg.log? Even if it does not contain the action that failed first, the lines before the failure may show if packages were being installed in an unexpected order. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551831: cupt: Incorrectly upgrades libc6, breaking the system
On Wed, Oct 21, 2009 at 12:01:51PM +0300, Eugene V. Lyubimkin wrote: However, this is another side of already archived http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543365 (ironically, reported by you too). On i386 we have the issue: libc6-i686 strictly Pre-Depends on libc6 (= ...), and whatever package from this two cupt tries to upgrade first, the pre-dependency will be broken. Let me try to add libc maintainers to the loop to know the correct upgrade path. Hmm. remove old libc6-i686, upgrade libc6, install new libc6-i686 seems to be a sequence where the Pre-Depends never breaks. Since libc6-i686 is not needed for the system to function properly, removing it temporarily is not a problem. Now the question is can it be generalized to other packages? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499825: DISTRO check is unneccessary
Hi! Reading the bug report, the $DISTRO check seems bogus. - It depends on a conffile that is not part of the package. There is _no_ guarantee that /etc/issue contains any string related to the distribution. - Why not just simply check for the presence of /lib/modules/$(uname -r)/kernel/ubuntu/acpi? If the directory is present on a Debian system, then it is very likely meant to be _used_. Nothing prevents the admin to install an Ubuntu kernel on an otherwise Debian box. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483397: iceweasel: latest xulrunner update leaves iceweasel broken
On Thu, May 29, 2008 at 12:48:50AM -0400, Eric Dorland wrote: * Gábor Gombás ([EMAIL PROTECTED]) wrote: Package: iceweasel Version: 3.0~b5-4 Severity: grave Justification: renders package unusable Hi, After upgrading xulrunner-1.9 I get the following when I want to run iceweasel: $ iceweasel Error: Platform version '1.9' is not compatible with minVersion = 1.9b5 maxVersion = 1.9b5 Did you upgrade to iceweasel 3.0rc1? No, as it is not in the archive: # apt-get update [...] # apt-cache policy iceweasel iceweasel: Installed: 3.0~b5-4 Candidate: 3.0~b5-4 Version table: *** 3.0~b5-4 0 101 http://ftp.hu.debian.org experimental/main Packages 101 http://ftp.fi.debian.org experimental/main Packages 100 /var/lib/dpkg/status 2.0.0.14-2 0 500 http://ftp.hu.debian.org lenny/main Packages 990 http://ftp.hu.debian.org unstable/main Packages 990 http://ftp.fi.debian.org unstable/main Packages 2.0.0.12-0etch1 0 500 http://ftp.hu.debian.org etch/main Packages Anyway, if iceweasel depends on the exact xulrunner version and not just anything recent enough, shouldn't that be reflected in the package dependencies? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474294: RFH: Chrony goes into endless loop on x86_64
On Thu, Apr 24, 2008 at 02:21:39PM -0500, John Hasler wrote:
Gabor writes:
That will be difficult since sometimes the bug does not hit for weeks and
then suddenly chrony starts to loop all the time.
Are you saying that you have seen the bug?
Yes, see bug #447011. In fact, #474294 is a duplicate of #447011...
So I'd say go ahead and upload the new version to unstable, and if there
are no new occurances of the bug for 1-2 months then you can close it.
Which would probably result in Chrony being removed from Lenny.
Well, then someone should start debugging it. The gdb trace sent by
Goshwin is quite promising. If UTI_NormaliseTimeval() is called with
x-tv_usec being a very large value (say LONG_MAX), that would clearly
explain the hang, and it would also explain why i386 does not seem to be
affected even if it is just as buggy as amd64: on i386, the while {}
loops execute at most 2147 times which is basically unnoticable, while
on amd64 that can be 2^32 times more.
So, IMHO turning the two while {} loops in UTI_NormaliseTimeval() into
divide/remainder operations should fix the hang. However, it still needs
investigation _why_ UTI_NormaliseTimeval() is being called with such a
bad time value, as it may be a result of a more severe bug like memory
corruption. Maybe upstream could help here.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
Laboratory of Parallel and Distributed Systems
Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary
Phone/Fax : +36 1 329-78-64 (secretary)
W3: http://www.lpds.sztaki.hu
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459762: sasl2-bin: postinst hangs
Hi, On Wed, Jan 09, 2008 at 09:41:57AM +0200, Fabian Fagerholm wrote: Something seems to go wrong with the debconf stuff. Did you get any debconf prompts when upgrading the package? Yes, about where to back up sasldb. I can't seem to figure out why it would hang, though. Could you send the output of sasldblistusers2 | wc -l. 0 Shell: /bin/sh linked to /bin/dash This is of course worth noting. Could you try running the postinst script by hand (/var/lib/dpkg/info/sasl2-bin.postinst) as root and see what happens? Better yet, set DEBCONF_DEBUG to developer before running the postinst script. Back up your /etc/sasldb2 first; other than that, it should be completely safe. # /var/lib/dpkg/info/sasl2-bin.postinst configure debconf (developer): frontend started debconf (developer): frontend running, package name is sasl2-bin debconf (developer): starting /var/lib/dpkg/info/sasl2-bin.config configure debconf (developer): -- RESET cyrus-sasl2/backup-sasldb2 debconf (developer): -- 0 debconf (developer): -- INPUT medium cyrus-sasl2/backup-sasldb2 debconf (developer): -- 0 question will be asked debconf (developer): -- GO Configuring sasl2-bin - Cyrus SASL has stored usernames and passwords in the /etc/sasldb2 database file. That file has to be upgraded to a newer database format. First, a backup of the current file will be created. You can use that if you need to manually downgrade Cyrus SASL. However, automatic downgrades are not supported. Please specify the backup file name. You should check the available disk space in that location. If the backup file already exists, it will be overwritten. Leaving this field empty will select the default value (/var/backups/sasldb2.bak). Backup file name for /etc/sasldb2: /var/backups/sasldb2.bak debconf (developer): -- 0 ok debconf (developer): -- GET cyrus-sasl2/backup-sasldb2 debconf (developer): -- 0 /var/backups/sasldb2.bak debconf (developer): starting /var/lib/dpkg/info/sasl2-bin.postinst configure Starting SASL Authentication Daemon: saslauthd. [... hangs here ...] From lsof output it seems saslauthd inherits the debconf pipe and does not close it, therefore the frontend does not notice that the postinst script has finished. This seems to help: --- sasl2-bin.postinst.orig 2008-01-09 10:35:27.0 +0100 +++ sasl2-bin.postinst 2008-01-09 10:35:37.0 +0100 @@ -63,6 +63,8 @@ if ! dpkg-statoverride --list $SASLDB_FILE /dev/null 21; then dpkg-statoverride --update --add root sasl 660 $SASLDB_FILE fi + + db_stop ;; abort-upgrade|abort-remove|abort-deconfigure) Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456520: mozilla-venkman: Insecure /tmp usage
Package: mozilla-venkman Version: 0.9.87.2-1 Severity: critical Tags: security Justification: root security hole Hi, mozilla-venkman.preinst contains: #! /bin/sh find . -maxdepth 1 -mindepth 1 /tmp/fin Just do an ln -s /etc/shadow /bin/fin as any user before installing the package, and watch the fireworks. Btw. why the heck does the preinst script need to dump the contents of the root directory to a file that is never used? Gabor -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22.6 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mozilla-venkman depends on: ii iceweasel 2.0.0.11-1 lightweight web browser based on M mozilla-venkman recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445861: HAL daemon exited with return code 1
Hi, This bug seems to take an annoyingly long time to fix, so I tried to run hald --daemon=no --verbose=yes under valgrind and I got: ==9630== Invalid read of size 1 ==9630==at 0x4A07AC4: strcmp (mc_replace_strmem.c:341) ==9630==by 0x4C2E68D: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C2E955: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C2E350: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C2E578: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C35D5D: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C35E22: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C3608C: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C1498D: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C13B7A: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C13D9B: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C13325: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C2B92E: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C2C80E: (within /usr/lib/libdbus-1.so.3.4.0) ==9630==by 0x4C2D0AA: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== Address 0x4F0D228 is 0 bytes inside a block of size 5 free'd ==9630==at 0x4A0682B: free (vg_replace_malloc.c:233) I don't know if this is _the_ reason why hald quits but at least it is clearly a use-after-free bug and it should be easy to catch if someone recompiles hal libdbus with full debug info and runs hald under valgrind again - I don't have the time right now. iF hal0.5.10-3 Hardware Abstraction Layer ii libdbus-1-31.1.2-1 simple interprocess messaging system Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437838: cyrus-imapd-2.3: Daemons/tools die due to Berkeley DB version mismatch
On Thu, Aug 23, 2007 at 09:34:27AM +0200, Ondřej Surý wrote: So package gets compiled against lidb4.5-dev headers and -ldb-4.4 libraries. Yes, I also realized that I got the versioning wrong (I somehow thought it linked to a version higher than the -dev package, but of course the opposite is still possible for exactly the same reason). It will be fixed in 2.3.9-1 release. Thanks. Be careful that 2.3.9 already seems to check for BDB 4.6 too. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu -
Bug#437838: cyrus-imapd-2.3: Daemons/tools die due to Berkeley DB version mismatch
On Tue, Aug 21, 2007 at 10:25:58PM +0200, Ondřej Surý wrote: So question is where did you get that source code which you sent patch for? Oh, the patch is from the set I used for Cyrus builds at some other place; actually it's against a post-2.3.8 CVS version. I forget to check the sources of the Debian package. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu -
Bug#437838: cyrus-imapd-2.3: Daemons/tools die due to Berkeley DB version mismatch
On Sun, Aug 19, 2007 at 08:07:39PM +0200, Ondřej Surý wrote: Correct fix would be to find why it didn't find libdb4.4. The reason is in the comment of the proposed patch. Every libdbX.Y Debian package installs the library as /usr/lib/libdb-X.Y.so, because that's the SONAME of the Berkeley DB 4.x libraries. The libdbX.Y-dev package however installs the /usr/lib/libdb.so symlink that points to the DB version the -dev package belongs to. That means you _can_ link to any BDB version if you use an explicit DB name (like the Cyrus configure script does) even when the -dev package is not present or if the -dev package belongs to a different library version. So, if you happen to have _any_ libdbX.Y package installed that has a version higher than the -dev package (example: you have all libdb4.4, libdb4.4-dev, and libdb4.5 installed) then the Cyrus configuration snippet will find the highest library version (4.5 in this case, since the linker will find the /usr/lib/libdb-4.5.so library), and not the version of the -dev package. And that will cause the version mismatch. The reason why this problem do not occur with other packages is that almost every other library (including the 3.x series of BDB) uses a SONAME of the form libfoo.so.X.Y.Z, i.e. the SONAME does not end in .so. Could you supply more information about your build environment? Include at least list of libdb*-dev packages installed. I used the Debian-provided packages, so you should check the experimental buildds. I know nothing about them. However I noticed this problem during personal builds long before there was a Debian package available. Just install both libdb4.4-dev and libdb4.5 and see what happens. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu -
Bug#437838: cyrus-imapd-2.3: Daemons/tools die due to Berkeley DB version mismatch
On Tue, Aug 21, 2007 at 01:55:56PM +0200, Ondřej Surý wrote: Now I see. You're right. But where did db-4.5 come from? 2.3.8-1 source from experimental doesn't have it, 2.3.8-1 source from subversion doesn't have it. Is this your local modification? I have no idea. Maybe some other unrelated software on the buildd needed it. I've done no local modifications, I've installed the official packages: apt-cache policy cyrus-imapd-2.3 cyrus-imapd-2.3: Installed: 2.3.8-1 Candidate: 2.3.8-1 Version table: *** 2.3.8-1 0 101 http://ftp.hu.debian.org experimental/main Packages 101 http://ftp.fi.debian.org experimental/main Packages 100 /home/gombasg/tmp/debian/x86_64/status Correct fix is either fix berkdb.m4 macro to use information from /usr/include/db.h (DB_VERSION_MAJOR and DB_VERSION_MINOR) or just by using: Build-Conflict: libdb4.5 Build-Depends: libdb4.4-dev Which of course needs to be modified each time new libdb4.x is released. libdb4.6 is already in the archive but Cyrus 2.3.9 does not yet test for it. I think adding some way to configure to explicitely ask for the BDB version to use would be the best solution. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu -
Bug#437838: cyrus-imapd-2.3: Daemons/tools die due to Berkeley DB version mismatch
Package: cyrus-imapd-2.3 Version: 2.3.8-1 Severity: grave Tags: patch Justification: renders package unusable Hi, On AMD64, all daemons and database tools die complaining that they were compiled against db-4.4 headers but were linked against db-4.5. For local Cyrus builds I have used the following patch (autoreconf is needed after applying): --- cmulocal/berkdb.m4.orig 2007-02-13 16:44:00.0 +0100 +++ cmulocal/berkdb.m4 2007-08-14 14:53:42.0 +0200 @@ -213,7 +213,8 @@ fi saved_LIBS=$LIBS -for dbname in db-4.5 db4.5 db45 db-4.4 db4.4 db44 db-4.3 db4.3 db43 db-4.2 db4.2 db42 db-4.1 db4.1 db41 db-4.0 db4.0 db-4 db40 db4 db-3.3 db3.3 db33 db-3.2 db3.2 db32 db-3.1 db3.1 db31 db-3 db30 db3 db + # On Debian, /usr/lib/libdb.so points to the version corresponding to the -dev package, so test that first +for dbname in db db-4.5 db4.5 db45 db-4.4 db4.4 db44 db-4.3 db4.3 db43 db-4.2 db4.2 db42 db-4.1 db4.1 db41 db-4.0 db4.0 db-4 db40 db4 db-3.3 db3.3 db33 db-3.2 db3.2 db32 db-3.1 db3.1 db31 db-3 db30 db3 do LIBS=$saved_LIBS -l$dbname AC_TRY_LINK([#include db.h], Gabor -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22.1 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434374: libsuitesparse: depends on non-free libparmetis3.1
Package: libsuitesparse Version: 3.0.0-4 Severity: serious Justification: Policy 2.2.1 $ apt-cache show libsuitesparse [...] Depends: [...], libparmetis3.1 [...] $ apt-cache show libparmetis3.1 [...] Section: non-free/libs [...] Gabor -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21.5 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libsuitesparse depends on: ii lapack3 [liblapack.so.3] 3.0.2531a-6 library of linear algebra routines ii libc62.6-2 GNU C Library: Shared libraries ii libparmetis3.1 3.1-7 Parallel Graph Partitioning and Sp ii refblas3 [libblas.so.3] 1.2-8 Basic Linear Algebra Subroutines 3 libsuitesparse recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378303: linux-kernel-headers: bitmap.h: 'BITS_PER_LONG' undeclared
On Sat, Jul 15, 2006 at 08:42:56AM +0200, Julien Danjou wrote: In file included from /usr/include/linux/cpumask.h:86, from /usr/include/asm-i486/processor.h:23, from /usr/include/asm/processor.h:8, from /usr/include/asm-i486/atomic.h:6, from /usr/include/asm/atomic.h:8, from swapon02.c:87: Anything that includes atomic.h from user space is fundamentally broken. The definitions in atomic.h are _NOT_ atomic on many architectures when used in user space (if they compile at all). Fix ltp. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Bug#349674: unison: causes data loss if one of the replicas disappears
On Tue, Jan 24, 2006 at 09:44:59PM +0100, Sylvain Le Gall wrote: Was it during the synchronisation phase (when effectively doing operation) or before (when calculating changes) ? I don't really know, I was not sitting in front of the machine during the synchronization. I only realized the end result. I think, it is the first case, and in this case, i agree : it a real problem. I think not noticing that the whole filesystem has changed is a problem in any phase. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349674: unison: causes data loss if one of the replicas disappears
Package: unison Version: 2.13.16-4 Severity: critical Justification: causes serious data loss Hi, I'm regularly replicating my home directory to an USB harddisk using unison. This morning the USB drive got disconnected during the synchronization (hw error). Instead of noticing that one of the replica roots have completely disappeared and aborting, unison started to delete large amounts of data from my home directory. Luckily I could restore most of it, but this behaviour makes unison unsuitable as a serious synchronization tool. Possible solution: unison should do a stat() on the replica roots before delete operations and if the st_dev field changes (i.e. the file system containing the replica is unmounted or is over-mounted) it should abort the synchronization. This is not a complete solution as it does not protect from e.g. bind mounts, but it would at least cover the removable device fails causing the mount to go away case. Gabor -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages unison depends on: ii libc6 2.3.5-12 GNU C Library: Shared libraries an Versions of packages unison recommends: ii openssh-client [ssh-client] 1:4.2p1-5 Secure shell client, an rlogin/rsh -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
