[kontact] [Bug 402623] Cannot start flatpak on non KDE desktop environments
https://bugs.kde.org/show_bug.cgi?id=402623 --- Comment #5 from Bug Janitor Service --- Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 419929] kmail closes after setting trash folder
https://bugs.kde.org/show_bug.cgi?id=419929 Erick Osorio changed: What|Removed |Added CC||evgom@gmail.com --- Comment #1 from Erick Osorio --- Same problem from long time ago. The bug still in Kmil 20.12.2. Not always happen, but is almost every time, with many accounts configured. Just set trash folder and restart kmail. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 433270] New: Cannot change default aggregation/theme on a specific folder
https://bugs.kde.org/show_bug.cgi?id=433270 Bug ID: 433270 Summary: Cannot change default aggregation/theme on a specific folder Product: kmail2 Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: message list Assignee: kdepim-bugs@kde.org Reporter: godlik...@gmail.com Target Milestone: --- Whenever I try to change the default aggregation or theme on a specific folder to override the default, nothing happens. The folder refreshes exactly as it was. Going to the folder properties again, it shows the unchanged setting. No matter how many times this is done, it does not affect the message list. STEPS TO REPRODUCE 1. Right click on a folder -> Folder properties 2. Go to the View tab. Change either the aggregation or theme by unchecking the relevant checkbox and selecting anything from the combobox. 3. Click OK. OBSERVED RESULT 1. Folder refreshes as it was. No change performed. 2. Go back to Folder properties -> view 3. Settings are as their default; no changes were performed, despite changing settings and clicking OK. EXPECTED RESULT Changes to the default aggregation/theme of a folder should take place and be saved properly. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo Linux - KDE Applications 20.12.2 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION This is happening on 5.16.2 (as reported by help -> about kontact) but the version selector here in the bugzilla does not have it as an available version. It does not seem to matter how many messages are in a folder. Can reproduce this on a folder with 68 messages as well as one with over 130k messages. Also this was a fresh installation after >1 year of not using Kontact/Kmail. No settings of any kind related to Kmail/Akonadi/similar packages were on this system. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 433253] New: Folder list shows unread messages but filter doesn't
https://bugs.kde.org/show_bug.cgi?id=433253 Bug ID: 433253 Summary: Folder list shows unread messages but filter doesn't Product: kmail2 Version: 5.15.1 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: folders Assignee: kdepim-bugs@kde.org Reporter: c...@mail.3d.hu Target Milestone: --- Created attachment 135904 --> https://bugs.kde.org/attachment.cgi?id=135904=edit A screenshot showing the problem: folder list shows 2 unread messages but when I filter the messate list for unread messages, nothing shows up SUMMARY See the attached screenshot. The folder list shows 2 unread messages but filtering reveals none. This happened a few times already, and then it goes away somehow. STEPS TO REPRODUCE Don't know; jut using Kmail randomly ends up in a situation like this. OBSERVED RESULT Number of unread messages is inconsistent with the message list. EXPECTED RESULT Filtering the message list for unread messages should give exactly the same number of results as indicated by the folder. SOFTWARE/OS VERSIONS Operating System: Kubuntu 20.10 KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.14.2 Kernel Version: 5.8.0-43-generic OS Type: 64-bit -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433252] New: akonadi_pop3_resource, signal: Segmentation fault - POPSession::getSlave (this=0x7f8db403c750) at /usr/src/debug/kdepim-runtime-20.04.2-lp152.1.1.x86_64/resources/pop3/jobs
https://bugs.kde.org/show_bug.cgi?id=433252 Bug ID: 433252 Summary: akonadi_pop3_resource, signal: Segmentation fault - POPSession::getSlave (this=0x7f8db403c750) at /usr/src/debug/kdepim-runtime-20.04.2-lp152.1.1.x86_64 /resources/pop3/jobs.cpp:171 Product: Akonadi Version: unspecified Platform: openSUSE RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: POP3 Resource Assignee: kdepim-bugs@kde.org Reporter: bugrprt21...@online.de CC: aa...@kde.org Target Milestone: --- Application: akonadi_pop3_resource (5.14.2 (20.04.2)) Qt Version: 5.12.7 Frameworks Version: 5.71.0 Operating System: Linux 5.3.18-lp152.63-default x86_64 Windowing system: X11 Distribution: openSUSE Leap 15.2 -- Information about the crash: - What I was doing when the application crashed: Nothing - I had manually checked for Mail in the POP3 resources - there were messages that the resources were being automatically checked and, therefore, a second check could not be started . . . -- Backtrace: Application: DCu-Postfach (akonadi_pop3_resource), signal: Segmentation fault [KCrash Handler] #4 std::__atomic_base::load (__m=std::memory_order_relaxed, this=0x1c) at /usr/include/c++/7/bits/atomic_base.h:396 #5 QAtomicOps::load (_q_value=...) at /usr/include/qt5/QtCore/qatomic_cxx11.h:227 #6 QBasicAtomicInteger::load (this=0x1c) at /usr/include/qt5/QtCore/qbasicatomic.h:103 #7 QWeakPointer::data (this=0x7f8db403c760) at /usr/include/qt5/QtCore/qsharedpointer_impl.h:569 #8 QPointer::data (this=0x7f8db403c760) at /usr/include/qt5/QtCore/qpointer.h:86 #9 QPointer::operator KIO::Slave* (this=0x7f8db403c760) at /usr/include/qt5/QtCore/qpointer.h:92 #10 POPSession::getSlave (this=0x7f8db403c750) at /usr/src/debug/kdepim-runtime-20.04.2-lp152.1.1.x86_64/resources/pop3/jobs.cpp:171 #11 LoginJob::slaveConnected (this=0x56166fc1b1c0, slave=0x56166fa871f0) at /usr/src/debug/kdepim-runtime-20.04.2-lp152.1.1.x86_64/resources/pop3/jobs.cpp:289 #12 0x7f8dd41bfe35 in QMetaObject::activate (sender=0x7f8db4031940, signalOffset=, local_signal_index=, argv=) at kernel/qobject.cpp:3804 #13 0x7f8dd5d1927f in KIO::Scheduler::slaveConnected(KIO::Slave*) () from /usr/lib64/libKF5KIOCore.so.5 #14 0x7f8dd41bfe35 in QMetaObject::activate (sender=0x56166fa871f0, signalOffset=, local_signal_index=, argv=) at kernel/qobject.cpp:3804 #15 0x7f8dd5ce0f9e in KIO::SlaveInterface::dispatch(int, QByteArray const&) () from /usr/lib64/libKF5KIOCore.so.5 #16 0x7f8dd5cde2e8 in KIO::SlaveInterface::dispatch() () from /usr/lib64/libKF5KIOCore.so.5 #17 0x7f8dd5ce5941 in KIO::Slave::gotInput() () from /usr/lib64/libKF5KIOCore.so.5 #18 0x7f8dd41bff4f in QtPrivate::QSlotObjectBase::call (a=0x7ffc69cca780, r=0x56166fa871f0, this=0x56166fc24bb0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:394 #19 QMetaObject::activate (sender=0x56166fa40ab0, signalOffset=, local_signal_index=, argv=) at kernel/qobject.cpp:3784 #20 0x7f8dd41c09e2 in QObject::event (this=0x56166fa40ab0, e=) at kernel/qobject.cpp:1261 #21 0x7f8dd47e7f2c in QApplicationPrivate::notify_helper (this=this@entry=0x56166f85a680, receiver=receiver@entry=0x56166fa40ab0, e=e@entry=0x7f8db403bf10) at kernel/qapplication.cpp:3701 #22 0x7f8dd47ef540 in QApplication::notify (this=0x7ffc69ccae00, receiver=0x56166fa40ab0, e=0x7f8db403bf10) at kernel/qapplication.cpp:3447 #23 0x7f8dd4190328 in QCoreApplication::notifyInternal2 (receiver=0x56166fa40ab0, event=0x7f8db403bf10) at kernel/qcoreapplication.cpp:1088 #24 0x7f8dd41904fe in QCoreApplication::sendEvent (receiver=, event=event@entry=0x7f8db403bf10) at kernel/qcoreapplication.cpp:1476 #25 0x7f8dd4192ee7 in QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x56166f876350) at kernel/qcoreapplication.cpp:1825 #26 0x7f8dd4193488 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1679 #27 0x7f8dd41edd93 in postEventSourceDispatch (s=0x56166f9c2200) at kernel/qeventdispatcher_glib.cpp:276 #28 0x7f8dcdd534a4 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #29 0x7f8dcdd53840 in ?? () from /usr/lib64/libglib-2.0.so.0 #30 0x7f8dcdd538cc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #31 0x7f8dd41ed3af in QEventDispatcherGlib::processEvents (this=0x56166f9c4ef0, flags=...) at kernel/qeventdispatcher_glib.cpp:422 #32 0x7f8dd418e57a in QEventLoop::exec (this=this@entry=0x7ffc69ccad50, flags=..., flags@entry=...) at kernel/qeventloop.cpp:225 #33 0x7f8dd4197780 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1389 #34 0x7f8dd6ac98bd in
[Akonadi] [Bug 421922] kde-apps/akonadi-{19.08.3,19.12.2} with dev-db/mysql-8.0.19{-r1} - error: 'Can't connect to local MySQL server through socket '/run/user/1000/akonadi/mysql.socket' (2)'
https://bugs.kde.org/show_bug.cgi?id=421922 Hannes Schweizer changed: What|Removed |Added CC|nilat...@gmx.net| -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 433244] New: notifications for e-mails and calendar reminders cannot be turned off
https://bugs.kde.org/show_bug.cgi?id=433244 Bug ID: 433244 Summary: notifications for e-mails and calendar reminders cannot be turned off Product: kontact Version: unspecified Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: summary Assignee: kdepim-bugs@kde.org Reporter: li...@omdao.com Target Milestone: --- SUMMARY Whatever I try to deactivate within Kontact or the KDE notification system settings always I get notifications for e-mails and calendar reminders. Also when I have closed Kontact. The cannot be turned off. This is molesting. Thanks for your all your efforts to make Kontact better. STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.10.13-2-MANJARO OS Type: 64-bit Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 433099] personalized mass mail function, serial e-mails individualized
https://bugs.kde.org/show_bug.cgi?id=433099 --- Comment #7 from Rüdiger --- I am using Kmail within Kontact. The information is pretty hided in the Tab Help, the last link: - introduction into kmail. This link should be moved in the first block below "Kontact introduction" as "Kmail introduction" And I believe it is better to have another link in Help: "About Kmail & What's new", if Kmail is active respectively for the other components. But it is up to you. Thanks anyway. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 433099] personalized mass mail function, serial e-mails individualized
https://bugs.kde.org/show_bug.cgi?id=433099 --- Comment #6 from Laurent Montel --- (In reply to Rüdiger from comment #5) > Fine. But if I look in any menu, I cannot find a link "new features"?? > > Maybe I should sugget to "Kontact" developers to implement a pop-up function > for new features. The best product has no value, if nobody knows about it. > > How do you think? nope as we removed this type of dialog as it's was old UI style. We have a "info" page in kmail for it. not necessary to create a dialog for it. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 --- Comment #10 from Antonio Rojas --- > Though I'm not sure I understand the concern. If pim devs don't pay > attention to the ABI then in what scenario would a distro not rebuild > everything? Or I guess to preempt the answer a bit, if distros can tell if > ABI was broken, why can't we, KDE, and bump the version when that happens. My current workflow is to manually test every out-of-release-service user after each major release, and rebuild stuff when necessary. I suppose bigger distros have resources to check for ABI breakage properly. I was assuming your alternative (b) would mean bumping the soversion on every release, including minor ones (using only the major version number wouldn't make sense given the date-based versioning that release service uses). But, given that PIM packages have a different internal version number from the release service version, (5.16.x currently), having 5.16 as the soversion would be a reasonable implementation of (b), so it only gets bumped on major releases. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 433090] zanshin fails with symbol lookup error in neon
https://bugs.kde.org/show_bug.cgi?id=433090 --- Comment #9 from Harald Sitter --- (In reply to Antonio Rojas from comment #8) > (In reply to Harald Sitter from comment #7) > > That may well be but then the soversion will still have to change. > > > > The only options for any library are: > > > > a) when ABI is broken the soversion is bumped > > b) nobody checks if ABI is broken and the soversion is directly tied to the > > release version e.g. the there is no libfoo.so.5 but only a > > libfoo.so.5.20.12.2 > > c) the library has no version, is considered private, and doesn't advertise > > itself for external use (install with NAMELINK_SKIP + no cmake config) > > > > One may pick any of the three. > > (b) would be a nightmare for packagers, we'd need to rebuild everything > after every bug fix release (note that this affects every PIM library, not > just akonadi) > For (c) it is too late, there is stuff using pim libraries already. > The right way is (a), but good luck trying to convince kdepim devs of that :) Heh. Distros can always opt out of b) and patch it to a) ;). Though I'm not sure I understand the concern. If pim devs don't pay attention to the ABI then in what scenario would a distro not rebuild everything? Or I guess to preempt the answer a bit, if distros can tell if ABI was broken, why can't we, KDE, and bump the version when that happens. The bottom line here is that proper so versioning is not the same as ABI stability. Just because pim doesn't care about ABI stability doesn't mean we should release clearly incorrectly versioned libraries. In particular when even our own software outside the release-service is using it, so the "oh but this library is not for third parties" excuse doesn't even fly here :| -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 433099] personalized mass mail function, serial e-mails individualized
https://bugs.kde.org/show_bug.cgi?id=433099 --- Comment #5 from Rüdiger --- Fine. But if I look in any menu, I cannot find a link "new features"?? Maybe I should sugget to "Kontact" developers to implement a pop-up function for new features. The best product has no value, if nobody knows about it. How do you think? -- You are receiving this mail because: You are the assignee for the bug.
