Debian package

[GoogleCodeExporter]

Reference: http://www.debian.org/doc/maint-guide/

As s3fs is getting its loose ends tied up, it's getting mature enough to go 
"mainstream" with a Debian package.

Original issue reported on code.google.com by dmoore4...@gmail.com on 29 Oct 2010 at 4:04

[GoogleCodeExporter]

Filed Intent To Package (ITP) bug with Debian

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601789

Original comment by dmoore4...@gmail.com on 29 Oct 2010 at 5:42

[GoogleCodeExporter]

Make sure that new package is dependent upon the fuse-utils package. This 
(reportedly) is needed for mounting through /etc/fstab to work.

Original comment by dmoore4...@gmail.com on 5 Nov 2010 at 4:26

[GoogleCodeExporter]

Include "mime-support" package in the dependency list. Needed for the 
/etc/mime.types file

Original comment by dmoore4...@gmail.com on 5 Nov 2010 at 5:47

[GoogleCodeExporter]

Hi

I gave a stab at packaging s3fs; I'm attaching the packaging.  Unfortunately, I 
hit a major issue preventing redistribution:

E: s3fs: possible-gpl-code-linked-with-openssl
N:
N:   This package appears to be covered by the GNU GPL but depends on the
N:   OpenSSL libssl package and does not mention a license exemption or
N:   exception for OpenSSL in its copyright file. The GPL (including
N:   version 3) is incompatible with some terms of the OpenSSL license, and
N:   therefore Debian does not allow GPL-licensed code linked with OpenSSL
N:   libraries unless there is a license exception explicitly permitting
N:   this.
N:   
N:   If only the Debian packaging, or some other part of the package not
N:   linked with OpenSSL, is covered by the GNU GPL, please add a lintian
N:   override for this tag. Lintian currently has no good way of
N:   distinguishing between that case and problematic packages.
N:   
N:   Severity: serious, Certainty: wild-guess
N:

Indeed, s3fs is GPL and links to openssl.

I could build s3fs successfully against both the openssl and the gnutls version 
of libcurl in Debian/Ubuntu but I could not build it against libgnutls instead 
of openssl: src/s3fs.h includes openssl headers and s3fs.cpp uses openssl 
CRYPTO_LOCK and others.

Would you consider gnutls' libgcrypto instead?

I believe the packaging is otherwise complete; I had to disable the testsuite 
as it relies on credential in $HOME, so not suitable for a buildd.

Thanks,

Original comment by loic.min...@gmail.com on 3 Mar 2011 at 3:23

Attachments:

• s3fs_1.40-1.debian.tar.gz

[GoogleCodeExporter]

Unless anyone else objects, I'd be happy to give gnutls a shot. I'll see what I 
can come up with tomorrow. I'd love to have a debian package!

Thanks!

Original comment by ben.lema...@gmail.com on 3 Mar 2011 at 5:55

[GoogleCodeExporter]

whew, openssl reaches quite a few places in s3fs. gnutls appears to have a 
compatibility layer 
(http://www.gnu.org/software/gnutls/manual/html_node/Compatibility-with-the-Open
SSL-library.html). i'll keep poking around though, i'm not familiar with either 
library. If anyone is feel free to jump in :)

Original comment by ben.lema...@gmail.com on 3 Mar 2011 at 5:22

[GoogleCodeExporter]

Shouldn't this only affect url=https:... ?  Is there a one-to-one 
correspondence with the openssl lib calls and the gnutls lib calls?  Are you 
running into compile time issues? ...or execution time issues?  

Admittedly, I'm mostly uneducated in this stuff, but just throwing a few 
thoughts out there.

Original comment by moore...@gmail.com on 4 Mar 2011 at 6:22

[GoogleCodeExporter]

Thanks for the packaging!
It seems that these files to be added to debian/docs file
(so the will be automatically placed to /usr/share/doc/...)
===========
AUTHORS
COPYING
ChangeLog
INSTALL
NEWS
README
===========

Original comment by dmi.cher...@gmail.com on 6 May 2011 at 11:16

[GoogleCodeExporter]

INSTALL is obviously not needed; COPYING isn't needed as all the information is 
wrapped in debian/copyright which gets installed there; AUTHORS is of dubious 
value to end-users on their installed systems; NEWS is empty; ChangeLog is 
relatively limited and distros like Ubuntu strip ChangeLogs away to save space 
anyway.

Yep, README would be useful

Original comment by loic.min...@gmail.com on 10 May 2011 at 10:35

[GoogleCodeExporter]

Is the openssl issue solved already? I'd like to build a package for debian 
too. I already uploaded a package to http://mentors.debian.net/package/s3fs, 
but because this is my first debian package, I'm not quite sure if everything 
is ok. And I read that mentors only accepts source packages, and I think mine 
is a binary package.

Anyway, I'like s3fs and I want to help debian provide a packaged version for 
it. :-)

Original comment by carsten....@gmail.com on 11 Aug 2011 at 3:25

[GoogleCodeExporter]

OpenSSL issue has not been solved, it may not be any time soon. Admittedly, I'm 
not very aware of the finer details when it comes to packaging w/ the SSLeay 
license. Does it just exclude the package from eligibility in the Debian 
upstream?

Original comment by ben.lema...@gmail.com on 11 Aug 2011 at 3:34

[GoogleCodeExporter]

I'm not sure if this is still an issue. I was able to build a package with 
libcurl4-gnutls-dev installed, instead of libcurl4-openssl-dev.

I read that the BSD license of openssl doesn't match with Debians preference 
for GPL. but is that still an issue if I can build the whole thing without 
openssl?

Maybe I should get a mentor who'll help me build this package and get me 
through this issues...

Original comment by carsten....@gmail.com on 11 Aug 2011 at 4:12

[GoogleCodeExporter]

IANAL, but the quick overview: 

Debian's issue is not that it has a preference for the GPL. The problem is that 
the advertising/acknowledgement clause of openssl is probably incompatible with 
GPL v2 (I don't know about GPLv3)

Debian chooses to error on the side of not linking GPL code to BSD code that 
includes the advertising/acknowledgement clause of it's license.

An exception to the sixth clause of the GPL (no additional encumbrances) can to 
be added by the s3fs developers to permit redistribution of binaries linked to 
openssl. 

All the developers of s3fs would have to agree to the exception to the GPL.

Original comment by m...@micheas.net on 23 Jan 2012 at 11:25

[GoogleCodeExporter]

A good way to deal with the issue is to allow linking against GnuTLS instead of 
OpenSSL

Original comment by loic.min...@gmail.com on 8 Feb 2012 at 3:45

[GoogleCodeExporter]

Has there been any movement on this? With debian-cloud now producing AMIs, it'd 
be nice to be able to use S3FS.

Original comment by christop...@ergonlogic.com on 31 Jul 2013 at 9:37

[GoogleCodeExporter]

According to this document https://people.gnome.org/~markmc/openssl-and-the-gpl 
there's a way link against openssl and distribute packaged version of s3fs. 
This requires copyright holders together should agree to add the text mentioned 
in the document. The details of how this should be fixed can be found in this 
email: http://lists.debian.org/debian-legal/2004/05/msg00595.html

If above conditions suit you, I can build and add s3fs packages to the Debian 
archive.

Original comment by andriyse...@gmail.com on 3 Dec 2013 at 2:45

[GoogleCodeExporter]

Hi, all

Thanks a lot.

If you can, please let me know about below case.
If s3fs was modified to be able to use NSS(or GnuTLS) instead of OpenSSL by 
"#ifdef", still do we need to add license header in comment in all sources?

I would add codes for this problem, thereby s3fs can be build with one of 
NSS/GnuTLS/OpenSSL.
Becase s3fs should be able to use the library same as libcurl used.

Thanks in advance for your help.

Original comment by ggta...@gmail.com on 4 Dec 2013 at 2:31

[GoogleCodeExporter]

Let's consider wget as an example of GPL software that can be linked against 
both OpenSSL and GnuTLS. Debian distributes only version linked with GnuTLS 
that makes possible to distribute it under the terms of GPL alone. However, it 
is the source code that _can_ be compiled and linked together with OpenSSL, so 
all source files in wget project contain a license block that permits linking 
against OpenSSL.

If you wish to leave the possibility for s3fs to be compiled linked OpenSSL, 
you should add menioned paragraph to the license and your project files (having 
a small copyright and license excerpt at the top of the file is a rule of thumb 
anyway).

As for libcurl, it is licensed under a 3-clause BSD license that allows it to 
be linked against both OpenSSL and GnuTLS (LGPL v2.1+). If you could use 
libcurl alone (i.e without direct linking againt openssl/gnutls) this could 
resolve the issue as well.

Original comment by andriyse...@gmail.com on 4 Dec 2013 at 11:29

[GoogleCodeExporter]

Hi, andriysenkovych

(I’m sorry about replying for this issue too late)

Today I made new branch as “cryptlibs” on 
Github(https://github.com/s3fs-fuse/s3fs-fuse) for this issue.
(Our s3fs project have moved on github last Dec because googlecodes did not 
support download archive.)

The “cryptlibs” branch supports another crypt libraries as GnuTLS and NSS, 
and supports OpenSSL yet.
New branch has some new sources which are separated by each crypt libraries.
And configure(.ac) for autoconf appends following four option.
  --enable-openssl-lib    s3fs build with OpenSSL(default is no)
  --enable-nss-lib        s3fs build with NSS(default is no)
  --enable-gnutls-lib     s3fs build with GnuTLS(default is no)
  --enable-nettle-lib     s3fs build with nettle in GnuTLS(default no)

You can understand first three option, for building s3fs with openssl, nss, 
gnutls.
But gnutls and nettle options are complicated.
If you specify only enable-gnutls-lib, it means compiling with GnuTLS + gcrypt.
If you want to compile with GnuTLS + Nettle, you need to specify both 
enable-gnutls-lib and enable-nettle-lib option.

Then, after you run configure script except openssl, you can see src/Makefile.
It does not link openssl_auth.cpp object which file have all codes for calling 
openssl api.
Thus s3fs which make without openssl option does not have any codes which calls 
openssl api.
(You can remove openssl_auth.cpp in source codes before building s3fs)

Because s3fs with NSS(or GnuTLS) binary does not have(and call) any openssl 
libraries codes, in this case I think that we can exclude it from a license of 
OpenSSL.
And I think that we can make debian package(gnutls or nss) without changing a 
license of s3fs.

Do you think about this and new branch?
Please let me know about your opinion.

Thanks in advance for your help.

Original comment by ggta...@gmail.com on 6 May 2014 at 3:28

[GoogleCodeExporter]

Hi, all

I updated master branch of s3fs on Github today.
This change is s3fs supports three SSL library(OpenSSL, NSS, GnuTLS).

* And changed configuration options(--with-openssl, --with-nss, --with-gnutls, 
--with-nettle) since before.

Thanks,

Original comment by ggta...@gmail.com on 1 Jun 2014 at 3:19

[GoogleCodeExporter]

Hi. It seems project has been moving to github, so I have answered there:

  https://github.com/s3fs-fuse/s3fs-fuse/issues/29#issuecomment-50949313

Original comment by andriyse...@gmail.com on 3 Aug 2014 at 9:44

[GoogleCodeExporter]

I'm going to close this issue because this issue moved on Github.
Regards,

Original comment by ggta...@gmail.com on 7 Feb 2015 at 3:24

• Changed state: Done