My KDE week

Archive for March 2012

There are annoying bugs and there are data loss bugs. The problem with the latter is that if people notice them it’s already too late. So I would like to collect all the data loss bugs for KDE PIM in order to attract testers and help debugging them, i.e. find a way for developers to re-produce them reliably.

Also, knowing what can cause data loss enables users to work around these scenarios and hence saves a lot of anger towards the devs.

So please point me to data loss bugs and test those listed already. If bugs are re-producible and confirmed by several users using different distros they are more likely to get fixed. Please do not add another “me too” to bug reports which already have a confirmation for your distro! Please do only test with current packages, i.e. akonadi 1.7.1 and KDE PIM 4.8.1.

Bug 293768

Symptoms: body and attachments are lost.

How to reproduce: Disconnect network while akonadi is downloading an email to move it to a local folder.

  1. Send a very large (long time to download is needed) email to your online imap account.
  2. Click on the email to make kmail display the “loading screen” in the preview pane.
  3. Press DEL to move the email to the local trash.
  4. While akonadi/kmail are still downloading, disconnect the network, e.g. open the networkmanagement plasmoid and untick the “enable network” checkbox.
  5. The email you deleted was moved to the trash as soon as the network got disconnected, even though downloading was not finished. Hence the email in the trash lost its body and attachments.

Bug 295484

Symptoms: Body and attachments lost when piping through external application and adding headers.

How to reproduce: Filter incoming emails through an external app which adds headers.

  1. Create spam filtering rules for spamassasin (or bogofilter) via kmail’s wizard.
  2. Make sure they are applied to your imap’s inbox.
  3. If possible open your imap account in a webmail interface.
  4. Wait for new email to arrive and check with the webmail interface how the email is replaced. Do not read it, since the bug is not re-producible with read email or by applying filters manually.
  5. After akonadi/kmail has filtered the email and added the anti-spam tool’s header, open it in both kmail and the webmail interface. Both show that the body and attachments are gone.
  6. For bogofilter you have to train it first (marking emails as spam and ham) in order for it to actually add any headers, i.e. trigger the bug.

Bug 286043

Symptoms: Headers as well as body and attachments are lost.

How to re-produce: This bug was not tested yet with recent packages and does not state a way to re-produce, so if you know how, please add it.

Bug 281704

Symptoms: Emails lost if KDE PIM is closed while copying from imap to imap.

How to reproduce: Copy/move an imap  folder and close kmail while the transaction is still in progress.

IMO this could be a duplicate of bug 293768.

With one day delay, due to some fixes in KDEPIM, KDE SC 4.8.1 got released and openSUSE packages can be found in the KDE:Release:48 (KR48) repo. Akonadi willl be updated to 1.7.1 shortly in order to fix a possible data loss bug when copying/moving emails.

Potential data loss bug in akonadi filtering

I got a new mail loss bug with 4.8.1 when using bogofilter, set-up via the kmail wizard, on new emails arriving in an imap inbox. As I can see via my webmail interface, they get the bogosity header added and are then written back to the server, i.e. the “old” email is deleted and the new one (including a new date and time)  added. Problem is, the new one is empty, i.e. lost all its content but the to/from etc. I can reproduce it, i.e. enabling that filter rule causes the issues, disabling it solves it. It only happens on arriving emails, i.e. I cannot re-produce it by applying the filter manually. Maybe akonadi 1.7.1 fixes it, maybe it is that moving/copying bug the NEWS file mentions. It might be a “personal” bug, i.e. only happening to me, yet you have been warned!

UPDATE: Unfortunately this mail loss bug does neither only happen to me nor is it fixed with akonadi 1.7.1.

UPDATE2: There seems to be another very annoying bug introduced with 4.8.1 which makes kmail2 crash a lot for some people. I do not experience that one although nepomuk and email indexing is enabled in general. Maybe because I disabled it for my imap’s inbox via right-click > folder properties > maintenance. So you can try to disable nepomuk and/or disable some folders’ indexing.

Update instructions

Instructions on how to update KDE are available on the openSUSE wiki. As well as the corresponding repos available in case you need apps from Extra or Playground. Remember, never mix the KDE:UpdatedApps repo or any other repo meant for plain openSUSE 12.1 with KR48, i.e. read the warning on the wiki!

How to know when packages are ready

There have been many asking when packages for 4.8.1 will be available and how one should know when they are ready. Actually that’s quite simple.

a) Easiest method: Wait until the packages are announced on the opensuse-kde mailinglist.

b) Other method:

  1. Check http://www.kde.org for a release announcement.
  2. Check whether all packages built successfully and got published. The latter is indicated by the loaded lorry icon at the top of the package table.
  3. You can also check whether publish flags are on. Before a new release building might already have finished but packages might not get published yet.
  4. Know what you are doing since without any announcement it could still be the case that disabling publishing was simply forgotten and even though published, packages are not ready for use yet – i.e. better stick to a).

Build numbers vs. changed content

Regarding updates many users confuse build numbers vs. changed package content. If the package management shows that updated packages are available it does not necessarily mean that the content of the package changed, i.e. it could be that it is just a re-build and thus has a higher build number. E.g. kdebase4-workspace-4.8.1-40.i586.rpm does not necessarily contain any updates compared to kdebase4-workspace-4.8.1-4.i586.rpm.

How to know whether a package has changed

If you want to know what/whether a package has changed, you can have a look at the package’s sources, which lists the latest revision comment at the bottom or a package’s revision log, which lists all revisions. These are available in the toolbar at the top after you clicked on a package.

If a package is just a link to another package you can find the original package via the link at the package’s source view.