[opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi, I have put an unofficial fork of the official OpenSC repo for the Debian packages ( git://git.debian.org/git/pkg-opensc/opensc.git ) onto github. It is available at git://github.com/marschap/pkg-opensc.git The branches erics-upsream erics-master are the upstream master branches from Eric's repo at git.debian.org The branches upstream master are my going at 0.12.2 packaging. Rough overview of the changes: * get rid of unecessary Build-Depends: libxt-dev * renable zlib readline support * add westcos-tool its man page: new with 0.12.2 * explicitely nable building of man pages * add *.profile files * don't use dh_autoconfigure in override_dh_autoconfigure, but call bootstrap (see below) configure directly * simplify opensc.install - get rid of debian/tmp - new file opensc.manpages - extend opensc.docs * empty 'dependency_libs' in .la files (please lintian) Are those .la files necessary at all (for dlopen, ...)? Details can be found in the commit messages. Using the changes I was able to successfully build private opensc 0.12.2-0pm1 (please forgive my private release numbering scheme ;-) packages for i386 and amd64. A few things I have not yet done/solved: * not 100% lintian clean: 3 or 4 warnings left I was too lazy. * In debian testing, trying to build the package using git-buildpackage with the autotools provided in the upstream tar ball failed. (Funnily it worked when doing a simple buildpackage) For this reason I am calling the ./bootstrap script at the beginning the configure phase which makes the package build, but creates a rather large debian diff. Feel free to play with it. Eric, what about a new, official Debian package, with my changes as the starting point as starting point? Best regards Peter -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
On 08/21/2011 12:36 PM, Peter Marschall wrote: * renable zlib readline support [...] what about a new, official Debian package, with my changes as the starting point as starting point? i don't think these are compatible with the DFSG, alas. GNU readline (at least) is GPL-licensed, and opensc links against OpenSSL. So building a package that links to both of them creates a non-redistributable work :( http://people.gnome.org/~markmc/openssl-and-the-gpl.html Is there any way to have OpenSC build against some crypto libraries other than OpenSSL (preferably licensed in GPL-compatible ways) so we could link it to readline without violating one license or the other? --dkg signature.asc Description: OpenPGP digital signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi Daniel, Am Sonntag 21 August 2011, 23:23:36 schrieb Daniel Kahn Gillmor: On 08/21/2011 12:36 PM, Peter Marschall wrote: * renable zlib readline support [...] what about a new, official Debian package, with my changes as the starting point as starting point? i don't think these are compatible with the DFSG, alas. GNU readline (at least) is GPL-licensed, and opensc links against OpenSSL. So building a package that links to both of them creates a non-redistributable work :( http://people.gnome.org/~markmc/openssl-and-the-gpl.html I agree with this. Is there any way to have OpenSC build against some crypto libraries other than OpenSSL (preferably licensed in GPL-compatible ways) so we could link it to readline without violating one license or the other? On the other hand: what part of opensc benefits from using readline? I guess the only place it might be used is the opensc-explorer, and it works fine for me without readline - so I say lets remove the readline code to avoid this. It might be nice to have opensc link with libgcrypt instead of openssl too. libgcrypt has a very nice interface and is much easier to use than openssl in my opinion. but if we work on such a change, we will have some fun with the new stacking: will applications (that use openssl or libgnutls) still work if that library or a helper to that lib uses a plugin interface (pkcs#12) to load opensc pkcs#12 plugin which is linked to (libcrypto or libgcrypt). we had problems even with app - openssl - opensc - libcrypto setup in the past, and I would expect problems here - or this should at least require a lot of testing to make sure the resulting setup works correctly. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
