I installed the latest version of the mysql backend, however I was puzzled by the fact that you could install different backend at the same time. I thought that it would convert from one database to the other during the installation process, but no. I searched how to migrate from sqlite to mysql (I do not remember doing the mysql to sqlite migration in the first place), and stumbled upon https://dev.gnupg.org/T6862[1].
It looks like the existing akonadi migration is pretty useless and requires lots of manual work, and in the end is just not robust enough. I'd prefer having a solution for the current sqlite backend I use, because Korganizer is, as stated before, unusable in this state. Could I record some logs to see where the slowness comes from? Regards, Alexandre Bonneau Le lundi 13 janvier 2025, 15:46:51 UTC−10:00 Alexandre Bonneau a écrit : > Hello Patrick, > > Well, that's unfortunate. > > > Which database type are you using ? > > » dlg akonadi > rc akonadi-backend-mysql 4:22.12.2-1 > ii akonadi-backend-sqlite 4:24.12.0-2 > > I'm not sure why the migration to 24.12 used sqlite instead of mysql. Could > that explain the extremely slow response time in Korganizer? > > > Which calendar type are you using ? > > I'm using akonadi_davgroupware_resource_1 for a nextcloud-synchronized > calendar. > > I'll try to install akonadi-backend-mysql 24.12 and see if that fixes > anything > > Control: severity -1 important > > > > Hej, > > > > Am Montag, 13. Januar 2025, 23:50:06 MEZ schrieb Alexandre Bonneau: > > > Package: korganizer > > > Version: 4:24.12.0-3 > > > Severity: grave > > > Justification: renders package unusable > > > X-Debbugs-Cc: alexandre.bonn...@linuxfr.eu > > > > > > Dear Maintainer, > > > > > > * What led up to the situation? > > > > > > Last week (approx 2025-01-06) I updated Debian testing with all the > > > new akonadi, korganizer and kdepim6 packages. > > > > > > * What exactly did you do (or not do) that was effective (or > > > > > > ineffective)? > > > > > > Just updated, then rebooted (multiple times). > > > > > > * What was the outcome of this action? > > > > > > After the updated was applied, you can see Korganizer has changed a > > > bit, for instance the task description are now hidden by the endDate > > > time, while before you could read the task description (but that's > > > for another bug report). However the BIG problem here is that every > > > single action in korganizer (not in kmail) takes between 4 to 10 > > > seconds to execute. > > > You want to use the mousewheel on the mini-calendar view to switch > > > weeks ; 10 seconds wait time for _each_ week. > > > You want to edit a tasks by double-cliking it; 5 seconds of wait time. > > > Wait, there's more; once the task editor opens, you again have 3-4 > > > seconds of wait time before being able to edit it's description. > > > You want to move a task to another day/time, 5 seconds. > > > You want to create an event, 5 seconds. > > > You get the gist; it has become _unusable_; how could that pass for > > > unstable to testing, not sure. > > > > > > * What outcome did you expect instead? > > > > > > Each of the actions described above should be instant, like it has > > > always been for the last 20 years. > > > > > > > > > Please revert any patch applied during the last (two?) week so that > > > it's usable again. > > > > > > Thanks for your time and work > > > > I can absolutely not reproduce your observations. korganizer is as fast > > as ever for those actions you described for me. I suspect it's either > > something in your akonadi database or maybe some old config causing > > trouble. > > > > Which database type are you using ? > > Which calendar type are you using ? > > > > What you can do is create a new user on your system and see if you can > > observe a similar behaviour. > > > > And no, reverting the update to 24.12 is not an option. -------- [1] https://dev.gnupg.org/T6862
signature.asc
Description: This is a digitally signed message part.
