Description of problem: Version-Release number of selected component (if applicable): akonadi-18.04.1-2.mga7.src.rpm How reproducible: Steps to Reproduce: 1. In terminal session, start kmail 2. Result: $ kmail Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) org.kde.pim.akonadiserver: Did not find MySQL server default configuration (mysql-global.conf) org.kde.pim.akonadiserver: Failed to remove runtime connection config file org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally... 3. Tried to start akonadi : $ akonadictl start Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) [mab@pc18 ~]$ org.kde.pim.akonadiserver: Did not find MySQL server default configuration (mysql-global.conf) org.kde.pim.akonadiserver: Failed to remove runtime connection config file org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally... 4. Check: $ locate mysql-global.conf /etc/akonadi/mysql-global.conf /usr/share/digikam/database/mysql-global.conf $ systemctl status mysqld Unit mysqld.service could not be found. # systemctl start mysqld Failed to start mysqld.service: Unit mysqld.service not found.
Assignee: bugsquad => kdeCC: (none) => marja11
CC: (none) => stephane.pontier
CC: (none) => bequimao.de
This bug also happens with other kde-apps which use akonadi, such as korganizer and kaddressbook.
CC: (none) => jimSource RPM: akonadi-18.04.1-2.mga7.src.rpm => akonadi-18.08.2-1.mga7.src.rpm
Is the package mariadb installed?
CC: (none) => geiger.david68210
seems to be: $ rpm -qa | grep mariadb mariadb-client-10.3.11-1.mga7 lib64mariadb-devel-10.3.11-1.mga7 mariadb-extra-10.3.11-1.mga7 mariadb-common-core-10.3.11-1.mga7 lib64mariadb3-10.3.11-1.mga7 mariadb-core-10.3.11-1.mga7 mariadb-common-10.3.11-1.mga7 mariadb-10.3.11-1.mga7 lib64mariadb18-10.1.28-1.mga7
On mga6, I also have lib64mariadb-embedded18, but there does not seem to be an equivalent package for cauldron.
Same problem on newly-installed Plasma Mageia-7-beta1-x86_64. (No such problem on Mageia-6.1)
M7beta1: akonadi-18.08.3-1.mga7 [I do not think this happened with Mageia 6]. (In reply to James Kerr from comment #1) > This bug also happens with other kde-apps which use akonadi, such as > korganizer and kaddressbook. These KDE programs (at least) want Akonadi in vain:- KJots KAlarm KMail/PIM Import KMail PIM setting exporter KAddressBook KOrganiser Some offer to start it, then like all the others, say: "The Akonadi personal information management service is not operational" below which is a "Details" button which does nothing. $ ps -ax | grep akonadi 21234 pts/0 S+ 0:00 grep --color akonadi I have raised the priority because so many applications, some significant, are blocked. I think the bug title could be clarified, but leave somebody nearer the centre to do that. This has nothing to do with databases (I think, unless there are two issues).
Priority: Normal => HighCC: (none) => lewyssmith
CC: (none) => curtis_mageia
M7 beta1 17 Dec 2018, Classic, 6 desktops, updated (1Gb, >1000 updates!). Running under Cinnamon from SDDM. *All* the KDE programs cited above now start correctly. So the problem seems to be fixed; thanks to whoever. I am closing the bug. If anybody objects, please re-open it. I will if other desktops still show the fault - which I do not expect.
Status: NEW => RESOLVEDResolution: (none) => FIXED
I'm sorry to say that - on my 64-bit Plasma install via classic iso and fully Cauldron-updated a few minutes ago and rebooted - Kmail still fails as described earlier (as does Kompozer: Bug 23628). No improvement here on Plasma install, so Re-opened.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
I see the same as Maurice @Lewis Do you have testing repo's enabled? A major update of QT5 and KF5 is in the course of being packaged. I think we should wait until those packages have been pushed to the release repo's before concluding definitively that this bug is fixed.
Keywords: (none) => 7beta1
Today's update to akonadi-18.12.0-2 has fixed this bug for me.
Although the akonadi update has enabled Kmail to start up apparently normally, it is still unusable here, because: (1) Although it has obviously picked up the maildir directory ~/mail (as it has the correct subfolders, each of which shows how many messages it contains), the Message-List and Message-Body panes are *empty* (even after several hours have passed during which Akonadi & Co might have been indexing the email DB). I suspect the indexing is simply not happening, so it seems there is a missing stage or two still. Will keep trying updates to see if the jigsaw completes itself... (N.B. Kompozer (bug 23628) is still a non-starter)
Akonadi works here now, too. The list of mailings of 2 IMAP accounts, one of these GMail, is not exposed either. I suggest to close this thread as fixed and open another one for better readability. IMO kompozer has no reference to KDE Plasma! Ulrich
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED
Kmail still unusable here on fully-updated Plasma5 Mageia-7 on nVidia desktop and also on Intel HP 450 Probook, although the situation is a big step forward from the previus 'cliff-edge' startup collapse. There seems to be some missing link between Kmail's multi-folder knowledge of the contents of the maildir ~/mail DB, and totally empty Message-List & Message-Body panes. Attempts to re-index the email DB do not succeed, even when left to run overnight, with zero evidence of improvement.
Out of curiosity, I cloned my Mageia-6.1 /home (which has a 100% working Kmail) onto Mageia-7, to see what its Kmail made of it: Not the slightest difference, despite the fact that the clone of Mga6.1 /home has a squeaky clean akonadi/.baloo DB: Mga7's Kmail opened correctly EXCEPT that the Message-List & Message-body panes remain empty, even though all the subfolders know how many messages each contains. So - a missing link between email DB and Kmail's listings in Message-List & Meaasge-Body panes...
Happy to report that with the advent of Kmail-18.12.1-2mga7 in today's Cauldron update on both desktop and laptop real hardware, Kmail is behaving normally and now displays in Header-Pane and Message-Pane. So far as I am concerned this bug can now be closed, thank godness. :-)
So time to fix this issue for mga6 too!
Status: RESOLVED => REOPENEDVersion: Cauldron => 6Resolution: FIXED => (none)Source RPM: akonadi-18.08.2-1.mga7.src.rpm => akonadi-17.12.2-1.mga6.src.rpmHardware: x86_64 => All
Assigning to QA, Advisory: ======================== Some users reported that kmail doesn't work properly. This come from some packaging issues and from some missing required dependencies. So this update fixes those issues. - akonadi: fix unavailable MySQL server default configuration - kmail require akonadi-mime (mga#24296) - kmail require kmailtransport - kmail recommend sasl2-plugin-kdexoauth2 (mga#23035) - kmail require ktnef, pim-sieve-editor and grantlee-editor ======================== Packages in 6/core/updates_testing: ======================== akonadi-17.12.2-1.1.mga6.x86_64.rpm lib64akonadiprivate5.x86_64.rpm lib64kf5akonadicore5.x86_64.rpm lib64kf5akonadiagentbase5.x86_64.rpm lib64kf5akonadiwidgets5.x86_64.rpm lib64kf5akonadixml5.x86_64.rpm lib64kf5akonadi-devel.x86_64.rpm kmail-17.12.2-1.1.mga6.x86_64.rpm ktnef-17.12.2-1.1.mga6.x86_64.rpm kmail-handbook-17.12.2-1.1.mga6.noarch.rpm lib64kmailprivate5-17.12.2-1.1.mga6.x86_64.rpm akonadi-17.12.2-1.1.mga6.i586.rpm libakonadiprivate5.i586.rpm libkf5akonadicore5.i586.rpm libkf5akonadiagentbase5.i586.rpm libkf5akonadiwidgets5.i586.rpm libkf5akonadixml5.i586.rpm libkf5akonadi-devel.i586.rpm kmail-17.12.2-1.1.mga6.i586.rpm ktnef-17.12.2-1.1.mga6.i586.rpm libkmailprivate5-17.12.2-1.1.mga6.i586.rpm Source RPM: ======================== akonadi-17.12.2-1.1.mga6.src.rpm kmail-17.12.2-1.1.mga6.src.rpm
Assignee: kde => qa-bugsKeywords: 7beta1 => 6.1Source RPM: akonadi-17.12.2-1.mga6.src.rpm => akonadi-17.12.2-1.mga6.src.rpm, kmail-17.12.2-1.mga6.src.rpm
No longer a problem here on either Mageia-6.1 or Magaei-7-beta2. Kmail working well on both now. Let's hope it stays that way...
@Maurice: first, thank you for all your work with this awkward problem. For Mageia *6*, can you confirm the version of the packages cited in comment 17. If everything works for you (perhaps already) with these updated pkgs, please MGA6-64-OK in Whiteboard, and Validate the update in Keywords.
> can you confirm the version of the packages cited in comment 17 There are a lot of packages cited there, Lewis! Which ones are you interested in? FYI, Urpmi has just confirmed that my Mageia-6.1 "Packages are up to date".
(In reply to Maurice Batey from comment #20) > Which ones are you interested in? If you do (M6): $ rpm -q kmail $ rpm -q akonadi you will see the essential, the other pkgs should conform. I currently see 17.12.2-1.mga6 for the two, pre-update.
I see: $ rpm -q kmail kmail-17.12.2-1.mga6 $ rpm -q akonadi akonadi-17.12.2-1.mga6
Whiteboard: (none) => MGA6-64-OKKeywords: (none) => validated_updateCC: (none) => sysadmin-bugs
I don't understand the procedure here in this bug report. It was a bugreport on Cauldron. I saw the Cauldron issues on my machine, too. I had no Mga6 issue that was not covered by another bug reports. Actually KMail, Akonadi, and Kontact are working fine. So I as a QA tester would not know what to test, except to test for regressions. The Mga6 side should have required a separate bug report. @ Maurice Pse do not set MGA6-64-OK and validated_update at the same time! Thus any other tester has no chance to object. It should require a few days. Best regards Ulrich
Keywords: validated_update => (none)
Ulrich, see request in Comment 19...
If it fix bug for Cauldron so it should simply do the same for mga6! Here with the bug 23035 we would simply ensure that kmail works properly! nothing more!
(In reply to Maurice Batey from comment #22) > I see: > $ rpm -q kmail > kmail-17.12.2-1.mga6 > $ rpm -q akonadi > akonadi-17.12.2-1.mga6 which shows that your M6 system does *not* include the update. This (& 23035) are both with QA to test. The fact that your system reports up-to-date is because both these updates have yet to be formally tested & pushed. I have removed the OK, it was not justified. See comment 19. @ Maurice: up to you now to test the formal update from Update Testing repo as per comment 17. And if you can do 23035 as well, please do. (In reply to Ulrich Beckmann from comment #23) > I don't understand the procedure here in this bug report. Yes, it is confusing. > I had no Mga6 issue that was not covered by another bug reports. Actually > KMail, Akonadi, and Kontact are working fine. So I as a QA tester would not > know what to test, except to test for regressions. Correct. > The Mga6 side should have required a separate bug report. Perhaps, but it is covered here now c17. > Pse do not set MGA6-64-OK and validated_update at the same time! > Thus any other tester has no chance to object. It should require a few days. If a test justifies the OK, the update will *not* normally be looked at again (except perhaps for the 'other' architecture). Validation is typically done when the last of required OKs is done. Due to QA workload, currently 1 mostly suffices. It can be un-done if somebody sees fit.
Whiteboard: MGA6-64-OK => (none)Keywords: 6.1 => (none)
> your M6 system does *not* include the update. This (& 23035) are both with QA > to test... I have removed the OK, it was not justified. Apologies for jumping gun... (Misunderstood what you wanted me to do.) > up to you now to test the formal update from Update Testing repo as per comment > 17. And if you can do 23035 as well, please do. Need to re-familiarise with Use of Updates Testing first... Cannot check 23035 as I do not use IMAP.
> up to you now to test the formal update from Update Testing repo > as per comment 17. P.S. Problem for me here: I don't have a 'Test' Mga6 install, and would not want to risk compromising my Production install of Mga6.1 with anything from Test - except as last resort (if no-one has a 'Test' Mga6) with appropriate backup and fingers crossed...
Blocks: (none) => 23035
OK Maurice, don(t worry. The two updates will soon be done by regular QA people. As for having a separate 'test' machine - I never have. The only real danger is an update that leaves the system unbootable. Otherwise, most updates that go wrong (rare) either do not update at all (safe), or can be 'undone' with $ urpmi --downgrade <packages>
Comment 26: > up to you now to test the formal update from Update Testing repo as per > comment 17. P.S. Which particular packages are we talking about here? Might be able to do something tomorrow...
> Might be able to do something tomorrow.. i.e. Mageia-6.1
Created attachment 10740 [details] List of installed packages I could now upgrade the list of packages sucessfully and will look for regressions. Ulrich
Can this update be validated, please?
No regression found. I tested several functions of akonadictl, too. Ulrich
Whiteboard: (none) => MGA6-64-OK
I think, waited enough time. Validating.
Keywords: (none) => validated_update
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2019-0013.html
Status: REOPENED => RESOLVEDResolution: (none) => FIXED