Is the module dependencies/tqca still needed? I use dependencies/tqca-tls, but not tqca. Also there has been no commit in tqca since Jul 2012.
cheers Michele
On 02/22/2014 01:07 AM, Michele Calgaro wrote:
Is the module dependencies/tqca still needed? I use dependencies/tqca-tls, but not tqca. Also there has been no commit in tqca since Jul 2012.
cheers Michele
I do not know the details, but I am building just tqca-tls as well. Someone who knows the history/requirements will have to enlighten us.
On Saturday 22 of February 2014 09:00:19 Michele Calgaro wrote:
I do not know the details, but I am building just tqca-tls as well. Someone who knows the history/requirements will have to enlighten us.
I added it to bug 1937 as a possible candidate for removal.
Michele
Yes, it is used tqca-tls, but tqca not.
On Sun February 23 2014 7:53:56 am Slávek Banko wrote:
On Saturday 22 of February 2014 09:00:19 Michele Calgaro wrote:
I do not know the details, but I am building just tqca-tls as well. Someone who knows the history/requirements will have to enlighten us.
I added it to bug 1937 as a possible candidate for removal.
Michele
Yes, it is used tqca-tls, but tqca not.
Both packages once were part of the overall KDE 3 build. What changed that tqca seems to be not needed?
On Mon, 24 Feb 2014 11:25:37 -0600 Darrell darrella@clovermail.net wrote:
On Sun February 23 2014 7:53:56 am Slávek Banko wrote:
On Saturday 22 of February 2014 09:00:19 Michele Calgaro wrote:
I do not know the details, but I am building just tqca-tls as well. Someone who knows the history/requirements will have to enlighten us.
I added it to bug 1937 as a possible candidate for removal.
Michele
Yes, it is used tqca-tls, but tqca not.
Both packages once were part of the overall KDE 3 build. What changed that tqca seems to be not needed?
qca-tls depends on qca--in fact, as far as I can tell, it's a qca plugin. I assume the same is true of their t* versions.
akio ~ # equery depends -a qca * These packages depend on qca: [...] app-crypt/qca-tls-1.0-r4 (=app-crypt/qca-1*)
akio ~ # cat /var/lib/layman/kde-sunset/app-crypt/qca-tls/qca-tls-1.0-r4.ebuild [...] DESCRIPTION="plugin to provide SSL/TLS capability to programs that utilize QCA"
Do we know which applications are using this, and has anyone tested their crypto/SSL capabilities (since this seems to be [t]qca's purpose)?
E. Liddell
qca-tls depends on qca--in fact, as far as I can tell, it's a qca plugin. I assume the same is true of their t* versions.
That is what I thought. The qca package is still built in Slackware releases, albeit, updated to version 2.0.2.
Do we know which applications are using this, and has anyone tested their crypto/SSL capabilities (since this seems to be [t]qca's purpose)?
I know of no tests ever being conducted.
Grepping through the source tree, I find the following use qca.h:
dependencies/tqca-tls/qcaprovider.h:29:#include"qca.h" tdenetwork/kopete/protocols/jabber/libiris/iris/xmpp-core/securestream.h:24:#include <qca.h> tdenetwork/kopete/protocols/jabber/libiris/iris/xmpp-core/tlshandler.cpp:24:#include <qca.h> tdenetwork/kopete/protocols/jabber/libiris/iris/xmpp-core/protocol.cpp:28:#include <qca.h> tdenetwork/kopete/protocols/jabber/libiris/iris/xmpp-core/stream.cpp:50:#include <qca.h> tdenetwork/kopete/protocols/jabber/libiris/iris/xmpp-core/simplesasl.cpp:27:#include <qca.h> tdenetwork/kopete/protocols/jabber/libiris/iris/xmpp-core/connector.cpp:35:#include <qca.h> tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/s5b.cpp:28:#include <qca.h> tdenetwork/kopete/protocols/jabber/libiris/qca/src/qcaprovider.h:29:#include "qca.h" tdenetwork/kopete/protocols/jabber/libiris/qca/src/qca.h:2: * qca.h - TQt Cryptographic Architecture tdenetwork/kopete/protocols/jabber/libiris/qca/src/qca.cpp:21:#include "qca.h" tdenetwork/kopete/protocols/jabber/libiris/cutestuff/network/httppoll.cpp:27:#include <qca.h> tdenetwork/kopete/protocols/jabber/jabberclient.cpp:27:#include <qca.h> tdenetwork/kopete/protocols/jabber/jabberaccount.cpp:28:#include <qca.h> tdenetwork/kopete/protocols/jabber/ui/jabberregisteraccount.cpp:36:#include <qca.h> tdenetwork/kopete/protocols/groupwise/libgroupwise/qcatlshandler.cpp:22:#include <qca.h> tdenetwork/kopete/protocols/groupwise/libgroupwise/tests/clientstream_test.h:22:#include <qca.h> tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:24:#include <qca.h> tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.h:23:#include <qca.h> tdenetwork/kopete/protocols/groupwise/libgroupwise/qca/src/qcaprovider.h:29:#include "qca.h" tdenetwork/kopete/protocols/groupwise/libgroupwise/qca/src/qca.h:2: * qca.h - TQt Cryptographic Architecture tdenetwork/kopete/protocols/groupwise/libgroupwise/qca/src/qca.cpp:21:#include "qca.h" tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:24:// #include <qca.h> tdenetwork/kopete/protocols/groupwise/gwaccount.cpp:46:#include <qca.h>
In Debian/Jessie, tqca-tls builds without the need for building tqca. Could you try in other distro and see if tqca-tls builds in the same way? If so, we can then drop tqca from the repo.
Cheers Michele
On Tue, 25 Feb 2014 06:10:00 +0000 (GMT) Michele Calgaro michele.calgaro@yahoo.it wrote:
In Debian/Jessie, tqca-tls builds without the need for building tqca. Could you try in other distro and see if tqca-tls builds in the same way? If so, we can then drop tqca from the repo.
My concern is that tqca-tls may compile but not actually *work* in the absence of tqca. Plugins can be really weird in how they link stuff together. Also, kopete seems to have a direct tqca dependency for some protocols (jabber and groupwise, judging from what Darrell found). We need to test not just the compiling, but the functionality of these packages before we can justify dropping tqca.
E. Liddell
My concern is that tqca-tls may compile but not actually *work* in the absence of tqca. Plugins can be really weird in how they link stuff together. Also, kopete seems to have a direct tqca dependency for some protocols (jabber and groupwise, judging from what Darrell found). We need to test not just the compiling, but the functionality of these packages before we can justify dropping tqca.
I see your point. If tqca-tls requires tqca for working correctly, then we will need to make it dependent on tqca for installation. Any way we could make a test for it? (I am no tqca expert at all :( )
Michele
Dne st 26. února 2014 Michele Calgaro napsal(a):
My concern is that tqca-tls may compile but not actually *work* in the absence of tqca. Plugins can be really weird in how they link stuff together. Also, kopete seems to have a direct tqca dependency for some protocols (jabber and groupwise, judging from what Darrell found). We need to test not just the compiling, but the functionality of these packages before we can justify dropping tqca.
I see your point. If tqca-tls requires tqca for working correctly, then we will need to make it dependent on tqca for installation. Any way we could make a test for it? (I am no tqca expert at all :( )
Michele
If I understand correctly, tqca is as a third-party "embedded" into Kopete. Hence on the tqca seemingly none depend and depends only on the tqca-tls, which is built as a library.
It therefore seems a good reason to not remove tqca. And in the future decide if tqca also build as a library. I think that for now we should postpone this question.
It therefore seems a good reason to not remove tqca. And in the future decide if tqca also build as a library. I think that for now we should postpone this question.
I agree. We have about 150 bug reports that have priority over what packages we keep or discard.
Darrell
-
Darrell -
David C. Rankin -
E. Liddell -
Michele Calgaro -
Slávek Banko