Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 369781 - app-crypt/truecrypt-7.0a-r5 fails to build with dev-libs/opensc-0.12.0
Summary: app-crypt/truecrypt-7.0a-r5 fails to build with dev-libs/opensc-0.12.0
Status: RESOLVED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Dane Smith (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-02 10:07 UTC by Dennis Schridde
Modified: 2012-11-26 01:07 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,23.71 KB, text/plain)
2011-06-02 10:07 UTC, Dennis Schridde
Details
truecrypt-7.0a-r5.ebuild.diff (truecrypt-7.0a-r5.ebuild.diff,1.48 KB, patch)
2011-07-15 17:09 UTC, Alon Bar-Lev
Details | Diff
truecrypt-7.0a-r5.ebuild.diff (truecrypt-7.0a-r5.ebuild.diff,1.50 KB, patch)
2011-07-15 17:15 UTC, Alon Bar-Lev
Details | Diff
truecrypt-7.0a-r5.ebuild.diff (truecrypt-7.0a-r5.ebuild.diff,1.47 KB, patch)
2011-07-15 17:26 UTC, Alon Bar-Lev
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Schridde 2011-06-02 10:07:39 UTC
Created attachment 275593 [details]
build.log

See attached build.log


Portage 2.2.0_alpha37 (default/linux/amd64/10.0/desktop/kde, gcc-4.5.2, glibc-2.13-r2, 2.6.39-gentoo x86_64)
=================================================================
System uname: Linux-2.6.39-gentoo-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_5000+-with-gentoo-2.0.2
Timestamp of tree: Thu, 02 Jun 2011 05:45:01 +0000
distcc 3.1 x86_64-pc-linux-gnu [disabled]
app-shells/bash:          4.2_p10
dev-java/java-config:     2.1.11-r3
dev-lang/python:          2.7.1-r1, 3.1.3-r1, 3.2
dev-util/cmake:           2.8.4-r1
sys-apps/baselayout:      2.0.2
sys-apps/openrc:          0.8.2-r1
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.13, 2.68
sys-devel/automake:       1.9.6-r3, 1.10.3, 1.11.1-r1
sys-devel/binutils:       2.21
sys-devel/gcc:            4.5.2
sys-devel/gcc-config:     1.4.1-r1
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82
sys-kernel/linux-headers: 2.6.38 (virtual/os-headers)
sys-libs/glibc:           2.13-r2
Repositories: gentoo kde pcsx2 oss-overlay sunrise qt-symbian-overlay gamerlay-stable local
Installed sets: @kdebase
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-pipe -O2 -march=athlon64-sse3 -ftree-vectorize"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0 /var/lib/neatx/home"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /e
tc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-pipe -O2 -march=athlon64-sse3 -ftree-vectorize"
DISTDIR="/var/cache/portage/distfiles"
EMERGE_DEFAULT_OPTS="--depclean-lib-check n --with-bdeps y --keep-going"
FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms sign strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS=""
GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ http://distfiles.gentoo.org"
LANG="en_GB.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--hash-style=gnu"
LINGUAS="de"
MAKEOPTS="-j3"
PKGDIR="/var/cache/portage/packages"
PORTAGE_COMPRESS="xz"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/var/cache/portage/gentoo"
PORTDIR_OVERLAY="/var/cache/portage/layman/kde /var/cache/portage/layman/pcsx2 /var/cache/portage/layman/oss-overlay /var/cache/portage/layman/sunrise /var/cache/portage/layman/qt-symbian-overlay /var/cache/portage/layman/gamerlay /var/cache/portage/local"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Diego Elio Pettenò (RETIRED) gentoo-dev 2011-06-02 11:44:37 UTC
Lovely, so truecrypt tries to find the PKCS#11 headr from OpenSC, but that's gone with 0.12.0 since the interface is the usual PKCS#11 one.

I guess one solution would be to have a pkcs11-headers package somewhere that depends on one of the many PKCS#11 implementations.

And if you're not sure about what I'm saying, see http://blog.flameeyes.eu/2011/04/25/network-security-services-nss-and-pkcs-11 and related posts.
Comment 2 Dane Smith (RETIRED) gentoo-dev 2011-06-02 12:03:53 UTC
Diego,
I read through your post. I think I understand what you're getting at. I do not however understand it well enough (nor have the hardware) to even begin to try to fix/test this. Any input on the best way to fix this (especially if you can test it) would be greatly helpful. Thanks!
Comment 3 Diego Elio Pettenò (RETIRED) gentoo-dev 2011-06-02 12:12:31 UTC
Alon can I ask your opinion on this as well?

I think one approach we can have here is:

a) create virtual/pkcs11, which depends on || ( opensc opencryptoki nss scute .. )
b) make it install some /usr/include/pkcs11.h file

And this is definitely not limited to truecrypt, although other packages simply use their own pkcs11.h header.

do you know where we could find an "official" header for this at all?
Comment 4 Alon Bar-Lev 2011-06-02 18:34:19 UTC
Hello,

PKCS#11 header files are needed only at compile time.
A product that is using PKCS#11 is expected to contain the headers in the version of the spec it expect/implements.

The problem is that RSA security requires adding advertising clause, so their header are not GNU compatible.

If this is not an issue, and I don't think that in truecrypt this is an issue as it has its own license, I would have downloaded proper PKCS#11 files and place them under ${WORKDIR}/pkcs11 or something, and add -I CPPFLAGS.

RSA Security PKCS#11 files may be found here[1].

At open source projects we use a different headers taken from scute[2], this is a free re-written headers files which should be compatible with the RSA security's one.

Again, I would have added this to SRC_URI and use it while building.

No extra dependencies should be added.

What do you think?

[1] http://www.rsa.com/rsalabs/node.asp?id=2133
[2] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=scute.git;a=blob;f=src/pkcs11.h;h=03e904b763d84cd738b83a14bff8b97637fbd740;hb=HEAD
Comment 5 Dennis Schridde 2011-07-12 08:32:06 UTC
Any news? The problem persists...
Comment 6 Dane Smith (RETIRED) gentoo-dev 2011-07-15 13:11:46 UTC
This should be fixed in -r5. 

+  15 Jul 2011; Dane Smith <c1pher@gentoo.org> truecrypt-7.0a-r5.ebuild:
+  Allow for the inclusion of our own pkcs11.h if using >=opensc-0.12 wrt
+  bug 369781. No revbump. Thanks to Alon Bar-Lev and Diego Elio Petteno
+  for help with the fix.
+

I cannot however, test if it is using opensc correctly. I know for sure it compiles fine, but beyond that, I don't have the hardware. If someone could test it for me and get back to me it would be handy. Thanks!

Closing test-request.
Comment 7 Alon Bar-Lev 2011-07-15 17:04:46 UTC
Not good.

You should drop the:
	|| ( dev-libs/pkcs11-helper dev-libs/opensc ) 

dependency.

You should also remove the:
if ! has_version dev-libs/pkcs11-helper && \
    has_version "=dev-libs/opensc-0.12*"; then 


Use only the embed PKCS#11.

The pkcs11_include_directory should always use the embed.
Comment 8 Alon Bar-Lev 2011-07-15 17:09:44 UTC
Created attachment 280133 [details, diff]
truecrypt-7.0a-r5.ebuild.diff

Something like this.

Did not test as don't use and have no wxGTK on system.

Are you sure both:
append-flags -I"${S}"/pkcs11
And:
PKCS11_INC="${S}/pkcs11"
Are needed?
Comment 9 Alon Bar-Lev 2011-07-15 17:15:18 UTC
Created attachment 280135 [details, diff]
truecrypt-7.0a-r5.ebuild.diff

Also there is no reason why to touch "${S}" with out of tarball files.
Use "${T}".
Comment 10 Dane Smith (RETIRED) gentoo-dev 2011-07-15 17:21:39 UTC
(In reply to comment #7)
> Not good.
> 
> You should drop the:
>     || ( dev-libs/pkcs11-helper dev-libs/opensc ) 
> 
> dependency.
> 
> You should also remove the:
> if ! has_version dev-libs/pkcs11-helper && \
>     has_version "=dev-libs/opensc-0.12*"; then 
> 
> 
> Use only the embed PKCS#11.
> 
> The pkcs11_include_directory should always use the embed.

Why should the dependency be dropped? Just because we provide the header in the ebuild now doesn't mean the library will be present.
Also, why should we be forcing that header if the user is using pkcs11-helper which has it's own headers installed? I only put that pkcs11.h file there for >=opensc-0.12 

I am extremely unfamiliar with the pkcs11 foo as I have no way to test it, so if I'm being stupid, feel free to tell me.

(In reply to comment #8)
> Created attachment 280133 [details, diff]
> truecrypt-7.0a-r5.ebuild.diff
> 
> Something like this.
> 
> Did not test as don't use and have no wxGTK on system.
> 
> Are you sure both:
> append-flags -I"${S}"/pkcs11
> And:
> PKCS11_INC="${S}/pkcs11"
> Are needed?

They wouldn't both be necessary no. I have the append-flags line there because I was forcing it to use the one included in ${S} if it didn't fine the one on the normal file system.
Comment 11 Alon Bar-Lev 2011-07-15 17:25:34 UTC
(In reply to comment #10)
> Why should the dependency be dropped? Just because we provide the header in the
> ebuild now doesn't mean the library will be present.
> Also, why should we be forcing that header if the user is using pkcs11-helper
> which has it's own headers installed? I only put that pkcs11.h file there for
> >=opensc-0.12 

PKCS#11 is an interface.
Not bound to any specific implementation.
You can use PKCS#11 interface with *ANY* PKCS#11 provider we have a few in portage and many other.

Application is PKCS#11 enabled - does not mean one or any implementation should exists.

> > Are you sure both:
> > append-flags -I"${S}"/pkcs11
> > And:
> > PKCS11_INC="${S}/pkcs11"
> > Are needed?
> 
> They wouldn't both be necessary no. I have the append-flags line there because
> I was forcing it to use the one included in ${S} if it didn't fine the one on
> the normal file system.

So leave only the PKCS11_INC statement. Better local change and use build features than global change.
Comment 12 Alon Bar-Lev 2011-07-15 17:26:17 UTC
Created attachment 280137 [details, diff]
truecrypt-7.0a-r5.ebuild.diff
Comment 13 Dane Smith (RETIRED) gentoo-dev 2011-07-15 17:54:02 UTC
Done in -r6. Thanks for the help Alon. Let me know if it all looks Ok.

+*truecrypt-7.0a-r6 (15 Jul 2011)
+
+  15 Jul 2011; Dane Smith <c1pher@gentoo.org> +truecrypt-7.0a-r6.ebuild:
+  Rev bump. Include our own headers by default. Removed dependency on a
+  pkcs11 implementation. Should work with any of them now. Thanks Alon
+  Bar-Lev for the help. Bump to EAPI 4. Bug 369781
Comment 14 Dennis Schridde 2011-07-16 00:44:28 UTC
(In reply to comment #11)
> PKCS#11 is an interface.
> Not bound to any specific implementation.
> You can use PKCS#11 interface with *ANY* PKCS#11 provider we have a few in
> portage and many other.
Doesn't that qualify it for a virtual? I.e. virtual/pkcs11 and DEPEND="pkcs11? (virtual/pkcs11)" in truecrypt.
Comment 15 Diego Elio Pettenò (RETIRED) gentoo-dev 2011-07-16 00:47:49 UTC
Quite possibly, yes, and it would be nice to have indeed, the problem is that in most cases, people would have one provided already, although it is a mess to configure it (NSS).
Comment 16 Alon Bar-Lev 2011-07-16 05:33:31 UTC
(In reply to comment #14)
> (In reply to comment #11)
> > PKCS#11 is an interface.
> > Not bound to any specific implementation.
> > You can use PKCS#11 interface with *ANY* PKCS#11 provider we have a few in
> > portage and many other.
> Doesn't that qualify it for a virtual? I.e. virtual/pkcs11 and DEPEND="pkcs11?
> (virtual/pkcs11)" in truecrypt.

No.
The fact that you allow application to support PKCS#11, does not mean that a provider must exist in order application to work. Also if you have a provider out side of tree you should not be forced to install a unneeded provider just to make it work.

The virtual keyword is good if a component is actually needed but have few options, and once built application detects this option and proceed.

This is not the case in PKCS#11.