Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote: > were in the week-end). I was aware of the discussion but did not > had the time to chime in, yet I was the person who re-opened the bug > #881333 in the first place. > I also invited someone else who is working on a concrete project involving > Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available > now but he also did not have the time to contribute to the discussion. > Software can be fixed/improved to also work with OpenGL ES. However > hardware, once bought, cannot be fixed to support Desktop OpenGL > when it has been designed for OpenGL ES only. Reading from #881333 you mean Gemini PDA. It comes with Mediatek X27, featuring Mali-T880. The hardware is not OpenGL ES only .. the propiertary driver is. Mesa-based panfrost driver should support both OpenGL and OpenGL ES: https://gitlab.freedesktop.org/panfrost The open source driver is of course not ready... ...but neither is Debian ES 2.0. In the long run, making the driver ready is time better spent than time spent trying to make Debian more friendly to a class of propiertary drivers. Riku
Bug#781148: libqt5gui5: Please make GTK2 to dependency optional
Package: qtbase-opensource-src
Version: 5.3.2+dfsg-4
Severity: wishlist
Tags: patch
ldd /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5|wc
28 1082144
ldd /usr/lib/x86_64-linux-gnu/qt5/plugins/platformthemes/libqgtk2.so|wc
59 2324767
This one pluging brings in 31 dependencies that Qt itself does not need.
For embedded and mobile systems considerable amount of storage can be saved
by making installing this plugin optional.
The attached patch against experimental is one possible way for splitting
the theme plugin out.
From 9bd8db1f1b812f330edad4a704bfa7de63883651 Mon Sep 17 00:00:00 2001
From: Riku Voipio riku.voi...@linaro.org
Date: Wed, 25 Mar 2015 10:57:07 +0200
Subject: [PATCH] Split libqgtk2 to a separate package
Saves some space on on systems where GTK2 isn't installed.
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
debian/control | 13 -
debian/libqt5gui5.install-common | 1 -
debian/libqt5libqgtk2.install| 1 +
3 files changed, 13 insertions(+), 2 deletions(-)
create mode 100644 debian/libqt5libqgtk2.install
diff --git a/debian/control b/debian/control
index 1409d64..6ba0c4a 100644
--- a/debian/control
+++ b/debian/control
@@ -88,12 +87,24 @@ Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: fontconfig, ${misc:Depends}, ${shlibs:Depends}
+Recommends: libqt5libqgtk2
Description: Qt 5 GUI module
Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.
.
The QtGui module extends QtCore with GUI functionality.
+Package: libqt5libqgtk2
+Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Description: Qt 5 GTK2 platform theme
+ Qt is a cross-platform C++ application framework. Qt's primary feature
+ is its rich set of widgets that provide standard GUI functionality.
+ .
+ The libqgtk2 module provides GTK2 theme compatability
+
Package: libqt5network5
Architecture: any
Multi-Arch: same
diff --git a/debian/libqt5gui5.install-common b/debian/libqt5gui5.install-common
index 7e9533a..aa36b09 100644
--- a/debian/libqt5gui5.install-common
+++ b/debian/libqt5gui5.install-common
@@ -7,4 +7,3 @@ usr/lib/*/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so
usr/lib/*/qt5/plugins/platforms/libqminimal.so
usr/lib/*/qt5/plugins/platforms/libqoffscreen.so
usr/lib/*/qt5/plugins/platforms/libqxcb.so
-usr/lib/*/qt5/plugins/platformthemes/libqgtk2.so
diff --git a/debian/libqt5libqgtk2.install b/debian/libqt5libqgtk2.install
new file mode 100644
index 000..2ce6d35
--- /dev/null
+++ b/debian/libqt5libqgtk2.install
@@ -0,0 +1 @@
+usr/lib/*/qt5/plugins/platformthemes/libqgtk2.so
--
2.1.4
Bug#740334: qtwebkit creates ARMv5 assembler
Package: qtwebkit-opensource-src Version: 5.2.1+dfsg-3 X-Debbugs-CC: debian-...@lists.debian.org Severity: normal Checking the end of the builddlog[1]: /tmp/ccaKPWJK.s: Assembler messages: /tmp/ccaKPWJK.s:23: Error: selected processor does not support ARM mode `blx r0' make[4]: *** [.obj/jit/JITStubs.o] Error 1 blx is not supported on ARMv4t, lowest arch supported on debian/armel. One needs to replace this code with: mov lr,pc bx r0 Or, alternatively build with -march=armv5. This option would mean than qtwebkit would be unusable on armv4t hardware. The main usecase for such hardware is the openmoko freerunner. Do we still have openmoko users who are interested in qtwebkit? Riku [1] https://buildd.debian.org/status/fetch.php?pkg=qtwebkit-opensource-srcarch=armelver=5.2.1%2Bdfsg-3stamp=1393519544 -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140228095703.ga19...@afflict.kos.to
Re: the mangling of ‘va_list’ has ch anged in GCC 4.4
Modestas Vainius wrote:
I have recently came across .symver directive [1][2] that is more
straightforward way to achieve the same thing. In that case, only source file
(.cpp) needs to be changed.
Brilliant! This shall be the plan then:
1) identify affected libraries (Jakubs list as base?)
2) provide patches for the libraries and submit them to BTS
3) give maintainers X days to MU the libraries, after that proceed to
NMU them
4) binNMU any packages using the functions with va_list parameters
5) release squeeze ;)
6) tell maintainers they are free to drop the symbol alias
Sounds ok to everyone?
For example:
---
$ cat test.h
void myprint(const char* fmt, va_list list);
$ cat libtest.cpp
#include cstdarg
#include test.h
void myprint(const char* fmt, va_list list) {
}
// va_list mangling has been changed in g++ 4.4
// Add ABI = g++-4.3 compatibility hack
#if defined __ARM_EABI__ defined __GNUC__ (__GNUC__ 4 || __GNUC__ == 4
__GNUC_MINOR__ = 4)
__asm__(.symver _Z7myprintPKcSt9__va_list, _Z7myprintPKcPv@@);
#endif
---
_Z7myprintPKcSt9__va_list ( myprint(char const*, std::__va_list) )
here is the new mangling while _Z7myprintPKcPv ( myprint(char const*, void*)
) is the old mangling. When this code is built under g++-4.4, the resulting
binary will have both symbols with _Z7myprintPKcPv and
'_Z7myprintPKcSt9__va_list' referring to the same address:
$ objdump -T libtest.so | grep _Z7myprint
06d8 gDF .text 0058 Base_Z7myprintPKcSt9__va_list
06d8 gDF .text 0058 Base_Z7myprintPKcPv
1. http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-
assembler/symver.html
2. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-
linker/version.html
--
To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the mangling of ‘va_list’ has cha nged in GCC 4.4
Hi debian-release, There is a major problem with gcc 4.4 and armel - the ABI of va_list changed (for c++ libraries). We need to decide one of the following: 1) library package name rename (like c2a rename previously) + the right thing to do + partial upgrades work as expected - Some hassle for !armel sid users while transition happens - Quite a bit of extra work for many unrelated people (maintainers, ftp-masters..) 2) binNMU campaign - during the upgrade armel sid users packages will be broken (some already are) - even after, partial upgrades for armel users risk broken setups + does not disturb !armel users + no extra work for others but porters and release team 3) g++ downgrade or reverting to the old va_list mangling within g++4.4 for armel - A bunch of libraries and binaries have already been compiled with the new g++ - I think this is a bad idea anyway What way should we proceed? The list of supposedly affected packages follow (haven't had time to check myself). Jakub Wilk wrote: [Please Cc me, I'm not subscribed.] Indeed, I believe that the following binary packages, which ship shared libraries, are affected (i.e. linking to them will cause problems): beast boinc-dev coinor-libipopt0 csladspa htdig icedove kompozer libace-5.6.3 libassa3.5-5 libavifile-0.7c2 libclthreads2 libclucene0ldbl libcsnd-java libcsnd5.2 libcsoundac5.2 libcwidget3 libdar64-4 libebml0 libfox-1.6-0 libfreehdl0 libgdal1-1.6.0 libggadget-1.0-0 libggadget-1.0-0a libgnomecanvasmm-2.6-1c2a libgnuradio-core0 libinsighttoolkit3.16 libkbluetooth0 libkwwidgets1.0.0908 liblog4cpp5 libmailutils2 libmrpt-core0.8 libnewpki2 liborsa0c2a libparagui1.1 libpoppler-qt4-3 libpoppler5 libpt-1.10.10 libpt-1.11.2-plugins-avc libpt-1.11.2 libpt2.6.5 libqtcore4 librlog5 libsefs4 libsetools-jni libsetools-tcl libusbprog0 libvtk5.2 libwfnetobjs0c2 libwvstreams4.6-extras libwxbase2.6-0 libwxbase2.6-dbg libwxbase2.8-0 libwxbase2.8-dbg libwxgtk2.6-0 libwxgtk2.6-dbg libwxgtk2.8-0 libwxgtk2.8-dbg nemiver octave3.0 octave3.2 paraview python-csound python-setools python-xpcom setools vlc xorsa -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the mangling of ‘va_lis t’ has changed in GCC 4.4
On Wed, Jan 27, 2010 at 11:19:35PM +0200, Modestas Vainius wrote: Hello, On trečiadienis 27 Sausis 2010 22:47:55 Riku Voipio wrote: There is a major problem with gcc 4.4 and armel - the ABI of va_list changed (for c++ libraries). We need to decide one of the following: 1) library package name rename (like c2a rename previously) + the right thing to do + partial upgrades work as expected - Some hassle for !armel sid users while transition happens - Quite a bit of extra work for many unrelated people (maintainers, ftp-masters..) 2) binNMU campaign - during the upgrade armel sid users packages will be broken (some already are) - even after, partial upgrades for armel users risk broken setups + does not disturb !armel users + no extra work for others but porters and release team 3) g++ downgrade or reverting to the old va_list mangling within g++4.4 for armel - A bunch of libraries and binaries have already been compiled with the new g++ - I think this is a bad idea anyway What way should we proceed? The list of supposedly affected packages follow (haven't had time to check myself). 4) it is also possible to manually create aliases that are mangled in the old way (va_list as void*) next to the symbols which g++-4.4 will auto-generate. This means some work for the maintainers (and porters) of the directly affected library packages (fortunately, the list of which does not seem to be huge). However, we win: 1) no painful transitions or disturbance on any arch including armel (i.e. it won't be worse than it is now); 2) no massive binNMUs of rdeps; 3) less work for the release team except tracking how affected libraries are being fixed; 4) no extra work for other teams. Interesting. Do you have a example on howto do that? -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541024: FTBFS: build-dep on gone libmysqlclient15-dev package
Package: akonadi Version: 1.2.0-1 Since version 5.1.37-1, libmysqlclient15-dev is gone. The package still exists in the archive, but is uninstallable. Any package still build-depending on libmysqlclient15-dev will FTBFS. This is filed against akonadi, since it is blocking a bunch of other (kde) packages from building, and thus would profit more from a urgent fix. But I'm sure there are other packages still build-depenging on libmysqlclient15-dev too.. From the build logs: Installing positive dependencies: cdbs debhelper cmake automoc quilt pkg-kde-tools libqt4-dev shared-mime-info libmysqlclient15-dev libxslt-dev libsoprano-dev xsltproc libdbus-1-dev libboost-program-options-dev ... The following packages have unmet dependencies: libmysqlclient15-dev: Depends: libmysqlclient-dev (= 5.1.36-5) but it is not going to be installed E: Broken packages -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523995: FTBFS on armel: qreal/double mismatch
Package: kdeartwork
Version: 4:4.2.2-1
Severity: serious
Ubuntu appears to have a patch for this:
+Index: kdeartwork-4.2.1/styles/phase/phasestyle.cpp
+===
+--- kdeartwork-4.2.1.orig/styles/phase/phasestyle.cpp 2009-01-21
05:24:12.0 -0500
kdeartwork-4.2.1/styles/phase/phasestyle.cpp 2009-02-27
12:04:15.0 -0500
+@@ -2052,7 +2052,7 @@
+ qreal cx = rect.center().x();
+ qreal cy = rect.center().y();
+ qreal radius = (qMin(w, h) / 2.0) - 2.0;
+- qreal tick = qMax(radius / 6, 4.0);
++ qreal tick = qMax(double(radius / 6), 4.0);
+
+ if (dial-subControls SC_DialGroove) {
+ QRectF groove = QRectF(cx-radius+tick, cy-radius+tick,
On Sun, Apr 12, 2009 at 04:28:13PM +0100, buildd user wrote:
[ 96%] Building CXX object styles/phase/CMakeFiles/phasestyle.dir/phasestyle.o
cd styles/phase /usr/bin/g++ -D_BSD_SOURCE -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII -D_REENTRANT
-DKDE_DEPRECATED_WARNINGS -DQT_PLUGIN -Dphasestyle_EXPORTS -g -O2 -g -Wall
-O2 -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align
-Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions
-fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics
-fvisibility=hidden -fvisibility-inlines-hidden -DNDEBUG -DQT_NO_DEBUG -fPIC
-I. -I../../../styles/phase -I../../.. -I../.. -I/usr/include/KDE
-I/usr/include/qt4/phonon -I/usr/include/qt4/QtXmlPatterns
-I/usr/include/qt4/QtWebKit -I/usr/include/qt4/QtHelp
-I/usr/include/qt4/QtAssistant -I/usr/include/qt4/QtDBus
-I/usr/include/qt4/QtTest -I/usr/include/qt4/QtUiTools
-I/usr/include/qt4/QtScript -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtXml
-I/usr/include/qt4/QtSql -I/usr/include/qt4/QtOpenGL
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtDesigner
-I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtGui
-I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt
-I/usr/share/qt4/mkspecs/default -I/usr/include/qt4 -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o
CMakeFiles/phasestyle.dir/phasestyle.o -c ../../../styles/phase/phasestyle.cpp
../../../styles/phase/phasestyle.cpp: In member function 'virtual void
PhaseStyle::drawComplexControl(QStyle::ComplexControl, const
QStyleOptionComplex*, QPainter*, const QWidget*) const':
../../../styles/phase/phasestyle.cpp:2055: error: no matching function for
call to 'qMax(qreal, double)'
make[3]: *** [styles/phase/CMakeFiles/phasestyle.dir/phasestyle.o] Error 1
make[3]: Leaving directory
`/build/buildd/kdeartwork-4.2.2/obj-arm-linux-gnueabi'
make[2]: *** [styles/phase/CMakeFiles/phasestyle.dir/all] Error 2
make[2]: Leaving directory
`/build/buildd/kdeartwork-4.2.2/obj-arm-linux-gnueabi'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/build/buildd/kdeartwork-4.2.2/obj-arm-linux-gnueabi'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
**
Build finished at 20090412-1625
FAILED [dpkg-buildpackage died]
Purging chroot-unstable/build/buildd/kdeartwork-4.2.2
--
To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519170: Konqueror crashs cause entire X server to crash
I am not completely sure Konqueror is the problem. Most certainly isn't. X server should not crash no matter what the applications running in the X session to. Please file a bug against xserver-xorg-core using the reportbug tool, or follow the instructions in http://wiki.debian.org/XStrikeForce/XserverDebugging -- rm -rf only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Help with uic segfault on ARM (RC-bug)
On Wed, Oct 08, 2008 at 08:19:13PM +0200, Michael Hanke wrote: I have no clue what causes this behavior, especially as uic-qt3 works nicely on all other platforms. AFAIK uic simply generates the sources to be compiled later on, so I cannot easily see a reason for it to segfault, due to a bug in fslview. the problem is in vtk, being looked at. that is in lenny. The most recent version in unstable seems to have an additional problem on ARMEL. It is also Qt-related (missing references) and strangly also limited to that platform. this seems to get fixed by not using the -Wl,--as-needed LDFLAG. can you upload a version of fslview that doesn't use -Wl,--as-needed ? -- rm -rf only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488661: found in unstable too
found 488661 kde4libs 4:4.0.84+svn828328-1 retitle 488661 hppa: FTBFS: `debian/tmp//usr/share/man/man1/kdecmake.1': No such file or directory thanks This now hit the unstable kde4libs build: http://buildd.debian.org/fetch.cgi?pkg=kde4libs;ver=4%3A4.0.84%2Bsvn828328-1;arch=hppa;stamp=1215295531 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484552: FTBFS: kppp not built on armel
Package: kdenetwork Version: 4:3.5.9-1 Severity: important Tags: patch After working around the gadu and xmms problems, Build of kdenetwork fails with: cp: cannot stat `./debian/tmp/usr/bin/kppp': No such file or directory Which is due to: checking if kppp should be compiled... no inclusion of if_ppp.h fails to get used, since aligned_u64 isn't defined. The following patch from fedora appears to rectify building kppp with a recent linux-libc-dev. diff -up kdenetwork-3.5.9/kppp/configure.in.in.ppp kdenetwork-3.5.9/kppp/configure.in.in --- kdenetwork-3.5.9/kppp/configure.in.in.ppp 2008-02-13 03:37:48.0 -0600 +++ kdenetwork-3.5.9/kppp/configure.in.in 2008-02-15 21:29:00.0 -0600 @@ -30,6 +30,9 @@ AC_TRY_LINK([ #ifndef STREAMS #if defined(linux) + #ifndef aligned_u64 +#define aligned_u64 unsigned long long __attribute__((aligned(8))) + #endif #include linux/if_ppp.h #elif defined(__DragonFly__) #include net/ppp/if_ppp.h diff -up kdenetwork-3.5.9/kppp/opener.cpp.ppp kdenetwork-3.5.9/kppp/opener.cpp --- kdenetwork-3.5.9/kppp/opener.cpp.ppp2008-02-13 03:37:48.0 -0600 +++ kdenetwork-3.5.9/kppp/opener.cpp2008-02-15 21:30:44.0 -0600 @@ -73,6 +73,9 @@ extern C int _Precvmsg(int, void*, int #include net/if.h #include net/ppp/if_ppp.h # elif defined HAVE_LINUX_IF_PPP_H +#ifndef aligned_u64 +# define aligned_u64 unsigned long long __attribute__((aligned(8))) +#endif #include linux/if_ppp.h # endif #else diff -up kdenetwork-3.5.9/kppp/pppstats.cpp.ppp kdenetwork-3.5.9/kppp/pppstats.cpp --- kdenetwork-3.5.9/kppp/pppstats.cpp.ppp 2008-02-13 03:37:48.0 -0600 +++ kdenetwork-3.5.9/kppp/pppstats.cpp 2008-02-15 21:29:00.0 -0600 @@ -73,6 +73,9 @@ #ifndef HAVE_NET_IF_PPP_H #ifdef HAVE_LINUX_IF_PPP_H #include linux/if.h + #ifndef aligned_u64 +#define aligned_u64 unsigned long long __attribute__((aligned(8))) + #endif #include linux/if_ppp.h #elif defined(__DragonFly__) #include net/if.h -- rm -rf only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343176: qt4-x11: FTBFS on arm (cannot bind packed field)
On Tuesday 13 December 2005 15:19, Jeremy Laine wrote: I noticed there is a patch in the Debian of qt-x11-free (10_arm_gcc4.dpatch) that seems to address the same issue. The attached patch should hopefully do the trick (I haven't been able to check for myself as I couldn't find a Debian/arm machine with chroots that is up). I'm compiling it currently with your patch, and qt4-x11 has passed the point it got stuck on the buildd. It's still building, but I think it will work. Thanks! In other news, doxygen [1] Is failing to a similar issue. Jeremy, can you issue a patch for that too? Looks like doxygen is embedding parts of QT into itself.. http://buildd.debian.org/fetch.php?pkg=doxygenver=1.4.5-1arch=armstamp=1131374720file=logas=raw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324436: kde bug triage
reassign 324436 kde merge 324436 324437 thanks Hi, please check http://lists.debian.org/debian-kde/2005/08/msg00089.html for information. Kde will be broken in unstable for sometime now. Use packages from stable or testing instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321136: kedit: TRADEMARK VIOLATION
On Wed, Aug 03, 2005 at 01:19:35PM -0400, Gravis Zero wrote: The name of this software MUST be changed. Short of this, this application should NOT be distributed. First, we found no evidence of kedit or KEDIT being trademarked at uspto.gov or TESS search. Second we do not _proactivelly_ enforce trademarks. If you wish that to change, please provide some good arguments why to do so at the debian-legal mailing list. Cheers, Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315392: kmail tries to access $HOME/Mail literally, and so fails to start
Hi, If you create a new user account and use kmail in it, does it still show the same behaviour? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317359: kde: ..3'rd Help-About $KDE-app tab calls the GPL License Agreement, ie; a contract.
package kde severity 317359 wishlist thanks ...summarian conclusion: Just remove Agreement from those tabs, leave License on them. ;o) ...subject 'n justification tells the story, further discussion can be found on Groklaw and likely d-legal too, the GPL is a license because it gives a permission to do something, such as distribution, on a certain condition, also distribute the source. I'm sorry, but I find you hard to follow. I find your ideas very far-fetched. Unless the debian-legal crowd agrees that having GPL on a tab called License agreement is serious bug, I plan to close this bug soon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317363: debian unstable powerpc, gcc-4.0.0, and glibc-2.3.5
On Thu, Jul 07, 2005 at 05:44:01PM -0500, Bob Tanner wrote: Since gcc-4.0.0 is the compiler for debian unstable on powerpc, it looks like glibc-2.3.5 is a Build-Depend. and glibc-2.3.5 is not part of sid. also, please read the g++-4.0 transiotion plan[0]. kde is expected to be broken and unbuildable currently on sid. If you want to _use_ kde, use etch or sarge versions of kde. If you want to help, you can start by compilig qt-x11-free (without firebird support ) and x11-xorg from the x strike force svn[1] with gcc4, and then start compiling kde 3.4 packages with gcc4. looking on gcc4/kde3.3 bugs may be a wasted effort, unless the same bugs persist in kde 3.4 as well. Cheers, Riku [0] http://lists.debian.org/debian-devel-announce/2005/07/msg1.html [1] http://people.debian.org/~branden/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310873: kdelibs4 -- kdelibs-bin circular dependency
On Thu, May 26, 2005 at 06:57:34PM +0200, Bill Allombert wrote: There is a circular dependency between kdelibs4 and kdelibs-bin which cause aptitude dist-upgrade to try to remove the whole KDE set of packages during some woody to sarge upgrade. See Bug #310490. Can you clarify? That bug report does not explain where the conclusion comes that this is caused by kdelibs4 - kdelibs-bin interdepency. Last time we digged the kde gets removed in dist-upgrade bugs, apt developers blamed it on having lots of versioned conflicts. however, removing them did not help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309710: kdenetwork: uninstallable on sparc in sarge/sid
On Wed, May 18, 2005 at 05:04:02PM -0700, Blars Blarson wrote: This is the usual arch all/any mismatch, but this has been propigated into testing. The sparc build appears to have succeeded on May 14, but has not yet been uploaded. It also built fine on my sparc pbuilder. There is not much we (as in kde maintainers) can do about that. Why kdenetwork has been built three times successfully[1] On sparc, yet never uploaded remains a mystery. As a debian developer and sparc user , you could test and upload, but AFAIK buildd admins prefer people would not do that. [1] http://buildd.debian.org/build.php?pkg=kdenetworkver=4%3A3.3.2-3arch=sparcfile=log -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292401: kdm_config override /etc/kde3/kdm/kdmrc which is a conffile
On Fri, Mar 04, 2005 at 11:48:36PM +0100, Bill Allombert wrote: If you prefer, read http://release.debian.org/sarge_rc_policy.txt: (which is the official definition of RC) 3. Configuration files Packages must not modify their own or other packages conffiles programmatically. (The only correct way to modify a conffile is the user running an editor specifically; if anything more automated is required or useful, configuration files must _NOT_ be handled as conffiles) The policy seems to be referring to making automatic changes on conffiles in _maintainer_scripts_. During upgrade/install of packages. I would see the kdm kcontrol module as an editor optimized for editing kdmrc. It would be silly to totally ban all GUIs that edit conffiles, even if they do not store the structure perfectly as is after save. You miss the point, it is not only a config file, but a *conffile*: I don't think that the policy requires that an *editor* must keep a *conffile* in a easy to merge format. Alternatively, you could stop shipping /etc/kde3/kde/kdmrc at all, provide a non-config file /usr/share/kde/kdmrc, change kdm to read /usr/share/kde/kdmrc if /etc/kde3/kde/kdmrc does not exist. That mean people having a /etc/kde3/kde/kdmrc won't get the change from /usr/share/kde/kdmrc, but currently they won't either if they use kcontrol. I don't know if it is better. Moving /etc/kde3/kde/kdmrc to /usr/share/kde/kdmrc might be a good idea, during the discussion of this bug in IRC it was noticed that atleast some php packages have gone this route. However, I would be relucant to torture the buildd's with only this fix. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295843: Installing libarts1-xine turns off the sound
Package: libarts1-xine severity 295843 important tags 295843 +moreinfo thanks No responses our request for more info, or anyone else confirming this bug either. Sometimes I wish settting the severity of the bug required confirmation from atleast one other user... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295843: Installing libarts1-xine turns off the sound
Hi, I'm not really convinced this is a serious bug, but rather an configuration error, since libarts1-xine is installed by a very large user base (including me) via kdemultimedia metapackage, and nobody else has complained so far... On Fri, Feb 18, 2005 at 09:40:25AM -0500, Slaven wrote: For some reason if I install this package I loose all sound on my computer (or better say all arts related sound). Are you sure it doesn't just fiddle with your mixer settings? As soon as I purge the package and restart kde I get the sound back. I am running clean sarge system installed from scratch. Please let me know how can I provide more information that may be relevant to this problem. I have Ensoniq 1731 sound card. Thanks, For starters, are you using alsa or oss. And what have selected as output device in kcontrol. Do the mixer setting (using alsamixer) look different when using a libarts1-xine session than a working session? Does sound work in normal xine? what are your xine settings? does running artsd on command line result any errors? Any sound-related errors in ~/.xession-errors ? Those questions for starters atleast. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291867: konqueror: Can't generate preview thumbnail for RealVideo files
On Sun, Jan 23, 2005 at 05:57:15PM +, David Johnson wrote: If I have a directory full of images and videos, Konqueror will happily generate preview thumbnails for each one until it reaches a RealVideo file, at which point it will stop generating thumbnails and sit there with the progress wheel whirring forever. In konqueror, file associations, what do you have as rm/ram viewer and embedder? If that app can't render the image for konqueror, this bug should be assigned to it. Presumably KDE is not able to generate a preview for such files, in which case it shouldn't try to. This is preventing it from generating previews for the rest of the files in the directory. You can set it off yourself in the same menu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286476: konqueror: valgrind info
severity 286476 important thanks ==4342==by 0x1CADA428: SmcOpenConnection (in /usr/X11R6/lib/libSM.so.6.0) ==4342==by 0x1C5683EA: QSessionManager::QSessionManager(QApplication*, QString, QString) (in /usr/lib/libqt-mt.so.3.3.3) kio (KIOConnection): ERROR: Header read failed, errno=104 kio (KIOConnection): ERROR: Header has invalid size (-1) kio (KIOConnection): ERROR: Header read failed, errno=104 kio (KIOConnection): ERROR: Header has invalid size (-1) This looks like it is loading a broken page from session, history or cache. Try creating a new user account and using konqueror there. For your current user, you need to find the broken files under ~/.kde/ . strace may be of help.
Bug#286476: konqueror: valgrind info
On Wed, Dec 22, 2004 at 05:48:22PM +0530, Joshua N Pritikin wrote: the header stuff disappeared but I still get: konqueror: ERROR: Error in BrowserExtension::actionSlotMap(), unknown action : searchProvider Those messages are visible here too, but don't cause konqi to exit. The error is somewhere else.
Bug#283339: Forward upstream, please?
severity 283339 important tags 283339 +upstream thanks (Downgrading, since the only affected program is working this bug around) Achim, can you forward this issue upstream? After reading this bugreport, I don't really feel confident that I understand the bug enough to make a sensible summary for bugs.kde.org.
Fixed in NMU of kdelibs 4:3.3.1-3
tag 285391 + fixed quit This message was generated automatically in response to a non-maintainer upload. The .changes file follows. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 13 Dec 2004 18:53:21 + Source: kdelibs Binary: kdelibs4 kdelibs-bin kdelibs kdelibs4-doc kdelibs-data kdelibs4-dev Architecture: source i386 all Version: 4:3.3.1-3 Distribution: unstable Urgency: high Maintainer: Debian Qt/KDE Maintainers debian-qt-kde@lists.debian.org Changed-By: Riku Voipio [EMAIL PROTECTED] Description: kdelibs- KDE core libraries metapackage kdelibs-bin - KDE core binaries kdelibs-data - KDE core shared data kdelibs4 - KDE core libraries kdelibs4-dev - KDE core libraries (development files) kdelibs4-doc - KDE core library documentation Closes: 285391 Changes: kdelibs (4:3.3.1-3) unstable; urgency=high . * Fix kdeaccessability Conflict. Closes: #285391 * Added patch to fix half of Konqueror Window Injection Vulnerability CAN-2004-115. kdebase upload will fix the rest. Files: a7c420ebe9db930b74b910a0c49cf6fe 1185 libs optional kdelibs_3.3.1-3.dsc ae50f903ed3e7f618285ef5e517678e3 324702 libs optional kdelibs_3.3.1-3.diff.gz c6e87a8f86fffd80682bd56f8b9eaafe 871042 libs optional kdelibs-bin_3.3.1-3_i386.deb b3beb77287d215c6f5cb25047ac92b17 8131216 libs optional kdelibs4_3.3.1-3_i386.deb abb9d9a3584f90df448928162a02f34b 1229002 libdevel optional kdelibs4-dev_3.3.1-3_i386.deb 90e86046aed285e39948ef207e810fe8 17134 kde optional kdelibs_3.3.1-3_all.deb 27cbc2f3d78c16190a6f6c70e2a2563c 7070702 libs optional kdelibs-data_3.3.1-3_all.deb b3a81cce7673b326fe109251122de430 11471152 doc optional kdelibs4-doc_3.3.1-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBvgGFibPvMsrqrwMRAjI3AJwIN6WZUb/Y6aZqZ0s6jjF/gXDh0gCg6+T1 35JDV08SgkUS7SHNYss1vgI= =TGD9 -END PGP SIGNATURE-
Bug#285243: kdelibs4: Undefined symbols cause serious breakage
On Sat, Dec 11, 2004 at 11:36:54PM +0100, Andy Ruddock wrote: Having just dist-upgraded I find that none of the KDE apps run because of undefined symbols in one or more libraries: 1) did relogin to kde after upgrade? 2) from what versions of kde* and libqt3c102-mt did you upgrade from? or If you can't remember, how long it was since you dist-upgraded last time? kpat: relocation error: /usr/lib/libDCOP.so.4: undefined symbol: _ZN6QGDict4readER11QDataStreamRPv kate: relocation error: /usr/lib/libkdefx.so.4: undefined symbol: _ZN7QObject5eventEP6QEvent kdevelop: relocation error: /usr/lib/libkdefx.so.4: undefined symbol: _ZN6QStyle6polishEP12QApplication ktuberling: relocation error: /usr/lib/libkparts.so.2: undefined symbol: _ZN6QGDict4readER11QDataStreamRPv These look like QT symbols instead of kdelibs symbols. ii libqt3c102-mt 3:3.3.3-7 Qt GUI Library (Threaded runtime v
Bug#284985: kdepim needs rebuild without gnokii support
On Sat, Dec 11, 2004 at 01:34:59PM -0800, Daniel Schepler wrote: I'll look into this. Any upload should also address the issue of kmail taking too long to build on some archs and timing out the buildd's. Any suggestions on that? That's not really kdepims fault. Really the thing you can do, before uploading, send to [EMAIL PROTECTED] mail asking increase timeout for kdepim. I tried compiling kdepim on arm, and it took the normal ~12h, so It would seem that timeouts where contemporary. Cheers, Riku
Bug#183702: Update and some tests on the kdelibs upgrade problem
On Sun, Nov 28, 2004 at 04:28:00PM +0100, Frank Lichtenheld wrote:
Especially apt-get still gets confused by the kdelibs4 - kdelibs -
kdelibs3 relations (kdelibs{,3,4}-bin is similar). I would suggest
going for the meta-package solution proposed earlier in the bug report.
The problem with creating kdelibs3 metapackage, is that it leaves kde2
packages depending on kdelibs3 still on the system. And unsuprinsgly
they will no longer work, since the actual libs are gone...
We have created a kdelibs3 and a kdelibs3-bin package with equivs that
just depend on kdelibs4(-bin) (= 4:3.2). That seemed to resolve all the
problems with apt-get, however we haven't tested all the possible
combinations of woody/sarge apt-get/aptitude (yet).
Did you check if packages depending on kdelibs3 where still installed
on the system after upgrade?
Re: meta-kde-extras upload pending
On Sun, Nov 21, 2004 at 02:46:11AM +0100, Adeodato Simó wrote:
can't we really loose this source package and have only meta-kde, that
generates kde{,-devel}-extras? is there some advantage/rationale for
having both?
In long term yes, but I think we should avoid structural changes in our
packages at this point, even if they are relatively minor.
Bug#281955: kdepim: FTBFS uses too much space/time to build
Daniel said: I don't see what I can really do about this. Dropping the static libraries entirely would be a policy violation, and compiling static libraries which contain just one big .o file wouldn't be much better. Reading policy about static libs[1] says The static library (libraryname.a) is usually in addition to the shared version, which doesn't sound like a requirement. More importantly, what real life use static kdepim libraries when there are no static libs for the underlying libraries? In other news, kdepim not getting compiled is getting a showstopper on our kde 3.3 for sarge, please quest. [1] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static
Re: Accepted meta-kde 5:42 (all source)
On Wed, Nov 17, 2004 at 08:49:23AM +0100, Adeodato Simó wrote: * Josh Metzler [Tue, 16 Nov 2004 19:55:36 -0500]: meta-kde (5:42) unstable; urgency=medium . * The why is kde in debian still 3.1.2 Release * Disconnect meta-kde version numbers from kde. Why did you change the version to 42? And, why did you increment the epoch to 5, as 42 is already a higher version than 3.1.2? still, I'm not sure I wholly agree with the decision. I know other packages do that too (e.g., 'gnome'), but I think I wouldn't mind having a meta-kde upload for each kde update for the benefit of a percentage of our users. There would be still times when meta-kde version could be out of sync with kde in sarge (since they can migrate independently). Since meta-kde doesn't come from kde sources, and looking at how meta-gnome2 is done, I chose to sheepishly follow. Chris also agreed with changes, so I went forward. As an afterthought, I could have remembered, that not everone is on the #debian-kde channel these days, and Josh is right that the epoch increase is uneccessary.
Bug#266760: this is a bug in arts and therefore affects sarge, too
On Tue, Oct 26, 2004 at 09:51:14PM -0400, Josh Metzler wrote: Known workarounds: - do not set arts to use realtime priority Maybe we should just drop setuid bit from artswrapper? That might save us from a security upload in future... The drawback is that 2.6 kernel users might get annoyed that they have to use dpkg-statoverride to enable realtim priority.
Bug#276607: Handling kde upgrades: was: #276607
On Fri, Oct 15, 2004 at 03:51:51AM +0200, Adeodato Simó wrote: $ dpkg -x libmimelib1_3.2.3-1_i386.deb before $ dpkg -x libmimelib1_3.3.0-1_i386.deb after $ objdump -TC before/usr/lib/libmimelib.so.1.0.1 | grep AllFieldBodiesAsString 0001cf60 gDF .text 00be Base DwHeaders::AllFieldBodiesAsString(DwString const) $ objdump -TC after/usr/lib/libmimelib.so.1.0.1 | grep AllFieldBodiesAsString $ this obviously leads to broken installations if one upgrades mimelib without upgrading, e.g., kmail. It's an upstream issue. SONAME should be changed on each incompatible change. However, as it appears that kde isn't going to respect that... this would be achieved via conflicts or similar methods, and of course only for binary packages from a same source package. for example, one could have the kdepim-base (empty) packge on which all kdepim binary packages would depend on (with = X.Y.Z-d, and kdepim-base itself would conflict all other kdepim packages X.Y.Z *and* X.Y.Z. if the above is regarded as to cause more grief than it would solve, reconsider after s/X.Y.Z/X.Y/ in the last line of the above paragraph. At kde maintainanence, we have traditionally avoided using versioned conflicts, as the apt maintainer is claiming that they should only used in extreme cases, and that kde's current wide use of versioned conflicts is making (for example) apt-get dist-upgrade from woody to sarge (see #183702 and #183985 for example). However, we may need to make our package interdepencies more strict. Every time any new kde packages are uploaded to sid or migrate to sarge, we get a bunch of Unresolved symbol Z4FooBar or I dist-upgraded and nothing works anymore bug reports. After all of the kde upload bunch is migrated, the problems disappear, which ofcourse is sign that our depencies are not strict enough. However, is just enforcing same version within the source package isn't enough? For example, as far as I can know, in kde some symbol could be dropped in kdelibs 3.4, and if kdepim uses that symbol, it won't work anymore after the new kdelibs is installed. To properly enforce it, we would need a more brutal approach: Package: kde-version Version: 3.3.0 Conflicts: kdelibs4 ( 3.2.99 ), kdelibs4 ( 3.3.0.99 ) Package: kdelibs4 Version: 3.2.3-3 Depends: kde-version ( = 3.2.3 ) Package: kdelibs4 Version: 3.3.0-1 Depends: kde-version ( = 3.3.0 ) Now, since most kde packages depend on kdelibs4, we don't need to explictly conflict with all kde packagess. However, the change would make life for sid users a real pain in the ass. Instead of kde being _unusable_ when a new kdelibs-kdebase-kdepim etc chain is in progress of being uploaded (ie most of the time), kde would be _uninstallable_. So the bug reports would be Can't install kde in sid and Apt-get dist-upgrade is holding kde packages instead of the ones in the earlier paragraph. Your idea (per-source base packages) improves the situation, for some reason especially kmail users seem to mix different versions of the supporting libraries provided by kmail, and end up with a broken kmail. I'm not sure what would be the proper way to solve all cases, as symbols seem to appear and disappear even between minor releases.
Bug#266760: KDE Logout Hang because realtime artsd: a followup
On Fri, Oct 01, 2004 at 05:01:45AM +0200, Adeodato Simó wrote: [This is a crosspost to Debian Bug#266760 and KDE Bugs #88401 and #86426, plus the debian-kde mailing list.] - the culprit of root of all evil seems to be kdeinit_shutdown in /usr/bin/startkde: I'd say the hang is produced when kdeinit (as per kdeinit_shutdown request) tries to shutdown an arts process that is in the middle of playback. the lines in question are: That would be an arts bug then, right? By adding a sleep 10 to startkde we would just be working around the bug that artsd running on realtime priority deadlocks the system if killed while playing back?
Bug#274779: kdebindings / libqt-perl conflict
On Thu, Oct 07, 2004 at 12:45:17PM +0200, Pierre Habouzit wrote: Le Jeudi 7 Octobre 2004 12:31, Adeodato Simó a écrit : note that if you have libqt-perl installed, you'll have to --force-overwrite libsmokeqt1 and libsmokeqt-dev (#274779). uho taht's bad you have to make either a conflict or a diversion !! Yes, I have to agree. Conflicts: libqt-perl is probably the best stop-gap measure at the moment.
Bug#270700: acknowledged by developer (kdelibs-data can't be upgraded)
On Fri, Sep 24, 2004 at 01:46:39PM +0200, Yann Forget wrote: Closing bug since it is a bug in a package not in Debian. What does mean in a package not in Debian? This is a package from Debian. Let's have a look at the original report: dpkg: error processing /var/cache/apt/archives/kdelibs-data_4%3a3.3.0-1.1_all.deb (--unpack): trying to overwrite `/usr/share/services/mms.protocol', which is also in package kplayer [16:23 wombat]~ apt-cache show kplayer W: Unable to locate package kplayer E: No packages found [16:24 wombat]~ EOD.
Bug#266760: kde: kde crashes X when quitting
tags 266760 +moreinfo,+help,+sid thanks Hi, This is probably an X or kernel bug, right? even if kdm included buggy code, the x server should not kill the machine for it. Peder Wrote: To get a stable (!) unstable system with KDE 3.3, no freezing problem at logout and no problems with tcsh I instead implement the solution to the tcsh problem described in bug 266814. You mean, that by fixing the Xsession, kde no longer crashes on logout? Xsession is known to be broken in unstable at the moment, and it can be fixed either by replacing /etc/kde3/kdm/Xsession with --snip-- #!/bin/sh . /etc/X11/Xsession --snip-- Or with patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265865msg=22
Bug#272140: request to remove kmilo from the list of kde dependencies
tags 272140 +upstream tags 272140 +wontfix severity 272140 wishlist thanks FINDINGS kmilo is listed as one of the packages kde depends on. Removing kmilo causes deinstallation of major part of kde. It deinstalls only itself and kde/kdeutils metapackage. there is no functionality in kde/kdeutils packages, they are simply a convinience to get ALL of kde/kdeutils installed easily. TO RESOLVE remove kmilo from list of packages kde depends on, so that kmilo could be installed/deinstalled independently without causing problems with other kde dependencies. kmilo is disabled by default, so if you have problems after enabling it, you can just re-disable it and it should't cause any problems again.
Bug#272229: Source for kdebase 3.3.0 fails make
On Sat, Sep 18, 2004 at 09:48:06AM -0500, Michael Satterwhite wrote: Package: kdebase Version: 4:3.3.0-1 Severity: serious Justification: no longer builds from source If the source for kdebase is retrieved and ./configured, it will fail in make with the following messages: Excactly what ary trying to do? I just did in clean, uptodate sid chroot: apt-get build-dep kdebase apt-get source -b kdebase And kdebase compiled fine. From your description, it sounds like you are using the configure scritps by hand, instead of using the debian building tools.
Bug#270389: kdelibs: t-p-u upload FTBFS on m68k
On Tue, Sep 07, 2004 at 12:03:17AM -0700, Steve Langasek wrote: Trying to build kdelibs 3.2.3-3.sarge.2 on m68k failed with the error: Making all in kspell make[4]: Entering directory `/build/buildd/kdelibs-3.2.3/obj-m68k-linux/doc/kspell' ../../kdoctools/meinproc --srcdir=../../../kdoctools --check --cache index.cache.bz2 ../../../doc/kspell/index.docbook make[4]: *** [index.cache.bz2] Error 139 Usually meinproc errors we have seen so far have been building machine running out of ram/disk space. Since all the other builds came out fine, this seems probable this time too.
Bug#269132: arts 1.3 + kde 3.2?
On Tue, Sep 07, 2004 at 01:01:04AM -0700, Steve Langasek wrote: Bug #269132 was opened to hold arts 1.3 out of testing, on the grounds that it has not been tested with kde 3.2. Has anyone had time to do such a test? It would be good to know if the 50-some packages blocked by arts currently will need to make other arrangements for sarge. Just installed arts and its libs, as well as the newer QT it depends on, and after logout login music is still playing fine in kaffeine. Also tried kaboodle and arts control panel, and everything works so far. I have the arts plugins from kdemultimedia installed, but I have no idea if they are being used (AFAIK kaboodle should).
Bug#263667: Please use gcrypt11/gnutls11 instead of gcrypt7/gnutls10
'kdelibs-bin' depends on gcrypt7 or gnutls10. As far as I can see it doesn't[1]. We do however depend on libcupsys2-gnutls10, which despite of the confusing name, depends[2] on gnutls11 already. Is your massfiler buggy or did I miss something? [1] http://packages.debian.org/unstable/libs/kdelibs-bin [2] http://packages.qa.debian.org/c/cupsys/news/2.html -- Riku Voipio| riku.voipio at iki.fi | kirkkonummentie 33 |+358 44 5000343 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Re: strange kdepim failure on m68k build
On Fri, Apr 30, 2004 at 05:06:45PM +0200, Wouter Verhelst wrote: On Fri, Apr 30, 2004 at 09:44:35AM -0500, Joaquin Ortega wrote: Kdepim (kdepim_4:3.2.2-2) failed to build twice on the m68k buildd (kullervo.debian.org). It has been labeled as failed and won't be built automatically. The reason given on the log is Ouch... tries to write outside build directory: Because, indeed, it does: it tries to write to $HOME/.kde , which is outside the build directory. That's not allowed; it's a bug (even if no report has been filed). meinproc only complains if it fails to write the config files. The m68 build is failing for some other reason. See The arm buildd log for example: http://buildd.debian.org/fetch.php?pkg=kdepimver=4%3A3.2.2-2arch=armstamp=1083165502file=logas=raw -- Riku Voipio| riku.voipio at iki.fi | kirkkonummentie 33 |+358 44 5000343 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver | signature.asc Description: Digital signature
Re: kdenetwork and kdemultimedia are stuck...
On Wed, Apr 28, 2004 at 10:35:17PM -0400, Christopher Martin wrote: Hello, kdenetwork isn't moving into Sarge. According to http://bjorn.haxx.se/debian/testing.pl?package=kdenetwork, this is this is because kmail and friends moved from kdenetwork to kdepim. they should migrate to sarge at same time in a few days. kdemultimedia isn't moving into Sarge because education-standalone-extras, education-thin-client-server, and education-workstation depend on packages, like kmidi, which it no longer provides. Either these edu packages need to be updated, or they need to be yanked from Sarge temporarily. I'm not sure what the normal procedure is. can you file a bug against those packages to stop referencing to kmidi and other packages no longer in kdemultmiedia? -- Riku Voipio| riku.voipio at iki.fi | kirkkonummentie 33 |+358 44 5000343 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#246310: kopete: An internal Kopete error occurred while parsing a message:
package kopete forwarded 246310 http://bugs.kde.org/show_bug.cgi?id=75497 thanks Before filing bugs that are probably not caused by debian packaging, it is allways worth searching the kde bug tracking system, if the bug has already been filed and handled there. WORKAROUND: If you are experiencing this with ICQ, set an appropriate encoding for the contact in its ICQ User Info and you will not get this error any more. -- Riku Voipio| riku.voipio at iki.fi | kirkkonummentie 33 |+358 44 5000343 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#246391: konqueror is broken
tags 246391 +sarge thanks I just tried to install kde apt-get install kde, the installation breaks installaing konqueror, I tired with apt-get -f install as apt said without success below is the output You will have to wait overnight (or a few days if your mirror lags) for the new kdebase to migrate to testing for konqueror to be installable. -- Riku Voipio| riku.voipio at iki.fi | kirkkonummentie 33 |+358 44 5000343 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#245645: /usr/bin/konqueror: konqueror renders a page a second time, far right of original
package konqueror severity 245645 minor tags 245645 +upstream thanks On Sat, Apr 24, 2004 at 07:32:02AM -0500, Brian McGroarty wrote: http://www.empiricalsoup.org/ That page is far from correct[1] html. Ofcourse, there are lots of buggy web pages out there, and khtml tries to be as bug-to-bug compatible with major browsers, but sometimes it might be better to use your time persuading the web page author to create standard-compatible pages rather than to bloat browsers with a yet another workaround. This does not seem to happen with other browsers. This does not happen on other web pages. Seriously, if you think there is a rendering bug in khtml (konqueror), you need to create a simplified test case[2] and submit it to the upstream bugzilla[3]. We simply do not have enough time to find the bug-triggering html from the page. [1] http://validator.w3.org/check?uri=http%3A%2F%2Fwww.empiricalsoup.org%2F [2] http://www.mozilla.org/newlayout/bugathon.html#testcase [3] http://bugs.kde.org/ -- Riku Voipio| riku.voipio at iki.fi | kirkkonummentie 33 |+358 44 5000343 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Re: kdecore (KIconLoader): WARNING: ...
On Thu, Apr 22, 2004 at 03:54:16PM +0200, Laurent wrote: Hello, I have installed hicolor-icon-theme-0.5-2 and kdelibs*-3.2.2-2 on my up-to-date SID. When I launch konqueror, I get a bunch of warnings: [15:15:02] [EMAIL PROTECTED]:~$ konqueror kdecore (KIconLoader): WARNING: Icon directory /usr/share/icons/hicolor/ group 16x16/stock/data not valid. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241283 It the versions you give above are correct, that bug needs to be reopened. And an other thing, in a first kde run, fonts are ugly, why are not set to Bitstream Vera Sans for example, it would unify kde and Gnome ? Does anyone know where kde grabs the default fonts? From the behavoiur I have seen, it seems like it just grabs the first ones in alphabetic listing (grah!)... -- Riku Voipio| riku.voipio at iki.fi | kirkkonummentie 33 |+358 44 5000343 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#243590: kdm is segfaulting on start
On Tue, Apr 13, 2004 at 05:19:38PM -0500, Zed Pobre wrote: I'm not sure exactly what changed that caused this behaviour. When kdm is started, X will start for just a moment, but before the greeter comes up, it will crash all the way back to the console and not restart X. Checking syslog shows an entry for kdm saying: Abnormal termination of greeter for display :0, code 0, signal 11 This is usually a sign of problems with xfree. does starting X with startx work? is there anything odd in XFree86.0.log? -- Riku Voipio| riku.voipio at iki.fi | kirkkonummentie 33 |+358 44 5000343 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#241283: kdelibs4: KIconLoader tries to load icons from strange directories
On Wednesday 31 March 2004 20:38, Laurent Bonnaud wrote: $ kedit kdecore (KIconLoader): WARNING: Icon directory /usr/share/icons/hicolor/ group 16x16/stock/chart not valid. kdecore (KIconLoader): WARNING: Icon directory /usr/share/icons/hicolor/ group 16x16/stock/code not valid. ... The various /usr/share/icons/hicolor/sizexsize directories do exist on my system. The problem comes for this spurious group string that is inserted after the hicolor path component. Do you have by any chance hicolor-icon-theme installed? If so, this probably needs to be reassigned. -- hi
Bug#240256: Can't send email through SMTP
package kmail tags 240256 +unreproducible,moreinfo thanks On Fri, Mar 26, 2004 at 03:31:02PM +0200, Martin Tsachev wrote: I just upgraded to 3.2 today and my SMTP stoppd working. I can only send email through the local Postfix. This works fine for me, so this probably just a configuration issue. With only these two lines of info, I can't help you. Try deleting your ~/.kde and reconfigure your mail setting from scratch. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#240632: Kmail crashes after I upgrade to KDE 3.2, downgrade didn't help
package kmail tags 240632 +sarge, unreproducible On Sun, Mar 28, 2004 at 04:17:39PM +0300, Martin Tsachev wrote: This started after I upgraded to KDE 3.2 from 3.1.3, I did the upgrade in KDE and Kmail was working, it only didn't want to send mail through SMTP. Then after I restarted KDE it started crashing. I removed all kde* with apt-get remove --purge and kwin, kicker, ksmserver, ksysguardd, *qt*, *arts*, removed ~/.kde and installed KDE 3.1.5 but it still crashes. Try downgrading this too: ii libmimelib1 4:3.2.1-1KDE mime library -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#240329: fails to launch
package knode tags 240329 +unreproducible thanks On Friday 26 March 2004 21:35, Nicolas DEGAND wrote: if I launch knode, it uses the hard drive extensively then fails with the following message : Can you follow the instructions here, by installing the debug packages and getting a crash backtrace or a valgrind output? http://www.kde-debian.org/~domi/debugging-kde-crash.html
Bug#235035: ksysv crashing Still a problem?
On Sun, Mar 21, 2004 at 10:18:40AM -0600, Craig Hempenius wrote: I seems to work with the debugging KDE versions. I says it crashed but I don't see it: What do you not see? [EMAIL PROTECTED]:~$ sudo ksysv SysV-Init Editor 1.3.8 Developer Version Copyright © 1997-2000 Peter Putzer. All rights reserved. Released under the GNU General Public License (GPL). kdecore (KIconLoader): WARNING: Icon directory /home/craig/.kde/share/icons/crystal/ group not valid. kio (KDirWatch): Available methods: Stat, FAM, DNotify kio (KDirWatch): Added Dir /etc/init.d [KDirWatch-1] kio (KDirWatch): Setup FAM (Req 1) for /etc/init.d ERROR: Communication problem with ksysv, it probably crashed. but you did not get a the traceback/crash window? we need that to debug the problem. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Re: KDE 3.2.1 Status Update - 20040309
On Sunday 21 March 2004 15:27, Noèl Köthe wrote: Uploaded 2 days ago but because of 3 new languages its waiting in NEW. Any idea when this will be resolved ? Please dont ask me over and over again (I get alot of requests and complaints about missing kde-i18n in sid). I have no idea when ftpmaster will approve it. Ask them not me.:) In my experience ftp-masters seem to handle packages in NEW in about 2-3 weeks. -- hi
Bug#238853: kontact: KMail in Kontact is in English, KMail alone is in Polish
package kontact reassign 238853 kde-i18n thanks I switched to KDE 3.2.1 from Debian, installed kde-i18n-pl 4:3.2.0-0pre1v1, kontact 4:3.2.1-1 and got one problem. Whole Kontact is in English instead of Polish :( If I run KMail alone it is Polish, same with KNode etc. Is is Kontact bug or I should change something? The reason is that we are still waiting for new kde-i18n pacakge. If out want Kontact in Polish now, you need to install kde-i18n-pl from experimental. Noel, whats up ith kde-i18n? you promised an upload to sid in few days a week ago? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#238189: XKB Options Configuration not working ?
On Tue, Mar 16, 2004 at 01:45:26AM +0100, Denis Barbier wrote: reassign 238189 kcontrol thanks Please do not play pingpong with bugs. Branden, do you have an opionion about this bug? should we split the setxkbmap stuff and kcontrol having keyboard options that do nothing? kcontrol uses it, so if setxkbmap has no effect either, it is clearly not a kcnotrol problem If setxkbmap has no effect, kcontrol should not display those buttons, or provide better explanations on what they do. How could kcontrol know that those options don't work, if setxkbmap doesnt tell so? The option texts are from a part of kxbd source prefixed by: // please don't change/fix messages below // they're taken from XFree86 as is and should stay the same (now there is some extra cannon fodder for the xfree86 licence change sucks) It is entirely possible, that command line kcontrol generates, setxkbmap -option caps:shift Is incorrect or wrong syntax, but without better manpage of setxkbmap, I can't really know. I do not know what kcontrol is supposed to do, but AFAICT CapsLock can not be emulated as on typewriters. The 'Shift cancels Caps' idiom means that Shift+Caps prints lowercase letters (roughly); when Shift is released, CapsLock is still locked. So if those options arent working for you, it is a problem with setxkbmap or your keyboard setup. Remember that kcontrol uses setxkbmap, and if setxkbmap fails silently, it can't really know that the specific options wont work. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#238102: Keyboard layout works fine for me
[EMAIL PROTECTED] Cc: Bcc: Subject: Re: Bug#238102: kcontrol/keyboard layout : enabling keyboard layout kills AltGr key Reply-To: In-Reply-To: [EMAIL PROTECTED] X-message-flag: Warning: message not sent with a DRM-Certified client package kcontrol severity 238102 normal thanks If I enable keyboard layout (with french keyboard), the ALTGR key is not usable anymore meaning that you cannot get | symbol which is very annoying on xterms... This is probably your own mistake. notice that in the keyboard layouts, you need to select a correct keyboard model too. Generic 105 key model is probably the one you want. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#238189: XKB Options Configuration not working ?
reassign 238189 xbase-clients severity wishlist retitle 238189 setxkbmap options syntax not documented well thanks On Monday 15 March 2004 22:53, Hervé Piedvache wrote: setxkbmap -option caps:shift seems to do nothing on my system ... not error message, no reaction ... nothing :o( setxkbmap is part of xbase-clients. kcontrol uses it, so if setxkbmap has no effect either, it is clearly not a kcnotrol problem Help needed ... better documentation may be or a package missing but ... need help please about this menu ! setxkbmap has a man page, which admittedly isnt very verbose about the actual options syntax. -- hi
Bug#237171: kmail 3.2.1 sources incorrectly reported as kdenetwork
reassign 237171 www.debian.org thanks Sorry for the bug reassigning noise looking at (atleast) the following package pages, http://packages.debian.org/unstable/mail/kmail http://packages.debian.org/unstable/kde/kopete It seems like the package descriptions arent updated properly. It may be a feature, as the old description is still valid for some arches in unstable. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#235684: kde: b key in KDE on the sparc platform doesn't work
On Tue, Mar 09, 2004 at 05:07:55PM -0500, Frederick Heckel wrote: Thanks for responding... Thanks for more info, now we can actually try to track this down... I don't know where else the bug could be-- it *only* occurs when KDE is running. Then it affects *all* applications. With any other window manager/environment(or on the text console), it never happens. It is present on all five of the Sparc systems my organization uses, each of which has a known good keyboard. So it isnt a keyboard or a xfree issue. Have you touched the keyboard setting in the control center? Regional - Keyboard layout. If you have, can you look at the contents of: ~/.kde/share/config/kxkbrc If that file exists, it should have something like Rule=sun Layout=type5 You can also try deleting the file, and kde should use whatever keyboard layout is set in X. If that doesnt work either, use the xev command both with and without kde, and report what it giver for the 'b' key. The relevant portion of XF86Config, which is reported to be correct for this model of sun keyboard and this version of XFree86 -- XF86Config-4 snippet -- Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules sun Option XkbModel type5 Option XkbLayout us EndSection -- end XF86Config-4 snippet-- Again, the problem does not occur in any other windowing environments-- we have tried to find it under fluxbox, fvwm, evilwm and others, and we have tried it with the same set of applications(such as gaim, mozilla-firebird, aterm, etc.). So I really have no idea where else the bug could possibly lie. I also maintain the severity of the bug was correct as posted, as this completely breaks most normal use of the system. (fwph) -- Frederick Heckel [EMAIL PROTECTED] (The strange attachment is my digital signature; do not be alarmed) === Yeah, but you're taking the universe out of context. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#235684: kde: b key in KDE on the sparc platform doesn't work
forwarded 235684 http://bugs.kde.org/show_bug.cgi?id=54385 thanks Hi, I think I spotted your bug on on kde bug tracking system. Can you check the link above and if removing the print binding from keyboard bindings cures the 'b' buttin for you? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#235684: kde: b key in KDE on the sparc platform doesn't work
severity 235684 normal thanks On Mon, Mar 01, 2004 at 04:59:39PM -0500, Frederick Heckel wrote: We have found that attempting to use the b key under any application in kde from sarge results in (a) b not being reported and (b) brief keyboard input failure. This is reported as a critical bug as it does break KDE quite thoroughly, and also breaks any application for which you might want to use the letter b. this cant be a kde bug. kde doesnt discriminate keys. it is either: 1) your keyboard hardware is broken (then your 'b' key wont work in terminal eith) 2) your xfree setup is broken (then you 'b' key doesnt work in xterm) -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#236771: krdc: Krdc not possible to enter password at password connect prompt
On Mon, Mar 08, 2004 at 09:34:23AM +0100, Robert Lindgren wrote: Package: krdc Version: 4:3.2.1-1 Severity: normal It's not possible to enter a password in the password prompt, it does get focus, and there is a blinking cursor, but it doesn't take any input, nor from keyboard, nor pasted passwords. This renders the packages unusable. I am using krdc without a problem in 3.2.1-1. Some questions that pop into mind: 1) have you restarted kde session since upgrade? 2) what window manager are you using? 3) Are konnecting to a vnc or rdp server? 4) what earlier kde versions have you had? -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (333, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.3 Locale: LANG=en_US, LC_CTYPE=en_US Versions of packages krdc depends on: ii kdelibs44:3.2.1-1KDE core libraries ii libart-2.0-22.3.16-1 Library of functions for 2D graphi ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libgcc1 1:3.3.3-1GCC support library ii libice6 4.3.0-5 Inter-Client Exchange library ii libjpeg62 6b-9 The Independent JPEG Group's JPEG ii libpng12-0 1.2.5.0-5PNG library - runtime ii libqt3c102-mt 3:3.2.3-2Qt GUI Library (Threaded runtime v ii libslp1 1.0.11-6 OpenSLP libraries ii libsm6 4.3.0-5 X Window System Session Management ii libssl0.9.7 0.9.7c-5 SSL shared libraries ii libstdc++5 1:3.3.3-1The GNU Standard C++ Library v3 ii libx11-64.3.0-5 X Window System protocol client li ii libxext64.3.0-5 X Window System miscellaneous exte ii libxrender1 0.8.3-5 X Rendering Extension client libra ii xlibs 4.3.0-5 X Window System client libraries m ii zlib1g 1:1.2.1-4compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#236771: krdc: Krdc not possible to enter password at password connect prompt
On Mon, Mar 08, 2004 at 12:04:00PM +0100, Robert Lindgren wrote: It doesn't help to move ~/.kde/share/config/krdcrc out of the way. The password input field is focus, but not possible to write anything to it. dammit! now I can reproduce it too.. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#236605: kdebase-kio-plugins: kio_sftp fails - bad ssh switch usage
On Sun, Mar 07, 2004 at 01:44:36PM +0100, [EMAIL PROTECTED] wrote: Package: kdebase-kio-plugins Version: 4:3.2.1-1 Severity: normal while querying via sftp through konqueror i grabbed its command from the process list and tested it to find out why it fails: ssh -p 22 -o ForwardX11 no -o ForwardAgent no -e none -l my_user_id -v the_remote_host -s sftp command-line line 0: Missing yes/no argument. This cant be your problem. I see the same command line in ps aux, but sftp kioslave works fine for my. what version of ssh do you have? 1:3.6.1p2-12 here. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Re: Bug#236605: kio_sftp
On Sun, Mar 07, 2004 at 02:59:21PM +0100, [EMAIL PROTECTED] wrote: The spec in my config :ssh_conf (or $HOME/.ssh/config Host remote_host_behind gateway ProxyCommand ssh my_remote_user_on_gateway@gateway_ip nc %h %p Which enable me to access my lan, though it ask 2 passwords. I guess i mixed between them ... kio_sftp is hard on that as it does not tell which host password is asked, and sometime lose one of them (when i acess a dir not owned by my user afaik). Your problem is that you are still using passwords. Use ssh keys and ssh-agent instead. read the ssh-keygen man page and some tutorial from google to get started. Which reminds me, that there is a serious need for graphical ssh key manager... -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#236078: kdm in testing / unstable does not validate passwords
On Fri, Mar 05, 2004 at 01:10:13AM -0600, Wayne Schroeder wrote: The auth.log (messages or syslog either) prints anything out when you login. It just lets you right in. libpam-runtime0.72-35 libpam0g 0.76-15 you need a newer libpam-runtime. If this goes away by upgrading libpam-runtime, this is the same bug as #233562. But with more serious impact. It is probably fixed with the latest kdebase upload in sid. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#236078: kdm in testing / unstable does not validate passwords
On Wed, Mar 03, 2004 at 07:20:59PM -0600, Wayne Schroeder wrote: Package: kdm Version: 3.1.5-2 Fresh woody install, new 2.4.25 kernel, apt-get install -t unstable x-window-system for my geforce4 etc, apt-get install -t testing kde kdm. mixing distribuitions like that isnt really supported. Granted, the depency system should figure out correctly, but nothing guarantees it. Everything is great except that kdm doesn't check my passwords at login. I can login as any user, including root, with any password. This sounds definetly scary, however, we need some more info. Specifically, The versions of following packages, and if not the versions in sarge, try with the sarge versions: libpam-runtime libpam0g kdelibs4 contents of /etc/pam.d/kdm /etc/pam.d/common* Also, /var/log/auth.log could carry some clues. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Re: KDE 3.2.0 Status Update - 20040221
On Tue, Feb 24, 2004 at 11:37:59AM +1100, Ben Burton wrote: The problem in my mind is not people being denied access to KDE 3.1.5. It's that once KDE 3.2 is in sid we more or less become committed to releasing sarge with 3.2, since we'll no longer be able to upload bugfixes for KDE 3.1.5. isnt testing-proposed-updates for that? This means that before sarge freezes we have to not only iron all the faults out of KDE 3.2, but we also have to locate and fix problems with 3rd-party apps that only appear with KDE 3.2. (Specifically I worry about *locating* these 3rd-party problems since it doesn't leave very much time at all for testing.) The we should probably notify all 3rd party maintainers to try running/compiling their packages against kde 3.2 in experimental/p.do packages. IMHO the real problem is arm/mips/mipsel/m68k - nothing guarantees that they will compile our packages in timely manner. I am not really happy of the thought that providing the best possible kde to 99% of our users depends on compiling kde on platforms whose users will probably not really use kde for anything :( -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Re: KDE 3.1.5 Status Update - 20040217
debian-release@lists.debian.org Cc: Bcc: Subject: Re: KDE 3.1.5 Status Update - 20040217 Reply-To: In-Reply-To: [EMAIL PROTECTED] On Wed, Feb 18, 2004 at 05:06:19AM -0600, Colin Watson wrote: As for the remaining things to happen before jack-audio-connection-kit and alsa-lib can be promoted, which will include kdeaddons, kdebase, and kdegames: Taking a liberty to reorder your list a bit: ardour needs to be built on arm ardour waits for raptor which needs newer redland redland is waiting for perl perl needs to be built on m68k, but has problems (#233175) libjackasyn has just had bug #232605 fixed, which needs to be built I think nothing depends on ardour libs or libjackasyn, so if take an aggressive aproach in killing this deadlock, we can remove those two from testing and let them back when they have recovered from their own problems (ardour-raptor-redland need their own set of hints anyway?) spiralsynthmodular is 7 days old; needs 10 This seems no problem. gst-plugins needs to be built on mipsel gst-plugins is 2 days old; needs 10 That would leave us with these two problems. Removing gst-plugins from testing would brake alot, so it seems out of question. Eight days fingers crossed nobody chooses to reupload any packages depending on Jack. I wish I could be confident of the timely mipsel build too. So, getting there ... If we are lucky yes. In a longer term we really need a less fragile way of getting largely interdependant packages timely to testing. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#233583: ksysguardd: Wrong dependencies
tags 233583 +sarge thanks On Wed, Feb 18, 2004 at 10:28:54PM +0100, Nikolas Garofil wrote: Package: ksysguardd When I tried to apt-get install ksysguardd, it gave a error because it couldn't find the dependency libsensors-1debian1. Shouldn't this be libsensors1 ? Yes, we know ksysguardd is uninstallable and it will be fixed as soon as next version (3.1.5-2) migrates to testing. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Fixed in NMU of kdepim 4:3.1.5-1.1
tag 217013 + fixed tag 232500 + fixed quit This message was generated automatically in response to a non-maintainer upload. The .changes file follows. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 15 Feb 2004 11:06:49 + Source: kdepim Binary: knotes kdepim-dev kdepim-libs kdepim-kfile-plugins kdepim kandy ksync kaddressbook kalarm kpilot korganizer karm kdepim-doc Architecture: source i386 all Version: 4:3.1.5-1.1 Distribution: unstable Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-kde@lists.debian.org Changed-By: Riku Voipio [EMAIL PROTECTED] Description: kaddressbook - KDE NG addressbook application kalarm - KDE alarm message and command scheduler kandy - KDE mobile phone utility karm - KDE time tracker tool kdepim - KDE Personal Information Management metapackage kdepim-dev - KDE Personal Information Management (development files) kdepim-doc - KDE Personal Information Management documentation kdepim-kfile-plugins - KDE File dialog plugins for vcf files. kdepim-libs - KDE PIM libraries knotes - KDE Notes korganizer - KDE personal organizer kpilot - KDE Palm Pilot hot-sync tool ksync - KDE Sync Closes: 217013 232500 Changes: kdepim (4:3.1.5-1.1) unstable; urgency=low . * NMU with Maintainers permission * New patch: 07_libmal1_support.diff from Ludovic Rousseau (Closes: #232500, #217013) Files: f0dadbe07ab04dd2990bfb4d464bb903 971 kde optional kdepim_3.1.5-1.1.dsc 9f20249be911be1582e976a684dcd7a4 48156 kde optional kdepim_3.1.5-1.1.diff.gz c2e841266c12c22bc375dfc646a64d4e 32138 devel optional kdepim-dev_3.1.5-1.1_i386.deb ed1bcc40c1c81d85ce6208dd6a4633b1 344676 utils optional kaddressbook_3.1.5-1.1_i386.deb 8a43ee5615c73820abef41d050f41865 319872 kde optional kalarm_3.1.5-1.1_i386.deb 79ad73ff95ee954f42b5b6850b69d76d 81252 utils optional kandy_3.1.5-1.1_i386.deb f1bb2aa096b1c7f152c9d10e9daf6c44 89024 utils optional karm_3.1.5-1.1_i386.deb e2a581021c475a5ca111986aabed780e 14312 kde optional kdepim-kfile-plugins_3.1.5-1.1_i386.deb 164462bad075ea22fdb2b721bd9301a3 438082 libs optional kdepim-libs_3.1.5-1.1_i386.deb 954a005dfc6865684cde2ebe8526dda0 92078 kde optional knotes_3.1.5-1.1_i386.deb bfe0ffcbe85b07cc1d3262401798fba5 805270 kde optional korganizer_3.1.5-1.1_i386.deb 7203eef1b2763f3a3578a424e2498848 825014 utils optional kpilot_3.1.5-1.1_i386.deb 7e1d6f545268a2e1d93d1f56993ada48 49200 utils optional ksync_3.1.5-1.1_i386.deb c46b08a46afa4043b926e1b283d90829 4828 kde optional kdepim_3.1.5-1.1_all.deb fc1ce135d292df5c11912db6581d141a 2495410 doc optional kdepim-doc_3.1.5-1.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAL3dIibPvMsrqrwMRAq8nAJ4/FRojVHKWLqDibNKbrXJQ14r1pgCffw+d 7qFuwM26Ep2C8Q9X94Gllw8= =ZiKO -END PGP SIGNATURE-
Re: KDE 3.1.5 Status Update - 20040209
On Tue, Feb 10, 2004 at 11:36:14AM -0600, Colin Watson wrote: On Mon, Feb 09, 2004 at 12:55:55PM -0600, Chris Cheney wrote: kdebase 3.1.5-2 --- mipsel - failed - needs retry with unbuilt qt-x11-free (see below) (Feb 4) s390- failed - bad kernel headers? (Feb 6) kdegames 3.1.5-1 arm - Needs-Build (Feb 9) mips- Needs-Build (Feb 9) There's going to be one problem with these two, namely that they both need newer alsa-lib which needs newer jack-audio-connection-kit than what's in testing, Add kdemultimedia to that list, when it finally gets built on arm, (need to increase buildd idle timeout..) it will need the newer alsa on arm. I'm inclined to remove some packages from testing to speed the way, but one of the affected packages is gst-plugins and that's a dependency of meta-gnome2, so that can't be so easily swept aside ... A newer upload of gst-plugins seems to be required in any case, since the latest gst-plugins does not compile with the latest alsa. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Re: KDE 3.1.5 Status Update - 20040201
Btw, I think it would be more usefull, if this would be in (rough) depency order instead of alphabetical. On Sunday 01 February 2004 10:06, Chris Cheney wrote: A few of the packages finally got reset to Needs-Build but there are still many more that need to be reset... The buildd infa appears been somewhat flaky during the auric - newraff transition. qt-x11-free 3.2.3-2 --- arm - Building (Jan 23) - appears done but the admin never uploaded mipsel- Needs-Build (Jan 22) This is the biggest showstopper NOW. Has anyone nagged the arm/mipsel admins on these? kdebase 3.1.5-2 --- waits also for the alsa-lib/jack-audio-kit. no RC bugs thou, just a lot of stuff to buildds to churn. kdemultimedia 3.1.5-1 - arm - failed - needs retry (possibly with longer timeout) (Jan 15) This looks more like the buildd admin canceling the build (probably realized it was using a broken g++). unfortunatly an arm compile *now* would result kdemm to wait for alsa-lib...
Re: Consider building ksysguardd without libsensors support for now?
On Mon, Jan 26, 2004 at 05:43:07PM +, Colin Watson wrote: I notice that the lm-sensors dependency is i386-specific, so presumably it's just an optional feature. I'd really like to remove this roadblock so that we can get on with other things, and maybe put it back later if and when lm-sensors gets sorted out. Would you consider building ksysguardd without lm-sensors support for now? Personally I'm all for it, lm-sensors has given nothing but grey hairs, and sensors aren't the main functionality of ksysguardd anyway. If someone uses the feature, maybe this move will enough to motivate them to get lm-sensors fixed. We would sitll have to wait for qt to compile to on mipsel to avoid getting a failed build and getting kicked into the end of que... If Chris is busy (preparing kde3.2 debs the unwashed hordes will want the second it is released), I have no problem uploading this (oneline) fix. AFAIK the other pending issues are the kate libkregexpeditor - kregexpeditor recommends update and possibly #203722 (-mieee for alpha). previous is trivial but the latter needs confirmation from the submitter, or someone else owning an alpha. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Re: KDE 3.1.5 Status Update -- 20040113
On Wed, Jan 14, 2004 at 01:39:12PM -0500, Nathanael Nerode wrote: Chris Cheney wrote: kdelibs --- m68k - failed - needs retry (waiting on qt-x11-free) mips - failed - ICE #226727 Please try to find a workaround for this ICE (or help find fix it). This appears to be moot, kdelibs compiled fine[1] on mips yesterday. The gcc version is same, but the building host different... The m68k porters are also very helpful and are compiling kde packages by hand as there are various issues bringing all the buildd's back post-compromise. The only thing I'm worried about (testing-wise) is the lm-sensors depency in kdebase. Which I assume you are working on already. It's also not top priority for GCC since gcc-3.3 is still producing silently wrong code in some situations (which comes first, of course). There's nothing new here. xlib6g/hppa for example doesn't[2] work in woody because of gcc miscompilation, which was fixed[3] in gcc-3.3... [1] http://buildd.debian.org/build.php?pkg=kdelibsver=4%3A3.1.5-1arch=mipsfile=log [2] http://lists.debian.org/debian-hppa/2002/debian-hppa-200205/msg00085.html [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204844 -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#212212: kdebase-bin: /usr/bin/kcheckpass has to be SUID root
On Thu, Jan 08, 2004 at 09:20:51AM +0100, Boris Boehlen wrote: On my box kcheckpass must be SUID root because otherwise I can't authenticate using pam_unix2 which I need because of our NIS+ environment. Where is this pam_unix2 from? I recall this is a non-debian package, and thus we really can't support all possible non-debian configurations. I recommend usind dpkg-statoverride to setup kcheckpass as suid root in that case. On my box I do not have unix_chkpwd. Do I really need it? Does it work with pam_unix2? that's in libpam-modules package here. I'm really curious how you can survive without that, as even password depends on it. maybe we need to add yeat another depency. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#226225: failed to preconfigure
severity 226225 serious tags 226225 +pending retitle 226225 Broken postinst: does not handle debconf return code for skipped questions merge 226225 224548 thanks On Mon, Jan 05, 2004 at 09:30:34AM +0100, Bas Zoetekouw wrote: While upgrading my sid system this morning (kdm 3.1.3-1 -- 3.1.4-1), it failed to preconfigure: Please look next time more closely to atleast the RC bugs of the package you are about to file a bugreport.. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#103008: konqueror: Konqueror java applet embedding vs. window managers
tags 103008 +wontfix thanks On Tue, Dec 30, 2003 at 04:10:43AM +0100, Danilo Piazzalunga wrote: Still occurs, depending on which window manager is in use. I forgot to CC: last time to the submitter, sorry about that. This isn't a bug in konqueror, but rather a feature (XEMBED) [1] missing in twm (and many other wm:s too). [1] http://freedesktop.org/Standards/xembed-spec/xembed-spec-0.5.html (looks like for some odd reason I last claimed that the lacking feature was netwm, which is ofcourse my mistake) These ones still have the problem: - twm 4.3.0-0pre1v4 does not support Xembed - wmaker 0.80.1-8 Odd. I'm pretty sure windowmaker supports xembed. Maybe it was just in the dock then. - xfwm4 4.0.2-2 (sometimes it is all right, sometimes just opens a silhouette window but the applet appears where it should be). That's a bug in xfwm4 - file a bug there if it bothers. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Re: Three more bugs:
On Thu, Dec 18, 2003 at 02:00:42AM +0100, Dominique Devriese wrote: Here are three more bugs that you can close in the new upload, that I forgot in my last mail: -snip- Thanks for your work domi I noticed while attempting to clean up kde BTS reports, that you have been very active caring about the bugs. I think you would be great help for the project if you would join the Debian QT/Kde maintainers team on alioth[1]. notice that you don't need to be a debian developer to get an alioth account and thus join projects. I'm not sure whats the post-breakin status of alioth, but I guess that after we get this kdebase stuff cleared, we can have a kick-off of the group maintainership. [1] http://alioth.debian.org/projects/pkg-kde/ -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver | pgpevVU22PkyS.pgp Description: PGP signature
Re: Debian KDE maintenance
On Thu, Dec 18, 2003 at 03:13:57PM +0100, Dominique Devriese wrote: 1. Exactly what is the role of the alioth pkg-kde project ? AFAICT from the website, there is no activity there, even the CVS repository is empty. The role is what we define it to be :) It is still in the planning phase. There is no cvs repository, because the current plan is to use subversion [1] not much to see there either. 2. Where does active development occur on the packages ? KDE CVS or the repository on alioth ? If on KDE CVS, then in what branch do you work ? 3_1 or HEAD ? When will you move to the new 3_2 branch ? There will be several diffrent branches. The model Branden uses for xfree86 maintainance[2] is probably close to what will be in kde svn. Now if I remember correctly, that means that trunk is whatever is going to next to sid, and under branches we debian dirs for other upstream versions (cvs, 3_2 and if we would have started this earlier 2_2). And under there, dirs for debian releases (sid/woody and soon sarge). And under people we have our own sandboxes where we can try any nontrivial changes. Now that's the plan, search the archives for more discussion. If anyone comes out with better ideas, now is the good time tell about them :) 3. How do you handle the upstream releases ? Do you take an official tarball as prepared by the KDE release dude, or do you pull your own copy from CVS at a time that suits you ? What happens if you then need to make some modifications to the debian-specific stuff and release a new package, but still based on the same upstream release ? Afaik we take the relases from cvs and clean them abit (remove CVS dirs etc). debian-specific changes are shipped as paches under debian/patches. 4. Is there an irc channel where you discuss the debian kde package development ? #debian-kde on freenode. There is typically more non-development discussion there thou. 5. Is there some kind of procedure on committing changes to the debian/ stuff ? I suppose trivial patches can be applied without a problem ? Where does discussion occur on more intrusive patches ? The policy suggestion[3] seems disappeared from people.debian.org - probably cleaned just to be sure. If I remember correctly, nontrivial patches should be done under your own people/domi branch, where the main package maintainer can verify them and merge it to trunk. 6. What is the status of the group maintainership ? Waiting that the more critical stuff (kdebase) gets done, basicly. I think everyone pretty much agreed with the proposed policy. And svn is pretty new to most of us, so there will probably be some experimenting with it first. And finally as reply to your other mail, you need get an alioth account and ask one the project admins to add you. [1] http://svn.debian.org/ [2] http://deadbeast.net/~branden/svn_pres/top.html [3] http://people.debian.org/~madkiss/debian-kde-policy.html -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver | pgpWYEnzA8kKi.pgp Description: PGP signature
Re: bug followup messages
On Wed, Nov 05, 2003 at 12:01:22AM -0600, Chris Cheney wrote: Anyone who is going through the bug lists and sends messages intended to reach the submitter must use [EMAIL PROTECTED] not just [EMAIL PROTECTED] This emails both the bug itself and the submitter, otherwise the email only goes to the bug log itself. Oh, crap, my bad. I remembered that simply replying to bug reports allways sent the message to the submitter.. Now I realize it is because BTS adds submitters address to Reply-To:, not because of @bugs.debian.org forwarding to submitter. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver | pgp9qJqLnUFDp.pgp Description: PGP signature
Re: Policy for Debian Qt/KDE Maintainers Group
On Sun, Oct 19, 2003 at 04:20:42PM +0200, Martin Loschwitz wrote: I prepared a policy for the Debian Qt/KDE Maintainers Group, the document can be found at http://people.debian.org/~madkiss/debian-kde-policy.html Hi, Just a few clarififications: 1. About alioth: Will we have the entire kde packages in alioth svn or just the debian/ dirs? I know we can't at the moment use pristine upstream tarballs, but having the entire source tree in our version managment feels like a HUGE waste of space, as we are supposed only to edit files under debian/ dirs.. 2. About commits to module, I think we should rewrite it as: - (5) Commits to a module may only be done if + (5) Commits to the TRUNK of a module may only be done if Creating a branch where to commit fixes and then letting primary maintainer to merge them to TRUNK if he finds them appropriate seems more intuitive than asking for permission for every commit. I'm refering TRUNK being here whatever we choose in svn to be the branch which next unstable upload will emarge from. Also, I think we should not be that strict for all commits. Strictly nonfunctional commits, like typofixes, better descriptions and documentation (Maybe even adding manpages) should be fix at will. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver | pgpopD8MwVu9M.pgp Description: PGP signature
Re: kdebindings-3.1.3 heading for sid
On Wed, Sep 03, 2003 at 11:00:13PM +0200, Ralf Nolden wrote: On Mittwoch, 3. September 2003 22:45, Riku Voipio wrote: yes. gcj compiles them fine after you wield a bit of vi against acinclude.m4.in. kdebindings doesn't need libjvm.so or libhpi.so, so checking for those two files is kinda ridiculous way to verify a working jvm... Can you make useful diffs and send them to [EMAIL PROTECTED] and [EMAIL PROTECTED] with a description so things work out of the box when they are in kde ? Well yes, I already implemented it as a patch in debian/patches now that I reviewed it, looks like removing the checks isn't a generic solution. you still need to link against libhpi.so if you happen to use sun/blackdown/ibm jdk to compile. I need to refine the patch to work in both cases. And as a more worrying problem, I'm still tracking to make it compile nicely with qt 3.2 without pulling unecessary amounts of code from HEAD... -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
kdebindings-3.1.3 heading for sid
Hi, I have a pretty much functioning kdebindings 3.1.3 ready for sid upload, see the attached changelog for details. there a few questions still remaining: 1) maintainer is currently [EMAIL PROTECTED] I assume I should either NMU it or adopt it? If I adopt it, should I use my name for maintainer or [EMAIL PROTECTED] Since for long time kdebindings has lacked loving, I assume that no-one else is intrested in maintaining kdebindings, the current control has me as maintainer. 2) qt 3.2 Lots of stuff has to be regenerated from qt 3.2 headers to work, And I'm not 100% sure I generated everything right. Any knowledge what's the upstream plan on this? All qt-3.2 changes I see are in HEAD, not 3_1 branches.. Also, while the example apps seem to work[1] It's probably more safe to build against kdelibs that are built against qt 3.2 as well? [1] with the exception of kmozilla, which doesn't compile - maybe some updates are needed to make it compile with mozilla 1.4? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver | Format: 1.7 Date: Sat, 30 Aug 2003 19:38:33 +0300 Source: kdebindings Binary: libsmokeqt-dev libdcopc-dev libkjsembed1 kdejava kalyptus libkdexparts-dev libkdec1 libkdexparts1 libkjsembed-dev dcopperl libdcopc1 xpart-notepad qtjava dcoppython kdebindings-c libsmokeqt1 dcopjava libqtc1 kdebindings-java Architecture: source i386 all Version: 4:3.1.3-1 Distribution: unstable Urgency: low Maintainer: Riku Voipio [EMAIL PROTECTED] Changed-By: Riku Voipio [EMAIL PROTECTED] Description: dcopjava - DCOP bindings for JAVA dcopperl - DCOP bindings for Perl dcoppython - DCOP bindings for Python kalyptus - C++ library bindings creating scripts kdebindings-c - KDE C bindings metapackage kdebindings-java - KDE Java bindings metapackage kdejava- Java bindings for kde libdcopc-dev - DCOP bindings for C (Development files) libdcopc1 - DCOP bindings for C libkdec1 - KDE bindings for C libkdexparts-dev - allows you to embed non-KDE apps as a KPart (development files) libkdexparts1 - allows you to embed non-KDE apps as a KPart libkjsembed-dev - embedded javascript library (Development files) libkjsembed1 - embedded javascript library libqtc1- Qt bindings for C libsmokeqt-dev - Scripting Meta Object Kompiler Engine - binding library to Qt dev libsmokeqt1 - Scripting Meta Object Kompiler Engine - binding library to Qt qtjava - Java bindings for qt xpart-notepad - xpart-notepad is a KDE xpart example for X applications turned in Closes: 104540 111756 128608 128609 192490 Changes: kdebindings (4:3.1.3-1) unstable; urgency=low . * New Maintainer * New upstream version for kde3, closes: #192490 * Java support added, closes: #111756 * A (bit) more nicer descriptions: closes: #104540, #128608, #128609 * updated build-depends to match sid * new patch auto-foo-update.diff make automake search for libgcj.so instead of libjvm.so and libhpi.so * new patch dcopperlfixes.diff reorder dcopperl headers * new patch dcoppythonfixes.diff workaround more strict gcc * new patch gcj-barf-killer.diff gcj complains of illegal chars in comments - which apparently isn't true, but we wouldn't want to rely on a propierty javac. * new patch gcc-3.3-barfs-on-KAutoMount.diff removes KAutoMount from compiled files temporarily * Thank for Ralf Nolden and Karolina Lindqvist for their previous unnoficial work! * Co-Maintainers welcome, especially if you use the kdejava-stuff Files: 08f4a42f6c7a7d1982637acee1ad57dd 778 devel optional kdebindings_3.1.3-1.dsc 718184780d315d78f7844e451ca90f3c 9985772 devel optional kdebindings_3.1.3.orig.tar.gz 73e6e80477a895df3ed8526b72e19add 17334 devel optional kdebindings_3.1.3-1.diff.gz 313119a9848c64193c9c90c4d787fea7 3900 libs optional kdebindings-c_3.1.3-1_all.deb e948275781aadd6705d93df44cf0f2da 3808 libs optional kdebindings-java_3.1.3-1_all.deb 84e3f55a6984ff0768220d8ae02276b7 19664 libs optional libdcopc1_3.1.3-1_i386.deb ab23dabda1542906dbb522a0145e0ac0 6056 devel optional libdcopc-dev_3.1.3-1_i386.deb b98f12389393e7531b19af1353b29e90 490358 libs optional libqtc1_3.1.3-1_i386.deb 639757cf0695cfb18d755f7dde0f1dfd 668102 libs optional libkdec1_3.1.3-1_i386.deb f9932604167c02f769e7ec9ddfe2a601 27312 devel optional dcopjava_3.1.3-1_i386.deb 59e3d2905fc36d15a8320f0194faaeb6 945884 devel optional qtjava_3.1.3-1_i386.deb 0517aa19a865f22e07d7bd7ebcc02795 1299258 devel optional kdejava_3.1.3-1_i386.deb b2b3a0aa3d0aca0515c3120fc1800a87 1152522 libs optional libsmokeqt1_3.1.3-1_i386.deb c5ec3db20bacb7d913ea8aad4f49f869 7388 devel optional libsmokeqt-dev_3.1.3-1_i386.deb fd6cb3abef0d76c3cfc74c170889fa52 40598 libs optional dcopperl_3.1.3-1_i386.deb bf40251ce787134d64cbd75dd9668d08
Re: kdebindings-3.1.3 heading for sid
On Wed, Sep 03, 2003 at 12:47:26PM -0500, Chris Cheney wrote: On Wed, Sep 03, 2003 at 06:49:44PM +0300, Riku Voipio wrote: I have a pretty much functioning kdebindings 3.1.3 ready for sid upload, see the attached changelog for details. Did you manage to get the java parts to compile using gcj? yes. gcj compiles them fine after you wield a bit of vi against acinclude.m4.in. kdebindings doesn't need libjvm.so or libhpi.so, so checking for those two files is kinda ridiculous way to verify a working jvm... -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
