Re: KDEPIM ready to be more broadly tested
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
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.
KDE Connect media player issue
I've recently discovered this application and it's really amazing and useful. What is working not so good is the media remote control plugin, because it's not able to automatically detected if you are using a compatible media player like amarok or vlc (this should be documented somewhere). I've found a workaround that consists in tinkering with KDE Connect options in systemsettings: you need to disable and to enable multimedia control receiver, than on the smartphone app the media player will show and will be working. I'm guessing if this is a problem on the app side or on the KDE side, what I know it's that the app is complaining about the KDE counterpart being older. Valerio
Re: KDEPIM ready to be more broadly tested
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: KDE Connect media player issue
On 27 July 2016 at 13:43, Valerio Passini wrote: > I've recently discovered this application and it's really amazing and > useful. > What is working not so good is the media remote control plugin, because > it's > not able to automatically detected if you are using a compatible media > player > like amarok or vlc (this should be documented somewhere). I've found a > workaround that consists in tinkering with KDE Connect options in > systemsettings: you need to disable and to enable multimedia control > receiver, > than on the smartphone app the media player will show and will be working. > I'm > guessing if this is a problem on the app side or on the KDE side, what I > know > it's that the app is complaining about the KDE counterpart being older. > > Valerio > > Hi, This is a bug in the computer side of the application. https://bugs.kde.org/show_bug.cgi?id=352529 The application doesn't detect when a media player is started, only those that are running when the plugin is loaded. This is fixed in the 1.0 version that was released 4 days ago in the kde git. The 1.0 version source isn't released yet in http://download.kde.org/unstable/kdeconnect/. When it's released there it can be packaged for Debian. -- Sami
Re: Am I wrong understanding akonadi won't go to testing?
On Tuesday, July 26, 2016 17:08:54 you wrote: > I understand there: https://qa.debian.org/excuses.php?package=akonadi > the only excuse remaining for akonadi to move to testing is: > https://release.debian.org/testing/freeze_policy.html > And I see no reason why this excuse should be removed, I don't see it would > fit in "Changes which can be considered". > > Or am I mistaken there? OK, so I'm mistaken. I've been very helpfully explained: "after the current kdepim transition in unstable the whole set of related packages will migrate to testing", and "the block request makes sure that testing remains in usable state" (I quote because it's still a little bit of Volapük to me) I find the link provided (https://release.debian.org/testing/freeze_policy.html) very confusing, because it refers to the "release" of stretch... And the freeze related to the release of stretch is only to take place in 2017... Or I'm only very dense there, because it's the first time I stumble on subtleties related to freezing process... I believe the transition of kdepim is over now: I see no excuses in the related packages which still stand save the aforementioned lock itself... Chris
Re: Am I wrong understanding akonadi won't go to testing?
Am Mittwoch, 27. Juli 2016, 13:35:33 CEST schrieb inkbottle: > On Tuesday, July 26, 2016 17:08:54 you wrote: > > I understand there: https://qa.debian.org/excuses.php?package=akonadi > > the only excuse remaining for akonadi to move to testing is: > > https://release.debian.org/testing/freeze_policy.html > > And I see no reason why this excuse should be removed, I don't see it > > would > > fit in "Changes which can be considered". > > > > Or am I mistaken there? > > OK, so I'm mistaken. > I've been very helpfully explained: > "after the current kdepim transition in unstable the whole set of related > packages will migrate to testing", and > "the block request makes sure that testing remains in usable state" > (I quote because it's still a little bit of Volapük to me) > > I find the link provided > (https://release.debian.org/testing/freeze_policy.html) > very confusing, because it refers to the "release" of stretch... > And the freeze related to the release of stretch is only to take place in > 2017... > > Or I'm only very dense there, because it's the first time I stumble on > subtleties related to freezing process... > > I believe the transition of kdepim is over now: I see no excuses in the > related packages which still stand save the aforementioned lock itself... Well it has been repeatedly complained that testing is in an unusable state, so… now the team uses transitions. That means, it may take (additional) weeks for a complete set of packages appear in testing. Its either that or broken testing. I don´t see much in between it. :) If you want to have stuff as it comes in, you can still switch to unstable – which works quite nicely for weeks already, IMHO. -- Martin
Re: KDEPIM ready to be more broadly tested
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: Am I wrong understanding akonadi won't go to testing?
On Wednesday, July 27, 2016 14:07:30 Martin Steigerwald wrote: > Am Mittwoch, 27. Juli 2016, 13:35:33 CEST schrieb inkbottle: > > On Tuesday, July 26, 2016 17:08:54 you wrote: > > > I understand there: https://qa.debian.org/excuses.php?package=akonadi > > > the only excuse remaining for akonadi to move to testing is: > > > https://release.debian.org/testing/freeze_policy.html > > > And I see no reason why this excuse should be removed, I don't see it > > > would > > > fit in "Changes which can be considered". > > > > > > Or am I mistaken there? > > > > OK, so I'm mistaken. > > I've been very helpfully explained: > > "after the current kdepim transition in unstable the whole set of related > > packages will migrate to testing", and > > "the block request makes sure that testing remains in usable state" > > (I quote because it's still a little bit of Volapük to me) > > > > I find the link provided > > (https://release.debian.org/testing/freeze_policy.html) > > very confusing, because it refers to the "release" of stretch... > > And the freeze related to the release of stretch is only to take place in > > 2017... > > > > Or I'm only very dense there, because it's the first time I stumble on > > subtleties related to freezing process... > > > > I believe the transition of kdepim is over now: I see no excuses in the > > related packages which still stand save the aforementioned lock itself... > > Well it has been repeatedly complained that testing is in an unusable state, > so… now the team uses transitions. That means, it may take (additional) > weeks for a complete set of packages appear in testing. Its either that or > broken testing. I don´t see much in between it. :) Thanks for the answer which settles things. I totally agree with this lock system: The default behaviour with the packages moving from unstable to testing provided 5 days have passed or a "release" bug has been filled could prove insufficient for a "testing" which is not "unstable". So, I won't be puzzled any more with that; However I reckon someone else seeing the explanations: "Freeze Policy for Stretch, let's release! What happens when we freeze...", might want explanations for himself. Chris > > If you want to have stuff as it comes in, you can still switch to unstable – > which works quite nicely for weeks already, IMHO.
Re: Am I wrong understanding akonadi won't go to testing?
Am 27.07.2016 um 14:07 schrieb Martin Steigerwald: > If you want to have stuff as it comes in, you can still switch to unstable – > which works quite nicely for weeks already, IMHO. I was long time afraid to use sid (although i work with debian 24x7 a day (servers and desktop), because it is called "unstable". But after I have switched and used sid a couple of weeks I am suprised about it, because I have less strugle with it instead of using testing. Especially the different versions in testing with kde were very annoying (I don't blame the maintainers about that). just my 2 cents -- Holger
Re: Am I wrong understanding akonadi won't go to testing?
Am Mittwoch, 27. Juli 2016, 17:38:55 CEST schrieb Holger Schramm: > Am 27.07.2016 um 14:07 schrieb Martin Steigerwald: > > If you want to have stuff as it comes in, you can still switch to unstable > > – which works quite nicely for weeks already, IMHO. > > I was long time afraid to use sid (although i work with debian 24x7 a > day (servers and desktop), because it is called "unstable". But after I > have switched and used sid a couple of weeks I am suprised about it, > because I have less strugle with it instead of using testing. Especially > the different versions in testing with kde were very annoying (I don't > blame the maintainers about that). Please note tough that there is no guarantee whatsoever that things work correctly in unstable. At some time I wasn´t even able to log in to the Plasma desktop, since it crashed while doing so. But this didn´t last for more than 2 days I AFAIR. The major transitions that build the background of this temporary instability, like the G++ ABI transition and some other stuff I don´t quite recall at the moment, are done. So I do not expect any major instability issues with unstable at the moment. But again, this is no guarantee. Back then I even installed MATE desktop that would even work if Qt would be completely broke (which it was for some time). On any account I suggest you are keeping another desktop around just in case, or at least be willing to temporarily install one, in case you want to follow unstable. Also… directly after a release it may be wise to stay with that release for a while, before following unstable again. That said, if you are willing to deal with issues, report them, help resolving them, find temporary workarounds, I see unstable as a quite viable alternative. Similar things apply to testing, however when using transitions works out as expected, in the future it may be a bit more stable, at the price of having to wait longer for new stuff to trickle in. What doesn´t work tough is to complain about that unstable is exactly that, well unstable, instead of focussing on the solution, i.e. making it stable again, or just applying a temporary workaround. I think this was one of the main points I´d like to bring up here all the time. Let it be a conscious decision and be ready to deal with the consequences of it and it can be quite adventurous, but lots of the time also quite pleasant experience. And if you stay positive and constructive, you help to keep the quality of Debian or to make it even better. -- Martin
Re: KDEPIM ready to be more broadly tested
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: Am I wrong understanding akonadi won't go to testing?
Am 27.07.2016 um 18:40 schrieb Martin Steigerwald: > Am Mittwoch, 27. Juli 2016, 17:38:55 CEST schrieb Holger Schramm: >> Am 27.07.2016 um 14:07 schrieb Martin Steigerwald: >>> If you want to have stuff as it comes in, you can still switch to unstable >>> – which works quite nicely for weeks already, IMHO. >> >> I was long time afraid to use sid (although i work with debian 24x7 a >> day (servers and desktop), because it is called "unstable". But after I >> have switched and used sid a couple of weeks I am suprised about it, >> because I have less strugle with it instead of using testing. Especially >> the different versions in testing with kde were very annoying (I don't >> blame the maintainers about that). > > Please note tough that there is no guarantee whatsoever that things work > correctly in unstable. I am aware of this. > At some time I wasn´t even able to log in to the Plasma desktop, since it > crashed while doing so. But this didn´t last for more than 2 days I AFAIR. > > The major transitions that build the background of this temporary > instability, > like the G++ ABI transition and some other stuff I don´t quite recall at the > moment, are done. So I do not expect any major instability issues with > unstable at the moment. > > But again, this is no guarantee. Back then I even installed MATE desktop that > would even work if Qt would be completely broke (which it was for some time). > > On any account I suggest you are keeping another desktop around just in case, > or at least be willing to temporarily install one, in case you want to follow > unstable. Also… directly after a release it may be wise to stay with that > release for a while, before following unstable again. I have additonally installed xfce for a long time, because if kde screws up I can use xfce which is based on gtk. Furthermore I have daily incremental backups of my desktop, a second computer to test the updates and if nothing explodes, I update the main computer. I feel that I am well prepared to survive. And if a problem occurs I have no issues digging very deep. > That said, if you are willing to deal with issues, report them, help > resolving > them, find temporary workarounds, I see unstable as a quite viable > alternative. > Similar things apply to testing, however when using transitions works out as > expected, in the future it may be a bit more stable, at the price of having > to > wait longer for new stuff to trickle in. What doesn´t work tough is to > complain about that unstable is exactly that, well unstable, instead of > focussing on the solution, i.e. making it stable again, or just applying a > temporary workaround. > > I think this was one of the main points I´d like to bring up here all the > time. Let it be a conscious decision and be ready to deal with the > consequences of it and it can be quite adventurous, but lots of the time also > quite pleasant experience. And if you stay positive and constructive, you > help > to keep the quality of Debian or to make it even better. > Thanks for your tipps and advices, I really appreciate your patience in writing all these long emails about using testing/sid the right way. -- Holger
