Re: Moving akonadi from kdesupport and akonadi-search from playground
Le Monday 20 July 2015, 22:58:39 Luigi Toscano a écrit : > Daniel Vrátil ha scritto: > > Hi all, > > > > we (the KDE PIM team) kinda screwed up when we forgot to communicate our > > intentions about > > next KDE PIM release with the release team and we ended up in a situation > > that we have > > some repositories in modules from which they cannot be released as part of > > KDE Applications, > > so releasing KF5-based KDE PIM as part of KDE Applications is currently > > endangered. > > I have a related question about this (sorry for hijacking the thread), but > as I'm moving translations around... > - do you mean do you want to move those to modules to kdepim? We don't want to merge it in kdepim We want to move in "KDE/" . > - do we need all kdepim, kdepim-runtime, kdepimlibs AND kde/pim? For what ? > > Ciao -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
[kdelibs/KDE/4.14] Re: cmake/modules: Remove policy settings from FindKDE4Internal.
On Montag, 20. Juli 2015 23:07:00 CEST, Allen Winter wrote: For years I have passed -DKDE4_ENABLE_HTMLHANDBOOK=1 to cmake when building KDE projects. As of today I get this error: CMake Error at cmake/modules/KDE4Macros.cmake:315 (add_custom_target): add_custom_target cannot create target "htmlhandbook" because another target with the same name already exists. The existing target is a custom target created in source directory "/data/mykde/src/KDE/kdelibs/doc/kioslave/data". See documentation for policy CMP0002 for more details. Call Stack (most recent call first): doc/kioslave/file/CMakeLists.txt:2 (kde4_create_handbook) add "-DCMAKE_POLICY_DEFAULT_CMP0002=OLD" This target relied on behavior that's been deprecated in CMake 2.6 (ie. like centuries ago) The stupid thing here is that before CMake 3.0(?) one would have gotten a warning to fix that, but things would still have worked - but that warning was silenced by FindKDEInternal.cmake Until Stephen removed that with http://quickgit.kde.org/?p=kdelibs.git&a=commit&h=dda2199d601491c6ceb07b5f11c8696216558623 While in theory a good idea (ppl. should really know that things are *gonna* break if they don't fix it), the default is "NEW" in CMake versions in the wild (>3.0) and configuration fails with an error instead of telling developers to "please fix your shit". Ie. Stephens change actually comes rather (too) late. It's however now mandatory, since apparently the OLD behavior is gonna removed soon, so things must be fixed, or will completely fail with upcoming CMake versions. Wrt this, I'd actually say that "yes, we need those patches in frozen kdelibs" - they don't fix, but expose bugs. (while ideally, the policy update should not have been stashed itfp, but we don't live in "should-land") Alternatively, we'd have to declare maximum cmake versions for kdelibs :-\ Cheers, Thomas
Re: [kdelibs/KDE/4.14] cmake/modules: Remove policy settings from FindKDE4Internal.
Allen Winter ha scritto: > Stephen, > > For years I have passed -DKDE4_ENABLE_HTMLHANDBOOK=1 to cmake when building > KDE projects. > As of today I get this error: > > CMake Error at cmake/modules/KDE4Macros.cmake:315 (add_custom_target): > add_custom_target cannot create target "htmlhandbook" because another > target with the same name already exists. The existing target is a custom > target created in source directory > "/data/mykde/src/KDE/kdelibs/doc/kioslave/data". See documentation for > policy CMP0002 for more details. > Call Stack (most recent call first): > doc/kioslave/file/CMakeLists.txt:2 (kde4_create_handbook) > > As I recall, KDE4_ENABLE_HTMLHANDBOOK automagically created the html versions > of the handbooks > which I found quite handy. In any event, should I stop passing variable now? > or is this something you can fix? > Maybe it could be the same issue fixed in kdoctools (but I think never backported): https://git.reviewboard.kde.org/r/116650/ http://quickgit.kde.org/?p=kdoctools.git&a=commit&h=8aad0fb7aaa3bbb9da8801d2d12f3396f74569d5 Does it look the same? Ciao -- Luigi
Re: [kdelibs/KDE/4.14] cmake/modules: Remove policy settings from FindKDE4Internal.
Stephen, For years I have passed -DKDE4_ENABLE_HTMLHANDBOOK=1 to cmake when building KDE projects. As of today I get this error: CMake Error at cmake/modules/KDE4Macros.cmake:315 (add_custom_target): add_custom_target cannot create target "htmlhandbook" because another target with the same name already exists. The existing target is a custom target created in source directory "/data/mykde/src/KDE/kdelibs/doc/kioslave/data". See documentation for policy CMP0002 for more details. Call Stack (most recent call first): doc/kioslave/file/CMakeLists.txt:2 (kde4_create_handbook) As I recall, KDE4_ENABLE_HTMLHANDBOOK automagically created the html versions of the handbooks which I found quite handy. In any event, should I stop passing variable now? or is this something you can fix? -Allen On Monday, July 20, 2015 10:31:39 PM Albert Astals Cid wrote: > El Dilluns, 20 de juliol de 2015, a les 20:27:24, Albert Astals Cid va > escriure: > > By the looks of it, it seems it's also making this not compile anymore > > > > https://build.kde.org/job/kdenetwork-filesharing%20Applications-15.08%20stab > > le-qt4/PLATFORM=Linux,compiler=gcc/1/console > > Actually this one seems to have autofixed itself. > > Weird. > > Albert > > > > > Sad Albert is Sad > > > > El Dilluns, 20 de juliol de 2015, a les 20:20:06, Albert Astals Cid va > escriure: > > > Do we really need all these commits in a frozen kdelibs? > > > > > > Are they bugfixes? > > > > > > Has someone reviewed them? > > > > > > It seems at least one of them has caused kde-workspace to stop compiling. > > > > > > Can you clarify what's the benefit of these set of commits? > > > > > > Cheers, > > > > > > Albert > > > > > > El Dilluns, 20 de juliol de 2015, a les 18:07:14, Stephen Kelly va > escriure: > > > > Git commit ddd2b3290d5d7cef9abfba7ce5e15b6c801d531c by Stephen Kelly. > > > > Committed on 20/07/2015 at 18:04. > > > > Pushed by skelly into branch 'KDE/4.14'. > > > > > > > > Remove policy settings from FindKDE4Internal. > > > > > > > > At this point, the ones which are set here are all set to NEW, except > > > > CMP0011. The point of CMP0011 here is to make the policy settings > > > > be used by consumers. All consumers need to gain a use of > > > > the cmake_minimum_required command now anyway to satisfy CMP, so > > > > just remove the call in the internal file. > > > > > > > > M +0-29 cmake/modules/FindKDE4Internal.cmake > > > > > > > > http://commits.kde.org/kdelibs/ddd2b3290d5d7cef9abfba7ce5e15b6c801d531c > > > > > > > > diff --git a/cmake/modules/FindKDE4Internal.cmake > > > > b/cmake/modules/FindKDE4Internal.cmake index 6527794..7d54b9b 100644 > > > > --- a/cmake/modules/FindKDE4Internal.cmake > > > > +++ b/cmake/modules/FindKDE4Internal.cmake > > > > @@ -345,35 +345,6 @@ > > > > > > > > # Redistribution and use is allowed according to the terms of the BSD > > > > > > > > license. # For details see the accompanying COPYING-CMAKE-SCRIPTS file. > > > > > > > > - > > > > -# this is required now by cmake 2.6 and so must not be skipped by > > > > if(KDE4_FOUND) below -cmake_minimum_required(VERSION 2.8.9 FATAL_ERROR) > > > > -# set the cmake policies to the 2.4.x compatibility settings (may > > > > change > > > > for KDE 4.3) -cmake_policy(VERSION 2.4.5) > > > > - > > > > -# CMake 2.6, set compatibility behaviour to cmake 2.4 > > > > -# this must be executed always, because the CMAKE_MINIMUM_REQUIRED() > > > > command above -# resets the policy settings, so we get a lot of warnings > > > > - > > > > -# CMP0003: add the link paths to the link command as with cmake 2.4 > > > > -cmake_policy(SET CMP0003 NEW) > > > > - > > > > -cmake_policy(SET CMP0005 NEW) > > > > -# since cmake 2.6.3: NEW behaviour is that setting policies doesn't > > > > "escape" the file -# where this is done, macros and functions are > > > > executed > > > > with the policies as they -# were when the were defined. Keep the OLD > > > > behaviour so we can set the policies here -# for all KDE software > > > > without > > > > the big warning > > > > -cmake_policy(SET CMP0011 OLD) > > > > - > > > > -# since cmake 2.8.4: when include()ing from inside cmake's module dir, > > > > prefer the files -# in this directory over those from CMAKE_MODULE_PATH > > > > -cmake_policy(SET CMP0017 NEW) > > > > - > > > > -if (POLICY CMP0026) > > > > - # Don't use the LOCATION target property of buildsystem targets. > > > > - cmake_policy(SET CMP0026 NEW) > > > > -endif (POLICY CMP0026) > > > > - > > > > > > > > # Only do something if it hasn't been found yet > > > > if(NOT KDE4_FOUND) >
Re: Moving akonadi from kdesupport and akonadi-search from playground
Daniel Vrátil ha scritto: > Hi all, > > we (the KDE PIM team) kinda screwed up when we forgot to communicate our > intentions about > next KDE PIM release with the release team and we ended up in a situation that > we have > some repositories in modules from which they cannot be released as part of KDE > Applications, > so releasing KF5-based KDE PIM as part of KDE Applications is currently > endangered. I have a related question about this (sorry for hijacking the thread), but as I'm moving translations around... - do you mean do you want to move those to modules to kdepim? - do we need all kdepim, kdepim-runtime, kdepimlibs AND kde/pim? Ciao -- Luigi
Re: KDE Applications Versioning
El Dilluns, 20 de juliol de 2015, a les 09:42:40, Andreas Cord-Landwehr va escriure: > On Tuesday 14 July 2015 07:08:57 Andreas Cord-Landwehr wrote: > > If it is OK this way, I can add it later today to the wiki page. > > Hi, since I did not hear any oppositions, I just added the paragraph to the > wiki page draft. Ok, i moved it to https://community.kde.org/Applications/Versioning and removed the construction notice. Cheers, Albert > > Cheers, > Andreas
Re: [kdelibs/KDE/4.14] cmake/modules: Remove policy settings from FindKDE4Internal.
El Dilluns, 20 de juliol de 2015, a les 20:27:24, Albert Astals Cid va escriure: > By the looks of it, it seems it's also making this not compile anymore > > https://build.kde.org/job/kdenetwork-filesharing%20Applications-15.08%20stab > le-qt4/PLATFORM=Linux,compiler=gcc/1/console Actually this one seems to have autofixed itself. Weird. Albert > > Sad Albert is Sad > > El Dilluns, 20 de juliol de 2015, a les 20:20:06, Albert Astals Cid va escriure: > > Do we really need all these commits in a frozen kdelibs? > > > > Are they bugfixes? > > > > Has someone reviewed them? > > > > It seems at least one of them has caused kde-workspace to stop compiling. > > > > Can you clarify what's the benefit of these set of commits? > > > > Cheers, > > > > Albert > > > > El Dilluns, 20 de juliol de 2015, a les 18:07:14, Stephen Kelly va escriure: > > > Git commit ddd2b3290d5d7cef9abfba7ce5e15b6c801d531c by Stephen Kelly. > > > Committed on 20/07/2015 at 18:04. > > > Pushed by skelly into branch 'KDE/4.14'. > > > > > > Remove policy settings from FindKDE4Internal. > > > > > > At this point, the ones which are set here are all set to NEW, except > > > CMP0011. The point of CMP0011 here is to make the policy settings > > > be used by consumers. All consumers need to gain a use of > > > the cmake_minimum_required command now anyway to satisfy CMP, so > > > just remove the call in the internal file. > > > > > > M +0-29 cmake/modules/FindKDE4Internal.cmake > > > > > > http://commits.kde.org/kdelibs/ddd2b3290d5d7cef9abfba7ce5e15b6c801d531c > > > > > > diff --git a/cmake/modules/FindKDE4Internal.cmake > > > b/cmake/modules/FindKDE4Internal.cmake index 6527794..7d54b9b 100644 > > > --- a/cmake/modules/FindKDE4Internal.cmake > > > +++ b/cmake/modules/FindKDE4Internal.cmake > > > @@ -345,35 +345,6 @@ > > > > > > # Redistribution and use is allowed according to the terms of the BSD > > > > > > license. # For details see the accompanying COPYING-CMAKE-SCRIPTS file. > > > > > > - > > > -# this is required now by cmake 2.6 and so must not be skipped by > > > if(KDE4_FOUND) below -cmake_minimum_required(VERSION 2.8.9 FATAL_ERROR) > > > -# set the cmake policies to the 2.4.x compatibility settings (may > > > change > > > for KDE 4.3) -cmake_policy(VERSION 2.4.5) > > > - > > > -# CMake 2.6, set compatibility behaviour to cmake 2.4 > > > -# this must be executed always, because the CMAKE_MINIMUM_REQUIRED() > > > command above -# resets the policy settings, so we get a lot of warnings > > > - > > > -# CMP0003: add the link paths to the link command as with cmake 2.4 > > > -cmake_policy(SET CMP0003 NEW) > > > - > > > -cmake_policy(SET CMP0005 NEW) > > > -# since cmake 2.6.3: NEW behaviour is that setting policies doesn't > > > "escape" the file -# where this is done, macros and functions are > > > executed > > > with the policies as they -# were when the were defined. Keep the OLD > > > behaviour so we can set the policies here -# for all KDE software > > > without > > > the big warning > > > -cmake_policy(SET CMP0011 OLD) > > > - > > > -# since cmake 2.8.4: when include()ing from inside cmake's module dir, > > > prefer the files -# in this directory over those from CMAKE_MODULE_PATH > > > -cmake_policy(SET CMP0017 NEW) > > > - > > > -if (POLICY CMP0026) > > > - # Don't use the LOCATION target property of buildsystem targets. > > > - cmake_policy(SET CMP0026 NEW) > > > -endif (POLICY CMP0026) > > > - > > > > > > # Only do something if it hasn't been found yet > > > if(NOT KDE4_FOUND)
Re: [kdelibs/KDE/4.14] cmake/modules: Remove policy settings from FindKDE4Internal.
By the looks of it, it seems it's also making this not compile anymore https://build.kde.org/job/kdenetwork-filesharing%20Applications-15.08%20stable-qt4/PLATFORM=Linux,compiler=gcc/1/console Sad Albert is Sad El Dilluns, 20 de juliol de 2015, a les 20:20:06, Albert Astals Cid va escriure: > Do we really need all these commits in a frozen kdelibs? > > Are they bugfixes? > > Has someone reviewed them? > > It seems at least one of them has caused kde-workspace to stop compiling. > > Can you clarify what's the benefit of these set of commits? > > Cheers, > Albert > > El Dilluns, 20 de juliol de 2015, a les 18:07:14, Stephen Kelly va escriure: > > Git commit ddd2b3290d5d7cef9abfba7ce5e15b6c801d531c by Stephen Kelly. > > Committed on 20/07/2015 at 18:04. > > Pushed by skelly into branch 'KDE/4.14'. > > > > Remove policy settings from FindKDE4Internal. > > > > At this point, the ones which are set here are all set to NEW, except > > CMP0011. The point of CMP0011 here is to make the policy settings > > be used by consumers. All consumers need to gain a use of > > the cmake_minimum_required command now anyway to satisfy CMP, so > > just remove the call in the internal file. > > > > M +0-29 cmake/modules/FindKDE4Internal.cmake > > > > http://commits.kde.org/kdelibs/ddd2b3290d5d7cef9abfba7ce5e15b6c801d531c > > > > diff --git a/cmake/modules/FindKDE4Internal.cmake > > b/cmake/modules/FindKDE4Internal.cmake index 6527794..7d54b9b 100644 > > --- a/cmake/modules/FindKDE4Internal.cmake > > +++ b/cmake/modules/FindKDE4Internal.cmake > > @@ -345,35 +345,6 @@ > > > > # Redistribution and use is allowed according to the terms of the BSD > > > > license. # For details see the accompanying COPYING-CMAKE-SCRIPTS file. > > > > - > > -# this is required now by cmake 2.6 and so must not be skipped by > > if(KDE4_FOUND) below -cmake_minimum_required(VERSION 2.8.9 FATAL_ERROR) > > -# set the cmake policies to the 2.4.x compatibility settings (may change > > for KDE 4.3) -cmake_policy(VERSION 2.4.5) > > - > > -# CMake 2.6, set compatibility behaviour to cmake 2.4 > > -# this must be executed always, because the CMAKE_MINIMUM_REQUIRED() > > command above -# resets the policy settings, so we get a lot of warnings > > - > > -# CMP0003: add the link paths to the link command as with cmake 2.4 > > -cmake_policy(SET CMP0003 NEW) > > - > > -cmake_policy(SET CMP0005 NEW) > > -# since cmake 2.6.3: NEW behaviour is that setting policies doesn't > > "escape" the file -# where this is done, macros and functions are executed > > with the policies as they -# were when the were defined. Keep the OLD > > behaviour so we can set the policies here -# for all KDE software without > > the big warning > > -cmake_policy(SET CMP0011 OLD) > > - > > -# since cmake 2.8.4: when include()ing from inside cmake's module dir, > > prefer the files -# in this directory over those from CMAKE_MODULE_PATH > > -cmake_policy(SET CMP0017 NEW) > > - > > -if (POLICY CMP0026) > > - # Don't use the LOCATION target property of buildsystem targets. > > - cmake_policy(SET CMP0026 NEW) > > -endif (POLICY CMP0026) > > - > > > > # Only do something if it hasn't been found yet > > if(NOT KDE4_FOUND)
Re: [kdelibs/KDE/4.14] cmake/modules: Remove policy settings from FindKDE4Internal.
Do we really need all these commits in a frozen kdelibs? Are they bugfixes? Has someone reviewed them? It seems at least one of them has caused kde-workspace to stop compiling. Can you clarify what's the benefit of these set of commits? Cheers, Albert El Dilluns, 20 de juliol de 2015, a les 18:07:14, Stephen Kelly va escriure: > Git commit ddd2b3290d5d7cef9abfba7ce5e15b6c801d531c by Stephen Kelly. > Committed on 20/07/2015 at 18:04. > Pushed by skelly into branch 'KDE/4.14'. > > Remove policy settings from FindKDE4Internal. > > At this point, the ones which are set here are all set to NEW, except > CMP0011. The point of CMP0011 here is to make the policy settings > be used by consumers. All consumers need to gain a use of > the cmake_minimum_required command now anyway to satisfy CMP, so > just remove the call in the internal file. > > M +0-29 cmake/modules/FindKDE4Internal.cmake > > http://commits.kde.org/kdelibs/ddd2b3290d5d7cef9abfba7ce5e15b6c801d531c > > diff --git a/cmake/modules/FindKDE4Internal.cmake > b/cmake/modules/FindKDE4Internal.cmake index 6527794..7d54b9b 100644 > --- a/cmake/modules/FindKDE4Internal.cmake > +++ b/cmake/modules/FindKDE4Internal.cmake > @@ -345,35 +345,6 @@ > # Redistribution and use is allowed according to the terms of the BSD > license. # For details see the accompanying COPYING-CMAKE-SCRIPTS file. > > - > -# this is required now by cmake 2.6 and so must not be skipped by > if(KDE4_FOUND) below -cmake_minimum_required(VERSION 2.8.9 FATAL_ERROR) > -# set the cmake policies to the 2.4.x compatibility settings (may change > for KDE 4.3) -cmake_policy(VERSION 2.4.5) > - > -# CMake 2.6, set compatibility behaviour to cmake 2.4 > -# this must be executed always, because the CMAKE_MINIMUM_REQUIRED() > command above -# resets the policy settings, so we get a lot of warnings > - > -# CMP0003: add the link paths to the link command as with cmake 2.4 > -cmake_policy(SET CMP0003 NEW) > - > -cmake_policy(SET CMP0005 NEW) > -# since cmake 2.6.3: NEW behaviour is that setting policies doesn't > "escape" the file -# where this is done, macros and functions are executed > with the policies as they -# were when the were defined. Keep the OLD > behaviour so we can set the policies here -# for all KDE software without > the big warning > -cmake_policy(SET CMP0011 OLD) > - > -# since cmake 2.8.4: when include()ing from inside cmake's module dir, > prefer the files -# in this directory over those from CMAKE_MODULE_PATH > -cmake_policy(SET CMP0017 NEW) > - > -if (POLICY CMP0026) > - # Don't use the LOCATION target property of buildsystem targets. > - cmake_policy(SET CMP0026 NEW) > -endif (POLICY CMP0026) > - > # Only do something if it hasn't been found yet > if(NOT KDE4_FOUND)
Re: KSyCoca, Thread safety, and Cache invalidation
On Monday 20 July 2015 16:05:06 David Faure wrote: > Or maybe QDateTime::currentDateTime() could avoid calling the awful tzset()? > Thiago, any input? QDateTime::currentDateTimeUtc() does not call tzset. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: KSyCoca, Thread safety, and Cache invalidation
On Monday 20 July 2015 16:05:06 David Faure wrote:
> On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote:
> > https://bugs.kde.org/show_bug.cgi?id=346974
> >
> > According to the backtrace, the process is busy inside
> > QMimeDataBase::mimeTypeForName(QString) doing time-related things and
> > accessing /etc/localtime all the time, probably because of the mtime
> > check that you mentioned. I don't know that Qt version was used
> > though, so I'm not sure if that still applies to the most recent
> > versions.
>
> I forgot my own code, it seems.
> Looking at it again: it does already only check the mtime on disk every 5
> seconds.
>
> int qmime_secondsBetweenChecks = 5;
> bool QMimeProviderBase::shouldCheck()
> {
> const QDateTime now = QDateTime::currentDateTime();
> if (m_lastCheck.isValid() && m_lastCheck.secsTo(now) <
> qmime_secondsBetweenChecks) return false;
> m_lastCheck = now;
> return true;
> }
>
> But it's exactly that call to QDateTime::currentDateTime() which ends up
> calling tzset (which seems to access to /etc/localtime on disk every time),
> according to https://bugsfiles.kde.org/attachment.cgi?id=92719
>
> Maybe this code should use QElapsedTimer instead of
> QDateTime::currentDateTime()? Or maybe QDateTime::currentDateTime() could
> avoid calling the awful tzset()? Thiago, any input?
Sorry, I had missed the other replies to this thread.
(I recommend using k-f-d to discuss code in KF5, kde-core-devel has too much
other stuff I have a hard time following it).
I'll work on a Qt patch.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
Re: Moving akonadi from kdesupport and akonadi-search from playground
Le Monday 20 July 2015, 17:08:45 Daniel Vrátil a écrit : > On 20.07.2015 16:44, Martin Sandsmark wrote: > > On Mon, Jul 20, 2015 at 04:17:16PM +0200, Daniel Vrátil wrote: > >> We only ported the code to KF5 > > > > Unless I'm misunderstanding something, isn't this a quite significant > > change? > > From experience even seemingly simple ports can introduce pretty > > serious > > breakage in edge cases. > > True, although the core code is mostly plain Qt wrapper around Xapian. > We've (me, > Laurent and few people on #kontact) been using it for couple weeks - > months now without > any problems. Yep I use it from 2 months without problem. I fixed some bugs etc. It's not just a porting we use it. Regards > > Dan -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: Moving akonadi from kdesupport and akonadi-search from playground
On 20.07.2015 16:44, Martin Sandsmark wrote: On Mon, Jul 20, 2015 at 04:17:16PM +0200, Daniel Vrátil wrote: We only ported the code to KF5 Unless I'm misunderstanding something, isn't this a quite significant change? From experience even seemingly simple ports can introduce pretty serious breakage in edge cases. True, although the core code is mostly plain Qt wrapper around Xapian. We've (me, Laurent and few people on #kontact) been using it for couple weeks - months now without any problems. Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)
Re: Moving akonadi from kdesupport and akonadi-search from playground
On Mon, Jul 20, 2015 at 04:17:16PM +0200, Daniel Vrátil wrote: > We only ported the code to KF5 Unless I'm misunderstanding something, isn't this a quite significant change? >From experience even seemingly simple ports can introduce pretty serious breakage in edge cases. -- Martin Sandsmark
Moving akonadi from kdesupport and akonadi-search from playground
Hi all, we (the KDE PIM team) kinda screwed up when we forgot to communicate our intentions about next KDE PIM release with the release team and we ended up in a situation that we have some repositories in modules from which they cannot be released as part of KDE Applications, so releasing KF5-based KDE PIM as part of KDE Applications is currently endangered. Normally I'd have to ask for the 2-week review period before moving the repos but since we are under a big time pressure and because the modules have both proven themselves (see below), I kindly ask for those repositories to be granted an exception to the review period and they can be moved right away. akonadi-search repository contains PIM-specific code that originally lived in Baloo repository and was split out when Baloo switched to KF5. We only ported the code to KF5 and removed all mentions of "Baloo" from code (it's now Akonadi::Search namespace). Technically this code already went through review when Baloo has been reviewed for move from playground, and also during Baloo development, and has been actively used with KDE PIM 4.x for several releases. akonadi I think has proven itself well enough in during the years :) I'd like to move both repositories to kde/pim module where other KDE PIM repos (mostly those split from kdepimlibs) currently live. If that's fine with everyone I'd request the move ASAP. Cheers, Daniel -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)
Re: KSyCoca, Thread safety, and Cache invalidation
On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote:
> https://bugs.kde.org/show_bug.cgi?id=346974
>
> According to the backtrace, the process is busy inside
> QMimeDataBase::mimeTypeForName(QString) doing time-related things and
> accessing /etc/localtime all the time, probably because of the mtime
> check that you mentioned. I don't know that Qt version was used
> though, so I'm not sure if that still applies to the most recent
> versions.
I forgot my own code, it seems.
Looking at it again: it does already only check the mtime on disk every 5
seconds.
int qmime_secondsBetweenChecks = 5;
bool QMimeProviderBase::shouldCheck()
{
const QDateTime now = QDateTime::currentDateTime();
if (m_lastCheck.isValid() && m_lastCheck.secsTo(now) <
qmime_secondsBetweenChecks)
return false;
m_lastCheck = now;
return true;
}
But it's exactly that call to QDateTime::currentDateTime() which ends up
calling tzset
(which seems to access to /etc/localtime on disk every time), according to
https://bugsfiles.kde.org/attachment.cgi?id=92719
Maybe this code should use QElapsedTimer instead of
QDateTime::currentDateTime()?
Or maybe QDateTime::currentDateTime() could avoid calling the awful tzset()?
Thiago, any input?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
Re: 3 UDSEntry optimizations
On Sunday, 19 July 2015 23:11:05 CEST, Mark Gaiser wrote: Regarding gerrit. How can i make patch 2 and 3 dependent on 1? You did a good job. A correct way is to produce three commits locally, 1 being parent of 2 and 2 being a parent of 3, and push these to refs/for/master, which is what you did. Gerrit will do the right thing here. And why is gerrit failing? You're getting a Verified-1 vote from the CI because the test suite doesn't pass. I would encourage people to take a look at the CI matrix overview [1] and fix these test failures. I was trying to get rid of most of these, but my time is limited and I don't know much about these libraries. Jenkins says the same, btw. With kind regards, Jan [1] http://ci-logs.kde.flaska.net/matrix.html -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: KDE Applications Versioning
Hi, > Since this hasn't been finalized I didn't include it in my email to kde-cvs- > announce about the creation of the 15.08 branches for the KDE Applications > modules. > > Cheers, > Albert > > El Dimarts, 14 de juliol de 2015, a les 07:08:57, Andreas Cord-Landwehr va > escriure: > > On Monday 13 July 2015 23:14:17 Albert Astals Cid wrote: > > > I did a few tweaks, i still feel it seems this is "the official way" > > > other > > > than an "optional way" of defining the version but maybe that's just me. > > > > Hi, I have the same feeling as Albert that the current text is not clear > > enough that both variants (increase version by hand and using the scripted > > approach) are fine. > > > > What about adding an introduction paragraph like the following: > > > > - - > > Every application has an application version number that regular has to be > > increased to distinguish different versions of the application (e.g., > > features, bugfixes). When an application does not have its own release > > schedule but is released alongside with KDE Applications, there is also the > > version number of the KDE Applications release. It is the maintainer's duty > > to take care on increasing the version number regularly and there are > > specifically two possible ways: > > > > 1. increase the version number by hand for each new release > > 2. use the same version number as KDE Applications and let the release > > script update the version number > > > > In the following, we explain how to use the scripted version numbers. > > - - > > > > If it is OK this way, I can add it later today to the wiki page. I somehow missed that mail ;=) I am all for adding that paragraph and then moving the wiki page to the right place. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
