Re: KDEPIM ready to be more broadly tested (libkpim.*4)

[inkbottle]

On Friday, July 29, 2016 8:40:31 PM CEST you wrote:
> Kopete is still developed and being ported to Frameworks.
I must have mistaken it for something else (my bad anyway).

> kde-standard is a Debian-specific metapackage, which probably has no sense
> given the evolution of the meaning of "KDE".
> 
> Ciao

Re: KDEPIM ready to be more broadly tested (libkpim.*4)

[Luigi Toscano]

Il 29 luglio 2016 20:30:43 CEST, inkbottle  ha scritto:
>Hi,
>
>So I did eventually upgraded to new KDEPIM.
>
>When doing my upgrade I saw some "libkpimindent.*4" and more generally 
>"libkpim.*4" things. I resolved to remove them for the sake of
>cleanness...
>
>Hence I had to remove "kopete" and hence kde-standard too.
>
>I understood kopete is something of the past (?); if so it could be
>removed 
>from kde-standard: is kde-standard a Debian thing?


Kopete is still developed and being ported to Frameworks. 
kde-standard is a Debian-specific metapackage, which probably has no sense 
given the evolution of the meaning of "KDE".

Ciao

-- 
Luigi

Re: KDEPIM ready to be more broadly tested (libkpim.*4)

[inkbottle]

Hi,

So I did eventually upgraded to new KDEPIM.

When doing my upgrade I saw some "libkpimindent.*4" and more generally 
"libkpim.*4" things. I resolved to remove them for the sake of cleanness...

Hence I had to remove "kopete" and hence kde-standard too.

I understood kopete is something of the past (?); if so it could be removed 
from kde-standard: is kde-standard a Debian thing?

Chris

Re: KDEPIM ready to be more broadly tested

[inkbottle]

On Thursday, July 28, 2016 16:54:43 Tim Ruehsen wrote:

> So, you are on Sid/unstable ?
> And you did
> apt-get update && apt-get dist-upgrade before ?
> 
> okular never stopped working here and I use it quite often.
> 
> $ dpkg -l '*okular*'
> ii  libokularcore6  4:15.08.3-1  amd64
> libraries for the Okular document viewer
> ii  libokularcore7  4:16.04.2-1  amd64
> libraries for the Okular document viewer
> ii  okular  4:16.04.2-1  amd64
> universal document viewer
> ii  okular-extra-backends   4:16.04.2-1  amd64
> additional document format support for Okular

Looking at the messages here, and also at 
https://qa.debian.org/developer.php?login=debian-qt-kde%40lists.debian.org,
I was a bit overenthusiastic, and thought version numbers beginning with "4:4|
4:15" was mostly something of the past.
The output output of:

aptitude search -F"%p; %V; %d" -t sid '?installed(?version("4:4|
4:15")?maintainer(debian-qt-kde))'|egrep "4:4|4:15"|wc -l

might not be so relevant, but it yields a "surprising?" 132 on my system.

Chris

> 
> But I guess libokularcore6 is orphaned and could be purged.
> 
> What exactly is your problem now ?
> 
> Tim

Re: KDEPIM ready to be more broadly tested

[Volker Groll]

Am Freitag, 29. Juli 2016, 13:13:45 CEST schrieb Tim Ruehsen:
> On Friday, July 29, 2016 10:08:52 AM CEST Volker Groll wrote:
> > Am Donnerstag, 28. Juli 2016, 21:26:03 CEST schrieb Tim Rühsen:
> > > On Donnerstag, 28. Juli 2016 17:27:25 CEST Volker Groll wrote:
> > > > Am Donnerstag, 28. Juli 2016, 16:54:43 CEST schrieb Tim Ruehsen:
> > > > > On Thursday, July 28, 2016 4:35:12 PM CEST Volker Groll wrote:
> > > > > > Hello Tim,
> > > > > > 
> > > > > > Am Donnerstag, 28. Juli 2016, 14:06:14 CEST schrieb Tim Ruehsen:
> > > > > > > On Thursday, July 28, 2016 1:46:55 PM CEST Volker Groll wrote:
> > > > > > > > Hi everybody,
> > > > > > > > 
> > > > > > > > I followed Tim's journey through akonadi the last days and
> > > > > > > > reproduced
> > > > > > > > the steps here with no success. Last night I removed
> > > > > > > > (hopefully)
> > > > > > > > all
> > > > > > > > stuff
> > > > > > > > from .config, .local, .kde which seems to me connected to
> > > > > > > > baloo
> > > > > > > > or
> > > > > > > > akonadi
> > > > > > > > or any parts of kontact modules.
> > > > > > > > Then I recreated every mail stuff again => no success, the
> > > > > > > > normal
> > > > > > > > search
> > > > > > > > above the mai list is working, akonadi search gives either
> > > > > > > > nothing
> > > > > > > > or
> > > > > > > > stupid results not connected to the search.
> > > > > > > > 
> > > > > > > > I also throwed 4:4.14 packages with help of deborphan out of
> > > > > > > > my
> > > > > > > > system
> > > > > > > > but especially libakonadi stuff is at 4:4.14.10-5?
> > > > > > > 
> > > > > > > Here we talked about Sid/unstable having 16.04.x.
> > > > > > > 
> > > > > > > $ dpkg -l|egrep 'akonadi|baloo|kdepim'
> > > > > > > 
> > > > > > > I can't say anything about the 4.14. stuff except that it was
> > > > > > > working
> > > > > > > before I went to 16.04.
> > > > > > > 
> > > > > > > Regards, Tim
> > > > > > 
> > > > > > Thanks for your answer.
> > > > > > 
> > > > > > I removed now all 4.14 stuff related to akondi|baloo|kdepim.
> > > > > > Both digikam and kde-utils (and kde-full!) pulled the old stuff,
> > > > > > while
> > > > > > installing libakonadi-kf5 won't complain, so I thought it is ok.
> > > > > > Now all akonadi stuff is 4:16.04.x or 16.04.x.
> > > > > > BTW: what means the leading '4'?
> > > > > 
> > > > > No idea.
> > > > > 
> > > > > > Also agentIndexingVersion=4 in baloorc gives a hint to version 4?
> > > > > 
> > > > > No, it is some internal protocol version.
> > > > > 
> > > > > > Proceedings are of course:
> > > > > > stop akonadi and baloo, remove search_db, changed baloorc
> > > > > > initialIndexingDone=false and reboot.
> > > > > > The hell: No change.
> > > > > > 
> > > > > > And yes, with 4.14 it worked with minor flaws on display.
> > > > > > 
> > > > > > There is also more old stuff of kde around, also parts of 15.x
> > > > > > But I need at least okular.
> > > > > 
> > > > > So, you are on Sid/unstable ?
> > > > > And you did
> > > > > apt-get update && apt-get dist-upgrade before ?
> > > > 
> > > > Yes, I came from stretch, and honestly I used aptitude dist-upgrade.
> > > > apt-get dist-upgrade does not want apply any changes right now
> > > > 
> > > > > okular never stopped working here and I use it quite often.
> > > > > 
> > > > > $ dpkg -l '*okular*'
> > > > > ii  libokularcore6  4:15.08.3-1  amd64
> > > > > libraries for the Okular document viewer
> > > > > ii  libokularcore7  4:16.04.2-1  amd64
> > > > > libraries for the Okular document viewer
> > > > > ii  okular  4:16.04.2-1  amd64
> > > > > universal document viewer
> > > > > ii  okular-extra-backends   4:16.04.2-1  amd64
> > > > > additional document format support for Okular
> > > > > 
> > > > > But I guess libokularcore6 is orphaned and could be purged.
> > > > 
> > > > Sorry misleading you.
> > > > I checked most of my installed kde packages to be on 16.04
> > > > and started to throw away everything older.
> > > > I of course installed the needed packages again.
> > > > By this: For me okular is working without libokularcore7.
> > > 
> > > okular 16.04.2-1 has a dependency: libokularcore7 (= 4:16.04.2-1)
> > > You can see this via
> > > $ apt-cache show okular
> > > 
> > > > Both baloo and akonadi are not working as expected:
> > > > On baloo when I try to index file contents it hangs indefinitely
> > > > and I cannot find any open file handler within baloo_indexer or
> > > > baloo_file_extractor hinting to a file causing this.

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Friday, July 29, 2016 10:08:52 AM CEST Volker Groll wrote:
> Am Donnerstag, 28. Juli 2016, 21:26:03 CEST schrieb Tim Rühsen:
> > On Donnerstag, 28. Juli 2016 17:27:25 CEST Volker Groll wrote:
> > > Am Donnerstag, 28. Juli 2016, 16:54:43 CEST schrieb Tim Ruehsen:
> > > > On Thursday, July 28, 2016 4:35:12 PM CEST Volker Groll wrote:
> > > > > Hello Tim,
> > > > > 
> > > > > Am Donnerstag, 28. Juli 2016, 14:06:14 CEST schrieb Tim Ruehsen:
> > > > > > On Thursday, July 28, 2016 1:46:55 PM CEST Volker Groll wrote:
> > > > > > > Hi everybody,
> > > > > > > 
> > > > > > > I followed Tim's journey through akonadi the last days and
> > > > > > > reproduced
> > > > > > > the steps here with no success. Last night I removed (hopefully)
> > > > > > > all
> > > > > > > stuff
> > > > > > > from .config, .local, .kde which seems to me connected to baloo
> > > > > > > or
> > > > > > > akonadi
> > > > > > > or any parts of kontact modules.
> > > > > > > Then I recreated every mail stuff again => no success, the
> > > > > > > normal
> > > > > > > search
> > > > > > > above the mai list is working, akonadi search gives either
> > > > > > > nothing
> > > > > > > or
> > > > > > > stupid results not connected to the search.
> > > > > > > 
> > > > > > > I also throwed 4:4.14 packages with help of deborphan out of my
> > > > > > > system
> > > > > > > but especially libakonadi stuff is at 4:4.14.10-5?
> > > > > > 
> > > > > > Here we talked about Sid/unstable having 16.04.x.
> > > > > > 
> > > > > > $ dpkg -l|egrep 'akonadi|baloo|kdepim'
> > > > > > 
> > > > > > I can't say anything about the 4.14. stuff except that it was
> > > > > > working
> > > > > > before I went to 16.04.
> > > > > > 
> > > > > > Regards, Tim
> > > > > 
> > > > > Thanks for your answer.
> > > > > 
> > > > > I removed now all 4.14 stuff related to akondi|baloo|kdepim.
> > > > > Both digikam and kde-utils (and kde-full!) pulled the old stuff,
> > > > > while
> > > > > installing libakonadi-kf5 won't complain, so I thought it is ok.
> > > > > Now all akonadi stuff is 4:16.04.x or 16.04.x.
> > > > > BTW: what means the leading '4'?
> > > > 
> > > > No idea.
> > > > 
> > > > > Also agentIndexingVersion=4 in baloorc gives a hint to version 4?
> > > > 
> > > > No, it is some internal protocol version.
> > > > 
> > > > > Proceedings are of course:
> > > > > stop akonadi and baloo, remove search_db, changed baloorc
> > > > > initialIndexingDone=false and reboot.
> > > > > The hell: No change.
> > > > > 
> > > > > And yes, with 4.14 it worked with minor flaws on display.
> > > > > 
> > > > > There is also more old stuff of kde around, also parts of 15.x
> > > > > But I need at least okular.
> > > > 
> > > > So, you are on Sid/unstable ?
> > > > And you did
> > > > apt-get update && apt-get dist-upgrade before ?
> > > 
> > > Yes, I came from stretch, and honestly I used aptitude dist-upgrade.
> > > apt-get dist-upgrade does not want apply any changes right now
> > > 
> > > > okular never stopped working here and I use it quite often.
> > > > 
> > > > $ dpkg -l '*okular*'
> > > > ii  libokularcore6  4:15.08.3-1  amd64
> > > > libraries for the Okular document viewer
> > > > ii  libokularcore7  4:16.04.2-1  amd64
> > > > libraries for the Okular document viewer
> > > > ii  okular  4:16.04.2-1  amd64
> > > > universal document viewer
> > > > ii  okular-extra-backends   4:16.04.2-1  amd64
> > > > additional document format support for Okular
> > > > 
> > > > But I guess libokularcore6 is orphaned and could be purged.
> > > 
> > > Sorry misleading you.
> > > I checked most of my installed kde packages to be on 16.04
> > > and started to throw away everything older.
> > > I of course installed the needed packages again.
> > > By this: For me okular is working without libokularcore7.
> > 
> > okular 16.04.2-1 has a dependency: libokularcore7 (= 4:16.04.2-1)
> > You can see this via
> > $ apt-cache show okular
> > 
> > > Both baloo and akonadi are not working as expected:
> > > On baloo when I try to index file contents it hangs indefinitely
> > > and I cannot find any open file handler within baloo_indexer or
> > > baloo_file_extractor hinting to a file causing this.
> > > BTW: with dolphin4 I can search (and find) the content of files!
> > 
> > baloo does file indexing, akonadi does email indexing (and some more).
> 
> I think I understand the basic purpose, but I miss tools and/or instructions
> to track down errors from a user perspective.
> Which (config) files to check / remove, access akonadi from command line,
> check caching stuff, databases? Then it would be possible to ask more
> precise for assistance. Exaggregated  I can only say: Search does not work.

I can currently 'akonadictl restart' without (serious) errors.


One type of error that I just fixed:
"AgentManager::agentInstanceSynchronizeCollection"  Agent instance  
"akonadi_mixedmaildir_resource_0"  has no re

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Friday, July 29, 2016 10:08:52 AM CEST Volker Groll wrote:
> Am Donnerstag, 28. Juli 2016, 21:26:03 CEST schrieb Tim Rühsen:
> > On Donnerstag, 28. Juli 2016 17:27:25 CEST Volker Groll wrote:
> > > Am Donnerstag, 28. Juli 2016, 16:54:43 CEST schrieb Tim Ruehsen:
> > > > On Thursday, July 28, 2016 4:35:12 PM CEST Volker Groll wrote:
> > > > > Hello Tim,
> > > > > 
> > > > > Am Donnerstag, 28. Juli 2016, 14:06:14 CEST schrieb Tim Ruehsen:
> > > > > > On Thursday, July 28, 2016 1:46:55 PM CEST Volker Groll wrote:
> > > > > > > Hi everybody,
> > > > > > > 
> > > > > > > I followed Tim's journey through akonadi the last days and
> > > > > > > reproduced
> > > > > > > the steps here with no success. Last night I removed (hopefully)
> > > > > > > all
> > > > > > > stuff
> > > > > > > from .config, .local, .kde which seems to me connected to baloo
> > > > > > > or
> > > > > > > akonadi
> > > > > > > or any parts of kontact modules.
> > > > > > > Then I recreated every mail stuff again => no success, the
> > > > > > > normal
> > > > > > > search
> > > > > > > above the mai list is working, akonadi search gives either
> > > > > > > nothing
> > > > > > > or
> > > > > > > stupid results not connected to the search.
> > > > > > > 
> > > > > > > I also throwed 4:4.14 packages with help of deborphan out of my
> > > > > > > system
> > > > > > > but especially libakonadi stuff is at 4:4.14.10-5?
> > > > > > 
> > > > > > Here we talked about Sid/unstable having 16.04.x.
> > > > > > 
> > > > > > $ dpkg -l|egrep 'akonadi|baloo|kdepim'
> > > > > > 
> > > > > > I can't say anything about the 4.14. stuff except that it was
> > > > > > working
> > > > > > before I went to 16.04.
> > > > > > 
> > > > > > Regards, Tim
> > > > > 
> > > > > Thanks for your answer.
> > > > > 
> > > > > I removed now all 4.14 stuff related to akondi|baloo|kdepim.
> > > > > Both digikam and kde-utils (and kde-full!) pulled the old stuff,
> > > > > while
> > > > > installing libakonadi-kf5 won't complain, so I thought it is ok.
> > > > > Now all akonadi stuff is 4:16.04.x or 16.04.x.
> > > > > BTW: what means the leading '4'?
> > > > 
> > > > No idea.
> > > > 
> > > > > Also agentIndexingVersion=4 in baloorc gives a hint to version 4?
> > > > 
> > > > No, it is some internal protocol version.
> > > > 
> > > > > Proceedings are of course:
> > > > > stop akonadi and baloo, remove search_db, changed baloorc
> > > > > initialIndexingDone=false and reboot.
> > > > > The hell: No change.
> > > > > 
> > > > > And yes, with 4.14 it worked with minor flaws on display.
> > > > > 
> > > > > There is also more old stuff of kde around, also parts of 15.x
> > > > > But I need at least okular.
> > > > 
> > > > So, you are on Sid/unstable ?
> > > > And you did
> > > > apt-get update && apt-get dist-upgrade before ?
> > > 
> > > Yes, I came from stretch, and honestly I used aptitude dist-upgrade.
> > > apt-get dist-upgrade does not want apply any changes right now
> > > 
> > > > okular never stopped working here and I use it quite often.
> > > > 
> > > > $ dpkg -l '*okular*'
> > > > ii  libokularcore6  4:15.08.3-1  amd64
> > > > libraries for the Okular document viewer
> > > > ii  libokularcore7  4:16.04.2-1  amd64
> > > > libraries for the Okular document viewer
> > > > ii  okular  4:16.04.2-1  amd64
> > > > universal document viewer
> > > > ii  okular-extra-backends   4:16.04.2-1  amd64
> > > > additional document format support for Okular
> > > > 
> > > > But I guess libokularcore6 is orphaned and could be purged.
> > > 
> > > Sorry misleading you.
> > > I checked most of my installed kde packages to be on 16.04
> > > and started to throw away everything older.
> > > I of course installed the needed packages again.
> > > By this: For me okular is working without libokularcore7.
> > 
> > okular 16.04.2-1 has a dependency: libokularcore7 (= 4:16.04.2-1)
> > You can see this via
> > $ apt-cache show okular
> > 
> > > Both baloo and akonadi are not working as expected:
> > > On baloo when I try to index file contents it hangs indefinitely
> > > and I cannot find any open file handler within baloo_indexer or
> > > baloo_file_extractor hinting to a file causing this.
> > > BTW: with dolphin4 I can search (and find) the content of files!
> > 
> > baloo does file indexing, akonadi does email indexing (and some more).
> 
> I think I understand the basic purpose, but I miss tools and/or instructions
> to track down errors from a user perspective.
> Which (config) files to check / remove, access akonadi from command line,
> check caching stuff, databases? Then it would be possible to ask more
> precise for assistance. Exaggregated  I can only say: Search does not work.

And I have to say: Yes, you are right :-(

I am back in the office with that machine where I thought searching now works, 
the machine that this discussion was about ...

Now...
- searching in a specific folder give

Re: KDEPIM ready to be more broadly tested

[Volker Groll]

Am Donnerstag, 28. Juli 2016, 21:26:03 CEST schrieb Tim Rühsen:
> On Donnerstag, 28. Juli 2016 17:27:25 CEST Volker Groll wrote:
> > Am Donnerstag, 28. Juli 2016, 16:54:43 CEST schrieb Tim Ruehsen:
> > > On Thursday, July 28, 2016 4:35:12 PM CEST Volker Groll wrote:
> > > > Hello Tim,
> > > > 
> > > > Am Donnerstag, 28. Juli 2016, 14:06:14 CEST schrieb Tim Ruehsen:
> > > > > On Thursday, July 28, 2016 1:46:55 PM CEST Volker Groll wrote:
> > > > > > Hi everybody,
> > > > > > 
> > > > > > I followed Tim's journey through akonadi the last days and
> > > > > > reproduced
> > > > > > the steps here with no success. Last night I removed (hopefully)
> > > > > > all
> > > > > > stuff
> > > > > > from .config, .local, .kde which seems to me connected to baloo or
> > > > > > akonadi
> > > > > > or any parts of kontact modules.
> > > > > > Then I recreated every mail stuff again => no success, the normal
> > > > > > search
> > > > > > above the mai list is working, akonadi search gives either nothing
> > > > > > or
> > > > > > stupid results not connected to the search.
> > > > > > 
> > > > > > I also throwed 4:4.14 packages with help of deborphan out of my
> > > > > > system
> > > > > > but especially libakonadi stuff is at 4:4.14.10-5?
> > > > > 
> > > > > Here we talked about Sid/unstable having 16.04.x.
> > > > > 
> > > > > $ dpkg -l|egrep 'akonadi|baloo|kdepim'
> > > > > 
> > > > > I can't say anything about the 4.14. stuff except that it was
> > > > > working
> > > > > before I went to 16.04.
> > > > > 
> > > > > Regards, Tim
> > > > 
> > > > Thanks for your answer.
> > > > 
> > > > I removed now all 4.14 stuff related to akondi|baloo|kdepim.
> > > > Both digikam and kde-utils (and kde-full!) pulled the old stuff, while
> > > > installing libakonadi-kf5 won't complain, so I thought it is ok.
> > > > Now all akonadi stuff is 4:16.04.x or 16.04.x.
> > > > BTW: what means the leading '4'?
> > > 
> > > No idea.
> > > 
> > > > Also agentIndexingVersion=4 in baloorc gives a hint to version 4?
> > > 
> > > No, it is some internal protocol version.
> > > 
> > > > Proceedings are of course:
> > > > stop akonadi and baloo, remove search_db, changed baloorc
> > > > initialIndexingDone=false and reboot.
> > > > The hell: No change.
> > > > 
> > > > And yes, with 4.14 it worked with minor flaws on display.
> > > > 
> > > > There is also more old stuff of kde around, also parts of 15.x
> > > > But I need at least okular.
> > > 
> > > So, you are on Sid/unstable ?
> > > And you did
> > > apt-get update && apt-get dist-upgrade before ?
> > 
> > Yes, I came from stretch, and honestly I used aptitude dist-upgrade.
> > apt-get dist-upgrade does not want apply any changes right now
> > 
> > > okular never stopped working here and I use it quite often.
> > > 
> > > $ dpkg -l '*okular*'
> > > ii  libokularcore6  4:15.08.3-1  amd64
> > > libraries for the Okular document viewer
> > > ii  libokularcore7  4:16.04.2-1  amd64
> > > libraries for the Okular document viewer
> > > ii  okular  4:16.04.2-1  amd64
> > > universal document viewer
> > > ii  okular-extra-backends   4:16.04.2-1  amd64
> > > additional document format support for Okular
> > > 
> > > But I guess libokularcore6 is orphaned and could be purged.
> > 
> > Sorry misleading you.
> > I checked most of my installed kde packages to be on 16.04
> > and started to throw away everything older.
> > I of course installed the needed packages again.
> > By this: For me okular is working without libokularcore7.
> 
> okular 16.04.2-1 has a dependency: libokularcore7 (= 4:16.04.2-1)
> You can see this via
> $ apt-cache show okular
> 
> > Both baloo and akonadi are not working as expected:
> > On baloo when I try to index file contents it hangs indefinitely
> > and I cannot find any open file handler within baloo_indexer or
> > baloo_file_extractor hinting to a file causing this.
> > BTW: with dolphin4 I can search (and find) the content of files!
> 
> baloo does file indexing, akonadi does email indexing (and some more).
I think I understand the basic purpose, but I miss tools and/or instructions
to track down errors from a user perspective.
Which (config) files to check / remove, access akonadi from command line,
check caching stuff, databases? Then it would be possible to ask more
precise for assistance. Exaggregated  I can only say: Search does not work.

Re: KDEPIM ready to be more broadly tested

[Tim Rühsen]

On Donnerstag, 28. Juli 2016 17:27:25 CEST Volker Groll wrote:
> Am Donnerstag, 28. Juli 2016, 16:54:43 CEST schrieb Tim Ruehsen:
> > On Thursday, July 28, 2016 4:35:12 PM CEST Volker Groll wrote:
> > > Hello Tim,
> > > 
> > > Am Donnerstag, 28. Juli 2016, 14:06:14 CEST schrieb Tim Ruehsen:
> > > > On Thursday, July 28, 2016 1:46:55 PM CEST Volker Groll wrote:
> > > > > Hi everybody,
> > > > > 
> > > > > I followed Tim's journey through akonadi the last days and
> > > > > reproduced
> > > > > the steps here with no success. Last night I removed (hopefully) all
> > > > > stuff
> > > > > from .config, .local, .kde which seems to me connected to baloo or
> > > > > akonadi
> > > > > or any parts of kontact modules.
> > > > > Then I recreated every mail stuff again => no success, the normal
> > > > > search
> > > > > above the mai list is working, akonadi search gives either nothing
> > > > > or
> > > > > stupid results not connected to the search.
> > > > > 
> > > > > I also throwed 4:4.14 packages with help of deborphan out of my
> > > > > system
> > > > > but especially libakonadi stuff is at 4:4.14.10-5?
> > > > 
> > > > Here we talked about Sid/unstable having 16.04.x.
> > > > 
> > > > $ dpkg -l|egrep 'akonadi|baloo|kdepim'
> > > > 
> > > > I can't say anything about the 4.14. stuff except that it was working
> > > > before I went to 16.04.
> > > > 
> > > > Regards, Tim
> > > 
> > > Thanks for your answer.
> > > 
> > > I removed now all 4.14 stuff related to akondi|baloo|kdepim.
> > > Both digikam and kde-utils (and kde-full!) pulled the old stuff, while
> > > installing libakonadi-kf5 won't complain, so I thought it is ok.
> > > Now all akonadi stuff is 4:16.04.x or 16.04.x.
> > > BTW: what means the leading '4'?
> > 
> > No idea.
> > 
> > > Also agentIndexingVersion=4 in baloorc gives a hint to version 4?
> > 
> > No, it is some internal protocol version.
> > 
> > > Proceedings are of course:
> > > stop akonadi and baloo, remove search_db, changed baloorc
> > > initialIndexingDone=false and reboot.
> > > The hell: No change.
> > > 
> > > And yes, with 4.14 it worked with minor flaws on display.
> > > 
> > > There is also more old stuff of kde around, also parts of 15.x
> > > But I need at least okular.
> > 
> > So, you are on Sid/unstable ?
> > And you did
> > apt-get update && apt-get dist-upgrade before ?
> 
> Yes, I came from stretch, and honestly I used aptitude dist-upgrade.
> apt-get dist-upgrade does not want apply any changes right now
> 
> > okular never stopped working here and I use it quite often.
> > 
> > $ dpkg -l '*okular*'
> > ii  libokularcore6  4:15.08.3-1  amd64
> > libraries for the Okular document viewer
> > ii  libokularcore7  4:16.04.2-1  amd64
> > libraries for the Okular document viewer
> > ii  okular  4:16.04.2-1  amd64
> > universal document viewer
> > ii  okular-extra-backends   4:16.04.2-1  amd64
> > additional document format support for Okular
> > 
> > But I guess libokularcore6 is orphaned and could be purged.
> 
> Sorry misleading you.
> I checked most of my installed kde packages to be on 16.04
> and started to throw away everything older.
> I of course installed the needed packages again.
> By this: For me okular is working without libokularcore7.

okular 16.04.2-1 has a dependency: libokularcore7 (= 4:16.04.2-1)
You can see this via
$ apt-cache show okular

> Both baloo and akonadi are not working as expected:
> On baloo when I try to index file contents it hangs indefinitely
> and I cannot find any open file handler within baloo_indexer or
> baloo_file_extractor hinting to a file causing this.
> BTW: with dolphin4 I can search (and find) the content of files!
> 

baloo does file indexing, akonadi does email indexing (and some more).

> On akonadi the indexer in akonadiconsole has finished, but
> "Tools->Find Messages" gives wrong results. Searching after
> starting kmail gives in rare cases a correct result list.
> Every following search gives the results of this first search.

I am just sitting at my home machine. Moving an email folder into another 
(drag&drop in KMail) seems to index the files. But interestingly, when 
searching for e.g. Subject 'contains' xxx, it shows emails that don't have 
'xxx' within the subject.

I just have 5 minutes time and maybe 0 tomorrow but if I find something 
here, I let you know.

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Sandro Knauß]

Hey,

[snip]
> Now all akonadi stuff is 4:16.04.x or 16.04.x.
> BTW: what means the leading '4'?

the leading 4 seperated by colon - is called epoch this is used by Debian and 
has nothing to do with upstream. 

> Also agentIndexingVersion=4 in baloorc gives a hint to version 4?
a baloo internal  version 

Regards,

sandro

signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Volker Groll]

Am Donnerstag, 28. Juli 2016, 16:54:43 CEST schrieb Tim Ruehsen:
> On Thursday, July 28, 2016 4:35:12 PM CEST Volker Groll wrote:
> > Hello Tim,
> > 
> > Am Donnerstag, 28. Juli 2016, 14:06:14 CEST schrieb Tim Ruehsen:
> > > On Thursday, July 28, 2016 1:46:55 PM CEST Volker Groll wrote:
> > > > Hi everybody,
> > > > 
> > > > I followed Tim's journey through akonadi the last days and reproduced
> > > > the steps here with no success. Last night I removed (hopefully) all
> > > > stuff
> > > > from .config, .local, .kde which seems to me connected to baloo or
> > > > akonadi
> > > > or any parts of kontact modules.
> > > > Then I recreated every mail stuff again => no success, the normal
> > > > search
> > > > above the mai list is working, akonadi search gives either nothing or
> > > > stupid results not connected to the search.
> > > > 
> > > > I also throwed 4:4.14 packages with help of deborphan out of my system
> > > > but especially libakonadi stuff is at 4:4.14.10-5?
> > > 
> > > Here we talked about Sid/unstable having 16.04.x.
> > > 
> > > $ dpkg -l|egrep 'akonadi|baloo|kdepim'
> > > 
> > > I can't say anything about the 4.14. stuff except that it was working
> > > before I went to 16.04.
> > > 
> > > Regards, Tim
> > 
> > Thanks for your answer.
> > 
> > I removed now all 4.14 stuff related to akondi|baloo|kdepim.
> > Both digikam and kde-utils (and kde-full!) pulled the old stuff, while
> > installing libakonadi-kf5 won't complain, so I thought it is ok.
> > Now all akonadi stuff is 4:16.04.x or 16.04.x.
> > BTW: what means the leading '4'?
> 
> No idea.
> 
> > Also agentIndexingVersion=4 in baloorc gives a hint to version 4?
> 
> No, it is some internal protocol version.
> 
> > Proceedings are of course:
> > stop akonadi and baloo, remove search_db, changed baloorc
> > initialIndexingDone=false and reboot.
> > The hell: No change.
> > 
> > And yes, with 4.14 it worked with minor flaws on display.
> > 
> > There is also more old stuff of kde around, also parts of 15.x
> > But I need at least okular.
> 
> So, you are on Sid/unstable ?
> And you did
> apt-get update && apt-get dist-upgrade before ?
Yes, I came from stretch, and honestly I used aptitude dist-upgrade.
apt-get dist-upgrade does not want apply any changes right now

> okular never stopped working here and I use it quite often.
> 
> $ dpkg -l '*okular*'
> ii  libokularcore6  4:15.08.3-1  amd64
> libraries for the Okular document viewer
> ii  libokularcore7  4:16.04.2-1  amd64
> libraries for the Okular document viewer
> ii  okular  4:16.04.2-1  amd64
> universal document viewer
> ii  okular-extra-backends   4:16.04.2-1  amd64
> additional document format support for Okular
> 
> But I guess libokularcore6 is orphaned and could be purged.
Sorry misleading you.
I checked most of my installed kde packages to be on 16.04 
and started to throw away everything older.
I of course installed the needed packages again.
By this: For me okular is working without libokularcore7.
 
> What exactly is your problem now ?
> 
> Tim

Both baloo and akonadi are not working as expected:
On baloo when I try to index file contents it hangs indefinitely
and I cannot find any open file handler within baloo_indexer or
baloo_file_extractor hinting to a file causing this.
BTW: with dolphin4 I can search (and find) the content of files!

On akonadi the indexer in akonadiconsole has finished, but
"Tools->Find Messages" gives wrong results. Searching after 
starting kmail gives in rare cases a correct result list. 
Every following search gives the results of this first search.

With 4.14 I was able to see the payload of my mails whithin
the akonadiconsole browser. Now I see the folder structure, but
if I select a folder, I get no entries and on the terminal there is 
"org.kde.akonadi.ETM: was item fetch job: items: 0"

Regards, volker

Re: KDEPIM ready to be more broadly tested

[Volker Groll]

Hi Rendy,

Am Donnerstag, 28. Juli 2016, 09:08:43 CEST schrieb rhkra...@gmail.com:
> Volker,
> 
> On Thursday, July 28, 2016 07:46:55 AM Volker Groll wrote:
> > Any help is appreciated
> 
> You might not consider this help, but I'll make the suggestion anyway.
It leads away from my question, but let's give a try.

> Perhaps it is worth considering a different tool to do the indexing and
> searching of your emails (and, presumably, other documents on your local
> disk)?
Actually I'm a little frustrated about akonadi/baloo (as it was from 3->4),
but I like the idea having all my pim information within one gui to support my
daily work with communication. I have a setup with 2 local Maildirs a bunch
of email accounts (2 imap, about 8 pop) and an owncloud server for calendar
and contacts. Most of the time I'm able to get my work done. But I got used
to search both file and mail within the last years, so what to do?
I'm using the search in dolpin and kmail to check old information on still
running projects --- actually it's somewhat like my CRM tool. 
With the integration in KDE, I can access --- in therory -- all information 
in a comfortable way.

> There are a number of reasons for this--one is to avoid being pushed into
> upgrade cycles based on other things--what I mean is, (iirc) you are now
> being forced to upgrade your email client and indexing search tool because
> you are either upgrading your Debian version or your version of KDE.
> 
> An independent tool, would be on its own cycle, and you could choose (within
> limitations) to upgrade or not when you upgraded your Debian or KDE
> versions.
> 
> I like recoll--google for it.  It works with many documents including
> various email stores, but I'm not sure whether or how it deals with Imap. 
> On the other hand, if you are storing the imap file(s) locally, I would
> think it should be able to handle it.
> 
> I have corresponded with the recoll developer and he has been helpful when I
> needed help.
> 
> One caveat--this is only a vague recollection, but I think that at one time
> kde was considering adopting (and, of course renaming) recoll for their
> indexing and search tool--perhaps it is even the basis for akonadi.
> 
> But, even if it is, switching to recoll instead of akonadi would get you out
> of the forced upgrades situation.
> 
> regards,
> Randy Kramer

I'm convinced there are a bunch of tools doing the index work. 
Every time the discussion runs towards "I have a problem with a tool" there
is a discussion "use an other (of course better) tool". Hm. 
Unfortunately there is no endless time to test all other tools to find a 
'best' one. 
I did a short look at recoll, but I find it not handy. I do not find i.e. the 
search for a sender of an email. My first impression is:  adequate for file
search, but it will took time get all my procedures adopted and learned 
with this tool. Hmmm.

Regards, volker

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Thursday, July 28, 2016 4:35:12 PM CEST Volker Groll wrote:
> Hello Tim,
> 
> Am Donnerstag, 28. Juli 2016, 14:06:14 CEST schrieb Tim Ruehsen:
> > On Thursday, July 28, 2016 1:46:55 PM CEST Volker Groll wrote:
> > > Hi everybody,
> > > 
> > > I followed Tim's journey through akonadi the last days and reproduced
> > > the steps here with no success. Last night I removed (hopefully) all
> > > stuff
> > > from .config, .local, .kde which seems to me connected to baloo or
> > > akonadi
> > > or any parts of kontact modules.
> > > Then I recreated every mail stuff again => no success, the normal search
> > > above the mai list is working, akonadi search gives either nothing or
> > > stupid results not connected to the search.
> > > 
> > > I also throwed 4:4.14 packages with help of deborphan out of my system
> > > but especially libakonadi stuff is at 4:4.14.10-5?
> > 
> > Here we talked about Sid/unstable having 16.04.x.
> > 
> > $ dpkg -l|egrep 'akonadi|baloo|kdepim'
> > 
> > I can't say anything about the 4.14. stuff except that it was working
> > before I went to 16.04.
> > 
> > Regards, Tim
> 
> Thanks for your answer.
> 
> I removed now all 4.14 stuff related to akondi|baloo|kdepim.
> Both digikam and kde-utils (and kde-full!) pulled the old stuff, while
> installing libakonadi-kf5 won't complain, so I thought it is ok.
> Now all akonadi stuff is 4:16.04.x or 16.04.x.
> BTW: what means the leading '4'?

No idea.

> Also agentIndexingVersion=4 in baloorc gives a hint to version 4?

No, it is some internal protocol version.

> Proceedings are of course:
> stop akonadi and baloo, remove search_db, changed baloorc
> initialIndexingDone=false and reboot.
> The hell: No change.
> 
> And yes, with 4.14 it worked with minor flaws on display.
> 
> There is also more old stuff of kde around, also parts of 15.x
> But I need at least okular.

So, you are on Sid/unstable ?
And you did
apt-get update && apt-get dist-upgrade before ?

okular never stopped working here and I use it quite often.

$ dpkg -l '*okular*'
ii  libokularcore6  4:15.08.3-1  amd64
libraries for the Okular document viewer
ii  libokularcore7  4:16.04.2-1  amd64
libraries for the Okular document viewer
ii  okular  4:16.04.2-1  amd64
universal document viewer
ii  okular-extra-backends   4:16.04.2-1  amd64
additional document format support for Okular

But I guess libokularcore6 is orphaned and could be purged.

What exactly is your problem now ?

Tim


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Volker Groll]

Hello Tim,

Am Donnerstag, 28. Juli 2016, 14:06:14 CEST schrieb Tim Ruehsen:
> On Thursday, July 28, 2016 1:46:55 PM CEST Volker Groll wrote:
> > Hi everybody,
> > 
> > I followed Tim's journey through akonadi the last days and reproduced
> > the steps here with no success. Last night I removed (hopefully) all stuff
> > from .config, .local, .kde which seems to me connected to baloo or akonadi
> > or any parts of kontact modules.
> > Then I recreated every mail stuff again => no success, the normal search
> > above the mai list is working, akonadi search gives either nothing or
> > stupid results not connected to the search.
> > 
> > I also throwed 4:4.14 packages with help of deborphan out of my system
> > but especially libakonadi stuff is at 4:4.14.10-5?
> 
> Here we talked about Sid/unstable having 16.04.x.
> 
> $ dpkg -l|egrep 'akonadi|baloo|kdepim'
> 
> I can't say anything about the 4.14. stuff except that it was working before
> I went to 16.04.
> 
> Regards, Tim

Thanks for your answer. 

I removed now all 4.14 stuff related to akondi|baloo|kdepim.
Both digikam and kde-utils (and kde-full!) pulled the old stuff, while 
installing libakonadi-kf5 won't complain, so I thought it is ok.
Now all akonadi stuff is 4:16.04.x or 16.04.x.
BTW: what means the leading '4'?
Also agentIndexingVersion=4 in baloorc gives a hint to version 4?

Proceedings are of course: 
stop akonadi and baloo, remove search_db, changed baloorc
initialIndexingDone=false and reboot. 
The hell: No change.

And yes, with 4.14 it worked with minor flaws on display.

There is also more old stuff of kde around, also parts of 15.x
But I need at least okular.

I have no idea left what to try...

Regards, volker

Re: KDEPIM ready to be more broadly tested

[rhkramer]

Volker,

On Thursday, July 28, 2016 07:46:55 AM Volker Groll wrote:
> Any help is appreciated

You might not consider this help, but I'll make the suggestion anyway.

Perhaps it is worth considering a different tool to do the indexing and 
searching of your emails (and, presumably, other documents on your local 
disk)?

There are a number of reasons for this--one is to avoid being pushed into 
upgrade cycles based on other things--what I mean is, (iirc) you are now being 
forced to upgrade your email client and indexing search tool because you are 
either upgrading your Debian version or your version of KDE.

An independent tool, would be on its own cycle, and you could choose (within 
limitations) to upgrade or not when you upgraded your Debian or KDE versions.

I like recoll--google for it.  It works with many documents including various 
email stores, but I'm not sure whether or how it deals with Imap.  On the 
other hand, if you are storing the imap file(s) locally, I would think it 
should be able to handle it.

I have corresponded with the recoll developer and he has been helpful when I 
needed help.

One caveat--this is only a vague recollection, but I think that at one time 
kde was considering adopting (and, of course renaming) recoll for their 
indexing and search tool--perhaps it is even the basis for akonadi.

But, even if it is, switching to recoll instead of akonadi would get you out 
of the forced upgrades situation.

regards,
Randy Kramer

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Thursday, July 28, 2016 1:46:55 PM CEST Volker Groll wrote:
> Hi everybody,
> 
> I followed Tim's journey through akonadi the last days and reproduced
> the steps here with no success. Last night I removed (hopefully) all stuff
> from .config, .local, .kde which seems to me connected to baloo or akonadi
> or any parts of kontact modules.
> Then I recreated every mail stuff again => no success, the normal search
> above the mai list is working, akonadi search gives either nothing or stupid
> results not connected to the search.
> 
> I also throwed 4:4.14 packages with help of deborphan out of my system
> but especially libakonadi stuff is at 4:4.14.10-5?

Here we talked about Sid/unstable having 16.04.x.

$ dpkg -l|egrep 'akonadi|baloo|kdepim'

I can't say anything about the 4.14. stuff except that it was working before I 
went to 16.04.

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Volker Groll]

Hi everybody,

I followed Tim's journey through akonadi the last days and reproduced
the steps here with no success. Last night I removed (hopefully) all stuff
from .config, .local, .kde which seems to me connected to baloo or akonadi
or any parts of kontact modules. 
Then I recreated every mail stuff again => no success, the normal search 
above the mai list is working, akonadi search gives either nothing or stupid
results not connected to the search.

I also throwed 4:4.14 packages with help of deborphan out of my system 
but especially libakonadi stuff is at 4:4.14.10-5?

Any help is appreciated
volker


Am Mittwoch, 27. Juli 2016, 14:22:22 CEST schrieb Tim Ruehsen:
> On Wednesday, July 27, 2016 1:16:18 PM CEST Martin Steigerwald wrote:
> > Am Mittwoch, 27. Juli 2016, 10:36:36 CEST schrieb Tim Ruehsen:
> > > And just another thing to check:
> > > 
> > > In KMail under Accounts/Receiving I see "Local Folders" pointing to
> > > /usr/
> > > oms/.local/share/local-mail/, Archive hook if off.
> > > And I see "KMail Folder" pointing to /usr/oms/Mail, but doesn't show the
> > > Archive tab.
> > > 
> > > Is that correct  - do you have the same ?
> > > I am not sure what this 'Local Folders' is for... it always stays empty.
> > 
> > I don´t have any KMail Folder resource anymore, just plain Maildir
> > resource.
> It is just named "KMail Folders" - it is of course a Maildir resource.
> 
> I have indexing / searching working now, but is was very spooky to get
> there... What I did:
> 
> I drag&drop'ped all folders from "KMail Folders" to "Local Folders" (my idea
> was to remove "KMail Folders" afterwards, thinking it was some kind of
> 'remnant' from upgrades). For a while it looked like it worked - all the
> folders/messages appeared in "Local Folders" - even indexed !
> 
> But than, folders started to reappear in "KMail Folders". After a while I
> had all my emails twice (checked this via 'ls' in ~/Mail/ and
> ~/.local/share/ local-mail/). After another while all folder from "Local
> Folders" where gone... At least my emails are indexed now and searching
> works.
> But I really transpired while fearing about my emails :-)
> 
> After moving the folders, the filter directories (I have ~120 filters)
> automatically changed to the new "Local Folder" directory. Pretty cool, I
> thought. Now that all folders where automagically moved back, the filter
> directories are at "Please select a folder" nice stupid work for the
> afternoon to select 120 directories one by one.
> 
> I will have the same issue at home, on my second Sid installation. But now I
> know how to get indexing working - and I just have ~15 filters to work on
> :-)
> 
> Thanks for all your great hints & help and for your patience & time !
> 
> Regards, Tim

Re: KDEPIM ready to be more broadly tested

[Martin Steigerwald]

Am Mittwoch, 27. Juli 2016, 14:22:22 CEST schrieb Tim Ruehsen:
> On Wednesday, July 27, 2016 1:16:18 PM CEST Martin Steigerwald wrote:
> > Am Mittwoch, 27. Juli 2016, 10:36:36 CEST schrieb Tim Ruehsen:
> > > And just another thing to check:
> > > 
> > > In KMail under Accounts/Receiving I see "Local Folders" pointing to
> > > /usr/
> > > oms/.local/share/local-mail/, Archive hook if off.
> > > And I see "KMail Folder" pointing to /usr/oms/Mail, but doesn't show the
> > > Archive tab.
> > > 
> > > Is that correct  - do you have the same ?
> > > I am not sure what this 'Local Folders' is for... it always stays empty.
> > 
> > I don´t have any KMail Folder resource anymore, just plain Maildir
> > resource.
> It is just named "KMail Folders" - it is of course a Maildir resource.

Are you sure it is a Maildir resource? There was a resource in earlier contact 
which was a mixed maildir resource, allowing mbox files within a maildir 
structure – pretty cool if you ask me, for archiving mails, yet, not as well 
supported as the plain maildir resource.

> I have indexing / searching working now, but is was very spooky to get
> there... What I did:
> 
> I drag&drop'ped all folders from "KMail Folders" to "Local Folders" (my idea
> was to remove "KMail Folders" afterwards, thinking it was some kind of
> 'remnant' from upgrades). For a while it looked like it worked - all the
> folders/messages appeared in "Local Folders" - even indexed !

Well, on moving local folder basically Akonadi *copies* all mails into it into 
its cache and *then* in the destination folder. I proved this behavior in an 
upstream bug report with a local maildir resource:

[Akonadi] [Bug 364114] New: moving a folder within one maildir resource is 
extremely slow and inefficient
https://bugs.kde.org/364114

So I am not surprised that this may trigger indexing. However in my eyes while 
I somewhat tend to understand the technical design behind this from an user 
point of view this is completely broken behavior. As a user I´d expect: Move 
the local directory containing the folder, record the location in the 
database, done.

> But than, folders started to reappear in "KMail Folders". After a while I
> had all my emails twice (checked this via 'ls' in ~/Mail/ and
> ~/.local/share/ local-mail/). After another while all folder from "Local
> Folders" where gone... At least my emails are indexed now and searching
> works.

So that I think should not happen. But unlike me you transferred between two 
resources, I moved between the same resource – maybe thats somehow related.

> But I really transpired while fearing about my emails :-)

I understand that. I didn´t see any data loss in Akonadi since a long time 
however, so while some things in Akonadi may work strange to very strange, I 
didn´t see it delete any mails it should not.

> After moving the folders, the filter directories (I have ~120 filters)
> automatically changed to the new "Local Folder" directory. Pretty cool, I
> thought. Now that all folders where automagically moved back, the filter
> directories are at "Please select a folder" nice stupid work for the
> afternoon to select 120 directories one by one.

I think that automagically moving back is a bug there. Feel free to research 
upstream bugtracker.

> I will have the same issue at home, on my second Sid installation. But now I
> know how to get indexing working - and I just have ~15 filters to work on
> :-)

Hm, I still think it should be more easy than that to get indexing working.

> Thanks for all your great hints & help and for your patience & time !

You are welcome. And my hand quite well again :)

Ciao,
-- 
Martin

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Wednesday, July 27, 2016 1:16:18 PM CEST Martin Steigerwald wrote:
> Am Mittwoch, 27. Juli 2016, 10:36:36 CEST schrieb Tim Ruehsen:
> > And just another thing to check:
> > 
> > In KMail under Accounts/Receiving I see "Local Folders" pointing to /usr/
> > oms/.local/share/local-mail/, Archive hook if off.
> > And I see "KMail Folder" pointing to /usr/oms/Mail, but doesn't show the
> > Archive tab.
> > 
> > Is that correct  - do you have the same ?
> > I am not sure what this 'Local Folders' is for... it always stays empty.
> 
> I don´t have any KMail Folder resource anymore, just plain Maildir resource.

It is just named "KMail Folders" - it is of course a Maildir resource.

I have indexing / searching working now, but is was very spooky to get 
there... What I did:

I drag&drop'ped all folders from "KMail Folders" to "Local Folders" (my idea 
was to remove "KMail Folders" afterwards, thinking it was some kind of 
'remnant' from upgrades). For a while it looked like it worked - all the 
folders/messages appeared in "Local Folders" - even indexed !

But than, folders started to reappear in "KMail Folders". After a while I had 
all my emails twice (checked this via 'ls' in ~/Mail/ and ~/.local/share/
local-mail/). After another while all folder from "Local Folders" where 
gone... At least my emails are indexed now and searching works.
But I really transpired while fearing about my emails :-)

After moving the folders, the filter directories (I have ~120 filters) 
automatically changed to the new "Local Folder" directory. Pretty cool, I 
thought. Now that all folders where automagically moved back, the filter 
directories are at "Please select a folder" nice stupid work for the 
afternoon to select 120 directories one by one.

I will have the same issue at home, on my second Sid installation. But now I 
know how to get indexing working - and I just have ~15 filters to work on :-)

Thanks for all your great hints & help and for your patience & time !

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Martin Steigerwald]

Am Mittwoch, 27. Juli 2016, 10:36:36 CEST schrieb Tim Ruehsen:
> And just another thing to check:
> 
> In KMail under Accounts/Receiving I see "Local Folders" pointing to /usr/
> oms/.local/share/local-mail/, Archive hook if off.
> And I see "KMail Folder" pointing to /usr/oms/Mail, but doesn't show the
> Archive tab.
> 
> Is that correct  - do you have the same ?
> I am not sure what this 'Local Folders' is for... it always stays empty.

I don´t have any KMail Folder resource anymore, just plain Maildir resource.

-- 
Martin

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

And just another thing to check:

In KMail under Accounts/Receiving I see "Local Folders" pointing to /usr/
oms/.local/share/local-mail/, Archive hook if off.
And I see "KMail Folder" pointing to /usr/oms/Mail, but doesn't show the 
Archive tab.

Is that correct  - do you have the same ?
I am not sure what this 'Local Folders' is for... it always stays empty.

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Tuesday, July 26, 2016 7:13:40 PM CEST Sandro Knauß wrote:
> Hi,
> 
> [snip]
> 
> > Does this also happen when you remove ~/.local/share/akonadi/search_db?
> > Move it out of the way and also have "initialIndexingDone=false" false
> > set and then restart.

Did that several times. It still happens.

> wait my systems tells me that the files are still under
> ~/.local/share/baloo/ contacts etc.
> 
> % ps aux | grep akonadi_in
> % ls -lsa  /proc//fd

That shows me the same as for Martin:
/usr/oms/.local/share/akonadi/search_db/...

> > If that doesn´t work, I think I don´t have any idea anymore. Escept than
> > to
> > watch ~/.xsession-errors, with relevant stuff in kdebugdialog dialog
> > enabled.
> 
> Well we can first test the xapian db itself. You need xapian-tools
> installed:

>  % delve ~/.local/share/baloo/email
> UUID = blablabla
> number of documents = 40123456
> average document length = 1900.00
> document length lower bound = 3
> document length upper bound = 600
> highest document id ever used = 705000
> has positional information = false

$ delve ~/.local/share/akonadi/search_db/email
UUID = a7ce645f-ed4a-48f3-980a-a188ed565ae1
number of documents = 635
average document length = 1856.19
document length lower bound = 583
document length upper bound = 10509
highest document id ever used = 59502
has positional information = false

Number of docs is by far too low.

> %xapian-cheeck ~/.local/share/baloo/email

$ xapian-check ~/.local/share/akonadi/search_db/email
record:
baseA blocksize=8K items=635 lastblock=10 revision=134 levels=1 root=5
B-tree checked okay
record table structure checked OK

termlist:
baseA blocksize=8K items=1270 lastblock=431 revision=134 levels=1 root=402
B-tree checked okay
termlist table structure checked OK

postlist:
baseA blocksize=8K items=82443 lastblock=1063 revision=134 levels=2 root=8
B-tree checked okay
postlist table structure checked OK

position:
Lazily created, and not yet used.

spelling:
Lazily created, and not yet used.

synonym:
Lazily created, and not yet used.

No errors found


'postlist' shows at least a reasonable number of items...


One thing I remember... someone said with IMAP accounts, you have to download 
the emails, else indexing does not work.
My POP3 accounts have the hook at "Leave the messages on the server" and "Days 
to leave messages" is set to 7. Is it possible that this setting accidentally 
prevents indexing ? It looks like all new emails become indexed, but not the 
old ones (though they are 'physically' downloaded and stay on disk).

> and you can ask the terms for a giving element in akonadi by:
> % delve ~/.local/share/baloo/email -r 297603
> [see a list of all terms for this item]
> 
> 
> to enable debuging output for akonadi search use kdebugsettings.
> @martin kdebugdialog/ kdebugdialog5 are not more useful anymore for kdepim,
> because it has switched logging to qt logging categories.

I set all hooks and said Apply, Save. Do you have instruction what to do and 
where to look at ?

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Sandro Knauß]

Hey,

> I don´t know whats up with your system, but my system shows this:

mmh interessting - but the search works forme fine ( i actually use the search 
quite often) Maybe I switched before the filepath was moved and it is saved 
somewhere. But with ps and ls we see the correct files for sure :D

> > to enable debuging output for akonadi search use kdebugsettings.
> > @martin kdebugdialog/ kdebugdialog5 are not more useful anymore for
> > kdepim,
> > because it has switched logging to qt logging categories.
> 
> Thanks, I didn´t know this. Any other tool to use instead?

Nearly all KF5 using qt logging categories fromthe kde applications i don't 
know. But qt logging categories are standard qt, so application will move to 
use it.

Regards,

sandro



signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Martin Steigerwald]

Am Dienstag, 26. Juli 2016, 19:13:40 CEST schrieb Sandro Knauß:
> Hi,
> 
> [snip]
> 
> > Does this also happen when you remove ~/.local/share/akonadi/search_db?
> > Move it out of the way and also have "initialIndexingDone=false" false
> > set and then restart.
> 
> wait my systems tells me that the files are still under
> ~/.local/share/baloo/ contacts etc.
> 
> % ps aux | grep akonadi_in
> % ls -lsa  /proc//fd

I don´t know whats up with your system, but my system shows this:

martin@merkaba:~> ls -l /proc/4329/fd | cut -c44- | grep .DB
13 -> /home/martin/.local/share/akonadi/search_db/email/record.DB
14 -> /home/martin/.local/share/akonadi/search_db/email/termlist.DB
15 -> /home/martin/.local/share/akonadi/search_db/email/postlist.DB
17 -> /home/martin/.local/share/akonadi/search_db/emailContacts/record.DB
18 -> /home/martin/.local/share/akonadi/search_db/emailContacts/termlist.DB
19 -> /home/martin/.local/share/akonadi/search_db/emailContacts/position.DB
20 -> /home/martin/.local/share/akonadi/search_db/emailContacts/postlist.DB
22 -> /home/martin/.local/share/akonadi/search_db/contacts/record.DB
23 -> /home/martin/.local/share/akonadi/search_db/contacts/termlist.DB
24 -> /home/martin/.local/share/akonadi/search_db/contacts/position.DB
25 -> /home/martin/.local/share/akonadi/search_db/contacts/postlist.DB
27 -> /home/martin/.local/share/akonadi/search_db/notes/record.DB
28 -> /home/martin/.local/share/akonadi/search_db/notes/termlist.DB
29 -> /home/martin/.local/share/akonadi/search_db/notes/postlist.DB
31 -> /home/martin/.local/share/akonadi/search_db/calendars/record.DB
32 -> /home/martin/.local/share/akonadi/search_db/calendars/termlist.DB
33 -> /home/martin/.local/share/akonadi/search_db/calendars/position.DB
34 -> /home/martin/.local/share/akonadi/search_db/calendars/postlist.DB
36 -> /home/martin/.local/share/akonadi/search_db/collections/record.DB
37 -> /home/martin/.local/share/akonadi/search_db/collections/termlist.DB
38 -> /home/martin/.local/share/akonadi/search_db/collections/position.DB
39 -> /home/martin/.local/share/akonadi/search_db/collections/postlist.DB

> to enable debuging output for akonadi search use kdebugsettings.
> @martin kdebugdialog/ kdebugdialog5 are not more useful anymore for kdepim, 
> because it has switched logging to qt logging categories.

Thanks, I didn´t know this. Any other tool to use instead?

Thanks,
-- 
Martin

Re: KDEPIM ready to be more broadly tested

[Sandro Knauß]

Hi,

[snip]
> Does this also happen when you remove ~/.local/share/akonadi/search_db? Move
> it out of the way and also have "initialIndexingDone=false" false set and
> then restart.

wait my systems tells me that the files are still under ~/.local/share/baloo/
contacts etc.

% ps aux | grep akonadi_in
% ls -lsa  /proc//fd
 
> If that doesn´t work, I think I don´t have any idea anymore. Escept than to
> watch ~/.xsession-errors, with relevant stuff in kdebugdialog dialog
> enabled.

Well we can first test the xapian db itself. You need xapian-tools installed:

 % delve ~/.local/share/baloo/email
UUID = blablabla
number of documents = 40123456
average document length = 1900.00
document length lower bound = 3
document length upper bound = 600
highest document id ever used = 705000
has positional information = false

%xapian-cheeck ~/.local/share/baloo/email

and you can ask the terms for a giving element in akonadi by:
% delve ~/.local/share/baloo/email -r 297603
[see a list of all terms for this item]


to enable debuging output for akonadi search use kdebugsettings.
@martin kdebugdialog/ kdebugdialog5 are not more useful anymore for kdepim, 
because it has switched logging to qt logging categories.

Regards,

sandro


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Martin Steigerwald]

Am Dienstag, 26. Juli 2016, 17:06:37 CEST schrieb Tim Ruehsen:
> On Tuesday, July 26, 2016 4:51:14 PM CEST Tim Ruehsen wrote:
> > On Tuesday, July 26, 2016 12:09:24 AM CEST Martin Steigerwald wrote:
> > > Hi Tim,
> > > 
> > > Am Montag, 25. Juli 2016, 22:10:36 CEST schrieb Tim Rühsen:
> > > > On Montag, 25. Juli 2016 17:24:45 CEST Sandro Knauß wrote:
> > > > > > It shows up with green Button and "Ready".
> > > > > 
> > > > > did you tried to restart akonadi? akonadictl restart? Because only
> > > > > with
> > > > > that akonadi will recognize new agents etc.
> > > > 
> > > > I even rebooted without effect.
> > > > And I see absolutely the same issues at a different (much newer) Sid
> > > > installation. Find Messages just doesn't work. The *akonadisearch*
> > > > packets
> > > > were also missing - I manually installed here as well.
> > > 
> > > I think you need to tweak this one:
> > > 
> > > martin@merkaba:~/.config> cat baloorc
> > > [Akonadi]
> > > aborted=false
> > > agentIndexingVersion=4
> > > dirtyCollections=
> > > initialIndexingDone=true
> > > 
> > > I´d even just remove it, so it redos the initial indexing, cause if it
> > > has
> > > "initialIndexingDone=true" in it, it won´t index the whole collections
> > > anymore. I bet it may have this in it from KDE SC 4 times… after
> > > migration
> > > of configuration, but I am not sure.
> > > 
> > > It stores the index data it stores in ~/.local/share/akonadi/search_db –
> > > this directory totals to 2 GiB on my system. In case that Xapian
> > > database
> > > is corrupted somehow, it may crash. So for a clean start, it may make
> > > sense
> > > to remove that directory as well.
> > 
> > I removed package 'baloo-utils', stopped KMail, stopped akonadi, removed
> > ~/.config/baloorc and removed ~/.local/share/akonadi/search_db. Than I
> > rebooted.
> > 
> > After reboot I started KMail and waited a few minutes... than
> > 
> > $ cat ~/.config/baloorc
> > [Akonadi]
> > agentIndexingVersion=4
> > dirtyCollections=
> > initialIndexingDone=true
> > 
> > $ l ~/.local/share/akonadi/search_db
> > total 32
> > drwxr-xr-x 8 oms users 4096 26-07-16 16:38:48 .
> > drwxr-xr-x 8 oms users 4096 26-07-16 16:38:48 ..
> > drwxr-xr-x 2 oms users 4096 26-07-16 16:38:48 calendars
> > drwxr-xr-x 2 oms users 4096 26-07-16 16:40:00 collections
> > drwxr-xr-x 2 oms users 4096 26-07-16 16:38:48 contacts
> > drwxr-xr-x 2 oms users 4096 26-07-16 16:41:40 email
> > drwxr-xr-x 2 oms users 4096 26-07-16 16:41:40 emailContacts
> > drwxr-xr-x 2 oms users 4096 26-07-16 16:38:48 notes
> > 
> > $ du ~/.local/share/akonadi/search_db
> > 20  /usr/oms/.local/share/akonadi/search_db/calendars
> > 20  /usr/oms/.local/share/akonadi/search_db/notes
> > 312 /usr/oms/.local/share/akonadi/search_db/email
> > 104 /usr/oms/.local/share/akonadi/search_db/emailContacts
> > 20  /usr/oms/.local/share/akonadi/search_db/contacts
> > 72  /usr/oms/.local/share/akonadi/search_db/collections
> > 552 /usr/oms/.local/share/akonadi/search_db
> > 
> > Tools/Find Messages in KMail still not working.
> > 
> > $ ps -ef|grep akonadi
> > oms   6056 1  0 16:38 ?00:00:00 /usr/bin/akonadi_control
> > oms   6063  6056  0 16:38 ?00:00:00 akonadiserver
> > oms   6067  6063  0 16:38 ?00:00:01 /usr/sbin/mysqld
> > --defaults-file=/usr/oms/.local/share/akonadi/mysql.conf
> > --datadir=/usr/oms/.local/share/akonadi/db_data/
> > --socket=/tmp/akonadi-oms.hwHVDb/mysql.socket oms   6119  6056  0
> > 16:38
> > ?00:00:00 /usr/bin/akonadi_akonotes_resource --identifier
> > akonadi_akonotes_resource_0 oms   6120  6056  0 16:38 ?   
> > 00:00:00
> > /usr/bin/akonadi_akonotes_resource --identifier
> > akonadi_akonotes_resource_1
> > oms   6121  6056  0 16:38 ?00:00:00
> > /usr/bin/akonadi_archivemail_agent --identifier akonadi_archivemail_agent
> > oms   6122  6056  0 16:38 ?00:00:00
> > /usr/bin/akonadi_contacts_resource --identifier
> > akonadi_contacts_resource_0
> > oms   6123  6056  0 16:38 ?00:00:00
> > /usr/bin/akonadi_followupreminder_agent --identifier
> > akonadi_followupreminder_agent oms   6124  6056  0 16:38 ?
> > 00:00:00 /usr/bin/akonadi_ical_resource --identifier
> > akonadi_ical_resource_0 oms   6125  6056  0 16:38 ?00:00:00
> > /usr/bin/akonadi_ical_resource --identifier akonadi_ical_resource_1 oms
> > 
> >   6128  6056  0 16:38 ?00:00:00 /usr/bin/akonadi_ical_resource
> > 
> > --identifier akonadi_ical_resource_2 oms   6129  6056  0 16:38 ?
> > 00:00:00 /usr/bin/akonadi_imap_resource --identifier
> > akonadi_imap_resource_1 oms   6131  6056  0 16:38 ?00:00:00
> > /usr/bin/akonadi_indexing_agent --identifier akonadi_indexing_agent oms
> > 
> >   6133  6056  0 16:38 ?00:00:00 /usr/bin/akonadi_maildir_resource
> > 
> > --identifier akonadi_maildir_resource_1 oms   6137  6056  0 16:38 ?
> > 
> >00:00:00 /usr/bin/akonadi_maildispatcher_agent 

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Tuesday, July 26, 2016 4:51:14 PM CEST Tim Ruehsen wrote:
> On Tuesday, July 26, 2016 12:09:24 AM CEST Martin Steigerwald wrote:
> > Hi Tim,
> > 
> > Am Montag, 25. Juli 2016, 22:10:36 CEST schrieb Tim Rühsen:
> > > On Montag, 25. Juli 2016 17:24:45 CEST Sandro Knauß wrote:
> > > > > It shows up with green Button and "Ready".
> > > > 
> > > > did you tried to restart akonadi? akonadictl restart? Because only
> > > > with
> > > > that akonadi will recognize new agents etc.
> > > 
> > > I even rebooted without effect.
> > > And I see absolutely the same issues at a different (much newer) Sid
> > > installation. Find Messages just doesn't work. The *akonadisearch*
> > > packets
> > > were also missing - I manually installed here as well.
> > 
> > I think you need to tweak this one:
> > 
> > martin@merkaba:~/.config> cat baloorc
> > [Akonadi]
> > aborted=false
> > agentIndexingVersion=4
> > dirtyCollections=
> > initialIndexingDone=true
> > 
> > I´d even just remove it, so it redos the initial indexing, cause if it has
> > "initialIndexingDone=true" in it, it won´t index the whole collections
> > anymore. I bet it may have this in it from KDE SC 4 times… after migration
> > of configuration, but I am not sure.
> > 
> > It stores the index data it stores in ~/.local/share/akonadi/search_db –
> > this directory totals to 2 GiB on my system. In case that Xapian database
> > is corrupted somehow, it may crash. So for a clean start, it may make
> > sense
> > to remove that directory as well.
> 
> I removed package 'baloo-utils', stopped KMail, stopped akonadi, removed
> ~/.config/baloorc and removed ~/.local/share/akonadi/search_db. Than I
> rebooted.
> 
> After reboot I started KMail and waited a few minutes... than
> 
> $ cat ~/.config/baloorc
> [Akonadi]
> agentIndexingVersion=4
> dirtyCollections=
> initialIndexingDone=true
> 
> $ l ~/.local/share/akonadi/search_db
> total 32
> drwxr-xr-x 8 oms users 4096 26-07-16 16:38:48 .
> drwxr-xr-x 8 oms users 4096 26-07-16 16:38:48 ..
> drwxr-xr-x 2 oms users 4096 26-07-16 16:38:48 calendars
> drwxr-xr-x 2 oms users 4096 26-07-16 16:40:00 collections
> drwxr-xr-x 2 oms users 4096 26-07-16 16:38:48 contacts
> drwxr-xr-x 2 oms users 4096 26-07-16 16:41:40 email
> drwxr-xr-x 2 oms users 4096 26-07-16 16:41:40 emailContacts
> drwxr-xr-x 2 oms users 4096 26-07-16 16:38:48 notes
> 
> $ du ~/.local/share/akonadi/search_db
> 20  /usr/oms/.local/share/akonadi/search_db/calendars
> 20  /usr/oms/.local/share/akonadi/search_db/notes
> 312 /usr/oms/.local/share/akonadi/search_db/email
> 104 /usr/oms/.local/share/akonadi/search_db/emailContacts
> 20  /usr/oms/.local/share/akonadi/search_db/contacts
> 72  /usr/oms/.local/share/akonadi/search_db/collections
> 552 /usr/oms/.local/share/akonadi/search_db
> 
> Tools/Find Messages in KMail still not working.
> 
> $ ps -ef|grep akonadi
> oms   6056 1  0 16:38 ?00:00:00 /usr/bin/akonadi_control
> oms   6063  6056  0 16:38 ?00:00:00 akonadiserver
> oms   6067  6063  0 16:38 ?00:00:01 /usr/sbin/mysqld
> --defaults-file=/usr/oms/.local/share/akonadi/mysql.conf
> --datadir=/usr/oms/.local/share/akonadi/db_data/
> --socket=/tmp/akonadi-oms.hwHVDb/mysql.socket oms   6119  6056  0 16:38
> ?00:00:00 /usr/bin/akonadi_akonotes_resource --identifier
> akonadi_akonotes_resource_0 oms   6120  6056  0 16:38 ?00:00:00
> /usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_1
> oms   6121  6056  0 16:38 ?00:00:00
> /usr/bin/akonadi_archivemail_agent --identifier akonadi_archivemail_agent
> oms   6122  6056  0 16:38 ?00:00:00
> /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_0
> oms   6123  6056  0 16:38 ?00:00:00
> /usr/bin/akonadi_followupreminder_agent --identifier
> akonadi_followupreminder_agent oms   6124  6056  0 16:38 ?   
> 00:00:00 /usr/bin/akonadi_ical_resource --identifier
> akonadi_ical_resource_0 oms   6125  6056  0 16:38 ?00:00:00
> /usr/bin/akonadi_ical_resource --identifier akonadi_ical_resource_1 oms
>   6128  6056  0 16:38 ?00:00:00 /usr/bin/akonadi_ical_resource
> --identifier akonadi_ical_resource_2 oms   6129  6056  0 16:38 ?   
> 00:00:00 /usr/bin/akonadi_imap_resource --identifier
> akonadi_imap_resource_1 oms   6131  6056  0 16:38 ?00:00:00
> /usr/bin/akonadi_indexing_agent --identifier akonadi_indexing_agent oms
>   6133  6056  0 16:38 ?00:00:00 /usr/bin/akonadi_maildir_resource
> --identifier akonadi_maildir_resource_1 oms   6137  6056  0 16:38 ?
>00:00:00 /usr/bin/akonadi_maildispatcher_agent --identifier
> akonadi_maildispatcher_agent oms   6141  6056  0 16:38 ?   
> 00:00:00 /usr/bin/akonadi_mailfilter_agent --identifier
> akonadi_mailfilter_agent oms   6143  6056  0 16:38 ?00:00:00
> /usr/bin/akonadi_migration_agent --identifier akonadi_migration_agent oms  
> 

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Tuesday, July 26, 2016 12:09:24 AM CEST Martin Steigerwald wrote:
> Hi Tim,
> 
> Am Montag, 25. Juli 2016, 22:10:36 CEST schrieb Tim Rühsen:
> > On Montag, 25. Juli 2016 17:24:45 CEST Sandro Knauß wrote:
> > > > It shows up with green Button and "Ready".
> > > 
> > > did you tried to restart akonadi? akonadictl restart? Because only with
> > > that akonadi will recognize new agents etc.
> > 
> > I even rebooted without effect.
> > And I see absolutely the same issues at a different (much newer) Sid
> > installation. Find Messages just doesn't work. The *akonadisearch* packets
> > were also missing - I manually installed here as well.
> 
> I think you need to tweak this one:
> 
> martin@merkaba:~/.config> cat baloorc
> [Akonadi]
> aborted=false
> agentIndexingVersion=4
> dirtyCollections=
> initialIndexingDone=true
>
> I´d even just remove it, so it redos the initial indexing, cause if it has
> "initialIndexingDone=true" in it, it won´t index the whole collections
> anymore. I bet it may have this in it from KDE SC 4 times… after migration
> of configuration, but I am not sure.
> 
> It stores the index data it stores in ~/.local/share/akonadi/search_db –
> this directory totals to 2 GiB on my system. In case that Xapian database
> is corrupted somehow, it may crash. So for a clean start, it may make sense
> to remove that directory as well.

I removed package 'baloo-utils', stopped KMail, stopped akonadi, removed 
~/.config/baloorc and removed ~/.local/share/akonadi/search_db.
Than I rebooted.

After reboot I started KMail and waited a few minutes... than

$ cat ~/.config/baloorc 
[Akonadi]
agentIndexingVersion=4
dirtyCollections=
initialIndexingDone=true

$ l ~/.local/share/akonadi/search_db
total 32
drwxr-xr-x 8 oms users 4096 26-07-16 16:38:48 .
drwxr-xr-x 8 oms users 4096 26-07-16 16:38:48 ..
drwxr-xr-x 2 oms users 4096 26-07-16 16:38:48 calendars
drwxr-xr-x 2 oms users 4096 26-07-16 16:40:00 collections
drwxr-xr-x 2 oms users 4096 26-07-16 16:38:48 contacts
drwxr-xr-x 2 oms users 4096 26-07-16 16:41:40 email
drwxr-xr-x 2 oms users 4096 26-07-16 16:41:40 emailContacts
drwxr-xr-x 2 oms users 4096 26-07-16 16:38:48 notes

$ du ~/.local/share/akonadi/search_db
20  /usr/oms/.local/share/akonadi/search_db/calendars
20  /usr/oms/.local/share/akonadi/search_db/notes
312 /usr/oms/.local/share/akonadi/search_db/email
104 /usr/oms/.local/share/akonadi/search_db/emailContacts
20  /usr/oms/.local/share/akonadi/search_db/contacts
72  /usr/oms/.local/share/akonadi/search_db/collections
552 /usr/oms/.local/share/akonadi/search_db

Tools/Find Messages in KMail still not working.

$ ps -ef|grep akonadi
oms   6056 1  0 16:38 ?00:00:00 /usr/bin/akonadi_control
oms   6063  6056  0 16:38 ?00:00:00 akonadiserver
oms   6067  6063  0 16:38 ?00:00:01 /usr/sbin/mysqld 
--defaults-file=/usr/oms/.local/share/akonadi/mysql.conf 
--datadir=/usr/oms/.local/share/akonadi/db_data/ 
--socket=/tmp/akonadi-oms.hwHVDb/mysql.socket
oms   6119  6056  0 16:38 ?00:00:00 
/usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_0
oms   6120  6056  0 16:38 ?00:00:00 
/usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_1
oms   6121  6056  0 16:38 ?00:00:00 
/usr/bin/akonadi_archivemail_agent --identifier akonadi_archivemail_agent
oms   6122  6056  0 16:38 ?00:00:00 
/usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_0
oms   6123  6056  0 16:38 ?00:00:00 
/usr/bin/akonadi_followupreminder_agent --identifier 
akonadi_followupreminder_agent
oms   6124  6056  0 16:38 ?00:00:00 /usr/bin/akonadi_ical_resource 
--identifier akonadi_ical_resource_0
oms   6125  6056  0 16:38 ?00:00:00 /usr/bin/akonadi_ical_resource 
--identifier akonadi_ical_resource_1
oms   6128  6056  0 16:38 ?00:00:00 /usr/bin/akonadi_ical_resource 
--identifier akonadi_ical_resource_2
oms   6129  6056  0 16:38 ?00:00:00 /usr/bin/akonadi_imap_resource 
--identifier akonadi_imap_resource_1
oms   6131  6056  0 16:38 ?00:00:00 /usr/bin/akonadi_indexing_agent 
--identifier akonadi_indexing_agent
oms   6133  6056  0 16:38 ?00:00:00 
/usr/bin/akonadi_maildir_resource --identifier akonadi_maildir_resource_1
oms   6137  6056  0 16:38 ?00:00:00 
/usr/bin/akonadi_maildispatcher_agent --identifier akonadi_maildispatcher_agent
oms   6141  6056  0 16:38 ?00:00:00 
/usr/bin/akonadi_mailfilter_agent --identifier akonadi_mailfilter_agent
oms   6143  6056  0 16:38 ?00:00:00 
/usr/bin/akonadi_migration_agent --identifier akonadi_migration_agent
oms   6145  6056  0 16:38 ?00:00:00 
/usr/bin/akonadi_mixedmaildir_resource --identifier 
akonadi_mixedmaildir_resource_0
oms   6147  6056  0 16:38 ?00:00:00 
/usr/bin/akonadi_newmailnotifier_agent --identifier 
akonadi_newmailnotifier_agent
om

Re: Akonadi indexing (was: Re: KDEPIM ready to be more broadly tested)

[Martin Steigerwald]

Am Dienstag, 26. Juli 2016, 13:14:14 CEST schrieb Tim Ruehsen:
> On Tuesday, July 26, 2016 12:49:20 PM CEST Martin Steigerwald wrote:
> > please no cc
> 
> Please anyone use cc for me :-)
> 
> Hi Martin,
> 
> thanks for your extended answer though you are handicapped right now.
> I wish you the best and a fast healing !

Thanks. Getting better every hour.

> > Am Dienstag, 26. Juli 2016, 10:13:23 CEST schrieb Tim Ruehsen:
> > > On Tuesday, July 26, 2016 12:09:24 AM CEST Martin Steigerwald wrote:
> > […]
> > 
> > > > It stores the index data it stores in ~/.local/share/akonadi/search_db
> > > > –
> > > > this directory totals to 2 GiB on my system. In case that Xapian
> > > > database
> > > > is corrupted somehow, it may crash. So for a clean start, it may make
> > > > sense
> > > > to remove that directory as well.
> > > 
> > > This directory contained three subdirs and there was not much data (<
> > > 1MB).
> > > 
> > > > And well when I say remove, I rather suggest you move it out of the
> > > > way,
> > > > instead of removing it immediately.
> > > 
> > > Removed both and restarted KDE (logout / login).
> > > 
> > > Now I get crashes
> > > Application: No such method 'agentName' in interface
> > > 'org.freedesktop.Akonadi.AgentManager' at object path '/AgentManager'
> > > (signature 'ss') (akonadi_baloo_indexer), signal: Aborted
> > > 
> > > akonadi_baloo_indexer(13140)/libakonadi: Unable to register service
> > 
> > AFAIK thats the old KDE SC 4 based indexer, which should not be running at
> > all.
> 
> Ohh. Ahh. Uhh. Ding dong.
> 
> > martin@merkaba:~> ps aux | grep "[b]aloo"
> > martin4104  0.0  1.8 5856360 298408 ?  SNl  Jul25   0:24 /usr/bin/
> > baloo_file
> > 
> > That is file based desktop search
> > 
> > martin@merkaba:~> ps aux | grep "[i]ndexing"
> > martin4329  0.0  0.6 753312 104188 ?   SNl  Jul25   0:33 /usr/bin/
> > akonadi_indexing_agent --identifier akonadi_indexing_agent
> > 
> > This is Akonadi indexing.
> > 
> > I am not even sure how you can still have installed Akonadi baloo indexer
> > when using Qt 5 based Akonadi and to my knowledge meanwhile if you have
> > new
> > qt5/kf5 based kdepim you will also have Qt5 based Akonadi. Maybe there is
> > a
> > breaks/ replaces missing.
> 
> When I first run into the half-way update to 16.04, I had to forcefully
> download/install packages from experimental. I definitely broke things but I
> thought it was cleaned up by now. I still have package 'baloo-utils'
> installed which contains akonadi_baloo_indexer.
> 
> $ apt-file search akonadi_baloo_indexer
> baloo-utils: /usr/bin/akonadi_baloo_indexer
> 
> > I suggest the following:
> > 
> > 1) report a bug with reportbug againsd akonadi-server or so, can still be
> > reassigned. Give all necessary details including dpkg -l | egrep "akonadi|
> > kdepim" | cut -c-72
> > 
> > Please also provide this output here to this list.
> 
> First I check the dependencies with apt-cache show. Onyl if these aren't
> correct, I'll file a bug.

I saw your bug report. I suggest adding the backtrace that mentioned 
akonadi_baloo_indexer to the bug report. You can simply do that by mailing it 
to bugnum...@bugs.debian.org.

> > 2) make sure akonadi_baloo_indexer is gone for good. something like
> > 
> > apt purge $(which akonadi_baloo_indexer)
> > 
> > 3) Move Akonadi indexing agent config + search_db out of the way once
> > again
> > and reboot.
> 
> I'll do that after lunch (and after checking above) and report back.

Great.

Thanks,
-- 
Martin

signature.asc
Description: This is a digitally signed message part.

Re: Akonadi indexing (was: Re: KDEPIM ready to be more broadly tested)

[Tim Ruehsen]

On Tuesday, July 26, 2016 12:49:20 PM CEST Martin Steigerwald wrote:
> please no cc

Please anyone use cc for me :-)

Hi Martin,

thanks for your extended answer though you are handicapped right now.
I wish you the best and a fast healing !

> Am Dienstag, 26. Juli 2016, 10:13:23 CEST schrieb Tim Ruehsen:
> > On Tuesday, July 26, 2016 12:09:24 AM CEST Martin Steigerwald wrote:
> […]
> 
> > > It stores the index data it stores in ~/.local/share/akonadi/search_db –
> > > this directory totals to 2 GiB on my system. In case that Xapian
> > > database
> > > is corrupted somehow, it may crash. So for a clean start, it may make
> > > sense
> > > to remove that directory as well.
> > 
> > This directory contained three subdirs and there was not much data (<
> > 1MB).
> > 
> > > And well when I say remove, I rather suggest you move it out of the way,
> > > instead of removing it immediately.
> > 
> > Removed both and restarted KDE (logout / login).
> > 
> > Now I get crashes
> > Application: No such method 'agentName' in interface
> > 'org.freedesktop.Akonadi.AgentManager' at object path '/AgentManager'
> > (signature 'ss') (akonadi_baloo_indexer), signal: Aborted
> > 
> > akonadi_baloo_indexer(13140)/libakonadi: Unable to register service
> 
> AFAIK thats the old KDE SC 4 based indexer, which should not be running at
> all.

Ohh. Ahh. Uhh. Ding dong.

> martin@merkaba:~> ps aux | grep "[b]aloo"
> martin4104  0.0  1.8 5856360 298408 ?  SNl  Jul25   0:24 /usr/bin/
> baloo_file
> 
> That is file based desktop search
> 
> martin@merkaba:~> ps aux | grep "[i]ndexing"
> martin4329  0.0  0.6 753312 104188 ?   SNl  Jul25   0:33 /usr/bin/
> akonadi_indexing_agent --identifier akonadi_indexing_agent
> 
> This is Akonadi indexing.
> 
> I am not even sure how you can still have installed Akonadi baloo indexer
> when using Qt 5 based Akonadi and to my knowledge meanwhile if you have new
> qt5/kf5 based kdepim you will also have Qt5 based Akonadi. Maybe there is a
> breaks/ replaces missing.

When I first run into the half-way update to 16.04, I had to forcefully 
download/install packages from experimental. I definitely broke things but I 
thought it was cleaned up by now. I still have package 'baloo-utils' installed 
which contains akonadi_baloo_indexer.

$ apt-file search akonadi_baloo_indexer
baloo-utils: /usr/bin/akonadi_baloo_indexer

> I suggest the following:
> 
> 1) report a bug with reportbug againsd akonadi-server or so, can still be
> reassigned. Give all necessary details including dpkg -l | egrep "akonadi|
> kdepim" | cut -c-72
> 
> Please also provide this output here to this list.

First I check the dependencies with apt-cache show. Onyl if these aren't 
correct, I'll file a bug.

> 2) make sure akonadi_baloo_indexer is gone for good. something like
> 
> apt purge $(which akonadi_baloo_indexer)
> 
> 3) Move Akonadi indexing agent config + search_db out of the way once again
> and reboot.

I'll do that after lunch (and after checking above) and report back.



signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Martin Steigerwald]

Am Dienstag, 26. Juli 2016, 09:37:40 CEST schrieb Tim Ruehsen:
> On Monday, July 25, 2016 10:55:45 PM CEST Diederik de Haas wrote:
> > On maandag 25 juli 2016 22:08:23 CEST Tim Rühsen wrote:
> > > BTW, I can't find such an option at all - maybe just for imap ?
> > 
> > Probably. I almost exclusively use imap.
> > 
> > > I really can't believe that this is a personal problem. I am just
> > > sitting
> > > at a  much newer Sid installation and experience absolutely the same
> > > problems. The question is: what did all of you do that I didn't ? And
> > > are
> > > you sure that indexing and "Tools/Find Messages" really work for you ?
> > 
> > It's working fine here. I can go to a random mail, copy a word from it and
> > put it in the search box and it'll find that mail again.
> > Which database backend are you using for akonadi?
> 
> It is the mysql backend.
> In fact I see (output by akonadi)
> Database "akonadi" opened using driver "QMYSQL"

Folder search box does not only rely on Akonadi Indexing agent, AFAIK it also 
filters by subject. But for global kmail search + search folders basically 
work as well. Just removing a search folder can be an issue (crash).

-- 
Martin

Re: Akonadi indexing (was: Re: KDEPIM ready to be more broadly tested)

[Martin Steigerwald]

Am Dienstag, 26. Juli 2016, 12:49:20 CEST schrieb Martin Steigerwald:
> please no cc
> 
> Am Dienstag, 26. Juli 2016, 10:13:23 CEST schrieb Tim Ruehsen:
> > On Tuesday, July 26, 2016 12:09:24 AM CEST Martin Steigerwald wrote:
> […]
> 
> > > It stores the index data it stores in ~/.local/share/akonadi/search_db –
> > > this directory totals to 2 GiB on my system. In case that Xapian
> > > database
> > > is corrupted somehow, it may crash. So for a clean start, it may make
> > > sense
> > > to remove that directory as well.
> > 
> > This directory contained three subdirs and there was not much data (<
> > 1MB).
> > 
> > > And well when I say remove, I rather suggest you move it out of the way,
> > > instead of removing it immediately.
> > 
> > Removed both and restarted KDE (logout / login).
> > 
> > Now I get crashes
> > Application: No such method 'agentName' in interface
> > 'org.freedesktop.Akonadi.AgentManager' at object path '/AgentManager'
> > (signature 'ss') (akonadi_baloo_indexer), signal: Aborted
> > 
> > akonadi_baloo_indexer(13140)/libakonadi: Unable to register service
> 
> AFAIK thats the old KDE SC 4 based indexer, which should not be running at
> all.
> 
> martin@merkaba:~> ps aux | grep "[b]aloo"
> martin4104  0.0  1.8 5856360 298408 ?  SNl  Jul25   0:24 /usr/bin/
> baloo_file
> 
> That is file based desktop search
> 
> martin@merkaba:~> ps aux | grep "[i]ndexing"
> martin4329  0.0  0.6 753312 104188 ?   SNl  Jul25   0:33 /usr/bin/
> akonadi_indexing_agent --identifier akonadi_indexing_agent
> 
> This is Akonadi indexing.
> 
> I am not even sure how you can still have installed Akonadi baloo indexer
> when using Qt 5 based Akonadi and to my knowledge meanwhile if you have new
> qt5/kf5 based kdepim you will also have Qt5 based Akonadi. Maybe there is a
> breaks/ replaces missing.
> 
> I suggest the following:
> 
> 1) report a bug with reportbug againsd akonadi-server or so, can still be
> reassigned. Give all necessary details including dpkg -l | egrep "akonadi|
> kdepim" | cut -c-72
> 
> Please also provide this output here to this list.
> 
> 2) make sure akonadi_baloo_indexer is gone for good. something like
> 
> apt purge $(which akonadi_baloo_indexer)
> 
> 3) Move Akonadi indexing agent config + search_db out of the way once again
> and reboot.
> 
> But first please really contribute by making a bug report.
> 
> > "org.freedesktop.Akonadi.Agent.akonadi_baloo_indexer" at dbus: ""
> > Shutting down "0x1032bb0" ...
> > KCrash: Application 'akonadi_baloo_indexer' crashing...
> > KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
> > KCrash: Connect sock_file=/usr/oms/.kde/socket-blitz-lx/kdeinit4__0
> > Unable to start Dr. Konqi
> > Not forwarding the crash to Apport.
> > ProcessControl: Application '/usr/bin/akonadi_baloo_indexer' returned with
> > exit code 255 (Unknown error)
> > akonadi_baloo_indexer(13148)/libakonadi: Unable to register service
> > "org.freedesktop.Akonadi.Agent.akonadi_baloo_indexer" at dbus: ""
> > KCrash: Application 'akonadi_baloo_indexer' crashing...
> > KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
> > Shutting down "0x1032bb0" ...
> > KCrash: Connect sock_file=/usr/oms/.kde/socket-blitz-lx/kdeinit4__0
> > Unable to start Dr. Konqi
> > Not forwarding the crash to Apport.
> > ProcessControl: Application '/usr/bin/akonadi_baloo_indexer' returned with
> > exit code 255 (Unknown error)
> > akonadi_baloo_indexer(13156)/libakonadi: Unable to register service
> > "org.freedesktop.Akonadi.Agent.akonadi_baloo_indexer" at dbus: ""
> > KCrash: Application 'akonadi_baloo_indexer' crashing...
> > KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
> > KCrash: Connect sock_file=/usr/oms/.kde/socket-blitz-lx/kdeinit4__0
> > 
> > > As Sandro told, it needs to be "akonadi_indexing_agent" being active.
> > > Additionally to that: You can´t configure Akonadi Search with
> > > Systemsettings, Systemsetting just configured the desktop file search.
> > > Basically the mail and contact indexing part of Baloo has been split out
> > > and is now Akonadi search. Almost unchanged, except for search database
> > > location.
> > 
> > Thanks, good to know.
> > "akonadi_indexing_agent" can't be something complicated than... how can it
> > crash at all (and I saw crash often in the past). I couldn't find any -dbg
> > packages, so the backtrace is pretty worthless.
> 
> It doesn´t crash. akonida_baloo_indexer crashes, not the indexing agent.
> 
> > > There is a way in KMail to disable fulltext indexing for folders, but as
> > > I
> > > found out, Akonadi doesn´t respect that setting.
> > > 
> > > I do think Akonadi Search doesn´t receive much love at the moment, and
> > > it
> > > shows.
> > 
> > That renders KMail at least incomplete. It worked perfect for me until
> > KDE4
> > came. From that point on it was getting worse and worse... If there was
> > any
> > easy way to convert all those emails from the last 15 ye

Re: KDEPIM ready to be more broadly tested

[Martin Steigerwald]

Am Mittwoch, 20. Juli 2016, 09:31:46 CEST schrieb Christian Hilberg:
> Am Dienstag, 19. Juli 2016, 15:56:41 CEST schrieb Christian Hilberg:
> > Am Dienstag 19 Juli 2016, 11:14:30 schrieb Christian Hilberg:
> > > Am Dienstag 19 Juli 2016, 11:01:21 schrieb Christian Hilberg:
> > > > [...]
> > > > While syncing the IMAP folders, the process got stuck at 100% at one
> > > > folder[...] Trying to resolve this now...
> > 
> > [...]
> 
> Well, allowed a second CPU core into my VM and the issue is gone...
> That smells like timing/timeout issue. The missing feedback to the
> user via the UI is already reported upstream, iirc.

Christian, please consider researching, adding to or creating upstream bug 
report, then Debian bug report forwarding to it.

-- 
Martin

Akonadi indexing (was: Re: KDEPIM ready to be more broadly tested)

[Martin Steigerwald]

please no cc

Am Dienstag, 26. Juli 2016, 10:13:23 CEST schrieb Tim Ruehsen:
> On Tuesday, July 26, 2016 12:09:24 AM CEST Martin Steigerwald wrote:
[…]
> > It stores the index data it stores in ~/.local/share/akonadi/search_db –
> > this directory totals to 2 GiB on my system. In case that Xapian database
> > is corrupted somehow, it may crash. So for a clean start, it may make
> > sense
> > to remove that directory as well.
> 
> This directory contained three subdirs and there was not much data (< 1MB).
> 
> > And well when I say remove, I rather suggest you move it out of the way,
> > instead of removing it immediately.
> 
> Removed both and restarted KDE (logout / login).
> 
> Now I get crashes
> Application: No such method 'agentName' in interface
> 'org.freedesktop.Akonadi.AgentManager' at object path '/AgentManager'
> (signature 'ss') (akonadi_baloo_indexer), signal: Aborted
> 
> akonadi_baloo_indexer(13140)/libakonadi: Unable to register service

AFAIK thats the old KDE SC 4 based indexer, which should not be running at 
all.

martin@merkaba:~> ps aux | grep "[b]aloo"
martin4104  0.0  1.8 5856360 298408 ?  SNl  Jul25   0:24 /usr/bin/
baloo_file

That is file based desktop search

martin@merkaba:~> ps aux | grep "[i]ndexing"
martin4329  0.0  0.6 753312 104188 ?   SNl  Jul25   0:33 /usr/bin/
akonadi_indexing_agent --identifier akonadi_indexing_agent

This is Akonadi indexing.

I am not even sure how you can still have installed Akonadi baloo indexer when 
using Qt 5 based Akonadi and to my knowledge meanwhile if you have new qt5/kf5 
based kdepim you will also have Qt5 based Akonadi. Maybe there is a breaks/
replaces missing.

I suggest the following:

1) report a bug with reportbug againsd akonadi-server or so, can still be 
reassigned. Give all necessary details including dpkg -l | egrep "akonadi|
kdepim" | cut -c-72

Please also provide this output here to this list.

2) make sure akonadi_baloo_indexer is gone for good. something like

apt purge $(which akonadi_baloo_indexer)

3) Move Akonadi indexing agent config + search_db out of the way once again 
and reboot.

But first please really contribute by making a bug report.

> "org.freedesktop.Akonadi.Agent.akonadi_baloo_indexer" at dbus: ""
> Shutting down "0x1032bb0" ...
> KCrash: Application 'akonadi_baloo_indexer' crashing...
> KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
> KCrash: Connect sock_file=/usr/oms/.kde/socket-blitz-lx/kdeinit4__0
> Unable to start Dr. Konqi
> Not forwarding the crash to Apport.
> ProcessControl: Application '/usr/bin/akonadi_baloo_indexer' returned with
> exit code 255 (Unknown error)
> akonadi_baloo_indexer(13148)/libakonadi: Unable to register service
> "org.freedesktop.Akonadi.Agent.akonadi_baloo_indexer" at dbus: ""
> KCrash: Application 'akonadi_baloo_indexer' crashing...
> KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
> Shutting down "0x1032bb0" ...
> KCrash: Connect sock_file=/usr/oms/.kde/socket-blitz-lx/kdeinit4__0
> Unable to start Dr. Konqi
> Not forwarding the crash to Apport.
> ProcessControl: Application '/usr/bin/akonadi_baloo_indexer' returned with
> exit code 255 (Unknown error)
> akonadi_baloo_indexer(13156)/libakonadi: Unable to register service
> "org.freedesktop.Akonadi.Agent.akonadi_baloo_indexer" at dbus: ""
> KCrash: Application 'akonadi_baloo_indexer' crashing...
> KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
> KCrash: Connect sock_file=/usr/oms/.kde/socket-blitz-lx/kdeinit4__0
> 
> > As Sandro told, it needs to be "akonadi_indexing_agent" being active.
> > Additionally to that: You can´t configure Akonadi Search with
> > Systemsettings, Systemsetting just configured the desktop file search.
> > Basically the mail and contact indexing part of Baloo has been split out
> > and is now Akonadi search. Almost unchanged, except for search database
> > location.
> 
> Thanks, good to know.
> "akonadi_indexing_agent" can't be something complicated than... how can it
> crash at all (and I saw crash often in the past). I couldn't find any -dbg
> packages, so the backtrace is pretty worthless.

It doesn´t crash. akonida_baloo_indexer crashes, not the indexing agent.

> > There is a way in KMail to disable fulltext indexing for folders, but as I
> > found out, Akonadi doesn´t respect that setting.
> > 
> > I do think Akonadi Search doesn´t receive much love at the moment, and it
> > shows.
> 
> That renders KMail at least incomplete. It worked perfect for me until KDE4
> came. From that point on it was getting worse and worse... If there was any
> easy way to convert all those emails from the last 15 years into a halfway
> working mail client I would do that instead of wasting my time with unloved
> and unsupported crap. But that is OT, and I am not giving up yet.

Tim, I didn´t write that it doesn´t work at all. It basically works here. But 
its more rough than I think is good for an end user who wants to have it 

Re: KDEPIM ready to be more broadly tested

[rhkramer]

On Tuesday, July 26, 2016 04:13:23 AM Tim Ruehsen wrote:
> On Tuesday, July 26, 2016 12:09:24 AM CEST Martin Steigerwald wrote:
> If there was any
> easy way to convert all those emails from the last 15 years into a halfway
> working mail client I would do that instead of wasting my time with unloved
> and unsupported crap. But that is OT, and I am not giving up yet.

I'm trying to remember--I guess you're using Imap and trying to store a local 
copy of your emails?

I'm not sure about Imap, but if you were using mbox or maildir to store your 
emails, that's pretty standard across quite a few email clients (in other 
words, you could easily switch to some other email client and get access to 
old emails).  

I would think Imap would be similarly standardized?

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Tuesday, July 26, 2016 12:09:24 AM CEST Martin Steigerwald wrote:
> Hi Tim,
> 
> Am Montag, 25. Juli 2016, 22:10:36 CEST schrieb Tim Rühsen:
> > On Montag, 25. Juli 2016 17:24:45 CEST Sandro Knauß wrote:
> > > > It shows up with green Button and "Ready".
> > > 
> > > did you tried to restart akonadi? akonadictl restart? Because only with
> > > that akonadi will recognize new agents etc.
> > 
> > I even rebooted without effect.
> > And I see absolutely the same issues at a different (much newer) Sid
> > installation. Find Messages just doesn't work. The *akonadisearch* packets
> > were also missing - I manually installed here as well.
> 
> I think you need to tweak this one:
> 
> martin@merkaba:~/.config> cat baloorc
> [Akonadi]
> aborted=false
> agentIndexingVersion=4
> dirtyCollections=
> initialIndexingDone=true
> 
> 
> I´d even just remove it, so it redos the initial indexing, cause if it has
> "initialIndexingDone=true" in it, it won´t index the whole collections
> anymore. I bet it may have this in it from KDE SC 4 times… after migration
> of configuration, but I am not sure.
> 
> It stores the index data it stores in ~/.local/share/akonadi/search_db –
> this directory totals to 2 GiB on my system. In case that Xapian database
> is corrupted somehow, it may crash. So for a clean start, it may make sense
> to remove that directory as well.

This directory contained three subdirs and there was not much data (< 1MB).

> And well when I say remove, I rather suggest you move it out of the way,
> instead of removing it immediately.

Removed both and restarted KDE (logout / login).

Now I get crashes
Application: No such method 'agentName' in interface 
'org.freedesktop.Akonadi.AgentManager' at object path '/AgentManager' 
(signature 'ss') (akonadi_baloo_indexer), signal: Aborted

akonadi_baloo_indexer(13140)/libakonadi: Unable to register service 
"org.freedesktop.Akonadi.Agent.akonadi_baloo_indexer" at dbus: "" 
Shutting down "0x1032bb0" ...
KCrash: Application 'akonadi_baloo_indexer' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
KCrash: Connect sock_file=/usr/oms/.kde/socket-blitz-lx/kdeinit4__0
Unable to start Dr. Konqi
Not forwarding the crash to Apport.
ProcessControl: Application '/usr/bin/akonadi_baloo_indexer' returned with 
exit code 255 (Unknown error)
akonadi_baloo_indexer(13148)/libakonadi: Unable to register service 
"org.freedesktop.Akonadi.Agent.akonadi_baloo_indexer" at dbus: "" 
KCrash: Application 'akonadi_baloo_indexer' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
Shutting down "0x1032bb0" ...
KCrash: Connect sock_file=/usr/oms/.kde/socket-blitz-lx/kdeinit4__0
Unable to start Dr. Konqi
Not forwarding the crash to Apport.
ProcessControl: Application '/usr/bin/akonadi_baloo_indexer' returned with 
exit code 255 (Unknown error)
akonadi_baloo_indexer(13156)/libakonadi: Unable to register service 
"org.freedesktop.Akonadi.Agent.akonadi_baloo_indexer" at dbus: "" 
KCrash: Application 'akonadi_baloo_indexer' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
KCrash: Connect sock_file=/usr/oms/.kde/socket-blitz-lx/kdeinit4__0


> As Sandro told, it needs to be "akonadi_indexing_agent" being active.
> Additionally to that: You can´t configure Akonadi Search with
> Systemsettings, Systemsetting just configured the desktop file search.
> Basically the mail and contact indexing part of Baloo has been split out
> and is now Akonadi search. Almost unchanged, except for search database
> location.

Thanks, good to know.
"akonadi_indexing_agent" can't be something complicated than... how can it 
crash at all (and I saw crash often in the past). I couldn't find any -dbg 
packages, so the backtrace is pretty worthless.

> There is a way in KMail to disable fulltext indexing for folders, but as I
> found out, Akonadi doesn´t respect that setting.
> 
> I do think Akonadi Search doesn´t receive much love at the moment, and it
> shows.

That renders KMail at least incomplete. It worked perfect for me until KDE4 
came. From that point on it was getting worse and worse... If there was any 
easy way to convert all those emails from the last 15 years into a halfway 
working mail client I would do that instead of wasting my time with unloved 
and unsupported crap. But that is OT, and I am not giving up yet.

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Monday, July 25, 2016 10:55:45 PM CEST Diederik de Haas wrote:
> On maandag 25 juli 2016 22:08:23 CEST Tim Rühsen wrote:
> > BTW, I can't find such an option at all - maybe just for imap ?
> 
> Probably. I almost exclusively use imap.
> 
> > I really can't believe that this is a personal problem. I am just sitting
> > at a  much newer Sid installation and experience absolutely the same
> > problems. The question is: what did all of you do that I didn't ? And are
> > you sure that indexing and "Tools/Find Messages" really work for you ?
> 
> It's working fine here. I can go to a random mail, copy a word from it and
> put it in the search box and it'll find that mail again.
> Which database backend are you using for akonadi?

It is the mysql backend.
In fact I see (output by akonadi)
Database "akonadi" opened using driver "QMYSQL"

> I have to admit that akonadi is a difficult beast. But it's not really
> surprising given the number of protocols it needs to support and workaround
> faulty/different implementations of those protocols.
> It can be that if sth didn't work right the first time that it doesn't fix
> things properly afterwards when there were missing packages initially.
> But I have no idea how to properly fix things.
> 
> What you could try is:
> akonadictl fsck
> akonadictl vacuum

Thanks, I am aware of these and executed them like a hundred times. They make 
no difference.

Regards, Tim
 

signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Martin Steigerwald]

Hi Tim,

Am Montag, 25. Juli 2016, 22:10:36 CEST schrieb Tim Rühsen:
> On Montag, 25. Juli 2016 17:24:45 CEST Sandro Knauß wrote:
> > > It shows up with green Button and "Ready".
> > 
> > did you tried to restart akonadi? akonadictl restart? Because only with
> > that akonadi will recognize new agents etc.
> 
> I even rebooted without effect.
> And I see absolutely the same issues at a different (much newer) Sid
> installation. Find Messages just doesn't work. The *akonadisearch* packets
> were also missing - I manually installed here as well.

I think you need to tweak this one:

martin@merkaba:~/.config> cat baloorc 
[Akonadi]
aborted=false
agentIndexingVersion=4
dirtyCollections=
initialIndexingDone=true


I´d even just remove it, so it redos the initial indexing, cause if it has 
"initialIndexingDone=true" in it, it won´t index the whole collections 
anymore. I bet it may have this in it from KDE SC 4 times… after migration of 
configuration, but I am not sure.

It stores the index data it stores in ~/.local/share/akonadi/search_db – this 
directory totals to 2 GiB on my system. In case that Xapian database is 
corrupted somehow, it may crash. So for a clean start, it may make sense to 
remove that directory as well.

And well when I say remove, I rather suggest you move it out of the way, 
instead of removing it immediately.

As Sandro told, it needs to be "akonadi_indexing_agent" being active. 
Additionally to that: You can´t configure Akonadi Search with Systemsettings, 
Systemsetting just configured the desktop file search. Basically the mail and 
contact indexing part of Baloo has been split out and is now Akonadi search. 
Almost unchanged, except for search database location.

There is a way in KMail to disable fulltext indexing for folders, but as I 
found out, Akonadi doesn´t respect that setting.

I do think Akonadi Search doesn´t receive much love at the moment, and it 
shows.

Thanks,
-- 
Martin

Re: KDEPIM ready to be more broadly tested

[Diederik de Haas]

On maandag 25 juli 2016 22:08:23 CEST Tim Rühsen wrote:
> BTW, I can't find such an option at all - maybe just for imap ?

Probably. I almost exclusively use imap.

> I really can't believe that this is a personal problem. I am just sitting at
> a  much newer Sid installation and experience absolutely the same problems.
> The question is: what did all of you do that I didn't ? And are you sure
> that indexing and "Tools/Find Messages" really work for you ?

It's working fine here. I can go to a random mail, copy a word from it and put 
it in the search box and it'll find that mail again.
Which database backend are you using for akonadi?

I have to admit that akonadi is a difficult beast. But it's not really 
surprising given the number of protocols it needs to support and workaround 
faulty/different implementations of those protocols.
It can be that if sth didn't work right the first time that it doesn't fix 
things properly afterwards when there were missing packages initially.
But I have no idea how to properly fix things.

What you could try is:
akonadictl fsck
akonadictl vacuum

and see whether that improves things.


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Tim Rühsen]

On Montag, 25. Juli 2016 17:24:45 CEST Sandro Knauß wrote:
> Hey,
> 
> > It shows up with green Button and "Ready".
> 
> did you tried to restart akonadi? akonadictl restart? Because only with that
> akonadi will recognize new agents etc.

I even rebooted without effect.
And I see absolutely the same issues at a different (much newer) Sid 
installation. Find Messages just doesn't work. The *akonadisearch* packets 
were also missing - I manually installed here as well.

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Tim Rühsen]

On Montag, 25. Juli 2016 19:03:29 CEST Diederik de Haas wrote:
> On maandag 25 juli 2016 17:16:09 CEST Tim Ruehsen wrote:
> > t shows up with green Button and "Ready".
> > 
> > From the Details:
> > Status: Online, Idle
> > Status message: Ready
> > Capabilities: Unique, Autostart
> > Mimetypes: text/directory
> 
> Have you enabled "Download all messages for offline use"? I'm not sure, but
> I thought that was needed for indexing ... and it makes sense too.

I have several accounts, but use pop3 - so the messages are downloaded. They 
are moved via filters into their destination folders.
BTW, I can't find such an option at all - maybe just for imap ?

I really can't believe that this is a personal problem. I am just sitting at a 
much newer Sid installation and experience absolutely the same problems.
The question is: what did all of you do that I didn't ? And are you sure that 
indexing and "Tools/Find Messages" really work for you ?

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Diederik de Haas]

On zondag 17 juli 2016 20:18:35 CEST Lisandro Damián Nicanor Pérez Meyer 
wrote:
> If you run unstable but have refrained from installing the kdepim packages
> up  to now, we would appreciate it if you go ahead and install them now,
> reporting any issues that you may find.

I have also done a fresh install and ran into an annoying default setting 
"Enable server-side subscribtions" was enabled for *only* the first account I 
set up and the consequence of this is that the inbox doesn't show any mails, 
all subfolders did however.
If I hadn't ran into this issue before I very likely wouldn't have found the 
fix and even then it took me quite a while to realize that the serverside 
subscriptions was the issue.
That it was only enabled for the first account I set up added to the confusion 
as to why I wasn't seeing any mails in Inbox and it doesn't make sense to me 
at all. Either enabled it (by default) for all or for none.

Cheers,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Diederik de Haas]

On maandag 25 juli 2016 17:16:09 CEST Tim Ruehsen wrote:
> t shows up with green Button and "Ready".
> 
> From the Details:
> Status: Online, Idle
> Status message: Ready
> Capabilities: Unique, Autostart
> Mimetypes: text/directory

Have you enabled "Download all messages for offline use"? I'm not sure, but I 
thought that was needed for indexing ... and it makes sense too.


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Sandro Knauß]

Hey,

> It shows up with green Button and "Ready".

did you tried to restart akonadi? akonadictl restart? Because only with that 
akonadi will recognize new agents etc.

Regards,

sandro


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Monday, July 25, 2016 4:59:28 PM CEST Sandro Knauß wrote:
> Hey,
> 
> baloo and akonadi-search have nothing in common. The two things lived
> together in one repo, but didn't changed code.
> 
> > Meanwhile, I removed ~/.local/share/baloo and hand-edited
> > ~/.config/baloofilerc (systemsettings seems to be buggy and doesn't save
> > my
> > changes). Basically I added some exceptions and set first run=true.
> > Then I switched 'Enable File Search' in systemsettings off and on again.
> > After that, i see baloo_file and /usr/bin/baloo_file_extractor working...
> > since a few hours now (I let it run the night and we'll see tomorrow).
> 
> if baloo_file_extractor  doesn't help for kmail search. You have to see a
> akonadi_indexing_agent running. It should be visible in akonadiconsole at
> the agent tab.

It shows up with green Button and "Ready".

From the Details:
Status: Online, Idle
Status message: Ready
Capabilities: Unique, Autostart
Mimetypes: text/directory

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Sandro Knauß]

Hey,

baloo and akonadi-search have nothing in common. The two things lived together 
in one repo, but didn't changed code. 

> Meanwhile, I removed ~/.local/share/baloo and hand-edited
> ~/.config/baloofilerc (systemsettings seems to be buggy and doesn't save my
> changes). Basically I added some exceptions and set first run=true.
> Then I switched 'Enable File Search' in systemsettings off and on again.
> After that, i see baloo_file and /usr/bin/baloo_file_extractor working...
> since a few hours now (I let it run the night and we'll see tomorrow).

if baloo_file_extractor  doesn't help for kmail search. You have to see a 
akonadi_indexing_agent running. It should be visible in akonadiconsole at the 
agent tab. 

regards,

sandro



signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Monday, July 25, 2016 11:58:28 AM CEST Sandro Knauß wrote:
> Hey,
> 
> > I am not sure. There is no package akonadi-search, also no utility
> > (searched with apt-file).
> 
> akonadi-search is the upstream name - so yes debian has split it into
> multiple packages.
> 
> > Do you mean
> > $ dpkg -l '*akonadisearch*'
> > ii  libkf5akonadisearchdebug5:amd64 16.04.2-2amd64
> > Akonadi search debug library
> > ii  libkf5akonadisearchpim5:amd64   16.04.2-2amd64
> > Akonadi search library
> > 
> > Should I manually install any of these ?
> > libkf5akonadisearchcore5
> > libkf5akonadisearchxapian5
> > libkf5akonadisearch-data
> > libkf5akonadisearch-bin
> 
> I have installed every package of these and it works for me. So yes give it
> a try.

Thanks Sandro !

Just installing (and rebooting) didn't make any difference.

Meanwhile, I removed ~/.local/share/baloo and hand-edited ~/.config/baloofilerc 
(systemsettings seems to be buggy and doesn't save my changes). Basically I 
added some exceptions and set first run=true.
Then I switched 'Enable File Search' in systemsettings off and on again.
After that, i see baloo_file and /usr/bin/baloo_file_extractor working... since 
a few hours now (I let it run the night and we'll see tomorrow).

What meanwhile changed in the Kmail Folder Properties/Maintenance:
"Indexing" shows a hook at "Enable Full Text Indexing" and says "Indexed 1 
item of this collection". Other folder already show some more indexed items... 
but any progress here is extremely slow. Maybe because I have ten thousands of 
emails, many have huge (binary) attachments.

Thanks for your help and I report on any progress.

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Sandro Knauß]

Hey,

> I am not sure. There is no package akonadi-search, also no utility (searched
> with apt-file).

akonadi-search is the upstream name - so yes debian has split it into multiple 
packages.

> Do you mean
> $ dpkg -l '*akonadisearch*'
> ii  libkf5akonadisearchdebug5:amd64 16.04.2-2amd64
> Akonadi search debug library
> ii  libkf5akonadisearchpim5:amd64   16.04.2-2amd64
> Akonadi search library
> 
> Should I manually install any of these ?
> libkf5akonadisearchcore5
> libkf5akonadisearchxapian5
> libkf5akonadisearch-data
> libkf5akonadisearch-bin

I have installed every package of these and it works for me. So yes give it a 
try.

Regards,

sandro

signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

On Monday, July 25, 2016 11:24:24 AM CEST Sandro Knauß wrote:
> Hey,
> 
> kmail using akonadi-search for indexing. Is that installed?

I am not sure. There is no package akonadi-search, also no utility (searched 
with apt-file).

Do you mean
$ dpkg -l '*akonadisearch*'
ii  libkf5akonadisearchdebug5:amd64 16.04.2-2amd64
Akonadi search debug library
ii  libkf5akonadisearchpim5:amd64   16.04.2-2amd64
Akonadi search library

Should I manually install any of these ?
libkf5akonadisearchcore5
libkf5akonadisearchxapian5
libkf5akonadisearch-data
libkf5akonadisearch-bin

Regards, Tim

> --
> 
> Am Montag, 25. Juli 2016, 10:47:24 CEST schrieb Tim Ruehsen:
> > KMail indexing still doesn't work.
> > 
> > Switched Systemsettings:Workspace->Search->File Search off and on again.
> > This started baloo indexing for a while. But Folders in Kmail still report
> > "Still not indexed." (Folder:Properties->Maintenance). Hook is set at
> > 'Enable Full Text Indexing".
> > 
> > Also removed ~/.kde/share/config/baloorc and restarted akonadi. Without
> > success. Now:
> > $ cat ~/.kde/share/config/baloorc
> > [Akonadi]
> > agentIndexingVersion=4
> > 
> > Is there any packet missing or a trick to get it working ?
> > 
> > Regards, Tim
> > 
> > ii  baloo 4:5.23.0-1   all  transitional
> > package for baloo
> > ii  baloo-kf5 5.23.0-1 amd64framework for
> > searching and managing metadata
> > ii  baloo-utils   4:4.14.2-2   amd64utilities for
> > Baloo
> > ii  kde-config-baloo-advanced 1.00.00-1amd64advanced
> > configuration module for KDE Baloo Desktop Search
> > ii  libbaloocore4 4:4.14.2-2   amd64core functionality
> > for Baloo
> > ii  libbaloofiles44:4.14.2-2   amd64files
> > functionality
> > for Baloo
> > ii  libbalooxapian4   4:4.14.2-2   amd64Xapian
> > functionality for Baloo
> > ii  libkf5baloo5  5.23.0-1 amd64framework for
> > searching and managing metadata core lib.
> > ii  libkf5balooengine55.23.0-1 amd64framework for
> > searching and managing metadata plugins
> > ii  libkf5baloowidgets-bin16.04.0-1amd64Wigets for use
> > with
> > Baloo - binaries
> > ii  libkf5baloowidgets5:amd64 16.04.0-1amd64Wigets for use
> > with
> > Baloo
> > 
> > 
> > ii  akonadi-backend-mysql   4:16.04.3-1  all  MySQL
> > storage
> > backend for Akonadi
> > ii  akonadi-server  4:16.04.3-1  amd64Akonadi PIM
> > storage service
> > ii  akonadiconsole  4:16.04.3-1  amd64management
> > and debugging console for akonadi
> > ii  libakonadi-contact4 4:4.14.10-5  amd64Akonadi
> > contacts access library
> > ii  libakonadi-kde4 4:4.14.10-5  amd64library for
> > using the Akonadi PIM data server
> > ii  libakonadi-kmime4   4:4.14.10-5  amd64Akonadi MIME
> > handling library
> > ii  libakonadiprotocolinternals11.13.0-10amd64libraries
> > for
> > the Akonadi PIM storage service
> > ii  libkf5akonadiagentbase5:amd64   4:16.04.3-1  amd64Akonadi
> > agent
> > base library
> > ii  libkf5akonadicalendar5:amd6416.04.2-2amd64library
> > providing calendar helpers for Akonadi items
> > ii  libkf5akonadicontact5:amd64 4:16.04.2-2  amd64Akonadi
> > contacts access library
> > ii  libkf5akonadicore-bin   4:16.04.3-1  amd64Tools for
> > Akonadi core library
> > ii  libkf5akonadicore5:amd644:16.04.3-1  amd64Akonadi core
> > library
> > ii  libkf5akonadimime5:amd644:16.04.2-2  amd64Akonadi MIME
> > handling library
> > ii  libkf5akonadinotes5:amd64   4:16.04.2-2  amd64Akonadi
> > notes
> > access library
> > ii  libkf5akonadiprivate5   4:16.04.3-1  amd64libraries
> > for
> > the Akonadi PIM storage service
> > ii  libkf5akonadisearchdebug5:amd64 16.04.2-2amd64Akonadi
> > search debug library
> > ii  libkf5akonadisearchpim5:amd64   16.04.2-2amd64Akonadi
> > search library
> > ii  libkf5akonadiwidgets5:amd64 4:16.04.3-1  amd64Akonadi
> > widgets library
> > 
> > 
> > ii  kdepim4:16.04.3-1  all  Personal
> > Information Management apps from the official KDE release
> > ii  kdepim-addons 16.04.2-2amd64Addons for
> > KDE PIM applications
> > ii  kdepim-doc4:16.04.3-1  all  KDE
> > Personal Information Management library documentation
> > ii  kdepim-runtime4:16.04.2-2  amd64runtime
> > components for Akonadi KDE
> > ii  kdepim-themeeditors   4:16.04.3-1  amd64Theme
> > Editors for KDE PIM applications
> > ii  kdepimlibs-data   4:16.04.2-2  all  kdepimlibs

Re: KDEPIM ready to be more broadly tested

[Sandro Knauß]

Hey,

kmail using akonadi-search for indexing. Is that installed?

Regards,

sandro

--
Am Montag, 25. Juli 2016, 10:47:24 CEST schrieb Tim Ruehsen:
> KMail indexing still doesn't work.
> 
> Switched Systemsettings:Workspace->Search->File Search off and on again.
> This started baloo indexing for a while. But Folders in Kmail still report
> "Still not indexed." (Folder:Properties->Maintenance). Hook is set at
> 'Enable Full Text Indexing".
> 
> Also removed ~/.kde/share/config/baloorc and restarted akonadi. Without
> success. Now:
> $ cat ~/.kde/share/config/baloorc
> [Akonadi]
> agentIndexingVersion=4
> 
> Is there any packet missing or a trick to get it working ?
> 
> Regards, Tim
> 
> ii  baloo 4:5.23.0-1   all  transitional package
> for baloo
> ii  baloo-kf5 5.23.0-1 amd64framework for
> searching and managing metadata
> ii  baloo-utils   4:4.14.2-2   amd64utilities for Baloo
> ii  kde-config-baloo-advanced 1.00.00-1amd64advanced
> configuration module for KDE Baloo Desktop Search
> ii  libbaloocore4 4:4.14.2-2   amd64core functionality
> for Baloo
> ii  libbaloofiles44:4.14.2-2   amd64files functionality
> for Baloo
> ii  libbalooxapian4   4:4.14.2-2   amd64Xapian functionality
> for Baloo
> ii  libkf5baloo5  5.23.0-1 amd64framework for
> searching and managing metadata core lib.
> ii  libkf5balooengine55.23.0-1 amd64framework for
> searching and managing metadata plugins
> ii  libkf5baloowidgets-bin16.04.0-1amd64Wigets for use with
> Baloo - binaries
> ii  libkf5baloowidgets5:amd64 16.04.0-1amd64Wigets for use with
> Baloo
> 
> 
> ii  akonadi-backend-mysql   4:16.04.3-1  all  MySQL storage
> backend for Akonadi
> ii  akonadi-server  4:16.04.3-1  amd64Akonadi PIM
> storage service
> ii  akonadiconsole  4:16.04.3-1  amd64management and
> debugging console for akonadi
> ii  libakonadi-contact4 4:4.14.10-5  amd64Akonadi
> contacts access library
> ii  libakonadi-kde4 4:4.14.10-5  amd64library for
> using the Akonadi PIM data server
> ii  libakonadi-kmime4   4:4.14.10-5  amd64Akonadi MIME
> handling library
> ii  libakonadiprotocolinternals11.13.0-10amd64libraries for
> the Akonadi PIM storage service
> ii  libkf5akonadiagentbase5:amd64   4:16.04.3-1  amd64Akonadi agent
> base library
> ii  libkf5akonadicalendar5:amd6416.04.2-2amd64library
> providing calendar helpers for Akonadi items
> ii  libkf5akonadicontact5:amd64 4:16.04.2-2  amd64Akonadi
> contacts access library
> ii  libkf5akonadicore-bin   4:16.04.3-1  amd64Tools for
> Akonadi core library
> ii  libkf5akonadicore5:amd644:16.04.3-1  amd64Akonadi core
> library
> ii  libkf5akonadimime5:amd644:16.04.2-2  amd64Akonadi MIME
> handling library
> ii  libkf5akonadinotes5:amd64   4:16.04.2-2  amd64Akonadi notes
> access library
> ii  libkf5akonadiprivate5   4:16.04.3-1  amd64libraries for
> the Akonadi PIM storage service
> ii  libkf5akonadisearchdebug5:amd64 16.04.2-2amd64Akonadi search
> debug library
> ii  libkf5akonadisearchpim5:amd64   16.04.2-2amd64Akonadi search
> library
> ii  libkf5akonadiwidgets5:amd64 4:16.04.3-1  amd64Akonadi
> widgets library
> 
> 
> ii  kdepim4:16.04.3-1  all  Personal
> Information Management apps from the official KDE release
> ii  kdepim-addons 16.04.2-2amd64Addons for
> KDE PIM applications
> ii  kdepim-doc4:16.04.3-1  all  KDE Personal
> Information Management library documentation
> ii  kdepim-runtime4:16.04.2-2  amd64runtime
> components for Akonadi KDE
> ii  kdepim-themeeditors   4:16.04.3-1  amd64Theme
> Editors for KDE PIM applications
> ii  kdepimlibs-data   4:16.04.2-2  all  kdepimlibs -
> data files
> ii  kdepimlibs-kio-plugins4:4.14.10-5  amd64kio slaves
> used by KDE PIM applications
> ii  kf5-kdepim-apps-libs-data 4:16.04.2-2  all  KDE PIM mail
> related libraries, data files
> ii  kf5-kdepimlibs-kio-plugins4:16.04.2-2  amd64kio slaves
> used by KDE PIM applications
> ii  libkf5kdepimdbusinterfaces5:amd64 4:16.04.2-2  amd64KDE PIM
> D-Bus interfaces library
> ii  libkf5libkdepim-data  4:16.04.2-3  all  KDE PIM
> library - data files
> ii  libkf5libkdepim-plugins:amd64 4:16.04.2-3  amd64KDE PIM
> library - plugins
> ii  libkf5libkdepim5:amd644:16.04.2-3  amd64KDE PIM
> library
> 
> 
> On Sunday, July 17, 2016 8:18:35 PM CEST Lisand

Re: KDEPIM ready to be more broadly tested

[Tim Ruehsen]

KMail indexing still doesn't work.

Switched Systemsettings:Workspace->Search->File Search off and on again. This 
started baloo indexing for a while. But Folders in Kmail still report "Still 
not indexed." (Folder:Properties->Maintenance). Hook is set at 'Enable Full 
Text Indexing".

Also removed ~/.kde/share/config/baloorc and restarted akonadi. Without 
success. Now:
$ cat ~/.kde/share/config/baloorc
[Akonadi]
agentIndexingVersion=4

Is there any packet missing or a trick to get it working ?

Regards, Tim

ii  baloo 4:5.23.0-1   all  transitional package 
for baloo
ii  baloo-kf5 5.23.0-1 amd64framework for 
searching and managing metadata
ii  baloo-utils   4:4.14.2-2   amd64utilities for Baloo
ii  kde-config-baloo-advanced 1.00.00-1amd64advanced configuration 
module for KDE Baloo Desktop Search
ii  libbaloocore4 4:4.14.2-2   amd64core functionality for 
Baloo
ii  libbaloofiles44:4.14.2-2   amd64files functionality for 
Baloo
ii  libbalooxapian4   4:4.14.2-2   amd64Xapian functionality 
for Baloo
ii  libkf5baloo5  5.23.0-1 amd64framework for 
searching and managing metadata core lib.
ii  libkf5balooengine55.23.0-1 amd64framework for 
searching and managing metadata plugins
ii  libkf5baloowidgets-bin16.04.0-1amd64Wigets for use with 
Baloo - binaries
ii  libkf5baloowidgets5:amd64 16.04.0-1amd64Wigets for use with 
Baloo


ii  akonadi-backend-mysql   4:16.04.3-1  all  MySQL storage 
backend for Akonadi
ii  akonadi-server  4:16.04.3-1  amd64Akonadi PIM 
storage service
ii  akonadiconsole  4:16.04.3-1  amd64management and 
debugging console for akonadi
ii  libakonadi-contact4 4:4.14.10-5  amd64Akonadi contacts 
access library
ii  libakonadi-kde4 4:4.14.10-5  amd64library for 
using the Akonadi PIM data server
ii  libakonadi-kmime4   4:4.14.10-5  amd64Akonadi MIME 
handling library
ii  libakonadiprotocolinternals11.13.0-10amd64libraries for 
the Akonadi PIM storage service
ii  libkf5akonadiagentbase5:amd64   4:16.04.3-1  amd64Akonadi agent 
base library
ii  libkf5akonadicalendar5:amd6416.04.2-2amd64library 
providing calendar helpers for Akonadi items
ii  libkf5akonadicontact5:amd64 4:16.04.2-2  amd64Akonadi contacts 
access library
ii  libkf5akonadicore-bin   4:16.04.3-1  amd64Tools for 
Akonadi core library
ii  libkf5akonadicore5:amd644:16.04.3-1  amd64Akonadi core 
library
ii  libkf5akonadimime5:amd644:16.04.2-2  amd64Akonadi MIME 
handling library
ii  libkf5akonadinotes5:amd64   4:16.04.2-2  amd64Akonadi notes 
access library
ii  libkf5akonadiprivate5   4:16.04.3-1  amd64libraries for 
the Akonadi PIM storage service
ii  libkf5akonadisearchdebug5:amd64 16.04.2-2amd64Akonadi search 
debug library
ii  libkf5akonadisearchpim5:amd64   16.04.2-2amd64Akonadi search 
library
ii  libkf5akonadiwidgets5:amd64 4:16.04.3-1  amd64Akonadi widgets 
library


ii  kdepim4:16.04.3-1  all  Personal 
Information Management apps from the official KDE release
ii  kdepim-addons 16.04.2-2amd64Addons for KDE 
PIM applications
ii  kdepim-doc4:16.04.3-1  all  KDE Personal 
Information Management library documentation
ii  kdepim-runtime4:16.04.2-2  amd64runtime 
components for Akonadi KDE
ii  kdepim-themeeditors   4:16.04.3-1  amd64Theme Editors 
for KDE PIM applications
ii  kdepimlibs-data   4:16.04.2-2  all  kdepimlibs - 
data files
ii  kdepimlibs-kio-plugins4:4.14.10-5  amd64kio slaves 
used by KDE PIM applications
ii  kf5-kdepim-apps-libs-data 4:16.04.2-2  all  KDE PIM mail 
related libraries, data files
ii  kf5-kdepimlibs-kio-plugins4:16.04.2-2  amd64kio slaves 
used by KDE PIM applications
ii  libkf5kdepimdbusinterfaces5:amd64 4:16.04.2-2  amd64KDE PIM D-Bus 
interfaces library
ii  libkf5libkdepim-data  4:16.04.2-3  all  KDE PIM 
library - data files
ii  libkf5libkdepim-plugins:amd64 4:16.04.2-3  amd64KDE PIM 
library - plugins
ii  libkf5libkdepim5:amd644:16.04.2-3  amd64KDE PIM 
library


On Sunday, July 17, 2016 8:18:35 PM CEST Lisandro Damián Nicanor Pérez Meyer 
wrote:
> As was posted [a couple of weeks ago], the latest version of KDE has been
> uploaded to unstable.
> 
> [a couple of weeks ago]
>  .html>
> 
> All packages are now uploaded and built and we believe this

Re: KDEPIM ready to be more broadly tested

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 20 de julio de 2016 9:31:46 A. M. ART Christian Hilberg wrote:
> Am Dienstag, 19. Juli 2016, 15:56:41 CEST schrieb Christian Hilberg:
> > Am Dienstag 19 Juli 2016, 11:14:30 schrieb Christian Hilberg:
> > > Am Dienstag 19 Juli 2016, 11:01:21 schrieb Christian Hilberg:
> > > > [...]
> > > > While syncing the IMAP folders, the process got stuck at 100% at one
> > > > folder[...] Trying to resolve this now...
> > 
> > [...]
> 
> Well, allowed a second CPU core into my VM and the issue is gone...
> That smells like timing/timeout issue. The missing feedback to the
> user via the UI is already reported upstream, iirc.

Wow, excellent report!

It's worth to note that I'm just being the messenger here, you all seem to 
know more than I do about K* stuff :)


-- 
En los momentos de crisis, la imaginación es mas importante que el
conocimiento.
 Albert Einstein

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Christian Hilberg]

Am Dienstag, 19. Juli 2016, 15:56:41 CEST schrieb Christian Hilberg:
> Am Dienstag 19 Juli 2016, 11:14:30 schrieb Christian Hilberg:
> > Am Dienstag 19 Juli 2016, 11:01:21 schrieb Christian Hilberg:
> > > [...]
> > > While syncing the IMAP folders, the process got stuck at 100% at one
> > > folder[...] Trying to resolve this now...
> [...]

Well, allowed a second CPU core into my VM and the issue is gone...
That smells like timing/timeout issue. The missing feedback to the
user via the UI is already reported upstream, iirc.

Best,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
Geschäftsführer: Nils Faerber, Ole Reinhardt
HR Siegen, HR B 9613

Re: KDEPIM ready to be more broadly tested

[Dominique Dumont]

On Tuesday, July 19, 2016 4:38:58 PM CEST Sandro Knauß wrote:
> looks like: https://bugs.kde.org/show_bug.cgi?id=362958

Indeed. Thanks for the pointer.

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Re: KDEPIM ready to be more broadly tested

[Sandro Knauß]

Moin,

> Calendar buttons are gone: I used to have a set of button to manage meeting
> when I got an invite from outlook users (i.e. a mail with an ics
> attachment). I cannot view the content of the calendar invite.

looks like: https://bugs.kde.org/show_bug.cgi?id=362958

regards,

sandro


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested

[Christian Hilberg]

Am Dienstag 19 Juli 2016, 11:14:30 schrieb Christian Hilberg:
> Am Dienstag 19 Juli 2016, 11:01:21 schrieb Christian Hilberg:
> > [...]
> > While syncing the IMAP folders, the process got stuck at 100% at one 
> > folder[...]
> > Trying to resolve this now...
> 
> Funny, oftentimes, Akonadiconsole shows a several thousand percent
> of "completeness" for the IMAP resource when trying to "Synchronize all",
> before the connection to the Akonadi server fails. This happens for
> seemingly random folders, now this one, then that one.
> 
> The Akonadi debugger information view shows a message which translates
> to "Connection to the akonadi service cannot be established".
> 
> Many of the folders are biggish, some thousand messages. Maybe a timeout
> of some sort?

Reduced the guilty folder's size, still:

...
log_imapresource: Detected inconsistency in local cache, we're missing some 
messages. Server:  547  Local:  500
log_imapresource: Refetching complete mailbox.
QDBusObjectPath Akonadi::Server::NotificationManager::subscribe(const QString&, 
bool) Akonadi::Server::NotificationManager(0x1e64810) "kontact_6660_EbGSKI" 
false
Database "akonadi" opened using driver "QMYSQL"
New notification bus: "/subscriber/kontact_6660_EbGSKI"
akonadicore_log: Invalid command, the world is going to end!
QIODevice::read (QLocalSocket): device not open
akonadicore_log: "Cannot connect to the Akonadi service."
Shutting down "akonadi_imap_resource_0" ...
Database "akonadi" opened using driver "QMYSQL"
Invalid command: no such handler for Transaction
akonadicore_log: Socket error occurred: "QLocalSocket: Remote closed"
akonadicore_log: Error during ItemSync:  "Cannot connect to the Akonadi 
service."
Shutting down "0x2126a20" ...
...

The IMAP resource seems to crash need to restart Akonadi, otherwise
nothing will work with this resource after the logged fail.

Looks like [0], though it is claimed to have been fixed in 16.04.3 ...

Best,

Christian

[0] https://bugs.kde.org/show_bug.cgi?id=364045

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
Geschäftsführer: Nils Faerber, Ole Reinhardt
HR Siegen, HR B 9613

Re: KDEPIM ready to be more broadly tested

[Dominique Dumont]

On Sunday, July 17, 2016 8:18:35 PM CEST Lisandro Damián Nicanor Pérez Meyer 
wrote:
> If you run unstable but have refrained from installing the kdepim packages
> up  to now, we would appreciate it if you go ahead and install them now,
> reporting any issues that you may find.

Calendar buttons are gone: I used to have a set of button to manage meeting 
when I got an invite from outlook users (i.e. a mail with an ics attachment). 
I cannot view the content of the calendar invite.

As a work-around, I right click on the ics part (in message structure window), 
open it with korganization and merge it in my calendat. Unfortunately, the 
meeting is set using local time zone and does not take into account the time 
zone of the organizer of the meeting. So some meeting are off by a few hours.

Thanks for working on kdepim :-)

All the best
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Re: KDEPIM ready to be more broadly tested

[Christian Hilberg]

Am Dienstag 19 Juli 2016, 11:01:21 schrieb Christian Hilberg:
> [...]
> While syncing the IMAP folders, the process got stuck at 100% at one 
> folder[...]
> Trying to resolve this now...

Funny, oftentimes, Akonadiconsole shows a several thousand percent
of "completeness" for the IMAP resource when trying to "Synchronize all",
before the connection to the Akonadi server fails. This happens for
seemingly random folders, now this one, then that one.

The Akonadi debugger information view shows a message which translates
to "Connection to the akonadi service cannot be established".

Many of the folders are biggish, some thousand messages. Maybe a timeout
of some sort?

Regards,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
Geschäftsführer: Nils Faerber, Ole Reinhardt
HR Siegen, HR B 9613

Re: KDEPIM ready to be more broadly tested

[Christian Hilberg]

Am Montag 18 Juli 2016, 09:00:45 schrieb Lisandro Damián Nicanor Pérez Meyer:
> On domingo, 17 de julio de 2016 8:18:35 P. M. ART Lisandro Damián Nicanor 
> Pérez Meyer wrote:
> > As was posted [a couple of weeks ago], the latest version of KDE
> 
> This is of course KDEPIM :)

Of *course*. :-)

Updated my Sid box today, got KDEPIM and libs 16.04.3. Wanted to check whether
my favourite issue [0] had been fixed. =)

Created a fresh user on the box, logged in for the first time into Plasma5,
and started Kontact.

MySQL refused to start up properly (while tests 1..4 passed):

---8<---
Test 5:  ERROR


MySQL server log contains errors.
Details: The MySQL server error log file '/home/chris/.local/share/akonadi/db_data/mysql.err'
 contains errors.

File content of '/home/chris/.local/share/akonadi/db_data/mysql.err':
160719  9:09:39 [Note] Plugin 'FEDERATED' is disabled.
160719  9:09:39 InnoDB: The InnoDB memory heap is disabled
160719  9:09:39 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160719  9:09:39 InnoDB: Compressed tables use zlib 1.2.8
160719  9:09:39 InnoDB: Using Linux native AIO
160719  9:09:39 InnoDB: Initializing buffer pool, size = 80.0M
160719  9:09:39 InnoDB: Completed initialization of buffer pool
160719  9:09:39 InnoDB: highest supported file format is Barracuda.
160719  9:09:39  InnoDB: Waiting for the background threads to start
160719  9:09:40 InnoDB: 5.5.46 started; log sequence number 1622641
160719  9:09:40 [Warning] Can't open and lock time zone table: Table 
'mysql.time_zone_leap_second' doesn't exist trying to live without them
160719  9:09:40 [ERROR] Can't open and lock privilege tables: Table 
'mysql.servers' doesn't exist
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_current' has the wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_history' has the wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_history_long' has the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'setup_consumers' has 
the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'setup_instruments' 
has the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'setup_timers' has 
the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'performance_timers' 
has the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'threads' has the 
wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_summary_by_thread_by_event_name' has the 
wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_summary_by_instance' has the wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'events_waits_summary_global_by_event_name' has the wrong 
structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'file_summary_by_event_name' has the wrong structure
160719  9:09:40 [ERROR] Native table 
'performance_schema'.'file_summary_by_instance' has the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'mutex_instances' has 
the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'rwlock_instances' 
has the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'cond_instances' has 
the wrong structure
160719  9:09:40 [ERROR] Native table 'performance_schema'.'file_instances' has 
the wrong structure
160719  9:09:40 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.46-0+deb8u1'  socket: '/tmp/akonadi-chris.raoZs2/mysql.socket'  
port: 0  (Debian)
160719  9:09:40 [Note] /usr/sbin/mysqld: Normal shutdown

160719  9:09:40  InnoDB: Starting shutdown...
160719  9:09:42  InnoDB: Shutdown completed; log sequence number 1622651
160719  9:09:42 [Note] /usr/sbin/mysqld: Shutdown complete
---8<---

>From what I found in the reports, this looks like [1].

I have checked that

* there is enough free disk space (~7GB free)
* the Akonadi directory structure under ~/.local/share/akonadi has the right 
permissions
  (this is not a migrated DB, but freshly created, as noted above)

So I thought this might be a wrong default setting with the table types, as 
Akonadi requires
InnoDB, as noted in [1]. But then, the log above shows that InnoDB is used.

As I am running the tests inside a virtual box, I assumed I might have had too 
little memory
reserved. Cleared the users' home, increased virtual machine mem from 4GB to 
8GB and started
over.

Alas, same thing happened. A migration might eat up truckloads of mem, but a 
fresh install
with no IMAP account yet -- just the MySQL DB -- I think 8GB of mem should 
suffice.

After quitting the email account wizard and Kontact alltogether, and starting 
Kontact anew,
no error dialog was shown. However, 'akonadictl status' keeps telling that the 
service is
down.

Trying the hint provided in [2] (deleting the db_data Akonad

Re: KDEPIM ready to be more broadly tested [What about testing freeze]

[inkbottle]

On Monday, July 18, 2016 13:06:22 Lisandro Damián Nicanor Pérez Meyer wrote:
> On lunes, 18 de julio de 2016 3:41:33 P. M. ART inkbottle wrote:
> > On Sunday, July 17, 2016 20:18:35 Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > > As was posted [a couple of weeks ago], the latest version of KDE has
> > > been
> > > uploaded to unstable.
> > > 
> > > [a couple of weeks ago]
> > >  > > bl
> > > e
> > > .html>
> > > 
> > > All packages are now uploaded and built and we believe this version is
> > > ready to be more broadly tested.
> > 
> > Hi,
> > 
> > I like to follow "testing", which I do for quite some time, but then I
> > can't remember what is the right thing to do when there is a freeze, as
> > it is the case now:
> > https://release.debian.org/testing/freeze_policy.html
> > 
> > On the one hand I really want to give all those packages a try (now), on
> > the other hand I'm yet a wee bit reluctant to shift to sid... (I remember
> > I had troubles, in the past, after doing so, and sticking to it for a
> > period of time)
> > 
> > When Strech is the new stable, will sid be the new testing?
> > Should I go for a temporary shift?
> 
> the packages will be in Stretch hopefully soon, so no need to worry.
Great,
Thanks

Re: KDEPIM ready to be more broadly tested [What about testing freeze]

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 18 de julio de 2016 3:41:33 P. M. ART inkbottle wrote:
> On Sunday, July 17, 2016 20:18:35 Lisandro Damián Nicanor Pérez Meyer wrote:
> > As was posted [a couple of weeks ago], the latest version of KDE has been
> > uploaded to unstable.
> > 
> > [a couple of weeks ago]
> >  > e
> > .html>
> > 
> > All packages are now uploaded and built and we believe this version is
> > ready to be more broadly tested.
> 
> Hi,
> 
> I like to follow "testing", which I do for quite some time, but then I can't
> remember what is the right thing to do when there is a freeze, as it is the
> case now:
> https://release.debian.org/testing/freeze_policy.html
> 
> On the one hand I really want to give all those packages a try (now), on the
> other hand I'm yet a wee bit reluctant to shift to sid... (I remember I had
> troubles, in the past, after doing so, and sticking to it for a period of
> time)
> 
> When Strech is the new stable, will sid be the new testing?
> Should I go for a temporary shift?

the packages will be in Stretch hopefully soon, so no need to worry.


-- 
Cuando me preguntaron sobre algún arma capaz de contrarrestar el poder de la
bomba atómica, yo sugerí la mejor de todas: la paz.
 Albert Einstein

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: KDEPIM ready to be more broadly tested [What about testing freeze]

[inkbottle]

On Sunday, July 17, 2016 20:18:35 Lisandro Damián Nicanor Pérez Meyer wrote:
> As was posted [a couple of weeks ago], the latest version of KDE has been
> uploaded to unstable.
> 
> [a couple of weeks ago]
>  .html>
> 
> All packages are now uploaded and built and we believe this version is ready
> to be more broadly tested.

Hi,

I like to follow "testing", which I do for quite some time, but then I can't 
remember what is the right thing to do when there is a freeze, as it is the 
case now:
https://release.debian.org/testing/freeze_policy.html

On the one hand I really want to give all those packages a try (now), on the 
other hand I'm yet a wee bit reluctant to shift to sid... (I remember I had 
troubles, in the past, after doing so, and sticking to it for a period of 
time)

When Strech is the new stable, will sid be the new testing?
Should I go for a temporary shift?

Chris




> If you run unstable but have refrained from installing the kdepim packages
> up to now, we would appreciate it if you go ahead and install them now,
> reporting any issues that you may find.
> 
> Given that this is a big update that includes quite a number of plugins and
> libraries, it's strongly recommended that you restart your KDE session after
> updating the packages.
> 
> Happy hacking,
> 
> The Debian Qt/KDE Team.

Re: KDEPIM ready to be more broadly tested

[Lisandro Damián Nicanor Pérez Meyer]

On domingo, 17 de julio de 2016 8:18:35 P. M. ART Lisandro Damián Nicanor 
Pérez Meyer wrote:
> As was posted [a couple of weeks ago], the latest version of KDE

This is of course KDEPIM :)

-- 
Antiguo proverbio del Viejo Machi: "Prefiero que mi cerebro esté en la
cresta de la ola, y mi PC un paso atrás sirviéndolo y no tener mi PC en
el 'estado del arte' y mi cerebro un paso atrás asistiéndola."
  http://www.grulic.org.ar/lurker/message/20090507.020516.ffda0441.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

KDEPIM ready to be more broadly tested

[Lisandro Damián Nicanor Pérez Meyer]

As was posted [a couple of weeks ago], the latest version of KDE has been 
uploaded to unstable.

[a couple of weeks ago] 


All packages are now uploaded and built and we believe this version is ready 
to be more broadly tested.

If you run unstable but have refrained from installing the kdepim packages up 
to now, we would appreciate it if you go ahead and install them now, reporting 
any issues that you may find.

Given that this is a big update that includes quite a number of plugins and 
libraries, it's strongly recommended that you restart your KDE session after 
updating the packages.

Happy hacking,

The Debian Qt/KDE Team.

-- 
So that's it - insecure, indiscriminate, user-hostile, slow, and full
of difficult, nit-picking people. Any other online community would
count each of these strengths as a terrible flaw. Perhaps wiki works
because the other online communities don't.
  PeterMerel about wikis

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.