[PATCH] Re: KDE 4.6.0: go or no go?
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. Please review/comment. Thanks, Dirk Index: runtime/nepomuk/services/strigi/nepomukstrigiservice.desktop === --- runtime/nepomuk/services/strigi/nepomukstrigiservice.desktop (Revision 1215883) +++ runtime/nepomuk/services/strigi/nepomukstrigiservice.desktop (Arbeitskopie) @@ -2,7 +2,7 @@ Type=Service X-KDE-ServiceTypes=NepomukService X-KDE-Library=nepomukstrigiservice -X-KDE-Nepomuk-autostart=true +X-KDE-Nepomuk-autostart=false X-KDE-Nepomuk-start-on-demand=false Name=Nepomuk Strigi Service Name[af]=Nepomuk Strigi diens Index: runtime/nepomuk/kcm/nepomukserverkcm.cpp === --- runtime/nepomuk/kcm/nepomukserverkcm.cpp (Revision 1215883) +++ runtime/nepomuk/kcm/nepomukserverkcm.cpp (Arbeitskopie) @@ -241,8 +241,8 @@ void Nepomuk::ServerConfigModule::load() // 1. basic setup KConfig config( nepomukserverrc ); m_checkEnableNepomuk-setChecked( config.group( Basic Settings ).readEntry( Start Nepomuk, true ) ); -m_checkEnableStrigi-setChecked( config.group( Service-nepomukstrigiservice ).readEntry( autostart, true ) ); - +m_checkEnableStrigi-setChecked( config.group( Service-nepomukstrigiservice ).readEntry( +autostart, false ) ); // 2. strigi settings KConfig strigiConfig( nepomukstrigirc ); Index: workspace/plasma/generic/runners/nepomuksearch/plasma-runner-nepomuksearch.desktop === --- workspace/plasma/generic/runners/nepomuksearch/plasma-runner-nepomuksearch.desktop (Revision 1215945) +++ workspace/plasma/generic/runners/nepomuksearch/plasma-runner-nepomuksearch.desktop (Arbeitskopie) @@ -143,4 +143,4 @@ X-KDE-PluginInfo-Email=tr...@kde.org X-KDE-PluginInfo-Name=nepomuksearch X-KDE-PluginInfo-Version=1.0 X-KDE-PluginInfo-License=LGPL -X-KDE-PluginInfo-EnabledByDefault=true +X-KDE-PluginInfo-EnabledByDefault=false ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On 01/20/2011 07:00 AM, 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? 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. With my release-team hat on, said patch is an acceptable workaround for now, though simply disabling the nepomuk krunner seemed to be enough for some. -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0: go or no go?
Tirsdag den 18. januar 2011 20:56:00 skrev Frank Reininghaus: Am Dienstag 18 Januar 2011, 20:06:52 schrieb Aaron J. Seigo: On Tuesday, January 18, 2011, Frank Reininghaus wrote: Am Dienstag 18 Januar 2011, 17:57:01 schrieb Aaron J. Seigo: There is a bug which lets some KDE apps (especially Dolphin) crash every time they are closed: https://bugs.kde.org/show_bug.cgi?id=257944 has strigi devels been contacted / drawn into this? all the Strigi web content I found looks quite outdated, but if anyone knows how to contact people who work actively on Strigi, drawing their attention to the bug report would certainly be a good idea. Jos van den Oever is still at the helm afaik and the mailing list is still active, if low volume, at strigi-de...@lists.sf.net .. thanks, I sent a mail to that list asking the Strigi devs to have a look at the report. The openSUSE problem seems to be fixed by updating to strigi 0.7.3.99. Not sure if the problem with strigi 0.7.3 was an upstream bug or a packaging issue on the openSUSE side or something else. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
This patch does in no way solve the issue. On 01/20/2011 02:00 PM, 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. Please review/comment. Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011 14:53:19 Martin Schlander wrote: Tirsdag den 18. januar 2011 20:56:00 skrev Frank Reininghaus: Am Dienstag 18 Januar 2011, 20:06:52 schrieb Aaron J. Seigo: On Tuesday, January 18, 2011, Frank Reininghaus wrote: Am Dienstag 18 Januar 2011, 17:57:01 schrieb Aaron J. Seigo: There is a bug which lets some KDE apps (especially Dolphin) crash every time they are closed: https://bugs.kde.org/show_bug.cgi?id=257944 has strigi devels been contacted / drawn into this? all the Strigi web content I found looks quite outdated, but if anyone knows how to contact people who work actively on Strigi, drawing their attention to the bug report would certainly be a good idea. Jos van den Oever is still at the helm afaik and the mailing list is still active, if low volume, at strigi-de...@lists.sf.net .. thanks, I sent a mail to that list asking the Strigi devs to have a look at the report. The openSUSE problem seems to be fixed by updating to strigi 0.7.3.99. Not sure if the problem with strigi 0.7.3 was an upstream bug or a packaging issue on the openSUSE side or something else. It appears to have been an upstream bug. I just updated the snapshot after Jos van den Oever pointed out that a) 0.7.3 was not an official release, and b) it's several months old. I have prompted him to make an 0.7.4 release, hopefully that will happen soon. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thu, Jan 20, 2011 at 08:18, Sebastian Trüg tr...@kde.org wrote: This patch does in no way solve the issue. I'm not sure what the release team is supposed to do with this statement. What do you think of 246678 and the 4.6.0 release? Ian ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
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. Alex -- Forwarded Message -- Subject: [CMake] CMake 2.8.4-rc1 ready for testing! Date: Thursday 13 January 2011 From: David Cole david.c...@kitware.com To: cm...@cmake.org I am happy to announce that CMake 2.8.4 has entered the release candidate stage! You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D Following is the list of changes in this release. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Happy building! -Dave ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
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
Re: [PATCH] Re: KDE 4.6.0: go or no go?
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: if(POLICY CMP0017) cmake_policy(SET CMP0011 NEW) endif(POLICY CMP0017) And I think the breakage is there. I was 2 weeks on vacation over the holidays, and just today I finally catched up with email. The respective patch was merged into cmake master early January. For testing whether KDE 4.6 branch builds with cmake 2.8.4rc1 I don't have time tonight, and then we are already visiting people until late Sunday. So please, as release coordinators, make sure this release builds with current cmake. If it doesn't, the patch above should fix it. I was working hard on this more or less constantly since last September, to come to a solution of the problem in cmake which is suitable for KDE. It took me many many hours, sweat, ... to get this, so please don't ship a KDE which does not build. And there's an easy way to fix it (see above). Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
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 Neundorfneund...@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
Re: [PATCH] Re: KDE 4.6.0: go or no go?
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
Re: [PATCH] Re: KDE 4.6.0: go or no go?
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 Neundorfneund...@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
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011, Ian Monroe wrote: On Thu, Jan 20, 2011 at 14:05, Alexander Neundorf neund...@kde.org wrote: On Thursday 20 January 2011, Ian Monroe wrote: ... 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. So, for what it's worth, here's my definitive and serious veto to that. Make sure it works properly with CMake 2.8.4rc1, if not, use the patch. Due to real life (and not having KDE as my payed job), I don't have time to check that myself before Sunday night, probably Monday night. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0: go or no go?
On Tuesday 18 January 2011, Dirk Mueller wrote: Looks like we have two bugs marked as ship stopper: bug 246678 and 262274, so just ignoring that is a bit of a problem for me :-) Hi, 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? Note that I need a solution asap, the tagging is scheduled for 23:59 UTC (aka in ~ 2 hours), though I will likely only be able to work on this tomorrow around noon. Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0: go or no go?
On Tuesday 18 January 2011 10:17:47 Dirk Mueller wrote: how are the pros/cons regarding declaring the current 4.6 branch as 4.6.0 or adding another RC to the game? Looks like we have two bugs marked as ship stopper: bug 246678 and 262274, so just ignoring that is a bit of a problem for me :-) I've been testing a series of patches for trueg. We found one set that fix 246678 last week, but introduces a time-consuming conversion process on first run. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0: go or no go?
Hi, Am Dienstag 18 Januar 2011, 10:17:47 schrieb Dirk Mueller: how are the pros/cons regarding declaring the current 4.6 branch as 4.6.0 or adding another RC to the game? There is a bug which lets some KDE apps (especially Dolphin) crash every time they are closed: https://bugs.kde.org/show_bug.cgi?id=257944 It's not marked as a blocker because 1. it seems that the bug is not in KDE itself, but probably in Strigi 2. only Opensuse is affected. But if Opensuse ships 4.6.0 in the current state with this issue unresolved, this might cause a lot of user pain and an endless stream of crash reports :-( Looks like we have two bugs marked as ship stopper: bug 246678 and 262274, Is the second one really a show stopper? Maybe users without bugzilla permissions should not be allowed to add keywords to reports... Cheers, Frank ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0: go or no go?
On Tuesday, January 18, 2011, Frank Reininghaus wrote: Hi, Am Dienstag 18 Januar 2011, 10:17:47 schrieb Dirk Mueller: how are the pros/cons regarding declaring the current 4.6 branch as 4.6.0 or adding another RC to the game? There is a bug which lets some KDE apps (especially Dolphin) crash every time they are closed: https://bugs.kde.org/show_bug.cgi?id=257944 It's not marked as a blocker because 1. it seems that the bug is not in KDE itself, but probably in Strigi 2. only Opensuse is affected. But if Opensuse ships 4.6.0 in the current state with this issue unresolved, this might cause a lot of user pain and an endless stream of crash reports :-( has strigi devels been contacted / drawn into this? do we have a solution for it? that one does seem like a show stopper to me unless we have some plan / resolution for it. Looks like we have two bugs marked as ship stopper: bug 246678 and 262274, Is the second one really a show stopper? Maybe users without bugzilla no, it's not a show stopper for an entire release. i've removed the keyword. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0: go or no go?
On Tuesday 18 January 2011, Frank Reininghaus wrote: Hi, Am Dienstag 18 Januar 2011, 17:57:01 schrieb Aaron J. Seigo: There is a bug which lets some KDE apps (especially Dolphin) crash every time they are closed: https://bugs.kde.org/show_bug.cgi?id=257944 has strigi devels been contacted / drawn into this? all the Strigi web content I found looks quite outdated, but if anyone knows how to contact people who work actively on Strigi, drawing their attention to the bug report would certainly be a good idea. Jos van den Oever is really busy with webodf these days, but if you mail him, he might be able to tell you who to contact. -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0: go or no go?
On Tuesday, January 18, 2011, Frank Reininghaus wrote: Hi, Am Dienstag 18 Januar 2011, 17:57:01 schrieb Aaron J. Seigo: There is a bug which lets some KDE apps (especially Dolphin) crash every time they are closed: https://bugs.kde.org/show_bug.cgi?id=257944 has strigi devels been contacted / drawn into this? all the Strigi web content I found looks quite outdated, but if anyone knows how to contact people who work actively on Strigi, drawing their attention to the bug report would certainly be a good idea. Jos van den Oever is still at the helm afaik and the mailing list is still active, if low volume, at strigi-de...@lists.sf.net .. i could add them to the bug, but it would probably be better if those who actually are involved with this issue took it up (since you / they will know much more about it than i do :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0: go or no go?
Am Dienstag 18 Januar 2011, 20:06:52 schrieb Aaron J. Seigo: On Tuesday, January 18, 2011, Frank Reininghaus wrote: Am Dienstag 18 Januar 2011, 17:57:01 schrieb Aaron J. Seigo: There is a bug which lets some KDE apps (especially Dolphin) crash every time they are closed: https://bugs.kde.org/show_bug.cgi?id=257944 has strigi devels been contacted / drawn into this? all the Strigi web content I found looks quite outdated, but if anyone knows how to contact people who work actively on Strigi, drawing their attention to the bug report would certainly be a good idea. Jos van den Oever is still at the helm afaik and the mailing list is still active, if low volume, at strigi-de...@lists.sf.net .. thanks, I sent a mail to that list asking the Strigi devs to have a look at the report. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0: go or no go?
On Tuesday 18 January 2011, Will Stephenson wrote: Looks like we have two bugs marked as ship stopper: bug 246678 and 262274, so just ignoring that is a bit of a problem for me :-) I've been testing a series of patches for trueg. We found one set that fix 246678 last week, but introduces a time-consuming conversion process on first run. Are they committed? Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
