Bug#878938: kmail: crashes when filling in contact info from "recent contacts" in coposer
On Tuesday, October 17, 2017 12:37:57 PM PDT Shawn Sörbom wrote: > Package: kmail > Version: 4:16.04.3-4~deb9u1 > Severity: important > > Dear Maintainer, > > An abort() signal is thrown in kmail composer when filling in the "To:" > field from the recent contacts drop-down menu, causing a crash. This only > seems to happen with certain contacts. I have not been able to isolate what > makes these contacts unique. Please contct me if you need more details. > I have attatched a stacktrace. > > Application: KMail (kmail), signal: Aborted > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [Current thread is 1 (Thread 0x7fe1edb12940 (LWP 10115))] > > Thread 9 (Thread 0x7fe1d97ff700 (LWP 10127)): > #0 0x7fff344bb949 in ?? () > #1 0x7fff344bbbd9 in clock_gettime () > #2 0x7fe20d317996 in clock_gettime () from > /lib/x86_64-linux-gnu/libc.so.6 #3 0x7fe20dcae091 in qt_clock_gettime > (ts=0x7fe1d97fe9e0, clock=) at > tools/qelapsedtimer_unix.cpp:109 #4 do_gettime (frac=, > sec=) at tools/qelapsedtimer_unix.cpp:164 #5 qt_gettime > () at tools/qelapsedtimer_unix.cpp:173 > #6 0x7fe20de2ace9 in QTimerInfoList::updateCurrentTime > (this=this@entry=0x7fe1c0002cd0) at kernel/qtimerinfo_unix.cpp:91 #7 > 0x7fe20de2b295 in QTimerInfoList::timerWait (this=0x7fe1c0002cd0, > tm=...) at kernel/qtimerinfo_unix.cpp:388 #8 0x7fe20de2c63e in > timerSourcePrepareHelper (timeout=0x7fe1d97feab4, src=) at > kernel/qeventdispatcher_glib.cpp:132 #9 timerSourcePrepare > (source=, timeout=0x7fe1d97feab4) at > kernel/qeventdispatcher_glib.cpp:165 #10 0x7fe201fd3edd in > g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 > 0x7fe201fd491b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #12 > 0x7fe201fd4b0c in g_main_context_iteration () from > /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x7fe20de2d06b in > QEventDispatcherGlib::processEvents (this=0x7fe1c8c0, flags=...) at > kernel/qeventdispatcher_glib.cpp:425 #14 0x7fe20ddd69ca in > QEventLoop::exec (this=this@entry=0x7fe1d97fec80, flags=..., > flags@entry=...) at kernel/qeventloop.cpp:212 #15 0x7fe20dc040f3 in > QThread::exec (this=) at thread/qthread.cpp:507 #16 > 0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf7955430) at > thread/qthread_unix.cpp:368 #17 0x7fe203fa6494 in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 #18 0x7fe20d30aaff in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > > Thread 8 (Thread 0x7fe1daddf700 (LWP 10125)): > #0 0x7fe20d2fd71d in read () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x7fe202018d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #2 0x7fe201fd44be in g_main_context_check () from > /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fe201fd4994 in ?? () from > /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fe201fd4b0c in > g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 > 0x7fe20de2d06b in QEventDispatcherGlib::processEvents > (this=0x7fe1cc0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #6 > 0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1daddec80, > flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #7 > 0x7fe20dc040f3 in QThread::exec (this=) at > thread/qthread.cpp:507 #8 0x7fe20dc08da8 in QThreadPrivate::start > (arg=0x55adf785d990) at thread/qthread_unix.cpp:368 #9 0x7fe203fa6494 > in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #10 > 0x7fe20d30aaff in clone () from /lib/x86_64-linux-gnu/libc.so.6 > > Thread 7 (Thread 0x7fe1db7fe700 (LWP 10123)): > #0 0x7fe20d3016ad in poll () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x7fe201fd49f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #2 0x7fe201fd4b0c in g_main_context_iteration () from > /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fe20de2d06b in > QEventDispatcherGlib::processEvents (this=0x7fe1c80008c0, flags=...) at > kernel/qeventdispatcher_glib.cpp:425 #4 0x7fe20ddd69ca in > QEventLoop::exec (this=this@entry=0x7fe1db7fdc80, flags=..., > flags@entry=...) at kernel/qeventloop.cpp:212 #5 0x7fe20dc040f3 in > QThread::exec (this=) at thread/qthread.cpp:507 #6 > 0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf78876a0) at > thread/qthread_unix.cpp:368 #7 0x7fe203fa6494 in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x7fe20d30aaff in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > > Thread 6 (Thread 0x7fe1dbfff700 (LWP 10121)): > #0 0x7fe20d2fd71d in read () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x7fe202018d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #2 0x0
Bug#878938: kmail: crashes when filling in contact info from "recent contacts" in coposer
Package: kmail Version: 4:16.04.3-4~deb9u1 Severity: important Dear Maintainer, An abort() signal is thrown in kmail composer when filling in the "To:" field from the recent contacts drop-down menu, causing a crash. This only seems to happen with certain contacts. I have not been able to isolate what makes these contacts unique. Please contct me if you need more details. I have attatched a stacktrace. Application: KMail (kmail), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fe1edb12940 (LWP 10115))] Thread 9 (Thread 0x7fe1d97ff700 (LWP 10127)): #0 0x7fff344bb949 in ?? () #1 0x7fff344bbbd9 in clock_gettime () #2 0x7fe20d317996 in clock_gettime () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x7fe20dcae091 in qt_clock_gettime (ts=0x7fe1d97fe9e0, clock=) at tools/qelapsedtimer_unix.cpp:109 #4 do_gettime (frac=, sec=) at tools/qelapsedtimer_unix.cpp:164 #5 qt_gettime () at tools/qelapsedtimer_unix.cpp:173 #6 0x7fe20de2ace9 in QTimerInfoList::updateCurrentTime (this=this@entry=0x7fe1c0002cd0) at kernel/qtimerinfo_unix.cpp:91 #7 0x7fe20de2b295 in QTimerInfoList::timerWait (this=0x7fe1c0002cd0, tm=...) at kernel/qtimerinfo_unix.cpp:388 #8 0x7fe20de2c63e in timerSourcePrepareHelper (timeout=0x7fe1d97feab4, src=) at kernel/qeventdispatcher_glib.cpp:132 #9 timerSourcePrepare (source=, timeout=0x7fe1d97feab4) at kernel/qeventdispatcher_glib.cpp:165 #10 0x7fe201fd3edd in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x7fe201fd491b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #12 0x7fe201fd4b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x7fe20de2d06b in QEventDispatcherGlib::processEvents (this=0x7fe1c8c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #14 0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1d97fec80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #15 0x7fe20dc040f3 in QThread::exec (this=) at thread/qthread.cpp:507 #16 0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf7955430) at thread/qthread_unix.cpp:368 #17 0x7fe203fa6494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #18 0x7fe20d30aaff in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 8 (Thread 0x7fe1daddf700 (LWP 10125)): #0 0x7fe20d2fd71d in read () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fe202018d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fe201fd44be in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fe201fd4994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fe201fd4b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fe20de2d06b in QEventDispatcherGlib::processEvents (this=0x7fe1cc0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #6 0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1daddec80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #7 0x7fe20dc040f3 in QThread::exec (this=) at thread/qthread.cpp:507 #8 0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf785d990) at thread/qthread_unix.cpp:368 #9 0x7fe203fa6494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #10 0x7fe20d30aaff in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 7 (Thread 0x7fe1db7fe700 (LWP 10123)): #0 0x7fe20d3016ad in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fe201fd49f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fe201fd4b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fe20de2d06b in QEventDispatcherGlib::processEvents (this=0x7fe1c80008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #4 0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1db7fdc80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #5 0x7fe20dc040f3 in QThread::exec (this=) at thread/qthread.cpp:507 #6 0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf78876a0) at thread/qthread_unix.cpp:368 #7 0x7fe203fa6494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x7fe20d30aaff in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 6 (Thread 0x7fe1dbfff700 (LWP 10121)): #0 0x7fe20d2fd71d in read () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fe202018d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fe201fd44be in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fe201fd4994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fe201fd4b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fe20de2d06b in QEventDispatcherGlib::processEvents (this=0x7fe1d8c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #6 0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1dbffec80,
Re: jessie upgrade deemed very difficult + there is no simple way not to install konqueror
On Monday, June 19, 2017 11:24:59 PM PDT inkbottle wrote: > task-kde-desktop depends on kde-standard > which depends on plasma-desktop > which depends on kde-baseapps > which depends on konqueror > which depends on tons of difficult to understand seemingly outdated > dependencies. > > The upgrade is very difficult > > In fact I give up the upgrade altogether. > I'll have to come to it through another angle: > There are tons of packages which I deem old and unnecessary, and I find no > simple way not to install them. > > And there is no simple way not to install konqueror. > > Chris > > PS: Also aptitude put all automatically installed packages to satisfy > dependencies in manually installed: hundreds of them. > > It is a very difficult upgrade. If you download the meta-package source for kde-baseapps, you could remove the konqueror dependency from the control file, bump the version number, and repack it. I know this isn't ideal, but if you are willing to invest time in the task, it is doable. Good luck, --Shawn
Re: Any chance of getting kio-audiocd for kf5 into backports?
On Thursday, May 18, 2017 8:01:46 PM PDT Pino Toscano wrote: > In data giovedì 18 maggio 2017 10:54:17 CEST, Shawn Sörbom ha scritto: > > On Friday, April 28, 2017 9:14:01 AM PDT Maximiliano Curia wrote: > > > ¡Hola Shawn! > > > > > > El 2017-04-27 a las 13:15 -0700, Shawn Sörbom escribió: > > > > So, should I wait for sid to reopen or try to upload to experimental? > > IIRC backports are packages already in testing (so the next release) > built for the current stable. This means that you cannot upload as > backport something which is not even in unstable. > > To be backported to stretch, the kf5 version of kio-audiocd (and its > dependencies) will need to be in the buster testing first, so there is > not much you can do before stretch is released. > > > Just a quick status update. I was able to build kio-audiocd, and it seems > > to work fairly well. I will be filing ITP's on it and its dependencies > > later today. > > ITP is for new sources, not for existing ones -- please do not file an > ITP for the kf5 version of kio-audiocd, since src:kio-audiocd already > is in Debian. I see. Thank you for clearing that up.
Re: Any chance of getting kio-audiocd for kf5 into backports?
On Friday, April 28, 2017 9:14:01 AM PDT Maximiliano Curia wrote: > ¡Hola Shawn! > > El 2017-04-27 a las 13:15 -0700, Shawn Sörbom escribió: > > So, should I wait for sid to reopen or try to upload to experimental? > > Is there a bug that needs to be reopen? > > If you are not a DD you can't upload the package directly, you'll need to > request a sponsored upload. In any case, please create a branch/repository > so we can review your changes. > > Happy hacking, Hi, Just a quick status update. I was able to build kio-audiocd, and it seems to work fairly well. I will be filing ITP's on it and its dependencies later today.
Re: improving the UX with the default KDE installation
On Saturday, April 22, 2017 1:07:09 PM PDT fradev wrote: > Hi everyone > > On 25/03/17 18:50:08 CEST, fradev wrote: > > Here are the dependencies of task-kde-desktop, on the right my > > suggestions. > > > > task-kde-desktop > > > > Depends: tasksel > > Depends: task-desktop > > Depends: kde-standard > > Depends: sddm > > Recommends: kdeaccessibility--> change to: Suggests > > Recommends: gnome-orca --> change to: Suggests > > Recommends: k3b --> change to: Suggests > > Recommends: k3b-i18n--> change to: Suggests > > Recommends: plasma-nm > > Recommends: kdesudo > > Recommends: libreoffice-kde > > Recommends: apper --> substitute with: synaptic > > Recommends: gimp > > Recommends: firefox-esr > > Recommends: libreoffice > > Recommends: libreoffice-help-en-us > > Recommends: mythes-en-us > > Recommends: hunspell-en-us > > Recommends: hyphen-en-us > > Recommends: system-config-printer > > Recommends: dragonplayer--> substitute with: vlc > > (original message here [1]) > > I didn't received many feedbacks about this and I'm thinking to send a bug > report (wishlist) proposing the changes highlighted above. > > What concerns me the most here is apper. Summarising: > - apper should be dead upstream > - plasma-discover is too bugged to be used as a replacement > - update-notifications don't seem to work with both (at least for me) > - what about muon? > - synaptic seems to be the only sane alternative but doesn't provide > update-notifications > - pk-update-icon provides update-notifications but depends on > gnome-packagekit > > Despite the integration with the Plasma desktop I think it is essential to > provide (also) a good graphical package manager with update-notifications. > What do you think about it? > > Francesco > > [1] https://lists.debian.org/debian-kde/2017/03/msg00041.html On the subject of what to change, could you also consider replacing akregator with quiterss? Akregator is just broken these days. I have been using quiterss for several months and it seems to work pretty well by contrast.
Re: Any chance of getting kio-audiocd for kf5 into backports?
On Thursday, April 27, 2017 1:52:10 PM PDT Maximiliano Curia wrote: > ¡Hola Shawn! > > El 2017-04-26 a las 16:40 -0700, Shawn Sörbom escribió: > > On Wednesday, April 26, 2017 12:27:10 PM PDT Shawn Sörbom wrote: > >> I noticed that there have been attempts recently to port the kio-audiocd > >> plugin to KF5. I Know it is a bit late in the freeze process to get a new > >> package accepted, but would the KDE team here be open to accepting it in > >> Backports? > >> > >> Some of us audiophiles can be a bit clingy when it comes to our optical > >> media collections :) > >> > >> PS. If all that is needed is a packager, I would be happy to file an ITP. > > > > H It turns out that the kde cdddb library (which kio-audiocd > > needs) in Stretch is still KDE4 based. So, kio-audiocd needs > > sub-dependencies. Grrr > Then you need to backport libkcddb and kio-audiocd to stretch, it should be > doable. I think that these backports can wait till we have the newer > kio-audiocd in sid. > > We might need a way to track the backports requests. I guess a wiki page > might be enough. https://wiki.debian.org/KDE/Backports > > Happy hacking, So, should I wait for sid to reopen or try to upload to experimental?
Re: Any chance of getting kio-audiocd for kf5 into backports?
On Wednesday, April 26, 2017 12:27:10 PM PDT Shawn Sörbom wrote: > Hi, > I noticed that there have been attempts recently to port the kio-audiocd > plugin to KF5. I Know it is a bit late in the freeze process to get a new > package accepted, but would the KDE team here be open to accepting it in > Backports? > > Some of us audiophiles can be a bit clingy when it comes to our optical > media collections :) > > Thanks, > --Shawn > > PS. If all that is needed is a packager, I would be happy to file an ITP. H It turns out that the kde cdddb library (which kio-audiocd needs) in Stretch is still KDE4 based. So, kio-audiocd needs sub-dependencies. Grrr
Any chance of getting kio-audiocd for kf5 into backports?
Hi, I noticed that there have been attempts recently to port the kio-audiocd plugin to KF5. I Know it is a bit late in the freeze process to get a new package accepted, but would the KDE team here be open to accepting it in Backports? Some of us audiophiles can be a bit clingy when it comes to our optical media collections :) Thanks, --Shawn PS. If all that is needed is a packager, I would be happy to file an ITP.
Re: improving the UX with the default KDE installation
On Sunday, April 23, 2017 3:42:40 PM PDT Nick wrote: > On Tue, 18 Apr 2017 13:39:35 -0700 > > Shawn Sörbom <sh...@sorbom.com> wrote: > > On Saturday, April 15, 2017 11:19:22 PM PDT Nick wrote: > > > JFTR, one alternative to Kmail might be 'Trojita' [1] > > > - I haven't (yet) tried it, and it's not a KDE program, > > > but it _is_ part of the KDE family, professionally > > > developed, looks nice, well-liked and is pure-Qt > > > so it fits well into a KDE environment. > > > The only "downside" is that it's IMAP-only. > > > > > > [1] http://trojita.flaska.net/ > > [...] > > > Subjectively, it feels fast, which I like. > > Great :) ... I've also read other folks comments to that effect ... > > > However, I noticed that it does not appear to have > > threading support, which I use a lot for mailing lists. > > Um ... me too, but maybe you mean something different from the simple > ability to show the component emails of a conversation in a branching > structure that keeps replies grouped with the messages they replied to > and which reflects the chronological sequence of the discussion ? > > Otherwise, the first screenshot at > http://trojita.flaska.net/screenshots.html appears to show > properly threaded messages ... > > > Lack of POP3 support is also an issue for anybody who > > prefers reading local copies of their mail. > > Agreed. Most ISPs limit how much email you can leave on their > mailservers, and how long it can stay there ... so unless we each set up > our own local mail-handling facilities (e.g. some spare box running > fetchmail and Dovecot/Courier), which we then access via IMAP, then lack > of POP3 is a show-stopper (other than for users who use only > IMAP-accessible "unlimited storage" free webmail addresses). > > I don't know what the Trojita author's wishes are for handling of > other mail protocols but if s/he would accept a patch then it might be > possible to bolt on the POP3 engine from some other open-source email > client. I'll try to make time to look into that. > > > The addressbook feature is somewhat lacking. There > > doesn't seem to be any ability to import contacts. > > Ah .. that would also be a major problem. > > > it is a nice lightweight alternative if you don't mind > > those limitations > > Thanks for taking the trouble to try it out and post a review. > > Cheers > Nick There is a sorting menu item that includes the option to thread messages, but all of the advanced sorting options are greyed out... At least this is the case with the package I linked to. I am curious if the issue is merely due to a build flag that was disabled.
Re: improving the UX with the default KDE installation
On Saturday, April 15, 2017 11:19:22 PM PDT Nick wrote: > On Sun, 2 Apr 2017 00:11:40 -0700 > Shawn Sörbom <sh...@sorbom.com> wrote: > > I'm a bit late to this discussion, but FWIW: > > [snip] > > > for a good "out of the box" experience, many people expect a mail > > client. Look at Kubuntu. Personally kmail would be of the first > > packages I would install on any KDE system that I would set up for an > > "average" user. A default email solution is something any distro > > should have. For a KDE specific solution, I don't think there is much > > else out there > > [snip] > > I agree that typical users are going to expect some kind of email > client to be bundled with a base install. > > I've liked Kmail all its life (since KDE 2.2.x) but I'm still (happily) > using Wheezy (now LTS), and must say I'm dreading upgrading to current > stable and getting the flaky Kmail experience that seems to be what > so many people find. JFTR, one alternative to Kmail might be > 'Trojita' [1] - I haven't (yet) tried it, and it's not a KDE program, > but it _is_ part of the KDE family, professionally developed, looks > nice, well-liked and is pure-Qt so it fits well into a KDE > environment. The only "downside" is that it's IMAP-only. > > [1] http://trojita.flaska.net/ > > Cheers > Nick Anyone wanting to try this can get Debian Packages via the Open Suse Build service here: http://software.opensuse.org/download.html?project=home:jkt-gentoo:trojita=trojita For those running stretch, you will need to install this dependancy manually: https://packages.debian.org/jessie/libs/libmimetic0 Subjectively, it feels fast, which I like. However, I noticed that it does not appear to have threading support, which I use a lot for mailing lists. Lack of POP3 support is also an issue for anybody who prefers reading local copies of their mail. The addressbook feature is somewhat lacking. There doesn't seem to be any ability to import contacts. This will cause a major bump for anyone reliant on .vcf contacts. But it is a nice lightweight alternative if you don't mind those limitations. --Shawn
Re: improving the UX with the default KDE installation
On Wednesday, April 5, 2017 3:10:55 PM PDT fradev wrote: > On 03/04/17 13:07:31 CEST, fradev wrote: > > >$ sudo apt autoremove kmail > > Sorry, there is a typo. The output that I posted was generated by > "$ sudo apt remove kmail", not "autoremove". I agree, but the original topic was about which packages shouldn't be included by default. Couldn't this be solved by changing it to "recommends" instead?
Re: improving the UX with the default KDE installation
On Saturday, April 1, 2017 12:20:17 PM PDT fradev wrote: > On 31/03/17 13:27:14 CEST, Maximiliano Curia wrote: > > >>> Depends: kmail--> change to: Suggests > > >> > > >> It has its glitches... But I use it > > > > > > I use it too and I propose to suggest it, and not recommend it, exactly > > > because it has it glitches and many people probably prefer other clients > > > or > > > just e-mail web interfaces even when using the Plasma desktop. > > > > I think that kde-standard needs to provide kmail, even if kmail is > > "glitchy", btw, it works way better than the one in jessie. The same goes > > for korganizer. kaddressbook and knotes are required for a sane kmail and > > korganizer installation respectively. > > I agree that all these packages are useful for kmail and korganizer. > However, especially when using multiple machines, a browser web can be said > to be essential but a complete mail suite is not. I have different > computers but only one is used for e-mail, from my point of view is not > useful to have kmail and friends installed by default on all my computers > by default because they serve different purposes. > > And, again, I think that kmail and its complementary applications installed > by default are too much for the general public. We power users have our > needs but the majority out there has more simple needs. For a lot of people > the web interface of their only e-mail account is more than enough, meaning > that what they need is just a web browser. > > Francesco But for a good "out of the box" experience, many people expect a mail client. Look at Kubuntu. Personally kmail would be of the first packages I would install on any KDE system that I would set up for an "average" user. A default email solution is something any distro should have. For a KDE specific solution, I don't think there is much else out there. If this were to come to a vote I would say leave it in.
Re: improving the UX with the default KDE installation
I agree with you about konqueror, but in the case of kwrite vs kate, I think the reason is that kate depends on some kwrite components. Technically kate is also targeted at programmers, whereas kwrite is similar to MS Notepad. On Wednesday, March 15, 2017 7:01:16 PM PDT fradev wrote: > Hi everyone > > The default KDE/Plasma 5 installation in Stretch, via task-kde-desktop, in > my opinion doesn't provide the best user experience because of the many > applications installed by default. > > While the experience with the Plasma desktop is pretty good, the same > cannot be said for some KDE applications. To improve the situation, at > least for me, in different occasions I had to: > > - manually install only the required KDE applications in a minimal Debian > setup; > - or manually remove all the unwanted KDE applications in the default KDE > installation (and break meta-packages). > > The main issue is that, in some cases, the applications required recursively > by the package task-kde-desktop are obsolete, bugged and/or are useless > redundancies. I'll make some examples at the end of this e-mail to better > explain my point of view. > > I don't know if there are other users considering this as a usability issue > but, in case, and if it is still possible to do something given the freeze > of Stretch, it could be solved by changing the applications listed as > dependencies and recommended by the meta-packages used in the default KDE > installation in Stretch. > > I'm working just for myself on a list of packages that can be omitted or > substituted and if someone is interested I can continue in this discussion. > > Regards > Francesco > > > EXAMPLES > > > Let's start with Konqueror, installed by default in the case discussed > above. Despite its history and how interesting it is, we all know that > Konqueror nowadays lacks developer manpower. Its web engines are obsolete > and probably not suitable anymore for a safe web surfing. Surely many of us > will not suggest its usage, especially to newcomers. Firefox and Chromium > are far superior web browsers and, besides, Firefox is recommended by > task-kde-desktop and it is installed in the default KDE installation. > > Konqueror can also be used as a file manager but we already have Dolphin, > that I'm sure is considered the de facto file manager in the Plasma > desktop, installed along with it. Konqueror therefore is pretty much > useless and redundant in a standard installation. If it so, why install it > by default? > > Same story with some of the KDEPIM applications installed by > task-kde-desktop/kde-standard. I'm a Kmail user but like many others I know > that Kmail can be a difficult beast to handle, it has its bugs, akonadi > could be a pain sometimes, and it lacks developer manpower too (and maybe > it will be replaced by Kube in the future). > > Despite I'm using Kmail I will probably suggest to other users and newcomers > to try Icedove/Thunderbird instead, or simply use their e-mail accounts via > web browser if it is too much for them. In my opinion Kmail and friends > should not be installed by default. > > There are other cases like that or minor redundancies, such as Kate and > Kwrite installed altogether. Why install them both?
Need help diagnosing Akregator failure
Hi, On Debian Testing, Akregator recently started hanging during startup. It usually occurs so fast that the welcome window freezes during mid-render After that, no UI elements are clickable. If I terminate the window and manually restart the application, akregator comes up with the restore screen but promptly freezes again. Thus far I have removed my user data (no effect) and also executed akregator in gdb (no discernible errors). I dont think I have enough information to file a bug report yet. What should I try next? Thanks, --Shawn
Re: KdePIM results testing migration from Plasma 4 to Plasma 5
On Thursday, November 17, 2016 2:35:47 AM PST Shawn Sörbom wrote: > On Wednesday, November 16, 2016 23:05:17 Martin Steigerwald wrote: > > Hello. > > > > Am Mittwoch, 16. November 2016, 13:31:12 CET schrieb Shawn Sörbom: > > > 2. My messages imported alright...but they were imported as a separate > > > directory structure. Long story short, I now have two "inboxes"-one of > > > which is empty. > > > > I didn´t use any KDEPIM Settings Importer or other import functionality in > > KMail. I just moved the maildir directories over to the new location in > > ~/.local/share/local-mails and pointed the maildir resource there, then > > gave it some time to synchronise. Also I let it pick up the old kmailrc. > > > > Okay, there is one additional step: Before that with KDEPIM 4 I moved all > > mbox archival folders I had in the mixed maildir resource to an extra > > resource and switched the main maildir resource from mixed maildir to > > plain > > maildir. I still didn´t point a mixed maildir resource to the old archived > > mails in KDEPIM 5 as last times I tried to do it ate all memory. > > > > Maybe you have two mail related resources now. If so you can remove one > > with Akonadiconsole for example. But make sure to pick the right one :). > > But even if you pick to wrong one, you can recreate a maildir resource > > and point it to the maildir location again, as deleting the resource does > > not delete the data it handles. > > > > Read: > > > > Akonadi misconception #1: where is my data? > > Submitted by amantia > > https://blogs.kde.org/2011/11/13/akonadi-misconception-1-where-my-data > > > > And this one: > > > > akonadi/KDE PIM backup/restore > > https://mail.kde.org/pipermail/kdepim-users/2016-October/000351.html > > > > > How do I go about providing bug reports from here? > > > > Thats a tough one. Why? > > > > - I think upstream as in bugs.kde.org would be the right recipient. > > > > - But I think upstream neither has the interest nor the manpower to handle > > issues related to migrate from KDEPIM 4 to 5 anymore – unless it a fix for > > a bug reproducable within KDEPIM + Akonadi 5. Stable Debian users are > > among the latest users to migrate. > > > > - Quite some of the issue like loosing filters may already be reported and > > lingering in upstream bugzilla. > > > > - Report in Debian then? I think Debian Qt/KDE maintainers do not have the > > resources to do much more than to refer to upstream. I am happy they are > > able to provide packages, although for KDEPIM it would be good to have > > 16.08 instead of 16.04, but this AFAIK is still blocked by packaging Qt > > WebEngine, which basically is a port of Chromium´s Blink webengine. > > > > Still if you want to report anything: Good luck! > > > > Otherwise I suggest to struggle your way through. Review resources in this > > list and in upstream kdepim-users list. Especially in kdepim-users mailing > > list, but I think also here I covered migration issues more than once. And > > so did others. Most if not all questions have been answered already and I > > don´t even completely recall it all. I migrated more than a year ago and > > forgot most of the process. If you need help, ask. At least you do the > > migration only once. > > > > I especially would ask in kdepim-users for any open migration issues. > > There > > are a lot of users who did the migration and there are upstream > > developers, > > too. > > > > Am I happy with that? Not really. But thats how I see the situation. > > Migrating from KDEPIM 4 to 5 has been rough for many users. > > > > Thanks, > > Moving to .local/share/local-mails did the trick. Thank you. > Still no filters after I copied over the directories, but I should be able > to fix that by importing them separately when I upgrade for real. I'm sure > glad I'm discovering this now as opposed to later! > Thank you so much! > > Its a shame this doesn't get fixed, I suspect it would be simple to detect a > plasma 4 backup and handle accordingly. I might just report it... Hi, I recently made the switch to testing and it seems that almost everything migrated without any intervention from me. It would seem that my fears were largely unfounded the only thing I had to fiddle with was migrating kwallet data, which didn't work the first time I ran it. But I got around that by resetting the migrated value in ~/.local/share/kwalletd/kwalletrc to "no", and then restarting kwalletd and kwalletd5 from the command line. A migration assistant will then ask for your old wallet's password. this should be the last time this ever happens, as the new wallet appears to be integrated with PAM. Is there any chance of getting this added to the Debian wiki? I feel it may be useful there. --Shawn
Re: KdePIM results testing migration from Plasma 4 to Plasma 5
On Wednesday, November 16, 2016 23:05:17 Martin Steigerwald wrote: > Hello. > > Am Mittwoch, 16. November 2016, 13:31:12 CET schrieb Shawn Sörbom: > > 2. My messages imported alright...but they were imported as a separate > > directory structure. Long story short, I now have two "inboxes"-one of > > which is empty. > > I didn´t use any KDEPIM Settings Importer or other import functionality in > KMail. I just moved the maildir directories over to the new location in > ~/.local/share/local-mails and pointed the maildir resource there, then gave > it some time to synchronise. Also I let it pick up the old kmailrc. > > Okay, there is one additional step: Before that with KDEPIM 4 I moved all > mbox archival folders I had in the mixed maildir resource to an extra > resource and switched the main maildir resource from mixed maildir to plain > maildir. I still didn´t point a mixed maildir resource to the old archived > mails in KDEPIM 5 as last times I tried to do it ate all memory. > > Maybe you have two mail related resources now. If so you can remove one with > Akonadiconsole for example. But make sure to pick the right one :). But > even if you pick to wrong one, you can recreate a maildir resource and > point it to the maildir location again, as deleting the resource does not > delete the data it handles. > > Read: > > Akonadi misconception #1: where is my data? > Submitted by amantia > https://blogs.kde.org/2011/11/13/akonadi-misconception-1-where-my-data > > And this one: > > akonadi/KDE PIM backup/restore > https://mail.kde.org/pipermail/kdepim-users/2016-October/000351.html > > > How do I go about providing bug reports from here? > > Thats a tough one. Why? > > - I think upstream as in bugs.kde.org would be the right recipient. > > - But I think upstream neither has the interest nor the manpower to handle > issues related to migrate from KDEPIM 4 to 5 anymore – unless it a fix for a > bug reproducable within KDEPIM + Akonadi 5. Stable Debian users are among > the latest users to migrate. > > - Quite some of the issue like loosing filters may already be reported and > lingering in upstream bugzilla. > > - Report in Debian then? I think Debian Qt/KDE maintainers do not have the > resources to do much more than to refer to upstream. I am happy they are > able to provide packages, although for KDEPIM it would be good to have > 16.08 instead of 16.04, but this AFAIK is still blocked by packaging Qt > WebEngine, which basically is a port of Chromium´s Blink webengine. > > Still if you want to report anything: Good luck! > > Otherwise I suggest to struggle your way through. Review resources in this > list and in upstream kdepim-users list. Especially in kdepim-users mailing > list, but I think also here I covered migration issues more than once. And > so did others. Most if not all questions have been answered already and I > don´t even completely recall it all. I migrated more than a year ago and > forgot most of the process. If you need help, ask. At least you do the > migration only once. > > I especially would ask in kdepim-users for any open migration issues. There > are a lot of users who did the migration and there are upstream developers, > too. > > Am I happy with that? Not really. But thats how I see the situation. > Migrating from KDEPIM 4 to 5 has been rough for many users. > > Thanks, Moving to .local/share/local-mails did the trick. Thank you. Still no filters after I copied over the directories, but I should be able to fix that by importing them separately when I upgrade for real. I'm sure glad I'm discovering this now as opposed to later! Thank you so much! Its a shame this doesn't get fixed, I suspect it would be simple to detect a plasma 4 backup and handle accordingly. I might just report it...
Up to date information on plasma versions in testing?
Hi folks, Just wondering where one can find up to date information on the plasma versions currently in stretch? the obvious answer would be to check individual packages of course, but I find that they often have confusing (and conflicting) version numbers. Is a package like Kwin a good overall progress indicator for the state of which version is (mostly) being used? Thanks, --Shawn
compiler warnings seem to be crashing my package build
Hi, I have been trying to build kcm-systemd against the KF5 libraries available in Sid, but when I do the build using dpkg-buildpackage, I get a compiler warning about an un-initialized variable and a subsequent crash. Yet, when I build it manually, no such problem occurs. I suspect that dh_autoconfigure sets flags to fail on warnings. How do I disable this without a complete override? The branch in question is here: https://github.com/shsorbom/kcmsystemd-debian/tree/deb_KF5_clean Thanks, --Shawn -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/18428346.0ajnNYS5V0@medusa
Re: So I have a Plasma 5 desktop!
Any word on when the rest of it will land in Sid? I have been holding off packaging work because I didn't really want to use experimental. I hope it is soon, I wont have time for Debian stuff once school restarts. On Thursday, July 09, 2015 16:50:51 David Baron wrote: Installing the kwin stuff stopped the immediate crashes. Could not see any text except some highlighted stuff and pieces of menus. Go to system settings, somehow, and set the compositor to xrender. This got everything painted again. Now of course, had to start over. Some pieces, widgets, are missing, even thought they were explicitly installed. Icon themes have missing pieces, and size-related flaws. But ... Plasma 5 is up and running and (mostly) quite nicely! -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4264614.m4SyW66lyD@medusa
Re: dpkg-buidpackage compresses khelpcenter documentation (needs to be raw)
Thanks, Overriding dh_compress did the trick. --Shawn On Wednesday, December 17, 2014 22:38:33 Lisandro Damián Nicanor Pérez Meyer wrote: On Tuesday 16 December 2014 16:15:59 Shawn Sörbom wrote: Hi, I discovered that when building my kcm-ufw package, Khelpcenter documentation is installed to the correct place, but it is installed in a compressed format. How do I override this behavior in debian/rules? Khelpcenter only seems to understand uncompressed docs. Thanks, --Shawn Sörbom Take a look at dh_compress' man page. You basically need to override it and call it with -Xwhat to not compress signature.asc Description: This is a digitally signed message part.
dpkg-buidpackage compresses khelpcenter documentation (needs to be raw)
Hi, I discovered that when building my kcm-ufw package, Khelpcenter documentation is installed to the correct place, but it is installed in a compressed format. How do I override this behavior in debian/rules? Khelpcenter only seems to understand uncompressed docs. Thanks, --Shawn Sörbom -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2996421.JP9f8f7JmO@medusa
Bug#773091: korganizer not remembering color selections for catagories
Package: korganizer Version: 4:4.14.1-1 Severity: minor Dear Maintainer, When I go into Korganizer - tools - configure korganizer to set catagory colors, I find that it is possible to apply color changes to task catagories, but when I rstart korganizer, all the color changes I made are set back to default (green). This only seems to happen if the catagory's coloris changed after it is in use by a given task. I have not tested this extensively yet. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages korganizer depends on: ii kde-runtime 4:4.14.2-1 ii kdepim-runtime4:4.14.2-2 ii kdepimlibs-kio-plugins4:4.14.2-2 ii libakonadi-calendar4 4:4.14.2-2 ii libakonadi-contact4 4:4.14.2-2 ii libakonadi-kde4 4:4.14.2-2 ii libakonadi-kmime4 4:4.14.2-2 ii libc6 2.19-13 ii libcalendarsupport4 4:4.14.1-1 ii libeventviews44:4.14.1-1 ii libgcc1 1:4.9.1-19 ii libincidenceeditorsng44:4.14.1-1 ii libkabc4 4:4.14.2-2 ii libkcalcore4 4:4.14.2-2 ii libkcalutils4 4:4.14.2-2 ii libkcmutils4 4:4.14.2-4 ii libkdecore5 4:4.14.2-4 ii libkdepim44:4.14.1-1 ii libkdepimdbusinterfaces4 4:4.14.1-1 ii libkdeui5 4:4.14.2-4 ii libkholidays4 4:4.14.2-2 ii libkio5 4:4.14.2-4 ii libkmime4 4:4.14.2-2 ii libknewstuff3-4 4:4.14.2-4 ii libkontactinterface4a 4:4.14.2-2 ii libkparts44:4.14.2-4 ii libkpimidentities44:4.14.2-2 ii libkpimutils4 4:4.14.2-2 ii libmailtransport4 4:4.14.2-2 ii libphonon44:4.8.0-4 ii libpimcommon4 4:4.14.1-1 ii libqt4-dbus 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqt4-xml4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libstdc++64.9.1-19 ii perl 5.20.1-3 ii phonon4:4.8.0-4 Versions of packages korganizer recommends: pn kdepim-kresources none korganizer suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141214005407.2754.1879.report...@medusa.shawnsorbom.net
Bug#730310: kmail pop3s in Sid
Hello again, I made time yesterday, and spun up a Debian Sid VM. It turns out that kmail doesn't fetch secure pop on the newest unstable build. The bug has the same symtoms as the variation in testing. The progress bar gets to 100%, but no mail appears in the main window. When I fetch again, I get a message saying that the previous login attempt was unsuccessful and I need to re-enter my username and password information. Re-entering the login information does not fix the problem. Should I file a seerate bug, since the initial bug is filed against stable? Btw I made sure to manually add the SSL cert in KDE's SSL preferences. The last time I looked POP3s in kmail does work in kubuntu. Would it be difficult to patch pop3s code into the Debian version? I would volunteer, but I don't really know where to start looking. PS. I tried running GDB on kmail, but when I did, my VM slowed to a crawl and became unusable (ank kmail didn't seem to start). Any Ideas? Thanks. Shawn Sörbom -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201402161737.58339.sh...@sorbom.com
Bug#730310: Debian Testing
I just tried SSL and unencrypted pop3 fetching on Debian testing using the private server. Unencrypted worked, SSL did not. However, this time there was no error message. Under SSL, the fetch progress bar completed, but when I tried again, I got a message saying that the previos fetch failed and I shoud re-enter my login information. Given that there were no error messages this time, I would like to try using the debug symols, but I could not find a -dbg package for kmail. Where is it? -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201311251028.02788.sh...@sorbom.com
Bug#730310: kmail: Could not negotiate SSL Certificate
Package: kmail Version: 4:4.4.11.1+l10n-3+b1 Severity: important Dear Maintainer, When I try to connect to a private e-mail server over pop3s using a self-signed certificate, kmail sends a notification as follows: Error Could not connect to server, could not negotiate SSL certificate. Where server is the name of the machine I was trying to connect to. Using unencrypted pop3, it works fine. Encrypted GMail using pop3 SSL encryption also works fine. The private server is using standard ports for POP3 SSL traffic. When I tested the private server using a kubuntu VM it worked fine. I have not been able to try Debian testing or unstable yet. -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kmail depends on: ii kde-runtime 4:4.8.4-2 ii kdepim-runtime 4:4.4.11.1-6 ii kdepimlibs-kio-plugins 4:4.8.4-2 ii libakonadi-contact4 4:4.8.4-2 ii libakonadi-kde4 4:4.8.4-2 ii libc6 2.13-38 ii libgcc1 1:4.7.2-5 ii libgpgme++2 4:4.8.4-2 ii libkabc44:4.8.4-2 ii libkcal44:4.8.4-2 ii libkcmutils44:4.8.4-4 ii libkde3support4 4:4.8.4-4 ii libkdecore5 4:4.8.4-4 ii libkdepim4 4:4.4.11.1+l10n-3+b1 ii libkdeui5 4:4.8.4-4 ii libkhtml5 4:4.8.4-4 ii libkimap4 4:4.8.4-2 ii libkio5 4:4.8.4-4 ii libkldap4 4:4.8.4-2 ii libkleo44:4.4.11.1+l10n-3+b1 ii libkmime4 4:4.8.4-2 ii libknotifyconfig4 4:4.8.4-4 ii libkontactinterface44:4.8.4-2 ii libkparts4 4:4.8.4-4 ii libkpgp44:4.4.11.1+l10n-3+b1 ii libkpimidentities4 4:4.8.4-2 ii libkpimtextedit44:4.8.4-2 ii libkpimutils4 4:4.8.4-2 ii libkresources4 4:4.8.4-2 ii libksieve4 4:4.4.11.1+l10n-3+b1 ii libktnef4 4:4.8.4-2 ii libmailtransport4 4:4.8.4-2 ii libmessagecore4 4:4.4.11.1+l10n-3+b1 ii libmessagelist4 4:4.4.11.1+l10n-3+b1 ii libmimelib4 4:4.4.11.1+l10n-3+b1 ii libnepomuk4 4:4.8.4-4 ii libphonon4 4:4.6.0.0-3 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-network 4:4.8.2+dfsg-11 ii libqt4-qt3support 4:4.8.2+dfsg-11 ii libqt4-xml 4:4.8.2+dfsg-11 ii libqtcore4 4:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libstdc++6 4.7.2-5 ii libthreadweaver44:4.8.4-4 ii perl5.14.2-21+deb7u1 ii phonon 4:4.6.0.0-3 Versions of packages kmail recommends: ii gnupg-agent 2.0.19-2+deb7u1 ii gnupg22.0.19-2+deb7u1 ii pinentry-gtk2 [pinentry-x11] 0.8.1-1 Versions of packages kmail suggests: ii bogofilter 1.2.2+dfsg1-2 pn clamav | f-prot-installer none ii kaddressbook 4:4.4.11.1+l10n-3+b1 pn kleopatra none ii procmail 3.22-20 -- no debconf information -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131123202829.5538.66062.report...@beagle.shawnsorbom.net
Possible KMail bug, Could not negotiate SSL Certificate
Hello, I am using KDE in Wheezy and I can't seem to get pop3 with SSL encryption to work properly on a private server. Unencrypted mail works perfectly fine over pop3. I fetch from a private server with a self signed certificate. GMail strangely works well. Whenever I try to connect to the private server, I get: Error Could not connect to server, could not negotiate SSL certificate. I tried doing fetches in Kubuntu 13.10 using POP3 SSL. This works fine. I found a possibly relevent bug in the KDE bugtracker here: https://bugs.kde.org/show_bug.cgi?id=155067 I should note that the error message itself was different than mine, but the symtoms were the same. I would like to file a bug report, but I am new to this and not sure what to include. What more information do I need before I get started? Thanks, Shawn Sörbom -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201311211810.27793.sh...@sorbom.com
Possible KMail bug, Could not negotiate SSL Certificate
Hello, I am using KDE in Wheezy and I can't seem to get pop3 with SSL encryption to work properly on a private server. Unencrypted mail works perfectly fine over pop3. I fetch from a private server with a self signed certificate. GMail strangely works well. Whenever I try to connect to the private server, I get: Error Could not connect to server, could not negotiate SSL certificate. I tried doing fetches in Kubuntu 13.10 using POP3 SSL. This works fine. I found a possibly relevent bug in the KDE bugtracker here: https://bugs.kde.org/show_bug.cgi?id=155067 I should note that the error message itself was different than mine, but the symtoms were the same. I would like to file a bug report, but I am new to this and not sure what to include. What more information do I need before I get started? Thanks, Shawn Sörbom -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201311211746.10734.sh...@sorbom.com
