Re: Review Request: plasma-thunderbolt

2019-05-16 Thread Daniel Vrátil
On Wednesday, 15 May 2019 23:08:57 CEST Albert Astals Cid wrote:
> El dimecres, 15 de maig de 2019, a les 15:27:07 CEST, Daniel Vrátil va 
escriure:
> > Hi all,
> > 
> > plasma-thunderbolt is a new repo containing, you guessed it, Thunderbolt
> > KCM for Plasma. I initially submitted the code as a patch against
> > plasma-desktop [0], where it got reviewed, but it was ultimately decided
> > to better put it into a separate repository, since it's not just a KCM
> > but also a library and a KDED module. I have backported all the changes
> > from the Phabricator review back to the repository, so the code in the
> > repo is identical to the one in the Phab review (minus buildsystem
> > changes and a small build fix for clang).
> > 
> > However, since this is still a new code, it must formally pass through
> > kdereview before I can submit it into Plasma as a new module.
> > 
> > Thus I'd kindly ask you to take one more look at the codebase [1] and let
> > me know if there are any more issues to fix, or if we can proceed to
> > include this in the next Plasma release.
> 
> There's this cmake warning
> 
> CMake Warning at /usr/lib64/cmake/KF5Package/KF5PackageMacros.cmake:74
> (message): KPackage components should be specified in reverse domain
> notation. Appstream information won't be generated for kcm_bolt.
> Call Stack (most recent call first):
>   src/kcm/CMakeLists.txt:22 (kpackage_install_package)

I need some help with this - I looked into plasma-desktop, but all KCMs 
generate this warning and after renaming the package I just wasn't able to 
pair it with the library (which makes not sense to be called 
org.kde.plasma.thunderbolt.so) - so for now I'd just ignore the warning (we 
don't need Appstream data for KCM anyway, do we?).

> clazy complains about a few Q_PROPERTY that should ideally either have a
> NOTIFY signal or be marked as CONSTANT

I fixed the ones in the code, I can't fix the ones in the generated DBus 
interfaces and adaptors.


> it also complains about a few const slots that return values. Seems like
> what you want is to actually mark them as invokable/scriptable and not as
> slots?

Good point, fixed those.

Thanks for the review,
Dan

> 
> Cheers,
>   Albert
> 
> > Thanks,
> > - Dan
> > 
> > [0] https://phabricator.kde.org/D19011
> > [1] https://cgit.kde.org/plasma-thunderbolt.git


-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683

signature.asc
Description: This is a digitally signed message part.


Re: Review Request: plasma-thunderbolt

2019-05-16 Thread Daniel Vrátil
On Wednesday, 15 May 2019 15:55:01 CEST Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 15. Mai 2019, 15:27:07 CEST schrieb Daniel Vrátil:
> > Thus I'd kindly ask you to take one more look at the codebase [1] and let
> > me know if there are any more issues to fix, or if we can proceed to
> > include this in the next Plasma release.
> 
> Pushed some small fixes to toplevel CMakeLists.txt
> 
> Other things seen on quick look at code (also not tested runtime):
> * kded misses a Messages.sh file.
> * no COPYRIGHT license files in the repo
> * kde_enable_exceptions() duplicated a few times, perhaps only do in subdirs
> where needed or use of kde_target_enable_exceptions() if fitting
> * libkbolt being a private library could be reflected in the libname, also
> get install(TARGETS kbolt ${KDE_INSTALL_TARGETS_DEFAULT_ARGS} LIBRARY
> NAMELINK_SKIP)

All fixed, thanks for the review (and the fixes)!

Dan

> 
> Cheers
> Friedrich


-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683

signature.asc
Description: This is a digitally signed message part.


Re: Review Request: plasma-thunderbolt

2019-05-16 Thread Daniel Vrátil
On Wednesday, 15 May 2019 15:34:58 CEST Nate Graham wrote:
> +1 from me; the original was good and this looks good too.
> 
> One minor thing that I don't think should be a blocker: Could we copy
> FindBolt.cmake into ECM with an eye towards not needing it here in a
> future release?

I think having FindBolt in ECM makes sense if there's a chance that some other 
components will use it. Right now I don't think anyone else is going to look 
for the Bolt daemon (as a runtime dependency).

Dan

> 
> Nate
> 
> On 5/15/19 7:27 AM, Daniel Vrátil wrote:
> > Hi all,
> > 
> > plasma-thunderbolt is a new repo containing, you guessed it, Thunderbolt
> > KCM for Plasma. I initially submitted the code as a patch against
> > plasma-desktop [0], where it got reviewed, but it was ultimately decided
> > to better put it into a separate repository, since it's not just a KCM
> > but also a library and a KDED module. I have backported all the changes
> > from the Phabricator review back to the repository, so the code in the
> > repo is identical to the one in the Phab review (minus buildsystem
> > changes and a small build fix for clang).
> > 
> > However, since this is still a new code, it must formally pass through
> > kdereview before I can submit it into Plasma as a new module.
> > 
> > Thus I'd kindly ask you to take one more look at the codebase [1] and let
> > me know if there are any more issues to fix, or if we can proceed to
> > include this in the next Plasma release.
> > 
> > Thanks,
> > - Dan
> > 
> > [0] https://phabricator.kde.org/D19011
> > [1] https://cgit.kde.org/plasma-thunderbolt.git


-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683

signature.asc
Description: This is a digitally signed message part.


Review Request: plasma-thunderbolt

2019-05-15 Thread Daniel Vrátil
Hi all,

plasma-thunderbolt is a new repo containing, you guessed it, Thunderbolt KCM 
for Plasma. I initially submitted the code as a patch against plasma-desktop 
[0], where it got reviewed, but it was ultimately decided to better put it 
into a separate repository, since it's not just a KCM but also a library and a 
KDED module. I have backported all the changes from the Phabricator review 
back to the repository, so the code in the repo is identical to the one in the 
Phab review (minus buildsystem changes and a small build fix for clang).

However, since this is still a new code, it must formally pass through 
kdereview before I can submit it into Plasma as a new module.

Thus I'd kindly ask you to take one more look at the codebase [1] and let me 
know if there are any more issues to fix, or if we can proceed to include this 
in the next Plasma release.

Thanks,
- Dan

[0] https://phabricator.kde.org/D19011
[1] https://cgit.kde.org/plasma-thunderbolt.git

-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683

signature.asc
Description: This is a digitally signed message part.


Re: CI system maintainability

2019-03-28 Thread Daniel Vrátil
On Thursday, March 28, 2019 3:39:54 PM CET Friedrich W. H. Kossebau wrote:
> Am Donnerstag, 28. März 2019, 11:27:44 CET schrieb Daniel Vrátil:
> > I'm completely fine with mandatory code review for everything and I'd be
> > happy to have this in PIM. I think the biggest problem in PIM to overcome
> > will be finding the reviewers - I dare say I'm currently the only one who
> > has at least a little idea about what's going on in Akonadi, so getting
> > for
> > instance Laurent to review my Akonadi patches might be hard - same for me
> > reviewing Laurent's KMail patches. This will require non-trivial amount of
> > effort for all members of the community to gain deeper understanding of
> > the
> > other components within the project and a willingness to step up and do a
> > code review even if they don't feel 100% comfortable with the code base.
> > But I believe that in the long run the benefits clearly out-weight the
> > cost.
> So why do you not do this already? Why would you only do this is there is a
> policy requiring you to do it?
> And why do you think this policy-driven behavioural change will work or is
> needed with everyone else?

I wrote this with my PIM hat on and targeted the PIM community, without 
realizing this is a cross-post, so I apologize for the confusion. I believe 
each project should choose whatever workflow and policy suits them.

That said, I do put up for review everything that is not Akonadi/PIM core 
(even changes to PIM components that are not "mine"). The reason I don't do 
this for Akonadi is that there's no-one really to review my code, because no-
one else works on it, or at least that has been my perception of the situation 
lately.

I've been thinking about bringing this topic up on the upcoming PIM sprint as 
I would like to have my code reviewed, I think it's a very good and healthy 
thing, but in case of KDE PIM, I think we need to agree that we'll actually 
review each others code, even if it's not "our own" code-base.

> Also, how do you ensure the review is actually of quality?

How do you ensure that the code people commit without a review is of quality?

> And not just socially driven "+1 for my buddie!", where buddy then also
> mentally shifts part of responsibility to other buddy, because, he, more
> eyes means I do not need to do the full work myself, glitches will be
> caught be them surely! Reviewer found a code formatting issue, done here,
> review happened.

This is a fair point, and I certainly am guilty of doing this occasionally in 
the past. But even reviewer can have a reviewer: if you keep accepting patches 
of "dubious quality" (break build, don't work, contain typos ...), someone 
else from the community will eventually notice and point out you should maybe 
be more careful with your reviews or pay attention to certain aspects (like 
"does it actually work?).

> The opposite also has been seen, reviewers feel they need to do "real"
> review and find things, so start to nitpick or to demand wrong changes,
> wasting everyone's time.
> 
> For myself I know I will happily have other people review my patches, but
> only if there are qualified people to be expected to do it with the needed
> quality in a reasonable time.
> 
> Then, trying to force by that policy other people to become proper
> specialist for certain other code projects to do qualified reviews,
> actually is a trade- off. They will have less time for their actual code
> project, becoming less a specialist there (or having time to review other
> people's contribution to that project).
> We need more contributors, not force existing contributors to distribute
> their abilities & resources over more projects (and thus having less for
> their actual one).

AFAIU the policy right now is keep putting up patches for review until you get 
commit access, then continue doing so until you feel like you don't have to 
anymore. 

But having experienced contributors putting up their code for review is a good 
thing as it allows newcomers (and not just them!) to better understand what is 
happening in the project and simple reviews can be a good starting point for 
them to get more involved in the community.

> I am also not aware of many contributors to KDE projects who are not capable
> to make a responsible decision between the few obvious simple fixes and
> those normal changes which better get feedback from others first. If one is
> unsure about one's post-beer late-night quick hack, one will upload it for
> review, no? At least if one's previous late-night commits turned out to be
> late-night mental state impacted.

This I think is somewhat related to the tooling as I said

Re: CI system maintainability

2019-03-28 Thread Daniel Vrátil
On Thursday, March 28, 2019 9:50:47 AM CET Kevin Ottens wrote:
> Hello,
> 
> On Thursday, 28 March 2019 09:41:29 CET Luca Beltrame wrote:
> > In data giovedì 28 marzo 2019 09:29:22 CET, Kevin Ottens ha scritto:
> > > at your screen or pair with you" in the past. Clearly this compromise
> > > gets
> > > somewhat exploited and that's especially bad in the case of a fragile
> > > and
> > > central component like KDE PIM.
> > 
> > I'm not sure I agree. I can't speak for seasoned developers, but I've
> > found
> > myself in a situation (more than once) where the fix is trivial (compile
> > error, missing ";", etc) and being forced to go through review would (IMO)
> > unnecessarily raise friction.

This is partially a problem of tooling IMO - review for even a trivial change 
will not cause any friction, if the tooling makes it super-easy and natural 
part of your workflow (and then you can always poke someone on IRC "hey, do 
you have 5 seconds for this super-simple review?").

Using arc with Phab is a bit annoying, so I can understand people fighting 
this. Gitlab with their "click this link to turn your commit into a merge 
request" is much better, plus it can be merged by the reviewer with a single 
click so you as a developer don't even need to care about the MR anymore.

> I don't fully disagree with this (although I'd have stories on nefarious
> typos even for what was supposed to be a "trivial fix"). But it becomes a
> question of trade-off, IOW "how hurtful to the project mandatory reviews?"
> vs "how hurtful to the project a central component being very regularly
> broken?".
> 
> I'd argue we're loosing more with the current state of PIM than we'd loose
> with mandatory reviews.

I'm completely fine with mandatory code review for everything and I'd be happy 
to have this in PIM. I think the biggest problem in PIM to overcome will be 
finding the reviewers - I dare say I'm currently the only one who has at least 
a little idea about what's going on in Akonadi, so getting for instance 
Laurent to review my Akonadi patches might be hard - same for me reviewing 
Laurent's KMail patches. This will require non-trivial amount of effort for 
all members of the community to gain deeper understanding of the other 
components within the project and a willingness to step up and do a code 
review even if they don't feel 100% comfortable with the code base. But I 
believe that in the long run the benefits clearly out-weight the cost.

Btw we practice this policy at work and I do truly appreciate it, not only as 
a huge learning experience but so many times just having a second pair of eyes 
to glance over my code has revealed issues that sometimes almost make me 
question my career choice as a programmer :-) I think this is especially 
important for projects like PIM, where most of us contribute at work in 
between waiting for CI and replying to 15 Slack threads or in the evening 
after a long day

Cao,
Dan

> Regards.


-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683

signature.asc
Description: This is a digitally signed message part.


Re: Review request: plasma-pass

2019-01-04 Thread Daniel Vrátil
Hi Albert,

thanks for the review! All the issues you mentioned are fixed in master now.

Dan


On Sunday, 16 December 2018 20:14:37 CET Albert Astals Cid wrote:
> El dilluns, 10 de desembre de 2018, a les 14:49:28 CET, Daniel Vrátil va 
escriure:
> > Hi folks,
> > 
> > back in May I wrote a Plasma applet that serves as a GUI frontend for the
> > pass password manager [0]. I blogged about it [1], but then somewhat
> > forgot to make a release etc. Recently I started getting some emails from
> > packagers where to get a tarballs so I think it's time to get some
> > translations in and start doing official releases. Thus I'd like to ask
> > for a review for inclusion in extragear.
> > 
> > The way pass works is it has a directory in which each password is stored
> > in a PGP-encrypted file, the name of the file is the name of the
> > password. You can also create subfolders to organize the passwords.
> > 
> > The code of the applet is a C++ model that watches said directory and
> > exposes its content as a tree. There's also a filter proxy model which
> > uses partial string matching code from KDevelop (so you can filter for
> > "jd@f" and it matches "john@fmail.com").
> > 
> > The applet itself sits in systray, when activated it shows the top-level
> > list of folders and password. Code-wise it contains a stack of list
> > views, when entering a subfolder it pushes a new listview with content of
> > that folder to the stack. Selecting a password decrypts it using gpg and
> > puts it into clipboard for 45 seconds. After that it clears it from the X
> > clipboard as well as Klipper.
> > 
> > There's a bit of mess regarding focus handling in the QML, but the goal
> > was to make the applet fully controllable via keyboard, which wasn't easy
> > with my QML skills :)
> 
> You have
> 
> plasma-pass:master$ wcgrep X-KDE-PluginInfo-Name
> ./package/metadata.desktop:27:X-KDE-PluginInfo-Name=plasmapass
> ./package/metadata.desktop:34:X-KDE-PluginInfo-Name=org.kde.plasma.pass
> 
> Which one is it? I guess the second? Then you also need to update your
> Messages.sh to match that one if you change it, see applets/colorpicker in
> kdeplasma-addons for example
> 
> 
> You're using old style connects, use the power of the "new one".
> 
> 
> PlasmaPass::PasswordsModel::Node has dtor but not copy-ctor,
> copy-assignment. Which means that if someone ever does PasswordsModel::Node
> a;
>  PasswordsModel::Node b = a;
> things will break since the default implementations will just copy the
> children vector and bad things will happen, i suggest you delete the copy
> and assignment functions.
> 
> 
> filterChanged is already a name of an existing function on
> QSortFilterProxyModel (i know sucks), so maybe you could rename that signal
> to something else? I guess this is not very important though but some
> people may get confused when reading the code.
> 
> 
> In the QML side you do a few == != that would be 0.001% faster doing
> === and !==, it's considered better JS code since "weird" promotions are
> not done, but your call.
> 
> 
> I have not actually tested whether the thing works or not, but it's small
> enough that i guess it does :D
> 
> Just had time for this quick code review, hope you find it useful :)
> 
> Cheers,
>   Albert
> 
> > Looking forward to your feedback,
> > Dan
> > 
> > 
> > [0] https://www.passwordstore.org/
> > [1] https://www.dvratil.cz/2018/05/plasma-pass/


-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683

signature.asc
Description: This is a digitally signed message part.


Review request: plasma-pass

2018-12-10 Thread Daniel Vrátil
Hi folks,

back in May I wrote a Plasma applet that serves as a GUI frontend for the pass 
password manager [0]. I blogged about it [1], but then somewhat forgot to make 
a release etc. Recently I started getting some emails from packagers where to 
get a tarballs so I think it's time to get some translations in and start 
doing official releases. Thus I'd like to ask for a review for inclusion in 
extragear.

The way pass works is it has a directory in which each password is stored in a 
PGP-encrypted file, the name of the file is the name of the password. You can 
also create subfolders to organize the passwords.

The code of the applet is a C++ model that watches said directory and exposes 
its content as a tree. There's also a filter proxy model which uses partial 
string matching code from KDevelop (so you can filter for "jd@f" and it 
matches "john@fmail.com").
 
The applet itself sits in systray, when activated it shows the top-level list 
of folders and password. Code-wise it contains a stack of list views, when 
entering a subfolder it pushes a new listview with content of that folder to 
the stack. Selecting a password decrypts it using gpg and puts it into 
clipboard for 45 seconds. After that it clears it from the X clipboard as well 
as Klipper.

There's a bit of mess regarding focus handling in the QML, but the goal was to 
make the applet fully controllable via keyboard, which wasn't easy with my  
QML skills :) 


Looking forward to your feedback,
Dan


[0] https://www.passwordstore.org/
[1] https://www.dvratil.cz/2018/05/plasma-pass/

-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683

signature.asc
Description: This is a digitally signed message part.


Re: kdereview: ksmtp

2017-05-30 Thread Daniel Vrátil
Hi Rolf,

thanks for the review, sorry it took me so long to get to you.

On Tuesday, May 16, 2017 8:05:17 PM CEST Rolf Eike Beer wrote:
> Am Donnerstag, 11. Mai 2017, 17:03:01 schrieb Daniel Vrátil:
> > Hi,
> > 
> > please review ksmtp, which is now in kdereview.
> 
> -the CMakeLists.txt has a mix of spaces inside () or not

Fixed

> 
> -in loginjob, line 173, you check for code 25. Should this be 250? Or is
> that 25*? Where is ServerResponse actually defined, I only see the header.

ServerResponse is defined in sessionthread.cpp for some reason. 
ServerResponse::isCode() indeed checks the prefix of the response, so 
isCode(25) returns true for any 25x return code.

> -does that support pipelining? I don't see any sync points, so I guess not.

Not yet, but it's next on the todo list.

> -there is a longstanding bug in KMail that it violates the RfC when it has a
> problem with authentication (e.g. password rejected), that is does not
> properly QUIT the SMTP session, but just closes the socket. Is that
> properly handled?

It is properly handled now. Calling Session::quit() does not close the 
connection but sends QUIT command and only closes the connection after a 
response arrives from the server (unless the server closes it first of course). 
It's now up to the user to ensure that the Session object is not destroyed 
until the state changes to Disconnected after calling Session::quit().

Dan

> 
> Greetings,
> 
> Eike


-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683

signature.asc
Description: This is a digitally signed message part.


Re: kdereview: ksmtp

2017-05-13 Thread Daniel Vrátil
On Thursday, May 11, 2017 11:11:11 PM CEST Albert Astals Cid wrote:
> El dijous, 11 de maig de 2017, a les 17:03:01 CEST, Daniel Vrátil va 
escriure:
> > Hi,
> > 
> > please review ksmtp, which is now in kdereview.
> 
> Are tests supposed to pass?
> 
> 2: QFATAL : SmtpTest::testLoginJob(Plain auth ok) Received signal 11

Hmm, it passes here. Must be some timing issue. I'll see if I can reproduce it 
on my other system.

Dan


> 
> Cheers,
>   Albert
> 
> > KSMTP is a small simple library with a KJob-based API similar to KIMAP or
> > KDAV to send mime messages via SMTP. It was initially written in 2011 by
> > Gregory Schlomoff but since then it's been lying around in playground
> > without any interest or use. I have recently picked it up, ported to
> > Frameworks and improved the job handling and authentication to make the
> > library ussable for KDE PIM and would like to have it released as part of
> > KDE Applications 17.08.
> > 
> > KDE PIM currently uses a custom KIO Slave to send messages via SMTP, which
> > is hard to maintain and extend. Having a Job-based library like KSmtp will
> > make it much easier for us to introduce support for example for Google
> > XOAUTH2 authentication mechanism.
> > 
> > Thanks,
> > Dan


-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

signature.asc
Description: This is a digitally signed message part.


Re: kdereview: ksmtp

2017-05-11 Thread Daniel Vrátil
Thanks, totally forgot to run clazy/krazy on the codebase.

On Thursday, May 11, 2017 10:25:36 PM CEST Allen Winter wrote:
> ran clazy level2 . no hits
> 
> ran krazy checks and it found:
> . Check for C++ ctors that should be declared 'explicit' [explicit]... 1
> issue found ./autotests/fakeserver.h: line#36 (1)

Fixed

> 
> . Check for normalized SIGNAL and SLOT signatures [normalize]... 4 issues
> found ./src/session.cpp: SIGNALS: line#285,286 (2)
> ./src/session.cpp: SLOTS: line#285,286 (2)

Fixed (converted to the new connect() syntax)

> . Check for strings used improperly or should be i18n. [strings]... 5 issues
> found ./autotests/fakeserver.cpp: QLatin1String issues
> line#172,175,190,201,218 (5)

Those are false positives. I guess krazy assumes .startsWith() to be 
QString::startsWith(), while those are QByteArray::startsWith().

Dan

> On Thursday, May 11, 2017 11:03:01 AM EDT Daniel Vrátil wrote:
> > Hi,
> > 
> > please review ksmtp, which is now in kdereview.
> > 
> > KSMTP is a small simple library with a KJob-based API similar to KIMAP or
> > KDAV to send mime messages via SMTP. It was initially written in 2011 by
> > Gregory Schlomoff but since then it's been lying around in playground
> > without any interest or use. I have recently picked it up, ported to
> > Frameworks and improved the job handling and authentication to make the
> > library ussable for KDE PIM and would like to have it released as part of
> > KDE Applications 17.08.
> > 
> > KDE PIM currently uses a custom KIO Slave to send messages via SMTP, which
> > is hard to maintain and extend. Having a Job-based library like KSmtp
> > will make it much easier for us to introduce support for example for
> > Google XOAUTH2 authentication mechanism.
> > 
> > Thanks,
> > Dan


-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683

signature.asc
Description: This is a digitally signed message part.


kdereview: ksmtp

2017-05-11 Thread Daniel Vrátil
Hi,

please review ksmtp, which is now in kdereview.

KSMTP is a small simple library with a KJob-based API similar to KIMAP or KDAV 
to send mime messages via SMTP. It was initially written in 2011 by Gregory 
Schlomoff but since then it's been lying around in playground without any 
interest or use. I have recently picked it up, ported to Frameworks and 
improved the job handling and authentication to make the library ussable for 
KDE PIM and would like to have it released as part of KDE Applications 17.08.

KDE PIM currently uses a custom KIO Slave to send messages via SMTP, which is 
hard to maintain and extend. Having a Job-based library like KSmtp will make 
it much easier for us to introduce support for example for Google XOAUTH2 
authentication mechanism.

Thanks,
Dan

-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

signature.asc
Description: This is a digitally signed message part.


Re: RFC: KDE Bugzilla Bugs Expiration

2015-07-31 Thread Daniel Vrátil
On Friday, July 31, 2015 09:55:30 PM Thomas Lübking wrote:
> On Freitag, 31. Juli 2015 19:29:53 CEST, Ingo Klöcker wrote:
> > I also do not see the point in nagging the user after a certain period of
> > time if nobody else ever cared to comment on the bug. Feels a bit like
> > little kids asking "Are we there yet?" over and over again.
> 
> The idea is not only to get rid of cruft (bugs which "auto-fixed" either
> implicitly by eg. code cleanups or as dupes) but also to remind developers
> by resubmission (eg. when a bug fell off the table during high activity
> periods)
> > I do see the point in Daniel's proposal because the time a release goes
> > EOL
> > feels like a sensible point in time for asking whether the bug still
> > exists.
> - when do "unspecified" version bugs EOL?

"Unspecified" version is IMO a silly thing in the first place. How is 
developer supposed to fix a bug if he does not know what version it happens 
with? I can see the point of it for wishes, but there I think it was agreed 
above that auto-closing should not affect those.

> - when do "git" version bugs EOL?

Hmm, good question. Maybe when a new version is released, all "git" bug 
reports should be moved to that version?

> - what defines EOL? supported versions in bugzilla?

Could be. That of course assumes someone maintains the list.

> - What if a user reports a bug against a version that turns EOL next week?

Then either the bug can be reproduced in newer version too and should be 
reassigned, or it has already been fixed and will be closed. If your concern 
is that the bug report would not get the "about to go EOL" notification, I see 
two ways:
1) there's a bot watching for new bugs and it will add the "this 
version is 
about to go EOL on $data" comment automatically,
2) or we explain the situation again in the final closing comment so 
that 
users know they still can reassign to newer version and reopen

> - Do we want bugs to be forgotton for 3 years or more and then tell the
> reporter: "we're now dropping support, sorry that nobody ever cared. if you
> want this to go unnoticed for another three years, please reopen the bug"?
> 
> A friendly reminder for user and developer (eg. until the bug could be
> CONFIRMED) to keep bugreports alive seems the better - and half a year is
> not exactly "nagging", but will also typically cross many distro updates.

I like the idea of a nag and I don't think it necesarily conflicts with the 
ideas above. Having a weekly/bi-weekly nags to developers would IMO work 
("hey, you have 10 new bugs this week that you did not comment on or confirmed 
yet, please look at them asap").  If the developer ignores the bugs even after 
that then it becomes a different problem, but that I don't know how to solve.

Dan

> 
> Cheers,
> Thomas

-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683

signature.asc
Description: This is a digitally signed message part.


Re: RFC: KDE Bugzilla Bugs Expiration

2015-07-31 Thread Daniel Vrátil
On Friday, July 31, 2015 10:12:00 AM Christoph Cullmann wrote:
> Hi,
> 
> I think one of the problems with our current Bugzilla database is that it
> contains a lot of "old" bugs and wishs.

True that!

> 
> As the manpower is limited and we sometimes not even keep up with the
> incoming new bugs, might it be a good idea to adopt a similar strategy like
> the Qt Project and expire bugs that got not changed since more than one
> year?
> 
> The idea would that a scripts closes all bugs that have no activity in the
> last year e.g. on a weekly basis and the closing comment would contain some
> gentle note that if the bug is still an issue, the reporter (or any person
> on CC) can just reopen it again.

We were actually discussing something similar for KDE PIM but our idea was 
based on Fedora, i.e. closing all bugs for given release when the release goes 
EOL. There is a comment added by a bot 3 weeks before EOL stating that the 
release will go EOL and if user thinks the bug is still valid in newer/current 
release, they should re-assign to newer release. When the release actually 
goes EOL all bugs still assigned to it are closed. The advantage of this 
approach IMO is that it also clears out bugs where the reporters are no longer 
available/willing to provide additional info to devs and at the same time 
without losing bugs which might be important yet non-trivial to fix (read: 
take more than a year for a dev to get there).

Especially for KDE PIM, given the size of the userbase and the amount of 
developers (3), bugs often take more than a year to get to and to be fixed.

> I think this would make a lot of time consuming bug triaging much easier.

Cannot agree more  :)


Cheers,
Daniel


> 
> Greetings
> Christoph

-- 
Daniel Vrátil
Email: dvra...@kde.org
Jabber: dan.vra...@kdetalk.net
IRC: dvratil on Freenode (#kde, #kontact, #akonadi)


Re: Moving akonadi from kdesupport and akonadi-search from playground

2015-07-24 Thread Daniel Vrátil
On Friday, July 24, 2015 10:24:10 AM laurent Montel wrote:
> Le Friday 24 July 2015, 00:13:48 Albert Astals Cid a écrit :
> > El Dimarts, 21 de juliol de 2015, a les 13:52:01, Daniel Vrátil va 
escriure:
> > > On Monday, July 20, 2015 04:17:16 PM Daniel Vrátil wrote:
> > > > 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.
> > > 
> > > Hi all,
> > > 
> > > if there are no objections, I'll request the repos to be move later in
> > > the
> > > afternoon.
> > 
> > Please let's get this done and end this painful release asap.
> 
> I don't know why it did not do it yet.
> 
> Dan ask it 2 days ago but no news.
> 
> I don't know why it was not done yet.
> 
> Regards

The repositories have been moved (thanks Ben!) and I have notified release 
team about what repos we want to release.

Thanks to everyone, and sorry for the noise we caused :)

Cheers,
Daniel

> 
> > Albert
> > 
> > > Thanks,
> > > Dan
> > > 
> > > > Cheers,
> > > > Daniel

-- 
Daniel Vrátil
Email: dvra...@kde.org
Jabber: dan.vra...@kdetalk.net
IRC: dvratil on Freenode (#kde, #kontact, #akonadi)


Re: Moving akonadi from kdesupport and akonadi-search from playground

2015-07-21 Thread Daniel Vrátil
On Monday, July 20, 2015 04:17:16 PM Daniel Vrátil wrote:
> 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.

Hi all,

if there are no objections, I'll request the repos to be move later in the 
afternoon.

Thanks, 
Dan


> 
> Cheers,
> Daniel

-- 
Daniel Vrátil
Email: dvra...@kde.org
Jabber: dan.vra...@kdetalk.net
IRC: dvratil on Freenode (#kde, #kontact, #akonadi)


Re: Moving akonadi from kdesupport and akonadi-search from playground

2015-07-20 Thread Daniel Vrátil

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)



Moving akonadi from kdesupport and akonadi-search from playground

2015-07-20 Thread Daniel Vrátil

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: [Kde-pim] KF5-QT5 branchgroup - jobs that need developeer attention

2015-04-15 Thread Daniel Vrátil

On 15.04.2015 09:44, Scarlett Clark wrote:
Here is a list of mostly compile failures and other tid bits that need 
to be
resolved by the respective developers. If you know the developer of a 
project
and they are not on this list please forward this. All jobs can be 
viewed at :

https://build-sandbox.kde.org/
Most of these are osx failures. If osx is not to be supported, I need 
to know

that too. Questions - concerns - just ask.
Thanks,
Scarlett

kdepimlibs - osx - compile failure breaks: kalarmcal, kdepim, 
kmailtransport


00:30:58 In file included from 
/Users/jenkins/builds/kdepimlibs/kf5-qt5/akonadi/src/core/exception.h:25:
00:30:58 In file included from 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/QByteArray:1:
00:30:58 In file included from 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qbytearray.h:37:
00:30:58 In file included from 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qrefcount.h:37:
00:30:58 In file included from 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qatomic.h:39:
00:30:58 In file included from 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qbasicatomic.h:58:
00:30:58 In file included from 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qatomic_x86.h:38:
00:30:58 In file included from 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qgenericatomic.h:38:
00:30:58 In file included from 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qtypeinfo.h:34:
00:30:58 
/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtCore/qtypetraits.h:108:1: 
error: unknown type name 'QT_BEGIN_NAMESPACE'

00:30:58 QT_BEGIN_NAMESPACE

This looks like a problem with Qt 5 deployment on the CI? I know that it 
would imply all other tasks failing with the same error,

but I have no idea why this should compile on Linux and not on OSX.


kdepim seems to fail due to missing grantlee dependency. Of course even 
with grantlee available, kdepim won't build until we figure out what's 
wrong with kdepimlibs.


00:37:47 CMake Error at CMakeLists.txt:91 (find_package):
00:37:47   Could not find a package configuration file provided by 
"Grantlee5"

00:37:47   (requested version 5.0) with any of the following names:
00:37:47
00:37:47 Grantlee5Config.cmake
00:37:47 grantlee5-config.cmake


Also looks like kdepim-runtime kf5-qt5 is missing on the sanbox CI - 
could you please add it?


Thanks,
Dan





___
KDE PIM mailing list kde-...@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


--
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)



Re: The Future or KDE PIM Releases

2015-04-14 Thread Daniel Vrátil
On Tuesday, April 14, 2015 12:17:39 AM Albert Astals Cid wrote:
> El Diumenge, 12 d'abril de 2015, a les 11:31:26, Daniel Vrátil va escriure:
> > Greetings from Toulouse!
> > 
> > Instead we will aim towards releasing KF5-based KDE PIM with "Akonadi 1"
> > in
> > the next release of KDE Applications in August. That means we now have
> > about 4 months to make sure that there are no regressions caused by
> > changes in Qt behavior - this should be manageable and not much effort
> > really. This is an internal change more or less, users won't notice
> > anything.
> 
> Meaning we stop releasing the LTS 4.14 by then?

Yes - that is assuming nothing goes terribly wrong and we would have to 
postpone the Qt 5 release.

Dan

> 
> Cheers,
>   Albert


The Future or KDE PIM Releases

2015-04-12 Thread Daniel Vrátil
Greetings from Toulouse!

We've been discussing the plans for releases of Akonadi(Next) and KDE PIM as a 
whole on the PIM sprint, because the current situation is kinda unclear and 
harmful for the project.

Now that we have a better idea of what Akonadi Next will be like, we decided 
that we don't want to just basically stop working on PIM and focus all our 
efforts towards Akonadi Next because that would cause the entire PIM to be in
sort of a limbo for who-knows-how-long and that would not be good for our 
users and for the project in general. We are already losing users so freezing
the development of the project does not sound like a good idea.

Instead we will aim towards releasing KF5-based KDE PIM with "Akonadi 1" in 
the next release of KDE Applications in August. That means we now have about 4
months to make sure that there are no regressions caused by changes in Qt 
behavior - this should be manageable and not much effort really. This is an 
internal change more or less, users won't notice anything.

Once the release is done, Christian will start focusing on Akonadi Next while
me, Laurent and others will focus on preparing PIM applications for the switch
to Akonadi Next (alongside normal development and maintenance). This involves
mostly getting rid of all Akonadi references from the code and replacing them
with domain-specific objects ("Email", "MailFolder" ,"Calendar", etc.), and 
writing a translation layer that will translate between Akonadi and the 
domain-specific objects. This is basically what Zanshin does and it works 
really really well for them. It's something we would have to do with Akonadi 
Next anyway. Once this is done (and once Akonadi Next is done) we simply 
switch the translation layers in applications to use Akonadi Next instead of 
Akonadi and be done with it. We find this to be the least disruptive approach 
for users since we will have stable and regular releases of KDE PIM while 
steadily working towards the switch and then just switching to Akonadi Next 
at some point, ideally without users really noticing.

However we realize that the amount of KDE PIM developers is not really enough
to cover all the PIM projects and applications, so we decided that we will 
only release components that have an (active) maintainer and that we feel we 
have enough manpower to work on. We will do an extragear release of the 
remaining projects at the same time as KDE Applications, but with no guarantee
of further releases or maintenance.

This is the current state - stuff that gets released in August with KDE 
Applications is considered "PIM Core", everything else is extragear.

Akregator
  - needs maintainer
  - release from extragear, unless a maintainer appears, then release with 
Applications as part of PIM core

Blogilo:
  - needs maintainer
  - no release in August, unless a maintainer appears, then release with 
Applications as part of PIM core

KAddressBook
  - maintained by Laurent
  - part of PIM core, release with KDE Applications in August

KOrganizer
  - maintained by Sergio
  - part of PIM core, release with KDE Applications in August

KAlarm
  - maintained by David Jarvie
  - release standalone in extragear, if David is willing to take care of that, 
otherwise no release

Kleopatra
  - needs maintainer
  - part of PIM core, release with KDE Applications in August

KMail
  - maintained by Laurent
  - part of PIM core, release with KDE Applications in August

KNotes
  - maintained by Laurent
  - part of PIM core, release with KDE Applications in August

Kontact
  - maintained by Laurent
  - part of PIM core, release with KDE Applications in August

With regard to Akonadi resources, we will NOT release KDE Accounts, Kolab 
Proxy (the old Kolab resource), Facebook, OpenXChange, Tags, NNTP and 
KBookmarks resources. We are desperately looking for maintainers for Maildir 
and MBox resources.

Regarding our underlaying libraries, we intend to release the following 
frameworks as soon as possible, since they are kdelibs4support-free, so we 
only need to review them:
 - GPGME++
 - KContacts
 - KLDAP
 - KMbox
 - Syndication

In the next rounds we will release the following frameworks, after we removed
their kdelibs4support dependency:
 - KMime
 - KIMAP
 - KCalCore

We believe that especially KContacts, KCalCore, KMime and KIMAP will draw a
lot of attention to KDE Frameworks, since there seems to be a demand for this 
kind of libraries.

The remaining kdepimlibs libraries (including Akonadi libs) will be released 
with KDE Applications as "PIM libraries".

We very much encourage other developers to step up for maintainership of any 
of the frameworks or applications above to reduce the workload of the current 
PIM team and help make KDE PIM awesome again.

We would welcome feedback and opinions from other PIM devs who are not here in
Toulouse. If everyone is fine with this proposal, we will

Re: Plasma 5.2 bits for kdereview

2014-12-23 Thread Daniel Vrátil
On Friday, December 19, 2014 06:46:11 PM Luigi Toscano wrote:
> Jonathan Riddell ha scritto:
> > Plasma 5.2 is due out next month and there's a few KDE projects which
> > would be good to be included.  Please review these for inclusion in
> > kde/workspace..
> > 
> 
> > kscreen and libkscreen maintained by Dan Vrátil.  libkscreen is already
> > released with Plasma but isn't in kde/workspace.
> > 
> >  https://projects.kde.org/projects/extragear/libs/libkscreen
> >  https://projects.kde.org/projects/extragear/base/kscreen
> 
> I disagree with moving libkscreen to kde/workspace. It is a dependency for
> at least one application (Okular), which has no Framework version for now
> but it will have it. It would make more sense to have libkscreen in
> Frameworks, like libnm*

AFAIK Okular is using KScreen only to get DPI info, which was not provided by 
QScreen in Qt 4. In Qt 5 you already have DPI API in QScreen, so you should 
not need KScreen anymore.


Dan


-- 
Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

signature.asc
Description: This is a digitally signed message part.


Re: [Kde-pim] kdepimlibs splitting done

2014-12-12 Thread Daniel Vrátil
On Friday, December 12, 2014 05:19:00 AM Aleix Pol wrote:
> Hi,
> I have performed the first round of kdepimlibs splitting tonight, as we
> agreed. Below you can see the for reference how the splitting was
> performed.
> 
> Dan, Laurent, can you give me the ok? Then we can proceed to remove
> the modules from the kdepimlibs repository.

The history of all modules seems to be complete, so +1 from me to remove them 
from kdepimlibs. Thanks a lot for taking care of the splitting, Aleix!

I guess the next steps are to review them, find maintainers and decide when 
they will get released. I would propose that this is discussed on the next IRC 
meeting on Monday (I'll send a separate email about that).


Cheers,
Daniel

> 
> Cheers!
> Aleix
> 
> kcontacts   -- [1]
> kxmlrpcclient   -- git filter-branch --tag-name-filter cat
> --subdirectory-filter kxmlrpcclient/ -- --all --tags
> kblog   -- git filter-branch --tag-name-filter cat
> --subdirectory-filter kblog/ -- --all --tags
> kcalcore-- git filter-branch --tag-name-filter cat
> --subdirectory-filter kcalcore/ -- --all --tags
> kcalutils   -- git filter-branch --tag-name-filter cat
> --subdirectory-filter kcalutils/ -- --all --tags
> kholidays   -- git filter-branch --tag-name-filter cat
> --subdirectory-filter kholidays/ -- --all --tags
> kalarmcal   -- [2]
> kimap   -- git filter-branch --tag-name-filter cat
> --subdirectory-filter kimap/ -- --all --tags
> kldap   -- git filter-branch --tag-name-filter cat
> --subdirectory-filter kldap/ -- --all --tags
> kidentitymanagement -- [3]
> kmbox   -- git filter-branch --tag-name-filter cat
> --subdirectory-filter kmbox/ -- --all --tags
> kmime   -- git filter-branch --tag-name-filter cat
> --subdirectory-filter kmime/ -- --all --tags
> kontactinterface-- git filter-branch --tag-name-filter cat
> --subdirectory-filter kontactinterface/ -- --all --tags
> kpimtextedit-- git filter-branch --tag-name-filter cat
> --subdirectory-filter kpimtextedit/ -- --all --tags
> ktnef   -- git filter-branch --tag-name-filter cat
> --subdirectory-filter ktnef/ -- --all --tags
> kmailtransport  -- git filter-branch --tag-name-filter cat
> --subdirectory-filter mailtransport/ -- --all --tags
> syndication -- git filter-branch --tag-name-filter cat
> --subdirectory-filter syndication/ -- --all --tags
> gpgmepp -- [4]
> 
> [1]
> time git filter-branch --tag-name-filter cat --prune-empty --index-filter '
> git read-tree $GIT_COMMIT:kcontacts || git read-tree --empty
> git read-tree --prefix kcontacts $GIT_COMMIT:kcontacts
> git read-tree --prefix kabc $GIT_COMMIT:kabc
> true
> ' master --all --tags
> 
> [2]
> time git filter-branch --tag-name-filter cat --prune-empty --index-filter '
> git read-tree $GIT_COMMIT:kalarmcal || git read-tree --empty
> git read-tree --prefix kalarm/cal/ $GIT_COMMIT:kalarm/cal/
> true
> ' master --all --tags
> 
> [3]
> time git filter-branch --tag-name-filter cat --prune-empty --index-filter '
> git read-tree $GIT_COMMIT:kidentitymanagement || git read-tree
> $GIT_COMMIT:kpimidentities
> true
> ' master --all --tags
> 
> [4]
> time git filter-branch --tag-name-filter cat --prune-empty --index-filter '
> git read-tree $GIT_COMMIT:gpgme++ || git read-tree --empty
> git read-tree --prefix qgpgme/src/ $GIT_COMMIT:qgpgme/src
> true
> ' master --all --tags
> ___
> KDE PIM mailing list kde-...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/

-- 
Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Associate Software Engineer
KDE Desktop Team, Red Hat

GPG Key: 0xC59D614F6F4AE348 

 
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 


signature.asc
Description: This is a digitally signed message part.


Re: Moving KScreen and libkscreen to extragear

2013-10-18 Thread Daniel Vrátil
On Monday 08 of July 2013 19:19:08 David Edmundson wrote:
> Code wise, things looks pretty good.
> 
> Minor comments:
>  - the library is GPL, not LGPL which is the norm for libraries.
> Is this deliberate?

No, I don't think so. I'm just fine with changing it to LGPL (and I guess Alex 
will be too).

> 
>  - Inside kscreen you have a copy of the metadata.desktop file twice.
> Just have the one and install it to the two places.

Fixed.

> You might also want to use the version number from your main CMakeLists.txt
> in your .desktop file too, otherwise updating can get messy.

Fixed, thanks.

> 
> -Generator::biggestOutput
> rename the local variable "total"...it's not a total of anything, I had to
> re-read it 10 times to realise the code was correct.

Right, confused me too :-) Fixed.

> In general though +1 from me.

Thanks :)

Dan

-- 
Daniel Vrátil
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

signature.asc
Description: This is a digitally signed message part.


Re: Fwd: looking for phonon gstreamer maintainer

2013-10-07 Thread Daniel Vrátil
On Wednesday 25 of September 2013 12:35:25 Harald Sitter wrote:
> -- Forwarded message --
> From: Harald Sitter 
> Date: Mon, Sep 23, 2013 at 4:55 PM
> Subject: looking for phonon gstreamer maintainer
> To: "For discussion of multimedia (sound/video) issues under KDE"
> 
> 
> 
> Ahoy,
> 
> since everyone who ever was/is/wanted to be Phonon GStreamer
> maintainer is either busy or has no interest in it, the backend has as
> of right now no actual maintenance.
> 
> If anyone wishes to step up and move the backend forward now is the
> time to do it. I'd like to note that this is not a one-man job though
> and I am going to continue to be supporting developer.
> 
> In the unfortunate case that no one is willing enough we will have to
> look at the possibility of moving the backend out of the support
> scope, leaving Phonon VLC as the only actively supported backend on
> all platforms.
> 
> As immediate result I will likely have to demote the backend's initial
> preference for the upcoming 4.7.0 release below Phonon VLC's.

Hi,

in Fedora we have a big interest in keeping phonon-gstreamer alive, namely 
because we can't ship phonon-vlc due to legal issues (you know, US company, 
software patents and what not...) and our users would not probably be very 
happy if we had no phonon working backend in Fedora KDE.

So far we are happy with gstreamer-0.10, but we realize that sooner or later 
we will have to start looking into supporting gstreamer-1.0. Even if we are 
able to keep phonon with gstreamer-0.10 alive by patching the hell out of it 
in downstream, at some point we will be forced to drop it, and then we would 
have nothing to switch to.

So I'm willing to help keeping phonon-gstreamer alive in upstream (I'm not 
saying I'll be able to fix all the bugs) and slowly look into the gst-1.0 port. 
I'm not able to fully maintain yet another project (I already have more than 
enough :-)), but as said above, I can contribute to keep it alive and push it 
over the hill to gstreamer-1.0 (come on, how hard can it be? ;-))

Luckily for me, we have a GStreamer guy in the office, so I can get some help 
from him if necessary :)

Cheers,
Dan

> 
> HS

-- 
Daniel Vrátil
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

signature.asc
Description: This is a digitally signed message part.


Re: Help solving an IMAP SSL bug

2013-08-22 Thread Daniel Vrátil
On Tuesday 20 of August 2013 20:42:05 Richard Moore wrote:
> On 19 August 2013 10:58, Daniel Vrátil  wrote:
> > Because it's a socket error KSslSocket will emit socketError() and IMAP
> > resource will try to reconnect. The interesting part here is, that calling
> > QAbstractSocket::disconnect() will emit the error again (probably it's
> > trying to write something to the socket?) and so we end up in an endless
> > loop, when we try to disconnect on an error, which causes an error, on
> > which we try to disconnect
> 
> You should call abort() rather than disconnect() here.

Thanks, that seems to solve the problem with disconnect() generating the 
error, but it does not solve the problem: after calling abort() in error 
handler, we try to reconnect. But calling KTcpSocket::connectToHostEncrypted() 
will generate the same error, so we end up in a loop anyway and the resource 
is not able to successfully establish a secured connection until it's 
restarted.

Cheers,
Dan

> 
> Cheers
> 
> Rich.

-- 
Daniel Vrátil
Associate Software Engineer, KDE Desktop Team
Red Hat, Inc

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

signature.asc
Description: This is a digitally signed message part.


Help solving an IMAP SSL bug

2013-08-19 Thread Daniel Vrátil
(cross-posting, because this might actually be a bug in KSslSocket or even Qt)  

Hi,

we currently have a quite annoying issue with Akonadi IMAP resource and SSL 
connection and because my knowledge of this topic is limited, I'm asking you 
guys for help.

When connection to an IMAP server is lost (timeout, server drops connection, 
etc.) and the resource tries to reconnect it fails due to 
QAbstractSocket::SslHandshakeFailedError error and so does every next attempt 
until the Akonadi resource is restarted.

Because it's a socket error KSslSocket will emit socketError() and IMAP 
resource will try to reconnect. The interesting part here is, that calling 
QAbstractSocket::disconnect() will emit the error again (probably it's trying 
to write something to the socket?) and so we end up in an endless loop, when 
we try to disconnect on an error, which causes an error, on which we try to 
disconnect

This results in a constant network traffic around 20kbps and means that we are 
effectively DOSing the IMAP server, which in the worst case can result in 
provider banning the IP address.

Surprisingly this happens only with some IMAP servers. I can reliably 
reproduce with Cyrus and Zimbra servers, but it does not happen with Dovecot 
server or Gmail.

Martin Briza was already looking into this problem in June [0], but got to no 
real solution, except for adding the missing mapping from 
QAbstractSocket::SslHandshakeFailedError to 
KTcpSocket::SslHandsakeFailedError, so we are now able to detect this error, 
but we still have on clue how to act on it and it does not really solve the 
fact that we can't establish a new connection.

Have anyone experienced something similar in past? Any ideas where to look?

Thanks,
Dani


[0] http://lists.kde.org/?l=kde-core-devel&m=137050526303582&w=2


-- 
Daniel Vrátil
Associate Software Engineer, KDE Desktop Team
Red Hat, Inc

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

signature.asc
Description: This is a digitally signed message part.


Re: Moving KScreen and libkscreen to extragear

2013-07-08 Thread Daniel Vrátil
On Thursday 04 of July 2013 22:28:27 Burkhard Lück wrote:
> Am Donnerstag, 4. Juli 2013, 01:13:36 schrieb Àlex Fiestas:
> > I would like to request a review so we can move KScreen and libkscreen to
> > extragear/base.
> > 
> > KScreen is a new manager for outputs such: monitors, projectors, embedded
> > 
> > screens... It contains:
> > -KDED Module which does some magic by auto configuring the screens,
> > and
> > 
> > saving configurations whenever they are changed.
> > 
> > -KCM allowing to apply any configuration (change resolution,
> > rotate...)
> > -A plasmoid that does little at the moment.
> 
> It has six qtTr() calls for gui strings, but these messages are not
> extracted to l10n-kde4/templates/messages, reported already some time ago
> here:
> 
> https://bugs.kde.org/show_bug.cgi?id=316548#c1

Hi,

it should be fixed now. I replaced qsTr calls with i18nc and added some context 
descriptions.

Cheers,
Dan


> 
> > -A library that offers a good abstraction so we can support multiple
> > 
> > backends. At the moment we support XRandR 1.1 and 1.2/3/4.

-- 
Daniel Vrátil
Associate Software Engineer, KDE Desktop Team
Red Hat, Inc

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

signature.asc
Description: This is a digitally signed message part.


Re: Buy Sprint tickets !

2013-03-03 Thread Daniel Vrátil
On Saturday 02 of March 2013 23:23:30 Àlex Fiestas wrote:
> Just a reminder that we should buy the plane tickets ASAP so we can get the
> cheaper deals. The sprint is only 40 days away.
>
> See you in Brno !

I already got my bus ticket to get to the office in the morning :P Looking
forward to meet you all there :-)

Dan

--
Daniel Vrátil
Associate Software Engineer, KDE Desktop Team
Red Hat, Inc

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

signature.asc
Description: This is a digitally signed message part.