kmail loses mails

[Debian Bug Importer]

Automatically imported from Debian bug report #321102 http://bugs.debian.org/321102

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #321102 http://bugs.debian.org/321102

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 03 Aug 2005 14:30:05 +0200
From: Bastian Venthur <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: kmail looses mails

Package: kmail
Version: 4:3.3.2-3
Severity: grave
Justification: renders package unusable

Ok here comes some really nasty bug: I'm using two different
dimap-accounts and kmail seems to ramdomly delete some mails or even
a whole folder (this happened at least once).

I cannot (and don't really want ;) reproduce this bug but I think I have
some hints/observations for the case of loosing some mails:

When you move one ore more mails (esp. with attachments) from one folder
to another, kmails shows that the mails have been moved without actually
having them moved: When you now[1] close kmail and start another
instance of kmail on a different machine(!) you can see, that no mail
has been moved. When you now start your old instance of kmail then you
can see how kmail starts to commit the changes.

No problem so far, but what if the user thinks, that his mail has
already been moved (because kmail pretents to) and makes some other
changes on a different machine? I think this is acutualy the reason for
losing sometimes some mails (I've just yesterday lost 3 mails which I
moved from one folder to another).

Ad [1]: You can wait even loger, as far as I've seen, kmail only moves
the mails (at least when you move many or big mails at once) when you
close and restart kmail.

About the second bug, the lost of a whole dimap-folder, I cannot say
very much, it just happend and I think I don't have to mention, that
this (and the other bug of course) just *must not* happen.

Kind regards

Bastian

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10-1-686-smp
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

Versions of packages kmail depends on:
ii kdelibs4 4:3.3.2-7 KDE core libraries
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libgcc1 1:4.0.1-3 GCC support library
ii libice6 6.8.2.dfsg.1-4 Inter-Client Exchange library
ii libkcal2a 4:3.3.2-3 KDE calendaring library
ii libkdenetwork2 4:3.3.2-3 KDE Network library
ii libkdepim1 4:3.3.2-3 KDE PIM library
ii libkleopatra0a 4:3.3.2-3 KDE GnuPG interface libraries
ii libkpimidentities1 4:3.3.2-3 KDE PIM user identity information
ii libksieve0 4:3.3.2-3 KDE mail/news message filtering li
ii libmimelib1a 4:3.3.2-3 KDE mime library
ii libpng12-0 1.2.8rel-1 PNG library - runtime
ii libqt3c102-mt 3:3.3.4-3 Qt GUI Library (Threaded runtime v
ii libsm6 6.8.2.dfsg.1-4 X Window System Session Management
ii libstdc++5 1:3.3.6-7 The GNU Standard C++ Library v3
ii libx11-6 6.8.2.dfsg.1-4 X Window Syste...

[Jarkko Suontausta (jarkko-suontausta)]

This nasty bug has a lengthy follow-up in the kde bug database:

http://bugs.kde.org/show_bug.cgi?id=104956

--
Jarkko Suontausta

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sat, 3 Sep 2005 19:33:25 +0300
From: Jarkko Suontausta <email address hidden>
To: <email address hidden>
Subject: kmail dimap mail loss: reported upstream

This nasty bug has a lengthy follow-up in the kde bug database:

http://bugs.kde.org/show_bug.cgi?id=104956

--
Jarkko Suontausta

[Bastian Venthur (expires-2007)]

submitter 258377 !
submitter 266378 !
submitter 266398 !
submitter 266401 !
submitter 266428 !
submitter 266544 !
submitter 283349 !
submitter 286466 !
submitter 288221 !
submitter 302240 !
submitter 306183 !
submitter 309379 !
submitter 309682 !
submitter 316766 !
submitter 317054 !
submitter 317057 !
submitter 319387 !
submitter 320674 !
submitter 321102 !
submitter 321230 !
submitter 321733 !
submitter 322161 !
submitter 322225 !
submitter 322319 !
submitter 322334 !
submitter 322335 !
submitter 322356 !
submitter 322437 !
submitter 322543 !
submitter 324179 !
submitter 324849 !
submitter 325922 !
submitter 326755 !
submitter 327113 !
submitter 330607 !
submitter 331398 !
submitter 331646 !
submitter 332473 !
submitter 336775 !
submitter 337937 !
submitter 337938 !
submitter 340071 !
submitter 342784 !
submitter 342786 !
submitter 342788 !
submitter 345161 !
submitter 345194 !
submitter 347953 !
submitter 348083 !
quit

Changed address from expires-2006@... to expires-2007@...

[Christopher Martin (chrsmrtn-debian)]

found 350851 4:3.4.2-2
severity 350851 grave
merge 321102 332473 350851
stop

These are all the same basic problem, and it goes back to KDE 3.4 (at
least).

[Filipus Klutiero (chealer)]

tags 321102 + upstream

[Fathi Boudra (fboudra)]

forwarded 321102 http://bugs.kde.org/show_bug.cgi?id=104956
forwarded 332473 http://bugs.kde.org/show_bug.cgi?id=114163
forwarded 350851 http://bugs.kde.org/show_bug.cgi?id=104956

321102, 332473, 350851 are merged and not fixed in upstream ATM.

[Carthik Sharma (carthik)]

Bug #104956 in the KDE BTS. Changing to Confirmed.

[Adam Porter (alphapapa)]

FYI, since upgrading to KDE 3.5.2 (Debian), my KMail IMAP problems and crashes
have gone away. If you have had this problem, please test with 3.5.2. This
may have been fixed as well.

[Bastian Venthur (expires-2007)]

> FYI, since upgrading to KDE 3.5.2 (Debian), my KMail IMAP problems and crashes
> have gone away. If you have had this problem, please test with 3.5.2. This
> may have been fixed as well.

No, please! Don't close the bug "just in case it has been fixed".
Upstream confirmed the bug, marked them as hard to reproduce and
*unlikely to fix* in the next time due issues with KDE's IMAP-IO slave.
I would not close this bug until the upstream bugreports have been
explicitly closed by upstream (Which is not the case right now).

I know it's tempting to close RC bugs in order to let a recent KDE-Pim
enter testing, but I would not like to expose other users unnecessarily
to a possible risk of data.

A better solution would be to increase the pressure on upstream to fix
this bug. I have the feeling, that closing this bug is not really No 1
on their priority list... (according to the time the bug has been open now)

Kind regards,

Bastian

[Riku Voipio (riku-voipio)]

On Thu, Apr 13, 2006 at 07:53:14PM +0200, Bastian Venthur wrote:
> No, please! Don't close the bug "just in case it has been fixed".
> Upstream confirmed the bug, marked them as hard to reproduce and

That's not the point. It's just a "heads-up" for you - Can you or can
you not reproduce the bug with latest version?

> A better solution would be to increase the pressure on upstream to fix
> this bug.

Increasing pressure doesn't really work on volunteers.. They are just
likely to find more interesting tasks to work on. More debugging info,
instructions for easier reproducing etc work better.

Cheers,
Riku

[Bastian Venthur (expires-2007)]

Riku Voipio wrote:
> On Thu, Apr 13, 2006 at 07:53:14PM +0200, Bastian Venthur wrote:
>> No, please! Don't close the bug "just in case it has been fixed".
>> Upstream confirmed the bug, marked them as hard to reproduce and
>
> That's not the point. It's just a "heads-up" for you - Can you or can
> you not reproduce the bug with latest version?

Nope, I can't -- mainly because I don't want to lose anymore mails. I
switched to Thunderbird after an "accident" two months ago. But at least
one of the upstream developers confirmed the bug mentioned a problem
with KDE's IMAP KIO-slave. Since he has not fixed (or closed) the bug
yet, I assume it's still open.

As a programmer, I don't believe in bugs fixing them self "somehow" just
because the version number has increased. If someone had worked on the
bug and found a fix, he surely would have left at least a note on the
bugreport, wouldn't he?

The bug is confirmed, marked as "critical" by upstream and still open
why should we assume it is closed?

>> A better solution would be to increase the pressure on upstream to fix
>> this bug.
>
> Increasing pressure doesn't really work on volunteers.. They are just
> likely to find more interesting tasks to work on. More debugging info,
> instructions for easier reproducing etc work better.

Please note, I don't wanted so sound rude, but someone came up with the
following idea:

Quoted from the upstream bugreport [1]:

"FYI, since upgrading to KDE 3.5.2 (Debian), my KMail IMAP problems and
crashes have gone away. If you have had this problem, please test with
3.5.2. If we don't get any more reports in, say, a couple of weeks, I
think we should consider closing this bug."

and I just wanted to make sure this bug does not get closed too
frivolous. I was using KMail for *months* without problems, until
suddenly the bug hit me again -- so closing the bug if no one confirms
within a couple of weeks sounds pretty irresponsible for me.

Kind regards,

Bastian

1. http://bugs.kde.org/show_bug.cgi?id=104956#c54

[Pierre Habouzit (madcoder)]

# canonize forwards
forwarded 85437 http://bugs.kde.org/20186
forwarded 85443 http://bugs.kde.org/20187
forwarded 100894 http://bugs.kde.org/6184
forwarded 102462 http://bugs.kde.org/35918
forwarded 103201 http://bugs.kde.org/28072
forwarded 116826 http://bugs.kde.org/35908
forwarded 118834 http://bugs.kde.org/35938
forwarded 121818 http://bugs.kde.org/35582
forwarded 123634 http://bugs.kde.org/36120
forwarded 129491 http://bugs.kde.org/54331
forwarded 131545 http://bugs.kde.org/66722
forwarded 131562 http://bugs.kde.org/48485
forwarded 134368 http://bugs.kde.org/40418
forwarded 134611 http://bugs.kde.org/54379
forwarded 135632 http://bugs.kde.org/37210
forwarded 141094 http://bugs.kde.org/54329
forwarded 141095 http://bugs.kde.org/54330
forwarded 143457 http://bugs.kde.org/31055
forwarded 145786 http://bugs.kde.org/62603
forwarded 146047 http://bugs.kde.org/54382
forwarded 147088 http://bugs.kde.org/118123
forwarded 158841 http://bugs.kde.org/66790
forwarded 161317 http://bugs.kde.org/54366
forwarded 172610 http://bugs.kde.org/59069
forwarded 174560 http://bugs.kde.org/67153
forwarded 175383 http://bugs.kde.org/52059
forwarded 180801 http://bugs.kde.org/54845
forwarded 180894 http://bugs.kde.org/71338
forwarded 183281 http://bugs.kde.org/66020
forwarded 185034 http://bugs.kde.org/66050
forwarded 185765 http://bugs.kde.org/54247
forwarded 185957 http://bugs.kde.org/70053
forwarded 186150 http://bugs.kde.org/28321
forwarded 186164 http://bugs.kde.org/33372
forwarded 187339 http://bugs.kde.org/43366
forwarded 187887 http://bugs.kde.org/66049
forwarded 190033 http://bugs.kde.org/66318
forwarded 192045 http://bugs.kde.org/66045
forwarded 192168 http://bugs.kde.org/50997
forwarded 193691 http://bugs.kde.org/58785
forwarded 194419 http://bugs.kde.org/7506
forwarded 194597 http://bugs.kde.org/66437
forwarded 194624 http://bugs.kde.org/67156
forwarded 194861 http://bugs.kde.org/23601
forwarded 198292 http://bugs.kde.org/66434
forwarded 198754 http://bugs.kde.org/66436
forwarded 198881 http://bugs.kde.org/66798
forwarded 199144 http://bugs.kde.org/66985
forwarded 199550 http://bugs.kde.org/18109
forwarded 201966 http://bugs.kde.org/66435
forwarded 201969 http://bugs.kde.org/66988
forwarded 202362 http://bugs.kde.org/62108
forwarded 202432 http://bugs.kde.org/66986
forwarded 202730 http://bugs.kde.org/62110
forwarded 203421 http://bugs.kde.org/62109
forwarded 205004 http://bugs.kde.org/83642
forwarded 205626 http://bugs.kde.org/71735
forwarded 207039 http://bugs.kde.org/72847
forwarded 207456 http://bugs.kde.org/57342
forwarded 207536 http://bugs.kde.org/66492
forwarded 207704 http://bugs.kde.org/79865
forwarded 208317 http://bugs.kde.org/67135
forwarded 208899 http://bugs.kde.org/66044
forwarded 210408 http://bugs.kde.org/66046
forwarded 210944 http://bugs.kde.org/47244
forwarded 211441 http://bugs.kde.org/65508
forwarded 214641 http://bugs.kde.org/62603
forwarded 215013 http://bugs.kde.org/79866
forwarded 215283 http://bugs.kde.org/66046
forwarded 215678 http://bugs.kde.org/71929
forwarded 217064 http://bugs.kde.org/66046
forwarded 218985 http://bugs.kde.org/41941
forwarded 219425 http://bugs.kde.org/76372
forwarded 219648 http://bugs.kde.org/69818...

[Debian Qt/KDE Maintainers (debian-qt-kde)]

user <email address hidden>
forwarded 321102 http://bugs.kde.org/104956
usertag 321102 =
usertag 321102 + bzStatus-new
thanks

[Bastian Venthur (expires-2007)]

Hi Devs,

I noticed KMail moving to testing, although it has grave bugs open. Was
this a mistake? I always thought packages with RC Bugs don't enter
testing until they're fixed?

Looking at #321102, I noticed that "found in version" is set to various
old versions but not to the current one (which is not that old BTW). If
this affected the migration to testing, it would look like cheating to
me in order to get the current PIM into testing at all costs.

I might be biased since I'm the reporter of some of the RC-bugs, but the
according upstream-bugs are still open (and still has 780 votes), so I
don't see a reason to assume this bug was somehow fixed. I suggest to
keep the bug open for every current version until the according
upstream-bug is closed. Since this is currently the only grave bug in
upstreams BTS I think the chances that upstream will forget about the
bug are pretty low.

Best regards,

Bastian

[Christopher Martin (chrsmrtn-debian)]

On Tuesday 25 April 2006 02:48, Bastian Venthur wrote:
> I noticed KMail moving to testing, although it has grave bugs open.
> Was this a mistake? I always thought packages with RC Bugs don't
> enter testing until they're fixed?
>
> Looking at #321102, I noticed that "found in version" is set to
> various old versions but not to the current one (which is not that
> old BTW). If this affected the migration to testing, it would look
> like cheating to me in order to get the current PIM into testing at
> all costs.
>
> I might be biased since I'm the reporter of some of the RC-bugs, but
> the according upstream-bugs are still open (and still has 780 votes),
> so I don't see a reason to assume this bug was somehow fixed. I
> suggest to keep the bug open for every current version until the
> according upstream-bug is closed. Since this is currently the only
> grave bug in upstreams BTS I think the chances that upstream will
> forget about the bug are pretty low.

Packages are allowed in to testing if the RC bug count on the version in
testing is higher or equal to the RC bug count on the version in
unstable. Since upstream bug reports indicated that the problems in
Kmail go back to KDE 3.4 at least (hence all the "found in" additions),
there was no point in holding kdepim 3.5 out of testing, since there
was no regression. It doesn't matter if the very latest package is not
marked "found in" for counting purposes; if the bug is open, then this
is assumed to be the case. Indeed, some people strongly suspect that
kdepim 3.5.2 fixed the problems, though since this isn't certain, we
should keep the bugs open for now. Still, this makes letting kdepim
into testing worthwhile.

Cheers,
Christopher Martin

[Pierre Habouzit (madcoder)]

user <email address hidden>

forwarded 100894 http://bugs.kde.org/6184
usertag 6184 =
usertag 6184 + bzStatus-new
forwarded 101379 http://bugs.kde.org/32192
usertag 32192 =
usertag 32192 + bzStatus-unconfirmed
forwarded 102462 http://bugs.kde.org/35918
usertag 35918 =
usertag 35918 + bzStatus-unconfirmed
forwarded 111358 http://bugs.kde.org/35921
usertag 35921 =
usertag 35921 + bzStatus-closed
usertag 35921 + bzRes-fixed

forwarded 116824 http://bugs.kde.org/35926
usertag 35926 =
usertag 35926 + bzStatus-resolved
usertag 35926 + bzRes-wontfix

forwarded 116826 http://bugs.kde.org/22723
usertag 22723 =
usertag 22723 + bzStatus-new
forwarded 118834 http://bugs.kde.org/35938
usertag 35938 =
usertag 35938 + bzStatus-new
forwarded 131562 http://bugs.kde.org/48485
usertag 48485 =
usertag 48485 + bzStatus-resolved
usertag 48485 + bzRes-worksforme

forwarded 134368 http://bugs.kde.org/40418
usertag 40418 =
usertag 40418 + bzStatus-new
forwarded 134611 http://bugs.kde.org/54379
usertag 54379 =
usertag 54379 + bzStatus-resolved
usertag 54379 + bzRes-fixed

forwarded 135632 http://bugs.kde.org/37210
usertag 37210 =
usertag 37210 + bzStatus-new
forwarded 141094 http://bugs.kde.org/54329
usertag 54329 =
usertag 54329 + bzStatus-resolved
usertag 54329 + bzRes-fixed

forwarded 141095 http://bugs.kde.org/54330
usertag 54330 =
usertag 54330 + bzStatus-resolved
usertag 54330 + bzRes-fixed

forwarded 143457 http://bugs.kde.org/31055
usertag 31055 =
usertag 31055 + bzStatus-unconfirmed
forwarded 145786 http://bugs.kde.org/62603
usertag 62603 =
usertag 62603 + bzStatus-new
forwarded 146047 http://bugs.kde.org/54382
usertag 54382 =
usertag 54382 + bzStatus-resolved
usertag 54382 + bzRes-fixed

forwarded 147088 http://bugs.kde.org/118123
usertag 118123 =
usertag 118123 + bzStatus-unconfirmed
forwarded 158841 http://bugs.kde.org/66790
usertag 66790 =
usertag 66790 + bzStatus-resolved
usertag 66790 + bzRes-fixed

forwarded 172610 http://bugs.kde.org/59069
usertag 59069 =
usertag 59069 + bzStatus-unconfirmed
forwarded 174560 http://bugs.kde.org/67153
usertag 67153 =
usertag 67153 + bzStatus-new
forwarded 180801 http://bugs.kde.org/54845
usertag 54845 =
usertag 54845 + bzStatus-new
forwarded 180894 http://bugs.kde.org/71338
usertag 71338 =
usertag 71338 + bzStatus-reopened
forwarded 183281 http://bugs.kde.org/66020
usertag 66020 =
usertag 66020 + bzStatus-new
forwarded 185034 http://bugs.kde.org/66050
usertag 66050 =
usertag 66050 + bzStatus-new
forwarded 185116 http://bugs.kde.org/59599
usertag 59599 =
usertag 59599 + bzStatus-new
forwarded 185957 http://bugs.kde.org/70053
usertag 70053 =
usertag 70053 + bzStatus-resolved
usertag 70053 + bzRes-fixed

forwarded 186150 http://bugs.kde.org/28321
usertag 28321 =
usertag 28321 + bzStatus-new
forwarded 186164 http://bugs.kde.org/33372
usertag 33372 =
usertag 33372 + bzStatus-new
forwarded 187339 http://bugs.kde.org/43366
usertag 43366 =
usertag 43366 + bzStatus-new
forwarded 187887 http://bugs.kde.org/66049
usertag 66049 =
usertag 66049 + bzStatus-new
forwarded 190033 http://bugs.kde.org/66318
usertag 66318 =
usertag 66318 + bzStatus-resolved
usertag 66318 + bzRes-duplicate

forwarded 192045 http://bugs.kde.org/6604...

[Pierre Habouzit (madcoder)]

user <email address hidden>
forwarded 85437 http://bugs.kde.org/show_bug.cgi?id=20186
tags 85437 + upstream fixed-upstream
usertags 85437 + status-CLOSED resolution-FIXED
tags 223708 + upstream fixed-upstream
usertags 223708 + status-CLOSED resolution-FIXED
forwarded 85443 http://bugs.kde.org/show_bug.cgi?id=20187
tags 85443 + upstream fixed-upstream
usertags 85443 + status-CLOSED resolution-FIXED
forwarded 100894 http://bugs.kde.org/show_bug.cgi?id=6184
tags 100894 + upstream
usertags 100894 + status-NEW
tags 215400 + upstream
usertags 215400 + status-NEW
tags 94567 + upstream wontfix
usertags 94567 + status-RESOLVED resolution-WONTFIX
forwarded 101379 http://bugs.kde.org/show_bug.cgi?id=32192
tags 101379 - wontfix
tags 101379 + upstream
usertags 101379 + status-UNCONFIRMED
usertags 154184 + status-RESOLVED resolution-FIXED
forwarded 102462 http://bugs.kde.org/show_bug.cgi?id=35918
usertags 102462 + status-UNCONFIRMED
forwarded 262988 http://bugzilla.kernel.org/show_bug.cgi?id=4532
tags 262988 + upstream fixed-upstream
usertags 262988 + status-CLOSED resolution-CODE_FIX
tags 132860 + upstream wontfix
usertags 132860 + status-RESOLVED resolution-WONTFIX
usertags 226824 + status-ASSIGNED
tags 221999 + upstream fixed-upstream
usertags 221999 + status-RESOLVED resolution-WORKSFORME
forwarded 103201 http://bugs.kde.org/show_bug.cgi?id=28072
tags 103201 + fixed-upstream
usertags 103201 + status-RESOLVED resolution-FIXED
usertags 169092 + status-NEW
tags 251067 + upstream
usertags 251067 + status-NEW
tags 144907 + upstream
usertags 144907 + status-ASSIGNED
forwarded 111358 http://bugs.kde.org/show_bug.cgi?id=35921
tags 111358 + upstream fixed-upstream
usertags 111358 + status-CLOSED resolution-FIXED
usertags 297529 + status-NEW
tags 223738 + upstream fixed-upstream
usertags 223738 + status-RESOLVED resolution-WORKSFORME
forwarded 116824 http://bugs.kde.org/show_bug.cgi?id=35926
usertags 116824 + status-RESOLVED resolution-WONTFIX
tags 180740 + upstream
usertags 180740 + status-REOPENED
usertags 169146 + status-NEW
tags 223928 + upstream fixed-upstream
usertags 223928 + status-RESOLVED resolution-WORKSFORME
usertags 190690 + status-UNCONFIRMED
tags 266542 + upstream
usertags 266542 + status-NEW
forwarded 116826 http://bugs.kde.org/show_bug.cgi?id=22723
usertags 116826 + status-NEW
tags 311758 + upstream
usertags 311758 + status-RESOLVED resolution-CODE_FIX
tags 303074 + upstream fixed-upstream
usertags 303074 + status-RESOLVED resolution-WORKSFORME
tags 196814 + upstream
usertags 196814 + status-NEW
tags 48602 + upstream wontfix
usertags 48602 + status-RESOLVED resolution-WONTFIX
tags 201323 + upstream
usertags 201323 + status-NEW
tags 238290 + upstream
usertags 238290 + status-NEW
forwarded 231017 https://bugzilla.icculus.org/show_bug.cgi?id=952
usertags 231017 + status-ASSIGNED
usertags 321403 + status-ASSIGNED
forwarded 118834 http://bugs.kde.org/show_bug.cgi?id=35938
usertags 118834 + status-NEW
usertags 200342 + status-NEW
tags 206744 + fixed-upstream
usertags 206744 + status-RESOLVED resolution-FIXED
tags 280412 + fixed-upstream
usertags 280412 + status-RESOLVED resolution-FIXED
tags 310141 + upstream
usertags 310141 + statu...

[Bastian Venthur (expires-2007)]

So here it is, someone confirmed this bug with 3.5.2 on Debian:

 http://bugs.kde.org/show_bug.cgi?id=104956

Quote:

"Bam! I had this bug right now. Using KDE 3.5.2 on Debian. Lost a whole
folder of mails (thank god it was only a ML). Nevertheless this is
totally uncool..."

Whoever marked this bug as "found in $VERSION" should upgrade this to
the newest version too or remove it completely (we know this bug is open
for years and there is IMHO reason to track every version-number the bug
appeared).

And please consider to remove KMail from testing again. There is nothing
"stable" about losing a whole Mail-Folder. Especially when we *know* the
software leads to data loss but pretend it to be stable.

Best regards,

Bastian

[Christopher Martin (chrsmrtn-debian)]

found 321102 4:3.5.2-1
found 332473 4:3.5.2-1
found 350851 4:3.5.2-1
stop

On Tuesday 16 May 2006 10:05, Bastian Venthur wrote:
> So here it is, someone confirmed this bug with 3.5.2 on Debian:
>
> http://bugs.kde.org/show_bug.cgi?id=104956
>
> Quote:
>
> "Bam! I had this bug right now. Using KDE 3.5.2 on Debian. Lost a
> whole folder of mails (thank god it was only a ML). Nevertheless this
> is totally uncool..."

Darn, I thought that perhaps it had gone away.

> Whoever marked this bug as "found in $VERSION" should upgrade this to
> the newest version too or remove it completely (we know this bug is
> open for years and there is IMHO reason to track every version-number
> the bug appeared).

I have added the "founds" for this version for the sake of clarity, but
it isn't necessary to mark "founds" for every last upload; the bug is
assumed to be present by the BTS unless marked fixed.

> And please consider to remove KMail from testing again. There is
> nothing "stable" about losing a whole Mail-Folder. Especially when we
> *know* the software leads to data loss but pretend it to be stable.

Perhaps a better solution would be disable dimap support in the 3.5.3
upload, and make sure that the fixed package makes Etch (which is
looming). Daniel, what do you feel about this? Given that upstream
appears to be unable to replicate and fix the problem, I think this
might be the safest, and least bothersome (to all other KMail users)
way of dealing with this issue.

Cheers,
Christopher Martin

[Adam Porter (alphapapa)]

On Tuesday 16 May 2006 11:03, Christopher Martin wrote:
> Perhaps a better solution would be disable dimap support in the 3.5.3
> upload, and make sure that the fixed package makes Etch (which is
> looming). Daniel, what do you feel about this? Given that upstream
> appears to be unable to replicate and fix the problem, I think this
> might be the safest, and least bothersome (to all other KMail users)
> way of dealing with this issue.

Personally, I'd be disappointed if this was done. I know the bug is present,
but I rely on KMail's dimap support for my mail. I switched from Thunderbird
because of Thunderbird's lousy, buggy dimap support. KMail's is superb,
other than this bug (which hasn't hit me yet).

By the way, you referred to "the fixed package." As far as I'm aware, this
bug isn't about to be fixed. A comment was made on the KDE Bugzilla that
really fixing it would require a restructuring of the IMAP backend/kioslave.
Did I miss something? I sure hope so, cause I'd love for this bug to be
truly fixed.

[Pierre Habouzit (madcoder)]

Le Mer 17 Mai 2006 05:30, Adam Porter a écrit :
> On Tuesday 16 May 2006 11:03, Christopher Martin wrote:
> > Perhaps a better solution would be disable dimap support in the
> > 3.5.3 upload, and make sure that the fixed package makes Etch
> > (which is looming). Daniel, what do you feel about this? Given that
> > upstream appears to be unable to replicate and fix the problem, I
> > think this might be the safest, and least bothersome (to all other
> > KMail users) way of dealing with this issue.
>
> Personally, I'd be disappointed if this was done. I know the bug is
> present, but I rely on KMail's dimap support for my mail. I switched
> from Thunderbird because of Thunderbird's lousy, buggy dimap support.
> KMail's is superb, other than this bug (which hasn't hit me yet).

this is not acceptable for our users. I'm in favor of disabling dimap
until that bug really disappears as well.

--
·O· Pierre Habouzit
··O <email address hidden>
OOO http://www.madism.org

[Bastian Venthur (expires-2007)]

retitle 321102 kmail loses mails
quit

Fixed typo in subject, feel free to adjust it accordingly.

[Marc 'HE' Brockschmidt (marc-marcbrockschmidt)]

Heya,

321102 has been open for a long time now, but etch is relatively near
now (especially for a big and therefore slow-moving package like
kdepim). In the last few mails in the buglog disabling the dimap support
leading to this problem was proposed, but there hasn't been any reaction
to this in the last month. Could you please give a short overview and
tell us what you're planning to do about this?

Marc
--
BOFH #399:
We are a 100% Microsoft Shop.

[Pierre Habouzit (madcoder)]

On Tue, Jun 13, 2006 at 12:09:17AM +0200, Marc 'HE' Brockschmidt wrote:
> Heya,
>
> 321102 has been open for a long time now, but etch is relatively near
> now (especially for a big and therefore slow-moving package like
> kdepim). In the last few mails in the buglog disabling the dimap support
> leading to this problem was proposed, but there hasn't been any reaction
> to this in the last month. Could you please give a short overview and
> tell us what you're planning to do about this?

  http://bugs.kde.org/show_bug.cgi?id=104956#c52 explains all the horror
of the situation.

  Ping daniel ? etch is close, and we *really* need to do something
here. I've looked at the source, disabling dimap seems quite ...
difficult to do, and upstream is clearly unwilling to fix it before KDE
4 wich will be too late.

  so fixing it (with a patch presumably) won't be easy and will need
testing. we should work on it. I lack the essential qualities to write
that patch sadly, and I've not found any on the web.
--
·O· Pierre Habouzit
··O <email address hidden>
OOO http://www.madism.org

[Sune Vuorela (sune-vuorela)]

On Thursday 15 June 2006 00:21, Pierre HABOUZIT, <email address hidden> wrote:
> Ping daniel ? etch is close, and we *really* need to do something
> here. I've looked at the source, disabling dimap seems quite ...
> difficult to do, and upstream is clearly unwilling to fix it before KDE
> 4 wich will be too late.

Being friendly and poking a bit to people on irc made one come up with a
partly patch. Now, creating new dIMAP-accounts in kmail is disabled thru the
user interface.

It is, although, still possible to create dIMAP accounts if you hand-edit the
configuration files. You need to be more skilled than normal to create your
config files yourself. For those who really want it, removing the patch and
rebuilding kmail would be easier.

THis means that there still might need to be found some solution for existing
dIMAP configurations.

I don't know if creating a warnbox on kmail startup saying "You are using
dIMAP - this might eat your data - please change to IMAP." would suffice.
Or maybe a debconf note on upgrade ?

But here is the patch; thanks to pinotree.

/Sune

[Sune Vuorela (debian-pusling)]

On Saturday 17 June 2006 10:17, Sune Vuorela wrote:
> Being friendly and poking a bit to people on irc made one come up with a
> partly patch. Now, creating new dIMAP-accounts in kmail is disabled thru
> the user interface.

Poking around people on irc sometimes helps.

The new plan is that we all during this week try to reproduce this bug and
create a step-by-step-manual to reproduce it, so the kmail developres can fix
it.

Remember that this is a dataloss bug, so have your backups ready (or use your
spam folder for testing)

Happy testing - and let us get this bug squashed.

/Sune

[Bastian Venthur (expires-2007)]

Hi,

I'm writing again since Pierre seems to have found a way to reproduce
this bug:

 http://bugs.kde.org/show_bug.cgi?id=104956#c71

As you might know I was very unhappy to see KMail entering testing with
this grave bug open. Someone came up with the idea that this bug might
have vanished, since it was hard to reproduce and not seen for a few
weeks. But Pierre finally seems to have proven the opposite.

According to Pierre's findings it seems like there is a latent (but
present) risk of losing some or all your IMAP data due bad code in KMail
(details in the bugreport above).

In order to fullfill our dont-hide-problems policy I'd suggest to to
remove KMail from testing or at least provide a new version with DIMAP
disabled.

Best regards,

Bastian

--
Bastian Venthur
http://venthur.de

[Fathi Boudra (fboudra)]

Till Adam provides 2 patches (one to fix, another to increase debugging verbosity). They have been included on Debian, it could be nice to do the same.

[Daniel Schepler (schepler)]

Source: kdepim
Source-Version: 4:3.5.5-1

We believe that the bug you reported is fixed in the latest version of
kdepim, which is due to be installed in the Debian FTP archive:

akregator_3.5.5-1_i386.deb
  to pool/main/k/kdepim/akregator_3.5.5-1_i386.deb
kaddressbook_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kaddressbook_3.5.5-1_i386.deb
kalarm_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kalarm_3.5.5-1_i386.deb
kandy_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kandy_3.5.5-1_i386.deb
karm_3.5.5-1_i386.deb
  to pool/main/k/kdepim/karm_3.5.5-1_i386.deb
kdepim-dbg_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kdepim-dbg_3.5.5-1_i386.deb
kdepim-dev_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kdepim-dev_3.5.5-1_i386.deb
kdepim-doc-html_3.5.5-1_all.deb
  to pool/main/k/kdepim/kdepim-doc-html_3.5.5-1_all.deb
kdepim-doc_3.5.5-1_all.deb
  to pool/main/k/kdepim/kdepim-doc_3.5.5-1_all.deb
kdepim-kfile-plugins_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kdepim-kfile-plugins_3.5.5-1_i386.deb
kdepim-kio-plugins_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kdepim-kio-plugins_3.5.5-1_i386.deb
kdepim-kresources_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kdepim-kresources_3.5.5-1_i386.deb
kdepim-wizards_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kdepim-wizards_3.5.5-1_i386.deb
kdepim_3.5.5-1.diff.gz
  to pool/main/k/kdepim/kdepim_3.5.5-1.diff.gz
kdepim_3.5.5-1.dsc
  to pool/main/k/kdepim/kdepim_3.5.5-1.dsc
kdepim_3.5.5-1_all.deb
  to pool/main/k/kdepim/kdepim_3.5.5-1_all.deb
kdepim_3.5.5.orig.tar.gz
  to pool/main/k/kdepim/kdepim_3.5.5.orig.tar.gz
kitchensync_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kitchensync_3.5.5-1_i386.deb
kleopatra_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kleopatra_3.5.5-1_i386.deb
kmail_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kmail_3.5.5-1_i386.deb
kmailcvt_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kmailcvt_3.5.5-1_i386.deb
knode_3.5.5-1_i386.deb
  to pool/main/k/kdepim/knode_3.5.5-1_i386.deb
knotes_3.5.5-1_i386.deb
  to pool/main/k/kdepim/knotes_3.5.5-1_i386.deb
kode_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kode_3.5.5-1_i386.deb
konsolekalendar_3.5.5-1_i386.deb
  to pool/main/k/kdepim/konsolekalendar_3.5.5-1_i386.deb
kontact_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kontact_3.5.5-1_i386.deb
korganizer_3.5.5-1_i386.deb
  to pool/main/k/kdepim/korganizer_3.5.5-1_i386.deb
korn_3.5.5-1_i386.deb
  to pool/main/k/kdepim/korn_3.5.5-1_i386.deb
kpilot_3.5.5-1_i386.deb
  to pool/main/k/kdepim/kpilot_3.5.5-1_i386.deb
ksync_3.5.5-1_i386.deb
  to pool/main/k/kdepim/ksync_3.5.5-1_i386.deb
ktnef_3.5.5-1_i386.deb
  to pool/main/k/kdepim/ktnef_3.5.5-1_i386.deb
libindex0-dev_3.5.5-1_i386.deb
  to pool/main/k/kdepim/libindex0-dev_3.5.5-1_i386.deb
libindex0_3.5.5-1_i386.deb
  to pool/main/k/kdepim/libindex0_3.5.5-1_i386.deb
libkcal2-dev_3.5.5-1_i386.deb
  to pool/main/k/kdepim/libkcal2-dev_3.5.5-1_i386.deb
libkcal2b_3.5.5-1_i386.deb
  to pool/main/k/kdepim/libkcal2b_3.5.5-1_i386.deb
libkdepim1-dev_3.5.5-1_i386.deb
  to pool/main/k/kdepim/libkdepim1-dev_3.5.5-1_i386.deb
libkdepim1a_3.5.5-1_i386.deb
  to pool/main/k/kdepim/libkdepim1a_3.5.5-1_i386.deb
libkgantt0-dev_3.5.5-1_i386.deb
  to pool/main/k/kdepim/libkgantt0-dev_3.5.5-1_i386.deb
libkgantt0_3.5.5-1_i386.deb
  to pool/main/k/k...

[Bastian Venthur (venthur)]

submitter 302240 !
submitter 327113 !
submitter 348481 !
submitter 378975 !
submitter 342784 !
submitter 258377 !
submitter 286466 !
submitter 316766 !
submitter 317057 !
submitter 322543 !
submitter 347953 !
submitter 379561 !
submitter 317054 !
submitter 320674 !
submitter 337937 !
submitter 337938 !
submitter 356182 !
submitter 358979 !
submitter 266398 !
submitter 322334 !
submitter 348223 !
submitter 384106 !
submitter 309379 !
submitter 321102 !
submitter 330607 !
submitter 332473 !
submitter 336775 !
submitter 345161 !
submitter 360363 !
submitter 384962 !
submitter 266378 !
submitter 266544 !
submitter 283349 !
submitter 309682 !
submitter 319387 !
submitter 321733 !
submitter 326755 !
submitter 342786 !
submitter 342788 !
submitter 345194 !
submitter 350614 !
submitter 360360 !
submitter 380740 !
submitter 306183 !
submitter 331398 !
submitter 331646 !
submitter 340071 !
submitter 348083 !
submitter 348537 !
submitter 350305 !
submitter 379118 !
submitter 266401 !
submitter 266428 !
submitter 288221 !
submitter 321230 !
submitter 322161 !
submitter 322225 !
submitter 322319 !
submitter 322335 !
submitter 322356 !
submitter 322437 !
submitter 324179 !
submitter 324849 !
submitter 325922 !
submitter 358558 !
submitter 378892 !
quit

[Bts-link-upstream (bts-link-upstream)]

#
# bts-link upstream status pull for source package kdepim
# see http://lists.debian.org/debian-devel-announce/2006/05/msg00001.html
#

user <email address hidden>

# remote status report for #321102
# * http://bugs.kde.org/show_bug.cgi?id=104956
# * remote status changed: NEW -> RESOLVED
# * remote resolution changed: (?) -> FIXED
# * closed upstream
tags 321102 + fixed-upstream
usertags 321102 - status-NEW
usertags 321102 + status-RESOLVED resolution-FIXED

# remote status report for #332473
# * http://bugs.kde.org/show_bug.cgi?id=104956
# * remote status changed: NEW -> RESOLVED
# * remote resolution changed: (?) -> FIXED
# * closed upstream
tags 332473 + fixed-upstream
usertags 332473 - status-NEW
usertags 332473 + status-RESOLVED resolution-FIXED

# remote status report for #350851
# * http://bugs.kde.org/show_bug.cgi?id=104956
# * remote status changed: NEW -> RESOLVED
# * remote resolution changed: (?) -> FIXED
# * closed upstream
tags 350851 + fixed-upstream
usertags 350851 - status-NEW
usertags 350851 + status-RESOLVED resolution-FIXED

# remote status report for #394309
# * http://bugs.kde.org/show_bug.cgi?id=135513
# * remote status changed: (?) -> RESOLVED
# * remote resolution changed: (?) -> FIXED
# * closed upstream
tags 394309 + fixed-upstream
usertags 394309 + status-RESOLVED resolution-FIXED

# remote status report for #394534
# * http://bugs.kde.org/show_bug.cgi?id=137306
# * remote status changed: UNCONFIRMED -> RESOLVED
# * remote resolution changed: (?) -> FIXED
# * closed upstream
tags 394534 + fixed-upstream
usertags 394534 - status-UNCONFIRMED
usertags 394534 + status-RESOLVED resolution-FIXED

# remote status report for #394998
# * http://bugs.kde.org/show_bug.cgi?id=135513
# * remote status changed: (?) -> RESOLVED
# * remote resolution changed: (?) -> FIXED
usertags 394998 + status-RESOLVED resolution-FIXED

# remote status report for #399876
# * http://bugs.kde.org/show_bug.cgi?id=136042
# * remote status changed: (?) -> UNCONFIRMED
usertags 399876 + status-UNCONFIRMED

thanks

[Sarah Kowalik (hobbsee-deactivatedaccount)]

we'll grab this in 3.5.6

[Adam Porter (alphapapa)]

tags 350851 -fixed-upstream
reopen 350851
found 350851 4:3.5.5.dfsg.1-4
thanks

(Actually I can't seem to reopen this bug in KDE. Argh. If someone doesn't
notice and reopen it, I'll file a new one and link it to Debian.)

It's with a heavy heart that I reopen this bug on KDE's and Debian's trackers.
Here's what just happened to me (using KMail 4:3.5.5.dfsg.1-4 from Debian):

Every time I reboot, the system changes my mouse evdev device back and forth
from /dev/input/event[1|2] to /dev/input/event[1|2], so I end up with no
mouse control, having to switch to another VT, edit xorg.conf and restart X.
KMail is usually in my previous session, and I have auto-login set up in KDM,
so when I booted, it logged me in, started KMail and downloaded new mail.
When I returned and saw that there was no mouse control, I edited xorg.conf
and restarted KDM. I probably should have used the keyboard to log out of my
KDE session first, rather than restarting KDM and causing X and all child
processes to be terminated. But still, should that have caused seven e-mails
that were displaying perfectly fine in my inbox and two subfolders to
suddenly turn to "No Subject",
completely-empty-view-the-source-and-there's-zilch goners? Then after
logging back in, KMail proceeded to upload those empty mails to the IMAP
server, erasing the e-mails there as well. Luckily I forward all my e-mail
to GMail as well, so I can still see them there.

The strange part is, after I restarted X and logged back in and started KMail,
the e-mails in my inbox were fine, at first. I read one and replied to it
even! But then when I clicked on the next unread message, the subject and
sender of the message I just clicked on turned into "No Subject"
and "Unknown". And then when I clicked on the message that I had *just read
and replied to*, it also turned into "No Subject" "Unknown"! Then when I
checked two other folders, the new messages in them were also "No
Subject" "Unknown"!

I hate to be the bearer of bad news, but KMail still has this problem. (Or
maybe this is actually a separate bug caused by a separate problem, but the
end result is still mail loss in disconnected IMAP accounts.)

[Ana Beatriz Guerrero López (ana)]

tags 350851 +fixed-upstream
notfound 350851 4:3.5.5.dfsg.1-4
close 350851 4:3.5.5-1
thanks

On Thu, Dec 28, 2006 at 07:06:16PM -0600, Adam Porter wrote:
[...]
>
> I hate to be the bearer of bad news, but KMail still has this problem. (Or
> maybe this is actually a separate bug caused by a separate problem, but the
> end result is still mail loss in disconnected IMAP accounts.)

Sorry Adam, we (KDE team) have been discussing this and we think this bug
is fixed. Since this bug was fixed in october only you has reported this
problem again. Also, after read your mail, it does not seem you have exactly
the same problem neither.
So, i'm closing the bug and you always can open a new one if you find out what
it is exaclty the problem.

P.S: btw, perhaps you could use /dev/input/mice instead?

[Bastian Venthur (venthur)]

reopen 350851
thanks

Hi,

I know this mail sucks (like this whole bug) but looking at the relevant
KDE bugreport, I really doubt that this bug is fixed.

  http://bugs.kde.org/show_bug.cgi?id=104956

I'm not using KMail anymore so I can't give any first hand information,
but I'm still following the relevant KDE bugreports and It simply looks
like this bug is not fixed.

Why was it closed anyway? Looks like upstreams bugreport is still open too.

Cheers,

Bastian

--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org

[Ana Beatriz Guerrero López (ana)]

close 350851 4:3.5.5-1
thanks

Hi Bastian,

On Mon, Jan 08, 2007 at 10:12:17PM +0100, Bastian Venthur wrote:
> reopen 350851
> thanks
>
> Hi,
>
> I know this mail sucks (like this whole bug) but looking at the relevant
> KDE bugreport, I really doubt that this bug is fixed.
>
> http://bugs.kde.org/show_bug.cgi?id=104956
>
> I'm not using KMail anymore so I can't give any first hand information,
> but I'm still following the relevant KDE bugreports and It simply looks
> like this bug is not fixed.
>
> Why was it closed anyway? Looks like upstreams bugreport is still open too.
>

So, you do not use kmail anymore, go to the kde bugzilla and see people
is still suffering this bug in kubuntu and decide to re-open this bug
in the Debian BTS?

The commit that should fix this bug was not committed before the kde3.5.5
release, so only distributions that have hand-picked the fix from svn had
it included.
It is 'closed' in kde bugzilla. 'Verified' is the 'step' after 'fixed'
in bugzilla wordings. Verified that it is fixed). Don't mix it with
'confirmed' which is a confirmation that the bug exists.

Ana

[Bastian Venthur (venthur)]

Ana Guerrero schrieb:
> So, you do not use kmail anymore, go to the kde bugzilla and see people
> is still suffering this bug in kubuntu and decide to re-open this bug
> in the Debian BTS?

No, I'm still subscribed to the relevant bugreports in the KDE bugzilla
(since I myself suffered from this bug) and noticed that every now and
then still mails come in. After I received another mail yesterday
claiming that this bug is still not fixed I looked through the Debian
BTS and KDEs BTS.

Looks like in Debian's BTS someone tried to reopen this bug in Deceber.
He even wanted to reopen this closed bug in the KDE BTS but he did not
know how so he opened a new one.

This and the point that in the main KDE bugreport (sudden mail loss)
even he KDE devs don't seem to claim that the bug is fixed but just
notice that it seems to be less likely to happen, I think/fear this bug
is still not fixed.

> The commit that should fix this bug was not committed before the kde3.5.5
> release, so only distributions that have hand-picked the fix from svn had
> it included.
> It is 'closed' in kde bugzilla. 'Verified' is the 'step' after 'fixed'
> in bugzilla wordings. Verified that it is fixed). Don't mix it with
> 'confirmed' which is a confirmation that the bug exists.

Sorry my bad, I really did not see that this bug was fixed. I really
should unsubscribe from upstreams BTS :)

Anyway, maybe this bug is fixed and I just overreacted -- let's hope for
the best.

Cheers,

Bastian

--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org

[Adam Porter (alphapapa)]

> close 350851 4:3.5.5-1
> thanks
>
> Hi Bastian,
>
> On Mon, Jan 08, 2007 at 10:12:17PM +0100, Bastian Venthur wrote:
> > reopen 350851
> > thanks
> >
> > Hi,
> >
> > I know this mail sucks (like this whole bug) but looking at the relevant
> > KDE bugreport, I really doubt that this bug is fixed.
> >
> > http://bugs.kde.org/show_bug.cgi?id=104956
> >
> > I'm not using KMail anymore so I can't give any first hand information,
> > but I'm still following the relevant KDE bugreports and It simply looks
> > like this bug is not fixed.
> >
> > Why was it closed anyway? Looks like upstreams bugreport is still open
> > too.
>
> So, you do not use kmail anymore, go to the kde bugzilla and see people
> is still suffering this bug in kubuntu and decide to re-open this bug
> in the Debian BTS?
>
> The commit that should fix this bug was not committed before the kde3.5.5
> release, so only distributions that have hand-picked the fix from svn had
> it included.
> It is 'closed' in kde bugzilla. 'Verified' is the 'step' after 'fixed'
> in bugzilla wordings. Verified that it is fixed). Don't mix it with
> 'confirmed' which is a confirmation that the bug exists.
>
>
> Ana

Ana,

If you check the latest reports on KDE #104956, you'll see that Christian
Maluck reports mail loss with the 1.9.5 version in Kubuntu, which checking
the changelog reveals to have the patch that is merged upstream in 3.5.5,
which means it has the same patch that Debian has.

Clearly, regardless of the upstream bug tracker's "status" field (which I and
others would change but are unable to), this bug is not solved. I just
experienced it myself a short time ago, and others are also experiencing it.
Why don't you just reopen this bug, rather than asking me to open an entirely
new bug and throwing away the logs associated with this one?

This is a severely damaging bug resulting in mail loss both locally and on the
server. Please reopen it until it is truly fixed.

Adam Porter

[Ana Beatriz Guerrero López (ana)]

Hi Adam,

On Tue, Jan 09, 2007 at 06:18:25AM -0600, Adam Porter wrote:
> >
> > So, you do not use kmail anymore, go to the kde bugzilla and see people
> > is still suffering this bug in kubuntu and decide to re-open this bug
> > in the Debian BTS?
> >
> > The commit that should fix this bug was not committed before the kde3.5.5
> > release, so only distributions that have hand-picked the fix from svn had
> > it included.
> > It is 'closed' in kde bugzilla. 'Verified' is the 'step' after 'fixed'
> > in bugzilla wordings. Verified that it is fixed). Don't mix it with
> > 'confirmed' which is a confirmation that the bug exists.
> >
> >
> > Ana
>
> Ana,
>
> If you check the latest reports on KDE #104956, you'll see that Christian
> Maluck reports mail loss with the 1.9.5 version in Kubuntu, which checking
> the changelog reveals to have the patch that is merged upstream in 3.5.5,
> which means it has the same patch that Debian has.
>
> Clearly, regardless of the upstream bug tracker's "status" field (which I and
> others would change but are unable to), this bug is not solved. I just
> experienced it myself a short time ago, and others are also experiencing it.
> Why don't you just reopen this bug, rather than asking me to open an entirely
> new bug and throwing away the logs associated with this one?
>
> This is a severely damaging bug resulting in mail loss both locally and on the
> server. Please reopen it until it is truly fixed.
>

As i told you i think you have a different problem that is not the same bug.
You can never swear a bug is totally fixed, but so far, we have no evidence
to think this bug is still unfixed.

Kubuntu's packaging of kde 3.5.5 was done separately from ours, and from what
I have seen they're not applying the patch that fixes this issue.
Upstream bug 104956 (http://bugs.kde.org/104956) has a patch attached to it
that was applied to KDE's 3.5 branch after 3.5.5 was tagged. We have included
that patch and it seems to fix the issue. This problem still occurs in other
distros (like Kubuntu) because they have not included that patch yet.
It will be fixed for them in KDE 3.5.6.

Ana

[Bastian Venthur (venthur)]

reopen 350851
forcemerge 350851 406258
thanks

Ok since there seem to be some uncertainty whether this bug is fixed or
not I tried to reproduce my beloved bug today and the sad news is that I
was able to reproduce this bug again.

I'll play around a bit to gain more informations and write a follow up
later. But for the impatient: Moving Mails from one folder to another
with DIMAP does nothing on the server (until you restarted KMail?).
Combine this with the same account on a different machine et voila.

Please don't close this bug again!

Cheers,

Bastian

--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org

[Bastian Venthur (venthur)]

reopen 321102
tags 321102 - fixed-upstream
thanks

Here are some minimalistic ways to reproduce this bug.

Some observations:

1) KMail does not show what's on the server but rather what should be on
the server:

When moving mails around in KMail, the mails aren't actually moved on
the server directly. KMail does this later (when?). Even when you close
and reopen KMail the mail is not moved on the server, although KMail
pretends that it has moved the mail! (Which is the root of the problem
as we will see later)

2) Pressing F5 inside a folder commits open changes for this folder on
the server.

2.a) Pressing F5 inside folder foo commits changes for foo but not for
folder bar (which is so dangerous that I cannot believe this was
actually implemented)

3) Rebuilding cache (sorry translated from my German version) seems to
re-read all the data from the server and overwrites KMails yet
uncommitted actions -- for this folder!

4) People who use IMAP tend to check their mails from more than one machine.

5) People have more than one account and sometimes move files from one
folder to another one on a different account.

Here is what I've used:

- Current KMail 1.9.5 from Sid
- current Dovecot from etch on the server side
- Initial layout: Four mails in inbox and two empty folders:

|-- Inbox
| |-- mail 1
| |-- mail 2
| |-- mail 3
| `-- mail 4
|-- folder 1
`-- folder 2

Ok let's get to the bug. I found different methods to reproduce this
bug. Here is the first and simplest method: I'll delete a mail by moving
a mail from one folder to another:

1) Drag mail 1 to folder 1 (move).
2) Now take a look on the server: Inbox has still 4 mails, folder 1 is
still empty. The changes are not committed to the server although KMail
pretends to.

3) Now go into your inbox and press F5 (refresh)
4) On the serverside mail 1 is now deleted from your Inbox but still not
present in folder 1. In other words if you'd close KMail now and delete
all it's configuration files from this box, mail 1 is lost!

Of course mail 1 is still living somewhere in KMails config files an
pressing F5 folder 1 will bring it back, but only on this machine.
Checking your mail from another box, it will look like your mail just
disappeared. Which is actually true since it is not on the server anymore.

Think this scenario is unrealistic? I for one often move a mail from my
inbox to another folder. And even more often press F5 in my inbox to
fetch new mail.

Here a second way, even funnier:

1) Move mail 1 (by dragging) from folder 1 to folder 2

The changes are not yet committed on the server! But KMail pretends to.

2) Rebuild cache on folder 2 (KMail will delete the just moved mail from
this folder since it's not present on server)

3) Refresh folder 1 with F5. KMail will remove the mail from the server
(which was not visible inside KMail)

Now you have effectively deleted mail mail 1 from KMail and the Server.

I'm sure there are many other ways to exploit this behavior. I've not
seen a single waring or error from KMail it just did what I say and
happily removed mail precious mails. I found another way to lose mails
in combination with two different boxes using the same accou...

[Sune Vuorela (debian-pusling)]

unmerge 350851
close 350851
unmerge 406258
forwarded 332473 http://bugs.kde.org/show_bug.cgi?id=114163
thanks

Hi Bastian

It seems like different bugs you are trying to refer to - and let us keep the
issues seperate instead of a giant metabug "kmail is a piece of shit" where
all info is posted.

Have you reported your findings to the correct bugs upstream?

You seem enjoying KDE bugs and we are a bit short of manpower in the kde team,
so we would welcome you in the team to help us with especially fixing these
bugs, but also the remaining 1300 bugs in kde in debian.

For debian we maybe would have to remove imap support from etch

Thanks in advance

Sune
 - on behalf of the team.
--
Man, do you know how could I do for reinstalling a connection?

First of all you neither should overclock the digital software to a device on
the firewall, nor can ever save a DirectGL server to boot from the clock.

[lickdragon (csights)]

After reading the way to reproduce this bug as outlined in
....
From: Bastian Venthur <email address hidden>
Subject: a way to reproduce KMail/DIMAP data loss
Date: Wed, 10 Jan 2007 13:41:17 +0100
..
 A suggested fix would be to prompt the user "Changes were made to the
disconnected IMAP cache. Commit changes to IMAP server?" -> "Yes" "No" when
exiting KMail. Maybe also have an explanation of the consequences. If "No"
is clicked just exit. If "Yes" is clicked show a bar indicating progress of
updating the IMAP server.
 The purpose of "No" is for those situations when the person is not connected
to the network and updating the server is not an option. (It would be nice
if possible connection to the server is checked automatically.)
 The purpose of "Yes" is to explicitly commit changes made in case the user
forgets about them. (I often check my mail CTRL-L one more time before
exiting to synchronize the cache and the server.)

 An analogy to what Bastian described would be if floppy disk drives had no
light on them: Everyone knows "don't eject the floppy until the light goes
off". If you do then the files might not be updated correctly. What KMail
needs is something similar to the light on the floppy disk.

Thanks !

[Ana Beatriz Guerrero López (ana)]

Hi,

A mail for the record of this bug: upstream (kdepim team) is having
a meeting this weekend [0], and they have added this problem on the agenda.

Ana

[0] http://www.kontact.org/news.php

[Sune Vuorela (debian-pusling)]

# Automatically generated email from bts, devscripts version 2.9.27
found 321102 4:3.5.5.dfsg.1-4
found 332473 4:3.5.5.dfsg.1-4
found 406258 4:3.5.5.dfsg.1-4

[Bastian Venthur (venthur)]

found 321102 4:3.5.5.dfsg.1-5
thanks

Hi,

One major argument against my previous two attempts to reproduce this
bug is, that I'm abusing KMails functions. F5 and "rebuild IMAP cache"
do exactly what they're supposed to do and it's not KMails fault if the
user loses mails when (ab)using this features.

I understand this point of view although I still disagree. But in oder
to protect our users I reproduced this bug again. This time by using
KMail "correctly".

Setup: This time I'm using two different accounts "foo" and "bar" and
move a mail from one account to the other.

(3) Delete mails by checking only one Account:

- Move a mail from foo's inbox to bar's inbox
No changes have yet been committed on the serverside

- now click "check mail in foo" (and only in foo)
KMail now removes the mail from foo's inbox but does not copy it into
bar's inbox.

- Close KMail
Check the mails on the serverside: one Mail is lost and it will be lost
until you restart this particular instance of KMail which can be in a
few minutes, days or never.

KMail leaves the state on the server in a broken state. Checking your
mail from another machine will look like you've just lost a mail. Maybe
the user will now use KMails "rescue" operations (F5 or rebuild the
cache) and therefor worsen the situation. If the user cannot start KMail
on the first machine for some reasons, it's mail will be lost forever.

(4) Delete mails by checking mail automatically:

You can even lose mails by don't doing anything. This chance is always
present when KMail does not check all available accounts together. Eg.
When you set "check mail automatically every x minutes" on account foo
and set "check mail automatically every y minutes" on account bar where
x < y then you're actually doing the same as in Example (3) just
automatically:

- Move a mail from foo's inbox to bar's inbox
No changes have yet been committed on the serverside

- Wait x minutes until KMail checks foo's mail
KMail now removes the mail from foo's inbox but does not copy it into
bar's inbox (until y minutes when KMail checks bar's mail)

- close KMail before it checked bar's mail,
Check the mails on the serverside: one Mail is lost and it will be lost
until you restart this particular instance of KMail which can be in a
few minutes, days or never.

Since I can already hear someone saying: "Oh, you're abusing KMail
again, just use CTRL-L to check all accounts as you're supposed to do!",
 here is my hopefully last part:

(5) Lose mails by unavailability of one server:

- Move a mail from foo's inbox to bar's inbox
No changes have yet been committed on the serverside

- Disconnect server bar (eg shutting bar's IMAP server down), to
simulate a broken connection to *one* of the two servers.

- Press CTRL-L (check all accounts -- the "right" way)
KMail now removes the mail from foo's inbox but does not copy it into
bar's inbox since bar's server is unavailable. It gives a warning that
the server is not available but does not mention that an pending
operation is currently broken.

- Close KMail
Check the mails on the serverside: one Mail is lost and it will be lost
until you restart this particular instance of KMail which can...

[Adam Porter (alphapapa)]

On Monday 15 January 2007 06:45, Bastian Venthur wrote:

> One last word about this bug: Bugs like this will always be reproducible
> until two-part actions like move mail from a to b (= copy mail from a to
> b, delete mail from a) are not handled somewhat atomic. In the current
> implementation KMail does not even try to do stuff like this atomic. If
> you fix this, then I think you will fix the bug.
>
> Summary: I've presented altogether five ways how certain situations in
> KMail can lead to data loss. I even was able to lose data by just
> justing CTRL-L like upstream suggests.
>
> All my examples might seem minimalistic and somewhat artificial, but
> please keep in mind that this is just in order to make the bug easy to
> reproduce! It's not hard to imagine how situations like this can happen
> to an average user on a more complicated setup.

Thank you, Bastian, for writing that. I think that is the best explanation
I've seen so far.

I'm not sure if doing dIMAP atomically would make sense; that sounds like
regular, online IMAP to me. The whole point of dIMAP is to make changes
offline and then sync them all at once. (Although the reason I use dIMAP is
merely to keep an offline copy of my IMAP mail for backup. I would love a
hybrid IMAP mode that would keep a local copy of all messages, and make
changes live on the server as you make them when you are online, but queue
changes for later syncing when you're in offline mode [and KMail even has
an "offline mode" option]).

I think a good workaround would be for KMail to keep track of whether it has
unsynced changes, and warn the user if he tries to close KMail or log out
before syncing the changes. It would also be nice if the connection
timeout/retry code was made more robust to cope better with times where the
server or connection to it goes down. Just yesterday I had some timeouts
while uploading a large message to the server after moving it from one folder
to another (why can't it just tell the server to move the message, rather
than uploading it again?), and the process didn't finish until I stopped and
resynced a couple of times, because KMail didn't timeout and retry on its
own.

Perhaps the real solution is to get rid of a separate disconnected/offline
IMAP mode and make a single, hybrid IMAP mode. When you're online, it should
make changes on the server as you make them locally. When you're offline, it
should queue changes for later syncing, and warn the user if he quits or logs
out without syncing them. And whether you're online or offline, it should
have an option to keep local copies of all messages.

[Bastian Venthur (venthur)]

Hi Adam,

Adam Porter schrieb:
> I'm not sure if doing dIMAP atomically would make sense; that sounds like
> regular, online IMAP to me. The whole point of dIMAP is to make changes
> offline and then sync them all at once. (Although the reason I use dIMAP is

Atomic means that an operation which consists of more than one atomic
step must follow the all-or-nothing principle. This means if one of the
steps fail, it must undo all other involved steps.

This does not contradict the way how DIMAP works. In fact it's still
perfectly possible to delay/queue the move operation when in offline
mode, but *when* the operation happens, it has to be atomic. This is the
only way to guarantee that the data keeps consistent and no data is lost.

An example: moving a mail consists of two steps: KMail has to copy the
file from A to B and remove the remaining file on A. If one part of
"move" fails, then you have either a duplicated file on the source- and
the target folder (delete fails) or your file is lost (copy fails).

If one of those two steps fails the other has to be undone in order to
keep the data consistent.

If it's not possible to implement move to be atomic it should be at
least guaranteed that no file is *lost* (eg. copy first and delete
afterwards). A duplicated file is a problem the user can cope with a
deleted is not.

One main problem of this bug is that the user does not actually *notice*
that his mail is lost when an accident happens. He moves a mail, sees
the desired result inside of KMail but does not know that actually his
mail is already gone on the server side. This makes the bug so dangerous.

Cheers,

Bastian

--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org

[Josh Metzler (joshdeb)]

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)

[Bastian Venthur (venthur)]

tags 321102 patch
thanks

Hi,

please consider the following patch. It disables DIMAP by simply
removing the DIMAP option when creating a new account, making it
impossible to create a new DIMAP account. Regular IMAP is still
perfectly possible.

In order to protect users with existing DIMAP accounts, it also pops up
a warning whenever KMail gets started and detects an DIMAP account.

The patch does not disable DIMAP itself. In fact it does not even touch
the DIMAP code. So other PIM components using DIMAP internally should
not be affected.

I've tested the patch and it seems to work fine.

The patch itself is very small: there are currently two ways to create a
DIMAP account, 1) the regular way and 2) when you start KMail the first
time an the wizard pops in. I've disabled the gui-Elements for the
DIMAP-options in both cases.

The second part of the patch is for the popup. Every time KMail starts
and detects a DIMAP account the popup with a warning is shown.

I think this patch is a good compromise. It does not really fix the bug,
but prevents the user from using DIMAP. IMHO it's better and cleaner
this way than just closing the bug by documenting it.

Cheers,

Bastian

--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org

[Helmut Toplitzer (bgrpt)]

Please add something like
"don't show warning again"
to the patch. Using the workgroup
functions on dimap will be really
annoying otherwise.

Thx.
Helmut

[Bastian Venthur (venthur)]

Am 19.01.2007 15:46 schrieb Helmut Toplitzer:
> Please add something like
> "don't show warning again"
> to the patch. Using the workgroup
> functions on dimap will be really
> annoying otherwise.

The popup will *only* kick-in when you have a DIMAP-(mail)-account.
Using regular IMAP with workgroup-functions enabled, does not produce
the popup.

There is BTW a bug in KMail when it tries to create those
workgroup-folders on the server (a nasty warning about folders not found
on the server) -- this is not related to my patch! I noticed this bug
before (my patch) when I tried to reproduce the mailloss. It happens
with DIMAP and IMAP.

Cheers,

Bastian

--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org

[Helmut Toplitzer (bgrpt)]

>
> The popup will *only* kick-in when you have a DIMAP-(mail)-account.
> Using regular IMAP with workgroup-functions enabled, does not produce
> the popup.

I'm using dimap with workgroup functions for 2 years now.
Without problems. (It's easy if you know what NOT to do)

Otherwise workgroup functions are not useable without connection.

So please educate and don't annoy existing users.
This is a problem which existed in all dimap implementations till now
and is not a reason to kick existing users in the a....

I understand your concerns but a warning everytime you start
kmail is not the right answer to this. So please make it
possible to disable the warning.

Thx.
Helmut

[Bastian Venthur (venthur)]

Am 19.01.2007 16:37 schrieb Helmut Toplitzer:
>> The popup will *only* kick-in when you have a DIMAP-(mail)-account.
>> Using regular IMAP with workgroup-functions enabled, does not produce
>> the popup.
>
> I'm using dimap with workgroup functions for 2 years now.
> Without problems. (It's easy if you know what NOT to do)

Yes, I agree. But that's also the problem. If you know what not to do,
then it might be possible to work with DIMAP without ever losing mails.
But looking at bugs.kde.org and searching for KMail bugs about mail loss
related to DIMAP reveals another truth: the users are not aware of those
bugs.

We could deliver KMail with DIMAP enabled, but then we'd have to make
sure that every user who's trying to create an DIMAP account is aware of
the risks. And by aware I mean that KMail must proactively provide this
information when trying to create such an account -- not just a file
hidden somewhere under /usr/share/doc. And every existing DIMAP user
should be at least once reminded that DIMAP is potentially unsafe for
production use.

But even if we could provide appropriate warnings, we'd still deliver
buggy and potentially harmful software in Debian stable...

I'd prefer to disable DIMAP completely -- better to cut down a single
feature than to expose our users to the risk of data loss. But that's
just my opinion and I'm not a KDE-maintainer.

Cheers,

Bastian

--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org

[Debian Qt/KDE Maintainers (debian-qt-kde)]

Source: kdepim
Source-Version: 4:3.5.5.dfsg.1-6

We believe that the bug you reported is fixed in the latest version of
kdepim, which is due to be installed in the Debian FTP archive:

akregator_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/akregator_3.5.5.dfsg.1-6_i386.deb
kaddressbook_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kaddressbook_3.5.5.dfsg.1-6_i386.deb
kalarm_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kalarm_3.5.5.dfsg.1-6_i386.deb
kandy_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kandy_3.5.5.dfsg.1-6_i386.deb
karm_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/karm_3.5.5.dfsg.1-6_i386.deb
kdepim-dbg_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kdepim-dbg_3.5.5.dfsg.1-6_i386.deb
kdepim-dev_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kdepim-dev_3.5.5.dfsg.1-6_i386.deb
kdepim-doc-html_3.5.5.dfsg.1-6_all.deb
  to pool/main/k/kdepim/kdepim-doc-html_3.5.5.dfsg.1-6_all.deb
kdepim-doc_3.5.5.dfsg.1-6_all.deb
  to pool/main/k/kdepim/kdepim-doc_3.5.5.dfsg.1-6_all.deb
kdepim-kfile-plugins_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kdepim-kfile-plugins_3.5.5.dfsg.1-6_i386.deb
kdepim-kio-plugins_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kdepim-kio-plugins_3.5.5.dfsg.1-6_i386.deb
kdepim-kresources_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kdepim-kresources_3.5.5.dfsg.1-6_i386.deb
kdepim-wizards_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kdepim-wizards_3.5.5.dfsg.1-6_i386.deb
kdepim_3.5.5.dfsg.1-6.diff.gz
  to pool/main/k/kdepim/kdepim_3.5.5.dfsg.1-6.diff.gz
kdepim_3.5.5.dfsg.1-6.dsc
  to pool/main/k/kdepim/kdepim_3.5.5.dfsg.1-6.dsc
kdepim_3.5.5.dfsg.1-6_all.deb
  to pool/main/k/kdepim/kdepim_3.5.5.dfsg.1-6_all.deb
kitchensync_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kitchensync_3.5.5.dfsg.1-6_i386.deb
kleopatra_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kleopatra_3.5.5.dfsg.1-6_i386.deb
kmail_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kmail_3.5.5.dfsg.1-6_i386.deb
kmailcvt_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kmailcvt_3.5.5.dfsg.1-6_i386.deb
knode_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/knode_3.5.5.dfsg.1-6_i386.deb
knotes_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/knotes_3.5.5.dfsg.1-6_i386.deb
kode_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kode_3.5.5.dfsg.1-6_i386.deb
konsolekalendar_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/konsolekalendar_3.5.5.dfsg.1-6_i386.deb
kontact_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kontact_3.5.5.dfsg.1-6_i386.deb
korganizer_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/korganizer_3.5.5.dfsg.1-6_i386.deb
korn_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/korn_3.5.5.dfsg.1-6_i386.deb
kpilot_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/kpilot_3.5.5.dfsg.1-6_i386.deb
ksync_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/ksync_3.5.5.dfsg.1-6_i386.deb
ktnef_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/ktnef_3.5.5.dfsg.1-6_i386.deb
libindex0-dev_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/libindex0-dev_3.5.5.dfsg.1-6_i386.deb
libindex0_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/libindex0_3.5.5.dfsg.1-6_i386.deb
libkcal2-dev_3.5.5.dfsg.1-6_i386.deb
  to pool/main/k/kdepim/libkcal2-dev_3.5.5.dfsg....

[Sune Vuorela (debian-pusling)]

On Friday 19 January 2007, Bastian Venthur wrote:
> please consider the following patch. It disables DIMAP by simply
> removing the DIMAP option when creating a new account, making it
> impossible to create a new DIMAP account. Regular IMAP is still
> perfectly possible.

As dimap works when you know its limitations, the attached patch is the way we
are about to go.

(when creating a account, a warning is shown)

/Sune

--
How to forward to the floppy disk?

You must boot from the laser e-mail of the file to debug a server.

[Debian Qt/KDE Maintainers (debian-qt-kde)]

Source: kdepim
Source-Version: 4:3.5.6.dfsg.1-1

We believe that the bug you reported is fixed in the latest version of
kdepim, which is due to be installed in the Debian FTP archive:

akregator_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/akregator_3.5.6.dfsg.1-1_i386.deb
kaddressbook_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kaddressbook_3.5.6.dfsg.1-1_i386.deb
kalarm_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kalarm_3.5.6.dfsg.1-1_i386.deb
kandy_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kandy_3.5.6.dfsg.1-1_i386.deb
karm_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/karm_3.5.6.dfsg.1-1_i386.deb
kdepim-dbg_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kdepim-dbg_3.5.6.dfsg.1-1_i386.deb
kdepim-dev_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kdepim-dev_3.5.6.dfsg.1-1_i386.deb
kdepim-doc-html_3.5.6.dfsg.1-1_all.deb
  to pool/main/k/kdepim/kdepim-doc-html_3.5.6.dfsg.1-1_all.deb
kdepim-doc_3.5.6.dfsg.1-1_all.deb
  to pool/main/k/kdepim/kdepim-doc_3.5.6.dfsg.1-1_all.deb
kdepim-kfile-plugins_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kdepim-kfile-plugins_3.5.6.dfsg.1-1_i386.deb
kdepim-kio-plugins_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kdepim-kio-plugins_3.5.6.dfsg.1-1_i386.deb
kdepim-kresources_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kdepim-kresources_3.5.6.dfsg.1-1_i386.deb
kdepim-wizards_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kdepim-wizards_3.5.6.dfsg.1-1_i386.deb
kdepim_3.5.6.dfsg.1-1.diff.gz
  to pool/main/k/kdepim/kdepim_3.5.6.dfsg.1-1.diff.gz
kdepim_3.5.6.dfsg.1-1.dsc
  to pool/main/k/kdepim/kdepim_3.5.6.dfsg.1-1.dsc
kdepim_3.5.6.dfsg.1-1_all.deb
  to pool/main/k/kdepim/kdepim_3.5.6.dfsg.1-1_all.deb
kdepim_3.5.6.dfsg.1.orig.tar.gz
  to pool/main/k/kdepim/kdepim_3.5.6.dfsg.1.orig.tar.gz
kitchensync_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kitchensync_3.5.6.dfsg.1-1_i386.deb
kleopatra_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kleopatra_3.5.6.dfsg.1-1_i386.deb
kmail_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kmail_3.5.6.dfsg.1-1_i386.deb
kmailcvt_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kmailcvt_3.5.6.dfsg.1-1_i386.deb
knode_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/knode_3.5.6.dfsg.1-1_i386.deb
knotes_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/knotes_3.5.6.dfsg.1-1_i386.deb
kode_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kode_3.5.6.dfsg.1-1_i386.deb
konsolekalendar_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/konsolekalendar_3.5.6.dfsg.1-1_i386.deb
kontact_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kontact_3.5.6.dfsg.1-1_i386.deb
korganizer_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/korganizer_3.5.6.dfsg.1-1_i386.deb
korn_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/korn_3.5.6.dfsg.1-1_i386.deb
kpilot_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/kpilot_3.5.6.dfsg.1-1_i386.deb
ksync_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/ksync_3.5.6.dfsg.1-1_i386.deb
ktnef_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/ktnef_3.5.6.dfsg.1-1_i386.deb
libindex0-dev_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/libindex0-dev_3.5.6.dfsg.1-1_i386.deb
libindex0_3.5.6.dfsg.1-1_i386.deb
  to pool/main/k/kdepim/libindex0_3.5.6.dfsg.1-1_i386.d...

[Sarah Kowalik (hobbsee-deactivatedaccount)]

kde 3.5.6 is about to be put in feisty, marking as released.