I and another fellow on irc downgraded to 5.1.42-7 , and it works better (no errors).

Hmph , has anybody reported this upstream to mysql.com?

Not yet, still investigating for details, not even 100% sure it's all mysql's fault, honestly.

all we know at this point is
akonadi-1.3.1 + mysql-5.1.43  = bad.

This upstream report looks a lot like what we're seeing,
http://bugs.mysql.com/bug.php?id=15547

but that doesn't seem specific to 5.1.43

15547 is ancient, but what is new in 5.1.43 is the patch for the linked report
http://bugs.mysql.com/bug.php?id=45058
I'll bet that broke it somehow.

I can do a build reversing that patch, and do some more testing.

Ugh, only parts of http://lists.mysql.com/commits/87152 seem to be applied in 5.1.53

Yeah, figuring out which patch actually got applied is often no fun with mysql.  I think they intentionally make their SCM not too transparent.

Keeping in mind that I know less than zip about akonadi --- could someone give me a step-by-step to reproduce this bug?

Sure.

0.  yum install akonadi

1.  make sure you have no existing ~/.local/share/akonadi dir.  (if exists, remove or rename)

2.  in terminal, 
$  akonadictl start

with the newer mysql-server, it fails to start and init the db giving errors per comment #1.

3.  (if you get akonadi to start),
$ akonadictl stop

then try repeating steps 1-3, with different mysql-server builds until success.

Created attachment 395215 [details]
Trial patch for this problem

Reverts the relevant changes between 5.1.42 and 5.1.43

I dug through the diff from 5.1.42 to 5.1.43 and extracted the parts that seemed to have to do with charset initialization.  This patch makes the problem go away for me, but I wonder if anyone else would like to try it?  Presumably it also brings back the issue that upstream hoped to fix in their bug 45058...

Thanks, I'll try to test that out today.

While I am not a Redhat user, I can confirm your patch addresses the issue. I was running into the same problems under FreeBSD with MySQL 5.5.1. Your patch applies cleanly to MySQL 5.5.1 as well and allows Akonadi to start normally. Thanks!

(In reply to comment #14)

5.5.1 broke too, huh?  I thought they'd just messed up the back-port to the 5.1.x branch.  Please report that at the upstream bug 45058.

(In reply to comment #15)

I reported upstream that this also happens with 5.5.1 earlier today. It seems that the code change in itself is causing a problem, across all branches of MySQL it was applied to.

I've added that patch to the just-completed build of 5.1.44; hopefully it will make things better.

mysql-5.1.44-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/mysql-5.1.44-1.fc12

mysql-5.1.44-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/mysql-5.1.44-1.fc13

mysql-5.1.44-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/mysql-5.1.44-1.fc11

mysql-5.1.44-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mysql'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-1922

I can confirm that with the patched mysql-server-5.1.44-1.fc12.x86_64 build, I
can no longer reproduce the problem described here.  Thanks!

mysql-5.1.44-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/mysql-5.1.44-2.fc13

mysql-5.1.44-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mysql'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-2470

mysql-5.1.44-2.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mysql'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-2519

mysql-5.1.44-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mysql'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-2547

I'm taking this off the blocker for the F11 and F12 KDE 4.4.0 updates as the MySQL in F11/F12 updates is fine and the one in F11/F12 updates-testing is now fixed too.

However, I had to add this to the F13Alpha blocker as the current MySQL in F13 Alpha is broken and this screws up the KDE spin. :-(

(mysql-5.1.44-2.fc13 has the fix, we need that build in the alpha.)

just to keep it on the public record, kevin tells me jesse is aware of this issue and will pull the fix into rc3.

it's a very borderline call on its actual alpha blocker-iness - per the criteria, we wouldn't necessarily consider a similar issue even in GNOME to be a blocker. but i'd certainly support including the fix if it's an obvious and relatively simple change that isn't likely to break anything else.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I'm prepared to push this stable if it gets another +1 karma.  But given mysql's recent track record a version update isn't necessarily a totally safe thing, so more testing would definitely make me feel better about it.

I've pulled mysql-5.1.44-2.fc13 into my side repo for the RC3 compose.

[ shrug... ]  Since apparently this will be in rc3 regardless of my concerns about stability, I might as well push it stable instead of having it go in through a back door.

Do you have a better suggestion wrt rc3?

1.  leave in 4.1.43 and keep the breakage outlined here
2.  patch 4.1.43 instead
3.  revert to 4.1.42
4.  ??

What I asked for was more people to test the package while it was in testing, like say more than one of the half dozen people subscribed to this bug report.  Doesn't seem that that's going to happen in any timely fashion, so I marked it stable.

If it makes you feel better, there were several other confirmations on irc (but I agree that getting the explicit bodhi +1's would've been nicer).

given the amount of confirmations mentioned by rex, and since this is blocking the alpha, let's close it. please re-open if there turn out to be problems.

if you want to confirm this you can fake up an alpha pre-rc3 KDE live build by using the KDE desktop .ks along with jesse's side repo, at http://alt.fedoraproject.org/pub/alt/stage/bleed/ . I'm doing this myself for the desktop spin to do some testing on that.

mysql-5.1.44-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

A patch has been committed to mysql that hopefully addresses this problem. Testing is appreciated.

Tom Lane: We use distributed revision control, a patch associated with a bug report might not be the merged patch due to code differences when merging between trees. To retrieve the exact path, use bzr to branch from launchpad and extract the exact revision (*).

http://forge.mysql.com/wiki/Bazaar

I'll try testing that out, provide feedback upstream.

upstream fix appears good, on initial testing.

For posterity, I'll attach the patch I used

Created attachment 396644 [details]
upstream patch for charset issue

replaces existing mysql-chartset-bug.patch

*** Bug 568844 has been marked as a duplicate of this bug. ***

mysql-5.1.44-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

mysql-5.1.44-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.