Re: Announcing the availability of first Qt 3.3 packages
Dominique Devriese [EMAIL PROTECTED] writes: 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 Well, anything under 500K or so I consider to be quite small. For a full Qt development environment (i.e. if you're doing Qt development, you really need all this stuff) with these 3.3.2 packages, you need: 41k libqt3-mt-dev_3.3.2-0pre1_i386.deb 2.9M libqt3c102-mt_3.3.2-0pre1_i386.deb 335k libqt3-headers_3.3.2-0pre1_all.deb 71k libqt3-compat-headers_3.3.2-0pre1_all.deb 1.1M qt3-dev-tools_3.3.2-0pre1_i386.deb 5.2M qt3-doc_3.3.2-0pre1_all.deb 324k qt3-linguist_3.3.2-0pre1_i386.deb 85k qt3-qtconfig_3.3.2-0pre1_i386.deb 229k qt3-assistant_3.3.2-0pre1_i386.deb 80k libqt3-i18n_3.3.2-0pre1_all.deb Total: 11M I left out qt3-designer because I don't use it, and to show the worst case scenario for my argument. A minimal build environment would require: 41k libqt3-mt-dev_3.3.2-0pre1_i386.deb 2.9M libqt3c102-mt_3.3.2-0pre1_i386.deb 335k libqt3-headers_3.3.2-0pre1_all.deb 71k libqt3-compat-headers_3.3.2-0pre1_all.deb 1.1M qt3-dev-tools_3.3.2-0pre1_i386.deb Total: 4.5M A Non-developer user of the libraries would need: 2.9M libqt3c102-mt_3.3.2-0pre1_i386.deb 85k qt3-qtconfig_3.3.2-0pre1_i386.deb 80k libqt3-i18n_3.3.2-0pre1_all.deb Total: 3.0M 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 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. 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? And the package name in no way suggests any difference from qt3-dev-tools. 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 . Full a full Qt development environment with these packages: 1.6Mlibqt3-mt-dev_3.3.2-1_i386.deb 3.6Mlibqt3c102-mt_3.3.2-1_i386.deb 17M qt-x11-free_3.3.2.orig.tar.gz 4.8Mqt3-dev-tools_3.3.2-1_i386.deb 6.3Mqt3-doc_3.3.2-1_all.deb Total: 17M So there's a 6M difference, 4M of which are due to qt3-designer (I'd have no problem splitting out qt3-designer). The rest of the difference is presumably due to the random stuff missing from Madkiss's packages, as seen in all the bug reports. A minimal build environment would require: 1.6Mlibqt3-mt-dev_3.3.2-1_i386.deb 3.6Mlibqt3c102-mt_3.3.2-1_i386.deb Total: 5.1M A non-developer user would need: 3.6Mlibqt3c102-mt_3.3.2-1_i386.deb 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) with fewer bugs (no missing files). -- You win again, gravity!
Bug#248468: juk: instantly crashes if output set to gstreamer
running: #apt-get install gstreamer-plugins fixes that problem for me. 0xDCB79B8B.asc Description: application/pgp-keys
Bug#227538: same problem with plastik
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have the same problem with the plastik theme in KDE. After the last upgrade I loaded the kcontrol from xfce and selected plastik because the former style was uninstalled, but after I started kcontrol later Plastik was disappeared from the list, and the other themes were okay. After reading through the list and creating a symlink from /etc/kde3 to /usr/share/config I could see all the old themes again, but plastik is still missing. - -- Clemens Schwaighofer - IT Engineer System Administration == TEQUILA\Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 http://www.tequila.co.jp == -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAzrCUjBz/yQjBxz8RAv8IAKDf/1XLH9c7GOQ08MAFZTtq0vzODwCgiw59 hs7+ua3x7jl7cnS9fsEDc7M= =voi6 -END PGP SIGNATURE-
Bug#254519: Can no longer manually pick a download location
Package: kget Version: 4:3.2.2-1 Severity: normal After specifying a downloadfolder for .deb files (~/download/deb) *all* files are automatically downloaded to that directory. Removing the default folder listing from the 'Folders' tab didn't restore the default behaviour of asking for a location. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.6-1-686 Locale: LANG=C, LC_CTYPE=C Versions of packages kget depends on: ii kdelibs4 4:3.2.3-2 KDE core libraries ii libart-2.0-2 2.3.16-5 Library of functions for 2D graphi ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-5client library to control the FAM ii libgcc1 1:3.3.4-1 GCC support library ii libice6 4.3.0.dfsg.1-4 Inter-Client Exchange library ii libjpeg62 6b-9 The Independent JPEG Group's JPEG ii libpcre3 4.5-1.1Perl 5 Compatible Regular Expressi ii libpng12-01.2.5.0-6 PNG library - runtime ii libqt3c102-mt 3:3.2.3-3 Qt GUI Library (Threaded runtime v ii libsm64.3.0.dfsg.1-4 X Window System Session Management ii libstdc++51:3.3.4-1 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-4 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-4 X Window System miscellaneous exte ii libxrender1 0.8.3-7X Rendering Extension client libra ii xlibs 4.3.0.dfsg.1-4 X Window System client libraries m ii zlib1g1:1.2.1.1-3compression library - runtime -- no debconf information
Bug#227538: same problem with plastik
Hi, After reading through the list and creating a symlink from /etc/kde3 to /usr/share/config I could see all the old themes again, but plastik is still missing. Try upgrading your kdeartwork-style to 3.2.3 (was uploaded about 12h ago, should appear on the mirrors tomorrow) -- this should fix your problem. Ben.
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
Bug#254529: Konqueror crashes when copying files with same name
To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Konqueror crashes when copying files with same name Package: konqueror Version: 4:3.2.2-1, all from 3.2.x up to now Copying or moving files directly from source to destination directory with both directorys opened with Konqueror, konqueror crashes and the kde crash manager pops up when a file with the same name exists in the destination directory. Konqueror does not ask to overwrite or rename the file, but simply crashes immediately. I am using debian testing/unstable, kernel vanilla 2.6.6, updated every few days, with kde 3.2.2.
reassigning screensaver wish
reassign 240154 kdelibs4 thanks mate Hi.. this is a generic screensaver issue, assigning to kdelibs4 accordingly. b.
Bug#254593: libkdefx.so.4: undefined symbol: _ZN7QPixmap6detachEv
Package: kdelibs Version: 4:3.2.3-2 Severity: grave 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 I am running Debian Sid, debian-patched linux-kernel 2.6.6 this is my first bug-report, sorry if it has some errors, please tell me how to do it better, or if you need more information, joerg Aufnehmen, abschicken, nah sein - So einfach ist WEB.DE Video-Mail: http://freemail.web.de/?mc=021200
Bug#246350: #246350 KIconLoader errors
The issue #246350 about KIconLoader errors seems to be discussed at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241283 There is also a user-configurable workaround there. Good to know, because otherwise under GDM the ~/.xsession-errors stops quickly with: ...Too much output, ignoring rest... With kind regards, Tuukka Hastrup -- -- Trying to catch me? Just follow up my Electric Fingerprints -- To help you: [EMAIL PROTECTED] http://www.iki.fi/Tuukka.Hastrup/ IRCNet: Stugge/tuukkah @#pii,#fenfire,#ynna Jabber ID: [EMAIL PROTECTED], ICQ #11321669
Bug#254595: kdm does listen on udp/177 by default
Package: kdm Version: 4:3.2.2-1 Severity: minor Tags: security only changing the config file by hand solves this... [Xdmcp] Enable=false -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.6-1-686 Locale: LANG=C, LC_CTYPE=C Versions of packages kdm depends on: ii debconf 1.4.25 Debian configuration management sy ii kdebase-bin 4:3.2.2-1 KDE Base (binaries) ii kdelibs4 4:3.2.2-2 KDE core libraries ii libart-2.0-2 2.3.16-5 Library of functions for 2D graphi ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-5client library to control the FAM ii libgcc1 1:3.3.3-9 GCC support library ii libice6 4.3.0.dfsg.1-1 Inter-Client Exchange library ii libpam-runtime0.76-21Runtime support for the PAM librar ii libpam0g 0.76-21Pluggable Authentication Modules l ii libpng12-01.2.5.0-6 PNG library - runtime ii libqt3c102-mt 3:3.2.3-2 Qt GUI Library (Threaded runtime v ii libsm64.3.0.dfsg.1-1 X Window System Session Management ii libstdc++51:3.3.3-9 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-1 X Window System miscellaneous exte ii libxrender1 0.8.3-7X Rendering Extension client libra ii libxtst6 4.3.0.dfsg.1-1 X Window System event recording an ii xbase-clients 4.3.0.dfsg.1-1 miscellaneous X clients ii xlibs 4.3.0.dfsg.1-1 X Window System client libraries m ii zlib1g1:1.2.1.1-3compression library - runtime -- debconf information: kdm/stop_running_server_with_children: false * shared/default-x-display-manager: kdm kdm/daemon_name: /usr/bin/kdm
Re: Announcing the availability of first Qt 3.3 packages
On Tue, Jun 15, 2004 at 02:40:57PM -0700, Brian Nelson wrote: Martin Loschwitz [EMAIL PROTECTED] writes: If your Qt package were properly maintained, I wouldn't bother you with So you admit you are bothering? That's a point to start. this. However, I think it's been in quite poor condition for a very long time now and I don't see them getting any better. Furthermore, you completely ignore every bug filed against the package. Start maintaining your package properly before you flame me. The only serious trouble in Qt3 until some days ago was that XCursor made it imposslbe to compile Qt3. Nothing else. You need to distinguish between I think they are poorly maintained and they are poorly maintained. -- You win again, gravity! -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : [EMAIL PROTECTED][EMAIL PROTECTED] `. `'` http://www.madkiss.org/people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.0! See http://www.debian.org/ signature.asc Description: Digital signature
Help with Qt internationalization
I'm dealing with a bug in the Qt pluging of Licq: #123836 Licq uses the Qt interfaces for message translation. Apparently, Qt ignores the standard locale environment variables. None of LC_ALL=fr_FR LC_ALL=fr LC_MESSAGES=fr_FR LC_MESSAGES=fr succeed to change the language. But LANG=fr LANG=fr_FR work. I also notice that none of these environment variables work to change the language of a random KDE application like konsole. Can anyone explain how the Qt internationalization facilities work and how the user is to set up his environment properly?
KDE_3_2_BRANCH: kdesdk/debian
CVS commit by benb: Packaging for 3.2.3. M +9 -0 changelog 1.53.2.8 M +1 -1 control 1.54.2.8 M +2 -2 kdesdk-doc-html.doc-base.cervisia 1.1.2.2 M +2 -2 kdesdk-doc-html.doc-base.kbabel 1.1.2.2 M +2 -2 kdesdk-doc-html.doc-base.kcachegrind 1.1.2.2 M +2 -2 kdesdk-doc-html.doc-base.umbrello 1.1.2.2 --- kdesdk/debian/changelog #1.53.2.7:1.53.2.8 @@ -1,2 +1,11 @@ +kdesdk (4:3.2.3-1) unstable; urgency=low + + * New upstream bugfix release. + * Rebuilt against STL-enabled Qt and corresponding kdelibs. + * Use real paths for doc-base entries instead of symlinked paths +(closes: #247690). + + -- Ben Burton [EMAIL PROTECTED] Wed, 16 Jun 2004 08:41:42 +1000 + kdesdk (4:3.2.2-1) unstable; urgency=low --- kdesdk/debian/control #1.54.2.7:1.54.2.8 @@ -3,5 +3,5 @@ Priority: optional Maintainer: Ben Burton [EMAIL PROTECTED] -Build-Depends: automake1.7, binutils-dev, bison, debhelper ( 4.0.0), flex, kdelibs4-dev (= 4:3.2.0), libdb4.0-dev, libqt3-mt-dev (= 3:3.2.1) +Build-Depends: automake1.7, binutils-dev, bison, debhelper ( 4.0.0), flex, kdelibs4-dev (= 4:3.2.3-2), libdb4.0-dev, libqt3-mt-dev (= 3:3.2.3-3) Standards-Version: 3.6.1 --- kdesdk/debian/kdesdk-doc-html.doc-base.cervisia #1.1.2.1:1.1.2.2 @@ -6,5 +6,5 @@ Format: HTML -Index: /usr/share/doc/cervisia/html/index.html -Files: /usr/share/doc/cervisia/html/*.html +Index: /usr/share/doc/kde/HTML/en/cervisia/index.html +Files: /usr/share/doc/kde/HTML/en/cervisia/*.html --- kdesdk/debian/kdesdk-doc-html.doc-base.kbabel #1.1.2.1:1.1.2.2 @@ -9,5 +9,5 @@ Format: HTML -Index: /usr/share/doc/kbabel/html/index.html -Files: /usr/share/doc/kbabel/html/*.html +Index: /usr/share/doc/kde/HTML/en/kbabel/index.html +Files: /usr/share/doc/kde/HTML/en/kbabel/*.html --- kdesdk/debian/kdesdk-doc-html.doc-base.kcachegrind #1.1.2.1:1.1.2.2 @@ -6,5 +6,5 @@ Format: HTML -Index: /usr/share/doc/kcachegrind/html/index.html -Files: /usr/share/doc/kcachegrind/html/*.html +Index: /usr/share/doc/kde/HTML/en/kcachegrind/index.html +Files: /usr/share/doc/kde/HTML/en/kcachegrind/*.html --- kdesdk/debian/kdesdk-doc-html.doc-base.umbrello #1.1.2.1:1.1.2.2 @@ -8,5 +8,5 @@ Format: HTML -Index: /usr/share/doc/umbrello/html/index.html -Files: /usr/share/doc/umbrello/html/*.html +Index: /usr/share/doc/kde/HTML/en/umbrello/index.html +Files: /usr/share/doc/kde/HTML/en/umbrello/*.html
Re: Announcing the availability of first Qt 3.3 packages
Martin Loschwitz [EMAIL PROTECTED] writes: 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 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. Ralf and I adopted Ivan E. Moores idea to have non-mt and mt packges since it is important to provide both flavours. Back when Ivan was the maintainer, the multi-threaded version was new, experimental, and possibly unstable, so it made sense to maintain two versions. However, this is no longer the case, so I question whether the single-threaded libraries serve any useful purpose. 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 . BRUAHAHAHAHA. Okay, I recovered from my laugh-attack, so, let's see. Let's just look at the .changes-file for a beginning. Removed the non-threaded library and plugins -- right. Who gives a damn on who needs these libraries? Let's just remove them to have Qt3 split into less packages! - Removed embedded tools - Removed old compatibility tools Yeah, of course. Give a damn on people who need these tools; who rely on that they are included in the Debian packages because they are included in the upstream's source tarball. How useful are the old compatibility tools these days, considering Qt 3.0 was released years ago? Those tools aren't built by Qt by default and any code that is still maintained would have been ported to Qt3 long ago. The embedded tools I didn't build because I don't know shit about them and would need to research them first. In any case, I don't see any reason why both of these toolsets couldn't be merged into qt3-dev-tools or wherever. * Don't enable xcursor support (Closes: #246198) Right. Because it's broken, we disable it instead of finding and fixing the problem. Disabling is massively easier than fixing anyway; only needs some letters in debian/rules! Hey, it was a quick fix to get the package to build. I did say that I didn't consider the packages fit for release, and this was one of the reasons. Let's summarize what you can bring to the table: Packages that appear to be structured less complicated and which turn out to be nothing but castrated if you look at them closely. And some wild number games, of course. I don't know what your original intention was but to me it seems that all you do is trolling to gain attention. Don't expect me to treat you with only a little amount of seriousness; don't expect me to deal with you anymore. If your Qt package were properly maintained, I wouldn't bother you with this. However, I think it's been in quite poor condition for a very long time now and I don't see them getting any better. Furthermore, you completely ignore every bug filed against the package. Start maintaining your package properly before you flame me. -- You win again, gravity!
KDE_3_2_BRANCH: kdesdk/debian
CVS commit by benb: Lintian cleanness. Asource.lintian-overrides 1.1.2.1 M +2 -0 changelog 1.53.2.9 M +1 -1 control 1.54.2.9 --- kdesdk/debian/changelog #1.53.2.8:1.53.2.9 @@ -5,4 +5,6 @@ * Use real paths for doc-base entries instead of symlinked paths (closes: #247690). + * Suggests (konqueror | www-browser) for kdesdk-doc-html instead of +just www-browser. -- Ben Burton [EMAIL PROTECTED] Wed, 16 Jun 2004 08:41:42 +1000 --- kdesdk/debian/control #1.54.2.8:1.54.2.9 @@ -18,5 +18,5 @@ Architecture: all Section: doc -Suggests: www-browser, kdesdk +Suggests: konqueror | www-browser, kdesdk Replaces: cervisia ( 4:3.2.0), kbabel ( 4:3.2.0), kbugbuster ( 4:3.2.0), kompare ( 4:3.2.0) Description: KDE Software Development Kit documentation in HTML format
kdenonbeta/kdedebian/kapture
CVS commit by mornfall: - get CElemPtr stuff into shape; mostly (still crashy with delete on deref on... some ref is slipping me, damnit) - template ParamT; works, looks good - optimize out some not-really-neccessary loops - safe CElemPtr's... looks good, seems worky (this commit was brought to you by a herd of flying plusses) M +122 -41 libcapture/celem.h 1.4 M +8 -6 libcapture/depgroupers.cpp 1.16 M +1 -0 libcapture/depgroupers.h 1.11 M +6 -6 libcapture/filters.cpp 1.17 M +2 -2 libcapture/grouper.cpp 1.25 M +20 -0 libcapture/param.h 1.5 M +31 -7 libcapture/pkgmanager.cpp 1.25 M +7 -3 libcapture/pkgmanager.h 1.18 M +35 -15libcapture/safeiterators.cpp 1.4 M +22 -17libcapture/safeiterators.h 1.4 M +1 -1 libcapture/tree.cpp 1.20 M +3 -2 libcapture/treefactory.h 1.6 M +1 -1 libcapture/treenode.cpp 1.8 M +4 -4 libcapture/treenode.h 1.10 M +1 -1 libkapture/listtreeview.cpp 1.14 M +9 -9 libkapture/listtreewidget.cpp 1.23 M +4 -4 libkapture/listtreewidget.h 1.15 M +6 -6 libkapture/pkgcelemview.cpp 1.6 M +1 -1 libkapture/pkgcelemview.h 1.4
KDE_3_2_BRANCH: kdesdk/debian
CVS commit by benb: Fixed in 3.2.3. M +2 -0 changelog 1.53.2.10 --- kdesdk/debian/changelog #1.53.2.9:1.53.2.10 @@ -7,4 +7,6 @@ * Suggests (konqueror | www-browser) for kdesdk-doc-html instead of just www-browser. + * KBabel catalogue manager no longer opens spurious empty windows +(closes: #237031). -- Ben Burton [EMAIL PROTECTED] Wed, 16 Jun 2004 08:41:42 +1000
Re: Announcing the availability of first Qt 3.3 packages
On June 15, 2004 18:27, Martin Loschwitz wrote: The only serious trouble in Qt3 until some days ago was that XCursor made it imposslbe to compile Qt3. Nothing else. You need to distinguish between I think they are poorly maintained and they are poorly maintained. I'm not qualified to judge how best to carve up the packages, but the simple fact is that Qt3 was being poorly maintained. In fact, for all intents and purposes, Qt was completely unmaintained, and that's not good enough for a crucial package. You are no doubt aware that this isn't the first round of openly expressed discontent with the state of Qt, since you took it over. Generally, you seem to have an extremely lax conception of what maintaining a package involves. Suffice it to say that frequent updates, a lively interest and open communication on all your bugs, careful attempts to meet user demands where at all possible, and an immediate response to RC problems, are simply the bare minimum that Debian demands, or should demand, of a maintainer. If you were too busy and needed help, you should have asked for it a long time ago. I've listed some of what needs to be fixed and improved in some of my earlier posts in this thread. I'm sure others could list more. Your latest packages are a great move in the right direction, and I thank you for them, but a great deal remains to be done. Christopher Martin
Re: Announcing the availability of first Qt 3.3 packages
On Tue, Jun 15, 2004 at 11:08:52AM +0200, Dominique Devriese wrote: 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. How does having part of the package arch-indep actually save any significant amount of time? Instead, it actually wastes a lot of buildd time since by having part of the dev packaging be indep it causes anything building against qt to ftbfs anytime a new qt is uploaded. This is because the version of the arch-dep -dev package depends on is no longer available until it has been built on that arch. Some people don't believe this is an issue but it has bitten KDE _many_ times. This problem is going to have to be solved from an archive standpoint before multiarch is started but right now it is already a very big issue with qt. 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. There are only two packages that use non-multithreaded version and could probably use it if we kicked their maintainers. qterm vipec Chris signature.asc Description: Digital signature
Re: Announcing the availability of first Qt 3.3 packages
On Tue, Jun 15, 2004 at 02:40:57PM -0700, Brian Nelson wrote: Martin Loschwitz [EMAIL PROTECTED] writes: 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 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. Ralf and I adopted Ivan E. Moores idea to have non-mt and mt packges since it is important to provide both flavours. Back when Ivan was the maintainer, the multi-threaded version was new, experimental, and possibly unstable, so it made sense to maintain two versions. However, this is no longer the case, so I question whether the single-threaded libraries serve any useful purpose. I believe this is the primary reason qt3 has both flavors in Debian still. Back when Ivan maintained qt2/qt3 he made the packaging the same for both iirc. qt2's -mt package was considered very experimental and pretty much nothing used it. However, qt3's -mt package was considered stable and nearly everything converted over to using it, right now only 2 packages in Debian are built against the non-multithreaded version and that is probably just because the maintainer didn't know what they were doing. Chris signature.asc Description: Digital signature
Re: Announcing the availability of first Qt 3.3 packages
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... Chris signature.asc Description: Digital signature
kdenonbeta/kdedebian/kapture/libcapture
CVS commit by mornfall: ... fix the CElemSPtr to not fuck up refcounting ... ... or at least not to free up referenced memory ... ... needs some fixes; and cleanup redundant code ... M +5 -2 celem.h 1.5 M +1 -2 depgroupers.cpp 1.17 M +3 -1 filters.cpp 1.18 M +8 -6 safeiterators.cpp 1.5 M +29 -4 safeiterators.h 1.5
kdenonbeta/kdedebian/kapture/libcapture
CVS commit by mornfall: fix include_HEADERS, so that make runs... M +1 -1 Makefile.am 1.16 --- kdenonbeta/kdedebian/kapture/libcapture/Makefile.am #1.15:1.16 @@ -7,5 +7,5 @@ # these are the headers for your project -include_HEADERS = DebDBParser.h depgroupers.h filters.h grouper.h pkgcache.h pkggroup.h pkgmanager.h pkgtags.h safeiterators.h stl_util.h tagcollbuilder.h treebranchnode.h treedepnode.h treefactory.h treegroupnode.h tree.h treenode.h treepkgnode.h treevernode.h treevisitor.h Vocabulary.h ZlibParserInput.h celem.h +include_HEADERS = DebDBParser.h depgroupers.h filters.h grouper.h pkgcache.h pkggroup.h pkgmanager.h pkgtags.h safeiterators.h stl_util.h tagcollbuilder.h treefactory.h tree.h treenode.h treevisitor.h Vocabulary.h ZlibParserInput.h celem.h # let automoc handle all of the meta source files (moc)
kdenonbeta/kdedebian/kapture
CVS commit by mornfall:
Fix bunch of warnings. Yes, it still compiles runs. Found another bug
tho, out to fix that...
M +2 -3 kapture/Makefile.am 1.13
M +6 -7 kapture/kapture.cpp 1.24
M +0 -4 kapture/kapture.h 1.10
M +2 -1 libcapture/pkgmanager.cpp 1.26
M +2 -0 libcapture/stl_util.cpp 1.4
--- kdenonbeta/kdedebian/kapture/kapture/Makefile.am #1.12:1.13
@@ -19,9 +19,8 @@
# which sources should be compiled for kapture
-kapture_SOURCES = main.cpp kapture.cpp kaptureview.cpp \
-kapturepref.cpp
+kapture_SOURCES = main.cpp kapture.cpp kapturepref.cpp
# these are the headers for your project
-noinst_HEADERS = kapture.h kaptureview.h kapturepref.h
+noinst_HEADERS = kapture.h kapturepref.h
# let automoc handle all of the meta source files (moc)
--- kdenonbeta/kdedebian/kapture/kapture/kapture.cpp #1.23:1.24
@@ -33,4 +33,5 @@
#include qtimer.h
#include kde_terminal_interface.h
+#include kparts/part.h
#include libcapture/grouper.h
@@ -50,6 +51,5 @@ using namespace kapture;
/* {{{ */
Kapture::Kapture()
-: KDockMainWindow (0, Kapture),
-m_printer(0)
+: KDockMainWindow (0, Kapture)
{
// accept dnd
@@ -190,5 +190,4 @@ Kapture::~Kapture()
kdDebug () Kapture::~Kapture endl;
// PkgManager::destroy ();
-delete m_printer;
}
/* }}} */
@@ -244,5 +243,5 @@ void Kapture::saveProperties(KConfig *co
// later when this app is restored
-if (!m_view-currentURL().isNull()) {
+/* if (!m_view-currentURL().isNull()) {
#if KDE_IS_VERSION(3,1,3)
config-writePathEntry(lastURL, m_view-currentURL());
@@ -250,5 +249,5 @@ void Kapture::saveProperties(KConfig *co
config-writeEntry(lastURL, m_view-currentURL());
#endif
-}
+} */
}
/* }}} */
@@ -263,6 +262,6 @@ void Kapture::readProperties(KConfig *co
QString url = config-readPathEntry(lastURL);
-if (!url.isEmpty())
-m_view-openURL(KURL::fromPathOrURL(url));
+/* if (!url.isEmpty())
+m_view-openURL(KURL::fromPathOrURL(url)); */
}
/* }}} */
--- kdenonbeta/kdedebian/kapture/kapture/kapture.h #1.9:1.10
@@ -11,6 +11,4 @@
#include kdockwidget.h
-#include kaptureview.h
-
class KPrinter;
class KTabWidget;
@@ -87,6 +85,4 @@ class Kapture : public KDockMainWindow
void setupAccel();
void setupActions();
-KaptureView *m_view;
-KPrinter *m_printer;
};
--- kdenonbeta/kdedebian/kapture/libcapture/pkgmanager.cpp #1.25:1.26
@@ -93,4 +93,5 @@ bool PkgManager::loadAll ()
m_notify = n;
notifyRebuild ();
+return r;
}
/* {{{ */
@@ -514,5 +515,5 @@ bool PkgManager::doCommit (CommitStatus
_system-UnLock();
-int count = 0;
+unsigned count = 0;
for (pkgCache::PkgIterator mP = m_cache - PkgBegin (); ! mP . end (); mP
++) {
if (m_cache [mP] . Delete ()) {
--- kdenonbeta/kdedebian/kapture/libcapture/stl_util.cpp #1.3:1.4
@@ -91,4 +91,5 @@ static string escape( string s, string d
}
/* }}} */
+#if 0
/* {{{ */
static liststring explode_helper (string s, string delim)
@@ -106,4 +107,5 @@ static liststring explode_helper (stri
}
/* }}} */
+#endif
/* {{{ */
liststring capture::explode (string s, string delim)
kdenonbeta/kdedebian/kapture/libcapture
CVS commit by mornfall:
Fix Depends node creation (busted in process of DepCElem(S)Ptr
debugging).
M +1 -1 depgroupers.cpp 1.18
--- kdenonbeta/kdedebian/kapture/libcapture/depgroupers.cpp #1.17:1.18
@@ -78,5 +78,5 @@ void Pkg2DepGrouper::addNode (TreeNode *
d - addDepend (D); */
} else {
-d = m_treeFact - make (0, de);
+d = m_treeFact - make (0, new DepCElem (*de));
cerr new depend ( d , parent =
(n ? n : r)
Bug#254643: When will the Export to nokia mobile phone support be compiled back in to kaddressbook?
Package: kaddressbook Version: 4:3.2.2-2 Severity: wishlist Hi, I was just wondering when we can expect Export to nokia mobile phone support to compiled back in the the unstable kaddressbook? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.6-2 Locale: LANG=C, LC_CTYPE=C Versions of packages kaddressbook depends on: ii kdelibs4 4:3.2.3-2 KDE core libraries ii libart-2.0-2 2.3.16-5 Library of functions for 2D graphi ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-5client library to control the FAM ii libgcc1 1:3.3.4-1 GCC support library ii libice6 4.3.0.dfsg.1-4 Inter-Client Exchange library ii libjpeg62 6b-9 The Independent JPEG Group's JPEG ii libkdepim14:3.2.2-2 KDE PIM library ii libpcre3 4.5-1.1Perl 5 Compatible Regular Expressi ii libpng12-01.2.5.0-6 PNG library - runtime ii libqt3c102-mt 3:3.2.3-3 Qt GUI Library (Threaded runtime v ii libsm64.3.0.dfsg.1-4 X Window System Session Management ii libstdc++51:3.3.4-1 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-4 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-4 X Window System miscellaneous exte ii libxpm4 4.3.0.dfsg.1-4 X pixmap library ii libxrender1 0.8.3-7X Rendering Extension client libra ii xlibs 4.3.0.dfsg.1-4 X Window System client libraries m ii zlib1g1:1.2.1.1-3compression library - runtime -- no debconf information
Re: Package Misconfiguration
Package is in a very bad inconsistent state - you should reinstall it before attempting a removal. Try apt-get intall --reinstall
Re: what happened to qtcups ?
On Monday 14 June 2004 10:11 am, James D. Freels wrote: I have found qtcups very handy for printing a document using cups and the kde interface. Apparently in the latest round of upgrades to kde/cups, this package went away. What are the alternatives and is it possible to put it back (guess I could try a build from source). Try kprinter. It's better anyway. -- Michael McIntyre Silvan [EMAIL PROTECTED] Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/
Re: screensavers can't be configured anymore in kde 3.2.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 24 May 2004 00:15, Nick Leverton wrote: On Sat, May 22, 2004 at 12:42:39AM +0100, Nick Boyce wrote: BTW I see there is another related-sounding bug already filed : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208769 KDE lists screensavers that aren't installed (filed in September 2003) as well as Frans's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243150 Can't configure some screensavers any more And http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245894 kcontrol: Cannot configure The Matrix screensaver Good news! I did an strace this weekend and managed to locate the probable cause [1]. After that Ben Burton has been very quick to squash the bug (thanks Ben!). I think the new packages (4:3.2.3-1) are already in the pipeline and hopefully will be in testing pretty soon [2]. [1] http://bugs.kde.org/show_bug.cgi?id=83324 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243150 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAz0Dsgm/Kwh6ICoQRAvX5AKCLZed5URys1gFebDad7VwGfohmaQCfao9H 6WHWiOwrXWPuKhXJTby4Dag= =spjm -END PGP SIGNATURE-
Re: screensavers can't be configured anymore in kde 3.2.2
I did an strace this weekend and managed to locate the probable cause [1]. Much appreciated btw. :) b.
