This is a update and rename of existing qca2 package

*** Bug 1161767 has been marked as a duplicate of this bug. ***

Fyi, qca can now support Qt5 too, but I chose to not include that yet, in order to keep the review simpler.

Please add documentation and botan plugins subpackages.
Use make doc to build documentation. Seems I didn't do install target for docs. So I must be copied to installation folder.

Spec URL: https://rdieter.fedorapeople.org/rpms/qca/qca.spec
SRPM URL: https://rdieter.fedorapeople.org/rpms/qca/qca-2.1.0-2.fc20.src.rpm

%changelog
* Fri Nov 14 2014 Rex Dieter <rdieter> 2.1.0-2
- -botan, -doc subpkgs, and READMEs to plugin subpkgs

#The following tests FAILED:
#          8 - FileWatch (Failed) 
How I can reproduce this?

Maybe should use %{_docdir} instead of %{_qt4_docdir}? Or there are reasons to use %{_qt4_docdir}?

Considering we will likely be adding qt5 support in the near future, using a Qt agnostic dir makes sense.  I'll switch that in the next pkg iteration (but won't update the review *just* for that.

As far as the failed test, good question, maybe the mock/koji environment is different somehow.  You should be able to reproduce it in mock yourself, then run 'mock shell' to entire into the buildroot for more investigation if needed.

Need to gnupg to BR. It is used in tests.

I rebuild qca for F21 x68_64 in mock. But can't reproduce FileWatcher failing unittest

$ rpm -qpl /home/taurus/rpmbuild/RPMS/x86_64/qca-2.1.0-2.fc20.R.x86_64.rpm
/usr/bin/mozcerts
/usr/bin/qcatool
/usr/lib64/libqca.so.2
/usr/lib64/libqca.so.2.1.0

It is bad idea to mix library and executable files. In this case I can't install on my system both qca.x86_64 and qca.i686 pacakges. Also mozcerts and qcatool not need for regular users. So this files should be moved to separate subpackes qca-tools for example or something like.

I wonder is it OK that package doesn't provide libqca-2.1.so ?

Re: comment #11
binaries should be ok, rpm uses binary coloring to prefer native binaries in this context.

Not sure what you mean by comment #12 , the library soname is libqca.so.2 (not libqca-2-1.so)

[root@lix lib64]# ll libQtCore.so.*
lrwxrwxrwx. 1 root root      18 Nov 14 02:14 libQtCore.so.4 -> libQtCore.so.4.8.6
lrwxrwxrwx. 1 root root      18 Nov 14 02:14 libQtCore.so.4.8 -> libQtCore.so.4.8.6
-rwxr-xr-x  1 root root 3108864 Jul 24 00:32 libQtCore.so.4.8.6
[root@lix lib64]# ll libqca.so.*
lrwxrwxrwx. 1 root root      15 Nov 14 02:15 libqca.so.2 -> libqca.so.2.0.3
lrwxrwxrwx. 1 root root      15 Nov 14 02:15 libqca.so.2.0 -> libqca.so.2.0.3
-rwxr-xr-x  1 root root 1154456 Aug  4  2013 libqca.so.2.0.3

In new qca no libqca.so.2.1 . There are only libqca.so.2 and libqca.so.2.1.0.

(In reply to Rex Dieter from comment #13)
> Re: comment #11
> binaries should be ok, rpm uses binary coloring to prefer native binaries in
> this context.
Yes. I checked it. No any problems. I installed both qca.i686 and qca.x86_64
# rpm -qa | grep qca
qca-devel-2.1.0-2.fc20.i686
qca-2.1.0-2.fc20.x86_64
qca-ossl-2.1.0-2.fc20.x86_64
qca-devel-2.1.0-2.fc20.x86_64
qca-gnupg-2.1.0-2.fc20.x86_64
qca-2.1.0-2.fc20.i686

Package is fine. About time to normalize names.

APPROVED

New Package SCM Request
=======================
Package Name: qca
Short Description: Qt Cryptographic Architecture
Upstream URL:  http://delta.affinix.com/qca
Owners: rdieter, slankes
Branches: f21,f20
InitialCC:

New Package SCM Request
=======================
Package Name: qca
Short Description: Qt Cryptographic Architecture
Upstream URL:  http://delta.affinix.com/qca
Owners: rdieter slankes
Branches: f21 f20
InitialCC:

Forgot, the package exists, but is retired and just needs some new branches.

Package Change Request
======================
Package Name: qca
New Branches: f21 f20
Owners: rdieter slankes

Git done (by process-git-requests).

Imported, thanks.

Boo, Qt5 build uses the same library soname and pkgconfig file names, so not parallel-installable with Qt4 versions.

Ivan, would you accept a patch to rename those to include a -qt5 suffix (when building against Qt5)?

And cmake files too.

Looks like I might be able to set QCA_SUFFIX=qt5 for this purpose, but I'd argue this should be set automatically in a standard way, else we risk API/ABI-incompatible implementations for different distros choosing different values for QCA_SUFFIX.

cmake files didn't use QCA_SUFFIX (yet), here's the patch I'm using currently,
http://pkgs.fedoraproject.org/cgit/qca.git/tree/qca-2.1.0-cmake_QCA_SUFFIX.patch

> but I'd argue this should be set automatically in a standard way

You are not alone :( https://git.reviewboard.kde.org/r/121168/

In really you must use two patches for Qt5 coinstalled version. 
http://quickgit.kde.org/?p=qca.git&a=commit&h=9a9c16dfd1affc92962acd92e4a5246830ccbc04
http://quickgit.kde.org/?p=qca.git&a=commit&h=66447d0454591f4c1deb5f4c988c6027194b1335

Anyway this all out of scope. Please make separate bugreport if you need/want.