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 <[email protected]> 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 [email protected] https://mail.kde.org/mailman/listinfo/release-team
