Re: KF 5.95-rc1 delayed

[Luca Carlon]

On Wed, Jun 8, 2022 at 11:41 AM David Faure  wrote:

> > > This also seems like something we should also fix before tagging:
> > > https://bugs.kde.org/show_bug.cgi?id=454635#c11
>
> Luca, Marco: I need your input quickly on this one.

https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/545

Isn't this also pretty relevant?
https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/535

Regards.

-- 
Dr. Luca Carlon
Software Engineer

Re: Cmake and dbus daemon on the system bus

[Luca Carlon]

Very sorry for the incredibly late answer, but I had to pause this task.

On Mon, Sep 16, 2019 at 9:56 PM David Edmundson
 wrote:
>
> Kauth is a wrapper round using dbus activation on the system bus...

Yes, and that is how my first implementation works. But it seemed less
flexible: the only way I found to implement something like a daemon is
a long running method. But it seems a bad approach when it comes to
multiple clients calling into the helper. I suppose that the helper is
single instance (which is ok), and the call to the method remains in
queue for the following clients. Is this correct? Do you think this is
a good architecture? Any advice?

> It's 99.9% the same.

Yes, code is almost identical, but is the policy file used for the
session bus? I can't find a description for that in the docs.
It seems however that I found something here:
https://techbase.kde.org/Development/Tutorials/PolicyKit/Helper_HowTo.
I skipped that article because it seemed outdated. Is it or can I
refer to it?

> You want to look for dbus-activation and set User=root in the
> activation desktop file that you put in
> /usr/share/dbus-1/system-services

I'll try that, thanks!
Sorry again for the late answer. Regards.


On Mon, Sep 16, 2019 at 9:56 PM David Edmundson
 wrote:
>
> Kauth is a wrapper round using dbus activation on the system bus...
>
> >I read the tutorials related to dbus in the techbase pages, but those seem 
> >more oriented to the sessionBus.
>
> It's 99.9% the same.
>
> >and a way to automatically start with root privileges the daemon
>
> You want to look for dbus-activation and set User=root in the
> activation desktop file that you put in
> /usr/share/dbus-1/system-services
>
> David



-- 
Dr. Luca Carlon
Software Engineer

Cmake and dbus daemon on the system bus

[Luca Carlon]

Hello,
not sure if this is the right place to ask. I'm working on this new
feature: https://bugs.kde.org/show_bug.cgi?id=410902. In the current
implementation I used KAuth, but it seems to me a dbus daemon would be a
better fit for this case. The daemon must be run as root, and should
therefore probably use the systemBus. I read the tutorials related to dbus
in the techbase pages, but those seem more oriented to the sessionBus.

I already implemented the communication, which seems to work properly. I'm
missing a way to automatically install the policy file with cmake (which
should be in /etc/dbus-1/system.d) and a way to automatically start with
root privileges the daemon (can that be done with a .desktop file?). Anyone
who can provide some info? Is there maybe a place where to find guidelines
about these two points? Or even examples doing the same?

Thank you very much for any help!
Regards.

-- 
Dr. Luca Carlon
Software Engineer

KDE service for mounting storage resources

[Luca Carlon]

Hello! For some projects I'd need some kind of "service" being able to
mount resources like SMB shares, FTP, SFTP etc... I read about KIO a bit,
but I'd need something that can be passed also to non-KIO applications.
I read the code of smb4k and it seems to do exactly what I need: using
KAuth and mounting to some specific path. But this seems a bit tied to the
specific application and only supporting SMB. What I'd need is some kind of
service, a bit like udisks, in order to mount on request from other
processes.
On IRC someone told me something like this may already be into Plasma: is
there someone able to provide more info?
Thanks!
Regards.

Luca

D14457: Forward-declare X509 structure

[Luca Carlon]

luc4 edited the summary of this revision.

REPOSITORY
  R239 KDELibs4Support

REVISION DETAIL
  https://phabricator.kde.org/D14457

To: luc4, #frameworks, cfeck, dfaure
Cc: dfaure, kde-frameworks-devel, michaelh, ngraham, bruns

D14457: Forward-declare X509 structure

[Luca Carlon]

luc4 added a comment.


  When QT_NO_OPENSSL is defined, I see that X509 was declared as a class, so I 
used the same instruction.
  In ksslconfig.h I have `#define KSSL_HAVE_SSL 0`. I don't know if I can 
recovery much more output, the build succeeded days ago.
  Unfortunately I'm not an expert of this section, but I see that libssl-dev is 
not installed. Maybe that made find() fail?
  In any case, if that dep is optional, I guess the build is not supposed to 
fail, is it?

REPOSITORY
  R239 KDELibs4Support

REVISION DETAIL
  https://phabricator.kde.org/D14457

To: luc4, #frameworks, cfeck, dfaure
Cc: dfaure, kde-frameworks-devel, michaelh, ngraham, bruns

D14457: Forward-declare X509 structure

[Luca Carlon]

luc4 added a comment.


  In D14457#304135 , @dfaure wrote:
  
  > Can you explain why in the commit log, not just what? The diff tells us 
what already, but why? I assume this fixes a compilation error? Which one, on 
which platform? Thanks.
  
  
  Unfortunately it would take some time to determine what changed that made 
this mandatory for me. Maybe some header changed in the hierarchy and the 
declaration is no more included anymore? Anyway, I cannot build it without 
declaring it. I'm building in docker using kdeneon/plasma:dev-unstable.

REPOSITORY
  R239 KDELibs4Support

REVISION DETAIL
  https://phabricator.kde.org/D14457

To: luc4, #frameworks, cfeck, dfaure
Cc: dfaure, kde-frameworks-devel, michaelh, ngraham, bruns

D14457: Forward-declare X509 structure

[Luca Carlon]

luc4 edited the summary of this revision.

REPOSITORY
  R239 KDELibs4Support

REVISION DETAIL
  https://phabricator.kde.org/D14457

To: luc4, #frameworks, cfeck, dfaure
Cc: dfaure, kde-frameworks-devel, michaelh, ngraham, bruns

D14457: Forward-declare X509 structure

[Luca Carlon]

luc4 retitled this revision from "Forward-define X509 structure" to 
"Forward-declare X509 structure".
luc4 edited the summary of this revision.

REPOSITORY
  R239 KDELibs4Support

REVISION DETAIL
  https://phabricator.kde.org/D14457

To: luc4
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D14457: Forward-define X509 structure

[Luca Carlon]

luc4 created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: kde-frameworks-devel.
luc4 requested review of this revision.

REVISION SUMMARY
  Forward-define X509 structure even when Qt ssl support is available.

REPOSITORY
  R239 KDELibs4Support

REVISION DETAIL
  https://phabricator.kde.org/D14457

AFFECTED FILES
  src/kssl/ksslcertificate.h

To: luc4
Cc: kde-frameworks-devel, michaelh, ngraham, bruns