Re: [ITP] FUSE 2.8

2016-07-17 Thread Marco Atzeri



On 17/07/2016 03:02, Bill Zissimopoulos wrote:

This package adds FUSE 2.8 support to Cygwin. FUSE is the well-known
"Filesystem in Userspace" project for Linux and other platforms: [FUSE].

FUSE file systems that use this package usually require minimal changes to
run on Cygwin. For example, here are the pull requests I have submitted to
SSHFS and FUSEPY to make them run on Cygwin: [SSHFS-PR], [FUSEPY-PR].

FUSE file systems that use this package will expose a file system not just
to Cygwin, but to ALL of Windows (i.e. Explorer, cmd.exe and all of
Windows apps will be able to access their files). For this to work the
cygfuse.dll in the package needs to interface with a kernel mode
component, which does NOT ship as part of this package.

Which brings me to a large caveat with this package. The package has an
external dependency on my own open source project called WinFsp [WINFSP].
WinFsp includes the necessary kernel-mode driver that enables the
FUSE-like functionality on Windows. Unfortunately this driver can only be
built with Microsoft tools. Furthermore it must be signed with an EV
certificate (and going forward Microsoft will soon require that they sign
every kernel mode driver themselves through the sysdev portal).

For this reason you cannot simply get the source code for the FUSE cygport
and WinFsp and compile everything from scratch. This is not a licensing
issue (all code is AGPLv3), but a tools/signing issue. The alternatives
are:

1. Accept the FUSE cygport package as is. Understand that it requires
prior installation of WinFsp in order to properly work.


libusb0 has similar requirements

Extract from the setup.ini
---
message: libusb0 "In order to use libusb0, you must download and run the
LibUSB-Win32 driver installer from:
https://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/libusb-win32-devel-filter-1.2.6.0.exe";
-

similar  mDNSResponder and avahi.


2. Accept the FUSE cygport package, but require that the package downloads
and installs the WinFsp MSI (perhaps as part of its post install process).


That will be complicated, I prefer #1



3. Reject this package.

I have currently implemented option (1) but I am happy to change to option
(2). The package files can be found at [CYGFUSE]. The source code for the
package can be found under the opt/cygfuse directory in this repository:
[WINFSP-GH]


pkill sshfs

Comments greatly appreciated.

Bill


Regards
Marco



Re: how to manage 2 guile version

2016-07-17 Thread Marco Atzeri



On 14/07/2016 23:29, Yaakov Selkowitz wrote:

On 2016-07-14 15:13, Marco Atzeri wrote:

I was thinking to pack the last guile-2.0.x
however this will require the repack of 1.8.8
version.


Yes, that would be a good idea at this point.


No problem for the headers as they are
properly isolated

/usr/include/guile/1.8/libguile/__scm.h
/usr/include/guile/1.8/libguile.h

but what to do of
/usr/lib/libguile.dll.a


Leave it; the new version is named libguile-2.0.dll.a.


Other suggestion/preference ?


https://github.com/cygwinports/guile
https://github.com/cygwinports/guile1.8

(Those haven't been updated in a while, so they may need version/release
bumps.)



thanks

2.0.12 build fine, I need just to look on some test failures

00-socket.test  seems to cause a segfault.

Regards
Marco


Re: [ITP] FUSE 2.8

2016-07-17 Thread David Stacey

On 17/07/16 02:02, Bill Zissimopoulos wrote:

The package has an
external dependency on my own open source project called WinFsp [WINFSP].
WinFsp includes the necessary kernel-mode driver that enables the
FUSE-like functionality on Windows. Unfortunately this driver can only be
built with Microsoft tools. Furthermore it must be signed with an EV
certificate (and going forward Microsoft will soon require that they sign
every kernel mode driver themselves through the sysdev portal).

For this reason you cannot simply get the source code for the FUSE cygport
and WinFsp and compile everything from scratch. This is not a licensing
issue (all code is AGPLv3), but a tools/signing issue.



IIRC, there is already precedent for this sort of thing in the Linux 
world, as boot loaders need to be signed to work with UFEI Secure Boot - 
see [1].


Dave.

[1] - https://fedoraproject.org/wiki/Secureboot