Bug#942435: fuse: /bin/fusermount3 & /sbin/mount.fuse3 do not exist

2019-10-16 Thread Michael Livshin
Package: fuse
Version: 2.9.9-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Not sure, probably a routine upgrade.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Tried to mount an SMB share from Nautilus.

   * What was the outcome of this action?

No filesystem-level mount was created under /run/user//gvfs/.

Running gvfs with debug prints shows that it tried to spawn "fusermount3" (by
way of libfuse), but failed to do so.

Creating a symlink with that name (pointing at "/bin/fusermount") worked around
the problem for me.

   * What outcome did you expect instead?

I expect a filesystem-level mount.  Most media players (for example) balk at
"smb://..." urls as arguments (which Nautilus resorts to feeding them when it
fails to mount properly with gvfs-fuse), and really want a local-looking path
instead.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-updates'), (500, 'stable'), (300, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fuse depends on:
ii  adduser   3.118
ii  libc6 2.29-2
ii  libfuse2  2.9.9-2
ii  mount 2.34-0.1
ii  sed   4.7-1

fuse recommends no packages.

fuse suggests no packages.

-- no debconf information



Bug#522858: The upstream version works fine

2009-07-09 Thread Michael Livshin

Guys.

You may seriously want to reconsider the debian patch to src/list.c.

What it does, basically, is make tar exit when it encounters a zero block
and no -i flag is given, without exhausting the input.

The without exhausting the input part is important when the input is
piped from a decompressor, because it means that the gunzip (or bunzip2,
or whatever) child of tar gets a SIGPIPE, and beginning with 1.22 tar
actually bothers to notice the fact and bombs out too.

Bottom line: this patch has always been wrong, but its effect is only 
visible

beginning with the 1.22 upstream version.

Cheers,
--m



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org