Bug#913959: kde4libs: Build-Depends on libssl1.0-dev
Source: kde4libs Version: 4:4.14.38-2 Severity: serious Hi, It seems that kde4libs Build-Depends on libssl1.0-dev as a result of #828363. There are currently no packages depending on libssl1.0.2 left in testing, but this source package is the only one that has a Build-Depends against libssl1.0-dev. There doesn't seem to be any of the binary packages that has a Depends or Recommends on libssl1.0.2, so either the support for it actually got disabled or it's loaded at run time and might fail to load it since nothing will pull in libssl1.0.2. Kurt
Bug#858938: fixed in kopete 4:18.04.1-1
On Sat, Nov 10, 2018 at 03:48:37PM +0100, Pino Toscano wrote: > In data sabato 10 novembre 2018 13:30:19 CET, Kurt Roeckx ha scritto: > > On Sun, Oct 28, 2018 at 11:29:43PM +0100, Sebastian Andrzej Siewior wrote: > > > On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote: > > > > On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior > > > > wrote: > > > > > On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote: > > > > > > On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote: > > > > > > > Source: kopete > > > > > > > Source-Version: 4:18.04.1-1 > > > > > > > > > > > > > > We believe that the bug you reported is fixed in the latest > > > > > > > version of > > > > > > > kopete, which is due to be installed in the Debian FTP archive. > > > > > > > > > > > > Any plans to upload this to unstable? > > > > > > > > > > There are just two packages left in testing which use openssl1.0. The > > > > > last kopete upload was in mid June. Is there anything blocking an > > > > > upload > > > > > to unstable? > > > > > > > > The other one just got fixed in unstable, so this will soon be the > > > > only package in testing still depending on libssl1.0.2. > > > > > > kopete is the only package in testing still using libssl1.0.2. Could > > > someone please comment on this? > > > > This is in experimental for more than 5 months now. > > > > If nobody replies to this, I will upload an NMU to unstable. > > NMU *what*? Because if you upload the version in experimental to > unstable, then you are effectively taking its maintainership. > The version in experimental is *NOT* ready for unstable/testing, > otherwise I would have uploaded it long ago. And you could have answered this months ago that it was not ready, or that you prefer to fix this the version in unstable instead, or whatever. > > OTOH, this kind of non-helping attitude for you openssl guys (for > example not helping fixing these porting bugs, constant useless poking, > breakage of openssl 1.1 in unstable) certainly does not help. > If you want cooperation, then be ccoperative yourself, instead of just > expecting others to follow whatever you do. > If you need help with something, please ask. Just as you, we're busy with various things, submitting patches for various packages. This bug got closed, so as far as we know you don't need help. Kurt
Re: Bug#858938: fixed in kopete 4:18.04.1-1
On Sun, Oct 28, 2018 at 11:29:43PM +0100, Sebastian Andrzej Siewior wrote: > On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote: > > On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote: > > > On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote: > > > > On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote: > > > > > Source: kopete > > > > > Source-Version: 4:18.04.1-1 > > > > > > > > > > We believe that the bug you reported is fixed in the latest version of > > > > > kopete, which is due to be installed in the Debian FTP archive. > > > > > > > > Any plans to upload this to unstable? > > > > > > There are just two packages left in testing which use openssl1.0. The > > > last kopete upload was in mid June. Is there anything blocking an upload > > > to unstable? > > > > The other one just got fixed in unstable, so this will soon be the > > only package in testing still depending on libssl1.0.2. > > kopete is the only package in testing still using libssl1.0.2. Could > someone please comment on this? This is in experimental for more than 5 months now. If nobody replies to this, I will upload an NMU to unstable. Kurt
Bug#858938: fixed in kopete 4:18.04.1-1
On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote: > On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote: > > On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote: > > > Source: kopete > > > Source-Version: 4:18.04.1-1 > > > > > > We believe that the bug you reported is fixed in the latest version of > > > kopete, which is due to be installed in the Debian FTP archive. > > > > Any plans to upload this to unstable? > > There are just two packages left in testing which use openssl1.0. The > last kopete upload was in mid June. Is there anything blocking an upload > to unstable? The other one just got fixed in unstable, so this will soon be the only package in testing still depending on libssl1.0.2. Kurt
Re: [Pkg-openssl-devel] OpenSSL+Qt interoperability?
On Tue, Sep 11, 2018 at 10:43:26PM +0300, Antti Järvinen wrote: > Dear OpenSSL+Qt Sirs, Please try 5.11.1+dfsg-8. Kurt
Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On Tue, Sep 11, 2018 at 08:14:35PM +0300, Dmitry Shachnev wrote: > Hi Kurt, > > On Tue, Sep 11, 2018 at 07:09:04PM +0200, Kurt Roeckx wrote: > > If this is for a call to SSL_CTX_set_max_proto_version(), you can > > use 0 instead of TLS_MAX_VERSION. > > Good point, thanks. > > However as the patch is temporary, I do not think it is worth > a new upload to change that. But maybe you can get upstream to use that instead. I'm thinking about removing that symbol from the public header, but that would be a 1.2 thing in that case. Kurt
Bug#907774: [Pkg-openssl-devel] Bug#908567: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On Tue, Sep 11, 2018 at 04:11:02PM +0300, Adrian Bunk wrote: > > Dmitry already implemented my short-term workaround: > https://tracker.debian.org/news/986618/accepted-qtbase-opensource-src-5111dfsg-8-source-into-unstable/ If this is for a call to SSL_CTX_set_max_proto_version(), you can use 0 instead of TLS_MAX_VERSION. Kurt
Bug#858938: fixed in kopete 4:18.04.1-1
On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote: > Source: kopete > Source-Version: 4:18.04.1-1 > > We believe that the bug you reported is fixed in the latest version of > kopete, which is due to be installed in the Debian FTP archive. Any plans to upload this to unstable? Kurt
Re: Bug#828522: QT4 and OpenSSL 1.1.0: [was Re: OpenSSL 1.1.0]
On Sat, Oct 29, 2016 at 10:32:34PM +0200, Sebastian Andrzej Siewior wrote: > One thing that confuses me: Why has none > of the libraries a dependency on libssl? >From what I understand they use dlopen() and this would allow GPL applications to use QT when they don't use OpenSSL. (QT itself being LGPL) This is of course potentionally problematic if we have 2 versions of openssl that get linked into the same application. Kurt
Re: Bug#828522: QT4 and OpenSSL 1.1.0: [was Re: OpenSSL 1.1.0]
On Tue, Jun 28, 2016 at 09:53:20PM +0200, Gert Wollny wrote: > Thanks for the review. Can I ask what the current state of this is? Kurt
Re: Bug#828522: QT4 and OpenSSL 1.1.0: [was Re: OpenSSL 1.1.0]
On Tue, Jun 28, 2016 at 07:36:27PM +0200, Gert Wollny wrote:
> Okay, the attached patch corrects this.
I had a quick look at the patch and have some comments.
> --- a/src/network/ssl/qsslcertificate.cpp
> +++ b/src/network/ssl/qsslcertificate.cpp
> @@ -259,10 +259,15 @@
> QByteArray QSslCertificate::version() const
> {
> QMutexLocker lock(QMutexPool::globalInstanceGet(d.data()));
> -if (d->versionString.isEmpty() && d->x509)
> +if (d->versionString.isEmpty() && d->x509) {
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> d->versionString =
> -
> QByteArray::number(qlonglong(q_ASN1_INTEGER_get(d->x509->cert_info->version))
> + 1);
> -
> +
> QByteArray::number(qlonglong(q_ASN1_INTEGER_get(d->x509->cert_info->version))
> + 1);
> +#else
> +d->versionString =
> + QByteArray::number(qlonglong(q_X509_get_version(d->x509)) + 1);
> +#endif
X509_get_version() exist in old versions (as macro), there is no
reason to have the version check, just always use it.
> @@ -276,7 +281,11 @@
> {
> QMutexLocker lock(QMutexPool::globalInstanceGet(d.data()));
> if (d->serialNumberString.isEmpty() && d->x509) {
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> ASN1_INTEGER *serialNumber = d->x509->cert_info->serialNumber;
> +#else
> +ASN1_INTEGER *serialNumber = q_X509_get_serialNumber(d->x509);
> +#endif
Same as above.
> @@ -489,24 +498,33 @@
> QSslKey key;
>
> key.d->type = QSsl::PublicKey;
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> X509_PUBKEY *xkey = d->x509->cert_info->key;
> +#else
> +X509_PUBKEY *xkey = q_X509_get_X509_PUBKEY(d->x509);
> +#endif
> EVP_PKEY *pkey = q_X509_PUBKEY_get(xkey);
> Q_ASSERT(pkey);
>
> -if (q_EVP_PKEY_type(pkey->type) == EVP_PKEY_RSA) {
> +int key_id;
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> +key_id = q_EVP_PKEY_type(pkey->type);
> +#else
> +key_id = q_EVP_PKEY_id(pkey);
> +#endif
You probably want EVP_PKEY_base_id here, look at the manpage.
> +if (key_id == EVP_PKEY_RSA) {
> key.d->rsa = q_EVP_PKEY_get1_RSA(pkey);
> key.d->algorithm = QSsl::Rsa;
> key.d->isNull = false;
> -} else if (q_EVP_PKEY_type(pkey->type) == EVP_PKEY_DSA) {
> +} else if (key_id == EVP_PKEY_DSA) {
> key.d->dsa = q_EVP_PKEY_get1_DSA(pkey);
> key.d->algorithm = QSsl::Dsa;
> key.d->isNull = false;
> -} else if (q_EVP_PKEY_type(pkey->type) == EVP_PKEY_DH) {
> +} else if (key_id == EVP_PKEY_DH) {
> // DH unsupported
> } else {
> // error?
> }
As already explain, you want to have EC support.
>
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> + q_X509_STORE_add_cert(ctx->cert_store, (X509
> *)caCertificate.handle());
> +#else
> + q_X509_STORE_add_cert(q_SSL_CTX_get_cert_store(ctx), (X509
> *)caCertificate.handle());
> +#endif
SSL_CTX_get_cert_store should exist in old version.
Kurt
Re: Bug#828522: QT4 and OpenSSL 1.1.0: [was Re: OpenSSL 1.1.0]
On Tue, Jun 28, 2016 at 12:46:17PM +0200, Gert Wollny wrote: > Control: tags -1 patch > > Hi, > > attached is the patch that I have come up with. > > I think that most of the changes are quite straightforward, but I'm not > quite sure whether "DSA_security_bits" is really a proper replacement > for "BN_num_bits(d->dsa->p)", likewise RSA_bits versus > BN_num_bits(d->rsa->n). DSA_security_bits probably doesn't what you expect, it's clearly not a replacement for the old code. It gives an equivalent number as if it was a symmetric cipher. For a 2048 bit DSA key it would return 112. That's also the difference between RSA_bits and RSA_security_bits. You could to use DSA_get0_pqg(), and then use BN_num_bits on p if you want the same. You probably also want to add support for EC keys. There are also the functions EVP_PKEY_bits() and EVP_PKEY_security_bits(), which should work for any EVP_PKEY, and I suggest you use that API instead. Kurt
Re: Bug#828522: QT4 and OpenSSL 1.1.0: [was Re: OpenSSL 1.1.0]
On Mon, Jun 27, 2016 at 01:34:02PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On lunes, 27 de junio de 2016 5:06:48 P. M. ART Gert Wollny wrote: > > Hi, > > > > while there was a little section about what breaks with QT on [1] it > > didn't mention that the threading model was changed completely without > > any compatibility layer, and QT4 uses this old threading model in their > > network/ssl layer - or at least they provide and set the locking > > callbacks. > > > > So unless openssl upstream (or someone else knowledgeable) gives an > > clear indication how to replace the old threading model with the new > > one, I'd rather not touch this part of the code. > > > > I'll see, however, whether I can provide a patch for the other compile > > errors. > > Ah, right, upstream also mentioned that, although for Qt 5. So this is even > more complicated than what I first assumed. > > CC-ing Kurt here to both let him know and maybe sugest something. > > Thanks Gert for looking into this! >From what I understand, you don't need to the the thread callbacks anymore, the old functions are macro's that don't do a thing. It should set up threading support and locking internally. So can you clarify what kind of things you see as issue? Kurt
Bug#828523: qtbase-opensource-src: FTBFS with openssl 1.1.0
Source: qtbase-opensource-src Version: 5.5.1+dfsg-17 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/qtbase-opensource-src_5.5.1+dfsg-17_amd64-20160529-1520 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828522: qt4-x11: FTBFS with openssl 1.1.0
Source: qt4-x11 Version: 4.8.7+dfsg-7 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/qt4-x11_4.8.7+dfsg-7_amd64-20160529-1519 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828519: qca2: FTBFS with openssl 1.1.0
Source: qca2 Version: 2.1.1-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/qca2_2.1.1-2_amd64-20160529-1516 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828367: kopete: FTBFS with openssl 1.1.0
Source: kopete Version: 16.04.0-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/kopete_16.04.0-2_amd64-20160529-1436 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828363: kde4libs: FTBFS with openssl 1.1.0
Source: kde4libs Version: 4.14.20-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/kde4libs_4.14.20-2_amd64-20160529-1433 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828364: kdelibs4support: FTBFS with openssl 1.1.0
Source: kdelibs4support Version: 5.22.0-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/kdelibs4support_5.22.0-1_amd64-20160529-1434 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#805159: virtuoso-opensource: FTBFS on powerpc
Source: virtuoso-opensource
Version: 6.1.6+dfsg2-2
Severity: serious
Control: block 797926 by -1
Hi,
Your package is failing to build on powerpc. I'm not sure what
the error really is, but at least this looks like the first error:
VAD Documentation sticker doc_vad_dav.xml creation...
***FAILED: starting DB.DBA.VAD_PACK('doc_vad_dav.xml', '.', 'doc_dav.vad')
***FAILED: starting commit work
***FAILED: starting checkpoint
***FAILED: checkpoint
***FAILED: shutdown
chmod: cannot access 'doc_dav.vad': No such file or directory
A full log can be seen at:
https://buildd.debian.org/status/fetch.php?pkg=virtuoso-opensource&arch=powerpc&ver=6.1.6%2Bdfsg2-2%2Bb1&stamp=1446805980
Kurt
Bug#805157: virtuoso-opensource: FTBFS on s390x: conflicting types for 'saddr_t'
Source: virtuoso-opensource Version: 6.1.6+dfsg2-2 Severity: serious Control: block 797926 by -1 Hi, Your package is failing to build on s390x with the following error: In file included from Dksestcp.c:32:0: Dksestcpint.h:45:25: error: conflicting types for 'saddr_t' typedef struct sockaddr saddr_t; ^ In file included from /usr/include/linux/types.h:4:0, from /usr/include/s390x-linux-gnu/asm/sigcontext.h:10, from /usr/include/s390x-linux-gnu/bits/sigcontext.h:27, from /usr/include/signal.h:332, from ../../libsrc/Dk/Dksystem.h:62, from ../../libsrc/Dk.h:40, from Dksestcp.c:30: /usr/include/s390x-linux-gnu/asm/types.h:18:25: note: previous declaration of 'saddr_t' was here typedef __signed__ long saddr_t; ^ Dksestcp.c: In function 'tcpses_listen': Dksestcp.c:485:14: warning: variable 'p_addr' set but not used [-Wunused-but-set-variable] saddrin_t *p_addr; ^ Makefile:880: recipe for target 'libdksrv_la-Dksestcp.lo' failed make[5]: *** [libdksrv_la-Dksestcp.lo] Error 1 A full log can be seen at: https://buildd.debian.org/status/fetch.php?pkg=virtuoso-opensource&arch=s390x&ver=6.1.6%2Bdfsg2-2%2Bb1&stamp=1446805326 Kurt
Re: Problem with dolphin package on buildd amd64 (brahms)
On Wed, Sep 23, 2015 at 07:55:56PM +0200, Kurt Roeckx wrote: > On Wed, Sep 23, 2015 at 12:58:01PM +0300, Boris Pek wrote: > > Hi everyone, > > > > As we can see at [1][2] something strange had happened during building of > > dolphin package on buildd amd64 (brahms). Could you look on this? > > It looks strange indeed, no idea what happened to the log. I gave > it back, let's see what happens. It ran out of disk space. I've stopped brahms. Kurt
Re: Problem with dolphin package on buildd amd64 (brahms)
On Wed, Sep 23, 2015 at 12:58:01PM +0300, Boris Pek wrote: > Hi everyone, > > As we can see at [1][2] something strange had happened during building of > dolphin package on buildd amd64 (brahms). Could you look on this? It looks strange indeed, no idea what happened to the log. I gave it back, let's see what happens. Kurt
Bug#623596: [Pkg-openssl-devel] Processed: Re: Bug#623596: mumble: Problem with the import certificats
On Wed, May 04, 2011 at 01:15:18PM +0300, Modestas Vainius wrote: > Hello, > > On antradienis 26 Balandis 2011 20:47:45 Thorvald Natvig wrote: > > That being said, Qt also supports explicit compile-time linking to > > libssl and libcrypto, which avoids issues like this one and also ensures > > that libqt4-network shows up as a reverse dependency for openssl. If > > nothing else, the runtime libraries for OpenSSL should be added as a > > recommends: for the libqt4-network package. But in todays crypto-heavy > > world, I can't really think of a good reason not to just link it. Among > > other things, Qt's web widgets (and URL classes) will not support https > > without libssl/libcrypto. > > OpenSSL license is THE reason. Or pure-GPL apps won't be able to link against > libQtNetwork which is unacceptable. I think dynamicly loading instead of linking doesn't change this license problem. Kurt -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504162353.ga20...@roeckx.be
Bug#498903: krita: Can't import files with dcraw: non-numeric argument to -n
On Wed, Feb 17, 2010 at 11:41:08AM +0100, Ana Guerrero wrote: > Hi Kurt, > > On Sat, Feb 13, 2010 at 03:05:19PM +0100, Kurt Roeckx wrote: > > found 498903 1:1.6.3-8 > > fixed 498903 1:2.1.1-1 > > thanks > > > > I think I never got your mail asking about this. The version > > in experimental seems to make use of libraw instead, so > > it's not giving that error. > > What kokeroulis meant is you have been asked about this bug from another > triager, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498903#10 Yes, and for some reason I never got that mail. > > Is that an embedded copy of libraw? I don't see it in the > > archive. > > > > No, Krita from koffice 2 uses libkdcraw from kdegraphics. Right, I noticed this aftewards. Kurt -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100217171048.ga18...@roeckx.be
Bug#498903: krita: Can't import files with dcraw: non-numeric argument to -n
found 498903 1:1.6.3-8 fixed 498903 1:2.1.1-1 thanks I think I never got your mail asking about this. The version in experimental seems to make use of libraw instead, so it's not giving that error. Is that an embedded copy of libraw? I don't see it in the archive. Kurt -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533624: kdebindings: FTBFS: error: non-static can't use default assignment operator
Source: kdebindings Version: 4:4.2.4-1+b1 Severity: serious Hi, There was an error while trying to autobuild your package: > Automatic build of kdebindings_4:4.2.4-1+b1 on excelsior by sbuild/amd64 98 > Build started at 20090614-2159 [...] > Build-Depends: debhelper (>= 7), quilt, kdelibs5-dev (>= 4:4.2.2), > libqt4-opengl-dev (>= 4.5.1), libphonon-dev (>= 4:4.3.0), libsoprano-dev (>= > 2.1.67-2~), python, python-all-dev, sip4 (>= 4.7.8), python-sip4-dev (>= > 4.7.8), python-qt4 (>= 4.4.4), python-qt4-dev (>= 4.4.4), ruby1.8-dev, > ruby1.8, python-support (>= 0.6), mono-devel (>= 2.0.1) [i386 kfreebsd-i386 > powerpc amd64 kfreebsd-amd64 ia64 arm armeb armel sparc s390], cli-common-dev > (>= 0.5.4) [i386 kfreebsd-i386 powerpc amd64 kfreebsd-amd64 ia64 arm armeb > armel sparc s390], okular-dev (>= 4:4.2.0), kdepimlibs5-dev (>= 4:4.2.0), > libakonadi-dev (>= 1.1.1) [...] > Toolchain package versions: linux-libc-dev_2.6.29-5 libc6-dev_2.9-13 > g++-4.3_4.3.3-10 gcc-4.3_4.3.3-10 binutils_2.19.1-1 libstdc++6_4.4.0-6 > libstdc++6-4.3-dev_4.3.3-10 [...] > make[3]: Entering directory > `/build/buildd/kdebindings-4.2.4/obj-x86_64-linux-gnu/python/pykde4-2.5' > /usr/bin/cmake -E cmake_progress_report > /build/buildd/kdebindings-4.2.4/obj-x86_64-linux-gnu/python/pykde4-2.5/CMakeFiles > > [ 1%] Building CXX object > CMakeFiles/python_module_PyKDE4_akonadi.dir/sip/akonadi/sipakonadipart0.o > /usr/bin/c++ -Dpython_module_PyKDE4_akonadi_EXPORTS -D_BSD_SOURCE > -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII > -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DQT3_SUPPORT -D_REENTRANT > -DQT_CORE_LIB -DQT_GUI_LIB -g -O2 -Wnon-virtual-dtor -Wno-long-long -ansi > -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith > -Wformat-security -fno-exceptions -fno-check-new -fno-common > -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden > -fvisibility-inlines-hidden -DNDEBUG -DQT_NO_DEBUG -fPIC -I. > -I/build/buildd/kdebindings-4.2.4/python/pykde4 -I/usr/include/python2.5 > -I/usr/include/qt4 -I/usr/include/qt4/Qt -I/usr/include/qt4/QtCore > -I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtGui > -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtOpenGL > -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSvg > -I/usr/include/solid -I/usr/include/kio -I/usr/include/kdeprint > -I/usr/include/kdeprint/lpr -I/usr/include/dom -I/usr/include/ksettings > -I/usr/include/knewstuff2 -I/usr/include/dnssd -D_GNU_SOURCE > -D_LARGEFILE64_SOURCE -o > CMakeFiles/python_module_PyKDE4_akonadi.dir/sip/akonadi/sipakonadipart0.o -c > sip/akonadi/sipakonadipart0.cpp > In file included from /usr/include/python2.5/Python.h:8, > from /usr/include/python2.5/sip.h:28, > from sip/akonadi/sipAPIakonadi.h:11, > from sip/akonadi/sipakonadipart0.cpp:7: > /usr/include/python2.5/pyconfig.h:948:1: warning: "_XOPEN_SOURCE" redefined > : warning: this is the location of the previous definition > /build/buildd/kdebindings-4.2.4/python/pykde4/sip/kdecore/typedefs.sip: In > function 'PyObject* convertFrom_QSet_0200QByteArray(void*, PyObject*)': > /build/buildd/kdebindings-4.2.4/python/pykde4/sip/kdecore/typedefs.sip:578: > warning: suggest explicit braces to avoid ambiguous 'else' > /usr/bin/cmake -E cmake_progress_report > /build/buildd/kdebindings-4.2.4/obj-x86_64-linux-gnu/python/pykde4-2.5/CMakeFiles > 1 > [ 2%] Building CXX object > CMakeFiles/python_module_PyKDE4_akonadi.dir/sip/akonadi/sipakonadipart1.o > /usr/bin/c++ -Dpython_module_PyKDE4_akonadi_EXPORTS -D_BSD_SOURCE > -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII > -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DQT3_SUPPORT -D_REENTRANT > -DQT_CORE_LIB -DQT_GUI_LIB -g -O2 -Wnon-virtual-dtor -Wno-long-long -ansi > -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith > -Wformat-security -fno-exceptions -fno-check-new -fno-common > -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden > -fvisibility-inlines-hidden -DNDEBUG -DQT_NO_DEBUG -fPIC -I. > -I/build/buildd/kdebindings-4.2.4/python/pykde4 -I/usr/include/python2.5 > -I/usr/include/qt4 -I/usr/include/qt4/Qt -I/usr/include/qt4/QtCore > -I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtGui > -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtOpenGL > -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSvg > -I/usr/include/solid -I/usr/include/kio -I/usr/include/kdeprint > -I/usr/include/kdeprint/lpr -I/usr/include/dom -I/usr/include/ksettings > -I/usr/include/knewstuff2 -I/usr/include/dnssd -D_GNU_SOURCE > -D_LARGEFILE64_SOURCE -o > CMakeFiles/python_module_PyKDE4_akonadi.dir/sip/akonadi/sipakonadipart1.o -c > sip/akonadi/sipakonadipart1.cpp > In file included from /usr/include/python2.5/Python.h:8, > from /usr/include/python2.5/sip.h:28, > from sip/akonadi/sipAPIakonadi.h:11, >
Bug#527006: kdegraphics: FTBFS: error: 'SANE_STATUS_WARMING_UP' was not declared in this scope
Source: kdegraphics Version: 4:4.2.2-1 Severity: serious Hi, There was an error while trying to autobuild your package: > Automatic build of kdegraphics_4:4.2.2-1+b1 on nautilus by sbuild/amd64 98 > Build started at 20090504-2019 [...] > Build-Depends: cdbs (>= 0.4.51), debhelper (>= 7), quilt, pkg-kde-tools (>= > 0.4.2), kdelibs5-dev (>= 4:4.2.2), libphonon-dev (>= 4:4.3.0), > libpoppler-qt4-dev (>= 0.8.0), libspectre-dev, libqca2-dev, libsane-dev, > libtiff4-dev, libgphoto2-2-dev, libchm-dev, libdjvulibre-dev, libxxf86vm-dev, > libqimageblitz-dev (>= 1:0.0.4-2), libexiv2-dev, libstreamanalyzer-dev (>= > 0.6.3), libstreams-dev (>= 0.6.3), libepub-dev, liblcms1-dev [...] > Toolchain package versions: libc6-dev_2.9-9 g++-4.3_4.3.3-8 gcc-4.3_4.3.3-8 > binutils_2.19.1-1 libstdc++6_4.3.3-8 libstdc++6-4.3-dev_4.3.3-8 [...] > cd libs/libksane/libksane && /usr/bin/g++ -DMAKE_KSANE_LIB -D_BSD_SOURCE > -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII > -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -g -O2 -g -Wall -O2 -Wnon-virtual-dtor > -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W > -Wpointer-arith -Wformat-security -fno-exceptions -fno-check-new -fno-common > -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden > -fvisibility-inlines-hidden -DNDEBUG -DQT_NO_DEBUG -fPIC -I. > -I../../../../libs/libksane/libksane -I../../../.. -I../../.. > -I/usr/include/KDE -I/usr/include/qt4/phonon -I/usr/include/qt4/QtXmlPatterns > -I/usr/include/qt4/QtWebKit -I/usr/include/qt4/QtHelp > -I/usr/include/qt4/QtAssistant -I/usr/include/qt4/QtDBus > -I/usr/include/qt4/QtTest -I/usr/include/qt4/QtUiTools > -I/usr/include/qt4/QtScript -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtXml > -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtNetwork > -I/usr/include/qt4/QtDesigner -I/usr/include/qt4/Qt3Support > -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt > -I/usr/share/qt4/mkspecs/default -I/usr/include/qt4 -D_GNU_SOURCE > -D_LARGEFILE64_SOURCE -o CMakeFiles/ksane.dir/sane_widget.o -c > ../../../../libs/libksane/libksane/sane_widget.cpp > ../../../../libs/libksane/libksane/sane_widget.cpp: In member function 'void > KSaneIface::KSaneWidget::startScan()': > ../../../../libs/libksane/libksane/sane_widget.cpp:1093: error: > 'SANE_STATUS_WARMING_UP' was not declared in this scope > ../../../../libs/libksane/libksane/sane_widget.cpp:1114: error: > 'SANE_STATUS_HW_LOCKED' was not declared in this scope > make[3]: *** [libs/libksane/libksane/CMakeFiles/ksane.dir/sane_widget.o] > Error 1 > make[3]: Leaving directory > `/build/buildd/kdegraphics-4.2.2/obj-x86_64-linux-gnu' > make[2]: *** [libs/libksane/libksane/CMakeFiles/ksane.dir/all] Error 2 > make[2]: Leaving directory > `/build/buildd/kdegraphics-4.2.2/obj-x86_64-linux-gnu' > make[1]: *** [all] Error 2 > make[1]: Leaving directory > `/build/buildd/kdegraphics-4.2.2/obj-x86_64-linux-gnu' > make: *** [debian/stamp-makefile-build] Error 2 > dpkg-buildpackage: failure: debian/rules build gave error exit status 2 A full build log can be found at: http://buildd.debian.org/build.php?arch=amd64&pkg=kdegraphics&ver=4:4.2.2-1+b1 Kurt -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523602: koffice: FTBFS: kis_image_magick_converter.cc:185: error: 'const struct _Image' has no member named 'generic_profiles'
Source: koffice Version: 1:1.6.3-7 Severity: serious Hi, Your package is failing to build with the following error: In file included from /build/buildd/koffice-1.6.3/./filters/krita/gmagick/kis_image_magick_converter.cc:44: /build/buildd/koffice-1.6.3/./krita/core/kis_layer.h:169: warning: type qualifiers ignored on function return type /build/buildd/koffice-1.6.3/./filters/krita/gmagick/kis_image_magick_converter.cc: In function 'void::setAnnotationsForImage(const Image*, KisImageSP)': /build/buildd/koffice-1.6.3/./filters/krita/gmagick/kis_image_magick_converter.cc:185: error: 'const struct _Image' has no member named 'generic_profiles' /build/buildd/koffice-1.6.3/./filters/krita/gmagick/kis_image_magick_converter.cc:189: error: 'const struct _Image' has no member named 'generic_profile' /build/buildd/koffice-1.6.3/./filters/krita/gmagick/kis_image_magick_converter.cc:189: error: 'const struct _Image' has no member named 'generic_profile' /build/buildd/koffice-1.6.3/./filters/krita/gmagick/kis_image_magick_converter.cc:191: error: 'const struct _Image' has no member named 'generic_profile' [...] Kurt -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#498903: krita: Can't import files with dcraw: non-numeric argument to -n
Package: krita Version: 1:1.6.3-7 Hi, When I try to open an raw file from my camera, I can get several error messages. Using the default settings, I always get: Error: Dcraw cannot load this image. Message: Non-numeric argument to "-n". If I turn on "Use camera raw colors, not sRGB", I get "-m" instead of "-n". I'm using dcraw 8.86-1. I can not find a version of dcraw that had an option of -n or -m that didn't take a numeric argument. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474586: libkcal2b: Contains duplicate timezone info.
Package: libkcal2b Version: 4:3.5.9-2 Severity: wishlist Hi, It seems that your package contains it's own data for timezones. I think it's best if it would support using the timezone information provided by system. This would allow us to change 1 package and all pacakges using timezone information could use that. In Debian we have the tzdata package for this. It seems this actually contains the same data as the kdepimlibs-data package. It also seems to be embedding a date in the name of the timezone. This causes problems in case the rules are updated and for instance an event was created using the old rules but by the time the event occurs the rules got changed. It would be better if the name of the timezone didn't contain any date. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474578: kdepimlibs-data: Contains timezone info
Package: kdepimlibs-data Version: 4:4.0.2-1 Severity: wishlist Hi, It seems that kdepimlibs-data contains it's own data for timezones. I think it's best if it would support using the timezone information provided by system. This would allow us to change 1 package and all pacakges using timezone information could use that. In Debian we have the tzdata package for this. It also seems to be embedding a date in the name of the timezone. This causes problems in case the rules are updated and for instance an event was created using the old rules but by the time the event occurs the rules got changed. It would be better if the name of the timezone didn't contain any date. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397073: konsole: not reading ~/.bashrc
On Mon, Nov 13, 2006 at 03:38:34PM -0700, Bruce Sass wrote:
>
> Kurt, please have a look at:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397073
Dear Mr. Sass,
Thank you for bringing this to my attention. But I don't see why you
need to contact me for this.
The package is group maintained, and alot of other people should already
be receiving your emails. And those people probably know alot more
about this than I do.
I would also like to point out that Sune works on KDE in general, and not
on konsole in specific. KDE is rather big, and you can't know
everything.
You should also be happy that Sune does put alot of time into Debian,
reading bug reports, trying to reproduce it, making suggestions on how
you can solve your problem and so on.
As part of the NM process I will be reviewing how he deals with bug
reports. The only thing I can say is that he's working hard on
making things better.
You seem to be confused to what "interactive" means. Basicly the shell
is interactive if you as user can type commands in it. This has nothing
to do with wether the program (or shell script) that is started by the
shell interacts with the user or not. In case a shell is started
with the "-c" option, it's non-interactive since it will start the
program, and when the program exits so will the shell. You can't type
new commands in the shell after the programs exited.
Anyway, you say it used to work, but it doesn't work anymore. I can see
a few reasons for this:
- Something in konsole changed;
- Something external to konsole changed;
- The way you use it has changed;
- Something else?
In any case it would be useful if you could describe what changed
between the point it worked and the point it stopped working.
Did you do a major upgrade of Debian or KDE? Do you know from what
version to what version? Since this seems to be the latest version, I
assume you have a recent installation, and you can probably use
/var/log/dpkg.log to find the version numbers.
Or you changed window manager, as you seem to mention in a later mail?
And this might be a bug (or feature) of a different WM that you see.
So, after looking a little, I found this code in
kdelibs/kdecore/kprocess.cpp:
if (d->useShell)
{
[...]
arglist[0] = d->shell.data();
arglist[1] = (char *) "-c";
arglist[2] = shellCmd.data();
arglist[3] = 0;
When I start a session, I also see a process with "bash -c
" with as child a "".
But I have no idea how it determises to use a shell or
not, but with the case I tried it atleast seems to be
using one. In your case it's probably also using bash,
and that should be easy enough to find out.
It's already been pointed out that starting bash with
-c won't read the .bashrc, so if you want those
environment variables you'll need some other way to set them.
Anyway, I think you misunderstand how things are supposed to work,
and the documentation probably needs to be worded better to avoid
confusion. But you don't seem to be happy about that.
If none of the suggestions work for you, I suggest you
file a (wishlist) bug for the option you like to see. (Or
change this bug to the wishlist bug.)
There might also be a bug in some software, but I'm currently not
conviced this is in konsole or KDE.
With kind regards,
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392797: libqt4-dev: Missing depends on libglib2.0-dev
Package: libqt4-dev Version: 4.2.0-1 Severity: serious Hi, Packages build depending on libqt4-dev are failing to build because QtCore.pc had "-lglib-2.0" in it. Please add a Depends on libglib2.0-dev. You could also move the "-lglib-2.0", and maybe the rest of the libraries from Libs to Libs.private. I also noticed that the file has this in it: -L/build/buildd/qt4-x11-4.2.0/lib You really don't want in the .pc files. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [P-a-s] Please enable %firebird2/amd64 to help unblock qt-x11-free.
On Fri, Mar 24, 2006 at 02:00:12PM -0500, Aaron M. Ucko wrote: > Greetings. > > As an amd64 user (though admittedly not an official porter), I have > been following the new official buildd's progress with some interest, > and observed a problem with the potential to block quite a few > packages: although the firebird2 source package rightly claims to > support amd64 (I just verified that 1.5.3.4870-3 builds without errors > on my system), Packages-arch-specific lists it as specific to > (hurd-)i386. Could you please bless it for amd64 as well? I've requested that myself like half an hour before your mail, and it was added within 10 minutes. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355099: Bug #355099: kdelibs FTBFS
On Fri, Mar 10, 2006 at 02:02:04PM +0100, Daniel Schepler wrote: > After some investigation of the failure of kdelibs to build, I found it > appears to be a bug in either libtool, ld, or the dynamic linker, so I'm > CC'ing the maintainers of those packages. The problem is that lt-meinproc is > getting linked with a NEEDED entry pointing to libkdecore.so because it > directly uses symbols from that library, which is indirectly brought in by > the -lkio argument, but the RPATH on the resulting binary only includes the > directory containing libkio.so. I think the commands you're talking about being issued here are: /bin/sh ../libtool --tag=CXX --mode=link g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -DDEBIAN_VERSION=4:3.5.1-3 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -L/usr/lib -L/usr/share/qt3/lib -L/usr/X11R6/lib -o meinproc meinproc.o xslt_pure.o libkbzipfilter_dummy.la -L/usr/lib -lxslt -lxml2 -lz -lm -L/usr/lib -lxml2 -lz -lm ../kio/libkio.la -lbz2 g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align-Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -DDEBIAN_VERSION=4:3.5.1-3 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -o .libs/meinproc meinproc.o xslt_pure.o -L/usr/lib -L/usr/share/qt3/lib -L/usr/X11R6/lib ./.libs/libkbzipfilter_dummy.a /usr/lib/libxslt.so /usr/lib/libxml2.so -lz -lm ../kio/.libs/libkio.so -lbz2 So basicly, there isn't a -lkdecore, while there should have been one. I consider this to be a bug in the package. The linker however adds in case it can detect it, as you seem to be aware of. See http://sourceware.org/ml/binutils/2005-09/msg00200.html for those who don't. As you say later in the mail adding kdecore to the link line solves this, and I think this should be done in any case. Looking at the result of an ldd on lt-meinproc I see: [...] libkdecore.so.4 => not found [...] libkdecore.so.4 => /usr/src/kdelibs-3.5.1/obj-x86_64-linux-gnu/kdecore/.libs/libkdecore.so.4 (0x2e6dc000) Where the first one comes from the executable itself, which doesn't have an rpath, and the second one comes from libkwalletclient.so.1 (thru libkio.so.4) > Then the dynamic linker can't find where > libkdecore.so is, despite the fact that libkio.so's RPATH includes the > directories containing its dependencies, and one of those libraries has the > RPATH needed for libkdecore.so. > So I can see a few different ways to fix this: > > * Make libtool include all indirect rpath's directly on the link command > line. > But I find this ugly, and in fact a step backwards from recent improvements, > and it really doesn't solve the general problem either. I've been pondering wether libtool should always add rpaths to libraries/binaries as long as they're not installed, but that has a few problems. One of them is, you'll always need to relink when you want to install it to remove the rpath's that you don't need. An other is that it's probably not very portable. One of the reasons I thought about this is #320698. > * Make the dynamic loader able to find libraries within rpath's from already > loaded libraries. But this doesn't totally solve the case outside libtool -- > what if that other library then gets relinked in such a way that it doesn't > indirectly include that rpath anymore? I think that 2 libraries with the same soname should be considered the same file. However, I think the problem is that in the executable (lt-meinproc) there is no rpath, so it can't find it at that time. Then later some other libraries get loaded, and one of them needs the same library again, but this time has an rpath. I think it's reasonable to expect it to fail. I think if it tried to load them in a different order, it would have worked, but I don't think it should. > * Make ld add the required directory to RPATH when it automatically adds a > NEEDED entry due to direct usage of symbols from the library involved. > Somewhat ugly, though. I already find it ugly that it adds the NEEDED by itself, please don't make it automaticly add RPATH's too. But if it wouldn't have added the NEEDED in the first place, you would have known that you needed to link to kdecore sooner, and wouldn't have this problem. I'm still for removing this feature from the linker. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344765: kdeedu: FTBFS: error: no matching function for call to 'KPassivePopup::show(QPoint)'
Package: kdeedu Version: 4:3.5.0-2 Severity: serious Tags: experimental Hi, Your package is failing to build with the following error: /build/buildd/kdeedu-3.5.0/build-tree/kdeedu-3.5.0/khangman/khangman/khangmanview.cpp:206: error: no matching function for call to 'KPassivePopup::show(QPoint)' /usr/include/kde/kpassivepopup.h:195: note: candidates are: virtual void KPassi vePopup::show() My first guess would be that you didn't change your build depends for kdelibs to require >= 4:3.5.0. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341614: qt-x11-free: FTBFS on amd64: amd64 not in arch list.
On Thu, Dec 01, 2005 at 03:30:12PM -0500, Christopher Martin wrote: > On December 1, 2005 15:14, you wrote: > > On Thu, Dec 01, 2005 at 02:09:31PM -0500, Christopher Martin wrote: > > > Argh, that my my fault. Given that amd64 is still separate from the > > > main archive, can you fix the problem for amd64 with an amd64-specific > > > update, or would you much rather have a new upload from us? > > > > We do not patch anything in our archive. I should get very > > convincing reasons to do it otherwise. (This also happens to > > be a required to a release candidate). > > > > I could do an NMU of this if you want, but I prefer not to. > > No, I'll make an upload to fix it later today. Sorry about the FUBAR. Thank you. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341614: qt-x11-free: FTBFS on amd64: amd64 not in arch list.
On Thu, Dec 01, 2005 at 02:09:31PM -0500, Christopher Martin wrote: > Argh, that my my fault. Given that amd64 is still separate from the main > archive, can you fix the problem for amd64 with an amd64-specific update, > or would you much rather have a new upload from us? We do not patch anything in our archive. I should get very convincing reasons to do it otherwise. (This also happens to be a required to a release candidate). I could do an NMU of this if you want, but I prefer not to. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341614: qt-x11-free: FTBFS on amd64: amd64 not in arch list.
Package: qt-x11-free Version: 3:3.3.5-2 Severity: important Hi, Your changelog said: * Build the InterBase plugin on amd64, now that firebird2 works there. But it seems you forgot to change the control file to say that libqt3-mt-ibase should get build on amd64 which results in the following error: dh_gencontrol -a dpkg-gencontrol: error: current build architecture amd64 does not appear in package's list (i386 hurd-i386 kfreebsd-i386 knetbsd-i386 netbsd-i386) dh_gencontrol: command returned error code 65280 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327618: libqt4-dev: Missing dependency
On Sun, Sep 11, 2005 at 08:52:51AM -0700, Brian Nelson wrote: > Kurt Roeckx <[EMAIL PROTECTED]> writes: > > > Your package has a QtSql.pc and Qt3Support.pc pkg-config file > > included. Packages using that fail to build because you're > > atleast missing a dependency on libmysqlclient14-dev, and looks > > like on libpq-dev too. Maybe some others? > > Well, it suggests libqt4-sql, which in turn suggests libmysqlclient-dev > and libpq-dev. However, that probably isn't strong enough; I should > probably just recommend them directly in libqt4-dev. > > I don't think a strong dependency is needed though, since most Qt apps > don't use the SQL module. Anything linking against either of those that is using pkg-config is going to have a build problem, because pgk-config is rather annoying about things like that. It really requires a Depends on those pacakges for now. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327159: Missing dependency on kdepim
reassign 327159 kdepim-dev retitle 327159 kdepim-dev: Missing dependency on kitchensync thanks > > This should dependencies kitchensync, not kdepim. kdepim is a > > meta package. > > OK. I've reassigned this bug to kdebluetooth. The bug was on the right package, it just was a missing dependency on the wrong package. kitchensync is also part of the kdepim source package. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327159: Missing dependency on kdepim
On Wed, Sep 07, 2005 at 04:23:55PM -0700, Matt Kraai wrote: > Package: kdepim-dev > Version: 4:3.4.2-1 > Severity: serious > > kdebluetooth fails to build because it cannot link against > /usr/lib/libkonnector.so and /usr/lib/libksync2.so. These symlinks, > provided by kdepim-dev, are present because kdebluetooth build-depends > on kdepim-dev, but the files that they point to are not present > because kdepim-dev does not depend on kdepim. This should dependencies kitchensync, not kdepim. kdepim is a meta package. ksync seems to be have an older version of the library? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327618: libqt4-dev: Missing dependency
Package: libqt4-dev Version: 4.0.1-1 Severity: serious Hi, Your package has a QtSql.pc and Qt3Support.pc pkg-config file included. Packages using that fail to build because you're atleast missing a dependency on libmysqlclient14-dev, and looks like on libpq-dev too. Maybe some others? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311958: kdebase: FTBFS: error making docs.
On Mon, Jun 06, 2005 at 01:21:05PM -0400, Christopher Martin wrote: > On June 5, 2005 15:30, Kurt Roeckx wrote: > > This a minimal sid chroot (only essential + build essential installed) > > with the following additional installed: > > apt-get install cdbs debhelper autotools-dev gawk gettext > > kdelibs4-dev/experimental dbus-qt-1-dev libldap2-dev libhal-dev > > libhal-storage-dev libncurses5-dev libpam0g-dev libpopt-dev > > libraw1394-dev libsensors-dev libsmbclient-dev libusb-dev libxtst-dev > > xutils xlibs-static-pic sharutils texinfo doxygen qt3-doc graphviz > > gsfonts-x11 kdelibs4=4:3.4.1-1 kdelibs-bin=4:3.4.1-1 > > libarts1-dev/experimental libarts1=1.4.1-1 libartsc0-dev=1.4.1-1 > > libartsc0=1.4.1-1 dbus-1-dev=0.23.4-1bindings0 dbus-1=0.23.4-1bindings0 > > What version is kdelibs-data? Was it upgraded to 3.4.1 as well? I ran the > above and it stayed at 3.3.2. Upgrading solved the problem. It probably stayed at 3.3.2. I try to build everything with only what is required from experimental thru the build dependencies, and the dependecies it has. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311958: kdebase: FTBFS: error making docs.
On Sun, Jun 05, 2005 at 01:51:24PM -0400, Christopher Martin wrote: > On June 4, 2005 07:17, Kurt Roeckx wrote: > > Package: kdebase > > Verison: 4:3.4.1-1 > > Severity: serious > > Tags: experimental > > > > Maybe this is a missing build dependency or something? > > Possibly, but I tried to reproduce this in a very minimal Sid chroot (arts > and kdelibs came from experimental, and dbus from our alioth repo, but > otherwise all Sid). It built without this problem, so I'm baffled. Are you > using any non-standard packages, aside from the obvious kde bits from > experimental, and dbus? This a minimal sid chroot (only essential + build essential installed) with the following additional installed: apt-get install cdbs debhelper autotools-dev gawk gettext kdelibs4-dev/experimental dbus-qt-1-dev libldap2-dev libhal-dev libhal-storage-dev libncurses5-dev libpam0g-dev libpopt-dev libraw1394-dev libsensors-dev libsmbclient-dev libusb-dev libxtst-dev xutils xlibs-static-pic sharutils texinfo doxygen qt3-doc graphviz gsfonts-x11 kdelibs4=4:3.4.1-1 kdelibs-bin=4:3.4.1-1 libarts1-dev/experimental libarts1=1.4.1-1 libartsc0-dev=1.4.1-1 libartsc0=1.4.1-1 dbus-1-dev=0.23.4-1bindings0 dbus-1=0.23.4-1bindings0 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311958: kdebase: FTBFS: error making docs.
Package: kdebase Verison: 4:3.4.1-1 Severity: serious Tags: experimental Hi, When building your package for experimental, I'm getting the following error: make[4]: Entering directory `/usr/src/kdebase-3.4.1/obj-i386-linux/doc/userguide' /usr/bin/meinproc --check --cache index.cache.bz2 /usr/src/kdebase-3.4.1/./doc/userguide/index.docbook control-center.docbook:59: parser error : Entity 'J.Hall' not defined &J.Hall; ^ control-center.docbook:60: parser error : Entity 'J.Hall.mail' not defined &J.Hall.mail; ^ control-center.docbook:199: parser error : Entity 'J.Hall' not defined &J.Hall; ^ [...] control-center.docbook:745: parser error : Entity 'J.Hall.mail' not defined &J.Hall.mail; ^ control-center.docbook:832: parser error : chunk is not well balanced ^ index.docbook:439: error: Failure to process entity control-center &control-center; ^ index.docbook:439: parser error : Entity 'control-center' not defined &control-center; ^ make[4]: *** [index.cache.bz2] Error 1 meinproc is from kdelibs-bin 3.4.1-1. Maybe this is a missing build dependency or something? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311712: kwifimanager: Does not have a versioned dependency on libmad0
Package: kwifimanager Version: 4:3.3.2-5 Severity: serious Tags: sarge-ignore Hi, Because of a bug in the libmad package (#310311) it lost it's shlibs and as a result you don't have a versioned dependency on libmad0 anymore. This could potentialy break partial upgrades. The release team has asked me to file this bug with the sarge-ignore tag: http://lists.debian.org/debian-release/2005/06/msg00031.html Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311710: kdelibs: Does not have a versioned dependency on libmad0
Package: kdelibs4 Version: 4:3.3.2-6.1 Severity: serious Tags: sarge-ignore Hi, Because of a bug in the libmad package (#310311) it lost it's shlibs and as a result you don't have a versioned dependency on libmad0 anymore. This could potentialy break partial upgrades. The release team has asked me to file this bug with the sarge-ignore tag: http://lists.debian.org/debian-release/2005/06/msg00031.html Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#282364: kdemultimedia: Builds depends on libtiff3g-dev in sarge.
Package: kdemultimedia Version: 4:3.2.2-1 Severity: serious Tags: sarge The package still didn't do the libtiff transition to libtiff4-dev in sarge. It's still build depending on libtiff3g-dev. There is a fixed version stuck in unstable. Kurt
Bug#282352: kdebase: Builds depends on libtiff3g-dev in sarge.
Package: kdebase Version: 4:3.2.2-1 Severity: serious Tags: sarge The package still didn't do the libtiff transition to libtiff4-dev in sarge. It's still build depending on libtiff3g-dev. There is a fixed version stuck in unstable. Kurt
Bug#282232: kdenetwork: Builds depends on libtiff3g-dev in sarge.
Package: kdenetwork Version: 4:3.2.2-1 Severity: serious Tags: sarge The package still didn't do the libtiff transition to libtiff4-dev in sarge. It's still build depending on libtiff3g-dev. There is a fixed version stuck in unstable. Kurt
Bug#278834: kdebindings: FTBFS: cp: cannot stat `debian/tmp/usr/lib/ruby/1.8/i386-linux/korundum.so.0.0.0': No such file or directory
Package: kdebindings Version: 4:3.3.0-2 Severity: serious The packaing is failing to build on all arches with the following error: dh_installman dh_install --list-missing cp: cannot stat `debian/tmp/usr/lib/ruby/1.8/i386-linux/korundum.so.0.0.0': No such file or directory dh_install: command returned error code 256 Kurt
