[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
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
Re: KDE 4.6.0: go or no go?
Tirsdag den 18. januar 2011 20:56:00 skrev Frank Reininghaus: Am Dienstag 18 Januar 2011, 20:06:52 schrieb Aaron J. Seigo: On Tuesday, January 18, 2011, Frank Reininghaus wrote: Am Dienstag 18 Januar 2011, 17:57:01 schrieb Aaron J. Seigo: There is a bug which lets some KDE apps (especially Dolphin) crash every time they are closed: https://bugs.kde.org/show_bug.cgi?id=257944 has strigi devels been contacted / drawn into this? all the Strigi web content I found looks quite outdated, but if anyone knows how to contact people who work actively on Strigi, drawing their attention to the bug report would certainly be a good idea. Jos van den Oever is still at the helm afaik and the mailing list is still active, if low volume, at strigi-de...@lists.sf.net .. thanks, I sent a mail to that list asking the Strigi devs to have a look at the report. The openSUSE problem seems to be fixed by updating to strigi 0.7.3.99. Not sure if the problem with strigi 0.7.3 was an upstream bug or a packaging issue on the openSUSE side or something else. ___ 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: KDE 4.6.0: go or no go?
On Thursday 20 January 2011 14:53:19 Martin Schlander wrote: Tirsdag den 18. januar 2011 20:56:00 skrev Frank Reininghaus: Am Dienstag 18 Januar 2011, 20:06:52 schrieb Aaron J. Seigo: On Tuesday, January 18, 2011, Frank Reininghaus wrote: Am Dienstag 18 Januar 2011, 17:57:01 schrieb Aaron J. Seigo: There is a bug which lets some KDE apps (especially Dolphin) crash every time they are closed: https://bugs.kde.org/show_bug.cgi?id=257944 has strigi devels been contacted / drawn into this? all the Strigi web content I found looks quite outdated, but if anyone knows how to contact people who work actively on Strigi, drawing their attention to the bug report would certainly be a good idea. Jos van den Oever is still at the helm afaik and the mailing list is still active, if low volume, at strigi-de...@lists.sf.net .. thanks, I sent a mail to that list asking the Strigi devs to have a look at the report. The openSUSE problem seems to be fixed by updating to strigi 0.7.3.99. Not sure if the problem with strigi 0.7.3 was an upstream bug or a packaging issue on the openSUSE side or something else. It appears to have been an upstream bug. I just updated the snapshot after Jos van den Oever pointed out that a) 0.7.3 was not an official release, and b) it's several months old. I have prompted him to make an 0.7.4 release, hopefully that will happen soon. Will ___ 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 tr...@kde.org 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?
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 david.c...@kitware.com 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 12:20, Alexander Neundorf neund...@kde.org 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, Ian Monroe wrote: On Thu, Jan 20, 2011 at 12:20, Alexander Neundorf neund...@kde.org 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 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 Neundorfneund...@kde.org 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 Thu, Jan 20, 2011 at 14:05, Alexander Neundorf neund...@kde.org wrote: On Thursday 20 January 2011, Ian Monroe wrote: On Thu, Jan 20, 2011 at 12:20, Alexander Neundorf neund...@kde.org 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, 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 Neundorfneund...@kde.org 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 Thursday 20 January 2011, Ian Monroe wrote: On Thu, Jan 20, 2011 at 14:05, Alexander Neundorf neund...@kde.org 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: Re: KDE 4.6.0 and cmake-2.8.4-rc1
On 01/20/2011 02:20 PM, Alexander Neundorf wrote: On Thursday 20 January 2011, Rex Dieter wrote: 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 ? Yes there were lots of warnings. :( For gory details, http://kojipkgs.fedoraproject.org/packages/kdebase-runtime/4.5.95/3.fc15/data/logs/i686/build.log kdelibs would be good. I'll try that next. Make sure all packages which are found with 2.8.3 are also found with 2.8.4rc1. I believe everything was found in the kdebase-runtime build, but I'll do some double-checking. -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0 and cmake-2.8.4-rc1
On Thursday 20 January 2011, Rex Dieter wrote: On 01/20/2011 02:20 PM, Alexander Neundorf wrote: On Thursday 20 January 2011, Rex Dieter wrote: 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 ? Yes there were lots of warnings. :( For gory details, http://kojipkgs.fedoraproject.org/packages/kdebase-runtime/4.5.95/3.fc15/da ta/logs/i686/build.log CMake Warning (dev) at /usr/share/cmake/Modules/FindThreads.cmake:156 (INCLUDE): File /usr/share/cmake/Modules/FindThreads.cmake includes /usr/share/kde4/apps/cmake/modules/FindPackageHandleStandardArgs.cmake (found via CMAKE_MODULE_PATH) which shadows /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake. This may cause errors later on . Policy CMP0017 is not set: Prefer files from the CMake module directory when including from there. Run cmake --help-policy CMP0017 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Yes, that's it exactly. FindThreads.cmake from CMake includes FindPackageHandleStandardArgs.cmake (short FPHSA.cmake) from kdelibs, while it expects to include FPHSA.cmake from cmake. This can cause breakage if the using module (FindThreads.cmake) uses new features of FPHSA.cmake, which are not yet there in the KDE-version of FPHSA.cmake. This problem is fixed by setting CMP0017 to NEW. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0 and cmake-2.8.4-rc1
On Thursday 20 January 2011, Rex Dieter wrote: On 01/20/2011 02:20 PM, Alexander Neundorf wrote: On Thursday 20 January 2011, Rex Dieter wrote: 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 ? Yes there were lots of warnings. :( The warnings are good. They show a problem which existed before, but we were not aware of it. In CMake you can add new stuff to modules in a fully backward compatible way. This new feature, e.g. in Foo.cmake, may be used by other modules shipped with cmake. If some project, e.g. KDE, happens to ship a slightly modified version of Foo.cmake, which does not yet have that new feature, can shadow the cmake version of Foo.cmake via CMAKE_MODULE_PATH, so a module from cmake, which include()s Foo.cmake, gets the old version from KDE, and not the new version from CMake (which has the feature), and so stuff breaks. The warning about CMP0017 appears in such cases. The new behaviour in this regard is that a project can not anymore shadow files from CMake via CMAKE_MODULE_PATH for modules shipped with CMake. You can think of this like an RPATH built into the modules shipped with CMake, and CMAKE_MODULE_PATH being only LD_LIBRARY_PATH. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE 4.6.0 tarballs (try#1) uploaded
Hi, I just finished uploading the first set of KDE 4.6.0 tarballs. It includes a hotfix for the last showstopper bug, so we can continue. Thanks to Sebastian and Will for debugging and working on the issue. Release announcement might slip a bit given that we're quite late in the game, though I prefer not to. Let me know if thats a problem for you in any case. Building is not finished yet for me, so let me know if you find any showstopper issues. Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
