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<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:
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