Re: Leaving Debian
Alejandro Exojo writes:
El Lunes, 4 de Octubre de 2004 09:37, Dominique Devriese escribió:
Anyway, it's been a real pleasure to work with you all, thanks for
all your time and valuable help.
Thanks all, for your kind words...
By the way, you wrote some HTML documents related to Debian/KDE that
I've been searching some weeks ago, but I didn't found them. There
were in http://www.kalyxo.org/~domi/. One was related to debugging
(it mentioned your debugging packages), and I'm interested in
re-reading again, and maybe posting it in the wiki, so they can be
easily mantained.
If you can send them, or tell me a new URL, it will be great.
I'm attaching them.
Pierre Habouzit writes:
well it's really a pity you left ... but I may be interested in
maintaining kdebindings ...
I just finisehd my NM process (well I'm waiting for the DAM approval
to be correct). so I'll need sponsoring, but I think I can handle
it.
Riku Voipio writes:
Adeodato writes:
I'm considering adopting the package if nobody more qualified steps
in. currently, I'm about to prepare 3.3 packages to see if I'm
ready. if you're thinking about adopting kdebindings
please do. I can still sponsor.
I'm glad people are interested in maintaining kdebindings, I hope you
and Adeodato can find a good way to cooperate. kdebindings is a very
cool package to have in Debian.
For the people who are interested in working on the packages, I'm also
attaching two scripts I use for automating the packaging of a new
upstream release.
cheers
domi
A page about my debian kde packages for user..
Title: Unofficial Debian KDE Packages with debugging support
Unofficial Debian KDE Packages with debugging support
I have made available unofficial Debian KDE packages that have
been compiled with debugging support. This document should answer
any questions about installing and uninstalling them.
Installing
Installing the packages is as easy as adding the following line to
your /etc/apt/sources.list:
deb http://www.kde-debian.org/~domi/debian-kde-debug/ unstable main
After that, execute the command "apt-get update && apt-get
upgrade" as root from a terminal.
Uninstalling
The packages' version numbers have been chosen such that they are
considered newer than the current official Debian KDE packages
from unstable, but older than any future versions that will
appear. This means that if you wait for the next update of the
latter packages, the old debugging packages will be uninstalled
automatically. If you want to remove them earlier than that, I
recommend removing the debugging packages with apt-get remove,
then removing the above line from your sources.list, next updating
and reinstalling KDE.
Dominique Devriese
Last modified: Tue Jan 6 17:11:13 CET 2004
A page for debian users who want to file a bug report on a kde crash.
Title: Debugging a KDE crash
Debugging a KDE crash
Introduction
In order for the Debian and KDE developers to be able to fix a
crash in a KDE program, they need a lot of information about it.
This document aims to describe how to get this information.
Please send all this information in a bug report, or if asked,
reply to the email, with an email containing all this
information.
Basic information
The first thing to do is to gather basic information about the
crash. Exactly what were you doing at the moment of the crash ?
Can you reproduce the crash ( i.e. if you do the same thing again,
does it crash again ? ). Also you should provide us with
information about your system. What version of the Debian KDE
packages were you running at the moment of the crash ? Have you
perhaps ever compiled separate Qt or KDE versions yourself, that
are still installed somewhere ? etc.
The Debian KDE debug packages
In order to get more information, you need to install a version
of the KDE packages that is compiled with support for debugging.
I have written a separate
document about how to do this.
Getting a backtrace
When a KDE program crashes, most of the time, you see a dialog
appear saying what happened and how. There, you can select the
tab "backtrace". You'll see that when running the Debian KDE
debug packages, it'll contain a lot more useful information than
otherwise. Please include the backtrace in your mail. Also, in
the crash dialog will be mentioned what kind of "signal" caused
the crash. Please mention this in your mail. Possible values for
this are "SIGSEGV", "SIGABRT", "SIGALRM" etc.
Valgrind: great memory problem debugger
If you are running an i386 machine ( this means, a "normal pc",
a "pentium I, II, III, or IV", an AMD "Athlon, Duron"
Leaving Debian
Hi, I have recently decided that I'm going to spend less time on computer projects in the coming year. I therefore no longer intend to maintain kdebindings. It's too bad I can't leave the package in someone's hands, but I don't know anyone who would like to take it. Anyway, it's been a real pleasure to work with you all, thanks for all your time and valuable help. About the practicalities: Riku ( or someone else ): could you upload a version of kdebindings with maintainer set to QA ? I still don't have upload rights Martin: Can you cancel my debian maintainer application ? I'll be filing a O: bug directly... cheers domi
Re: kdebindings for woody?
Matej Cepl writes: On Sunday 29 of August 2004 16:32, Kevin Krammer wrote: I guess it is just a lot of work to do this correctly and only very few people might need it. Well, I guess that at least scripting of KDE would be very helpful to everybody (KJS, Python, and Perl). myself with all Java-related stuff, just KJS and Python). I will upload all packages (except for huge .orig.tar.gz -- you can use the one from testing) to http://www.ceplovi.cz/matej/progs/debian/. Very nice! After two days of work, I have to admit total failure. The package is such a mess, that I do not know how could anybody make it compile anywhere. I did not manage to make kjscmd which would actually run nor could Python find the libraries. I may work on this sometimes in the future, but now I have to get to the real work. I would be interested to know what you mean by the package is a mess. It builds find in a Debian unstable or testing chroot. Furthermore, I have my doubts about the usefulness of a backport to woody when sarge is about to be released.. cheers domi
Re: KDE 3.3.0 Status Update
Chris Cheney writes: As everyone is aware by now I uploaded my KDE 3.3.0 debs last night. If anyone needs help updating their packages please let me know if you would like me to help. kdebindings I'm just home from a week of holidays. The updates for kdebindings 3.3 are in KDE CVS already, but some testing and polishing is probably still needed. Not sure when I'll have time to do so. Expect something between a few days and a month. cheers domi
KDE_3_3_BRANCH: kdebindings/debian
CVS commit by domi: make it build M +1 -1 control 1.8.2.2 --- kdebindings/debian/control #1.8.2.1:1.8.2.2 @@ -1,4 +1,4 @@ Source: kdebindings -Build-Depends: binutils-dev, debhelper ( 4.0.0), gawk, gettext, gij, gcj, libgcj4-dev, fastjar, kdelibs4-dev (= 4:3.2.92-1), libglib1.2-dev, libgtk1.2-dev, python2.3-dev, perl (= 5.6.0-16), libqt3-compat-headers (= 3:3.3.2-0pre2), sharutils +Build-Depends: binutils-dev, debhelper ( 4.0.0), gawk, gettext, gij, gcj, libgcj4-dev, fastjar, kdelibs4-dev (= 4:3.2.92-1), libglib1.2-dev, libgtk1.2-dev, python2.3-dev, perl (= 5.6.0-16), libqt3-compat-headers (= 3:3.3.2-0pre2), sharutils, ruby Section: devel Priority: optional
kdebindings/debian
CVS commit by domi: forward port: make it build M +1 -1 control 1.12 --- kdebindings/debian/control #1.11:1.12 @@ -1,4 +1,4 @@ Source: kdebindings -Build-Depends: binutils-dev, debhelper ( 4.0.0), gawk, gettext, gij, gcj, libgcj4-dev, fastjar, kdelibs4-dev (= 4:3.2.92-1), libglib1.2-dev, libgtk1.2-dev, python2.3-dev, perl (= 5.6.0-16), libqt3-compat-headers (= 3:3.3.2-0pre2), sharutils +Build-Depends: binutils-dev, debhelper ( 4.0.0), gawk, gettext, gij, gcj, libgcj4-dev, fastjar, kdelibs4-dev (= 4:3.2.92-1), libglib1.2-dev, libgtk1.2-dev, python2.3-dev, perl (= 5.6.0-16), libqt3-compat-headers (= 3:3.3.2-0pre2), sharutils, ruby Section: devel Priority: optional
KDE_3_3_BRANCH: kdebindings/debian
CVS commit by domi: backport the KDE 3.3 updates Alibkorundum0-ruby1.8.docs 1.2.2.1 Alibkorundum0-ruby1.8.examples 1.1.2.1 Alibkorundum0-ruby1.8.install 1.1.2.1 Alibkorundum0-ruby1.8.manpages 1.1.2.1 Alibqt0-ruby1.8.docs 1.1.2.1 Alibqt0-ruby1.8.examples 1.1.2.1 Alibqt0-ruby1.8.install 1.1.2.1 Alibqt0-ruby1.8.manpages 1.1.2.1 Alibsmokekde-dev.install 1.1.2.1 Alibsmokekde1.install 1.1.2.1 Alocal/krubyinit.1 1.1.2.1 Alocal/qtrubyinit.1 1.1.2.1 Alocal/rbkdeapi.1 1.1.2.1 Alocal/rbkdesh.1 1.1.2.1 Alocal/rbqtapi.1 1.1.2.1 Alocal/rbqtsh.1 1.1.2.1 Alocal/rbuic.1 1.1.2.1 Apatches/021-dont-install-example-kjsembed-plugins.diff 1.1.2.1 Apatches/023-dont-install-jsaccess.diff 1.1.2.1 Apatches/024-dont-install-javalib-test-program.diff 1.1.2.1 Apatches/025-dont-install-koala-test-program.diff 1.1.2.1 Apatches/026-install-qtruby-and-korundum-in-usr.diff 1.1.2.1 Apatches/027-fix-dcopjava-deps.diff 1.2.2.1 Apatches/028-make-cmdline.js-executable.diff 1.1.2.1 Apatches/029-ruby1.8-not-just-ruby.diff 1.1.2.1 M +13 -2 changelog 1.7.2.1 M +59 -7 control 1.8.2.1 M +1 -0 kjscmd.install 1.3.2.1 M +4 -0 libkjsembed1.install 1.3.2.1 M +1 -1 libsmokeqt1.install 1.3.2.1 M +24 -30rules 1.5.2.1 Rkjscmd.manpages 1.2 Rlocal/kjscmd.1 1.2
Bug#263897: kdelibs4-dev 4:3.2.92-1 needs a depends on libidn11-dev
Package: kdelibs4-dev Version: 4:3.2.92-1 Severity: normal In short: libkdeui and other libs link against libidn11, so the libidn.la file is needed when linking against libkdeui, so libidn11 needs to be there for compiling all kde apps, so kdelibs4-dev needs a depends on libidn11-dev. thanks domi -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686 Locale: LANG=nl, LC_CTYPE=nl (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages kdelibs4-dev depends on: ii kdelibs-bin4:3.2.92-1KDE core binaries ii kdelibs4 4:3.2.92-1KDE core libraries ii libart-2.0-dev 2.3.16-6 Library of functions for 2D graphi ii libarts1-dev 1.2.92-1 aRts Sound system (development fil ii libcupsys2-dev 1.1.20final+rc1-5 Common UNIX Printing System(tm) - ii libfam-dev 2.7.0-5 client library to control the FAM ii libpcre3-dev 4.5-1.1 Perl 5 Compatible Regular Expressi ii libssl-dev 0.9.7d-5 SSL development libraries, header ii libxml2-utils 2.6.11-3 XML utilities ii libxrender-dev 0.8.3-7 X Rendering Extension client libra -- no debconf information
kdebindings/debian
CVS commit by domi: further kde 3.3 updates Alibkorundum0-ruby1.8.docs 1.1 Alibkorundum0-ruby1.8.examples 1.1 Alibkorundum0-ruby1.8.install 1.1 Alibqt0-ruby1.8.docs 1.1 Alibqt0-ruby1.8.examples 1.1 Alibqt0-ruby1.8.install 1.1 Alibsmokekde-dev.install 1.1 Alibsmokekde1.install 1.1 Apatches/021-dont-install-example-kjsembed-plugins.diff 1.1 Apatches/022-dont-install-sip-files.diff 1.1 Apatches/023-dont-install-jsaccess.diff 1.1 Apatches/024-dont-install-javalib-test-program.diff 1.1 Apatches/025-dont-install-koala-test-program.diff 1.1 Apatches/026-install-qtruby-and-korundum-in-usr.diff 1.1 Apatches/027-fix-dcopjava-deps.diff 1.1 M +13 -2 changelog 1.8 M +47 -5 control 1.9 M +1 -0 kjscmd.install 1.4 M +4 -0 libkjsembed1.install 1.4 M +1 -1 libsmokeqt1.install 1.4 M +22 -28rules 1.6 Rkjscmd.manpages 1.2 Rlocal/kjscmd.1 1.2
kdebindings/debian/patches
CVS commit by domi: no longer necessary: we don't build the python stuff, since it's already in Debian from separate packages R022-dont-install-sip-files.diff 1.1
kdebindings/debian/patches
CVS commit by domi: make it apply M +3 -3 027-fix-dcopjava-deps.diff 1.2 --- kdebindings/debian/patches/027-fix-dcopjava-deps.diff #1.1:1.2 @@ -1,9 +1,9 @@ -Index: dcopjava/binding/Makefile.am +Index: kdebindings/dcopjava/binding/Makefile.am === RCS file: /home/kde/kdebindings/dcopjava/binding/Makefile.am,v retrieving revision 1.3.8.2 diff -u -r1.3.8.2 Makefile.am dcopjava/binding/Makefile.am10 May 2004 15:18:13 - 1.3.8.2 -+++ dcopjava/binding/Makefile.am5 Aug 2004 19:12:20 - +--- kdebindings/dcopjava/binding/Makefile.am10 May 2004 15:18:13 - 1.3.8.2 kdebindings/dcopjava/binding/Makefile.am5 Aug 2004 19:12:20 - @@ -6,10 +6,13 @@
pkg-kde: commit - rev 147 - in trunk/packages/kdebindings/debian: . local patches
Author: domi-guest
Date: 2004-08-05 14:45:51 -0600 (Thu, 05 Aug 2004)
New Revision: 147
Added:
trunk/packages/kdebindings/debian/libkorundum0-ruby1.8.docs
trunk/packages/kdebindings/debian/libkorundum0-ruby1.8.examples
trunk/packages/kdebindings/debian/libkorundum0-ruby1.8.install
trunk/packages/kdebindings/debian/libqt0-ruby1.8.docs
trunk/packages/kdebindings/debian/libqt0-ruby1.8.examples
trunk/packages/kdebindings/debian/libqt0-ruby1.8.install
trunk/packages/kdebindings/debian/libsmokekde-dev.install
trunk/packages/kdebindings/debian/libsmokekde1.install
trunk/packages/kdebindings/debian/patches/021-dont-install-example-kjsembed-plugins.diff
trunk/packages/kdebindings/debian/patches/023-dont-install-jsaccess.diff
trunk/packages/kdebindings/debian/patches/024-dont-install-javalib-test-program.diff
trunk/packages/kdebindings/debian/patches/025-dont-install-koala-test-program.diff
trunk/packages/kdebindings/debian/patches/026-install-qtruby-and-korundum-in-usr.diff
trunk/packages/kdebindings/debian/patches/027-fix-dcopjava-deps.diff
Removed:
trunk/packages/kdebindings/debian/kjscmd.manpages
trunk/packages/kdebindings/debian/libkdec1.docs
trunk/packages/kdebindings/debian/libkdec1.install
trunk/packages/kdebindings/debian/libqtc1.install
trunk/packages/kdebindings/debian/local/kjscmd.1
trunk/packages/kdebindings/debian/patches/013-qtc_clib_qtc_Makefile.am-noqaccessible.diff
trunk/packages/kdebindings/debian/patches/019-libqtjavasupport_la.diff
trunk/packages/kdebindings/debian/patches/020-cleanjarfiles.diff
Modified:
trunk/packages/kdebindings/debian/changelog
trunk/packages/kdebindings/debian/control
trunk/packages/kdebindings/debian/kjscmd.install
trunk/packages/kdebindings/debian/libkjsembed1.install
trunk/packages/kdebindings/debian/libsmokeqt1.install
trunk/packages/kdebindings/debian/patches/017-install-jnilibs-in-lib-jni.diff
trunk/packages/kdebindings/debian/rules
Log:
updates for KDE 3.3
Modified: trunk/packages/kdebindings/debian/changelog
===
--- trunk/packages/kdebindings/debian/changelog 2004-08-02 23:44:53 UTC (rev
146)
+++ trunk/packages/kdebindings/debian/changelog 2004-08-05 20:45:51 UTC (rev
147)
@@ -1,3 +1,24 @@
+kdebindings (4:3.2.92-1) unstable; urgency=low
+
+ * New upstream version.
+ * debian/patches/013-qtc_clib_qtc_Makefile.am-noqaccessible.diff,
+debian/patches/019-libqtjavasupport_la.diff,
+debian/patches/020-cleanjarfiles.diff: Accepted upstream, removed.
+ * debian/patches/017-install-jnilibs-in-lib-jni.diff: updated.
+ * debian/control: made libqt3-java suggest juic.
+ * debian/changelog: removed the obsolete libkdec1 and libqtc1 packages.
+ * debian/local/kjscmd.1, debian/kjscmd.manpages: removed kjscmd.1 which
+was accepted upstream.
+ * debian/libkjsembed1.install: install the qprocess kjsembed plugin.
+ * debian/rules: disable the python directory, as sip, pyqt and
+pykde are all packaged in Debian already.
+ * debian/control: added the libsmokekde1, libsmokekde-dev,
+libkorundum-ruby1.8 and libqtruby-ruby1.8 packages because of upstream
+additions.
+ * debian/control: fix libsmokeqt-dev to depend on libsmokeqt1
+
+ -- Dominique Devriese [EMAIL PROTECTED] Thu, 5 Aug 2004 21:08:08 +0200
+
kdebindings (4:3.2.3-1) unstable; urgency=low
* New upstream version.
Modified: trunk/packages/kdebindings/debian/control
===
--- trunk/packages/kdebindings/debian/control 2004-08-02 23:44:53 UTC (rev
146)
+++ trunk/packages/kdebindings/debian/control 2004-08-05 20:45:51 UTC (rev
147)
@@ -1,5 +1,5 @@
Source: kdebindings
-Build-Depends: binutils-dev, debhelper ( 4.0.0), gawk, gettext, gij, gcj,
libgcj4-dev, fastjar, kdelibs4-dev (= 4:3.1.4), libglib1.2-dev, libgtk1.2-dev,
python2.3-dev, perl (= 5.6.0-16), libqt3-compat-headers, sharutils
+Build-Depends: binutils-dev, debhelper ( 4.0.0), gawk, gettext, gij, gcj,
libgcj4-dev, fastjar, kdelibs4-dev (= 4:3.2.92-1), libglib1.2-dev,
libgtk1.2-dev, python2.3-dev, perl (= 5.6.0-16), libqt3-compat-headers (=
3:3.3.2-0pre2), sharutils
Section: devel
Priority: optional
Maintainer: Debian Qt/KDE Maintainers debian-qt-kde@lists.debian.org
@@ -16,28 +16,6 @@
.
This package is part of the official KDE bindings module.
-Package: libqtc1
-Architecture: any
-Section: libs
-Depends: ${shlibs:Depends}
-Description: Qt bindings for C
- This package contains the shared libraries necessary to run programs
- linked with the C bindings to Trolltech's Qt library. Qt is a very popular
- GUI toolkit, used by the KDE desktop environment.
- .
- This package is part of the official KDE bindings module.
-
-Package: libkdec1
-Architecture: any
-Section: libs
-Depends: ${shlibs:Depends}
-Description: kdelibs bindings for C
- This package contains the shared libraries necessary to run
kdebindings/debian
CVS commit by domi: some updates for 3.3 already, still quite some more to come M +10 -0 changelog 1.7 M +1 -23 control 1.8 M +0 -1 kjscmd.install 1.3 M +26 -24rules 1.5 M +11 -10patches/017-install-jnilibs-in-lib-jni.diff 1.3 Rlibkdec1.docs 1.2 Rlibkdec1.install 1.3 Rlibqtc1.install 1.3 Rpatches/013-qtc_clib_qtc_Makefile.am-noqaccessible.diff 1.2 Rpatches/019-libqtjavasupport_la.diff 1.2 Rpatches/020-cleanjarfiles.diff 1.2
Bug#261798: kdelibs-data 3.2.92-1 needs a replaces: for korganizer = 3.2.2-2 because of the knewstuff move to kdelibs
Package: kdelibs-data Version: 4:3.2.3-3debug1 Severity: important Hi, When installing kdelibs-data 3.2.92-1 on a system with korganizer 3.2.2-2 installed, I get the following errors: Voorbereiden om kdelibs-data 4:3.2.3-3debug1 te vervangen (met .../kdelibs-data_4%3a3.2.92-1_all.deb) ... Uitpakken van vervangende kdelibs-data ... dpkg: fout bij afhandelen van /var/cache/apt/archives/kdelibs-data_4%3a3.2.92-1_all.deb (--unpack): poging tot overschrijven van `/usr/share/apps/knewstuff/types', wat ook in pakket korganizer zit dpkg-deb: subproces paste werd gedood door signaal (Gebroken pijp) Voorbereiden om kdelibs4 4:3.2.3-3debug1 te vervangen (met .../kdelibs4_4%3a3.2.92-1_i386.deb) ... Uitpakken van vervangende kdelibs4 ... dpkg: fout bij afhandelen van /var/cache/apt/archives/kdelibs4_4%3a3.2.92-1_i386.deb (--unpack): poging tot overschrijven van `/usr/lib/libknewstuff.so.1.0.0', wat ook in pakket korganizer zit dpkg-deb: subproces paste werd gedood door signaal (Gebroken pijp) Voorbereiden om kdelibs-bin 4:3.2.3-3debug1 te vervangen (met .../kdelibs-bin_4%3a3.2.92-1_i386.deb) ... Uitpakken van vervangende kdelibs-bin ... dpkg: fout bij afhandelen van /var/cache/apt/archives/kdelibs-bin_4%3a3.2.92-1_i386.deb (--unpack): poging tot overschrijven van `/etc/kde3/khotnewstuffrc', wat ook in pakket korganizer zit dpkg-deb: subproces paste werd gedood door signaal (Gebroken pijp) Selecteren van voorheen niet geselecteerd pakket kdelibs4-dev. Uitpakken van kdelibs4-dev (uit .../kdelibs4-dev_4%3a3.2.92-1_i386.deb) ... Fouten gevonden tijdens behandelen van: /var/cache/apt/archives/kdelibs-data_4%3a3.2.92-1_all.deb /var/cache/apt/archives/kdelibs4_4%3a3.2.92-1_i386.deb /var/cache/apt/archives/kdelibs-bin_4%3a3.2.92-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) This is clearly a missing replaces line in kdelibs against korganizer. The KNewStuff lib was recently moved from kdepim to kdelibs. thanks domi -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686 Locale: LANG=nl, LC_CTYPE=nl (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages kdelibs-data depends on: ii hicolor-icon-theme0.5-3 Default fallback theme for Freedes -- no debconf information
Bug#261809: kdelibs-bin 3.2.92 needs a replaces for kcontrol = 3.2.3-3 for /usr/bin/fileshareset
Package: kdelibs-bin Version: 4:3.2.3-3debug1 Severity: important When installing kdelibs 3.2.92 on a system with kcontrol 3.2.3-3 installed, I get the following error: Voorbereiden om kdelibs-data 4:3.2.3-3debug1 te vervangen (met .../kdelibs-data_4%3a3.2.92-1_all.deb) ... Uitpakken van vervangende kdelibs-data ... dpkg: fout bij afhandelen van /var/cache/apt/archives/kdelibs-data_4%3a3.2.92-1_all.deb (--unpack): poging tot overschrijven van `/usr/share/icons/crystalsvg/128x128/apps/password.png', wat ook in pakket kcontrol zit dpkg-deb: subproces paste werd gedood door signaal (Gebroken pijp) Voorbereiden om kdelibs4 4:3.2.3-3debug1 te vervangen (met .../kdelibs4_4%3a3.2.92-1_i386.deb) ... Uitpakken van vervangende kdelibs4 ... Voorbereiden om kdelibs-bin 4:3.2.3-3debug1 te vervangen (met .../kdelibs-bin_4%3a3.2.92-1_i386.deb) ... Uitpakken van vervangende kdelibs-bin ... dpkg: fout bij afhandelen van /var/cache/apt/archives/kdelibs-bin_4%3a3.2.92-1_i386.deb (--unpack): poging tot overschrijven van `/usr/bin/fileshareset', wat ook in pakket kcontrol zit dpkg-deb: subproces paste werd gedood door signaal (Gebroken pijp) Selecteren van voorheen niet geselecteerd pakket kdelibs4-dev. Uitpakken van kdelibs4-dev (uit .../kdelibs4-dev_4%3a3.2.92-1_i386.deb) ... Fouten gevonden tijdens behandelen van: /var/cache/apt/archives/kdelibs-data_4%3a3.2.92-1_all.deb /var/cache/apt/archives/kdelibs-bin_4%3a3.2.92-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) cheers domi -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686 Locale: LANG=nl, LC_CTYPE=nl (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages kdelibs-bin depends on: pn kdelibs4 Not found. ii libart-2.0-2 2.3.16-6 Library of functions for 2D graphi ii libbz2-1.0 1.0.2-1 A high-quality block-sorting file ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libcupsys2-gnutls101.1.20final+rc1-3 Common UNIX Printing System(tm) - ii libfam0c1022.7.0-5 client library to control the FAM ii libgcc11:3.4.1-3 GCC support library ii libice64.3.0.dfsg.1-6Inter-Client Exchange library ii libpng12-0 1.2.5.0-6 PNG library - runtime ii libqt3c102-mt 3:3.3.2-0pre2 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0.dfsg.1-6X Window System Session Management ii libstdc++5 1:3.3.4-5 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-6X Window System protocol client li ii libxext6 4.3.0.dfsg.1-6X Window System miscellaneous exte ii libxml22.6.11-2 GNOME XML library ii libxrender10.8.3-7 X Rendering Extension client libra ii libxslt1.1 1.1.8-2 XSLT processing library - runtime ii menu-xdg 0.1 freedesktop.org menu compliant win ii netpbm 2:10.0-4 Graphics conversion tools ii python 2.3.4-1 An interactive high-level object-o ii xlibs 4.3.0.dfsg.1-6X Window System client libraries m ii zlib1g 1:1.2.1.1-5 compression library - runtime -- no debconf information
Bug#261810: kdelibs-data 3.2.92 needs replaces for kcontrol = 3.2.3-2 for /usr/share/icons/crystalsvg/128x128/apps/password.png
Package: kdelibs-data Version: 4:3.2.92-1 Severity: important When installing kdelibs-data 3.2.92-1 on a system with kcontrol 3.2.3-1 installed, I get the following error: Voorbereiden om kdelibs-data 4:3.2.3-3debug1 te vervangen (met .../kdelibs-data_4%3a3.2.92-1_all.deb) ... Uitpakken van vervangende kdelibs-data ... dpkg: fout bij afhandelen van /var/cache/apt/archives/kdelibs-data_4%3a3.2.92-1_all.deb (--unpack): poging tot overschrijven van `/usr/share/icons/crystalsvg/128x128/apps/password.png', wat ook in pakket kcontrol zit dpkg-deb: subproces paste werd gedood door signaal (Gebroken pijp) Voorbereiden om kdelibs4 4:3.2.3-3debug1 te vervangen (met .../kdelibs4_4%3a3.2.92-1_i386.deb) ... Uitpakken van vervangende kdelibs4 ... Voorbereiden om kdelibs-bin 4:3.2.3-3debug1 te vervangen (met .../kdelibs-bin_4%3a3.2.92-1_i386.deb) ... Uitpakken van vervangende kdelibs-bin ... dpkg: fout bij afhandelen van /var/cache/apt/archives/kdelibs-bin_4%3a3.2.92-1_i386.deb (--unpack): poging tot overschrijven van `/usr/bin/fileshareset', wat ook in pakket kcontrol zit dpkg-deb: subproces paste werd gedood door signaal (Gebroken pijp) Selecteren van voorheen niet geselecteerd pakket kdelibs4-dev. Uitpakken van kdelibs4-dev (uit .../kdelibs4-dev_4%3a3.2.92-1_i386.deb) ... Fouten gevonden tijdens behandelen van: /var/cache/apt/archives/kdelibs-data_4%3a3.2.92-1_all.deb /var/cache/apt/archives/kdelibs-bin_4%3a3.2.92-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) thanks domi -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686 Locale: LANG=nl, LC_CTYPE=nl (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages kdelibs-data depends on: ii hicolor-icon-theme0.5-3 Default fallback theme for Freedes -- no debconf information
kdebindings/debian
CVS commit by domi: fast forward from 3_2_BRANCH, doesn't work yet M +117 -18 changelog 1.6 M +1 -0 compat 1.2 M +65 -78control 1.7 M +68 -10copyright 1.3 M +6 -0 juic.install 1.2 M +1 -0 juic.manpages 1.2 M +3 -0 kjscmd.install 1.2 M +1 -0 kjscmd.manpages 1.2 M +6 -0 kjscmd.menu 1.2 M +2 -0 konqueror-kjsembed-plugin.install 1.2 M +3 -4 libdcop-perl.install 1.3 M +1 -0 libdcop3-java-dev.manpages 1.2 M +1 -4 libdcop3-java.install 1.3 M +2 -2 libdcop3-jni.install 1.3 M +12 -0 libkde3-java.README.Debian 1.2 M +3 -0 libkde3-java.docs 1.2 M +2 -0 libkde3-java.examples 1.2 M +1 -2 libkde3-java.install 1.3 M +4 -4 libkde3-jni.install 1.3 M +1 -3 libkdec1.install 1.3 M +8 -6 libkjsembed-dev.install 1.3 M +4 -1 libkjsembed1.install 1.3 M +30 -0 libqt3-java.README.Debian 1.2 M +4 -0 libqt3-java.examples 1.2 M +8 -1 libqt3-java.install 1.3 M +6 -4 libqt3-jni.install 1.3 M +0 -2 libqtc1.install 1.3 M +1 -2 libsmokeqt1.install 1.3 M +0 -1 python-dcop.install 1.3 M +91 -41rules 1.4 M +28 -0 local/dcopidl2java.1 1.2 M +39 -0 local/juic.1 1.2 M +24 -0 local/kjscmd.1 1.2 M +16 -0 patches/002-am-maintainer-mode.diff 1.2 M +15 -0 patches/011-kdejava_koala_org_kde_koala_Makefile.am-encoding.diff 1.2 M +13 -0 patches/012-dcoppython_lib_Makefile.am-sitepackages.diff 1.2 M +16 -0 patches/013-qtc_clib_qtc_Makefile.am-noqaccessible.diff 1.2 M +30 -0 patches/017-install-jnilibs-in-lib-jni.diff 1.2 M +17 -0 patches/018-juic-uixsldir.diff 1.2 M +34 -0 patches/019-libqtjavasupport_la.diff 1.2 M +32 -0 patches/020-cleanjarfiles.diff 1.2 RTODO 1.2 Rdcopjava.install 1.2 Rdcopperl.install 1.2 Rdcoppython.install 1.2 Rdirs 1.3 Rkalyptus.install 1.2 Rkdejava.install 1.2 Rkmozilla.install 1.2 Rlibdcopc-dev.install 1.2 Rlibdcopc1.install 1.2 Rlibkdec-dev.install 1.2 Rlibkdexparts-dev.install 1.2 Rlibkdexparts1.install 1.2 Rlibqt3-java-doc.install 1.2 Rlibqtc-dev.install 1.2 Rpython-dcop.override 1.2 Rqtjava.install 1.2
Bug#253127: kdecore (KIconLoader): WARNING: Icon directory foo group bar is not valid
Phil Edwards writes: The patch only downgrades the severity of the diagnostic. That is not true. The debugging output is disabled in non-debug builds like debian's build, and the patch would thus make the output go away. I'd still like to know whst an end-user like me can do to avoid /hundreds/ of these useless messages every time a KDE program is run, especially if there's not going to be another KDE release after the current 3.2.3, which doesn't have the patch. See adeodato's reply. You could also have edited kdebugrc yourself or have changed the theme description file from the hicolor-icon-theme stuff... What makes sn icon directory group not valid? For reference, the cause of this bug is that the authors of hicolor-icon-theme have taken the liberty to invent group types that kde did not expect. See one of the three bugs that have been merged with this one, the one I first filed against hicolor-icon-theme, but which was later reassigned and merged here. cheers domi
Re: KDE Styles broken in sarge
Ian Eure writes: I just updated my sarge desktop today, and I can only select the built-in QT styles now. (CDE, MS Windows 9x, Motif, Motif Plus, Platinum SGI) There were some QT updates when I updated this morning, but I didn't pay too much attention to what got replaced. I've purged my system of old (non- c102) QT packages, and reinstalled kdelibs4. When I ldd the KDE styles (in /usr/lib/kde3/plugins/styles), I don't see any broken library dependencies. Anyone else seeing this? Anyone know how to fix it? This is a known problem caused by an incompatibility between the kdelibs and qt version in testing. It can be fixed by either downgrading qt or upgrading kdelibs. cheers domi
Bug#257588: kdelibs: Please provide kdelibs4-dbg
Alejandro Exojo writes: El Domingo, 4 de Julio de 2004 16:23, Ben Burton escribió: Hi. Having just spent a day chasing a rather nasty kbear bug deep through the internals of kdelibs, it seems to be that it would be helpful for KDE developers to be able to install a kdelibs with debug symbols (rather than having to rebuild kdelibs from sources, as I had to do). FWIW, I suppose you ask for a official kdelibs package, but if you want to gain some time, you can use dominique's packages: http://www.kalyxo.org/~domi/debian-kde-debug.html Note that I'll be uploading kdelibs-3.2.3-2debug1 soon.. cheers domi
Bug#243375: kdelibs-bin: menu-method freedesktop should set the Generic Name Field to longtitle instead of title
Bill Allombert writes: On Mon, Apr 12, 2004 at 03:24:29PM -0500, Chris Cheney wrote: That is 79 chars wide! That probably won't even fit on the screen width of many systems. I am not sure what happens in that case, whether it just wraps the text of displays part of it off the side of the screen. There are two real bugs here that you have touched on though. 1. Debian menu has no real concept of GenericName Debian menu do not need to. You can use a generictitle field in menu file and set up menu-methods to use it. I was going to ask whether it might not be possible to mandate the field in the menu policy, but after looking into the docs a bit, I guess I need to first ask whether it wouldn't be a good idea to mandate some (minimal) things the menu files need to contain ? 2. KDE menu doesn't display comments as tooltips (Gnome does this nicely) If both of those bugs were fixed it would work much better. We could have GenericName = generictitle() and Comment = longtitle() or something You need a $generictitle, but we already have it. longtitle() do not exist and generictitle() is not needed, AFAICS. This seems very unclear to me. AIUI, you mean that we already have $generictitle because the menu program and system don't need any changes outside of the menu files and menu methods to support the extra field ? AFAICS, quite some packages do have $longtitle, so I think that saying that it doesn't exist is a bit strange. And I don't see why you say that $generictitle is not needed ( assuming you mean that it's not useful for programs' menu files to provide the field ). It would clearly be very useful for compatibility with KDE's expectations. Add to xdg-desktop-entry-spec-apps GenericName= $generictitle And start to add generictitle=A Generic title in menu files. Yeah, this is the easy part of the job. The hard part is of course getting apps to provide the field. similiar to that. I look forward to the time when Debian will convert to the freedesktop menu standards so that the integration will be much smoother. :) LOL Hm, I'm wondering about how serious people are taking this. I would personally like to see Debian move ( in the long term, like most Debian things ) to freedesktop menu standards, because those have a much higher chance of being available in third party software. This is of course not at all urgent, and I'm not entirely sure it would be worth the extra effort. What do you think about this ? cheers domi
Re: revising the first cd contents...
Chris Cheney writes: On Wed, Jun 30, 2004 at 02:00:52AM +0200, Achim Bohnet wrote: On Saturday 26 June 2004 15:41, Joey Hess wrote: Chris Cheney wrote: kde-core is enough to get KDE running, it includes arts/kdelibs/kdebase, but it doesn't include any of the other official KDE packages. It does include basic apps like kate, konqueror and konsole. The kde package installs the full official KDE release, but doesn't include 3rd party apps they are included in the kde-extras package instead. Would the KDE people be satisfied if the first debian CD installed a KDE that was only kde-core for the desktop task? Installs from more than Hey, KDE people wake up! ;) ;) kde-core contains all of the great base other KDE apps can and do use. But from the applicataion/user point of view there is the konqueror, kwrite(kate) and konsole That's all! kde-core has: no mailer (kmail), no cd player (kscd), no mixer (kmix), no addressbook (kaddressbook), no pdfviewer (kghostview). All I ever use is konqueror, konsole, and kedit. :) I often use konqueror, kghostview and kopete. The latter cannot be left out imho. cheers domi
Bug#253028: It seems a kdeprint problem
package konqueror reassign 253028 kdeprint package kdeprint merge 253028 256720 thanks Cesar Martinez Izquierdo writes: I have the same problem with other KDE programs, so I think it's a kdeprint problem. See bug #256720, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256720 Maybe this bug should be reasigned to kdeprint, and merged with #256720 ? I don't have the problem, but the two bugs seem to be very similar, so you're probably right that they should be merged. I'm hereby doing so. cheers domi
Bug#227538: kdelibs: mixed results on 3.2.2
Chris Cheney writes: On Sat, Jun 26, 2004 at 04:20:12AM +0200, Dominique Devriese wrote: -snip patch- I haven't heard anything about this bug in a while. Does this patch work? I'm pretty sure it fixes the problem, yes. Has been applied to packages that have been released? It's committed in pkg-kde/kdelibs, but apparently it's still not in any uploaded kdelibs version. Chris must have missed this simple patch... Its not committed in the main tree afaict, where is it? Right, I didn't commit it yet, I misinterpreted an empty svn up output.. Guess I'm still too used to the old CVS way :) I will add it to the next upload if it seems to help. I think someone told me before what changing this patch does but it doesn't seem to be in the bug log. Yeah, I seem to remember eplaining it to you once.. The way it currently is seems to work for me, what bug do you see with this exactly? calc-amd64:~# kde-config --path config /root/.kde/share/config/:/etc/kde3/ Well, the problem is that what's currently there happens to work in some cases, but doesn't work in other cases, like the one that the bug report was about. I'll try to explain it again: It's all about the string comparison: If somestring is a variable of type char*, then 'somestring == something' in C++ and C is not a string comparison, but a pointer comparison. It checks that the variable somestring points to the same region of memory that something is put in. Now, the C++ standard leaves some behaviour wrt. string storage undefined, but what g++ does, is that if it finds two string literals containing the same thing, it stores them only once, if the two strings are in the same compile unit or link unit or whatever unit it takes for this. Anyway, what happens in your case ( where it works properly ) is that, the first time that the function is called with something as an argument, it is by chance one of the identical strings in the same compile unit, and the check happens to succeed. The function then caches the result it just calculated, and all further invocations of the function give the correct result. However, if the first invocation of the function happens to be a string from another compile unit, then the pointer comparison fails, the function calculates the wrong result, and this result is cached for all further invocations. I debugged the bug that was described in this bug report, and this is in fact the case. Anyway, I'll be committing the patch now, if you don't mind, with the above explanation in the commit log... cheers domi
pkg-kde: commit - rev 138 - trunk/packages/kdelibs/debian/patches
Author: domi-guest Date: 2004-06-26 10:20:40 -0600 (Sat, 26 Jun 2004) New Revision: 138 Modified: trunk/packages/kdelibs/debian/patches/10_kstandarddirs.diff Log: Commit patch for #227538 Here's a bit of explanation: I'll try to explain it again: It's all about the string comparison: If somestring is a variable of type char*, then 'somestring == something' in C++ and C is not a string comparison, but a pointer comparison. It checks that the variable somestring points to the same region of memory that something is put in. Now, the C++ standard leaves some behaviour wrt. string storage undefined, but what g++ does, is that if it finds two string literals containing the same thing, it stores them only once, if the two strings are in the same compile unit or link unit or whatever unit it takes for this. Anyway, what happens in your case ( where it works properly ) is that, the first time that the function is called with something as an argument, it is by chance one of the identical strings in the same compile unit, and the check happens to succeed. The function then caches the result it just calculated, and all further invocations of the function give the correct result. However, if the first invocation of the function happens to be a string from another compile unit, then the pointer comparison fails, the function calculates the wrong result, and this result is cached for all further invocations. I debugged the bug that was described in this bug report, and this is in fact the case. Modified: trunk/packages/kdelibs/debian/patches/10_kstandarddirs.diff === --- trunk/packages/kdelibs/debian/patches/10_kstandarddirs.diff 2004-06-17 21:28:04 UTC (rev 137) +++ trunk/packages/kdelibs/debian/patches/10_kstandarddirs.diff 2004-06-26 16:20:40 UTC (rev 138) @@ -6,7 +6,7 @@ candidates-append(path); } +// UGLY HACK - Chris Cheney -+if (local (config == type)) ++if (local (!strcmp(config, type))) + candidates-append(/etc/kde3/); +// local = false;
Bug#227538: kdelibs: mixed results on 3.2.2
Itai Seggev writes: === --- debian/patches/10_kstandarddirs.diff (revision 125) +++ debian/patches/10_kstandarddirs.diff (working copy) @@ -6,7 +6,7 @@ candidates-append(path); } + // UGLY HACK - Chris Cheney -+ if (local (config == type)) ++ if (local (!strcmp(config, type))) + candidates-append(/etc/kde3/); + // local = false; What does that do exactly? It would seem to append /etc/kde3 to all types other than config? Or did I misunderstand what I was doing in that patch? Chris I haven't heard anything about this bug in a while. Does this patch work? I'm pretty sure it fixes the problem, yes. Has been applied to packages that have been released? It's committed in pkg-kde/kdelibs, but apparently it's still not in any uploaded kdelibs version. Chris must have missed this simple patch... cheers domi
Bug#247408: unreproducible
package kdelibs4 tags 247408 +unreproducible thanks Hi, Some remarks 1 I can't reproduce the problem. 2 Kbuildsycoca should always be run at the appropriate times, it has fam and stuff for directory watching to make sure of that. I'm not sure why it wouldn't do so in your case. umbrello installs its mime type in the correct directory. 3 Even if kde hasn't yet picked up the mimetype, that's no reason for umbrello to crash. cheers domi
Bug#253127: patch
package kdebase
reassign 253127 kdelibs4
package kdelibs4
tags 253127 +upstream, patch
thanks
Attached is a patch for the problem. It's committed in
KDE_3_2_BRANCH, but I'm not sure another KDE 3.2 release is planned.
I'm holding up committing it in HEAD because of the 3.2 beta freeze.
cheers
domi
Index: kicontheme.cpp
===
RCS file: /home/kde/kdelibs/kdecore/kicontheme.cpp,v
retrieving revision 1.60
diff -u -r1.60 kicontheme.cpp
--- kicontheme.cpp 29 May 2004 15:20:51 - 1.60
+++ kicontheme.cpp 24 Jun 2004 12:49:10 -
@@ -167,7 +167,7 @@
KIconThemeDir *dir = new KIconThemeDir(*itDir + *it, cfg);
if (!dir-isValid())
{
- kdWarning(264) Icon directory *itDir group *it not valid.\n;
+ kdDebug(264) Icon directory *itDir group *it not valid.\n;
delete dir;
}
else
Bug#255514: Should have lower priority for x-session-manager
Matthew Garrett writes: In an ideal world, kdeinit would be at a lower priority for x-session-manager than gnome-session. Users who want to use KDE are more likely to be sufficiently competent to work out how to change their default, Why would you say so ? and currently we have the slightly silly situation that a clean install of sarge with Desktop selected gives you gdm by default but then launches KDE. As for me, I think gdm is the best desktop manager atm, and kde the best desktop environment, so the priorities seem correct wrt my personal preferences ;) cheers domi
Bug#255539: Kdelibs 4:3.2.3-2 breaks some themes
Kimmo Teräväinen writes: This bug is i a a fact the same than bug #254021, but I think it was filed against wrong packages. Updating kde from 4:3.2.3-1 to 4:3.2.3-2 breaks kde window widget themes. Many themes (including Keramik) disappear in Control Center and as soon as kde programs are restarted they start to use some other theme instead (.NET). More specifically bug exists only if packages kdelibs4 and kdelibs-bin are updated. When downgraded into version 4:3.2.3-1 themes come back. What versions of Qt do you have installed ? Does it help if you upgrade Qt ? cheers domi
Bug#254593: Bug254593: libkdefx.so.4: undefined symbol: _ZN7QPixmap6detachEv
Joerg Reckers writes: here some more information as domi proposed: Hi, thanks for the extra info. Everything seems normal except for this: nm --dynamic /usr/lib/libqt-mt.so | grep _ZN7QPixmap6detachEv does't give me anything, thats why the undefiened symbol? if i grep for Pixmap6 i just get 00281730 T _ZN7QPixmap6resizeEii 0033d150 T _ZNK14QListBoxPixmap6heightEPK8QListBox 00347e30 W _ZNK14QListBoxPixmap6pixmapEv 001c5200 T _ZNK7QPixmap6metricEi Something must have gone wrong with your qt library. Are you using any special qt packages ? Have you compiled qt yourself ? Any other info you think can be useful ? And can you please also send us the output of the following commands ? md5sum /usr/lib/libqt-mt.so dpkg -l 'libqt*' thanks domi
Bug#252928: Why did you lower the severity of #252928?
package kdelibs4 reassign 252928 apollon package apollon severity 252928 normal thanks Adrian Bunk writes: severity 252928 grave thanks Hi Chris, Hi, Sorry for interfering with the discussion. why did you lower without any further comment the severity of this bug I reported? I described in my bugreport how this issue might cause future breakage in sarge, and the simple workaround via a conflict would be easy to implement. First, why don't you read the definitions of the severity levels ? How in the world does this make the kdelibs4 package mostly unusable ? Second, I don't understand either why you seem to think this is a kdelibs bug and not an apollon one ? I'm reassigning to apollon. Thirdly, the severity level would be correct for apollon, but since I can't reproduce your problem, I'm lowering it to normal. thanks domi
Bug#254593: Bug254593: libkdefx.so.4: undefined symbol: _ZN7QPixmap6detachEv
Joerg Reckers writes: md5sum /usr/lib/libqt-mt.so 4673fe60a02b1ee69c18b918b3ffc170 /usr/lib/libqt-mt.so where can i check if the fingerprint is the right one? I've done a quick check against the qt lib from the package you are using, and it's apparently wrong. Your lib must somehow have gotten corrupted. I would advise you to install the debsums package to check whether I haven't made a mistake, and to reinstall qt if you get the same results. It's probably best to let debsums check the rest of your files as well. Have you by any chance run the prelink program recently ? cheers domi
Bug#252928: Why did you lower the severity of #252928?
package kdelibs4 severity 252928 important thanks Adrian Bunk writes: I described in my bugreport how this issue might cause future breakage in sarge, and the simple workaround via a conflict would be easy to implement. First, why don't you read the definitions of the severity levels ? How in the world does this make the kdelibs4 package mostly unusable ? kdelibs from unstable + apollon from - apollon doesn't work Yes, as I said, this does not at all make the *kdelibs* package *mostly unusable*. It's definitely RC The Debian BTS severities are not about whatever definition you attach to the idea of being RC or not, they are about: critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. serious is a severe violation of Debian policy (that is, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. normal the default value, applicable to most bugs. as you can see on http://www.debian.org/Bugs/Developer.en-gb.html#severities Clearly, the highest severity that this bug can arguably qualify for is serious if and only if Chris Cheney thinks so, and important otherwise. Chris has clearly shown that he did not at the time think so, so I am downgrading this bug to important. It's up to him to change it to serious if he thinks it deserves that. I hope we can now stop playing pingpong with the severity ? In the sense must be fixed, before the new kdelibs enters testing, or apollon in testing will be broken. The only thing that's keeping the new apollon ( which, according to its changelog has the real fix for the problem ) from entering testing is its dependency on kdelibs. Thus, there is little chance that the new kdelibs would enter sarge and the new apollon wouldn't. Second, I don't understand either why you seem to think this is a kdelibs bug and not an apollon one ? I'm reassigning to apollon. I don't know who's at fault, but no matter who's fault it is, a conflict in kdelibs is needed. For people using strange combinations of testing and unstable, I agree that a conflict would be useful, but I don't consider this release critical at all, for the reason stated above. And even if I did, it wouldn't matter at all, read the fn definitions of the severity levels, please. No change in apollon can prevent the breakage of apollon in testing if a new kdelibs enters testing before a new apollon. True, but this situation will be fixed immediately when the new apollon enters testing as well. The only thing that's keeping it from doing that is its dependency on kdelibs4. Thus, when kdelibs4 will enter testing, so will apollon. cheers domi
Bug#252928: Why did you lower the severity of #252928?
Adrian Bunk writes: On Fri, Jun 18, 2004 at 10:29:07PM +0200, Dominique Devriese wrote: ... Clearly, the highest severity that this bug can arguably qualify for is serious if and only if Chris Cheney thinks so, and important otherwise. Chris has clearly shown that he did not at the time think so, so I am downgrading this bug to important. It's up to him to change it to serious if he thinks it deserves that. I hope we can now stop playing pingpong with the severity ? As said in the part of the mail you skipped: Your RM reopened a similar (grave) bug I sent that covered a similar issue. Chris uploaded a new version of kdelibs 6 days after my bug report. Why did he downgrade it instead of simply fixing the issue via a conflict? Probably because 1 adding a conflict to a package because of a bug in another package is generally the wrong thing to do, even if it may be good as a workaround in this case 2 you did not provide a lot of explanation about why it was the correct thing to do in this case In the sense must be fixed, before the new kdelibs enters testing, or apollon in testing will be broken. The only thing that's keeping the new apollon ( which, according to its changelog has the real fix for the problem ) from entering testing is its dependency on kdelibs. Thus, there is little chance that the new kdelibs would enter sarge and the new apollon wouldn't. ... Imagine a new upload of apollon to unstable, a RC bug in apollon, or many other reasons like apollon not being built on one architecture. Of course, but you have to agree that it won't take ages to fix something like this in a simple package like apollon. This is where the difference is with the wine bug you were talking about. By the way, why do you seem to think that an uninstallable version of apollon in sarge is better than a version that crashes on startup ? cheers domi
Bug#252928: Why did you lower the severity of #252928?
Adrian Bunk writes: 2 you did not provide a lot of explanation about why it was the correct thing to do in this case And if the it's unclear, a question might be a better solution than a silent lowering of the severity... I have already told you numerous times that the severity was wrong. I also told you the probable reasons why the bug was not yet fixed in the release you were refering to. I consider this discussion closed. cheers domi
Bug#252928: Why did you lower the severity of #252928?
Chris Cheney writes: I am really fatigued (I think I may not have ever gotten well yet) so I don't really want to start a flamewar. Here is a more full quote and more fully explains the situation. The situation with apollon is not the same as the wine issue. The wine issue was that old already in Debian stable versions of wine would break with new libc6. apollon if it exists in Debian stable already (I didn't check) would not work anyway since it would be compiled against KDE 2.2. I'll let domi and you hash this out the rest of the way, I need to lay back down. Hm, right, didn't notice this. Anyway, the question comes down to what combinations of versions we support. There are two situations in which people would suffer from the bug: 1 people who have mixed unstable/testing environments, due to partial upgrades, or apt pinning 2 the situation where the new kdelibs reaches testing, and the new apollon doesn't. Debian doesn't officially support the first group, and the second situation is not all that likely. However, adding the conflict doesn't very much overhead, except for the fact that if we start doing this for every such situation, we'll end up with a hell of a lot of conflicts. Anyway, I'd say to just add the conflict, we can easily remove it afterward. In the past, there have been kdelibs-data conflicts for problems outside of kdelibs as well. Ok if I commit this to pkg-kde, calc ? cheers domi
KDE_3_2_BRANCH: kdebindings/debian
CVS commit by domi: update M +5 -1 changelog 1.5.2.19 M +2 -1 control 1.6.2.7 --- kdebindings/debian/changelog #1.5.2.18:1.5.2.19 @@ -2,6 +2,10 @@ * New upstream version. + * Change maintainer address to Debian Qt/KDE Maintainers +debian-qt-kde@lists.debian.org and list me as uploader. + * Fix a simple bug in juic: juic: Incorrect code generated in polish() +(closes: 254882) - -- Dominique Devriese [EMAIL PROTECTED] Tue, 1 Jun 2004 13:05:50 +0200 + -- Dominique Devriese [EMAIL PROTECTED] Thu, 17 Jun 2004 23:05:27 +0200 kdebindings (4:3.2.2-5) unstable; urgency=low --- kdebindings/debian/control #1.6.2.6:1.6.2.7 @@ -3,5 +3,6 @@ Section: devel Priority: optional -Maintainer: Dominique Devriese [EMAIL PROTECTED] +Maintainer: Debian Qt/KDE Maintainers debian-qt-kde@lists.debian.org +Uploaders: Dominique Devriese [EMAIL PROTECTED] Standards-Version: 3.6.1
Bug#254593: libkdefx.so.4: undefined symbol: _ZN7QPixmap6detachEv
package kdelibs tags 254593 +unreproducible thanks Joerg Reckers writes: I got the following error when i try to start an application (incl kde) using the libkdefx libary: relocation error: /usr/lib/libkdefx.so.4: undefined symbol: _ZN7QPixmap6detachEv /usr/lib/libkdefx.so.4 is a link to /usr/lib/libkdefx.so.4.2.0 Hi, thanks for the bug report. I cannot reproduce this problem on my machine. Can you provide us with the output of the following commands: ls -l /usr/lib/libkdefx* ls -l /usr/lib/libqt* ldd /usr/lib/libkdefx.so.4.2.0 nm --dynamic /usr/lib/libqt-mt.so | grep _ZN7QPixmap6detachEv Thanks domi
Bug#254529: Unreproducible
package konqueror tags 254529 +unreproducible thanks Hi, I cannot reproduce this problem. Can you please provide more information about this bug ? Take a look at this page for ideas on what information to provide: http://www.kalyxo.org/~domi/debugging-kde-crash.html cheers domi
Re: Announcing the availability of first Qt 3.3 packages
Brian Nelson writes: Chris Cheney [EMAIL PROTECTED] writes: On Tue, Jun 15, 2004 at 05:43:33PM -0700, Brian Nelson wrote: Why do you insist so stubbornly on maintaining the package? You don't take very good care of it, and you've said in the past that you don't even do any Qt development. If you saw Qt before a few of us beat on it around April 2002 you would understand why no one else _wants_ to maintain it. Trolltech is very lacking in clue and had to be constantly beat on to do things competently. They may be getting better but from what I have heard recently they are still pretty incompetent. I was originally going to maintain Qt as well but ran away screaming. ;) Thats pretty bad considering the shape KDE was in at the time as well... Yeah, I'm quite aware of Trolltech's occasional insanity. However, I'm maintaining a fork anyway so maintaining the Debian package wouldn't really be much extra work for me. Since you seem to want to replace Martin by force, let me just say this: Martin's track record wrt bugs is far from perfect, but I feel very much more comfortable with him maintaining the package than you doing it. Your uninformed proposals wrt. undoing the package split have proven to me that you don't know Qt enough to be able to maintain the package, and that you don't have the experience or intelligence to realise that fact. I am also convinced that you don't know about the kind of difficult to resolve bugs that a Qt maintainer is faced with. You have to realise that ACE is a package that not much people use ( and rightfully so imho, but let's not start about that ), so it's pretty easy to fix its bugs. Conclusion: I suggest that you try to work together with Martin on the package or shut up. cheers domi
Re: Announcing the availability of first Qt 3.3 packages
Brian Nelson writes: qt3-apps-dev: stuff you need when you're going to be doing special things with embedding Qt designer and stuff. Almost noone needs this. Special things? What the hell are special things? As I said: embedding Qt designer and stuff. And the package name in no way suggests any difference from qt3-dev-tools. Then you should be complaining about the package name, not the fact that the package exists. I'm doing both. What does embedding Qt designer mean? Is that something that is useful to many people? Of course it's useful, but not to many people, no. I consider that a reason to not include it in a general -dev package. For example: you seem to propose to not split out the compat headers, I think this would be a very bad idea, since I rely on this in my qt development to make sure I'm not using obsolete qt headers. This was discussed on debian-devel around the time the split was going to be made. Several people agreed that there were superior alternate ways to accomplish this without splitting out the obsolete headers, and consequently breaking the compilation of many packages. For instance, you could put #warning pragmas at the top of each obsolete header so that the compiler spits out a warning when one is used. I personally fail to see how this would be superior rather than complementary. One of the reasons I'm so ornery when it comes to the Debian Qt packages is that much of this stuff was discussed before the split and there seemed to be a consensus that there were a lot of problems with it, yet it was done anyway without heeding any of the advice. You don't happen to have a link around, do you ? For another thing, Qt assistant is not only a development tool either. Many Qt apps use it to display their documentation. You would require every user of such apps to install the entire development package. Really? I was not aware of this. I don't think it would matter much though since I doubt any users other than Qt developers are aware of the assistant, and the documentation is in html format readable by any web browser anyway. It's not a matter of being aware of them. The fact is that if you press help in some qt programs, they call the assistant. Users need it. period. You also seem to ignore non-multithreaded use of the qt libraries, even though there are still applications depending on this. Well, there are only 2 packages in Debian still using them (I filed bugs to fix all of them)--one appears to have a dead upstream and the other has a negligent maintainer. Non-multithreaded use is discouraged and will be removed in Qt 4. There's no reason for Debian to remove it earlier. I consider your bugs invalid. You seem to not want to support embedded cross-development, again without considering people who need this. There is already a Qt/Embedded source package in the archive. Can that be used in place of the qt3-dev-tools-embedded stuff? That is Qt/Embedded version 2, this is Qt/Embedded version 3. Summarizing: Qt is a very complex package, and there are good reasons for most, if not all split-ups. I'm still unconvinced of that. Fine, I'm not going to keep arguing with you over this. IMHO, as you've demonstrated above, you don't seem to know Qt thoroughly enough to be able to understand the need for the structure of its packages. If you want to help, it would imho be more useful to send Martin patches for some of the real problems, as he has already requested often. I have in the past, but they've been rejected (because Ralf Nolden is a stubborn flaming nitwit IMNSHO). Any link on that ? I have also been going through bug reports, since many are no longer relevant, already fixed. etc. Great. cheers domi
Re: Announcing the availability of first Qt 3.3 packages
Brian Nelson writes: Summarizing: Qt is a very complex package, and there are good reasons for most, if not all split-ups. I'm still unconvinced of that. Fine, I'm not going to keep arguing with you over this. IMHO, as you've demonstrated above, you don't seem to know Qt thoroughly enough to be able to understand the need for the structure of its packages. I'm confident I know Qt very well for standard application development and I don't see anything above that demonstrates otherwise. Yeah, firstly, I've prolly been too harsh above. Sorry. I guess it's my natural geek tendency to flame coming up :s What I was talking about is that you didn't seem to know what Qt Assistant is intended to be used for, what qt-apps-dev could be used for, even when the package description stated it pretty clearly etc, and the radicalness of your proposals. About the issues we were discussing: * get rid of non-mt packages - Could save quite some buildd time, but might upset some people still depending on it. I wouldn't do it yet for Qt 3.0 personally. * get rid of embedded stuff - prolly not a good idea, you seem to have changed your mind here too or I misunderstood you in the first place. * get rid of libqt3-compat-headers - I disagreed, but Ben convinced me. * move a lot of dev stuff into one -dev package - Don't really like the idea, since it makes all people install more stuff they don't need, and I still seem to miss the advantage. I've already admitted to not knowing anything about embedded stuff. Which is fine no one actually uses all of Qt, so no one is qualified to be the sole maintainer of the package. It should be group-maintained. FWIW, I would very much like to see Qt group-maintained, if at all possible. I'm going to abstain from further comments, as I really should be studying... cheers domi
Re: Announcing the availability of first Qt 3.3 packages
Brian Nelson writes: qt3-dev-tools: a number of binaries ( note: architecture dependent, so you don't want them in an arch independent headers package ) for normal development with Qt Who said we need a arch-indep headers package anyway? I don't know of any other library packages in Debian that have one. Hell, I co-maintain one, if not the, largest library package in Debian and it doesn't have headers split into a separate package. It's not a requirement, but it's generally a good thing to do, to save buildd time for arch-dep packages. Please read the packaging policy if you need more information. I'm not going to criticise your packaging of ace here. qt3-apps-dev: stuff you need when you're going to be doing special things with embedding Qt designer and stuff. Almost noone needs this. Special things? What the hell are special things? As I said: embedding Qt designer and stuff. And the package name in no way suggests any difference from qt3-dev-tools. Then you should be complaining about the package name, not the fact that the package exists. Anyway, if you're going to be making claims like this, it would be a lot more useful if you could provide us with a proposal about how you would like to see the package split up, so we could consider this in a useful manner. As I said before, I think most stuff should be moved into a single -dev package. For a working example, see the packages at http://bignachos.com/~nelson/debian . snip: some usage scenario's So ultimately we're talking about a 2M difference for a developers and 600K for users or buildds, with the trade-off being far simpler packages (8 packages vs. 23 or whatever the current number is) Try to think of some more usage scenario's. For example: you seem to propose to not split out the compat headers, I think this would be a very bad idea, since I rely on this in my qt development to make sure I'm not using obsolete qt headers. For another thing, Qt assistant is not only a development tool either. Many Qt apps use it to display their documentation. You would require every user of such apps to install the entire development package. You also seem to ignore non-multithreaded use of the qt libraries, even though there are still applications depending on this. You seem to not want to support embedded cross-development, again without considering people who need this. Summarizing: Qt is a very complex package, and there are good reasons for most, if not all split-ups. If you want to help, it would imho be more useful to send Martin patches for some of the real problems, as he has already requested often. with fewer bugs (no missing files). I don't see a correlation between the number of packages and the amount of misplaced or forgotten files. As long as the package is split into more than one package, there can be mistakes in the splitting I guess. cheers domi
Re: viewmol wants to provide kde icons
Drew Parsons writes: Hello, my package viewmol contains a handful of icons for kde. I don't use kde daily myself, so I'm not sure about correct handling of the icons. viewmol has its own install script for the icons, it wants to copy them under /usr/share/icons/default.kde, as well as providing /usr/share/applications/viewmol.desktop and some desktop config files under /usr/share/mimelnk. Bug #254247 reports that use of /usr/share/icons/default.kde is a conflict against kdelibs-data. But dpkg does not complain. On the other hand, kdelibs-data's version of default.kde is a symlink to crystalsvg, while viewmol's is a plain directory. This will be a problem if viewmol is installed before kdelibs-data. Is there any better way of handling the icons which viewmol wants to place under default.kde, or is a pre-dependency on kdelibs-data the only solution (not a very good solution for those viewmol users who don't use kde)? I think it should just install them under /usr/share/icons/crystalsvg ( and if the kde icon theme would be changed again some day, in whatever other directory that default.kde points to ). cheers domi
Re: Announcing the availability of first Qt 3.3 packages
Brian Nelson writes: IMO, the reason for the missing files is the ridiculous number of superfluous packages Qt has been split into. Is it really necessary to have libqt3-mt-dev, libqt3-headers, libqt3-compat-headers, qt3-dev-tools, qt3-designer, qt3-apps-dev, qt3-linguist, qt3-assistant, qt3-qtconfig, qt3-dev-tools-embedded, qt3-dev-tools-compat, etc. (I think I even left some out!) in separate packages? Just a single -dev package seems sufficient to me. It makes me wonder what kind of a bribe it took to get this past the ftp-masters. Are you sure you know what you're talking about ? I can think of a lot of situations in which those tools are used in various different combinations, so that it really is a good idea to have them in separate packages. Huh? That's absolutely no reason to put a bunch of small binaries in separate packages. You gain nothing except unnecessary complexity. Let's see. I don't consider these small binaries: qt3-assistant_3%3a3.3.2-0pre1_i386.deb 229K qt3-designer_3%3a3.3.2-0pre1_i386.deb 3,9M qt3-linguist_3%3a3.3.2-0pre1_i386.deb 324K qt3-dev-tools_3%3a3.3.2-0pre1_i386.deb 1,2M qt3-dev-tools-embedded_3%3a3.3.2-0pre1_i386.deb 273K Also, you must only be talking about qt3-assistant, qt3-qtconfig, qt3-linguist, and qt3-designer. What you've said doesn't apply to headers, and who the hell knows what the difference between qt3-dev-tools, qt3-apps-dev, etc. is anyway? I do, and you would too if you had taken the time to look at the package descriptions: qt3-dev-tools: a number of binaries ( note: architecture dependent, so you don't want them in an arch independent headers package ) for normal development with Qt qt3-apps-dev: stuff you need when you're going to be doing special things with embedding Qt designer and stuff. Almost noone needs this. Anyway, if you're going to be making claims like this, it would be a lot more useful if you could provide us with a proposal about how you would like to see the package split up, so we could consider this in a useful manner. cheers domi
Re: Announcing the availability of first Qt 3.3 packages
Christopher Martin writes: Hello, Thanks for making these packages available. They're working very well, but I did notice a few small things. Dito, thanks a lot for reconsidering, Martin. libqt3-mt-dev now pulls in several database libraries. Is this avoidable somehow? Agree with this. Also, the Kmenu now has a problem wherein there is a gap between it and its submenus. Also, the arrow heads that point to the submenus are missing. I seem to recall a KDE mailing list discussion of these problems. I'm not sure what the solution was - perhaps KDE 3.2.3, or a patch from qt-copy. http://bugs.kde.org/show_bug.cgi?id=77545 The patch is in qt-copy/patches/0047-fix-kmenu-width.diff apparently. I haven't yet seen any further problems with Qt 3.3. Generally, there are a large number of bugs open that should be dealt with one way or another - people have requested dbg packages, static libraries, that libqt3-dev and libqt3-mt-dev be simultaneously installable, etc. etc. I'm no Qt guru, but if there are things you want help with, perhaps posting specific requests to this list will yield assistance. Same goes for kdelibs and kdebase, if people are looking for stuff to do ;) cheers domi
Re: Announcing the availability of first Qt 3.3 packages
Christopher Martin writes: Generally, there are a large number of bugs open that should be dealt with one way or another - people have requested dbg packages, Just a note that I maintain unofficial debug packages of qt, kdelibs, kdebase and occasionally ( when I happen to build them ) other kde modules at http://kalyxo.org/~domi/debian-kde-debug.html. Qt 3.2.3-3debug1 is currently compiling. cheers domi
Re: Announcing the availability of first Qt 3.3 packages
Brian Nelson writes: Christopher Martin [EMAIL PROTECTED] writes: On June 13, 2004 12:44, Brian Nelson wrote: For one, they're missing the qaccessible.h header. It appears to missing from the 3.2.3 packages as well. Martin, there seem to be a few other bugs open regarding missing files. qvfbhdr.h is missing - #182366. tabwidget.png should also allegedly exist - #195189. And someone raised a question over the location of #headers under /u/i/qt3, that I'm not qualified to answer fully, but thought I'd mention - please see #226990. There are yet more reports on missing headers, but these are the ones that are still relevant, from what I can tell. IMO, the reason for the missing files is the ridiculous number of superfluous packages Qt has been split into. Is it really necessary to have libqt3-mt-dev, libqt3-headers, libqt3-compat-headers, qt3-dev-tools, qt3-designer, qt3-apps-dev, qt3-linguist, qt3-assistant, qt3-qtconfig, qt3-dev-tools-embedded, qt3-dev-tools-compat, etc. (I think I even left some out!) in separate packages? Just a single -dev package seems sufficient to me. It makes me wonder what kind of a bribe it took to get this past the ftp-masters. Are you sure you know what you're talking about ? I can think of a lot of situations in which those tools are used in various different combinations, so that it really is a good idea to have them in separate packages. cheers domi
KDE_3_2_BRANCH: kdebindings/debian
CVS commit by domi: update M +6 -0 changelog 1.5.2.18 --- kdebindings/debian/changelog #1.5.2.17:1.5.2.18 @@ -1,2 +1,8 @@ +kdebindings (4:3.2.3-1) unstable; urgency=low + + * New upstream version. + + -- Dominique Devriese [EMAIL PROTECTED] Tue, 1 Jun 2004 13:05:50 +0200 + kdebindings (4:3.2.2-5) unstable; urgency=low
pkg-kde: commit - rev 128 - trunk/packages/kdebindings/debian
Author: domi-guest Date: 2004-06-01 05:07:55 -0600 (Tue, 01 Jun 2004) New Revision: 128 Modified: trunk/packages/kdebindings/debian/changelog trunk/packages/kdebindings/debian/rules Log: update to builddir!=srcdir and kde 3.2.3 Modified: trunk/packages/kdebindings/debian/changelog === --- trunk/packages/kdebindings/debian/changelog 2004-05-06 11:23:17 UTC (rev 127) +++ trunk/packages/kdebindings/debian/changelog 2004-06-01 11:07:55 UTC (rev 128) @@ -1,3 +1,16 @@ +kdebindings (4:3.2.3-1) unstable; urgency=low + + * New upstream version. + + -- Dominique Devriese [EMAIL PROTECTED] Tue, 1 Jun 2004 13:05:50 +0200 + +kdebindings (4:3.2.2-5) unstable; urgency=low + + * qtjava/designer/juic/lib: remove the two xml parsers, so they don't bloat the package and the diff.gz + * debian/rules: make it clean properly by using builddir!=srcdir + + -- Dominique Devriese [EMAIL PROTECTED] Sat, 22 May 2004 20:39:58 +0200 + kdebindings (4:3.2.2-4) unstable; urgency=low * debian/control: Removed Build-Depends on autoconf and automake. Modified: trunk/packages/kdebindings/debian/rules === --- trunk/packages/kdebindings/debian/rules 2004-05-06 11:23:17 UTC (rev 127) +++ trunk/packages/kdebindings/debian/rules 2004-06-01 11:07:55 UTC (rev 128) @@ -26,7 +26,7 @@ endif # I'd like to move to builddir!=srcdir when I can get upstream to build with it. -#objdir = $(CURDIR)/obj-$(DEB_BUILD_GNU_TYPE) +objdir = $(CURDIR)/obj-$(DEB_BUILD_GNU_TYPE) upstream_version=`head -1 $(CURDIR)/debian/changelog | sed -e s,.*:\([^-]*\).*,\1,` ifndef PERL @@ -76,18 +76,16 @@ chmod +x configure # make build directory - # mkdir $(objdir) + mkdir $(objdir) # run configure with build tree $(objdir) - # ( not yet in a different build tree) - # cd $(objdir) \ - # ../configure \ - # --enable-final - ./configure \ + cd $(objdir) \ + ../configure \ $(configkde) \ --with-java=/usr \ --with-pythondir=/usr/lib/python2.3/site-packages \ DO_NOT_COMPILE='dcopperl kalyptus kdeobjc korundum qtobjc qtruby qtsharp xparts' + # --enable-final touch configure-stamp @@ -95,11 +93,11 @@ build-stamp: configure-stamp dh_testdir - # cd $(objdir) + cd $(objdir) \ $(MAKE) # build dcopjava even though it's disabled upstream. - # cd $(objdir) + cd $(objdir) \ $(MAKE) -C dcopjava #dcopperl is disabled @@ -138,7 +136,7 @@ fi # Remove build tree - #rm -rf $(objdir) + rm -rf $(objdir) # if Makefile exists run distclean if test -f Makefile; then \ @@ -157,7 +155,9 @@ dh_installdirs -s # Main install. + cd $(objdir) \ $(MAKE) install DESTDIR=$(CURDIR)/debian/tmp + cd $(objdir) \ $(MAKE) -C dcopjava install DESTDIR=$(CURDIR)/debian/tmp #DCOPPerl is disabled. # $(MAKE) -C dcopperl pure_install PREFIX=$(CURDIR)/debian/tmp/usr
Re: QT needs new maintainer(s), or at least an NMU
Martin Loschwitz writes: On Tue, Jun 01, 2004 at 08:53:54AM -0400, Christopher Martin wrote: Hello, I had assumed that the lack of QT updates was a conscious choice by the KDE maintainers to hold off on uploading QT 3.3. But your message implies that this isn't really the case. As far as I am concerned, KDE 3.2 is still not officially certified for running with Qt 3.3, is it? It is. On http://www.kde.org/info/requirements/3.2.php, it says Qt = 3.2.3. Anyway, Qt 3.3 should not go into Sarge, I think. Why not ? It's been released for more than 4 months already, which means it's about the same age as KDE 3.2. cheers domi
Bug#251832: kdelibs4, kdelibs-bin uninstallable in sid
Kevin Price writes: Hi, on my sid machine, I solved the problem by simply recompiling kdelibs4 with the correct libcupsys2-dev installed. IMHO a simple build-depends on libcupsys2-dev (= 1.1.20final+cvs20040330-4) would be appropriate. I'm pretty sure the maintainer is aware of the problem and the fix, but that he is only waiting until the KDE 3.3 release to upload a fixed version. This allows him to combine the two uploads, and prevents killing the buildd's with many resource-intensive kde* uploads. cheers domi
Bug#251832: kdelibs4, kdelibs-bin uninstallable in sid
Kevin Price writes: Hi, Dominique Devriese wrote: I'm pretty sure the maintainer is aware of the problem and the fix, I figure that much too. My suggestion was aimed at those users filing more and more reports about the same problem. That's why I merged the first couple of bugs I came across. Great, thanks. Obligatory help request: If you're interested in working on other kde* bugs in debian, we could very much use the assistance ;) but that he is only waiting until the KDE 3.3 release to upload a fixed version. This allows him to combine the two uploads, and prevents killing the buildd's with many resource-intensive kde* uploads. My machine spent a long time compiling only the kdelibs4. I can well imagine how the buildds are impacted by too frequent kde* uploads. Is there a schedule for a kde 3.3 release? Sigh, I meant 3.2.3 of course. Look here for KDE release schedules: http://developer.kde.org/development-versions/ cheers domi
Re: ksysv usability
Zack Cerza writes: Hello all, I don't know how many of you use ksysv from kdeadmin, but I do on occasion. One thing has bothered me, though, since I first started using it. I assumed it was a stupid bug that would be fixed soon, but that was a few releases ago. When you resize the main ksysv window, all the little panels in it stay the same size - the size being too damn small to see anything. I don't know much at all about Qt programming (which is sad... anyone know a good book?), but it can't be that hard to change this behavior. I first thought to look for .ui files in kdeadmin/kdesdk/, but that only turned up UI designs for the config dialogs. So, is anyone here familiar with ksysv's code? Where is the interface defined if not in a .ui file? Would this be feasible to fix? You're asking on the wrong list, you should try [EMAIL PROTECTED] cheers domi ( who would very much like to see ksysv move to kdeblackhole )
Re: [OT] kde-i18n-ar?
tom writes: Hey all, I just asked at #debian-kde, but no-one seemed to want to (or know an) answer, so I'm hoping this is the right place. I recently installed Mandrake 10 on another disk to, well, have a look, and I was happily surprised when I saw it offers Arabic support. Back in Debian, I thought I'd apt-get install kde-i18n-ar, but it's not there. Is that merely the case because i18n-ar is not a part of the official KDE distribution, as I learned soon thereafter? And if it is, does that mean even if someone would package it, it wouldn't be included in Debian? No, Debian would probably not reject it because it isn't part of the official KDE sources, just as they would not reject KDE apps that aren't part of KDE itself. But it appears [1] that arabic will be part of kde 3.2.3, so there's currently little point left to packaging it separately, I think. chees domi Footnotes: [1] http://wiki.arabeyes.org/KDEMania
Re: Extragears in Debian
Tomàs Núñez writes: Hi Is there any plan (or any thought) to put KDE extragears in Debian? We have most of this apps as separate packets (eg K3b, kwifimanager), but not all of them. So will debian have (shortly or in the future) a meta-packet named kdeextragear-1 (or 2 or 3)? As for the metapackages: I don't see a reason to make a kdeextragear-1 metapackage, as the apps in that package don't have anything in common. It might make sense to make a single kdeextragear package though. As for the packaging: the apps in kdeextragear-* are never released together, and there is in general not a single point in time where they are all in a releasable state. So it does not make sense to package them together imho. cheers domi
KDE_3_2_BRANCH: kdebindings/debian
CVS commit by domi: update: don't bloat the package and the diff.gz with the xml parsers M +6 -0 changelog 1.5.2.16 M +10 -10rules 1.3.2.15 --- kdebindings/debian/changelog #1.5.2.15:1.5.2.16 @@ -1,2 +1,8 @@ +kdebindings (4:3.2.2-5) unstable; urgency=low + + * qtjava/designer/juic/lib: remove the two xml parsers, so they don't bloat the package and the diff.gz + + -- Dominique Devriese [EMAIL PROTECTED] Sat, 22 May 2004 20:38:51 +0200 + kdebindings (4:3.2.2-4) unstable; urgency=low --- kdebindings/debian/rules #1.3.2.14:1.3.2.15 @@ -27,5 +27,5 @@ # I'd like to move to builddir!=srcdir when I can get upstream to build with it. -#objdir = $(CURDIR)/obj-$(DEB_BUILD_GNU_TYPE) +objdir = $(CURDIR)/obj-$(DEB_BUILD_GNU_TYPE) upstream_version=`head -1 $(CURDIR)/debian/changelog | sed -e s,.*:\([^-]*\).*,\1,` @@ -77,16 +77,14 @@ # make build directory -# mkdir $(objdir) +mkdir $(objdir) # run configure with build tree $(objdir) -# ( not yet in a different build tree) -# cd $(objdir) \ -# ../configure \ -# --enable-final -./configure \ +cd $(objdir) \ +../configure \ $(configkde) \ --with-java=/usr \ --with-pythondir=/usr/lib/python2.3/site-packages \ DO_NOT_COMPILE='dcopperl kalyptus kdeobjc korundum qtobjc qtruby qtsharp xparts' +# --enable-final touch configure-stamp @@ -96,9 +94,9 @@ dh_testdir -# cd $(objdir) +cd $(objdir) \ $(MAKE) # build dcopjava even though it's disabled upstream. -# cd $(objdir) +cd $(objdir) \ $(MAKE) -C dcopjava @@ -139,5 +137,5 @@ # Remove build tree -#rm -rf $(objdir) +rm -rf $(objdir) # if Makefile exists run distclean @@ -158,5 +156,7 @@ # Main install. +cd $(objdir) \ $(MAKE) install DESTDIR=$(CURDIR)/debian/tmp +cd $(objdir) \ $(MAKE) -C dcopjava install DESTDIR=$(CURDIR)/debian/tmp #DCOPPerl is disabled.
KDE_3_2_BRANCH: kdebindings/debian
CVS commit by domi: update M +2 -1 changelog 1.5.2.17 --- kdebindings/debian/changelog #1.5.2.16:1.5.2.17 @@ -2,6 +2,7 @@ * qtjava/designer/juic/lib: remove the two xml parsers, so they don't bloat the package and the diff.gz + * debian/rules: make it clean properly by using builddir!=srcdir - -- Dominique Devriese [EMAIL PROTECTED] Sat, 22 May 2004 20:38:51 +0200 + -- Dominique Devriese [EMAIL PROTECTED] Sat, 22 May 2004 20:39:58 +0200 kdebindings (4:3.2.2-4) unstable; urgency=low
Re: Qt library without STL support?
Marius writes: Hello, Can anyone tell me why Qt library is build without STL support in Debian (at least in Sarge and Sid)? I've done some search in Debian BTS. This was reported as important bug in #194475 and #242633. #194475 is 354 (!) days old and #242633 is 34 #days old. None of reports where answered by maintainer. I've also searched debian-qt-kde and debian-kde mailing lists, but results did not satisfied me (they say people need STL support, but it's unclear why library is built without it). I've asked Madkiss this before, and even sent him the trivial patch that changes it iirc, but he never told me the reason for keeping it as is. IMHO, -no-stl is wrong, and it is no longer recommended by KDE for qt-copy. Also look at the following log entries of qt-copy/README.qt-copy: revision 1.209 date: 2003/04/24 11:52:00; author: faure; state: Exp; lines: +2 -2 Well we can't really recommend -no-stl anymore then. revision 1.252 date: 2004/04/01 20:17:39; author: faure; state: Exp; lines: +1 -2 The configure line was there twice in this file - once with -no-stl and once without it. The cvs history shows that after the kde-core-devel discussion (where it was agreed to remove -no-stl), it was only removed from one of the two places. - let's have the options in only one place. Madkiss, can you please tell us your reasons for not changing it ? thanks domi
Re: default file permissions
Ulrich Fürst writes: Antiphon schrieb: The executable bit can be applied to files and directories alike since, in reality, a directory is merely just a kind of file. rw-rw would be 660 So setting my umask to 006 would lead to let new files be 660, right? UMASK(2) Linux Programmer's Manual UMASK(2) NAME umask - set file creation mask SYNOPSIS #include sys/types.h #include sys/stat.h mode_t umask(mode_t mask); DESCRIPTION umask sets the umask to mask 0777. The umask is used by open(2) to set initial file permissions on a newly-created file. Specifically, permissions in the umask are turned off from the mode argument to open(2) (so, for example, the common umask default value of 022 results in new files being created with per- missions 0666~022 = 0644 = rw-r--r-- in the usual case where the mode is specified as 0666). RETURN VALUE This system call always succeeds and the previous value of the mask is returned. CONFORMING TO SVr4, SVID, POSIX, X/OPEN, BSD 4.3 SEE ALSO creat(2), open(2) Linux 1998-08-09 UMASK(2) ;) cheers domi
Re: kdemangen.pl
Ben Burton writes: Well I know it's in cvs/kdesdk/scripts otherwise I wouldn't know it existed. It's not in the Debian package kdesdk-scripts. This is because it's not installed by default (see kdesdk/scripts/Makefile.am). My current policy with kdesdk-scripts is to only install the executable scripts that upstream has decided should be made available to the world at large (there's several other scripts also that aren't installed by default). Right, this is my fault. It's fixed in HEAD. cheers domi
Re: [patch] kdemangen.pl - sort options sections
Zack Cerza writes: I made a patch to sort the options sections in kdemangen.pl. They were in the order: Generic options: Qt options: KDE options: Options: Arguments: ( you can send kdemangen.pl patches to me directly ) The patch looks good, but I can't get it to apply cleanly. Can you send it as an attachment ? thanks domi
KDE_3_2_BRANCH: kdebindings/debian/patches
CVS commit by domi: update M +1 -1 019-libqtjavasupport_la.diff 1.1.2.2
Bug#227538: kdelibs: mixed results on 3.2.2
package kdelibs tags 227538 +patch thanks Chris Cheney writes: On Tue, May 04, 2004 at 04:19:00PM -0700, Itai Seggev wrote: The problem bug is a real bug and not a result of upgrading. I a fresh install with the new sarge installer beta 4, and the problem persisted. I also have discovered why this problem manifested in 3.1.4-3. The binary packages search /etc/qt3/ and /usr/share/config for config files. Up to (and including) 3.1.4-2, /usr/share/config was a symlink to /etc/kde3; hence, it could find the config files. In 3.1.4-3, this symlink was removed. This also explains why installing from debian source over the binary package also fixed the problem permanently: the source install installed the config files into /usr/share/config, so any later binary package could find the config files. Thus, there are 3 solutions to this (and presumably other, related) bugs: Domi could you look into this a bit more? I can reproduce the problem now that I used the symlink, which indicates that kthemestyle isn't using the proper config file lookup mechanism, but I am not sure how it does the config file lookup. It sounds like it is hardcoding paths in its lookup instead of using the kde wide functions that are meant to be used! 8( The problem is probably in kthemebase.cpp somewhere. kdelibs/kstyles/kthemestyle/kthemebase.cpp kdelibs/kstyles/utils/installtheme/main.cpp Chris, it's all your fault ;p Ok to commit ? cheers domi Index: debian/patches/10_kstandarddirs.diff === --- debian/patches/10_kstandarddirs.diff(revision 125) +++ debian/patches/10_kstandarddirs.diff(working copy) @@ -6,7 +6,7 @@ candidates-append(path); } +// UGLY HACK - Chris Cheney -+if (local (config == type)) ++if (local (!strcmp(config, type))) + candidates-append(/etc/kde3/); +// local = false;
Re: kdemangen.pl
Zack Cerza writes: Hey, Can we please get kdemangen.pl in kdesdk or whereever else it should belong, at some point? I think we might find that some people would be willing to create some manpages for KDE apps that are missing them. Take another look in kdesdk/scripts/ ;) cheers domi
KDE_3_2_BRANCH: kdebindings/debian
CVS commit by domi: kdebindings (4:3.2.2-4) unstable; urgency=low * debian/control: Removed Build-Depends on autoconf and automake. * debian/control: Added Build-Depends on sharutils for uudecode. -- Dominique Devriese [EMAIL PROTECTED] Wed, 5 May 2004 23:04:44 +0200 M +7 -0 changelog 1.5.2.15 M +1 -1 control 1.6.2.6 --- kdebindings/debian/changelog #1.5.2.14:1.5.2.15 @@ -1,2 +1,9 @@ +kdebindings (4:3.2.2-4) unstable; urgency=low + + * debian/control: Removed Build-Depends on autoconf and automake. + * debian/control: Added Build-Depends on sharutils for uudecode. + + -- Dominique Devriese [EMAIL PROTECTED] Wed, 5 May 2004 23:04:44 +0200 + kdebindings (4:3.2.2-3) unstable; urgency=low --- kdebindings/debian/control #1.6.2.5:1.6.2.6 @@ -1,4 +1,4 @@ Source: kdebindings -Build-Depends: autoconf (= 2.52), automake1.6, binutils-dev, debhelper ( 4.0.0), gawk, gettext, gij, gcj, libgcj4-dev, fastjar, kdelibs4-dev (= 4:3.1.4), libglib1.2-dev, libgtk1.2-dev, python2.3-dev, perl (= 5.6.0-16), libqt3-compat-headers +Build-Depends: binutils-dev, debhelper ( 4.0.0), gawk, gettext, gij, gcj, libgcj4-dev, fastjar, kdelibs4-dev (= 4:3.1.4), libglib1.2-dev, libgtk1.2-dev, python2.3-dev, perl (= 5.6.0-16), libqt3-compat-headers, sharutils Section: devel Priority: optional
pkg-kde: commit - rev 126 - trunk/packages/kdebindings/debian
Author: domi-guest Date: 2004-05-05 15:10:37 -0600 (Wed, 05 May 2004) New Revision: 126 Modified: trunk/packages/kdebindings/debian/changelog trunk/packages/kdebindings/debian/control Log: kdebindings (4:3.2.2-4) unstable; urgency=low * debian/control: Removed Build-Depends on autoconf and automake. * debian/control: Added Build-Depends on sharutils for uudecode. -- Dominique Devriese [EMAIL PROTECTED] Wed, 5 May 2004 23:04:44 +0200 Modified: trunk/packages/kdebindings/debian/changelog === --- trunk/packages/kdebindings/debian/changelog 2004-04-30 10:46:11 UTC (rev 125) +++ trunk/packages/kdebindings/debian/changelog 2004-05-05 21:10:37 UTC (rev 126) @@ -1,3 +1,10 @@ +kdebindings (4:3.2.2-4) unstable; urgency=low + + * debian/control: Removed Build-Depends on autoconf and automake. + * debian/control: Added Build-Depends on sharutils for uudecode. + + -- Dominique Devriese [EMAIL PROTECTED] Wed, 5 May 2004 23:04:44 +0200 + kdebindings (4:3.2.2-3) unstable; urgency=low * debian/dirs: removed, no longer necessary. Modified: trunk/packages/kdebindings/debian/control === --- trunk/packages/kdebindings/debian/control 2004-04-30 10:46:11 UTC (rev 125) +++ trunk/packages/kdebindings/debian/control 2004-05-05 21:10:37 UTC (rev 126) @@ -1,5 +1,5 @@ Source: kdebindings -Build-Depends: autoconf (= 2.52), automake1.6, binutils-dev, debhelper ( 4.0.0), gawk, gettext, gij, gcj, libgcj4-dev, fastjar, kdelibs4-dev (= 4:3.1.4), libglib1.2-dev, libgtk1.2-dev, python2.3-dev, perl (= 5.6.0-16), libqt3-compat-headers +Build-Depends: binutils-dev, debhelper ( 4.0.0), gawk, gettext, gij, gcj, libgcj4-dev, fastjar, kdelibs4-dev (= 4:3.1.4), libglib1.2-dev, libgtk1.2-dev, python2.3-dev, perl (= 5.6.0-16), libqt3-compat-headers, sharutils Section: devel Priority: optional Maintainer: Dominique Devriese [EMAIL PROTECTED]
Bug#246631: konsole: incorrect window title
package konsole tags 246631 upstream forwarded 246631 http://bugs.kde.org/show_bug.cgi?id=68337 thanks Tomas Hoger writes: There's report about this problem on KDE's bug tracking system. See: http://bugs.kde.org/show_bug.cgi?id=68337 Just my 2c ;) Ok, thanks domi
Bug#237042: fixed upstream
package konqueror tags 237042 +fixed-upstream thanks Fixed in HEAD. cheers domi
Re: KDE322: libqt-mt = libqt3c102-mt
Chris Cheney writes: On Mon, Apr 26, 2004 at 03:39:09AM +0200, Dominique Devriese wrote: Henning Moll writes: On Sunday 25 April 2004 17:35, Dominique Devriese wrote: Henning Moll writes: Hi! Will this package be also renamed in the 'final release' of KDE322 for Woody? Yes. AFAIK, 'c102' stands for the transition from one gcc-version to another incompatible gcc-version, which is done in sid. Why should this affect woody? Oh, I see, I thought you were talking about unstable. /me should learn to read posts better... About the c102 thing: KDE 3.2 depends on Qt = 3.2.3, and I assume that the KDE packagers for woody have just ported the qt-x11-free packages from unstable to woody, instead of trying to adapt the woody packages to a newer Qt. I personally would probably have done the same. They should only have the c102 name if the packages are compiled with gcc 3.2 or newer. Hm, not sure if this really matters on woody ? But still, aren't there going to be other incompatibilities with the previous packages as well ? I am providing a package of k3b for woody. This package won't install with the current debs of KDE322. Sure, it's easy to correct this, but then, the package will fail on systems with older versions of KDE3. Can't you make your package depend on kdelibs4, and use the implicit kdelibs4- libqt3* dependency ? No. The package dependencies are generated at build time against whatever the package links to, plus manually set dependencies. So for kdelibs4 and libqt3c102-mt they are automatically set up. Hm, dpkg-shlibdeps should have a way to exclude a package dependency. cheers domi
Re: Problems with startup menu.
Adeodato Sim writes: * Jan Hudec [Sat, 24 Apr 2004 10:29:14 +0200]: I have a problem that Debian item disapeared from my start menu in KDE (quite recently, with update from 4:3.2.2-1 to 4:3.2.2-2). The /etc/menu-methods/kdelibs-bin is gone. It is reported by packages.debian.org as being in kdelibs-bin 4:3.2.2-2, but does not exist on my system (was deleted by preinst script, but never created nor does it exist in the .deb). I am not reporting this as a bug (yet), because I don't know what caused it. Please, tell me which things I should check. # apt-get install menu-xdg How could he not have this installed, since kdelibs-bin depends on it? cheers domi
Bug#245494: ksvg: svgdisplay gets signal 11 on some images
package ksvg tags 245494 +upstream forwarded 245494 http://bugs.kde.org/show_bug.cgi?id=80320 thanks Markus Schaber writes: Package: ksvg Version: 4:3.2.2-1 Severity: important Tags: sid Hi, on some SVG images (e. G. the attached one or the SVGAbout.svg that comes with Adobe SVG Plugin) svgdisplay gets killed with signal 11. The DrKonqi backtrace that shows up after the crash seems to be rather useless because of a lack of symbols. I run it under gnome, in a mixed testing/unstable environment. Some of the examples that come with batik squiggle work fine while others display distorted images, but I could not provoke a crash with those of the squggle examples I tried. Can you reproduce the problem? Yes, thanks, I've forwarded this bug report upstream. cheers domi
Re: Problems with startup menu.
Rene Engelhard writes: Hi, Dominique Devriese wrote: How could he not have this installed, since kdelibs-bin depends on it? Because it doesn't: $ apt-cache show kdelibs-bin | grep xdg Recommends: menu-xdg Hm, right, I was confused by apt-cache rdepends menu-xdg output. cheers domi
Re: Problems with startup menu.
Christopher Martin writes: It's only a Recommends, so a manual apt-get install menu-xdg is required. The kdelibs README.Debian needs a slight update to explain what and why is now required to get the Debian menu in KDE. Out of curiosity, why isn't menu-xdg a Recommends of kicker or kdebase, and perhaps documented there as well? I would guess that more people would look to kdebase or kicker for information than kdelibs or the dependencies of kdelibs-bin. Why is menu-xdg only a Recommended by kdelibs-bin ? IIUC, it is needed for Debian policy conformance, and as such should be a hard depends, no ? cheers domi
Bug#245820: [PATCH] Make KMilo compile on ppc
Hi, As I'm not sure who's maintaining kmilo, I'm sending this to some people holding copyright in the relevant files, and core-devel. The attached patch is supposed to fix a compile failure [1] in kdeutils/kmilo/powerbook2, which is caused by the pbbuttons library having renamed the macro TAG_BRIGHTNESS to TAG_LCDBRIGHTNESS ( as documented in the changelog [2] ). Ok to commit this patch to BRANCH and HEAD ? cheers domi Footnotes: [1] http://buildd.debian.org/fetch.php?pkg=kdeutilsver=4%3A3.2.2-1arch=powerpcstamp=1082850620file=logas=raw [2] http://www.cymes.de/members/joker/projects/pbbuttons/clog-gtkpbbuttons.txt Index: kmilo/powerbook2/pb_monitor.cpp === RCS file: /home/kde/kdeutils/kmilo/powerbook2/pb_monitor.cpp,v retrieving revision 1.4.2.2 diff -u -r1.4.2.2 pb_monitor.cpp --- kmilo/powerbook2/pb_monitor.cpp 27 Mar 2004 17:49:46 - 1.4.2.2 +++ kmilo/powerbook2/pb_monitor.cpp 25 Apr 2004 16:53:09 - @@ -36,6 +36,12 @@ //among which is template... #undef template #include pbb.h + +// TAG_BRIGHTNESS was renamed to TAG_LCDBRIGHTNESS in pbbuttons +// 0.6.1-2 +#ifndef TAG_LCDBRIGHTNESS +#define TAG_LCDBRIGHTNESS TAG_BRIGHTNESS +#endif } #define BUFFERLEN 200 @@ -79,7 +85,7 @@ rc = Monitor::Mute; m_progress = (int)tag-data; break; - case TAG_BRIGHTNESS: + case TAG_LCDBRIGHTNESS: rc = Monitor::Brightness; m_progress = ((int)tag-data)*100/15; break;
Bug#245820: KDE_3_2_BRANCH: kdeutils/kmilo/powerbook2
CVS commit by domi:
Make it compile with pbbuttons = 0.6.1-2
CCMAIL:[EMAIL PROTECTED]
M +7 -1 pb_monitor.cpp 1.4.2.3
--- kdeutils/kmilo/powerbook2/pb_monitor.cpp #1.4.2.2:1.4.2.3
@@ -37,4 +37,10 @@ extern C {
#undef template
#include pbb.h
+
+// TAG_BRIGHTNESS was renamed to TAG_LCDBRIGHTNESS in pbbuttons
+// 0.6.1-2
+#ifndef TAG_LCDBRIGHTNESS
+#define TAG_LCDBRIGHTNESS TAG_BRIGHTNESS
+#endif
}
@@ -80,5 +86,5 @@ Monitor::DisplayType PowerBookMonitor::p
m_progress = (int)tag-data;
break;
-case TAG_BRIGHTNESS:
+case TAG_LCDBRIGHTNESS:
rc = Monitor::Brightness;
m_progress = ((int)tag-data)*100/15;
Bug#245820: Acknowledgement (kdeutils: FTBFS on powerpc (missing TAG_BRIGHTNESS))
Petter Reinholdtsen writes: The constant is supposed to be in pbbtags.h from package pbbuttonsd-dev. It was recently upgraded to a newer version (0.5.9-1), and this new version do not a constant have TAG_BRIGHTNESS. This bug has been fixed in 3_2_BRANCH and HEAD upstream. This means it will be fixed in all further kde releases, notably kde 3.2.3. cheers domi
Re: KDE322: libqt-mt = libqt3c102-mt
Henning Moll writes: Hi! Will this package be also renamed in the 'final release' of KDE322 for Woody? Yes. This would break compatibility with many (all?) existing KDE applications packaged for KDE 322. Indeed, along with the numerous other backward incompatible changes. I am providing a package of k3b for woody. This package won't install with the current debs of KDE322. Sure, it's easy to correct this, but then, the package will fail on systems with older versions of KDE3. That's why you're supposed to provide two packages if you want them to work on two different Debian distributions. cheers domi
Re: KDE322: libqt-mt = libqt3c102-mt
Henning Moll writes: On Sunday 25 April 2004 17:35, Dominique Devriese wrote: Henning Moll writes: Hi! Will this package be also renamed in the 'final release' of KDE322 for Woody? Yes. AFAIK, 'c102' stands for the transition from one gcc-version to another incompatible gcc-version, which is done in sid. Why should this affect woody? Oh, I see, I thought you were talking about unstable. /me should learn to read posts better... About the c102 thing: KDE 3.2 depends on Qt = 3.2.3, and I assume that the KDE packagers for woody have just ported the qt-x11-free packages from unstable to woody, instead of trying to adapt the woody packages to a newer Qt. I personally would probably have done the same. I am providing a package of k3b for woody. This package won't install with the current debs of KDE322. Sure, it's easy to correct this, but then, the package will fail on systems with older versions of KDE3. Can't you make your package depend on kdelibs4, and use the implicit kdelibs4-libqt3* dependency ? cheers domi
Re: KDE 3.2.2 for Woody... Careful upgrading..
Jesús Roncero Franco writes: Ok, I'd remake my question. If today's preferred method of installing and upgrading software in debian is apt-get, and it has some problems, why is this the first time I heard of it? I mean, from a user perspective, one that reads many debian related mailing lists, apt-get is the most recommended tool, not aptitude. Then you read the wrong mailing lists. I sometimes work on Debian KDE bug reports, and using apt-get for major upgrades is a known, and not-going-to-be-fixed-any-time-soon bug. Anyway, how do the debian kde guys make it to do it almost painless? Well erm, making the dependency statements as simple as possible helps, but apt-get dist-upgrade currently still fails on upgrading from woody to testing iirc, and we have no idea how to fix it. cheers domi
Re: KDE 3.2.2 for Woody... Careful upgrading..
Hendrik Sattler writes: The latter is much, much more informative and better tells me about the current situation. aptitude is even wrong here (the lynx package is only removed, not purged). From dpkg: rc lynx 2.8.4.1b-1 I have no idea about the interface of all these things. Furthermore, it's about which tool you want to use to upgrade, apt-cache is purely an informational tool. However, it still has a low version number, there may be reasons for it. AFAIK, it's considered stable. PS: Please DO NOT send me a copy of an answer per PM gg:Mail-Followup-To: cheers domi
Bug#242641: kdm does not obey pam_limits
package kdm forwarded 242641 http:/bugs.kde.org/show_bug.cgi?id=80032 tags 242641 +upstream thanks Xavier Hienne writes: Actually, Kees is right, this a kdm issue. I checked kdebase-3.2.1/kdm/backend/client.c and, at line 1142, there are two function calls whose return value is not used : Thanks, your comment seemed very useful, and I have forwarded this bug report upstream. Thanks domi
Re: KDE 3.2.2 for Woody... Careful upgrading..
Michael Peddemors writes: Korganizer ate my calendar.. (Backup your .ics, actually my fault, anyone upgrading should always backup their .kde directory, JUST IN CASE, however it still should not have ate it.) Can you file a bug report about that on bugs.kde.org, so people there can try to diagnose and fix ? First of all, apparently you're using apt-get install for upgrading packages. This is a bad idea. Use dselect, aptitude, synaptic, these do a much better job at automatically handling dependencies. OpenOffice no longer wants to install Sorry, but the following packages have unmet dependencies: openoffice.org1.1-bin: Depends: libfreetype6 ( 2.1.0) but 2.1.5-1woody2 is to be installed That of course has nothing to do with KDE. However, you need to remove the old openoffice.org1.1-bin, as it is replaced by openoffice.org-bin. See above, this would have been fixed by a proper pkg mgt tool. kdeaddons won't install... Not sure why.. (Actually, NOW it does, but only after installing kdeaddons-kfile-plugins, not sure why that didn't automagically work) See above: use a proper mgt tool. Fonts all changed.. (maybe new defaults, and didn't keep the old settings.) No idea. komba2 is now gone..(That I understand, I guess) That's strange, it is still there on my system. Lost 'psi' as it needs libqt3-mt, but that will remove everything.. as we now use libqt3c102-mt (Strange the naming for qt3-dev-tools stayed the same) If you're going to be using unstable, you should also use psi from unstable. See above: use a proper pkg mgt tool. Something replaces kdepim-libs.. I had to remove that one, it got jammed up as well.. This is intended. See above: use a proper pkg mgt tool. cheers domi
Re: KDE 3.2.2 for Woody... Careful upgrading..
Michael Peddemors writes: If you notice, I am NOT using unstable, but WOODY.. Again, I am doing testing of the upgrade, for our clients are going to run into the same issues.. This is to point out that there are some dependency problems that prevent an apt-get upgrade, or apt-get install in moving to this version of KDE.. I have the ability to deal with these issues, others on the list may not. Perhaps you missed the point of my last mail: DO NOT USE APT-GET FOR MAJOR UPGRADES ! cheers domi
Re: KDE 3.2.2 for Woody... Careful upgrading..
Hendrik Sattler writes: Am Tuesday 20 April 2004 18:09 schrieb Dominique Devriese: Michael Peddemors writes: If you notice, I am NOT using unstable, but WOODY.. Again, I am doing testing of the upgrade, for our clients are going to run into the same issues.. This is to point out that there are some dependency problems that prevent an apt-get upgrade, or apt-get install in moving to this version of KDE.. I have the ability to deal with these issues, others on the list may not. Perhaps you missed the point of my last mail: DO NOT USE APT-GET FOR MAJOR UPGRADES ! Hmm, upgrading KDE is a major upgrade? Yes. Meaning that it needs uninstalling other packages and installing new ones instead. Additionally, I disagree with you. I do not like dselect. aptitute may be good but the interface really sucks It's not about an interface, it's about apt-get's logic being insufficient to properly figure out the correct solution for dependency problems. Use either dselect, aptitude, or whatever other pkg mgt app you prefer, that has proper dependency resolution code, but NOT APT-GET. All the bugs in the OP's mail were caused by this. If you want to use apt-get anyway, then at least use apt-get dist-upgrade. cheers domi
Re: KDE 3.2.2 for Woody... Careful upgrading..
Jesús Roncero Franco writes: On Tuesday 20 April 2004 20:39, Dominique Devriese wrote: Yes. Meaning that it needs uninstalling other packages and installing new ones instead. Additionally, I disagree with you. I do not like dselect. aptitute may be good but the interface really sucks It's not about an interface, it's about apt-get's logic being insufficient to properly figure out the correct solution for Well, then how are the official debian sid packages made? Those seem to upgrade fine. Maybe it is that people is too used to apt-get dist-upgrading quite easily. Why then debian relies on apt-get and not on aptitude :-? First, there are difficult apt versions, apt's logic is already a little bit better in sarge and sid. It's just very bad in woody, and Debian officially recommends to not use it for upgrading to sarge. Second, there's a difference between apt-get dist-upgrade on the one hand and apt-get install and apt-get upgrade on the other hand. The OP was using the latter, and these are completely unsufficient for major upgrades, which is what I was trying to make very clear with the capitalised text. apt-get dist-upgrade is not all too bad ( in sarge ), but still does not succeed in completely figuring out the dependencies properly in all situations. Third, the reason why Debian relies on apt-get ( meaning that apt-get is priority important, not at all meaning that Debian can't be used without apt-get ), and not on aptitude is simply that apt came first. Aptitude is strictly better, and if hit had been available at the time, I'm sure aptitude would have been chosen over apt-get. Fourth, just a last comment: as a developer who has looked at the dpkg and apt code ( and you may believe me or not, I don't care, I'd just like to make this clear ): Debian's packaging tools are pretty poorly coded. People often argue about how great apt-get is, compared to Red Hat's and Mandrake's tools, but what they mean is that the Debian package repository is pretty good, this has nothing to do with apt. The problems with dpkg, apt and aptitude are, briefly: 1 They do not properly make use of any sort of database. dpkg uses its data in a very slow manner. Apt-get uses a different database, and uses it in a very slow manner as well. Both suck. 2 They don't provide certain extremely useful features like keeping track of which packages were *explicitly* installed and which weren't, in order to provide much more useful dependency resolution. 3 They don't have a proper graphic, user-friendly interface. This is partly fixed by certain recent programs like aptitude, synaptic and others, but none of these succeed in reaching the level of ease of use necessary for ordinary users, partly because of the above reasons as well. Anyway, IMHO, a lot of things here require fixing. If I had time, I'd love to write a proper apt replacement, but I don't have time, unfortunately. cheers domi
Bug#227538: kdelibs: mixed results on 3.2.2
Itai Seggev writes:
On Sat, Apr 17, 2004 at 10:52:27PM +0200, Dominique Devriese wrote:
Itai Seggev writes:
OK, so this is the only place in the source where the error
message appears:
QStringList keys() const
{
QSettings cfg;
KStyleDirs::dirs()-addToSearch( config, cfg );
QStringList keys; bool ok;
keys = cfg.readListEntry( /kthemestyle/themes, ok); if
( !ok )
qWarning( KThemeStyle cache seems corrupt!\n );
//Too
bad one can't i18n this :-(
return keys;
}
For reference: this code comes from
kdelibs/kstyles/kthemestyle/kthemestyle.cpp.
This code is the same in both debian and pristine sources (which
I guess makes sense, given the recompiling the debian sources
fixes the problem). It's not entirely clear to me how this code
actually ever works, but apparently it does.
Why wouldn't it work ?
I didn't say it wouldn't, I just said I don't understand how it
works. I did locate kthemestyle/themes and got null output, so I
guess that string is some sort of key and not a physical
directory. However, I don't really know the internals of KDE.
What happens there is a QSettings class is created, the current config
resource dirs are added to its search path. Then, QSettings is told
to get the config entry /kthemestyle/themes which it is supposed to
get from a file kthemestylerc in its search path. I can't see why
that fails for you. I'd like to debug this, but I can't since I don't
get the error.
However, I'm no closer to figuring out why I'm getting this
message.
Can you send us the output of the command locate kthemestylerc
and the contents of the file /etc/kde3/kthemestylerc ? Possibly,
152:cavy:/usr/share/apps/kstyle/themes locate kthemestylerc
/etc/kde3/.kthemestylerc.lock /etc/kde3/kthemestylerc
/usr/local/kde/share/config/kthemestylerc
/usr/local/kde/share/config/.kthemestylerc.lock
/usr/local/src/kde/kdelibs/kstyles/themes/kthemestylerc
All three copies of the file are identical:
153:cavy:/usr/share/apps/kstyle/themes cat /etc/kde3/kthemestylerc
[General] themes=marble^eriscos^esystem^esystemalt^e
[marble] file=marble.themerc
[riscos] file=riscos.themerc
[system] file=system.themerc
[systemalt] file=systemalt.themerc
Right. It means you have installed a local version of KDE, right ?
Do you happen to have set KDEDIRS to something or have done other
uncommon things ? Can you check if the problem goes away if you
remove those settings ?
thanks
domi
Re: simplifying enhancing kde manpages
Achim Bohnet writes: I'm not sure if it's okay to cp qts debug.html in a (L)GPL manpage. in a GPL manpage: yes, otherwise: probably not, but it's not like they're going to sue you over cp'ing some stuff out of their docs.. cheers domi
Bug#126406: kppp: Alternative for using noauth as suggested by README
Ernst Kloppenburg writes: Am Samstag, 17. April 2004 09:16 schrieb Dominique Devriese: Ernst Kloppenburg writes: Putting noauth into the kppp configuration normally is not possible, because noauth is a privileged option. This is solved by 'privgroup dip'. Oh, I see. Then shouldn't this bug be reassigned to the ppp package ? In my eyes the 'privgroup dip' think is only a workaround to make kppp work, not a real solution. Thus -- I think -- this only belongs in the kppp README. But maybe the ppp maintainer has another opinion. I see. What do you think about this text for /usr/share/doc/kppp/README.Debian ( replacing the current text about the issue ) ? kppp and immediate disconnects == The ppp protocol includes an authentication scheme. Users of a ppp daemon are supposed to check the authentication of the user on the other end. However, some ISP's don't bother to properly send this authentication, because most clients don't check it anyway. The Linux version does check it by default, leading to immediate disconnects. The solution to this is to set the noauth option in your kppp configuration. However, in order for this to work ( noauth is a priviledged option of the ppp daemon ), you need to add privgroup dip to /etc/ppp/options and/or files like /etc/ppp/options.ttyS0 (For example). Feel free to submit an improved version of the above text if you think it is not clear enough, or if there are errors in it or if you have other remarks. thanks domi
Re: Why fonts are available with X and not with KDE ?
Herv writes: Hi, I have a trouble with fonts ... I can see some fonts under X ... with xfontsel for example ... or with this command : snip This is a development mailing list. Please ask this kind of question on [EMAIL PROTECTED] thanks domi
Bug#240329: knode package fails to launch - knode wrapper works perfectly
Robert Cheramy writes: Package: knode Version: 4:3.2.2-1 Severity: normal Followup-For: Bug #240329 Hi, I spend some time today trying to find where this knode bug could come from. While recompiling kdepim with debug options and a few more kdDebug lines in knode source, I tried to start knode from the object folder : /usr/src/kdepim-3.2.2/obj-i386-linux/knode It worked ! The installed deb package still would not start (!) As you may know, /usr/src/kdepim-3.2.2/obj-i386-linux/knode is a bash wrapper and the knode I start (/usr/bin/knode) is an ELF excutable. I rebuilt the packages ifrom scratch to be sure this behaviour is reproducible with standard packages, and it is. I have no idea what the wrapper does, and I hope this could be somewhat useful to you... Thanks for the information. The symbol that is said to be undefined should be defined in the file /usr/lib/libkdenetwork2.so.2. Can you check whether it is available, and if so, send us the output of the following command: nm --dynamic /usr/lib/libkdenetwork2.so.2 | grep _ZN15KScoringManagerC2ERK7QString Thanks domi
Re: manually compile kdebindings?
Bauduin Raphael writes: Dominique Devriese wrote: Raphael Bauduin writes: Hi, as kdebindings arent available in debian unstable, has anyone already compiled it manually? I didn't search a lot, but when I tried it complained it didn't find the multithreaded qt, although it was really there. I am working on Debian packages for it. Looking forward to it! Yes, they're pretty much ready, but I need someone to upload them for me ( I am not a Debian Developer yet, and the process of becoming one is pretty long unfortunately ). Your error is something pretty basic, namely that you need to install the libqt3-mt-dev package. I have it, but the libqt3-mt package is replaced by libqt3c102-mt, which is also installed: ii libqt3-mt-dev 3.2.3-2 ii libqt3c102-mt 3.2.3-2 I also had libqt3c102 installed, but even when I remove it, I get the same problem. Yes, you only need libqt3c102-mt and libqt3-mt-dev. /usr/lib/qt configure:27097: rm -rf SunWS_cache; g++ -o conftest -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -O2 -fno-exceptions -fno-check-new -fno-common -I/usr/include/qt3 -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -L/usr/share/qt3/lib -L/usr/X11R6/lib conftest.cc -lqt-mt -lpng -lz -lm -ljpeg -ldl -lXext -lX11 -lSM -lICE -lpthread 15 /tmp/ccz7t5hU.o(.text+0xb): In function `main': : undefined reference to `QString::null' snip Hm, this is a pretty strange error. The test program definitely gets linked against libqt-mt, and that library is supposed to define the QString::null symbol. What output does the following command generate ? nm --dynamic /usr/share/qt3/lib/libqt-mt.so | c++filt | grep QString::null cheers domi
Re: manually compile kdebindings?
Bauduin Raphael writes: Dominique Devriese wrote: [zip] If you're interested in testing the packages, they are available here: http://www.kalyxo.org/~domi/kdebindings/ All feedback is very welcome ! I'll test the ruby bindings when available ;-) Then you'll have to wait until at least the next kdebindings release, cause they aren't included in 3.2. This may still take a couple of months. Possibly, there could be an earlier release of kdebindings, but this is not yet decided upon. cheers domi
Re: manually compile kdebindings?
Bauduin Raphael writes: using bash completion: bidibule:/usr/share/qt3/lib# ls ../../../lib ls: ../../../lib: No such file or directory #it completes lib as file (puts a space after lib), but when hitting enter, it doesn't find the file... I'm sick, so my brain is like in the London fog, and it wouldn't surprise me if I had missed something very obvious ;-) This is very strange. Not sure what you're doing wrong, but I suggest you fix it first, and see if that doesn't fix your compile problems by any chance as well. cheers domi
Bug#244177: knotes: knotes has become useless - opens up lots of new notes every restart
package knotes tags 244177 +sid merge 244177 237184 forwarded 237184 http://bugs.kde.org/show_bug.cgi?id=72888 thanks domi Gabor Gludovatz writes: Package: knotes Version: 4:3.2.1-1 Severity: important Everytime I start the knotes application, its stored notes count gets doubled. Many new notes appear with names [Actions] and [Display]. Most of these new notes cannot be showed, only make the screen appear total black and no application can be seen behind them. Only ALT-F4 solves the problem. I've been using this new version for a few days, and until today it worked perfectly. But now I'm always deleting the new notes in vain, the next start they show up again. We're aware of this bug, it has been fixed upstream, and the fix will be included in KDE 3.2.2. cheers domi
Bug#126406: kppp: Alternative for using noauth as suggested by README
Ernst Kloppenburg writes: Hello, On Thu, Apr 15, 2004 at 09:18:20 +0200, Dominique Devriese wrote: Ernst Kloppenburg writes: Package: kppp Version: 4:3.1.5-1 Severity: normal Followup-For: Bug #126406 as the original bug reporter says, /usr/share/doc/kppp/README.Debian gives the very questionable advice to set noauth in /etc/ppp/options Are you sure that you know what this option does ? It does not mean that all users are allowed to change ppp settings. It means that the ppp client does not try to check the authentication of the ppp server of your ISP. Quite a lot of ISPs have broken authentication configs on their servers, because windows clients never check them anyway. I think I clearly understand the noauth option: - if noauth is given, your pppd does not require the ppp server of the ISP to authenticate (which would not be possible) - there is a second case, where noauth applies: when somebody dials into your machine (which may be wanted or not). It is for this second case, that putting 'noauth' into the options file is not recommended. Therefore, normally all provider configurations in /etc/ppp/peers do contain 'noauth'. Putting noauth into the kppp configuration normally is not possible, because noauth is a privileged option. This is solved by 'privgroup dip'. Oh, I see. Then shouldn't this bug be reassigned to the ppp package ? cheers domi
Bug#227538: kdelibs: mixed results on 3.2.2
Itai Seggev writes:
OK, so this is the only place in the source where the error message
appears:
QStringList keys() const
{
QSettings cfg;
KStyleDirs::dirs()-addToSearch( config, cfg );
QStringList keys; bool ok;
keys = cfg.readListEntry( /kthemestyle/themes, ok); if (
!ok )
qWarning( KThemeStyle cache seems corrupt!\n ); //Too
bad one can't i18n this :-(
return keys;
}
For reference: this code comes from
kdelibs/kstyles/kthemestyle/kthemestyle.cpp.
This code is the same in both debian and pristine sources (which I
guess makes sense, given the recompiling the debian sources fixes
the problem). It's not entirely clear to me how this code actually
ever works, but apparently it does.
Why wouldn't it work ?
However, I'm no closer to figuring out why I'm getting this
message.
Can you send us the output of the command locate kthemestylerc and
the contents of the file /etc/kde3/kthemestylerc ? Possibly,
something strange has happened to that file, or you have a file by
that name from some other location.
(Perhaps this is only the result of an upgrade? If I get
the chance, I'll try install the pacakges on a pristine partition
and see what happens).
k
thanks
domi
Bug#241259: kdemultimedia: [m68k/unstable] cp: cannot stat `./debian/tmp/usr/lib/kde3/kfile_flac.la': No such file or directory
Chris Cheney writes: I didn't notice what was going on here at first since I had assumed that domi had actually checked that kdemultimedia didn't build-dep on libflac-dev which it does. Hm, I seem to have missed it when I checked :( I am not sure what the problem is and it may even be fixed by now. If the upload of kdemultimedia 3.2.2-1 still fails like before I will have to look into the issue a lot closer. It builds fine on i386, but doesn't seem to even try to go into the kfile-plugins/flac dir on the other archs. Apparently, the same failure occurs in 3.2.2 as well. I've done some research, and the failure appears to be that the function FLAC__seekable_stream_decoder_process_single is not defined in libFLAC.so on non-i386 arches. On my system, it definitely is there ( I run i386 ). I don't understand why this would be the case, but my guess is a bug in libflac. Reassign to libflac4 ? cheers domi
Re: kdemultimedia 3.2.2-1 still fails to build on other archs...
Chris Cheney writes: I am not sure what is going on here but kdemultimedia builds fine on i386 inside a clean chroot(!) but says the below on other archs: Anyone happen to have any idea what is going on? Well, this is #241259, see my comment there. cheers domi
