Re: KDEPIM issues (was: Re: Bugs bugs bugs)
Am Montag, 23. Februar 2015, 18:39:40 schrieb Volker Wysk: > Am Sonntag, 22. Februar 2015, 16:13:10 schrieb Martin Steigerwald: > > Am Samstag, 21. Februar 2015, 16:32:33 schrieb Volker Wysk: > > > I've never used the experimental branch. When will the packages > > > migrate > > > to Unstable? > > > > They won´t before Jessie release. > > > > Maybe KDEPIM 4.14.5 could make it to unstable as its only bug fixes, > > but that would need an exception from the release team as well in > > this late state of Jessie freeze, I think – unless they fix RC bugs > > (and only! them). The freezing / release policy is clarified in some > > document I don´t have the URL at hand at the moment, should be easy > > to find. > > This should be it: > https://release.debian.org/jessie/freeze_policy.html > > It doesn't predict when Jessie will be released, but I get the > impression that it won't be much longer. > > > > > For me beside KDEPIM KDE / Plasma 4.14.2 really works quite good. > > > > KDEPIM basically works, but there are still a lot of open issues. > > > > > > Exactly... > > > > Well, that may not change *that much* with a newer version. 4.14.5 has > > some bugs fixed, but I compiled kdepim-runtime and kdepimlibs 4.14.5 > > on top of KDEPIM 4.14.2 as packages by debian and I still have most > > of the issues. > > What do you mean by "compile on top of"? I am using KDEPIM as packaged for Debian with newer kdepimlibs, kdepim- runtime and akonadi-server compiled by myself… > What sources are you using? I can find only 4.14.3 on kde.org, not > 4.14.5. … using repositories cloned via git. I usually do not use tarballs anymore. I described this here: List: kdepim-users Subject:[kdepim-users] how to compile akonadi server quick guide (war: Re: rant) From: Martin Steigerwald Date: 2015-01-29 13:57:13 Message-ID: 4101921.0cRO6RppXc () merkaba http://lists.kde.org/?l=kdepim-users&m=142253985206516&w=2 Similar it is with kdepim-runtime and kdepimlibs, but they need a bit more dependencies. Instead of git checkout -b 1.13 origin/1.13 you need to checkout the origin/KDE/4.14 branch after the clone. And of course the remote repo URLs are different. As said, the new akonadi server helps a lot with MySQL load, but in the end I still see KMail and Akonadi not talking to each other with KMail not responding anymore to user requests in any usable way (just displays blue wait message), so even the latest updates for KDE SC 4.14 / Akonadi for Qt 4 do not fix that. If you want just the MySQL performance improvements its sufficient to compile Akonadi server as I described in above post. > > And the Plasma 5 / Qt 5 port of KDEPIM is not yet ready as far as I am > > aware of. Even that will use the Akonadi as we now it today, so it may > > have still similar shortcomings and bugs. > > This means that parts of the KDE SC will use Plasma 5 / Qt 5, whereas > other parts (KDEPIM) still use Plasma 4 / Qt4 ? Will that work? It sure > wouldn't make sense to run Akonadi4 and Akonadi5 simultaneously.. ? Is > Akonadi only used by KDEPIM? Yes, it will work. KDE 4 applications will work with KDE 5 as desktop. But for Akonadi you want to have it all Qt 5 / Plasma 5 or all Qt 4 and KDE SC 4. > > I still use POP3 for my main private > > account, but also IMAP is fragile, with Exchange, but there Exchange > > has at least a fair share in causing the trouble. > > You mean Microsoft Exchange? Yes. > > Yet, reporting those won´t magically make them go away and upstream > > could need more developers. Thats why I hope that the adoption of > > KDEPIM for Munich will help its overall stability. Cause frankly, > > from what I see so far, it is not enterprise ready at all. > > > > So for a clearly defined setup where you control server and client I > > think for IMAP it can work okay. Not excellent, but okay. > > I use the mail server of my web hoster, and download the mail to my > desktop system, using POP3 - no need for IMAP. It's simple this way. Well thats what I do privately, although I administrate the IMAP server on my server VM. > > In case you want to go that route, I suggest you also subscribe to > > kdepim- users and probably kde-pim upstream mailinglists via > > lists.kde.org and be prepared to deal with any issues you see, report > > bugs, help with bug triaging and try to be patient. > > Yes, that's what it amounts to. Well its no use to pretend anything different. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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/1536431.1AxChCiYh1@merkaba
Re: KDEPIM issues (was: Re: Bugs bugs bugs)
On Monday, 2015-02-23, 18:39:40, Volker Wysk wrote: > Am Sonntag, 22. Februar 2015, 16:13:10 schrieb Martin Steigerwald: > > Am Samstag, 21. Februar 2015, 16:32:33 schrieb Volker Wysk: > > And the Plasma 5 / Qt 5 port of KDEPIM is not yet ready as far as I am > > aware of. Even that will use the Akonadi as we now it today, so it may > > have still similar shortcomings and bugs. > > This means that parts of the KDE SC will use Plasma 5 / Qt 5, whereas other > parts (KDEPIM) still use Plasma 4 / Qt4 ? There are only few applications that use Plasma as a technology, e.g. Amarok. Applications already do not depend on Plasma as a desktop shell. > Will that work? Yes, all libraries should be able to coexist. > It sure wouldn't make sense to run Akonadi4 and Akonadi5 simultaneously.. ? Right. My hope is that Akonadi Next will still be able to service connections from clients using on Qt4 based Akonadi client libraries. The Qt5 version of Akonadi does since it is the same software, just built with Qt5. > Is Akonadi only used by KDEPIM? No. Contacts are probably the most widely used data accessed through Akonadi, email is probably the least widely used. Cheers, Kevin signature.asc Description: This is a digitally signed message part.
Re: KDEPIM issues (was: Re: Bugs bugs bugs)
Hey, > Well, that may not change *that much* with a newer version. 4.14.5 has > some bugs fixed, but I compiled kdepim-runtime and kdepimlibs 4.14.5 on top > of KDEPIM 4.14.2 as packages by debian and I still have most of the > issues. I also run akonadiserver 1.13 branch from git with the MySQL > optimizations, and while that helps with MySQL load, I still have KMail > and Akonadi seem to disconnect with each other at times. It is quite hard to track issues down, if they happen once in a while. I think all kdepim devs so am I try to fix these stuff, but hunting anything non reproducable is a lot of work. > And the Plasma 5 / Qt 5 port of KDEPIM is not yet ready as far as I am > aware of. Even that will use the Akonadi as we now it today, so it may > have still similar shortcomings and bugs. > There is Akonadi Next in prototyping by Aaron Seigo and Christian > Mollekopf, but this is far from finished so far. The porting work for qt5 is done in master - but we won't release it until the new api for akonadi next is outlined. We do not want to stick another release cycle with the current api for akonadi. The current plan is to release in a year. Until than only bugfixes are released for the qt4 version. > I am not sure whether all the fixes for the KDEPIM deployment in Munich > have gone upstream. I had hoped that these would fix quite some of the > longer term issues of Akonadi, but whatever trickled upstream so far did > not seem to fix it. Neither the bugfixes nor enhancment havn't got upstream - they are only available at github and on our obs: https://github.com/kolab-groupware/kdepim https://obs.kolabsys.com/project/show/Kontact:4.13:Development Well hopefully the next weeks give us time to push things upstream. > What could work quite well, and thats why I think for Munich it could > work, would be to have some decent (!) IMAP server like Dovecot (not > Exchange!) together with KMail. kolab uses cycrus as imap server. But dovecot ( I use this personaly) also plays very nicely with kmail. > KDEPIM / Akonadi I think still needs robustness work. But someone has to > do it. And unless I actually contribute to that, I know I need to wait > until someone does. Well akonadi was the first try of such a middelware and we learned a lot of things. And we now know, that was bad/good design descisions, these we went into akonadi next. > In case you want to go that route, I suggest you also subscribe to kdepim- > users and probably kde-pim upstream mailinglists via lists.kde.org and be > prepared to deal with any issues you see, report bugs, help with bug > triaging and try to be patient. > > Thats the situation as I see it today after having myself investing quite > some time into bug reporting, reading up bugs, trying to fix things for me > without going into developing. Doing that might be the next step, but from > the performance fix for Maildir´s KDEPIM devels guided me to some time ago > I got the impression that the Akonadi code base wants some time to > understand it enough to fix any of the longer term, in my eyes, probably > fundamental, issues with it. cewl - I'm looking forward to see more of your work in kdepim; if there is anything where I can assist you - feel free to contact me. regards, sandro -- 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/1457674.DbvhxYp7N6@tabin.local
Re: KDEPIM issues (was: Re: Bugs bugs bugs)
On Sunday 22 February 2015 16:13:10 Martin Steigerwald wrote: > What could work quite well, and thats why I think for Munich it could > work, would be to have some decent (!) IMAP server like Dovecot (not > Exchange!) together with KMail. I have this setup here and indeed dovecot-imap, akonadi and kmail work nicely together for me. All are Debian jessie boxes. Rainer -- Rainer Dorsch http://bokomoko.de/ -- 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/1799689.gj3HT5iYvv@blackbox
Re: KDEPIM issues (was: Re: Bugs bugs bugs)
Am Sonntag, 22. Februar 2015, 16:13:10 schrieb Martin Steigerwald: > Am Samstag, 21. Februar 2015, 16:32:33 schrieb Volker Wysk: > > I've never used the experimental branch. When will the packages migrate > > to Unstable? > > They won´t before Jessie release. > > Maybe KDEPIM 4.14.5 could make it to unstable as its only bug fixes, but > that would need an exception from the release team as well in this late > state of Jessie freeze, I think – unless they fix RC bugs (and only! them). > The freezing / release policy is clarified in some document I don´t have > the URL at hand at the moment, should be easy to find. This should be it: https://release.debian.org/jessie/freeze_policy.html It doesn't predict when Jessie will be released, but I get the impression that it won't be much longer. > > > For me beside KDEPIM KDE / Plasma 4.14.2 really works quite good. > > > KDEPIM basically works, but there are still a lot of open issues. > > > > Exactly... > > Well, that may not change *that much* with a newer version. 4.14.5 has > some bugs fixed, but I compiled kdepim-runtime and kdepimlibs 4.14.5 on top > of KDEPIM 4.14.2 as packages by debian and I still have most of the > issues. What do you mean by "compile on top of"? What sources are you using? I can find only 4.14.3 on kde.org, not 4.14.5. > And the Plasma 5 / Qt 5 port of KDEPIM is not yet ready as far as I am > aware of. Even that will use the Akonadi as we now it today, so it may > have still similar shortcomings and bugs. This means that parts of the KDE SC will use Plasma 5 / Qt 5, whereas other parts (KDEPIM) still use Plasma 4 / Qt4 ? Will that work? It sure wouldn't make sense to run Akonadi4 and Akonadi5 simultaneously.. ? Is Akonadi only used by KDEPIM? > I still use POP3 for my main private > account, but also IMAP is fragile, with Exchange, but there Exchange has > at least a fair share in causing the trouble. You mean Microsoft Exchange? > What could work quite well, and thats why I think for Munich it could > work, would be to have some decent (!) IMAP server like Dovecot (not > Exchange!) together with KMail. > So while for me KDEPIM and Akonadi got a lot better, like Nepomuk got, > before Vishesh replaced it by Baloo which works even better, KDEPIM and I > think especially Akonadi still has a fair share of issues. I think the > majority of the bugs I reported for KDE / Plasma in the last 2 or 3 years > with bugs.kde.org has been with Akonadi and KDEPIM. I see... > Yet, reporting those won´t magically make them go away and upstream could > need more developers. Thats why I hope that the adoption of KDEPIM for > Munich will help its overall stability. Cause frankly, from what I see so > far, it is not enterprise ready at all. > So for a clearly defined setup where you control server and client I think > for IMAP it can work okay. Not excellent, but okay. I use the mail server of my web hoster, and download the mail to my desktop system, using POP3 - no need for IMAP. It's simple this way. > In case you want to go that route, I suggest you also subscribe to kdepim- > users and probably kde-pim upstream mailinglists via lists.kde.org and be > prepared to deal with any issues you see, report bugs, help with bug > triaging and try to be patient. Yes, that's what it amounts to. Bye Volker -- 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/15321979.eiy9pJ50aW@debian
KDEPIM issues (was: Re: Bugs bugs bugs)
Hi Volker, Am Samstag, 21. Februar 2015, 16:32:33 schrieb Volker Wysk: > Am Samstag, 21. Februar 2015, 00:15:29 schrieb Martin Steigerwald: > > Am Montag, 16. Februar 2015, 09:05:38 schrieb Volker Wysk: > > > Hello! > > > > Hi Volker, > > > > > Actually, I'm a KDE fan. But it - still - has that many bugs, that I > > > couldn't recommend it. > > > > > > "Still" means 4.14.2, the version in Debian-unstable. Does anybody > > > know > > > when KDE5 will arrive in Debian? Or has even tried it? > > > > > > I've tried to compile KDE from the sources, but failed. > > > > Maxy uploads a lot of KDE Frameworks 5.6 and Plasma 5 packages into > > Debian experimental since quite some weeks. It seems they are not yet > > build to binary packages tough. I bet we will read about it when they > > are ready. > > > > Maxy also uploaded some 4.14.5 packages, I think for KDEPIM, to > > experimental as well. I think 4.14.5 packages would be good for stable > > as well, but well… > > Sounds good. > > I've never used the experimental branch. When will the packages migrate > to Unstable? They won´t before Jessie release. Maybe KDEPIM 4.14.5 could make it to unstable as its only bug fixes, but that would need an exception from the release team as well in this late state of Jessie freeze, I think – unless they fix RC bugs (and only! them). The freezing / release policy is clarified in some document I don´t have the URL at hand at the moment, should be easy to find. > > For me beside KDEPIM KDE / Plasma 4.14.2 really works quite good. > > KDEPIM basically works, but there are still a lot of open issues. > > Exactly... Well, that may not change *that much* with a newer version. 4.14.5 has some bugs fixed, but I compiled kdepim-runtime and kdepimlibs 4.14.5 on top of KDEPIM 4.14.2 as packages by debian and I still have most of the issues. I also run akonadiserver 1.13 branch from git with the MySQL optimizations, and while that helps with MySQL load, I still have KMail and Akonadi seem to disconnect with each other at times. And the Plasma 5 / Qt 5 port of KDEPIM is not yet ready as far as I am aware of. Even that will use the Akonadi as we now it today, so it may have still similar shortcomings and bugs. There is Akonadi Next in prototyping by Aaron Seigo and Christian Mollekopf, but this is far from finished so far. So I think there are no updates available to KDEPIM and Akonadi at the moment that will fix those longer existing issues. So I think if you want to be without those bugs *now*, you can only use a different set of applications or try to fix the bugs yourself or get someone paid to do it. I am not sure whether all the fixes for the KDEPIM deployment in Munich have gone upstream. I had hoped that these would fix quite some of the longer term issues of Akonadi, but whatever trickled upstream so far did not seem to fix it. I sure hope that KDEPIM and Akonadi is performaning better in the Munich setup than for me personally. I still use POP3 for my main private account, but also IMAP is fragile, with Exchange, but there Exchange has at least a fair share in causing the trouble. What could work quite well, and thats why I think for Munich it could work, would be to have some decent (!) IMAP server like Dovecot (not Exchange!) together with KMail. So while for me KDEPIM and Akonadi got a lot better, like Nepomuk got, before Vishesh replaced it by Baloo which works even better, KDEPIM and I think especially Akonadi still has a fair share of issues. I think the majority of the bugs I reported for KDE / Plasma in the last 2 or 3 years with bugs.kde.org has been with Akonadi and KDEPIM. Yet, reporting those won´t magically make them go away and upstream could need more developers. Thats why I hope that the adoption of KDEPIM for Munich will help its overall stability. Cause frankly, from what I see so far, it is not enterprise ready at all. But consider, with Kolab using a decent IMAP server (and it does to my knowledge, especially if Dovecot is used) and smaller accounts than I have, it may well work okay. And I have seen slides that a ton of data has been migrated to it and it works okay. So this is just my personal impression that I draw from my three setups I have and in no way representative. I read less about serious issues in kdepim-users these days. Whether that means they have gone away for some users or the users just silently put up with it or use something different, I don´t know. So for a clearly defined setup where you control server and client I think for IMAP it can work okay. Not excellent, but okay. KDEPIM / Akonadi I think still needs robustness work. But someone has to do it. And unless I actually contribute to that, I know I need to wait until someone does. I still think KMail is simply the best MUA for desktops I have *ever* seen. So I put up with any issues, fine tuning my setup with some tricks I learned recently (SizeTreshold=32768, was menti