Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011, Ian Monroe wrote: > On Thu, Jan 20, 2011 at 14:05, Alexander Neundorf wrote: > > On Thursday 20 January 2011, Ian Monroe wrote: ... > >> Delaying 4.6.0 at this point due to a cmake that barely any distros > >> are using seems quite foolish to me (assuming it is an issue). > > > > No, this is not foolish. > > All distros will use cmake >= 2.8.4 in the future. > > There aren't too many distros in the future that will be building > 4.6.0. They will be building 4.6.1 and 4.6.2. That was my point. > > If a distro with an aggressive cmake-upgrade policy does hit the > problem they can patch it at that point. 4.6.0 is going to be tagged > tonight hopefully. So, for what it's worth, here's my definitive and serious veto to that. Make sure it works properly with CMake 2.8.4rc1, if not, use the patch. Due to real life (and not having KDE as my payed job), I don't have time to check that myself before Sunday night, probably Monday night. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011, Rex Dieter wrote: > On 01/20/2011 02:05 PM, Alexander Neundorf wrote: > > On Thursday 20 January 2011, Ian Monroe wrote: > >> On Thu, Jan 20, 2011 at 12:20, Alexander Neundorf wrote: > >>> On Thursday 20 January 2011, Dirk Mueller wrote: > On Wednesday 19 January 2011, Dirk Mueller wrote: > > so the general consensus seems to be against slipping the schedule > > and inserting a RC3. > > > > This means that we need to solve bug 246678. Given that there seems > > to be no fix in sight (no comment in the last 14 days), can we > > mitigate it. is there a way to disable whatever causes the problem by > > default? what would be the patch for that? > > Hi, > > I think the attached patch should make the services be disabled by > default, thereby avoiding kde bug 246678. I'm asking for a review and > a comment whether we can go ahead with this workaround for KDE 4.6.0. > > As the general consensus was (previously) already against slipping the > schedule, I need a solution NOW to be able to release 4.6.0 in time. > >>> > >>> Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ? > >>> > >>> If not, please do so. > >>> > >>> There has been a relatively significant change in it wrt to how > >>> include() and find_package() find their files (now when a file which is > >>> part of cmake calls include() or find_package() it first looks in > >>> CMAKE_ROOT/share/cmake/Modules/ instead of first looking in > >>> CMAKE_MODULE_PATH). > >>> > >>> I didn't have a lot of time since mid of December, so I didn't get > >>> around to give it a try. Also today I won't have the time and then > >>> there's already weekend, and I won't return before late Sunday. > >>> If it breaks (should error out somewhere related to > >>> FindPackageHandleStandardArgs), please let me know. > >>> Setting cmake policy CMP0017 to NEW should fix this breakage if it > >>> occurs. This would have to be done at the top of FindKDE4Internal.cmake > >>> where the other policies are set too, inside a if(POLICY CMP0017) > >>> guard. > >>> > >>> IMO if this breakge occurs, this is something which we *must* fix > >>> before the 4.6.0 release. I spent basically months of arguing and > >>> testing about this issue with the cmake devs to get this new behaviour > >>> (without the new behaviour KDE 4.5.0/4.5.1 would have broken cmake > >>> 2.8.3, or the other way round, depending on how you see it) into cmake. > >> > >> Delaying 4.6.0 at this point due to a cmake that barely any distros > >> are using seems quite foolish to me (assuming it is an issue). > > > > No, this is not foolish. > > All distros will use cmake>= 2.8.4 in the future. > > It would mean that KDE 4.6.0 will forever be unbuildable with any cmake>= > > 2.8.4. > > > > This is the code which would have to go into FindKDE4Internal.cmake in > > case of breakage: > > Looks ok to me, just built kdebase-runtime-4.5.95 with cmake-2.8.4-rc1 > yesterday (is that a good enough test?). Hmm, not necessarily. Were there warnings about files being shadowed, mentioning CMP0017 issued by cmake ? kdelibs would be good. Make sure all packages which are found with 2.8.3 are also found with 2.8.4rc1. There should be a FindPackageLog.txt file be created in the build directory which lists the found and not found packages. If not, try again with the patch. Thanks Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thu, Jan 20, 2011 at 14:05, Alexander Neundorf wrote: > On Thursday 20 January 2011, Ian Monroe wrote: >> On Thu, Jan 20, 2011 at 12:20, Alexander Neundorf wrote: >> > On Thursday 20 January 2011, Dirk Mueller wrote: >> >> On Wednesday 19 January 2011, Dirk Mueller wrote: >> >> > so the general consensus seems to be against slipping the schedule and >> >> > inserting a RC3. >> >> > >> >> > This means that we need to solve bug 246678. Given that there seems to >> >> > be no fix in sight (no comment in the last 14 days), can we mitigate >> >> > it. is there a way to disable whatever causes the problem by default? >> >> > what would be the patch for that? >> >> >> >> Hi, >> >> >> >> I think the attached patch should make the services be disabled by >> >> default, thereby avoiding kde bug 246678. I'm asking for a review and a >> >> comment whether we can go ahead with this workaround for KDE 4.6.0. >> >> >> >> As the general consensus was (previously) already against slipping the >> >> schedule, I need a solution NOW to be able to release 4.6.0 in time. >> > >> > Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ? >> > >> > If not, please do so. >> > >> > There has been a relatively significant change in it wrt to how include() >> > and find_package() find their files (now when a file which is part of >> > cmake calls include() or find_package() it first looks in >> > CMAKE_ROOT/share/cmake/Modules/ instead of first looking in >> > CMAKE_MODULE_PATH). >> > >> > I didn't have a lot of time since mid of December, so I didn't get around >> > to give it a try. Also today I won't have the time and then there's >> > already weekend, and I won't return before late Sunday. >> > If it breaks (should error out somewhere related to >> > FindPackageHandleStandardArgs), please let me know. >> > Setting cmake policy CMP0017 to NEW should fix this breakage if it >> > occurs. This would have to be done at the top of FindKDE4Internal.cmake >> > where the other policies are set too, inside a if(POLICY CMP0017) guard. >> > >> > IMO if this breakge occurs, this is something which we *must* fix before >> > the 4.6.0 release. I spent basically months of arguing and testing about >> > this issue with the cmake devs to get this new behaviour (without the new >> > behaviour KDE 4.5.0/4.5.1 would have broken cmake 2.8.3, or the other way >> > round, depending on how you see it) into cmake. >> >> Delaying 4.6.0 at this point due to a cmake that barely any distros >> are using seems quite foolish to me (assuming it is an issue). > > No, this is not foolish. > All distros will use cmake >= 2.8.4 in the future. There aren't too many distros in the future that will be building 4.6.0. They will be building 4.6.1 and 4.6.2. That was my point. If a distro with an aggressive cmake-upgrade policy does hit the problem they can patch it at that point. 4.6.0 is going to be tagged tonight hopefully. Ian ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011, Alexander Neundorf wrote: > On Thursday 20 January 2011, Ian Monroe wrote: > > On Thu, Jan 20, 2011 at 12:20, Alexander Neundorf wrote: > > > On Thursday 20 January 2011, Dirk Mueller wrote: > > >> On Wednesday 19 January 2011, Dirk Mueller wrote: > > >> > so the general consensus seems to be against slipping the schedule > > >> > and inserting a RC3. > > >> > > > >> > This means that we need to solve bug 246678. Given that there seems > > >> > to be no fix in sight (no comment in the last 14 days), can we > > >> > mitigate it. is there a way to disable whatever causes the problem > > >> > by default? what would be the patch for that? > > >> > > >> Hi, > > >> > > >> I think the attached patch should make the services be disabled by > > >> default, thereby avoiding kde bug 246678. I'm asking for a review and > > >> a comment whether we can go ahead with this workaround for KDE 4.6.0. > > >> > > >> As the general consensus was (previously) already against slipping the > > >> schedule, I need a solution NOW to be able to release 4.6.0 in time. > > > > > > Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ? > > > > > > If not, please do so. > > > > > > There has been a relatively significant change in it wrt to how > > > include() and find_package() find their files (now when a file which is > > > part of cmake calls include() or find_package() it first looks in > > > CMAKE_ROOT/share/cmake/Modules/ instead of first looking in > > > CMAKE_MODULE_PATH). > > > > > > I didn't have a lot of time since mid of December, so I didn't get > > > around to give it a try. Also today I won't have the time and then > > > there's already weekend, and I won't return before late Sunday. > > > If it breaks (should error out somewhere related to > > > FindPackageHandleStandardArgs), please let me know. > > > Setting cmake policy CMP0017 to NEW should fix this breakage if it > > > occurs. This would have to be done at the top of FindKDE4Internal.cmake > > > where the other policies are set too, inside a if(POLICY CMP0017) > > > guard. > > > > > > IMO if this breakge occurs, this is something which we *must* fix > > > before the 4.6.0 release. I spent basically months of arguing and > > > testing about this issue with the cmake devs to get this new behaviour > > > (without the new behaviour KDE 4.5.0/4.5.1 would have broken cmake > > > 2.8.3, or the other way round, depending on how you see it) into cmake. > > > > Delaying 4.6.0 at this point due to a cmake that barely any distros > > are using seems quite foolish to me (assuming it is an issue). > > No, this is not foolish. > All distros will use cmake >= 2.8.4 in the future. > It would mean that KDE 4.6.0 will forever be unbuildable with any cmake >= > 2.8.4. > > This is the code which would have to go into FindKDE4Internal.cmake in case > of breakage: > > if(POLICY CMP0017) >cmake_policy(SET CMP0011 NEW) > endif(POLICY CMP0017) Typo !!! Corrected version: if(POLICY CMP0017) cmake_policy(SET CMP0017 NEW) endif(POLICY CMP0017) Just a note: this patch has zero effects and zero risk of breakage with cmake versions which don't have CMP0017, i.e. all cmake < 2.8.4. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On 01/20/2011 02:05 PM, Alexander Neundorf wrote: > On Thursday 20 January 2011, Ian Monroe wrote: >> On Thu, Jan 20, 2011 at 12:20, Alexander Neundorf wrote: >>> On Thursday 20 January 2011, Dirk Mueller wrote: On Wednesday 19 January 2011, Dirk Mueller wrote: > so the general consensus seems to be against slipping the schedule and > inserting a RC3. > > This means that we need to solve bug 246678. Given that there seems to > be no fix in sight (no comment in the last 14 days), can we mitigate > it. is there a way to disable whatever causes the problem by default? > what would be the patch for that? Hi, I think the attached patch should make the services be disabled by default, thereby avoiding kde bug 246678. I'm asking for a review and a comment whether we can go ahead with this workaround for KDE 4.6.0. As the general consensus was (previously) already against slipping the schedule, I need a solution NOW to be able to release 4.6.0 in time. >>> >>> Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ? >>> >>> If not, please do so. >>> >>> There has been a relatively significant change in it wrt to how include() >>> and find_package() find their files (now when a file which is part of >>> cmake calls include() or find_package() it first looks in >>> CMAKE_ROOT/share/cmake/Modules/ instead of first looking in >>> CMAKE_MODULE_PATH). >>> >>> I didn't have a lot of time since mid of December, so I didn't get around >>> to give it a try. Also today I won't have the time and then there's >>> already weekend, and I won't return before late Sunday. >>> If it breaks (should error out somewhere related to >>> FindPackageHandleStandardArgs), please let me know. >>> Setting cmake policy CMP0017 to NEW should fix this breakage if it >>> occurs. This would have to be done at the top of FindKDE4Internal.cmake >>> where the other policies are set too, inside a if(POLICY CMP0017) guard. >>> >>> IMO if this breakge occurs, this is something which we *must* fix before >>> the 4.6.0 release. I spent basically months of arguing and testing about >>> this issue with the cmake devs to get this new behaviour (without the new >>> behaviour KDE 4.5.0/4.5.1 would have broken cmake 2.8.3, or the other way >>> round, depending on how you see it) into cmake. >> >> Delaying 4.6.0 at this point due to a cmake that barely any distros >> are using seems quite foolish to me (assuming it is an issue). > > No, this is not foolish. > All distros will use cmake>= 2.8.4 in the future. > It would mean that KDE 4.6.0 will forever be unbuildable with any cmake>= > 2.8.4. > > This is the code which would have to go into FindKDE4Internal.cmake in case of > breakage: Looks ok to me, just built kdebase-runtime-4.5.95 with cmake-2.8.4-rc1 yesterday (is that a good enough test?). -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011, Ian Monroe wrote: > On Thu, Jan 20, 2011 at 12:20, Alexander Neundorf wrote: > > On Thursday 20 January 2011, Dirk Mueller wrote: > >> On Wednesday 19 January 2011, Dirk Mueller wrote: > >> > so the general consensus seems to be against slipping the schedule and > >> > inserting a RC3. > >> > > >> > This means that we need to solve bug 246678. Given that there seems to > >> > be no fix in sight (no comment in the last 14 days), can we mitigate > >> > it. is there a way to disable whatever causes the problem by default? > >> > what would be the patch for that? > >> > >> Hi, > >> > >> I think the attached patch should make the services be disabled by > >> default, thereby avoiding kde bug 246678. I'm asking for a review and a > >> comment whether we can go ahead with this workaround for KDE 4.6.0. > >> > >> As the general consensus was (previously) already against slipping the > >> schedule, I need a solution NOW to be able to release 4.6.0 in time. > > > > Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ? > > > > If not, please do so. > > > > There has been a relatively significant change in it wrt to how include() > > and find_package() find their files (now when a file which is part of > > cmake calls include() or find_package() it first looks in > > CMAKE_ROOT/share/cmake/Modules/ instead of first looking in > > CMAKE_MODULE_PATH). > > > > I didn't have a lot of time since mid of December, so I didn't get around > > to give it a try. Also today I won't have the time and then there's > > already weekend, and I won't return before late Sunday. > > If it breaks (should error out somewhere related to > > FindPackageHandleStandardArgs), please let me know. > > Setting cmake policy CMP0017 to NEW should fix this breakage if it > > occurs. This would have to be done at the top of FindKDE4Internal.cmake > > where the other policies are set too, inside a if(POLICY CMP0017) guard. > > > > IMO if this breakge occurs, this is something which we *must* fix before > > the 4.6.0 release. I spent basically months of arguing and testing about > > this issue with the cmake devs to get this new behaviour (without the new > > behaviour KDE 4.5.0/4.5.1 would have broken cmake 2.8.3, or the other way > > round, depending on how you see it) into cmake. > > Delaying 4.6.0 at this point due to a cmake that barely any distros > are using seems quite foolish to me (assuming it is an issue). No, this is not foolish. All distros will use cmake >= 2.8.4 in the future. It would mean that KDE 4.6.0 will forever be unbuildable with any cmake >= 2.8.4. This is the code which would have to go into FindKDE4Internal.cmake in case of breakage: if(POLICY CMP0017) cmake_policy(SET CMP0011 NEW) endif(POLICY CMP0017) And I think the breakage is there. I was 2 weeks on vacation over the holidays, and just today I finally catched up with email. The respective patch was merged into cmake master early January. For testing whether KDE 4.6 branch builds with cmake 2.8.4rc1 I don't have time tonight, and then we are already visiting people until late Sunday. So please, as release coordinators, make sure this release builds with current cmake. If it doesn't, the patch above should fix it. I was working hard on this more or less constantly since last September, to come to a solution of the problem in cmake which is suitable for KDE. It took me many many hours, sweat, ... to get this, so please don't ship a KDE which does not build. And there's an easy way to fix it (see above). Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thu, Jan 20, 2011 at 12:20, Alexander Neundorf wrote: > On Thursday 20 January 2011, Dirk Mueller wrote: >> On Wednesday 19 January 2011, Dirk Mueller wrote: >> > so the general consensus seems to be against slipping the schedule and >> > inserting a RC3. >> > >> > This means that we need to solve bug 246678. Given that there seems to be >> > no fix in sight (no comment in the last 14 days), can we mitigate it. is >> > there a way to disable whatever causes the problem by default? what would >> > be the patch for that? >> >> Hi, >> >> I think the attached patch should make the services be disabled by default, >> thereby avoiding kde bug 246678. I'm asking for a review and a comment >> whether we can go ahead with this workaround for KDE 4.6.0. >> >> As the general consensus was (previously) already against slipping the >> schedule, I need a solution NOW to be able to release 4.6.0 in time. > > Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ? > > If not, please do so. > > There has been a relatively significant change in it wrt to how include() and > find_package() find their files (now when a file which is part of cmake calls > include() or find_package() it first looks in CMAKE_ROOT/share/cmake/Modules/ > instead of first looking in CMAKE_MODULE_PATH). > > I didn't have a lot of time since mid of December, so I didn't get around to > give it a try. Also today I won't have the time and then there's already > weekend, and I won't return before late Sunday. > If it breaks (should error out somewhere related to > FindPackageHandleStandardArgs), please let me know. > Setting cmake policy CMP0017 to NEW should fix this breakage if it occurs. > This would have to be done at the top of FindKDE4Internal.cmake where the > other policies are set too, inside a if(POLICY CMP0017) guard. > > IMO if this breakge occurs, this is something which we *must* fix before the > 4.6.0 release. I spent basically months of arguing and testing about this > issue with the cmake devs to get this new behaviour (without the new > behaviour KDE 4.5.0/4.5.1 would have broken cmake 2.8.3, or the other way > round, depending on how you see it) into cmake. Delaying 4.6.0 at this point due to a cmake that barely any distros are using seems quite foolish to me (assuming it is an issue). Seems like a reasonable goal for 4.6.1 though. Remember there's not much time between these releases. 4.6.0 might end up on users computers for a longtime (so its important to work out runtime issues), but the window when distros are going to be building 4.6.0 is relatively small. Ian ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011, Dirk Mueller wrote: > On Wednesday 19 January 2011, Dirk Mueller wrote: > > so the general consensus seems to be against slipping the schedule and > > inserting a RC3. > > > > This means that we need to solve bug 246678. Given that there seems to be > > no fix in sight (no comment in the last 14 days), can we mitigate it. is > > there a way to disable whatever causes the problem by default? what would > > be the patch for that? > > Hi, > > I think the attached patch should make the services be disabled by default, > thereby avoiding kde bug 246678. I'm asking for a review and a comment > whether we can go ahead with this workaround for KDE 4.6.0. > > As the general consensus was (previously) already against slipping the > schedule, I need a solution NOW to be able to release 4.6.0 in time. Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ? If not, please do so. There has been a relatively significant change in it wrt to how include() and find_package() find their files (now when a file which is part of cmake calls include() or find_package() it first looks in CMAKE_ROOT/share/cmake/Modules/ instead of first looking in CMAKE_MODULE_PATH). I didn't have a lot of time since mid of December, so I didn't get around to give it a try. Also today I won't have the time and then there's already weekend, and I won't return before late Sunday. If it breaks (should error out somewhere related to FindPackageHandleStandardArgs), please let me know. Setting cmake policy CMP0017 to NEW should fix this breakage if it occurs. This would have to be done at the top of FindKDE4Internal.cmake where the other policies are set too, inside a if(POLICY CMP0017) guard. IMO if this breakge occurs, this is something which we *must* fix before the 4.6.0 release. I spent basically months of arguing and testing about this issue with the cmake devs to get this new behaviour (without the new behaviour KDE 4.5.0/4.5.1 would have broken cmake 2.8.3, or the other way round, depending on how you see it) into cmake. Alex -- Forwarded Message -- Subject: [CMake] CMake 2.8.4-rc1 ready for testing! Date: Thursday 13 January 2011 From: David Cole To: cm...@cmake.org I am happy to announce that CMake 2.8.4 has entered the release candidate stage! You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D Following is the list of changes in this release. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Happy building! -Dave ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thu, Jan 20, 2011 at 08:18, Sebastian Trüg wrote: > This patch does in no way solve the issue. I'm not sure what the release team is supposed to do with this statement. What do you think of 246678 and the 4.6.0 release? Ian ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
This patch does in no way solve the issue. On 01/20/2011 02:00 PM, Dirk Mueller wrote: > On Wednesday 19 January 2011, Dirk Mueller wrote: > >> so the general consensus seems to be against slipping the schedule and >> inserting a RC3. >> >> This means that we need to solve bug 246678. Given that there seems to be >> no fix in sight (no comment in the last 14 days), can we mitigate it. is >> there a way to disable whatever causes the problem by default? what would >> be the patch for that? > > Hi, > > I think the attached patch should make the services be disabled by default, > thereby avoiding kde bug 246678. I'm asking for a review and a comment > whether > we can go ahead with this workaround for KDE 4.6.0. > > As the general consensus was (previously) already against slipping the > schedule, I need a solution NOW to be able to release 4.6.0 in time. > > Please review/comment. > > Thanks, > Dirk > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On 01/20/2011 07:00 AM, Dirk Mueller wrote: > On Wednesday 19 January 2011, Dirk Mueller wrote: > >> so the general consensus seems to be against slipping the schedule and >> inserting a RC3. >> >> This means that we need to solve bug 246678. Given that there seems to be >> no fix in sight (no comment in the last 14 days), can we mitigate it. is >> there a way to disable whatever causes the problem by default? what would >> be the patch for that? > I think the attached patch should make the services be disabled by default, > thereby avoiding kde bug 246678. I'm asking for a review and a comment whether > we can go ahead with this workaround for KDE 4.6.0. > > As the general consensus was (previously) already against slipping the > schedule, I need a solution NOW to be able to release 4.6.0 in time. With my release-team hat on, said patch is an acceptable workaround for now, though simply disabling the nepomuk krunner seemed to be enough for some. -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
[PATCH] Re: KDE 4.6.0: go or no go?
On Wednesday 19 January 2011, Dirk Mueller wrote: > so the general consensus seems to be against slipping the schedule and > inserting a RC3. > > This means that we need to solve bug 246678. Given that there seems to be > no fix in sight (no comment in the last 14 days), can we mitigate it. is > there a way to disable whatever causes the problem by default? what would > be the patch for that? Hi, I think the attached patch should make the services be disabled by default, thereby avoiding kde bug 246678. I'm asking for a review and a comment whether we can go ahead with this workaround for KDE 4.6.0. As the general consensus was (previously) already against slipping the schedule, I need a solution NOW to be able to release 4.6.0 in time. Please review/comment. Thanks, Dirk Index: runtime/nepomuk/services/strigi/nepomukstrigiservice.desktop === --- runtime/nepomuk/services/strigi/nepomukstrigiservice.desktop (Revision 1215883) +++ runtime/nepomuk/services/strigi/nepomukstrigiservice.desktop (Arbeitskopie) @@ -2,7 +2,7 @@ Type=Service X-KDE-ServiceTypes=NepomukService X-KDE-Library=nepomukstrigiservice -X-KDE-Nepomuk-autostart=true +X-KDE-Nepomuk-autostart=false X-KDE-Nepomuk-start-on-demand=false Name=Nepomuk Strigi Service Name[af]=Nepomuk Strigi diens Index: runtime/nepomuk/kcm/nepomukserverkcm.cpp === --- runtime/nepomuk/kcm/nepomukserverkcm.cpp (Revision 1215883) +++ runtime/nepomuk/kcm/nepomukserverkcm.cpp (Arbeitskopie) @@ -241,8 +241,8 @@ void Nepomuk::ServerConfigModule::load() // 1. basic setup KConfig config( "nepomukserverrc" ); m_checkEnableNepomuk->setChecked( config.group( "Basic Settings" ).readEntry( "Start Nepomuk", true ) ); -m_checkEnableStrigi->setChecked( config.group( "Service-nepomukstrigiservice" ).readEntry( "autostart", true ) ); - +m_checkEnableStrigi->setChecked( config.group( "Service-nepomukstrigiservice" ).readEntry( +"autostart", false ) ); // 2. strigi settings KConfig strigiConfig( "nepomukstrigirc" ); Index: workspace/plasma/generic/runners/nepomuksearch/plasma-runner-nepomuksearch.desktop === --- workspace/plasma/generic/runners/nepomuksearch/plasma-runner-nepomuksearch.desktop (Revision 1215945) +++ workspace/plasma/generic/runners/nepomuksearch/plasma-runner-nepomuksearch.desktop (Arbeitskopie) @@ -143,4 +143,4 @@ X-KDE-PluginInfo-Email=tr...@kde.org X-KDE-PluginInfo-Name=nepomuksearch X-KDE-PluginInfo-Version=1.0 X-KDE-PluginInfo-License=LGPL -X-KDE-PluginInfo-EnabledByDefault=true +X-KDE-PluginInfo-EnabledByDefault=false ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
