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