Description of problem: After fixing bug #27273, a lot of error messages were gone, this made it easier to see if/when this error message appeared: org.kde.pim.akonadicore: Received response with a different tag! This error message seems to appear when selecting a message in the email window which has an attachment included, and also some other emails but have not quite figured-out what may be the common problem with those other emails. Version-Release number of selected component (if applicable): mga8beta1 with updates upto today which include qtengine fixes that fixed #27273. How reproducible: all steps done in bug #27273....install classic mageia 32bit, clone an earlier email inbox, like for example inbox-2019 to ./loca/share/local-mail/inbox-2019/{cur/*, new/*, tmp/*}, then select various emails that contain attachments. This error message seems to trigger on first time email read, but not on second time email read. Steps to Reproduce: 1.Install mageia8beta1 classic install 2.add updates 3.add cloned email folder as per bug #27273 4.select various emails that contain attachments (below is for 3 unread emails) org.kde.pim.akonadicore: Received response with a different tag! org.kde.pim.akonadicore: Received response with a different tag! org.kde.pim.akonadicore: Received response with a different tag!
Plasma Applications updated to 20.08.1 and rebuilt against QT 5.15.1 / KF5 74. Does this still apply?
Keywords: (none) => NEEDINFO
latest updates - KDE and plasma working okay now. This problem still appears - at first I believed it was related only to new unread or untouched emails since some emails do not trigger this tag message a second time. However - I selected everything and marked everything as unread - and now notice that unread messages are also shown as a closed envelope, plus now also shows 305 unread messages in the left panel. I'll have to create a smaller sample email list and clone that to see what could be repeatable, but it does seem to be related to untouched emails.
tested further - with latest updates. different tag! error if .config/akonadi/akonadiserverrc uses MYSQL, but cannot get error to happen if user uses SQLITE3 most recent updates kmail does not create a proper directory if akonadi is using MSQL [test3@genesis ~]$ ls -l .local/share/local-mail/ total 12 drwxrwxr-x 2 test3 test3 4096 Sep 19 21:24 cur/ drwxrwxr-x 2 test3 test3 4096 Sep 19 21:24 new/ drwxrwxr-x 2 test3 test3 4096 Sep 19 21:24 tmp/ but for akonadi with SQLITE3 the directory is populated, plus able to read additional directory: [test4@genesis ~]$ ls -l .local/share/local-mail/ total 40 drwxrwxr-x 2 test4 test4 4096 Sep 19 21:15 cur/ drwxrwxr-x 5 test4 test4 4096 Sep 19 21:16 drafts/ drwxrwxr-x 5 test4 test4 4096 Sep 19 21:16 inbox/ drwx------ 5 test4 test4 4096 Sep 12 21:17 inbox-2019/ drwxrwxr-x 2 test4 test4 4096 Sep 19 21:15 new/ drwxrwxr-x 5 test4 test4 4096 Sep 19 21:15 outbox/ drwxrwxr-x 5 test4 test4 4096 Sep 19 21:15 sent-mail/ drwxrwxr-x 5 test4 test4 4096 Sep 19 21:16 templates/ drwxrwxr-x 2 test4 test4 4096 Sep 19 21:15 tmp/ drwxrwxr-x 5 test4 test4 4096 Sep 19 21:16 trash/
Thank you for your experiments. > org.kde.pim.akonadicore: Received response with a different tag! Can you please confirm that this error (if I understand it correctly) only happens when you select unread messages? [And you said above, only with MySQL, not SQLite3]. The question of what directories should be present is questionable. I have Kmail, unconfigured & never used: $ ls -l .local/share/local-mail/ total 20 drwxr-xr-x 2 lewis lewis 4096 Meh 26 16:27 cur/ drwxr-xr-x 2 lewis lewis 4096 Meh 26 16:27 new/ drwxr-xr-x 5 lewis lewis 4096 Meh 26 16:27 outbox/ drwxr-xr-x 5 lewis lewis 4096 Meh 26 16:27 sent-mail/ drwxr-xr-x 2 lewis lewis 4096 Meh 26 16:27 tmp/ but Kmail itself shows: inbox outbox sent-mail wastebin [trash] drafts templates If there is a real problem here, that would warrant a new bug. Aurelien is better qualified to comment on the akonadiserver database - unknown territory to me.
CC: (none) => lewyssmith
For importing mails, I suggest you to use Import Wizard from Tools menu in KMail.
CC: (none) => ouaurelien
Also, I'm sorry but SQLite is unsupported upstream to use in conjunction with Akonadi. See Closed bug https://bugs.mageia.org/show_bug.cgi?id=27286
After updating - I am able to use Kmail wizard with better success. Attaching 2 archives. These are basically emails that can be found in mailing lists, so nothing private to be concerned with. 1 - inbox-test.tar.gz 2 - Archive_inbox_test_2020-09-26.tar.gz For inbox-test.tar.gz use caution when expanding this archive, otherwise it will expand into your .kde4 directory. I suggest to expand it in your Document folder, or maybe simply use Dolphin and grab the last inbox{cur,tmp,new} and drag it to Document folder. You will notice the file names are directly from kmail1 maildir format. Dragging the entire inbox into .local/share/local-mail/ and then running kmail, it is quickly recognized as an inbox This version will have a few hits for "Received response with a different tag!" The second time touching the same email won't cause the message "Received response with a different tag!" For Archive_inbox_test_2020-09-26.tar.gz This was an archive created after touching every email, and then exporting this archive. Importing this archive into another new user creates no message "Received response with a different tag!" I also note the archive (generated by kmail2) has shorter file names like 1,2,3,....10 without the extra attribute(flags) attached on the file names as was carried by the kmail1 inbox tar.gz file I also noted now that having used kmail wizard that everything is imported into the database since nothing imported landed in .local/share/local-mail/* Kmail (patched/updated) is behaving much better now compared to mga8beta1 classic install (32bit). I'll take a look at some larger (kmail1 4.6.5) folders.
Created attachment 11890 [details] kmail1 (4.6.5) maildir test folder from .kde4/share/apps/kmail
Created attachment 11891 [details] kmail1 test folder imported to kmail2, exported from kmail2
Status of this?
Created attachment 12070 [details] snapshot of blacked-out area for preview (and also happens for email too). Hi Aurelien, I had not looked at this for a while, but I did load the latest patches, reboot, and then also used the 55k attachment (above). I expanded the inbox-test into ~/.local/share/apps/local-mail/ but noticed that kmail2 did not attempt to fetch the mail from that directory like the vanilla 8beta1, so I then used kmail wizard to fetch from the tar.gz version - which worked okay. On starting a command line and then re-running Kmail2, I did not see any org.kde.pim.akonadicore: Received response with a different tag! I do notice that I have a black preview pane as well as black email. I do notice that the message bar does toggle between "No HTML Message" and "Plain message", so I believe it is reading and understanding the messages, but not displaying them. In summary, seems kmail2 is fixed for the message: org.kde.pim.akonadicore: Received response with a different tag! I'll leave it for your best judgment on if this bug can be closed, and a new bug reported, or if you want to continue this bug with the new problem. Thanks for fixing the message.
I lost my battle to configure Kmail, to try the 'black' problem. The references to 'kmail2' are puzzling, we just have kmail, currently: kmail-20.08.3-1.mga8 > In summary, seems kmail2 is fixed for the message: > org.kde.pim.akonadicore: Received response with a different tag! I think it would be better to close this bug, and raise a new one for the black panels problem. If you do, please for all bugs always quote the exact package version, for example from '$ rpm -q kmail', and the Version(s) given in Help-About Kmail. Try a KDE forum first, to see whether other people have the same problem, or whether it really is a Mageia problem. And if you raise a new bug, an attached screenshot can be very helpful.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Hi Lewis, kmail1 existed in KDE3 and ran in Mageia1 - this was pretty-much the last version before the backend was converted from using kmail custom database to using akonadi connected to {mysql,sqlite,postgre} to hold data. kmail2 is also the reference on the kde.org website for this version that uses the akonadi backend. I am seeing the 'black' problem now, and started bug#27884 Reading your email right now to use 'rpm -q kmail' this problem exists for kmail-20.12.0-1.mga8 I'll try finding a similar issue on the kde.org bug list unless someone already knows of one right now. Thanks for the feedback.