<2863414.xACffPTQfr@linux-t46v.suse>
Message-ID: <20161214144858.GA19043@archbox>
On Wed, Dec 14, 2016 at 02:49:58PM +0100, David Faure wrote:
> Done, here's the information about the new tarball.
>
> kpackage v5.29.1
> b6eafc589fb5da5aa5c98c5fbc0a5ae9d3796c37
> 91aa6c79f99492eeefb0b03cb1d04cc19f91d5a5c08867141e31ea1b74c17ced sources/kpackage-5.29.1.tar.xz
>
> I also committed www/info/source-kf-5.29.1.inc, can you take care of editing
> www/info/kde-frameworks-2.59.0.php, mention the "known bugs" and include
> the new info "inc" file under the main one ?
Um.. I don't have super powers to write to www on svn.. however attached
patch for it.
--
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
-------------- next part --------------
Index: kde-frameworks-5.29.0.php
===================================================================
--- kde-frameworks-5.29.0.php (revision 1476986)
+++ kde-frameworks-5.29.0.php (working copy)
@@ -22,7 +22,7 @@
surfacing after the release was packaged:
- - No significant bugs.
+ - KPackage: Generates compile time error if applicaiton using two packages with different type but similar id. Fixed in 5.29.1
Please check the bug database
@@ -60,6 +60,9 @@
+
From aacid at kde.org Wed Dec 14 18:52:18 2016
From: aacid at kde.org (Albert Astals Cid)
Date: Wed, 14 Dec 2016 19:52:18 +0100
Subject: kpackage-5.29.1
In-Reply-To: <20161214144858.GA19043@archbox>
References:
<2863414.xACffPTQfr@linux-t46v.suse> <20161214144858.GA19043@archbox>
Message-ID: <1842638.0GWxN2lQdO@xps>
El dimecres, 14 de desembre de 2016, a les 20:18:58 CET, Bhushan Shah va
escriure:
> On Wed, Dec 14, 2016 at 02:49:58PM +0100, David Faure wrote:
> > Done, here's the information about the new tarball.
> >
> > kpackage v5.29.1
> > b6eafc589fb5da5aa5c98c5fbc0a5ae9d3796c37
> > 91aa6c79f99492eeefb0b03cb1d04cc19f91d5a5c08867141e31ea1b74c17ced
> > sources/kpackage-5.29.1.tar.xz
> >
> > I also committed www/info/source-kf-5.29.1.inc, can you take care of
> > editing www/info/kde-frameworks-2.59.0.php, mention the "known bugs" and
> > include the new info "inc" file under the main one ?
>
> Um.. I don't have super powers to write to www on svn.. however attached
> patch for it.
David commited it.
I fixed the applicaiton -> application typo.
Cheers,
Albert
From aacid at kde.org Wed Dec 14 18:59:49 2016
From: aacid at kde.org (Albert Astals Cid)
Date: Wed, 14 Dec 2016 18:59:49 +0000
Subject: www/sites/www/announcements
Message-ID:
SVN commit 1477002 by aacid:
Fix supported Qt versions in KF5
CCMAIL: faure at kde.org
CCMAIL: release-team at kde.org
M +1 -1 kde-frameworks-5.13.0.php
M +1 -1 kde-frameworks-5.14.0.php
M +1 -1 kde-frameworks-5.15.0.php
M +1 -1 kde-frameworks-5.16.0.php
M +1 -1 kde-frameworks-5.17.0.php
M +1 -1 kde-frameworks-5.18.0.php
M +1 -1 kde-frameworks-5.19.0.php
M +1 -1 kde-frameworks-5.20.0.php
M +1 -1 kde-frameworks-5.21.0.php
M +1 -1 kde-frameworks-5.22.0.php
M +1 -1 kde-frameworks-5.23.0.php
M +1 -1 kde-frameworks-5.24.0.php
M +1 -1 kde-frameworks-5.25.0.php
M +1 -1 kde-frameworks-5.26.0.php
M +1 -1 kde-frameworks-5.27.0.php
M +1 -1 kde-frameworks-5.28.0.php
M +1 -1 kde-frameworks-5.29.0.php
--- trunk/www/sites/www/announcements/kde-frameworks-5.13.0.php #1477001:1477002
@@ -340,7 +340,7 @@
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.3");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.3");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.3");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.3");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.3");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.3");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.3");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.3");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.4");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.4");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.4");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.4");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.5");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.5");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.5");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.5");?>
cmake .; make; make install commands. For a single Tier 1 framework, this is often the easiest solution. People interested in contributing to frameworks or tracking progress in development of the entire set are encouraged to use kdesrc-build.
Frameworks %2 requires Qt %3.
-", "http://kdesrc-build.kde.org/", $release, "5.2");?>
+", "http://kdesrc-build.kde.org/", $release, "5.5");?>
Message-ID: <20161215165734.2edbe563@giskard.marionegri.it>
Il giorno Sun, 04 Dec 2016 00:37:52 +0100
David Faure ha scritto:
> KDE Frameworks 5.29.0 has been uploaded to the usual place.
I know it's been released, but there's a snag with frameworkintegration:
- wrong CMake check (checks for AppStreamQt >= 0.10 but doesn't get
detected because the CMake file in 0.10 is called AppstreamQt -
lowercase s -,). It's only correct for AppStreamQt 0.10.4+ (why,
*why* SIC changes in minor releases!)
- even if that is fixed, it uses includes that aren't available in
0.10, so compilation fails. Again, likely available in 0.10.4 or so.
Either the version check is fixed, or the code adjusted to actually
work on 0.10.0.
(/me is not too fond of the constant breakage in AppStreamQt as well)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Firma digitale OpenPGP
URL:
From aacid at kde.org Thu Dec 15 17:58:15 2016
From: aacid at kde.org (Albert Astals Cid)
Date: Thu, 15 Dec 2016 18:58:15 +0100
Subject: new dragon tarball - was - Re: KDE Applications 16.12.0 packages
available for packagers
In-Reply-To: <1540435.zciKPnytZj@xps>
References: <1540435.zciKPnytZj@xps>
Message-ID: <7819534.ydcXRCUMSG@xps>
People had forgotten to merge stable branches to master and bugfixes were lost.
dragon Applications/16.12
ccac1eb4227bc6df2ccfe0d899df43c331060421
028fe9e7475dd88d0ebe3a3e5b1e26677886013a4e82457fab880ad17ed34a23 sources/dragon-16.12.0.tar.xz
Cheers,
Albert
El divendres, 9 de desembre de 2016, a les 12:18:19 CET, Albert Astals Cid va escriure:
> At the usual location.
>
> Haven't had time to compile yet, will start now.
>
> REVISIONS_AND_HASHES file at https://paste.kde.org/paclv5d4w
>
> Public release next week thursday.
>
> Cheers,
> Albert
From aacid at kde.org Thu Dec 15 17:59:13 2016
From: aacid at kde.org (Albert Astals Cid)
Date: Thu, 15 Dec 2016 18:59:13 +0100
Subject: Update Dragon 16.12 tarball release
In-Reply-To: <2719150.EoeFMS7zca@toni-pc>
References: <2719150.EoeFMS7zca@toni-pc>
Message-ID: <1629387.RaA59B2yNB@xps>
El dijous, 15 de desembre de 2016, a les 6:45:31 CET, Anthony Fieroni va
escriure:
> I merge branch 16.04 into 16.12, it was forgotten.
Hood catch, but please next time try to catch it before the release day.
>
> https://cgit.kde.org/dragon.git/commit/?h=Applications/16.12
Also next time i'd appreciate if you mailed release-team and not me directly.
We have mailing lists for a reason :)
Cheers,
Albert
From aacid at kde.org Thu Dec 15 18:41:51 2016
From: aacid at kde.org (Albert Astals Cid)
Date: Thu, 15 Dec 2016 18:41:51 +0000
Subject: www/sites/www
Message-ID:
SVN commit 1477139 by aacid:
KDE Applications 16.12.0
CCMAIL: release-team at kde.org
M +0 -10 announcements/announce-applications-16.12.0.php
M +7 -1 announcements/index.php
M +1 -1 announcements/release_data.php
M +32 -0 i18n/pt/www.inc
M +32 -0 i18n/uk/www.inc
M +4 -8 index.php
A info/applications-16.12.0.php
A info/source-applications-16.12.0.inc
http://websvn.kde.org/?view=rev&revision=1477139
From aacid at kde.org Thu Dec 15 21:14:38 2016
From: aacid at kde.org (Albert Astals Cid)
Date: Thu, 15 Dec 2016 22:14:38 +0100
Subject: Dropping the svn kio from kdesdk-kioslaves
Message-ID: <3186774.Hvc6M4JW8H@xps>
Why?
* It doesn't compile with newer libsvn
* It's kdelibs4-based
Any disagreement on dropping it?
Cheers,
Albert
From kfunk at kde.org Thu Dec 15 22:12:58 2016
From: kfunk at kde.org (Kevin Funk)
Date: Thu, 15 Dec 2016 23:12:58 +0100
Subject: Dropping the svn kio from kdesdk-kioslaves
In-Reply-To: <3186774.Hvc6M4JW8H@xps>
References: <3186774.Hvc6M4JW8H@xps>
Message-ID: <2378706.iPFFefHPQL@kerberos>
On Thursday, 15 December 2016 22:14:38 CET Albert Astals Cid wrote:
> Why?
> * It doesn't compile with newer libsvn
> * It's kdelibs4-based
Heya,
I know a few people that use kdesvn, how's the relation to that?
I saw that Christian (CC'ed) put quite some effort in porting kdesvn over to a
KF5-based kdelibs4support-free code base. If I understand correctly kdesvn.git
even contains a copy of the KIO SVN implementation (c.f. kdesvn.git:src/
kiosvn)?
Please elaborate :)
PS: /me never uses SVN directly usually.
Cheers,
Kevin
> Any disagreement on dropping it?
>
> Cheers,
> Albert
--
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: This is a digitally signed message part.
URL:
From tcberner at gmail.com Thu Dec 15 22:42:11 2016
From: tcberner at gmail.com (Tobias C. Berner)
Date: Thu, 15 Dec 2016 23:42:11 +0100
Subject: Dropping the svn kio from kdesdk-kioslaves
In-Reply-To: <2378706.iPFFefHPQL@kerberos>
References: <3186774.Hvc6M4JW8H@xps> <2378706.iPFFefHPQL@kerberos>
Message-ID:
On FreeBSD we have this patch
https://svnweb.freebsd.org/ports/head/devel/kdesdk4-kioslaves/files/patch-svn_svn.cpp?revision=400399
to make the kioslave build against subversion 1.9.
mfg Tobias
On 15 December 2016 at 23:12, Kevin Funk wrote:
> On Thursday, 15 December 2016 22:14:38 CET Albert Astals Cid wrote:
> > Why?
> > * It doesn't compile with newer libsvn
> > * It's kdelibs4-based
>
> Heya,
>
> I know a few people that use kdesvn, how's the relation to that?
>
> I saw that Christian (CC'ed) put quite some effort in porting kdesvn over
> to a
> KF5-based kdelibs4support-free code base. If I understand correctly
> kdesvn.git
> even contains a copy of the KIO SVN implementation (c.f. kdesvn.git:src/
> kiosvn)?
>
> Please elaborate :)
>
> PS: /me never uses SVN directly usually.
>
> Cheers,
> Kevin
>
> > Any disagreement on dropping it?
> >
> > Cheers,
> > Albert
>
>
> --
> Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From aleixpol at kde.org Fri Dec 16 00:39:49 2016
From: aleixpol at kde.org (Aleix Pol)
Date: Fri, 16 Dec 2016 01:39:49 +0100
Subject: KDE Frameworks 5.29.0
In-Reply-To: <20161215165734.2edbe563@giskard.marionegri.it>
References: <1544539.SQJqS6oqim@linux-t46v.suse>
<20161215165734.2edbe563@giskard.marionegri.it>
Message-ID:
On Thu, Dec 15, 2016 at 4:57 PM, Luca Beltrame wrote:
> Il giorno Sun, 04 Dec 2016 00:37:52 +0100
> David Faure ha scritto:
>
>> KDE Frameworks 5.29.0 has been uploaded to the usual place.
>
> I know it's been released, but there's a snag with frameworkintegration:
>
> - wrong CMake check (checks for AppStreamQt >= 0.10 but doesn't get
> detected because the CMake file in 0.10 is called AppstreamQt -
> lowercase s -,). It's only correct for AppStreamQt 0.10.4+ (why,
> *why* SIC changes in minor releases!)
> - even if that is fixed, it uses includes that aren't available in
> 0.10, so compilation fails. Again, likely available in 0.10.4 or so.
>
> Either the version check is fixed, or the code adjusted to actually
> work on 0.10.0.
>
> (/me is not too fond of the constant breakage in AppStreamQt as well)
https://phabricator.kde.org/D3696
Aleix
From Ch.Ehrlicher at gmx.de Fri Dec 16 05:31:46 2016
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Fri, 16 Dec 2016 06:31:46 +0100
Subject: Dropping the svn kio from kdesdk-kioslaves
In-Reply-To: <2378706.iPFFefHPQL@kerberos>
References: <3186774.Hvc6M4JW8H@xps> <2378706.iPFFefHPQL@kerberos>
Message-ID: <9853b246-4e1c-45b2-48c6-90740aa1cad5@gmx.de>
Am 15.12.2016 um 23:12 schrieb Kevin Funk:
> On Thursday, 15 December 2016 22:14:38 CET Albert Astals Cid wrote:
>> Why?
>> * It doesn't compile with newer libsvn
>> * It's kdelibs4-based
> Heya,
>
> I know a few people that use kdesvn, how's the relation to that?
>
> I saw that Christian (CC'ed) put quite some effort in porting kdesvn over to a
> KF5-based kdelibs4support-free code base. If I understand correctly kdesvn.git
> even contains a copy of the KIO SVN implementation (c.f. kdesvn.git:src/
> kiosvn)?
>
> Please elaborate :)
You're correct - kdesvn contains a kioslave for svn and I ported it to
KF5 (just released kdesvn 2.0.0 some days ago). I don't know if
kdesdk-kioslaves has more functionality but from my point of view it can
be dropped.
Cheers,
Christian
From kfunk at kde.org Fri Dec 16 10:32:21 2016
From: kfunk at kde.org (Kevin Funk)
Date: Fri, 16 Dec 2016 11:32:21 +0100
Subject: Dropping the svn kio from kdesdk-kioslaves
In-Reply-To: <9853b246-4e1c-45b2-48c6-90740aa1cad5@gmx.de>
References: <3186774.Hvc6M4JW8H@xps> <2378706.iPFFefHPQL@kerberos>
<9853b246-4e1c-45b2-48c6-90740aa1cad5@gmx.de>
Message-ID: <1516727.qubFCWHrX7@kerberos>
On Friday, 16 December 2016 06:31:46 CET Christian Ehrlicher wrote:
> Am 15.12.2016 um 23:12 schrieb Kevin Funk:
> > On Thursday, 15 December 2016 22:14:38 CET Albert Astals Cid wrote:
> >> Why?
> >>
> >> * It doesn't compile with newer libsvn
> >> * It's kdelibs4-based
> >
> > Heya,
> >
> > I know a few people that use kdesvn, how's the relation to that?
> >
> > I saw that Christian (CC'ed) put quite some effort in porting kdesvn over
> > to a KF5-based kdelibs4support-free code base. If I understand correctly
> > kdesvn.git even contains a copy of the KIO SVN implementation (c.f.
> > kdesvn.git:src/ kiosvn)?
> >
> > Please elaborate :)
>
> You're correct - kdesvn contains a kioslave for svn and I ported it to
> KF5 (just released kdesvn 2.0.0 some days ago). I don't know if
> kdesdk-kioslaves has more functionality but from my point of view it can
> be dropped.
If the SVN kioslave is standalone, wouldn't it make more sense to actually
keep it in a separate repository/package? So users who just want the Dolphin
integration can just use that?
Wouldn't it make more sense to move your kioslave implementation into kdesdk-
kioslaves, replacing the older copy?
I'm not sure whether Albert just wants to kill the repository or he's just
phasing old unmaintained software. In case of the latter, updating the copy
with the better maintained version probably makes more sense.
Cheers,
Kevin
> Cheers,
> Christian
--
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: This is a digitally signed message part.
URL:
From null at kde.org Mon Dec 19 12:30:44 2016
From: null at kde.org (David Faure)
Date: Mon, 19 Dec 2016 12:30:44 +0000
Subject: [kdepim-runtime/Applications/16.12]
resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource
which failed to create std.ics if it didn't exist.
Message-ID:
Git commit 8ae09b6f4afa8ceb2770da67b6dc79c78b86af47 by David Faure.
Committed on 19/12/2016 at 12:29.
Pushed by dfaure into branch 'Applications/16.12'.
Fix DATA LOSS bug in ical resource which failed to create std.ics if it didn't exist.
The default setup sets the Path to be a local path, not a URL.
=> Use QUrl::fromUserInput so that it can deal with both cases, paths and URLs.
CCMAIL: smartins at kde.org, release-team at kde.org
M +2 -2 resources/shared/singlefileresource/singlefileresource.h
https://commits.kde.org/kdepim-runtime/8ae09b6f4afa8ceb2770da67b6dc79c78b86af47
diff --git a/resources/shared/singlefileresource/singlefileresource.h b/resources/shared/singlefileresource/singlefileresource.h
index f3c19aaf5..3f4149903 100644
--- a/resources/shared/singlefileresource/singlefileresource.h
+++ b/resources/shared/singlefileresource/singlefileresource.h
@@ -55,7 +55,7 @@ public:
, mSettings(new Settings(config()))
{
// The resource needs network when the path refers to a non local file.
- setNeedsNetwork(!QUrl(mSettings->path()).isLocalFile());
+ setNeedsNetwork(!QUrl::fromUserInput(mSettings->path()).isLocalFile());
}
~SingleFileResource()
{
@@ -82,7 +82,7 @@ public:
return;
}
- mCurrentUrl = QUrl(mSettings->path()); // path already has scheme
+ mCurrentUrl = QUrl::fromUserInput(mSettings->path()); // the string contains the scheme if remote, doesn't if local path
if (mCurrentHash.isEmpty())
{
// First call to readFile() lets see if there is a hash stored in a
From aacid at kde.org Mon Dec 19 22:01:45 2016
From: aacid at kde.org (Albert Astals Cid)
Date: Mon, 19 Dec 2016 23:01:45 +0100
Subject: [kdepim-runtime/Applications/16.12]
resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource which
failed to create std.ics if it didn't exist.
In-Reply-To:
References:
Message-ID: <82351898.d197Cbyks8@xps>
Can you clarify when the data loss happens?
Do we need a re-release?
Cheers,
Albert
El dilluns, 19 de desembre de 2016, a les 12:30:44 CET, David Faure va
escriure:
> Git commit 8ae09b6f4afa8ceb2770da67b6dc79c78b86af47 by David Faure.
> Committed on 19/12/2016 at 12:29.
> Pushed by dfaure into branch 'Applications/16.12'.
>
> Fix DATA LOSS bug in ical resource which failed to create std.ics if it
> didn't exist.
>
> The default setup sets the Path to be a local path, not a URL.
> => Use QUrl::fromUserInput so that it can deal with both cases, paths and
> URLs.
>
> CCMAIL: smartins at kde.org, release-team at kde.org
>
> M +2 -2 resources/shared/singlefileresource/singlefileresource.h
>
> https://commits.kde.org/kdepim-runtime/8ae09b6f4afa8ceb2770da67b6dc79c78b86a
> f47
>
> diff --git a/resources/shared/singlefileresource/singlefileresource.h
> b/resources/shared/singlefileresource/singlefileresource.h index
> f3c19aaf5..3f4149903 100644
> --- a/resources/shared/singlefileresource/singlefileresource.h
> +++ b/resources/shared/singlefileresource/singlefileresource.h
> @@ -55,7 +55,7 @@ public:
> , mSettings(new Settings(config()))
> {
> // The resource needs network when the path refers to a non local
> file. - setNeedsNetwork(!QUrl(mSettings->path()).isLocalFile());
> +
> setNeedsNetwork(!QUrl::fromUserInput(mSettings->path()).isLocalFile()); }
> ~SingleFileResource()
> {
> @@ -82,7 +82,7 @@ public:
> return;
> }
>
> - mCurrentUrl = QUrl(mSettings->path()); // path already has scheme
> + mCurrentUrl = QUrl::fromUserInput(mSettings->path()); // the string
> contains the scheme if remote, doesn't if local path if
> (mCurrentHash.isEmpty())
> {
> // First call to readFile() lets see if there is a hash stored
> in a
From faure at kde.org Mon Dec 19 23:07:25 2016
From: faure at kde.org (David Faure)
Date: Tue, 20 Dec 2016 00:07:25 +0100
Subject: [kdepim-runtime/Applications/16.12]
resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource which
failed to create std.ics if it didn't exist.
In-Reply-To: <82351898.d197Cbyks8@xps>
References: <82351898.d197Cbyks8@xps>
Message-ID: <4121968.pfLXGO043c@asterixp50>
On lundi 19 décembre 2016 23:01:45 CET Albert Astals Cid wrote:
> Can you clarify when the data loss happens?
It happened to me with the default setup as a new user (!)
Starting akonadi as a new user, you get a "Personal Calendar" ical resource, configured to point to $HOME/.local/share/apps/korganizer/std.ics (1)
This path typically doesn't exist for a new user (the "apps/" part of it is very kde4, korganizer in kf5 uses ~/.local/share/korganizer), and the code to mkpath the parent dir was incorrect before my fix, so the ical resource would fail to save any change. And since saving (in the writeFile() method) happens delayed (2), it's not part of the akonadi job error handling.
The resource just failed to save, almost silently, except for two qWarnings:
akonadi_ical_resource: writeToFile() mCalendar is 0!
akonadi_ical_resource: Error writing to file
(1) this comes from kdepim-runtime/defaultsetup/defaultcalendar.desktop
(2) see kdepim-runtime/resources/shared/singlefileresource/singlefileresourcebase.cpp
If anyone else can test the "new user setup" and either confirm my findings or prove me wrong, I'm very interested.
I was creating TODOs with zanshin, but I assume that creating events with korganizer would do the same.
> Do we need a re-release?
I would say yes, unless I'm missing something that makes this bug happen only to me (e.g. to git master users).
But AFAICS it's a consequence of the fix for bug 352693, which happened a year ago.
--
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
From sknauss at kde.org Tue Dec 20 09:29:03 2016
From: sknauss at kde.org (Sandro =?ISO-8859-1?Q?Knau=DF?=)
Date: Tue, 20 Dec 2016 10:29:03 +0100
Subject: [kdepim-runtime/Applications/16.12]
resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource which
failed to create std.ics if it didn't exist.
In-Reply-To: <4121968.pfLXGO043c@asterixp50>
References: <82351898.d197Cbyks8@xps>
<4121968.pfLXGO043c@asterixp50>
Message-ID: <1782871.7y7jmFglRY@tuxin>
Hey,
mmh the description of your problem does not match with the commit you have
pushed, or do i miss anything.
Your patch is "only doing:
QUrl(mSettings->path()) -> QUrl::fromUserInput(mSettings->path());
right?
that means that we still have the problem with schema prefix in the url? And
than mCurrentUrl.isLocalFile() is not true and you'll do not enter that
codepath? Because the part that gets the dir you havn't changed...
Just a little bit curious, why this is only a problem for a new user?
On the other side I do not understand why the default local is import to
trigger this bug.
Btw. if the default location for korganzier has changed, than please update
the defaultcalendar.desktop path.
Best Regards,
sandro
--
Am Dienstag, 20. Dezember 2016, 00:07:25 CET schrieb David Faure:
> On lundi 19 décembre 2016 23:01:45 CET Albert Astals Cid wrote:
> > Can you clarify when the data loss happens?
>
> It happened to me with the default setup as a new user (!)
>
> Starting akonadi as a new user, you get a "Personal Calendar" ical resource,
> configured to point to $HOME/.local/share/apps/korganizer/std.ics (1)
>
> This path typically doesn't exist for a new user (the "apps/" part of it is
> very kde4, korganizer in kf5 uses ~/.local/share/korganizer), and the code
> to mkpath the parent dir was incorrect before my fix, so the ical resource
> would fail to save any change. And since saving (in the writeFile() method)
> happens delayed (2), it's not part of the akonadi job error handling. The
> resource just failed to save, almost silently, except for two qWarnings:
> akonadi_ical_resource: writeToFile() mCalendar is 0!
> akonadi_ical_resource: Error writing to file
>
> (1) this comes from kdepim-runtime/defaultsetup/defaultcalendar.desktop
> (2) see
> kdepim-runtime/resources/shared/singlefileresource/singlefileresourcebase.c
> pp
>
> If anyone else can test the "new user setup" and either confirm my findings
> or prove me wrong, I'm very interested.
>
> I was creating TODOs with zanshin, but I assume that creating events with
> korganizer would do the same.
> > Do we need a re-release?
>
> I would say yes, unless I'm missing something that makes this bug happen
> only to me (e.g. to git master users). But AFAICS it's a consequence of the
> fix for bug 352693, which happened a year ago.
From Ch.Ehrlicher at gmx.de Tue Dec 20 09:40:44 2016
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Tue, 20 Dec 2016 10:40:44 +0100
Subject: Dropping the svn kio from kdesdk-kioslaves
In-Reply-To: <1516727.qubFCWHrX7@kerberos>
References: <3186774.Hvc6M4JW8H@xps> <2378706.iPFFefHPQL@kerberos>
<9853b246-4e1c-45b2-48c6-90740aa1cad5@gmx.de> <1516727.qubFCWHrX7@kerberos>
Message-ID: <5e0238e7-934e-6ba5-dd82-35810380b1e7@gmx.de>
Am 16.12.2016 um 11:32 schrieb Kevin Funk:
> If the SVN kioslave is standalone, wouldn't it make more sense to actually
> keep it in a separate repository/package? So users who just want the Dolphin
> integration can just use that?
>
> Wouldn't it make more sense to move your kioslave implementation into kdesdk-
> kioslaves, replacing the older copy?
>
> I'm not sure whether Albert just wants to kill the repository or he's just
> phasing old unmaintained software. In case of the latter, updating the copy
> with the better maintained version probably makes more sense.
I took a look into kdesdk-kioslaves - the code for svn there is
completely different from kdesvn kioslave. Therefore I would suggest to
remove kdesdk-kioslaves/svn because I won't maintain two different
implementations for one protocol.
A distro packager can separate the kdesvn kioslave into a separate
package, at least this is what I would expect looking at the kdesvn code.
Christian
From faure at kde.org Tue Dec 20 20:24:16 2016
From: faure at kde.org (David Faure)
Date: Tue, 20 Dec 2016 21:24:16 +0100
Subject: [kdepim-runtime/Applications/16.12]
resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource which
failed to create std.ics if it didn't exist.
In-Reply-To: <1782871.7y7jmFglRY@tuxin>
References: <4121968.pfLXGO043c@asterixp50>
<1782871.7y7jmFglRY@tuxin>
Message-ID: <7806444.SMD64hJD1G@asterixp50>
On mardi 20 décembre 2016 10:29:03 CET Sandro Knauß wrote:
> Hey,
>
> mmh the description of your problem does not match with the commit you have
> pushed, or do i miss anything.
The latter, I think ;)
> Your patch is "only doing:
> QUrl(mSettings->path()) -> QUrl::fromUserInput(mSettings->path());
> right?
Right.
> that means that we still have the problem with schema prefix in the url?
No, fromUserInput supports both absolute paths and URLs, see API docs.
> And than mCurrentUrl.isLocalFile() is not true and you'll do not enter that
> codepath?
isLocalFile() will be true for local files and false for remote URLs, I don't
see a problem here.
> Just a little bit curious, why this is only a problem for a new user?
Well, anyone without a ~/.local/share/apps/korganizer/ subdir,
which certainly includes new users.
> On the other side I do not understand why the default local is import to
> trigger this bug.
Parse error at "default local is import". Can you rephrase?
> Btw. if the default location for korganzier has changed, than please update
> the defaultcalendar.desktop path.
And break "Personal Calendar" for all users who copy their home dir (but not
their akonadi setup) to another computer? Seems too dangerous to me, for zero
gain. The korganizer in the path is historical anyhow, korganizer no longer
accesses std.ics directly, ever since akonadi 1 came into play.
--
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
From aacid at kde.org Fri Dec 23 18:26:29 2016
From: aacid at kde.org (Albert Astals Cid)
Date: Fri, 23 Dec 2016 19:26:29 +0100
Subject: [kdepim-runtime/Applications/16.12]
resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource which
failed to create std.ics if it didn't exist.
In-Reply-To: <7806444.SMD64hJD1G@asterixp50>
References: <1782871.7y7jmFglRY@tuxin>
<7806444.SMD64hJD1G@asterixp50>
Message-ID: <4094495.rKjsmaqygT@xps>
So i guess we're in agreement that we need a new tarball? Or can we just tell
distro packagers to patch it?
My issue with a new tarball is that i will need to call it 16.12.0.1 (since i
don't want to do 16.12.1 with just kderuntime-changes) and then distros are
going to complain since it has one extra version, and since it's not a whole
new release we again basically depend on distros picking up the new tarball.
So may as well just ask them to patch it in?
Cheers,
Albert
El dimarts, 20 de desembre de 2016, a les 21:24:16 CET, David Faure va
escriure:
> On mardi 20 décembre 2016 10:29:03 CET Sandro Knauß wrote:
> > Hey,
> >
> > mmh the description of your problem does not match with the commit you
> > have
> > pushed, or do i miss anything.
>
> The latter, I think ;)
>
> > Your patch is "only doing:
> > QUrl(mSettings->path()) -> QUrl::fromUserInput(mSettings->path());
> > right?
>
> Right.
>
> > that means that we still have the problem with schema prefix in the url?
>
> No, fromUserInput supports both absolute paths and URLs, see API docs.
>
> > And than mCurrentUrl.isLocalFile() is not true and you'll do not enter
> > that
> > codepath?
>
> isLocalFile() will be true for local files and false for remote URLs, I
> don't see a problem here.
>
> > Just a little bit curious, why this is only a problem for a new user?
>
> Well, anyone without a ~/.local/share/apps/korganizer/ subdir,
> which certainly includes new users.
>
> > On the other side I do not understand why the default local is import to
> > trigger this bug.
>
> Parse error at "default local is import". Can you rephrase?
>
> > Btw. if the default location for korganzier has changed, than please
> > update
> > the defaultcalendar.desktop path.
>
> And break "Personal Calendar" for all users who copy their home dir (but not
> their akonadi setup) to another computer? Seems too dangerous to me, for
> zero gain. The korganizer in the path is historical anyhow, korganizer no
> longer accesses std.ics directly, ever since akonadi 1 came into play.
From faure at kde.org Fri Dec 23 19:59:25 2016
From: faure at kde.org (David Faure)
Date: Fri, 23 Dec 2016 20:59:25 +0100
Subject: [kdepim-runtime/Applications/16.12]
resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource which
failed to create std.ics if it didn't exist.
In-Reply-To: <4094495.rKjsmaqygT@xps>
References: <7806444.SMD64hJD1G@asterixp50>
<4094495.rKjsmaqygT@xps>
Message-ID: <4545140.d1cgH4srhd@asterixp50>
On vendredi 23 décembre 2016 19:26:29 CET Albert Astals Cid wrote:
> So i guess we're in agreement that we need a new tarball? Or can we just
> tell distro packagers to patch it?
>
> My issue with a new tarball is that i will need to call it 16.12.0.1 (since
> i don't want to do 16.12.1 with just kderuntime-changes) and then distros
> are going to complain since it has one extra version, and since it's not a
> whole new release we again basically depend on distros picking up the new
> tarball.
>
> So may as well just ask them to patch it in?
I don't mind either way, ask them if they're ok with a patch ;)
--
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
From sknauss at kde.org Fri Dec 23 20:04:52 2016
From: sknauss at kde.org (Sandro =?ISO-8859-1?Q?Knau=DF?=)
Date: Fri, 23 Dec 2016 21:04:52 +0100
Subject: [kdepim-runtime/Applications/16.12]
resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource which
failed to create std.ics if it didn't exist.
In-Reply-To: <4545140.d1cgH4srhd@asterixp50>
References: <4094495.rKjsmaqygT@xps>
<4545140.d1cgH4srhd@asterixp50>
Message-ID: <2918353.mcmRY2p6PO@tuxin>
Hey,
> > So i guess we're in agreement that we need a new tarball? Or can we just
> > tell distro packagers to patch it?
jepp - either way is okay for me.
Best Reagrds,
sandro
From bcooksley at kde.org Sat Dec 24 02:05:15 2016
From: bcooksley at kde.org (Ben Cooksley)
Date: Sat, 24 Dec 2016 15:05:15 +1300
Subject: [kdepim-runtime/Applications/16.12]
resources/shared/singlefileresource:
Fix DATA LOSS bug in ical resource which failed to create std.ics if it
didn't exist.
In-Reply-To: <4094495.rKjsmaqygT@xps>
References: <1782871.7y7jmFglRY@tuxin>
<7806444.SMD64hJD1G@asterixp50> <4094495.rKjsmaqygT@xps>
Message-ID:
On Sat, Dec 24, 2016 at 7:26 AM, Albert Astals Cid wrote:
> So i guess we're in agreement that we need a new tarball? Or can we just tell
> distro packagers to patch it?
>
> My issue with a new tarball is that i will need to call it 16.12.0.1 (since i
> don't want to do 16.12.1 with just kderuntime-changes) and then distros are
> going to complain since it has one extra version, and since it's not a whole
> new release we again basically depend on distros picking up the new tarball.
Whichever one works easiest for the packagers I guess.
Considering the severity of this issue though (silent data loss) we
should probably make an advisory in about a month's time of which
distributions have failed to patch/upgrade their packages so users are
aware of the risk they are taking.
>
> So may as well just ask them to patch it in?
>
> Cheers,
> Albert
Cheers,
Ben
>
> El dimarts, 20 de desembre de 2016, a les 21:24:16 CET, David Faure va
> escriure:
>> On mardi 20 décembre 2016 10:29:03 CET Sandro Knauß wrote:
>> > Hey,
>> >
>> > mmh the description of your problem does not match with the commit you
>> > have
>> > pushed, or do i miss anything.
>>
>> The latter, I think ;)
>>
>> > Your patch is "only doing:
>> > QUrl(mSettings->path()) -> QUrl::fromUserInput(mSettings->path());
>> > right?
>>
>> Right.
>>
>> > that means that we still have the problem with schema prefix in the url?
>>
>> No, fromUserInput supports both absolute paths and URLs, see API docs.
>>
>> > And than mCurrentUrl.isLocalFile() is not true and you'll do not enter
>> > that
>> > codepath?
>>
>> isLocalFile() will be true for local files and false for remote URLs, I
>> don't see a problem here.
>>
>> > Just a little bit curious, why this is only a problem for a new user?
>>
>> Well, anyone without a ~/.local/share/apps/korganizer/ subdir,
>> which certainly includes new users.
>>
>> > On the other side I do not understand why the default local is import to
>> > trigger this bug.
>>
>> Parse error at "default local is import". Can you rephrase?
>>
>> > Btw. if the default location for korganzier has changed, than please
>> > update
>> > the defaultcalendar.desktop path.
>>
>> And break "Personal Calendar" for all users who copy their home dir (but not
>> their akonadi setup) to another computer? Seems too dangerous to me, for
>> zero gain. The korganizer in the path is historical anyhow, korganizer no
>> longer accesses std.ics directly, ever since akonadi 1 came into play.
>
>
From jr at jriddell.org Tue Dec 27 12:48:03 2016
From: jr at jriddell.org (Jonathan Riddell)
Date: Tue, 27 Dec 2016 12:48:03 +0000
Subject: Plasma 5.8.5
Message-ID:
Plasma 5.8.5 is now released https://www.kde.org/announcements/plasma-5.8.5.php
From aacid at kde.org Wed Dec 28 11:14:12 2016
From: aacid at kde.org (Albert Astals Cid)
Date: Wed, 28 Dec 2016 12:14:12 +0100
Subject: [kdepim-runtime/Applications/16.12]
resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource which
failed to create std.ics if it didn't exist.
In-Reply-To:
References: <4094495.rKjsmaqygT@xps>
Message-ID: <14547006.mbdgdMWApL@xps>
El dissabte, 24 de desembre de 2016, a les 15:05:15 CET, Ben Cooksley va
escriure:
> On Sat, Dec 24, 2016 at 7:26 AM, Albert Astals Cid wrote:
> > So i guess we're in agreement that we need a new tarball? Or can we just
> > tell distro packagers to patch it?
> >
> > My issue with a new tarball is that i will need to call it 16.12.0.1
> > (since i don't want to do 16.12.1 with just kderuntime-changes) and then
> > distros are going to complain since it has one extra version, and since
> > it's not a whole new release we again basically depend on distros picking
> > up the new tarball.
> Whichever one works easiest for the packagers I guess.
>
> Considering the severity of this issue though (silent data loss) we
> should probably make an advisory in about a month's time of which
> distributions have failed to patch/upgrade their packages so users are
> aware of the risk they are taking.
We only have security advisories AFAIK
https://www.kde.org/info/security/
What kind of advisory/way to make the world now were you thinking about?
Cheers,
Albert
>
> > So may as well just ask them to patch it in?
> >
> > Cheers,
> >
> > Albert
>
> Cheers,
> Ben
>
> > El dimarts, 20 de desembre de 2016, a les 21:24:16 CET, David Faure va
> >
> > escriure:
> >> On mardi 20 décembre 2016 10:29:03 CET Sandro Knauß wrote:
> >> > Hey,
> >> >
> >> > mmh the description of your problem does not match with the commit you
> >> > have
> >> > pushed, or do i miss anything.
> >>
> >> The latter, I think ;)
> >>
> >> > Your patch is "only doing:
> >> > QUrl(mSettings->path()) -> QUrl::fromUserInput(mSettings->path());
> >> > right?
> >>
> >> Right.
> >>
> >> > that means that we still have the problem with schema prefix in the
> >> > url?
> >>
> >> No, fromUserInput supports both absolute paths and URLs, see API docs.
> >>
> >> > And than mCurrentUrl.isLocalFile() is not true and you'll do not enter
> >> > that
> >> > codepath?
> >>
> >> isLocalFile() will be true for local files and false for remote URLs, I
> >> don't see a problem here.
> >>
> >> > Just a little bit curious, why this is only a problem for a new user?
> >>
> >> Well, anyone without a ~/.local/share/apps/korganizer/ subdir,
> >> which certainly includes new users.
> >>
> >> > On the other side I do not understand why the default local is import
> >> > to
> >> > trigger this bug.
> >>
> >> Parse error at "default local is import". Can you rephrase?
> >>
> >> > Btw. if the default location for korganzier has changed, than please
> >> > update
> >> > the defaultcalendar.desktop path.
> >>
> >> And break "Personal Calendar" for all users who copy their home dir (but
> >> not their akonadi setup) to another computer? Seems too dangerous to me,
> >> for zero gain. The korganizer in the path is historical anyhow,
> >> korganizer no longer accesses std.ics directly, ever since akonadi 1
> >> came into play.
From sknauss at kde.org Wed Dec 28 23:31:00 2016
From: sknauss at kde.org (Sandro =?ISO-8859-1?Q?Knau=DF?=)
Date: Thu, 29 Dec 2016 00:31:00 +0100
Subject: libkdav
In-Reply-To: <7488865.cTG6kGkpQy@tuxin>
References: <14819448.3HmizyNruI@tuxin> <3682462.nLaBPmAJY7@odin>
<7488865.cTG6kGkpQy@tuxin>
Message-ID: <1827080.CrBZHg2jGj@tuxin>
Hey,
We now have a new created repository named pim/kdav ( a DAV library for
GroupDAV, CalDav and CardDav). That we split out kdepim-runtime. This library
is now in ready for review. It builds already and together with hefee/dev/kdav
branch in kdepim-runtime and is a functional replacement. At the moment
kdepim-runtime is not taking any usage of kdav.
Some outlines:
everything is GPL2+
dependencies: QtCore, QtGui, QtXml and KioCore
It is planned to release kdav within 17.04. But this is not a formal mail to
add this repo to the list of released repos.
Rough future plan:
* make sure kdav compiles at CI
* merge hefee/dev/kdav branch and make sure it works with a owncloud resource
* streamline version numbers with KDEPIM & send a fromal mail to release team
to add kdav.
Some remakes:
* version number is not streamlines with KDEPIM ( this will be done if we
switch kdepim-runtime ti actually use it)
* @i18n-team: no need to copy strings to other repos, they will stay in
kdepim-runtime (but in other files)
* I don't want to put this into the KF5 namespace, because it is not a
Frameworks, and I think we as PIMsters were wrong in pushing this into that
namespace.
* CI support will come and is already requested :)
Best Regards,
sandro
--
Am Montag, 19. Dezember 2016, 12:29:03 CET schrieb Sandro Knauß:
> Hey,
>
> > > moved Akonadi parts already into own files, that can be enter into
> > > kdepim-runtime.
> >
> > Are you willing to port the dav resource to KDAV, once its released?
>
> I'll to the porrting and it will compile and work afterwards. But I will not
> do the logic change(s). I think here at the switch form QString -> DavUrl
> (see below) some function in settings could be removed are not needed
> anymore. I don't want to change the logic in settings because it has the
> potential to break the resource and I do not want to digg into the resource
> internal logic, how the QString -> DavUrl replacement is handled inside
> settings.
>
> > Yep, I certainly think making DavCollection::url() return a QUrl is the
> > right way to go.
>
> not QUrl we use DavUrl, because we also need the protocoll setting of
> DavUrl.
> > Any chance you could backport your patch to kdepim-runtime 16.12?
>
> Well this is not a bug in Applicatinos/16.12. The DAV resource it self has
> function to do the transistion:
> Settings::configuredDavUrl
> Settings::davUrlFromCollectionUrl
>
> This issue only one, because I create a seperate library, that should be
> self contained. For Applications/16.12 it is only a not nice logic
> seperation...
>
> Best Regards,
>
> sandro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL:
From montel at kde.org Thu Dec 29 05:57:01 2016
From: montel at kde.org (laurent Montel)
Date: Thu, 29 Dec 2016 06:57:01 +0100
Subject: libkdav
In-Reply-To: <1827080.CrBZHg2jGj@tuxin>
References: <14819448.3HmizyNruI@tuxin> <7488865.cTG6kGkpQy@tuxin>
<1827080.CrBZHg2jGj@tuxin>
Message-ID: <7099067.Ho2AmuCX7h@linux-5nvn>
Hi,
You still install export fileinclude in /include/KF5/libkdav_version.h
You still create a KF5:: namespaced lib "Add_library(KF5::kdav SHARED
IMPORTED)"
You generate pri file with
ecm_generate_pri_file(BASE_NAME kdav
LIB_NAME kdav
FILENAME_VAR PRI_FILENAME INCLUDE_INSTALL_DIR $
{KDE_INSTALL_INCLUDEDIR_KF5}/KDAV
)
Toplevel CmakeList needs cleanup
############### KDEPIM-Runtime version ################
# KDEPIM_RUNTIME_VERSION
# Version scheme: "x.y.z build".
#
# x is the version number.
# y is the major release number.
# z is the minor release number.
#
# "x.y.z" follow the kdelibs version kdepim is released with.
#
# If "z" is 0, it the version is "x.y"
#
# KDEPIM_RUNTIME_DEV_VERSION
# is empty for final versions. For development versions "build" is
# something like "pre", "alpha1", "alpha2", "beta1", "beta2", "rc1", "rc2".
#
# Examples in chronological order:
#
# 3.0
# 3.0.1
# 3.1 alpha1
# 3.1 beta1
# 3.1 beta2
# 3.1 rc1
# 3.1
# 3.1.1
# 3.2 pre
# 3.2 alpha1
And
set(CMAKE_MODULE_PATH ${kdepim-runtime_SOURCE_DIR}/cmake/modules $
{ECM_MODULE_PATH})
I can't see an autotest directory ? I think that it will good to have some
autotest for a lib.
Regards
Le jeudi 29 décembre 2016, 00:31:00 CET Sandro Knauß a écrit :
> Hey,
>
> We now have a new created repository named pim/kdav ( a DAV library for
> GroupDAV, CalDav and CardDav). That we split out kdepim-runtime. This
> library is now in ready for review. It builds already and together with
> hefee/dev/kdav branch in kdepim-runtime and is a functional replacement. At
> the moment kdepim-runtime is not taking any usage of kdav.
>
> Some outlines:
> everything is GPL2+
> dependencies: QtCore, QtGui, QtXml and KioCore
>
> It is planned to release kdav within 17.04. But this is not a formal mail to
> add this repo to the list of released repos.
>
> Rough future plan:
> * make sure kdav compiles at CI
> * merge hefee/dev/kdav branch and make sure it works with a owncloud
> resource * streamline version numbers with KDEPIM & send a fromal mail to
> release team to add kdav.
>
> Some remakes:
> * version number is not streamlines with KDEPIM ( this will be done if we
> switch kdepim-runtime ti actually use it)
> * @i18n-team: no need to copy strings to other repos, they will stay in
> kdepim-runtime (but in other files)
> * I don't want to put this into the KF5 namespace, because it is not a
> Frameworks, and I think we as PIMsters were wrong in pushing this into that
> namespace.
> * CI support will come and is already requested :)
>
> Best Regards,
>
> sandro
>
> --
>
> Am Montag, 19. Dezember 2016, 12:29:03 CET schrieb Sandro Knauß:
> > Hey,
> >
> > > > moved Akonadi parts already into own files, that can be enter into
> > > > kdepim-runtime.
> > >
> > > Are you willing to port the dav resource to KDAV, once its released?
> >
> > I'll to the porrting and it will compile and work afterwards. But I will
> > not do the logic change(s). I think here at the switch form QString ->
> > DavUrl (see below) some function in settings could be removed are not
> > needed anymore. I don't want to change the logic in settings because it
> > has the potential to break the resource and I do not want to digg into
> > the resource internal logic, how the QString -> DavUrl replacement is
> > handled inside settings.
> >
> > > Yep, I certainly think making DavCollection::url() return a QUrl is the
> > > right way to go.
> >
> > not QUrl we use DavUrl, because we also need the protocoll setting of
> > DavUrl.
> >
> > > Any chance you could backport your patch to kdepim-runtime 16.12?
> >
> > Well this is not a bug in Applicatinos/16.12. The DAV resource it self has
> > function to do the transistion:
> > Settings::configuredDavUrl
> > Settings::davUrlFromCollectionUrl
> >
> > This issue only one, because I create a seperate library, that should be
> > self contained. For Applications/16.12 it is only a not nice logic
> > seperation...
> >
> > Best Regards,
> >
> > sandro
--
Laurent Montel | laurent.montel at 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,
www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent
software solutions
From bcooksley at kde.org Fri Dec 30 05:36:51 2016
From: bcooksley at kde.org (Ben Cooksley)
Date: Fri, 30 Dec 2016 18:36:51 +1300
Subject: [kdepim-runtime/Applications/16.12]
resources/shared/singlefileresource:
Fix DATA LOSS bug in ical resource which failed to create std.ics if it
didn't exist.
In-Reply-To: <14547006.mbdgdMWApL@xps>
References: <4094495.rKjsmaqygT@xps>
<14547006.mbdgdMWApL@xps>
Message-ID:
On Thu, Dec 29, 2016 at 12:14 AM, Albert Astals Cid wrote:
> El dissabte, 24 de desembre de 2016, a les 15:05:15 CET, Ben Cooksley va
> escriure:
>> On Sat, Dec 24, 2016 at 7:26 AM, Albert Astals Cid wrote:
>> > So i guess we're in agreement that we need a new tarball? Or can we just
>> > tell distro packagers to patch it?
>> >
>> > My issue with a new tarball is that i will need to call it 16.12.0.1
>> > (since i don't want to do 16.12.1 with just kderuntime-changes) and then
>> > distros are going to complain since it has one extra version, and since
>> > it's not a whole new release we again basically depend on distros picking
>> > up the new tarball.
>> Whichever one works easiest for the packagers I guess.
>>
>> Considering the severity of this issue though (silent data loss) we
>> should probably make an advisory in about a month's time of which
>> distributions have failed to patch/upgrade their packages so users are
>> aware of the risk they are taking.
>
> We only have security advisories AFAIK
> https://www.kde.org/info/security/
>
> What kind of advisory/way to make the world now were you thinking about?
A press release of some description would do the job I think.
I'll admit i'm not sure of the form it should take though.
>
> Cheers,
> Albert
Cheers,
Ben
>
>>
>> > So may as well just ask them to patch it in?
>> >
>> > Cheers,
>> >
>> > Albert
>>
>> Cheers,
>> Ben
>>
>> > El dimarts, 20 de desembre de 2016, a les 21:24:16 CET, David Faure va
>> >
>> > escriure:
>> >> On mardi 20 décembre 2016 10:29:03 CET Sandro Knauß wrote:
>> >> > Hey,
>> >> >
>> >> > mmh the description of your problem does not match with the commit you
>> >> > have
>> >> > pushed, or do i miss anything.
>> >>
>> >> The latter, I think ;)
>> >>
>> >> > Your patch is "only doing:
>> >> > QUrl(mSettings->path()) -> QUrl::fromUserInput(mSettings->path());
>> >> > right?
>> >>
>> >> Right.
>> >>
>> >> > that means that we still have the problem with schema prefix in the
>> >> > url?
>> >>
>> >> No, fromUserInput supports both absolute paths and URLs, see API docs.
>> >>
>> >> > And than mCurrentUrl.isLocalFile() is not true and you'll do not enter
>> >> > that
>> >> > codepath?
>> >>
>> >> isLocalFile() will be true for local files and false for remote URLs, I
>> >> don't see a problem here.
>> >>
>> >> > Just a little bit curious, why this is only a problem for a new user?
>> >>
>> >> Well, anyone without a ~/.local/share/apps/korganizer/ subdir,
>> >> which certainly includes new users.
>> >>
>> >> > On the other side I do not understand why the default local is import
>> >> > to
>> >> > trigger this bug.
>> >>
>> >> Parse error at "default local is import". Can you rephrase?
>> >>
>> >> > Btw. if the default location for korganzier has changed, than please
>> >> > update
>> >> > the defaultcalendar.desktop path.
>> >>
>> >> And break "Personal Calendar" for all users who copy their home dir (but
>> >> not their akonadi setup) to another computer? Seems too dangerous to me,
>> >> for zero gain. The korganizer in the path is historical anyhow,
>> >> korganizer no longer accesses std.ics directly, ever since akonadi 1
>> >> came into play.
>
>