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 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?).
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