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