kdenonbeta/kdedebian/kapture
CVS commit by mornfall: Start work towards very basic dpkg progress interface. No worky ATM. Also cleanup KaptureManager pointers, it's singleton now. Plus few random changes. M +1 -1 TODO 1.33 M +2 -1 kapture/kapture.cpp 1.25 M +0 -1 kapture/kapture.h 1.11 M +0 -1 libcapture/pkgmanager.cpp 1.27 M +1 -1 libcapture/pkgmanager.h 1.19 M +1 -0 libcapture/pkgsystem.cpp 1.2 M +0 -1 libkapture/celemview.h 1.3 M +3 -4 libkapture/commitstatus.cpp 1.2 M +1 -3 libkapture/commitstatus.h 1.2 M +29 -1 libkapture/dpkgpm.cpp 1.3 M +13 -0 libkapture/dpkgpm.h 1.3 M +4 -2 libkapture/kapturemanager.cpp 1.24 M +6 -4 libkapture/kapturemanager.h 1.11 M +0 -1 libkapture/listtreeview.h 1.3 M +0 -1 libkapture/pkgcelemview.h 1.5 M +0 -1 libkapture/summaryview.h 1.3 M +0 -1 libkapture/treeview.h 1.7
kdeextragear-1/amarok/debian
CVS commit by mornfall:
Debian packages for 1.0 release:
- split engines from amarok, depend on at least one engine
- note that xmms is not supported, but solution is seeked
Aamarok-arts.install 1.1
Aamarok-gstreamer.install 1.1
M +8 -1 amarok.install 1.2
M +18 -0 changelog 1.2
M +21 -1 control 1.2
--- kdeextragear-1/amarok/debian/amarok.install #1.1:1.2
@@ -1 +1,8 @@
-debian/tmp/*
+debian/tmp/usr/share/apps/amarok/*
+debian/tmp/usr/share/icons/*
+debian/tmp/usr/share/config.kcfg/amarok.kcfg
+debian/tmp/usr/share/servicetypes/amarok_plugin.desktop
+debian/tmp/usr/share/applications/kde/amarok.desktop
+debian/tmp/usr/share/doc/*
+debian/tmp/usr/bin/*
+debian/tmp/etc/*
--- kdeextragear-1/amarok/debian/changelog #1.1:1.2
@@ -1,2 +1,20 @@
+amarok (1.0.0-1) unstable; urgency=low
+
+ * Build official 1.0.0 release.
+
+ -- Peter Rockai (mornfall) <[EMAIL PROTECTED]> Wed, 16 Jun 2004 23:48:52
+0200
+
+amarok (1.0-pre1-2) unstable; urgency=low
+
+ * Fix amarok-arts package, was missing mcop files. Duh.
+
+ -- Peter Rockai (mornfall) <[EMAIL PROTECTED]> Wed, 16 Jun 2004 23:25:29
+0200
+
+amarok (1.0-pre1-1) unstable; urgency=low
+
+ * First 1.0.0 prerelease.
+
+ -- Peter Rockai (mornfall) <[EMAIL PROTECTED]> Wed, 16 Jun 2004 10:18:31
+0200
+
amarok (1.0-beta4-2) unstable; urgency=low
--- kdeextragear-1/amarok/debian/control #1.1:1.2
@@ -4,4 +4,5 @@
Maintainer: Peter Rockai (mornfall) <[EMAIL PROTECTED]>
Build-Depends: cdbs (>= 0.4.21), debhelper (>> 4.0.18), kdelibs4-dev (>=
4:3.2), kdemultimedia-dev (>= 4:3.2), libtag1-dev (>= 1.1),
libgstreamer0.8-dev, libgstreamer-plugins0.8-dev
+Build-Conflicts: xmms-dev
Standards-Version: 3.5.8.0
@@ -9,5 +10,5 @@
Section: sound
Architecture: any
-Depends: arts (>= 1.2), ${shlibs:Depends}
+Depends: amarok-arts | amarok-gstreamer, ${shlibs:Depends}
Description: versatile and easy to use audio player for KDE
amaroK tries to be a little different, providing a simple drag and drop
@@ -24,2 +25,21 @@
This version is built with aRts and GStreamer support, NMM engine is not
yet included.
+ .
+ The xmms visualisation support was disabled in this release. We are working
+ on a solution though.
+
+Package: amarok-arts
+Section: sound
+Architecture: any
+Depends: arts (>= 1.2), ${shlibs:Depends}
+Description: arts engine for amarok audio player
+ Arts support for amaroK, a versatile and easy to use audio player for KDE.
+ See package amarok for the actual player.
+
+Package: amarok-gstreamer
+Section: sound
+Architecture: any
+Depends: gstreamer0.8-plugins, ${shlibs:Depends}
+Description: gstreamer engine for amarok audio player
+ GStreamer support for amaroK, a versatile and easy to use audio player for
+ KDE. See package amarok for the actual player.
Processed: kteatime failure to dock into system tray
Processing commands for [EMAIL PROTECTED]: > retitle 248607 Please allow KSystemTray apps to dock into the GNOME systray Bug#248607: kteatime: Shows only empty screen Changed Bug title. > reassign 248607 kdelibs4 Bug#248607: Please allow KSystemTray apps to dock into the GNOME systray Bug reassigned from package `kteatime' to `kdelibs4'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#254794: kmail: Relocation error in libkabc.so.1
Package: kmail Version: 4:3.2.2-2 Severity: grave Justification: renders package unusable Whenever I try to write an Email, kmail crashes with the following error in .xsession-error: relocation error: /usr/lib/libkabc.so.1: undefined symbol: -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.6-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages kmail depends on: ii kdebase-kio-plugins 4:3.2.2-1 KDE I/O Slaves ii kdelibs4 4:3.2.3-2 KDE core libraries ii ktnef 4:3.2.2-2 KDE TNEF viewer 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 libkcal2 4:3.2.2-2 KDE calendaring library ii libkdenetwork24:3.2.2-2 KDE Network library ii libkdepim14:3.2.2-2 KDE PIM library ii libksieve04:3.2.2-2 KDE mail/news message filtering li ii libmimelib1 4:3.2.2-2 KDE mime 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 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: Announcing the availability of first Qt 3.3 packages
Dominique Devriese <[EMAIL PROTECTED]> writes: > 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, Well, I know what it is used for--I use it all the time when doing Qt development. I never realized any application actually made use of it to display their own documentation. A quick check of qt3-assistant's reverse dependencies shows that nothing outside of Qt depends on qt3-assistant in Debian, so you can surely understand my ignorance. > what qt-apps-dev could be used for, even when the package description > stated it pretty clearly etc, Hmm, I wonder if I was thinking of another package description. The qt3-apps-dev one does seem pretty clear (though the package name is still confusing). It still seems like an odd package to me; it sounds like it could suitably be integrated into another package. > 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 think you looked at the changelog entry of my Qt package and assumed everything I did was for a good reason. In actuality, the changes were noted to record the damage I did as well as the things I actually thought were good ideas. Sorry about the confusion. To clarify, here are my following proposals: * Remove the non-mt packages. Rationale: No package[1] in Debian depends on it. It only serves to confuse people which package (libqt3-dev or libqt3-mt-dev) to use, and bogs down the buildds. Result: Removes libqt3-dev, libqt3c102, libqt3c102-mysql, libqt3c102-odbc, libqt3c102-psql, libqt3c102-sqlite Removing the non-mt packages would only potentially break 3rd-party software that uses the non-mt libraries. This software includes: - Old Qt2.x era software whose configure scripts are not capable of detecting the mt version. These scripts were already broken by the move from /usr/share/qt -> /usr/share/qt3, so it's not worth worrying about. - Commercial software linked against the non-mt version as a shared library. Such software is likely quite rare since normally commercial software is statically-linked. Users of any such software, if it exists, should bash the vendor to fix it. - Software compiled on other distributions but run on Debian. This is another unusual case that is dependent on whether other distributions use the mt or non-mt libs (the GCC version used could break compatibility anyway). I have not investigated this at all, but I suspect most other distros compiled with GCC 3.x use the mt libs as well, so this situation would be moot. Also, there's another potential solution to these problems: create a libqt-mt.so.3 -> libqt.so.3 symlink and have libqt3c102-mt provide libqt3c102. Making stuff reentrant seems, in theory to me anyway, to not break binary compatibility. For my own amusement, I just tried running the qterm in Debian with this symlink and it seemed to run OK. I have no idea if it would work reliably for other software though. History note: I am largely responsible for the software in Debian uniformly using the mt libs. It was decided by Madkiss (and others?) a year or two ago to deprecate the non-mt libs in favor of the mt libs. I strongly supported this stance, and at Madkiss's, errr, goading[2], I filed bugs with patches against every package in Debian depending on libqt3/libqt3c102. [1] OK, vipec and qterm do depend on libqt3c102. vipec has a patch that is waiting for the maintainer to apply it, and qterm and old and should just be removed. [2] http://lists.debian
Bug#254721: juk: FTBFS on amd64: Please remove the build dependency on gcc-3.2
close 254721 thanks On 04-Jun-16 12:52, Christopher Martin wrote: > On June 16, 2004 12:20, Chris Cheney wrote: > > Juk the source package needs to be removed from the archive, its > > already part of kdemultimedia source now. Sorry, I did not check that. > I filed a request for this already - #254481. Can this #254721 then be > closed? Done. Regards Andreas Jochens
Processed: Re: Bug#254721: juk: FTBFS on amd64: Please remove the build dependency on gcc-3.2
Processing commands for [EMAIL PROTECTED]: > close 254721 Bug#254721: juk: FTBFS on amd64: Please remove the build dependency on gcc-3.2 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Andreas Jochens <[EMAIL PROTECTED]> > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
kdenonbeta (silent)
CVS commit by binner: CVS_SILENT fixuifiles M +0 -3 akregator/src/settings_browser.ui 1.5 M +0 -3 akregator/src/settings_general.ui 1.8 M +0 -6 applets/kjsapplet/installer.ui 1.2 M +0 -3 finglonger/kcmfinglonger/pageactiontypebase.ui 1.2 M +0 -3 finglonger/kcmfinglonger/pagerunappbase.ui 1.2 M +0 -3 finglonger/kcmfinglonger/profilebase.ui 1.3 M +0 -3 frontman/src/dialogs/pathspagebase.ui 1.2 M +0 -3 frontman/src/kernel/frontiobase.ui 1.3 M +0 -3 frontman/src/kernel/dialogs/startdlgbase.ui 1.2 M +0 -3 kalypso/kalypso/pagecomponentsimpl.ui 1.9 M +0 -3 kalypso/kalypso/pagefinalimpl.ui 1.3 M +0 -3 kalypso/kalypso/pageinstallimpl.ui 1.6 M +0 -3 kalypso/kalypso/pageintroimpl.ui 1.8 M +0 -3 kalypso/kalypso/pagelocationimpl.ui 1.8 M +0 -3 kalypso/kalypso/pageversionimpl.ui 1.12 M +0 -3 kard/src/theme.ui 1.6 M +0 -3 kard/src/timer.ui 1.5 M +0 -3 kblog/blogEditUI.ui 1.4 M +0 -3 kblog/editview.ui 1.2 M +0 -3 kblog/imageSelect.ui 1.3 M +0 -3 kblog/postmgrview.ui 1.4 M +0 -3 kcmdhcpd/addhost_ui.ui 1.5 M +0 -3 kcmdhcpd/addserver_ui.ui 1.6 M +0 -3 kcmdhcpd/addsubnet_ui.ui 1.6 M +0 -3 kcmdhcpd/dhcpd_config_ui.ui 1.8 M +0 -3 kcmdhcpd/editserver_ui.ui 1.8 M +0 -3 kcmdhcpd/hostitem_ui.ui 1.5 M +0 -3 kcmdhcpd/leasesitem_ui.ui 1.4 M +0 -3 kcmdhcpd/oneitem_ui.ui 1.9 M +0 -3 kcmdhcpd/oneitemtime_ui.ui 1.6 M +0 -3 kcmdhcpd/optionsitem_ui.ui 1.6 M +0 -3 kcmdhcpd/rangeitem_ui.ui 1.3 M +0 -3 kcmdhcpd/rangesitem_ui.ui 1.8 M +0 -3 kcmdhcpd/subnetitem_ui.ui 1.6 M +0 -3 kdedebian/kapture/libkapture/pkgcelemviewcommonui.ui 1.3 M +0 -3 kdedebian/kapture/libkapture/pkgcelemviewdetailsui.ui 1.3 M +0 -3 kdedebian/kapture/part/partviewui.ui 1.4 M +0 -3 kdeprintphoto/pageintroimpl.ui 1.3 M +0 -3 kdeprintphoto/printsettingsimpl.ui 1.5 M +0 -3 kdeprintphoto/selectimagesimpl.ui 1.4 M +0 -3 kfs/src/kfsdsiteproploc.ui 1.4 M +0 -3 kfs/src/kfsdsyncdialog.ui 1.3 M +0 -3 kfs/src/kfsmainwidget.ui 1.3 M +0 -3 kggst/base/kggst_unsupportedplatformwidget.ui 1.3 M +0 -3 kifi/src/ui/configtabwidget.ui 1.2 M +0 -9 kimproxy/editors/imeditorbase.ui 1.6 M +0 -3 kimproxy/src/imlabelbase.ui 1.3 M +1 -7 kjssupport/subclassingdlgbase.ui 1.2 M +0 -3 kmameleon/main/layouts/mod_custom.ui 1.3 M +0 -3 kmameleon/main/layouts/mod_devices.ui 1.3 M +0 -3 kmameleon/main/layouts/mod_effects.ui 1.2 M +0 -3 kmameleon/main/layouts/mod_gl.ui 1.2 M +0 -3 kmameleon/main/layouts/mod_paths.ui 1.2 M +0 -3 kmameleon/main/layouts/mod_sdl.ui 1.2 M +0 -3 kmameleon/main/layouts/mod_x11.ui 1.2 M +1 -1 kmathprof/src/kmathprofbase.ui 1.8 M +1 -1 kmathprof/src/statisticbase.ui 1.3 M +1 -1 kmathtool/src/AreaPerimeter1D.ui 1.8 M +1 -4 kmathtool/src/FactorsD.ui 1.5 M +0 -3 kmathtool/src/LinesD.ui 1.2 M +0 -3 kmathtool/src/ParabolasD.ui 1.2 M +1 -4 kmathtool/src/StartWidgetD.ui 1.3 M +0 -3 konqsidebar_plugins/konqsidebarmediaplayer/mediawidget_skel.ui 1.5 M +0 -3 konqsidebar_plugins/konqsidebarmediaplayer/mediawidget_skel_designer.ui 1.2 M +0 -3 kontextbar/src/setupdialogview.ui 1.2 M +1 -4 kontextbar/src/sidebarselector.ui 1.2 M +0 -3 kpicross/src/editui.ui 1.4 M +0 -3 kpicross/src/selectboardui.ui 1.3 M +0 -3 kpolicy/src/generalsettingsimpl.ui 1.3 M +0 -3 kpolicy/src/globalsettingsimpl.ui 1.7 M +0 -3 kpolicy/src/konqsettingsimpl.ui 1.4 M +0 -3 kpolicy/src/mainwidgetimpl.ui 1.7 M +0 -3 kpolicy/src/resourcerestrictionsimpl.ui 1.4 M +1 -4 kstyle2/editdialog_ui.ui 1.8 M +0 -3 kstyle2/kstyle2_ui.ui 1.8 M +0 -24 kttsd/kcmkttsmgr/kcmkttsmgrwidget.ui 1.6 M +0 -3 kttsd/plugins/command/texttospeechconfigurationui.ui 1.3 M +0 -3 kttsd/plugins/festivalint/festivalintconfwidget.ui 1.4 M +0 -9 kwhatsbroken/infection.ui 1.2 M +1 -10 libkrdf/owl/designer/mainwindow.ui 1.2 M +1 -1 threadweaver/examples/jobs-gui/gui_base.ui 1.3 M +1 -1 threadweaver/examples/processrequests/processrequest.ui 1.3 M +0 -3 uirtk/tests/kdevelop.ui 1.2 M +1 -28 xinput/mainform.ui 1.2
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
Bug#254721: juk: FTBFS on amd64: Please remove the build dependency on gcc-3.2
On June 16, 2004 12:20, Chris Cheney wrote: > Juk the source package needs to be removed from the archive, its > already part of kdemultimedia source now. I filed a request for this already - #254481. Can this #254721 then be closed? Cheers, Christopher Martin
Bug#254721: juk: FTBFS on amd64: Please remove the build dependency on gcc-3.2
On Wed, Jun 16, 2004 at 05:23:02PM +0200, Andreas Jochens wrote: > Package: juk > Severity: normal > Tags: patch > > juk does not build on amd64 because it insists on using gcc-3.2. > Please remove this dependency on gcc-3.2 (see attached patch). Juk the source package needs to be removed from the archive, its already part of kdemultimedia source now. Chris signature.asc Description: Digital signature
Re: Announcing the availability of first Qt 3.3 packages
Dominique Devriese <[EMAIL PROTECTED]> writes: > 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. We, more personal insults. As I've said before, I don't consider the Qt packages I posted earlier fit for upload. In fact, if I did take over the package in Debian, I wouldn't make many of the changes I made in that package, especially considering sarge's imminent release. Also, I'm not convinced all of my proposals are good ideas. They are merely proposals I've opened for discussion. I've provided the rationale for each of my proposals, but all I've gotten in return are statements like "it's important to provide both flavours" (uh, why? I've already tried to explain why it's *not* important) or falsities about the buildd's and such. Which all kind of makes me think no one involved in Debian's Qt package has any idea what they're doing--and looking at the package, that seems very plausible. > I am also convinced that you don't know about the kind of difficult to > resolve bugs that a Qt maintainer is faced with. Err, well I have gone through many of the bug reports, which is something Madkiss clearly has not done. So I do have a pretty good idea... > 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 ), Heh heh, fair enough... > so it's pretty easy to fix its bugs. True. I'm not saying that being involved in ACE's packaging qualifies me to maintain Qt, though it has given me experience in hacking on a build system even uglier than Qt's (which is an impressive feat...). > Conclusion: I suggest that you try to work together with Martin on the > package or shut up. I've always tried to work together. I think the whole territorial "MY PACKAGE, HANDS OFF!" thing in Debian is just bullshit. We all should be working together. I was trying to have a reasonable discussion in this thread. I pointed out problems and offered solutions, asked questions about things I didn't understand, and backed up my arguments with thoughtful explanations. Then Madkiss attacked me and tried to laugh me out of the room, and now you're saying you think I'm an idiot without explanation (saying I don't understand package splits is *not* an explanation). And people wonder why the Debian Qt packages are in such shitty shape? Have you considered that Madkiss (and possibly you) are not willing to work together with anyone else, and are more content to fight and argue than to actually improve the packages? It's not like I'm the first person Madkiss has pissed off--as I'm sure we all remember. -- You win again, gravity!
Bug#254721: juk: FTBFS on amd64: Please remove the build dependency on gcc-3.2
Package: juk Severity: normal Tags: patch juk does not build on amd64 because it insists on using gcc-3.2. Please remove this dependency on gcc-3.2 (see attached patch). Regards Andreas Jochens diff -urN ../tmp-orig/juk-1.95/debian/control ./debian/control --- ../tmp-orig/juk-1.95/debian/control 2004-01-22 00:02:20.0 +0100 +++ ./debian/control2004-06-16 17:06:43.155300039 +0200 @@ -2,7 +2,7 @@ Section: devel Priority: optional Maintainer: David Schleef <[EMAIL PROTECTED]> -Build-Depends: cdbs, debhelper (>= 4.1.0), libkdegst0.6-dev, g++-3.2, xlibs-dev, libmusicbrainz2-dev, libid3-3.8.3-dev, chrpath +Build-Depends: cdbs, debhelper (>= 4.1.0), libkdegst0.6-dev, xlibs-dev, libmusicbrainz2-dev, libid3-3.8.3-dev, chrpath Standards-Version: 3.6.1 Package: juk diff -urN ../tmp-orig/juk-1.95/debian/rules ./debian/rules --- ../tmp-orig/juk-1.95/debian/rules 2003-10-10 02:17:11.0 +0200 +++ ./debian/rules 2004-06-16 17:06:28.479140260 +0200 @@ -7,9 +7,6 @@ include /usr/share/cdbs/1/rules/simple-patchsys.mk include /usr/share/cdbs/1/class/autotools.mk -CC := gcc-3.2 -CXX := g++-3.2 - common-install-arch:: chrpath -d debian/juk/usr/bin/juk -- System Information: Debian Release: testing/unstable Architecture: amd64 (x86_64) Kernel: Linux 2.6.6-1-k8-smp Locale: LANG=C, LC_CTYPE=C
Re: Announcing the availability of first Qt 3.3 packages
Dominique Devriese <[EMAIL PROTECTED]> writes: >> 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 ? There's a massive thread here: http://lists.debian.org/debian-devel/2003/02/msg00329.html A little more here: http://lists.debian.org/debian-devel/2003/02/msg00065.html There's probably more but I don't feel like looking. >>> 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. Well in that case it clearly belongs in libqt3c102-mt. >>> 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. The libqt3-dev package description, written by Madkiss, says: WARNING: The nonthreaded version of Qt3 is considered deprecated and may disappear anytime in the future. Please use libqt3-mt instead (Read README.Debian for instructions). Non-multithreaded use is already discouraged, at least in Debian... Furthermore, we are not compelled in any way to include it. When building Qt, you get a choice, and that choice is multi-threaded by default. You don't get both. Qmake is designed more or less to adapt to the currently installed Qt--if it's built mt, qmake creates makefiles for mt. I don't see any reason why we need to have both versions if no software in Debian uses non-mt. >>> 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. Just because I want to change the package around (actually, it's more reverting it to the way it was pre-madkiss), does that make me incompetent? 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. >>> 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 ? http://bugs.debian.org/180326 -- You win again, gravity!
Bug#254666: Acknowledgement (konqueror: fails when started using the web navigation profile.)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The bug may be more related to kdebase or kdelibs because Kontact also crashes when sending an e-mail. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA0D4RyR3/fFPzMKsRAhs5AJwPf/9F1XT7mUrH/lP8K4SsOM4jSQCdHSEH 6+WOcF6AUn2nxhQ4zBIhiW0= =lxbp -END PGP SIGNATURE-
KDE_3_2_BRANCH: kdesdk/debian
CVS commit by benb: More manpages. M +1 -0 changelog 1.53.2.11 --- kdesdk/debian/changelog #1.53.2.10:1.53.2.11 @@ -3,4 +3,5 @@ * New upstream bugfix release. * Rebuilt against STL-enabled Qt and corresponding kdelibs. + * Added manpages for cvs2dist and build-progress.sh. * Use real paths for doc-base entries instead of symlinked paths (closes: #247690).
KDE_3_2_BRANCH: kdesdk/debian
CVS commit by benb: More manpages. Abuild-progress.sh.1 1.1.2.1 M +1 -0 kdesdk-scripts.manpages 1.11.2.3 M +3 -0 rules 1.55.2.3 --- kdesdk/debian/kdesdk-scripts.manpages #1.11.2.2:1.11.2.3 @@ -1,3 +1,4 @@ debian/adddebug.1 +debian/build-progress.sh.1 debian/cheatmake.1 debian/create_cvsignore.1 --- kdesdk/debian/rules #1.55.2.2:1.55.2.3 @@ -208,5 +208,8 @@ mv debian/kdesdk-scripts/usr/share/man/py/man1/zonetab2pot.1 \ debian/kdesdk-scripts/usr/share/man/man1/zonetab2pot.py.1; \ + mv debian/kdesdk-scripts/usr/share/man/sh/man1/build-progress.1 \ +debian/kdesdk-scripts/usr/share/man/man1/build-progress.sh.1; \ rm -rf debian/kdesdk-scripts/usr/share/man/py; \ + rm -rf debian/kdesdk-scripts/usr/share/man/sh; \ ;; \ esac; \
KDE_3_2_BRANCH: kdesdk/debian
CVS commit by benb: Manpage for cvs2dist. Acvs2dist.1 1.1.2.1 M +1 -0 kdesdk-scripts.manpages 1.11.2.2 --- kdesdk/debian/kdesdk-scripts.manpages #1.11.2.1:1.11.2.2 @@ -5,4 +5,5 @@ debian/create_makefiles.1 debian/cvs-clean.1 +debian/cvs2dist.1 debian/cvscheck.1 debian/cvslastchange.1
Bug#254685: your mail
retitle #254685 doesn't correctly display some icons thanks Why did the original bug report go out without subject? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Karlsruhe, Germany | lose things."Winona Ryder | Fon: *49 721 966 32 15 Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
Processed: Re: your mail
Processing commands for [EMAIL PROTECTED]: > retitle #254685 doesn't correctly display some icons Bug#254685: Changed Bug title. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: Announcing the availability of first Qt 3.3 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. 1. it achieves the original aim of alerting developers to their use of deprecated headers; 2. it still alerts developers who use deprecated headers even if you need to have compat-headers installed for some other reason (e.g., some user on your system is building 3rd party software that uses them) - the compat-headers solution fails completely in this scenario; 3. the errors themselves are clearer (a single "#warning: qlist.h is deprecated" is clearer than "error: cannot find header qlist.h" followed by a large flood of undefined types/etc); 4. it doesn't cause fatal breakages for users who just want to build some 3rd-party app and who aren't authoring Qt apps themselves; 5. it doesn't require root access (to install compat-headers) if you want to ignore the issue for the time being; 6. it doesn't give the impression that stuff that builds on every other system will fail to build on debian. So it achieves the same aim as the compat-headers split as seen in point 1, and in points 2, 3, 4, 5 and 6 it is a superior solution. I don't see any advantages that the compat-headers split has over #warnings. You could argue that by causing build failures it forces the issue to be dealt with *NOW*, but aside from being rude (IMHO), it could go one of two ways. Either the developer fixes their app, or the developer installs compat-headers for the time being (more important bugs to fix), at which point the errors go away and the developer forgets about it altogether. Anyway. This was all hashed out in some detail many months ago. I'm basically rehashing it just to answer your question. :) b.
Bug#254685:
Package: kpdf Version: 4:3.2.2-1 Severity: normal Hi, please have a look at http://www.lancom-systems.de/download/Documentation/Reference_Manual/LANCOM_Reference_Manual_3.32_DE.pdf page 11, and compare with kghostview's output of page 11. The Exclamation Mark, i, and Flash icons are displayed way too big by kpdf. Greetings Marc -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.6-janeway Locale: LANG=C, LC_CTYPE=C Versions of packages kpdf 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 libfreetype6 2.1.7-2.1 FreeType 2 font engine, shared lib ii libgcc1 1:3.3.4-1 GCC support library ii libice6 4.3.0.dfsg.1-4 Inter-Client Exchange library ii libpaper1 1.1.14 Library for handling paper charact 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
kdenonbeta/kdedebian/kapture/libcapture
CVS commit by mornfall:
Fix the update w/o debtags crash. Hopefully.
M +4 -0 pkgtags.cpp 1.6
--- kdenonbeta/kdedebian/kapture/libcapture/pkgtags.cpp #1.5:1.6
@@ -268,4 +268,8 @@ int capture::pkgTagsUpdate (pkgAcquireSt
// Updates the package tag database (requires root)
{
+if (access (fn_dist_vocab, R_OK))
+return 1;
+mkdir ((_config->FindDir("Dir::State::lists") + "tags/") . c_str (), 0755);
+
/// Update the system vocabulary
cerr << "Merging system vocabularies...\n";
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
Bug#254666: konqueror: fails when started using the web navigation profile.
Package: konqueror Version: 4:3.2.2-1 Severity: critical Justification: breaks unrelated software It also breaks, at least, kopete and kmldonkey. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (700, 'testing'), (500, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.6-1-k7 Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 Versions of packages konqueror depends on: ii kcontrol 4:3.2.2-1 KDE Control Center ii kdebase-kio-plugins 4:3.2.2-1 KDE I/O Slaves ii kdelibs4 4:3.2.3-2 KDE core libraries ii kdesktop 4:3.2.2-1 KDE Desktop ii kfind 4:3.2.2-1 KDE File Find Utility 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.4.0-2 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 libkonq4 4:3.2.2-1 Core libraries for KDE's file mana 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-2 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
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
kdenonbeta/kdedebian/kapture/tests/libcapture
CVS commit by gj: Make it compile, even if the thing was not setup anywhere on HD before M +1 -1 Makefile.am 1.4 --- kdenonbeta/kdedebian/kapture/tests/libcapture/Makefile.am #1.3:1.4 @@ -4,5 +4,5 @@ # set the include path for X, qt and KDE -INCLUDES = -I$(top_srcdir) -I$(top_srcdir)/tests -I/usr/include/libtagcoll $(all_includes) +INCLUDES = -I$(top_srcdir) -I$(top_srcdir)/libcapture -I$(top_srcdir)/tests -I/usr/include/libtagcoll $(all_includes) # these are the headers for your project
Bug#227538: plastik reappears
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After the update of the kdethemes package to 3.2.3 the plastik theme reappears. - -- 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) iD8DBQFAz9V3jBz/yQjBxz8RAlaZAJ0bQfwSFPwvqS182EDnYTt65cfuWACg0afT XTct1rSzZmBzTcBi++DM9b4= =uVtG -END PGP SIGNATURE-
