Bug#817821: fuse4bsd: Claims to provide fusermount, but doesn't

Package: fuse4bsd Severity: normal Hello, The package description claims: Description: Filesystem in USErspace (utilities) Simple interface for userspace programs to export a virtual filesystem to kFreeBSD. . This package contains the fusermount utility which is necessary to mount fuse

fusermount

Hello, The fuse4bsd package description claims: Description: Filesystem in USErspace (utilities) Simple interface for userspace programs to export a virtual filesystem to kFreeBSD. . This package contains the fusermount utility which is necessary to mount fuse filesystems. But then: $

Re: Replacement for setxattr on kFreeBSD?

On Mar 04 2016, Cyril Brulebois <k...@debian.org> wrote: > Nikolaus Rath <nikol...@rath.org> (2016-03-03): >> On Mar 02 2016, Steven Chamberlain <ste...@pyro.eu.org> wrote: >> >> [...] Can you tell me how to detect >> >> GNU/kFreeBSD f

Re: Replacement for setxattr on kFreeBSD?

On Mar 02 2016, Steven Chamberlain wrote: >> [...] Can you tell me how to detect >> GNU/kFreeBSD from Python? sys.platform and os.uname are potential >> candidates, but the Python docs unfortunately don't mention what the >> values of those variables are for GNU/kFreeBSD (and

Re: Replacement for setxattr on kFreeBSD?

On Mar 01 2016, Steven Chamberlain <ste...@pyro.eu.org> wrote: > Nikolaus Rath wrote: >> I noticed that the kfreeBSD build of python-llfuse is failing because of >> >> build/temp.gnukfreebsd-10.1-0-amd64-x86_64-3.5/src/llfuse.o: In function >> `getxattr_p': >&

Replacement for setxattr on kFreeBSD?

Hello kFreeBSD people, I noticed that the kfreeBSD build of python-llfuse is failing because of build/temp.gnukfreebsd-10.1-0-amd64-x86_64-3.5/src/llfuse.o: In function `getxattr_p': /«BUILDDIR»/python-llfuse-0.43+dfsg/src/xattr.h:38: warning: getxattr is not implemented and will always fail

Re: Bug#815328: python-llfuse: FTBFS on kfreebsd: unsatisfiable B-D: fuse

On Feb 22 2016, Steven Chamberlain <ste...@pyro.eu.org> wrote: > Nikolaus Rath wrote: >> Ah, ok. I guess it gives non-zero exact status if it doesn't find any >> tests to run at all. >> >> So the next question is why is it finding only one test, a

Re: Bug#815328: python-llfuse: FTBFS on kfreebsd: unsatisfiable B-D: fuse

> $ py.test-3 -s test/ ; echo exit status $? > == test session starts > === > platform gnukfreebsd10 -- Python 3.4.4rc1, pytest-2.8.5, py-1.4.31, > pluggy-0.3.1 -- /usr/bin/python3 > cachedir: test/.cache >

Re: [kfreebsd] massive report for uninstallable FUSE packages

On 07/17/2011 12:43 PM, Robert Millan wrote: I think I'll patch S3QL to fall back on umount if fusermount is not available and depend on fuse | fuse4bsd. This should work fine, because then if the user was able to mount the file system on BSD he must have been root, and using umount instead of

Re: mode_t bitwise operations different under kFreeBSD?

On 07/16/2011 02:45 PM, Petr Salinger wrote: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -O2 -fPIC -g -I/usr/include/python2.7 -c src/llfuse.c -o build/temp.gnukfreebsd-8.1-1-686-smp-i686-2.7/src/llfuse.o -D_FILE_OFFSET_BITS=64 -I/usr/include/fuse

Re: [kfreebsd] massive report for uninstallable FUSE packages

On 07/16/2011 03:29 PM, Robert Millan wrote: 2011/7/16 Nikolaus Rath nikol...@rath.org: I'm maintaining the s3ql package and it uses the fusermount command. I am not sure what you mean with a FUSE daemon...? Presence of init.d script led me to think there was a daemon, but now I notice

Re: mode_t bitwise operations different under kFreeBSD?

Petr Salinger petr.salin...@seznam.cz writes: It is roughly equal to this: void foo(unsigned short int a) { a = (( a (~0x1F)) | 0x10); } It seems to me that the S_* constants should have the same type as mode_t, so it's not quite the same... The ~S_IFMT is not a constant. See

Re: [kfreebsd] massive report for uninstallable FUSE packages

On 07/16/2011 07:32 PM, Robert Millan wrote: 2011/7/17 Nikolaus Rath nikol...@rath.org: Robert Millan r...@debian.org writes: Else if %package% depends on fuse-utils because it can't work at all without fusermount, please reply to this bug report so we can try to find a solution. The s3ql