Bug#332473: we are documenting the behavior of dimap in kmail
tags 332473 + pending thanks Since upstream seems to think that the current behavior of kmail (syncing a folder at a time) is the way it was designed to work, we have decided to document the behavior with a warning that not using dimap as upstream intended can result in lost mail. This will be documented in both kmail/README.Debian, and hpoefully in a dialog that is shown upon creating a dimap account. The release team has told us that such documentation would make this a non-release critical issue. Since the warning warns against using kmail in the way it is used in these bugs to cause mail loss, the kdepim upload will close these bugs in its changelog. That also will make tracking the RC bug in etch easier than just downgrading the bugs. If someone wants to open another bug of non-RC severity against kmail for not doing atomic updates of mail moves, they are welcome to do so. Debian is unlikely to do anything about it unless upstream does, however. Thanks for everyone's help in tracking down the issues involved with dimap and kmail. Josh Metzler (for the Debian Qt/KDE Team) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403004: kmail: Kmail does not start after sarge->etch upgrade
On Thursday 14 December 2006 12:49, Ana Guerrero wrote: > Hi, > > On Thu, Dec 14, 2006 at 09:22:36AM +0600, Alexander Litvinov wrote: > > Package: kmail > > Version: 4:3.5.5.dfsg.1-2 > > Severity: grave > > Justification: renders package unusable > > > > I have updgraded from sarge to etch at 14 dec 2006. After this upgrade > > my kmail does not start. Just after starting it shows KDE's crash > > window with the text (not exact, translated from russian): > > Application kmail has broken with signal 11 (SIGSEGV). Stack trace will > > be included later. > > [...] > > I just reproduced this bug. > > But i agree with Josh Metzler about the severity: > > I'm not sure it is grave, though, as I think it only applies to > people using IMAP with a courier-imap server that isn't "most > people" > > Alexander: > If you rename your file $HOME/.kde/share/config/kmailrc as kmailrc.old, > you will be able to start kmail again, but all your account info will be > lost. Basically, you will have to configure all your accounts in kmail > again :( > > Ana First, I've been assuming that you are accessing a courier-imap server for at least one account. Is that true? (Are all your folders under the inbox, or did you have to set INBOX. as the prefix to folders in sarge's kmail?). If not, then this is a different problem. If you are accessing a courier-imap server, rather than reconfiguring all your accounts, I believe that renaming or deleting $HOME/.kde/share/apps/kmail/imap/* should allow kmail to start up. Deleting this is fine, as it is just kmail's cache of all the e-mail headers. Since kmail in KDE 3.5 handles namespace/prefix differently, if will have to redownload all the headers anyway. That was enough to let me start kmail when I upgraded to KDE 3.5. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#364395: user's modifications to init script has a bug?
Looking at the initscript Patrick included in his message, and the one shipped with the package, it looks he added this line: PARAMS="-m /var/spool/postfix/var/run/saslauthd" However, according to man start-stop-daemon, -m does not take an argument. So, my guess is that start-stop-daemon is failing do to this addition. That doesn't necessarily explain why it is failing for others, though. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335577: does this bug exist in sid?
There has been a new g++ transition and a few new upstream versions of k3b in sid since this bug was last tested. Also, I am unsure of exactly what it affects. Are these correct: The amd64 sid version of k3b works fine on a k3b system. The stable version of i386 k3b crashes in a 32-bit chroot on an amd64 system. Does the current sid version of i386 k3b work in a 32 bit chroot on an amd64 system? If not, is it really an RC bug, given that the native amd64 version works? I would like to be able to mark this bug closed in the sid version, or downgrade it to non-rc, as it (and a missing hppa build) are what is keeping k3b from reentering testing. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337296: kitchensync crashes during the first run
On Thursday 03 November 2005 01:24 pm, Hervé Leroux wrote: > Subject: kitchensync crashes during the first run > Package: kitchensync > Version: 4:3.4.2-2 > Severity: grave > Justification: renders package unusable > > When I run kitchensync for the first time (or after > deleting .kde/share/apps/kitchensync .kde/share/config/kitchensyncrc), > the program returns a segfault. Does this still happen in the 3.4.3 version? Also, does it only crash the first time you run it? If so (running it second and future times works), I'm going to downgrade this bug to important. Thanks, Josh
Bug#339802: libmimelib1c2: Fails to install packege with apt
On Friday 18 November 2005 04:33 pm, Alexandre Touret wrote: > Unpacking libmimelib1c2 (from .../libmimelib1c2_4%3a3.4.2-2_i386.deb) ... > dpkg: error processing > /var/cache/apt/archives/libmimelib1c2_4%3a3.4.2-2_i386.deb (--unpack): > trying to overwrite `/usr/lib/libmimelib.so.1.0.1', which is also in > package libmimelib1 Errors were encountered while processing: What version of Debian are you trying to upgrade from? The only libmimelib1 I can find at http://packages.debian.org/ is in oldstable. Stable has libmimelib1a, which libmimelib1c2 properly Replaces and Conflicts with, so it can overwrite that file in the corresponding package. You could try removing libmimelib1 first (dpkg --remove libmimelib1), and then libmimelib1c2 should be able to install. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337690: ksayit: KSayit crashes on startup
On Saturday 05 November 2005 02:50 pm, Ronny Standtke wrote: > Package: ksayit > Version: 4:3.4.2-2 > Severity: grave > Justification: renders package unusable > > > KSayit crashes on startup. Here is the backtrace: ... > #3 0xb799bb6e in __gnu_cxx::__pool::_M_reclaim_block () >from /usr/lib/libstdc++.so.6 > #4 0xb7c2b632 in __gnu_cxx::__mt_alloc__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >>::deallocate () from /usr/lib/libartskde.so.1 ... This is a result of a toolchain bug #336114, and unfortunately there is not much that the debian-qt-kde maintainers until they are told how it will be solved. If you really need ksayit working, recompiling kdelibs with the current g++ should work around this problem. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337478: koffice: FTBFS: invalid use of undefined type `struct KisfilterRegistry'
On Friday 04 November 2005 09:10 pm, Josh Metzler wrote: > It looks to me like the problem might be that kis_filter.h and > kis_filter_registry.h include each other. As far as I can tell, > kis_filter_registry.h doesn't have any reason to include kis_filter.h, so > I would try removing that include to see if it fixes things. I ought to just look in kde cvs first - this is exactly what was committed 11 days ago with the log "don't confuse gcc 4.0.3/4.1": http://websvn.kde.org/branches/koffice/1.4/koffice/krita/core/kis_filter_registry.h?rev=473737&r1=418647&r2=473737 Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337478: koffice: FTBFS: invalid use of undefined type `struct KisfilterRegistry'
On Friday 04 November 2005 09:36 am, Daniel Schepler wrote: > Package: koffice > Version: 1:1.4.2-2 > Severity: serious > > >From my pbuilder build log: > > ... > if /bin/sh ../../libtool --silent --mode=compile --tag=CXX g++ > -DHAVE_CONFIG_H -I. -I../../../krita/ui -I../.. > -I../../../krita/ui/../core/filters -I../../../krita/ui/../core > -I../../../krita/ui/../core/resources/ > -I../../../krita/ui/../core/color_strategy > -I../../../krita/ui/../core/tiles -I../../../krita/ui/../core/tool > -I../../../krita/ui/../core/paintop -I../../../lib/kofficeui > -I../../lib/kofficeui -I../../../lib/kofficecore -I../../lib/kofficecore > -I../../../lib/store -I../../lib/store -I../../../lib/kwmf > -I../../lib/kwmf -I../../../lib/kopainter -I../../lib/kopainter > -I/usr/include/kde -I/usr/share/qt3/include -I. -DQT_THREAD_SUPPORT > -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 > -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W > -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -Wformat-security > -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions > -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST > -DQT_NO_STL -DQT_N O_COMPAT -DQT_NO_TRANSLATION -DHAVE_KNEWSTUFF -MT > kis_filter_box.lo -MD -MP -MF ".deps/kis_filter_box.Tpo" \ -c -o > kis_filter_box.lo `test -f '../../../krita/ui/kis_filter_box.cc' || echo > '../../../krita/ui/'`../../../krita/ui/kis_filter_box.cc; \ then mv -f > ".deps/kis_filter_box.Tpo" ".deps/kis_filter_box.Plo"; \ else rm -f > ".deps/kis_filter_box.Tpo"; exit 1; \ > fi > ../../../krita/ui/../core/kis_filter.h: In function 'KisFilterSP > createFilter(KisView*)': ../../../krita/ui/../core/kis_filter.h:47: > error: invalid use of undefined type 'struct KisFilterRegistry' > ../../../krita/ui/../core/kis_canvas_subject.h:38: error: forward > declaration of 'struct KisFilterRegistry' > ../../../krita/ui/../core/kis_filter.h:49: error: invalid use of > undefined type 'struct KisFilterRegistry' > ../../../krita/ui/../core/kis_canvas_subject.h:38: error: forward > declaration of 'struct KisFilterRegistry' > ../../../krita/ui/../core/kis_filter.h:53: error: invalid use of > undefined type 'struct KisFilterRegistry' > ../../../krita/ui/../core/kis_canvas_subject.h:38: error: forward > declaration of 'struct KisFilterRegistry' > ../../../krita/ui/kis_filter_box.cc: At global scope: > ../../../krita/ui/kis_filter_box.cc:60: warning: unused parameter 'item' > make[5]: *** [kis_filter_box.lo] Error 1 > make[5]: Leaving directory > `/tmp/buildd/koffice-1.4.2/obj-i486-linux-gnu/krita/ui' make[4]: *** > [all-recursive] Error 1 > make[4]: Leaving directory > `/tmp/buildd/koffice-1.4.2/obj-i486-linux-gnu/krita/ui' make[3]: *** > [all-recursive] Error 1 > make[3]: Leaving directory > `/tmp/buildd/koffice-1.4.2/obj-i486-linux-gnu/krita' make[2]: *** > [all-recursive] Error 1 > make[2]: Leaving directory `/tmp/buildd/koffice-1.4.2/obj-i486-linux-gnu' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/tmp/buildd/koffice-1.4.2/obj-i486-linux-gnu' > make: *** [build-stamp] Error 2 It looks to me like the problem might be that kis_filter.h and kis_filter_registry.h include each other. As far as I can tell, kis_filter_registry.h doesn't have any reason to include kis_filter.h, so I would try removing that include to see if it fixes things. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337423: kdelibs4-dev: Ambigous overload for 'operator+' error in kresources/manager.h
On Friday 04 November 2005 06:26 am, Xavier FACQ wrote: > Package: kdelibs4-dev > Version: 4:3.4.2-4 > Severity: serious > Justification: no longer builds from source > > When i try to build kopete from svn or using sources from apt-get > source, it always failed with this error : > > /usr/include/kde/kresources/manager.h: In member function 'QStringList > KRES::Manager::resourceTypeDescriptions() const': > /usr/include/kde/kresources/manager.h:338: error: ambiguous overload for > 'operator+' in '" (" + ((const > KRES::Manager*)this)->KRES::Manager::mFactory->.KRES::Factory::typeDe >scription((* it))' > /usr/share/qt3/include/qstring.h:1072: note: candidates are: const > QString operator+(QChar, const QString&) > /usr/share/qt3/include/qstring.h:1080: note: const > QString operator+(char, const QString&) > make[2]: *** [addresseeitem.lo] Erreur 1 > make[2]: Leaving directory > `/home/xfacq/tmp/Dev/svndir/kdenetwork/kopete/libkopete/ui' > make[1]: *** [all-recursive] Erreur 1 > make[1]: Leaving directory > `/home/xfacq/tmp/Dev/svndir/kdenetwork/kopete/libkopete' > make: *** [all-recursive] Erreur 1 Could you somehow have QT_NO_CAST_ASCII defined while building? Looking in qstring.h, it should be using this operator+ on line 1050: inline const QString operator+( const char *s1, const QString &s2 ) Your build doesn't appear to be finding that, though. Since the definition is wrapped in a #ifndef QT_NO_CAST_ASCII, it seems like having that defined while building could cause your build failure. ... A quick grep -r through the kdenetwork sources shows that this appears to be defined in all the kopete Makefile.am's and Makefile.in's, but not in any other kdenetwork packages. So, I wonder how the buildd's built it? Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334239: koffice_1:1.3.5-5(m68k/unstable):
On Sunday 16 October 2005 10:23 am, [EMAIL PROTECTED] wrote: > Package: koffice > Version: 1:1.3.5-5 > Severity: serious > > There was an error while trying to autobuild your package: > > Automatic build of koffice_1:1.3.5-5 on ska by sbuild/m68k 69 > > Build started at 20051014-1604 > > [...] > > > ** Using build dependencies supplied by package: > > Build-Depends: g++-3.4 [arm hppa m68k], automake1.7, debhelper (>= > > 4.0.0), flex, kdelibs4-dev (>= 4:3.2.0), libaspell-dev, > > libfontconfig1-dev, libmagick++9-dev, libpaper-dev, libtiff4-dev, > > libwv2-dev (>= 0.1.9-0), libxml2-dev, libxslt1-dev, postgresql-dev, > > python2.3-dev, sharutils > > [...] > > > The following central src deps are (probably) missing: > > libtiff3g-dev I don't think this is needed - koffice build-depends on libtiff4-dev. > > ../../../karbon/core/vcolor.cc:294: internal compiler error: in > > verify_initial_elim_offsets, at reload1.c:3297 Please submit a full bug > > report, > > with preprocessed source if appropriate. > > See http://gcc.gnu.org/bugs.html> for instructions. > > For Debian GNU/Linux specific bug reporting instructions, > > see . > > make[4]: *** [vcolor.lo] Error 1 > > make[4]: Leaving directory > > `/build/buildd/koffice-1.3.5/obj-m68k-linux-gnu/karbon/core' make[3]: > > *** [all-recursive] Error 1 > > make[3]: Leaving directory > > `/build/buildd/koffice-1.3.5/obj-m68k-linux-gnu/karbon' make[2]: *** > > [all-recursive] Error 1 > > make[2]: Leaving directory > > `/build/buildd/koffice-1.3.5/obj-m68k-linux-gnu' make[1]: *** [all] > > Error 2 > > make[1]: Leaving directory > > `/build/buildd/koffice-1.3.5/obj-m68k-linux-gnu' make: *** > > [build-stamp] Error 2 > > A full build log can be found at: > http://buildd.debian.org/build.php?arch=m68k&pkg=koffice&ver=1:1.3.5-5 > > I tried to build the offending file with gcc-4.0, and that succeeded; > if koffice is built with g++-3.4 because it failed previously, you may > want to try reverting that change on your next upload. I believe this file builds with g++-4.0. Unfortunately, koffice ICEd on arm when built with g++-4.0 with the following error: ./koDocument.moc: In member function 'QDomDocument KoDocument::_ZTv0_n28_NK10KoDocument11domDocumentEv() const': ./koDocument.moc:217: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 This ICE has turned up in numerous kde packages. g++-4.0 always ICEs while compiling this file on arm, hppa, and m68k, so as soon as this ICE was seen on arm, a new version using g++-3.4 for arm, hppa, and m68k was uploaded. This ICE is fixed in gcc 4.1, but as far as I know has not been backported to 4.0. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323133 for more details. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327959: builds with gcc-4.0
This is just a quick note to let you know that I rebuilt knutclient locally in a clean sid pbuilder chroot, and it built fine. I have not yet upgraded my desktop computer to kde 3.4.2, so I haven't yet tested the new package. If knutclient hasn't been uploaded for the transition yet when I do upgrade, I'll send another e-mail with my testing results. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327231: filelight 0.6.4.1 ftbfs with gcc 4.0
This is a followup to bug #327231, but maybe should be a separate bug report. I tried rebuilding filelight against the latest kdelibs using gcc-4.0, and it fails with this error: scanmanager.h:56: error: 'void ScanManager::startPrivate(const QString&)' is private scanmanager.h:81: error: within this context I believe the problem has something to do with gcc-4.0 requiring anything declared as a friend to be visible where it is being declared. Since this is a private function in another class, it isn't visible in the context it is being used. I don't know how to fix it without making it a public function, but I'm sure there is some way. There is also a new upstream prerelease - 1.0-beta6, but it is fairly different, as it builds a kpart instead of just an application. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325592: kdebase-data: upgrading to 4:3.4.2-1 with kdebase 4:3.3.2-1 breaks kcontrol
Package: kdebase-data Version: 4:3.4.2-1 Severity: serious A user reported in #debian-kde that his kcontrol was empty of modules. I lead him through downgrading kdebase-data to 4:3.3.2-1 and that fixed it. I then reproduced by upgrading kdebase-data to 4:3.4.2-1 on a stock sid system (all of kde still at 3.3.2). kcontrol is now empty of modules. It seems that kdebase-data needs the same version dependency on kdebase that kdelibs-data needed on kdelibs4. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325092: kmail: Kmail segfault with libqt3c102-mt but works fine with libqt3-mt, but this situation isn't a livable one.
reassign 325092 kdelibs4 merge 320581 325092 thanks On Thursday 25 August 2005 11:06 pm, David Hill wrote: > Package: kmail > Version: 4:3.3.2-3 > Severity: grave > Justification: renders package unusable > > > GDB= > Received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1244882720 (LWP 29713)] > 0xb758e95b in QString::QString () from /usr/lib/libqt-mt.so.3 > > quite simple from this point of vue! Right, this is actually a bug in the kdelibs version you have. Your two options for now are: 1) downgrade kdelibs[4, -data, -bin] to the version in testing. 2) use kontact (which embeds kmail and doesn't suffer from this bug for some reason). > dpkg --force-depends -i libqt3-mt_3%3a3.3.4-7_i386.deb fixes the problem > but creates conflicts with all the other kde packages that uses > libqt3c102-mt I'm surprised this works at all, as you are installing a supposedly ABI incompatible qt that is compiled with gcc 4.0 while everything that uses it is still compiled with gcc 3.3 (which had a different c++ ABI). Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324894: no more installable on sid
On Wednesday 24 August 2005 01:50 pm, Francesco Paolo Lovergine wrote: > Package: kdebase-dev > Version: 4:3.3.2-1 > Severity: grave > > Dunno if you are waiting for c++ transition completion, anyway current > sid version is not installable. Any reason to not move the experimental > one in the sid pool? That's just for notice. This is due to the c++ transition, as you suspected. The current experimental version is also not compiled with the new gcc, so that wouldn't help. You can either rebuild the packages yourself with the new gcc, or you can wait a few weeks until kde has made it through the transition. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324830: juk: package is not installable
On Wednesday 24 August 2005 06:10 am, Klaus Huber wrote: > # apt-get install juk ... > The following packages have unmet dependencies: > juk: Depends: libtunepimp-bin but it is not going to be installed > E: Broken packages This is expected. It is due to the gcc 4.0 transition currently taking place in unstable. If you want to install juk in unstable, you will need to get libtunepimp-bin and any other packages it complains about from testing. This may not be possible because some other package you have may depend on the transitioned libtunepimp-bin. If that is the case, your only option to use juk would be to switch back to testing for the time being. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324147: kde: After upgrade, KDE menus dissapear
reassign 324147 kdelibs-data severity 324147 serious merge 323747 324147 thanks On Saturday 20 August 2005 10:38 am, Xabier Villar wrote: > Package: kde > Severity: important > > After an upgrade, KDE menus dissapear, and are not regenerated even if I > rename .kde. Menu items in kcontrol and kinfocenter also dissapear, and I > must indicate what program use when I click any icon on my desktop or > file manager writting it (no menu show). Konqueror seems to work well. You have just been bitten by serious bug #323747. You have upgraded kdelibs-data to 4:3.4.2-1. Downgrade it to the precious version, restart kde, and everything should be fine. Josh p.s. downgrade kdelibs* to 4:3.3.2-6.1 to get rid of your KMail segfaulting problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320515: bug confusion?
As far as I understand, #318979 caused xorg-x11 to FTBFS on sparc because it included which used __user but failed to include where __user was defined. This was apparently fixed in linux-kernel-headers_2.6.13+0rc3-1. So, #318979 is no longer a problem. What Adeodato is saying is that xorg-x11 will again FTBFS if it is uploaded before *this* bug (#320515) is fixed. And, because xorg-x11 has never successfully built on sparc, a number of packages that are waiting on it to build (kde having the biggest dependency chain) cannot yet be uploaded for the gcc 4.0 transition. So, you can forget about bug #318979. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304147: kiconedit: crashes with SIGSEGV on start-up
On Monday 11 April 2005 07:08 am, Riku Voipio wrote: > On Mon, Apr 11, 2005 at 09:48:26AM +0100, Neil Williams wrote: > > Loading kiconedit from the menu causes a SIGSEGV as soon > > as the window tries to display. The window then closes > > and the KDE crash handler appears. > > unreproducible on sarge. same version of package in sid too. > Try moving ./.kde/share/config/kiconeditrc somewhere else, or > try using kiconedit with a fresh new user account. Unreproducible on sid, with the same versions (including of kdelibs4 and various xlibs packages). > > Versions of packages kiconedit depends on: > > ii kdelibs4 4:3.3.2-4.0.2 KDE core libraries > > Where is that version from? debian does not have such version of kdelibs Sid does, as the result of two binary NMU's on i386. > > > ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange > > library ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System > > Session Management ii libx11-6 4.3.0.dfsg.1-12.0.1 X Window > > System protocol client li ii libxext6 4.3.0.dfsg.1-12.0.1 X > > Window System miscellaneous exte ii xlibs4.3.0.dfsg.1-12 > > X Keyboard Extension (XKB) configu > > Ditto for your X version. Again, sid does, as the result of a binray NMU. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295131: NEW-queue handling after extending group of ftp-master
On Wednesday 23 March 2005 05:33 pm, Bartosz Fenski aka fEnIo wrote: > On Wed, Mar 23, 2005 at 11:09:17PM +0100, Joerg Jaspert wrote: > > > Usually NEW-queue was handled by the date of first upload of some > > > package. After tracking of debian-bugs and/or debian-wnpp mailing > > > lists last days I can say it's not true anymore. > > > > > > So could someone explain what are the criterions now? > > > > There are criterions for the order? > > Well, ok. Lets define some: > > - How much money did you sent to one ftpmaster/assistant? > > - How much do you intent to send? > > - Are you a girl? > > - Alcohol level? > > - Random picking. > > I could apply for fourth alternatively. > Or maybe fifth but with the 1/4 probability :P > > > Actually there are none, as the queue should be (soon) small enough to > > not need any. So we havent bothered too look for rules, just started. > > The reason for the "random" order is just me, approving old and new > > uploads - to get the queue smaller and not let newer uploads rot in the > > queue as long as some old stuff. > > Ok. That's something what I wanted to hear. Great to see that NEW queue > is handled at all and that I had to wait for answer so short ;) > > > Looking at the queue noone needs to worry about that, so please do > > something more useful like RC bug fixing. :) > > Believe me I'm trying to investigate and fix #295131. Btw any ideas/help > are welcome. Second RC bug for scorched3d is fixed both in upstream and > on my box, but without fixing first one there's no need to upload. > > Once again hints for #295131 are welcome, since afaik it works on sarge, > and not on sid so we've got probably some interesting bug in libglib or > something relevant. > > regards > fEnIo I have know idea if this would work, but what about using libwxgtk2.5.3 rather than libwxgtk2.4? I don't know how much porting effort if any would be involved in that, but libwxgtk2.5.3 seems to be built against libglib2.0 like scorched3d and libSDL, whereas (as the bug report says) libwxgtk2.4 is linked against libglib1.2. Josh -- 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 Wednesday 26 January 2005 05:56 pm, Bill Allombert wrote: > Package: kdm > Version: 4:3.3.1-4 > Severity: serious > Justification: Policy 10.7.3 > > > Hello KDE maintainers, > > kcontrol overwrite the conffile /etc/kde3/kdm/kdmrc without > respecting comment and formating. For example if you start with the > file provided in the current kdm package, launch kcontrol, > choose Login manager->Administrator Mode,make a change, cancel it > and it apply, you get a complelty different file /etc/kde3/kdm/kdmrc, > see patch below. > > This means dpkg conffiles handling is useless here since you cannot > merge the changes. > > Cheers, > Bill While I agree that it is a pain that the kdm kcontrol module reorganizes kdmrc and strips all comments, I am fairly certain it is not a policy violation. For it to be a policy violation, the maintainer scripts (i.e. the scripts run when the package is installed) would need to do this to it. Applications that the user runs can do whatever they want to conffiles (otherwise you would need to file serious bugs against all editors, as I can mess up kdmrc worse with those than I can with kdm_config). While the comments are very helpful, the best solution might be to run kdm_config on the default kdmrc and save it with no changes. This way any changes made using kdm_config on the local system would fit in with the kdmrc shipped with kdm and the diff when upgrading kdm would actually be useful. In the meantime, I have stopped using the kdm kcontrol module to edit kdmrc. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]