Searching for whatever filename in Dolphin regularly aborts at some point, ending with the display of : "The process for the filenamesearch protocol died unexpectedly" in the search area. Just many bugs have been opened on the kde bug tracking system about that issue, most of them implying kdeinit, files access rights... bugs that where actually solved with 5.83 and 5.85 releases. Waste of time to mention them. However the trouble remains and is reported by some Gentooer here : https://bugs.kde.org/show_bug.cgi?id=437153#c10 trouble acknowledeged by Ahmad Samir as part of his #12 comment as being a different issue. Ahmad actually fixed this bug with the following commit : https://invent.kde.org/network/kio-extras/-/commit/5dff395ecea2977cf149c293c16c4d4a5151493b#e87cbe0c042d254e839c0aa3372e139e925a9ba7 commit, which made its way neither to current gentoo stable 21.04.3-r2 nor to ~21.08.2 Applying this commit to my kio-extras-21.04.3-r2 solves the problem for me. (Did not try with ~21.08.2) Reproducible: Always
Created attachment 743922 [details, diff] Patch fixing Dolphin"s search crashes Raw copy of upstream patch fixing crash due to KCoreDirLister changes
Created attachment 743925 [details] kio-extras-21.04.3 ebuild applying above mentioned patch
Had forgotten to : A/ Mention in the conditions for the bug to occur : Baloo disabled. B/ Draw particular attention on final part of upstream's commit's comments and consequently on KDE_FORK_SLAVES defaults settings.
When you attach bugs, please ideally use git format-patch style. You can get that from invent.kde.org interface by using ".patch" suffix.
(In reply to Andreas Sturmlechner from comment #4) > When you attach bugs, please ideally use git format-patch style. You can get > that from invent.kde.org interface by using ".patch" suffix. *attach patches
Can you confirm this is happening while you are running an unmodified version of >=KDE Frameworks-5.85 (oldest version available in Gentoo since 2021-09-14) with its default KDE_FORK_SLAVES=ON? Because upstream assures me either condition would make this a non issue.
(In reply to Andreas Sturmlechner from comment #6) > Can you confirm this is happening while you are running an unmodified > version of >=KDE Frameworks-5.85 To be honest, I won't claim running a strictly speaking unmodified version of gentoo's KF85 as a whole. (Since I found necessary to revisit that charming new dependency on libglvnd (cf BUG #813717 ) This being acknowledged, I fail to understand how my fiddling would impact here as far as they only concern kde-frameworks/kwayland and kde-frameworks/plasma. v.g : Not a single kde-frameworks/* package explicitly mentioned among kio-extras-21.* package's dependencies, all of these being emerged unmodified. > …with its default KDE_FORK_SLAVES=ON? KDE_FORK_SLAVES=ON ??? I fail to understand something in there : AFAIU the condition on KDE_FORK_SLAVES is set on the fact that this variable belongs to the user environment or not (and irrespective of its actual value): bool fork = qEnvironmentVariableIsSet("KDE_FORK_SLAVES"); AFAIU again, default (in non particular debugging conditions) is to **not** set KDE_FORK_SLAVES in the environment and I can confirm that I never set it personally to whatever value : $ env|grep KDE KDE_SESSION_UID=1000 KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true KDE_APPLICATIONS_AS_SCOPE=1 And that is precisely what the above patch addresses : "Note that this crash only happens if KDE_FORK_SLAVES is _not_ set." > either condition would make this a non issue. Then this would mean that some upstream's kde-frameworks/ ? -5.85 package explicitly defaults to setting that variable in the user's environment (I'm doubtful) or that upstream's devs have that variable explicitly set for debug purposes (a couple of testing-dedicated programs actually set this variable) See for instance qputenv("KDE_FORK_SLAVES", "yes"); in KIOThreadTest::initTestCase() and several others of the like. For the record, I recall what I wrote in the OP : "Just many bugs have been opened on the kde bug tracking system about that issue, most of them implying kdeinit, files access rights... bugs that where actually solved with 5.83 and 5.85 releases." So, could also be possible that upstream believes that these fixes are enough but, this is actually not enough as exposed by myself and a couple of other gentoo users for who (kde-frameworks-5.85 && KDE_FORK_SLAVES not belonging to the environment) Ahmad Samir's patch is a necessity to solve this issue completely.
All this TL;DR story being hereabove written and, as suggested as part of my comment #3, forcing KDE_FORK_SLAVES=WhateverIDontCare in the user's environment can be understood as being a functionally possible and simpler alternative to patching Ahmad's commit. I did not test though :-P
KIO_FORK_SLAVES is *also* a cmake variable that has been switched to *ON* with KDE Frameworks 5.85: https://invent.kde.org/frameworks/kio/-/commit/bed4ddf24244e3fb250f8b350902f37713c8c6e7 A very simple answer to my question could have been "yes, I have reproduced that bug with >=5.85 and I did not mess with that variable."
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=19a0f717d4322e58473f4e8aea88521fd158abf6 commit 19a0f717d4322e58473f4e8aea88521fd158abf6 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-10-16 21:58:32 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-10-20 13:25:57 +0000 kde-apps/kio-extras: Fix kio_filenamesearch crash Reported-by: Eric F. Garioud <eric-f.garioud@wanadoo.fr> Bug: https://bugs.gentoo.org/817008 Package-Manager: Portage-3.0.28, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> ...o-extras-21.04.3-kio_filenamesearch-crash.patch | 36 ++++++++ kde-apps/kio-extras/kio-extras-21.04.3-r3.ebuild | 1 + kde-apps/kio-extras/kio-extras-21.08.2-r1.ebuild | 97 ++++++++++++++++++++++ 3 files changed, 134 insertions(+)
(In reply to Andreas Sturmlechner from comment #9) > A very simple answer to my question could have been "yes, I have reproduced > that bug with >=5.85 and I did not mess with that variable." Oh! Yes indeed! So sorry! Of course, things could have been made even more simple, had you resolved fixed directly from comment #3 ! Ha! I realize that you just brought my bug into the traditionally no-talking zone, I apologize & ->-[
Gentoo is not in the business of piling up patches by acclamation no-questions-asked. Maintainers *are* going to discuss with upstream, which in this case has led to the commit be included in 21.08.3 as well. Occasionally you will be asked to clarify, no matter how clear the case seems to be to you. You will find it increasingly hard to garner attention in the future if you don't work on your communication skills.
(In reply to Andreas Sturmlechner from comment #12) > You will find it increasingly hard to garner attention in the future if you > don't work on your communication skills. Working on my communication skills ? Errr ? Oh! Yes! I see! I stand corrected & make no doubt you'll praise my efforts in improving them : Natürlich hätte man es noch einfacher machen können, hättest du gleich nach Kommentar #3 behoben! BTW no talking there, so, in the highly improbable case you would have additional desiderata regarding my communication skills, please feel free to fill a bug as part of ComRel.
(In reply to Eric F. GARIOUD from comment #13) > (In reply to Andreas Sturmlechner from comment #12) > > You will find it increasingly hard to garner attention in the future if you > > don't work on your communication skills. > > Working on my communication skills ? Errr ? Consider it the more favorable view as it implies there is still room for improvement. (In reply to Eric F. GARIOUD from comment #13) > please feel free to fill a bug as part of ComRel. If you continue to insist on it in the future, as you seem to have done with other maintainers in the past, your wish might just be fulfilled eventually.
amd64 done
x86 done
arm64 done all arches done
