[neon] [Bug 388035] Cannot add EWS outbound transport in KMail

2021-03-15 Thread James Young 
https://bugs.kde.org/show_bug.cgi?id=388035

--- Comment #7 from James Young  ---
This is a KDE Neon-specific packaging issue so the status of this on Manjaro
Linux is unfortunately not relevant.

However, currently the Neon kmail package has kmailtransport-akonadi as a
'Recommends' soft dependency which should cause it to be installed under most
circumstances.

I still think this is wrong: if EWS support is installed at all,
kmailtransport-akonadi should be a hard dependency.  If install-recommends is
off - which is quite easy to do and some apt frontends do by default - then
it's possible to set up an EWS receiving account after a fresh KMail install,
but not a sending one.  This is confusing behaviour that no end-user would
expect.

-- 
You are receiving this mail because:
You are watching all bug changes.

[neon] [Bug 388035] Cannot add EWS outbound transport in KMail

2017-12-19 Thread James Young 
https://bugs.kde.org/show_bug.cgi?id=388035

James Young <marmar...@gmail.com> changed:

   What|Removed |Added

   Platform|Other   |Neon Packages

-- 
You are receiving this mail because:
You are watching all bug changes.

[neon] [Bug 388035] New: Cannot add EWS outbound transport in KMail

2017-12-19 Thread James Young 
https://bugs.kde.org/show_bug.cgi?id=388035

Bug ID: 388035
   Summary: Cannot add EWS outbound transport in KMail
   Product: neon
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: neon-b...@kde.org
  Reporter: marmar...@gmail.com
CC: j...@jriddell.org, neon-b...@kde.org, sit...@kde.org
  Target Milestone: ---

Out of the box on Neon, I cannot add an Exchange Web Services (EWS) outbound
email account to take full advantage of Akonadi's new EWS functionality in
KMail.  Note that setting up a 'Receiving' EWS Email Account works fine.

This is because the 'Sending' account dialog in KMail needs the
kmailtransport-akonadi plugin in order to list Akonadi-provided outbound mail
transports.  This plugin is contained in the kmailtransport-akonadi package,
and the kmailtransport-akonadi package is not depended on by kmail, so is not
installed by default.  Installing the kmailtransport-akonadi package manually
resolves the issue.

Please make kmail depend on kmailtransport-akonadi to ensure a nice
out-of-the-box experience for Neon end users.

-- 
You are receiving this mail because:
You are watching all bug changes.

[neon] [Bug 375979] Akonadi sqlite backend crashes Akonadi, incompatible qt versions

2017-02-07 Thread James Young 
https://bugs.kde.org/show_bug.cgi?id=375979

--- Comment #4 from James Young <marmar...@gmail.com> ---
Still happening for me with akonadi and the packages in Neon User: 
akonadi-backend-sqlite provides its own custom sqlite driver for Qt, it doesn't
use the default libqt5sql5-sqlite.

Anyway, I rebuilt akonadi against Qt 5.7.1 and problem went away.

-- 
You are receiving this mail because:
You are watching all bug changes.

[neon] [Bug 375979] New: Akonadi sqlite backend crashes Akonadi, incompatible qt versions

2017-02-03 Thread James Young 
https://bugs.kde.org/show_bug.cgi?id=375979

Bug ID: 375979
   Summary: Akonadi sqlite backend crashes Akonadi, incompatible
qt versions
   Product: neon
   Version: unspecified
  Platform: Neon Packages
OS: Linux
Status: UNCONFIRMED
  Severity: crash
  Priority: NOR
 Component: Packages User Edition
  Assignee: neon-b...@kde.org
  Reporter: marmar...@gmail.com
CC: j...@jriddell.org, neon-b...@kde.org, sit...@kde.org
  Target Milestone: ---

Currently akonadi is crashing when using the sqlite backend on neon user
edition.  This appears to be because the qsqlite3 driver
(akonadi-backend-sqlite version 4:16.12.1-0neon+16.04+build20) is built using
Qt 5.7.0 but is interfacing with the current version of Qt in neon, which is
5.7.1 (5.7.1+dfsg-3+16.04+build5).  When akonadiserver crashes, it prints this:

Cannot mix incompatible Qt library (version 0x50700) with this library (version
0x50701)

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-pa] [Bug 371580] Plasma crash when using volume control applet

2016-10-24 Thread James Young via KDE Bugzilla 
https://bugs.kde.org/show_bug.cgi?id=371580

James Young <marmar...@gmail.com> changed:

   What|Removed |Added

   Platform|Ubuntu Packages |Neon Packages
   Target Milestone|1.0 |---
Product|plasmashell |plasma-pa
  Component|general |applet

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 371580] New: Plasma crash when using volume control applet

2016-10-24 Thread James Young via KDE Bugzilla 
https://bugs.kde.org/show_bug.cgi?id=371580

Bug ID: 371580
   Summary: Plasma crash when using volume control applet
   Product: plasmashell
   Version: 5.8.2
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: k...@davidedmundson.co.uk
  Reporter: marmar...@gmail.com
CC: bhus...@gmail.com, plasma-b...@kde.org

Application: plasmashell (5.8.2)

Qt Version: 5.7.0
Frameworks Version: 5.27.0
Operating System: Linux 4.4.0-46-lowlatency x86_64
Distribution: Ubuntu 16.04.1 LTS

-- Information about the crash:
Using the Plasma volume control applet, I was trying to connect an application
that was recording audio to a different Pulseaudio source, by dragging and
dropping the application to the new source.  While I was in the middle of the
drag-and-drop operation, the application stopped recording.  When I dropped the
application icon on the new source, Plasma crashed and restarted with the
accompanying backtrace.

The crash can be reproduced sometimes.

-- Backtrace:
Application: Plasma (plasmashell), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f6009fb28c0 (LWP 6010))]

Thread 18 (Thread 0x7f5f21ffb700 (LWP 6955)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f60171c4adb in QWaitConditionPrivate::wait
(time=18446744073709551615, this=0x7395b30) at
thread/qwaitcondition_unix.cpp:143
#2  QWaitCondition::wait (this=, mutex=0x7019ad0,
time=18446744073709551615) at thread/qwaitcondition_unix.cpp:215
#3  0x7f5f5fde807f in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#4  0x7f5f5fdec078 in ?? () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#5  0x7f5f5fde726d in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x7f5f5fdec0d2 in ?? () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x7f5f5fde726d in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x7f5f5fde9bf0 in ThreadWeaver::Thread::run() () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x7f60171c3c28 in QThreadPrivate::start (arg=0x7f5efc003190) at
thread/qthread_unix.cpp:344
#10 0x7f60162a770a in start_thread (arg=0x7f5f21ffb700) at
pthread_create.c:333
#11 0x7f6016ad082d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 17 (Thread 0x7f5f227fc700 (LWP 6954)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f60171c4adb in QWaitConditionPrivate::wait
(time=18446744073709551615, this=0x7395b30) at
thread/qwaitcondition_unix.cpp:143
#2  QWaitCondition::wait (this=, mutex=0x7019ad0,
time=18446744073709551615) at thread/qwaitcondition_unix.cpp:215
#3  0x7f5f5fde807f in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#4  0x7f5f5fdec078 in ?? () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#5  0x7f5f5fde726d in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x7f5f5fdec0d2 in ?? () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x7f5f5fde726d in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x7f5f5fdec0d2 in ?? () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x7f5f5fde726d in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#10 0x7f5f5fdec0d2 in ?? () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#11 0x7f5f5fde726d in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#12 0x7f5f5fdec0d2 in ?? () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#13 0x7f5f5fde726d in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#14 0x7f5f5fde9bf0 in ThreadWeaver::Thread::run() () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#15 0x7f60171c3c28 in QThreadPrivate::start (arg=0x7f5ef8002f90) at
thread/qthread_unix.cpp:344
#16 0x7f60162a770a in start_thread (arg=0x7f5f227fc700) at
pthread_create.c:333
#17 0x7f6016ad082d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 16 (Thread 0x7f5f22ffd700