So, I've tried again, this time restarting Akonadi when the migration script
said it was done. I tried two variations:
1) akonadictl restart before pressing ok on the window showing the kmail
resource migration. Surprisingly, this did not cause KMail to shut down. It
also didn't really work --
On Sunday 14 December 2014 21:35:45 Diane Trout wrote:
The migration bug is the one kmail bug I've been able to reproduce
repeteadly.
I have a work-around patch that basically does
akonadictl restart
when the migrator says Migration Done
Oh, I haven't followed that advice. I'll try
Finally got to it.
The upgrade was not smooth at all; the update script ended quickly enough, but
the real upgrade only happened when I opened KMail. I had the same experience
as last time -- KMail shows blank folders, nothing seems to be going on,
except if you look for it. At some point
The migration bug is the one kmail bug I've been able to reproduce repeteadly.
I have a work-around patch that basically does
akonadictl restart
when the migrator says Migration Done I've been hoping that upstream would
say if that's a reasonable work around.
I haven't figured out how to
I contacted Upstream and although they're too busy right now he offered this
clue, in response to my bug description.
Diane
[Diane]
With akonadiconsole under job tracker I can see a vast number of
SpecialCollectionsRequestJob's being scheduled and with the query browser
see a bunch of
Hi,
On Wednesday 26 November 2014 15:21:15 you wrote:
Hi! As Sandro pointed out, this seems fixed in newer versions. Can you
please test if this is still an issue for you?
I have no means to reconstruct the update as it was. I am using two systems:
One of them is a sid which I keep
On Saturday 29 November 2014 15:05:58 Shai Berger wrote:
Hi,
On Wednesday 26 November 2014 15:21:15 you wrote:
Hi! As Sandro pointed out, this seems fixed in newer versions. Can you
please test if this is still an issue for you?
[snip]
I can try to copy the user from testing to sid and
Shai: please also note Diane's workaround: maybe restarting akonadi after the
upgrade solves the issue.
That would be:
- Unlog from KDE
- Do the upgrade (in you case, create the new user and copy the data)
- Log in
Then wait some minutes, if you see the process doesn't ends open a console and
The sequence for me was:
* do the upgrade
* log in
* the knotes upgrade script runs
* the kmail2 upgrade script runs
* akonadi goes a bit crazy toward the end of the kmail 2
upgrade script, but the upgrade script does report
upgrade complete
* after the upgrade finished then I restarted
Some more details about trying to debug this:
I did akonadictl restart in a terminal so I could see log messages from
akonadi.
Then I ran /usr/bin/kmail-migrator --interactive
After a bit it started constantly printing:
akonadi_maildispatcher_agent($pid)/libakonadi: Resource id's don't
tag 727800 moreinfo
thanks
Hi! As Sandro pointed out, this seems fixed in newer versions. Can you please
test if this is still an issue for you?
Kinds regards, Lisandro.
--
Without us [Free Software developers], people would study computer science
and programming without ever having seen a
Control: reassign 727800 akonadi
Hey,
there are some newer versions and the bug you mentioned is marked as resolved
fixed.
The biggest issue with akonadi is, that older akonadi databases are often in
kind of a broken state (something like 1.10). That is/was not visible in (
KDE 4.9),
Package: kmail
Version: 4:4.10.5-2
Severity: grave
Justification: causes non-serious data loss
Dear Maintainer,
Today, following a safe-upgrade which updated the Qt4 libraries,
I found the whole KMail/Akonadi system quite broken.
I should note that, after the upgrade, I rebooted the system, as
13 matches
Mail list logo
