[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: liboauth (Updated package)



Robin,
Thanks for solving all those issues.
Looks like its all set to package. This is where I come in. I will get
the package into Debian. I am debianizing the new upstream release and
shall soon post an updated RFS here with new package on
mentors.debian.net (probably in a week).
Cheers,
Bilal Akhtar.

On Sat, 2010-05-22 at 17:39 +0200, Robin Gareus wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Paul Wise wrote:
> > [CCing you since I presume you aren't subscribed, apologies if you are]
> No I'm not. Thanks for paying attention.
> 
> > On Fri, May 21, 2010 at 1:17 AM, Robin Gareus <robin@gareus.org> wrote:
> > 
> >>> xmalloc is GPL not LGPL so I'm wondering why upstream and
> >>> debian/copyright refer to the LGPL.
> >> xmalloc is 'generated' by autotools (autotools replaces the project-name in
> >> there) and /usr/share/doc/autoproject/README reads:
> >>
> >> "autoproject itself is distributed under the GNU General Public License.
> >> As a special exception to the GNU General Public License, you may
> >> use the files generated by autoproject without any restriction."
> > 
> > Hmm. I'd say that exception is so vague as to be useless. A permissive
> > license would be much better.
> 
> I've contacted the autotools author and suggested to change that
> sentence in the README to:
> "..without any restriction unless the generated-file states otherwise."
> 
> Getting the FSF to change the license of xmalloc.c to something more
> permissive would be great; but I'm not prepared to fight that uphill
> battle any longer :) I usually like the GPL and it's easy enough to
> re-invent xmalloc, anyway.
> 
> >>> xmalloc reduces the amount of software that can link with liboauth
> >>> (due to GPL licensing incompatibilities), it would be nice if upstream
> >>> could use plain malloc. You may want to send upstream a patch.
> >> no need to send a patch:
> >> xmalloc is only used IFF liboauth is configured with --enable-gpl.
> > 
> > Ah. The README says that --disable-gpl may cause segfaults, that
> > doesn't sound good.
> 
> Well, in practice it does not make much of a difference if the program
> exit(1) or segfaults if it encounters an out-of-memory error, does it :)
> 
> Anyway I figured it's easier to just replace GPL-xmalloc with some
> equivalent.. done in >= liboauth 0.8.0.
> 
> > Also, by using OpenSSL, you are preventing GPLed apps from using
> > liboauth due to license incompatibility between the apps and OpenSSL,
> > yay transitive license violations :D
> > 
> > http://lists.debian.org/debian-legal/2007/11/msg00061.html
> > 
> > Providing GnuTLS and or NSS backends might be one option to fix this.
> > Another might be to delegate SSL stuff to the app using liboauth.
> 
> Since liboauth-0.7.2 '--enable-nss' is available which makes liboauth
> use NSS instead of OpenSSL.
> 
> > Also, in 0.7.1, xmalloc is still linked into the library, you need to
> > do some ifdefs in src/Makefile.am.
> 
> Thanks for the hint; so far I was under the impression that simply not
> using the code (#ifdefs in xmalloc.h/xmalloc.c) would do the trick.
> 
> > libtool: link: x86_64-linux-gnu-gcc -shared  .libs/liboauth_la-oauth.o
> > .libs/liboauth_la-hash.o .libs/liboauth_la-xmalloc.o
> > .libs/liboauth_la-oauth_http.o   -lm -lcrypto /usr/lib/libcurl.so
> > -Wl,-z -Wl,defs   -Wl,-soname -Wl,liboauth.so.0 -o
> > .libs/liboauth.so.0.5.2
> 
> water under the bridge now.
> 
> >>> Uhh, actually since you are linking xmalloc and OpenSSL (GPL & OpenSSL
> >>> licenses are not compatible), the liboath0 binary package is not
> >>> distributable!
> >> Thanks for bringing this to my attention, I've added an exemption as suggested
> >> by http://lists.debian.org/debian-legal/2004/05/msg00595.htm
> > 
> > Uh, you are not the copyright holder of the xmalloc code, so you cannot do this.
> > 
> > As said above, --disable-gpl and dropping OpenSSL is the solution here.
> 
> since 0.8.0 there's no GPLed code in liboauth anymore.
> 
> The packaging (debian/ folder in the source-repo) is still GPL; but
> that's mostly for my own convenience and once you're done I'm happy to
> remove it from the source (unless you suggest otherwise).
> 
> >>> libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
> >>> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> >> ?? I don't use ACLOCAL_AMFLAGS in Makefile.am.
> > 
> > Probably it is prompting you to add it.
> 
> No, but I've added it anyway (liboauth-0.8.3).
> 
> >>> lintian complaints (send most upstream):
> > 
> >>> X: liboauth0: shlib-calls-exit usr/lib/liboauth.so.0.5.2
> > 
> > Looks like that was caused by using xmalloc.
> > 
> >>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:374
> >>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:376
> >>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:403
> >>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:405
> >>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:863
> >> Well, these are tricky! Said man-page is generated by Doxygen. Any ideas how to
> >> tell doxygen to properly escape those hyphens?
> >>
> >> I've found
> >> http://www.mail-archive.com/debian-mentors@lists.debian.org/msg39606.html
> >> but replacing them is not really an option since doxygen is also generating html
> >> from the same sources.
> > 
> > How are you building the manual page? Your Makefile.am doesn't list
> > any commands for doing so.
> 
> The top-level Makefile.am contains:
> 
> stamp-doxygen: src/oauth.h doc/mainpage.dox
>   $(DOXYGEN) Doxyfile && touch stamp-doxygen
>   cp doc/man/man3/oauth.h.3 doc/oauth.3
> 
> 
> Cheers!
> robin
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkv3+rQACgkQeVUk8U+VK0KiHgCgjY3+FrIeAL+StlLLE4l1OwX+
> 2vEAn1Yafo7He8Awk7J2YOR09ShjmCoz
> =3l+x
> -----END PGP SIGNATURE-----
> 
> 

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: