Just a heads-up:
We hope to land a new PolicyKit version (which will turn into 1.0, eventually) in F12 soon. The new version simplifies the API and will require PolicyKit-using application to be ported. For more information, have a look at the feature page:
http://fedoraproject.org/wiki/Features/PolicyKitOne
It also has pointers to api docs and a (terse) porting guide. We already have a collection of patches for quite a few PolicyKit-using apps, so the transitions should be relatively painless.
Matthias
On Wed, May 13, 2009 at 09:00:46PM -0400, Matthias Clasen wrote:
Just a heads-up:
We hope to land a new PolicyKit version (which will turn into 1.0, eventually) in F12 soon. The new version simplifies the API and will require PolicyKit-using application to be ported. For more information, have a look at the feature page:
http://fedoraproject.org/wiki/Features/PolicyKitOne
It also has pointers to api docs and a (terse) porting guide. We already have a collection of patches for quite a few PolicyKit-using apps, so the transitions should be relatively painless.
http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE
doesn't uindicate how to discriminate at compile time which version we are compiling against. Please indictate in the porting doc how to detect the installed version in configure. That's the bare minimum when you're changing APIs in that way. We obviously need libvirt to handle older and newer versions !
Also what does • No kit_* OOM handling in the new library means ?
Daniel
On Sat, May 16, 2009 at 8:56 AM, Daniel Veillard veillard@redhat.com wrote:
• No kit_* OOM handling in the new library means ?
The old kit_* functions used to handle OOM (out of memory conditions) and report back the correct error. The new library is more GLib like, and doesn't handle OOM very well at all. It's likely you didn't care about OOM before, so this change won't affect you.
Richard.
On Sun, May 17, 2009 at 09:14:03AM +0100, Richard Hughes wrote:
On Sat, May 16, 2009 at 8:56 AM, Daniel Veillard veillard@redhat.com wrote:
? No kit_* OOM handling in the new library means ?
The old kit_* functions used to handle OOM (out of memory conditions) and report back the correct error. The new library is more GLib like, and doesn't handle OOM very well at all. It's likely you didn't care about OOM before, so this change won't affect you.
Well there are two ends to this. The client app side (eg virt-manager) we don't care about OOM, since we're using GTK and that just aborts all the time. For the service end, eg libvirtd, we do care about OOM handling and we test for it, so this change is an unfortunate regression :-(
Regards, Daniel
On Mon, 2009-05-18 at 10:57 +0100, Daniel P. Berrange wrote:
On Sun, May 17, 2009 at 09:14:03AM +0100, Richard Hughes wrote:
On Sat, May 16, 2009 at 8:56 AM, Daniel Veillard veillard@redhat.com wrote:
? No kit_* OOM handling in the new library means ?
The old kit_* functions used to handle OOM (out of memory conditions) and report back the correct error. The new library is more GLib like, and doesn't handle OOM very well at all. It's likely you didn't care about OOM before, so this change won't affect you.
Well there are two ends to this. The client app side (eg virt-manager) we don't care about OOM, since we're using GTK and that just aborts all the time. For the service end, eg libvirtd, we do care about OOM handling and we test for it, so this change is an unfortunate regression :-(
No, there is no regression here. As I tried to explain in the reply to Veillard:
1. In libvirtd, simply check for authorization by speaking to the polkitd-1 using either the D-Bus API (via e.g. libdbus-1 which handles OOM) or a through helper.
2. virt-manager will not have to know _anything_ about PolicyKit
And if either polkitd-1 or the helper aborts() due to OOM, then you will get a D-Bus error back (or if using a helper, WIFEXITED(status) != 0) and you can check the authorization again - this works because the bus daemon (which handles OOM) will then reactivate polkitd-1.
David
On Sat, 2009-05-16 at 09:56 +0200, Daniel Veillard wrote:
On Wed, May 13, 2009 at 09:00:46PM -0400, Matthias Clasen wrote:
Just a heads-up:
We hope to land a new PolicyKit version (which will turn into 1.0, eventually) in F12 soon. The new version simplifies the API and will require PolicyKit-using application to be ported. For more information, have a look at the feature page:
http://fedoraproject.org/wiki/Features/PolicyKitOne
It also has pointers to api docs and a (terse) porting guide. We already have a collection of patches for quite a few PolicyKit-using apps, so the transitions should be relatively painless.
http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE
doesn't uindicate how to discriminate at compile time which version we are compiling against. Please indictate in the porting doc how to detect the installed version in configure. That's the bare minimum when you're changing APIs in that way. We obviously need libvirt to handle older and newer versions !
For testing availability, PolicyKit 0.9.x provides polkit.pc, the new version provides polkit-gobject-1.pc that you can use to test for.
Also what does • No kit_* OOM handling in the new library means ?
The client side library now uses GObject and the policy there is to abort() on OOM. If you don't like this, you can use either the D-Bus interface of the PolicyKit daemon or call out to a helper program (not yet written, but it's simple) to check the authorization.
Note that the model in the new PolicyKit release is a lot simpler - you now only need PolicyKit support in the actual privileged mechanism that needs to check for authorization. E.g. the client (virt-manager in this case) does not really need to know anything about PolicyKit - the authentication dialogs are popped up automatically if the mechanism passes ALLOW_USER_INTERACTION when checking whether the client calling into your mechanism is authorized for some action.
So, for the libvirt daemon, where I believe you do care about handling OOM, the easiest thing is probably to just use the helper program to check for authorizations. Just easier all around and less foreign code polluting your process.
Anyway, I'll make sure there are sufficient docs to make this transition as simple as possible.
David
On Jueves 14 Mayo 2009 03:00:46 Matthias Clasen escribió:
Just a heads-up:
We hope to land a new PolicyKit version (which will turn into 1.0, eventually) in F12 soon. The new version simplifies the API and will require PolicyKit-using application to be ported. For more information, have a look at the feature page:
http://fedoraproject.org/wiki/Features/PolicyKitOne
It also has pointers to api docs and a (terse) porting guide. We already have a collection of patches for quite a few PolicyKit-using apps, so the transitions should be relatively painless.
Hi, could you be more specific in porting guide with some more real world examples etc. Patches are OK for quick overview what should be done but it's not a good source if you don't know code for those apps.
For us (KDE SIG) it's really big problem - PK1 already missed 4.3 release (as it brings old PK support) so it's possible to have it upstream for 4.4 (next year). I'd try to contact upstream to ask them about current status but it looks like nobody is currently working on port but I hope we can help with it (as it comes from Fedora)...
Could you add policykit-qt/kde to blockers on PK1 Feature page?
How long old PK will be shipped in Fedora?
Thanks Jaroslav
Matthias
Jaroslav Reznik wrote:
On Jueves 14 Mayo 2009 03:00:46 Matthias Clasen escribió:
Just a heads-up:
We hope to land a new PolicyKit version (which will turn into 1.0, eventually) in F12 soon. The new version simplifies the API and will require PolicyKit-using application to be ported. For more information, have a look at the feature page:
http://fedoraproject.org/wiki/Features/PolicyKitOne
It also has pointers to api docs and a (terse) porting guide. We already have a collection of patches for quite a few PolicyKit-using apps, so the transitions should be relatively painless.
could you be more specific in porting guide with some more real world examples etc. Patches are OK for quick overview what should be done but it's not a good source if you don't know code for those apps.
Seems frustrations are mounting: "On policykit and standards" http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html
-- Rex
| From: Rex Dieter rdieter@math.unl.edu
| Seems frustrations are mounting: | "On policykit and standards" | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html
[I'm an outsider. This thread is my introduction to the whole area. I'm not even a KDE user.]
This certainly does not look like a healthy approach to standardization and cooperation.
- the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE appears clearly biased towards GNOME, even though its URL and title suggest universality: the first substantial line talks about polkit-gobject-1 (I *think* that gobject means GNOME object)
- in a well-constituted standards process (not a de facto standard), stakeholders are consulted before changes are made. It looks as if KDE folks have been stakeholders and have not been allowed to even sign-off on the design, let alone participate in it.
- for good reason, the normal output of a standardization process is a document, not code. There appears to be no complete documentation.
- all stakeholders ought to be treated respectfully and equitably. That means, for example, KDE ought not the be second to GNOME. More particularly, the architectures should be open-ended, allowing for more than KDE and GNOME. See, for example, http://c2.com/cgi/wiki?ZeroOneInfinityRule
I admit that my reactions may be ill-founded. Perhaps this is meant to be an example of "We reject: kings, presidents and voting. We believe in: rough consensus and running code" (The IETF approach, as phrased by http://en.wikipedia.org/wiki/David_D._Clark ) Even the IETF does have votes (but only of those in the room at the time).
On Mon, May 25, 2009 at 02:22:02PM -0400, D. Hugh Redelmeier wrote:
| From: Rex Dieter rdieter@math.unl.edu
| Seems frustrations are mounting: | "On policykit and standards" | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html
[I'm an outsider. This thread is my introduction to the whole area. I'm not even a KDE user.]
This certainly does not look like a healthy approach to standardization and cooperation.
the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE appears clearly biased towards GNOME, even though its URL and title suggest universality: the first substantial line talks about polkit-gobject-1 (I *think* that gobject means GNOME object)
in a well-constituted standards process (not a de facto standard), stakeholders are consulted before changes are made. It looks as if KDE folks have been stakeholders and have not been allowed to even sign-off on the design, let alone participate in it.
for good reason, the normal output of a standardization process is a document, not code. There appears to be no complete documentation.
all stakeholders ought to be treated respectfully and equitably. That means, for example, KDE ought not the be second to GNOME. More particularly, the architectures should be open-ended, allowing for more than KDE and GNOME. See, for example, http://c2.com/cgi/wiki?ZeroOneInfinityRule
I admit that my reactions may be ill-founded. Perhaps this is meant
You are attempting to create problems here which don't exist. David has already pointed out in another mail that if apps don't want to use the glib based library, they can talk to DBus directly. There are native QT bindings for DBus, and pretty much any other language can talk to DBus too with no deps on glib / gobject.
Daniel
On Martes 26 Mayo 2009 11:16:14 Daniel P. Berrange escribió:
On Mon, May 25, 2009 at 02:22:02PM -0400, D. Hugh Redelmeier wrote:
| From: Rex Dieter rdieter@math.unl.edu | | Seems frustrations are mounting: | "On policykit and standards" | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html
[I'm an outsider. This thread is my introduction to the whole area. I'm not even a KDE user.]
This certainly does not look like a healthy approach to standardization and cooperation.
the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE appears clearly biased towards GNOME, even though its URL and title suggest universality: the first substantial line talks about polkit-gobject-1 (I *think* that gobject means GNOME object)
in a well-constituted standards process (not a de facto standard), stakeholders are consulted before changes are made. It looks as if KDE folks have been stakeholders and have not been allowed to even sign-off on the design, let alone participate in it.
for good reason, the normal output of a standardization process is a document, not code. There appears to be no complete documentation.
all stakeholders ought to be treated respectfully and equitably. That means, for example, KDE ought not the be second to GNOME. More particularly, the architectures should be open-ended, allowing for more than KDE and GNOME. See, for example, http://c2.com/cgi/wiki?ZeroOneInfinityRule
I admit that my reactions may be ill-founded. Perhaps this is meant
You are attempting to create problems here which don't exist. David has already pointed out in another mail that if apps don't want to use the glib based library, they can talk to DBus directly. There are native QT bindings for DBus, and pretty much any other language can talk to DBus too with no deps on glib / gobject.
Seems like direct DBus communication is the only way to do it from Qt/KDE apps as PolKit library requires gtk_init() somewhere in code... I've prepared patch for polkit-qt to the new PK1 Core API but... Or is there any other way to initialize glib without need for it? I'm not familiar with GTK app development... But library that expects gtk_init somewhere in application to be correctly intialized...
PK1 should be split into parts - cross-desktop backends should be on freedesktop, gnome specific libraries should be in gnome repository. This should stop confusion.
Jaroslav
Daniel
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ |: :| http://libvirt.org -o- http://virt-manager.org -o- |: http://ovirt.org :| http://autobuild.org -o- |: http://search.cpan.org/~danberr/ :| GnuPG: 7D3B9505 -o- F3C9 553F A1DA |: 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Tue, 2009-05-26 at 15:37 +0200, Jaroslav Reznik wrote:
Seems like direct DBus communication is the only way to do it from Qt/KDE apps as PolKit library requires gtk_init() somewhere in code... I've prepared patch for polkit-qt to the new PK1 Core API but... Or is there any other way to initialize glib without need for it? I'm not familiar with GTK app development... But library that expects gtk_init somewhere in application to be correctly intialized...
Calling g_type_init() should be enough; there is no direct GTK+ dependency in polkit-gobject. Even g_type_init() may be too much for KDE apps to swallow though, so going directly to the bus is still a good idea.
PK1 should be split into parts - cross-desktop backends should be on freedesktop, gnome specific libraries should be in gnome repository. This should stop confusion.
You mean like
http://cgit.freedesktop.org/PolicyKit http://git.gnome.org/cgit/PolicyKit-gnome
?
On Martes 26 Mayo 2009 15:44:56 Matthias Clasen escribió:
On Tue, 2009-05-26 at 15:37 +0200, Jaroslav Reznik wrote:
Seems like direct DBus communication is the only way to do it from Qt/KDE apps as PolKit library requires gtk_init() somewhere in code... I've prepared patch for polkit-qt to the new PK1 Core API but... Or is there any other way to initialize glib without need for it? I'm not familiar with GTK app development... But library that expects gtk_init somewhere in application to be correctly intialized...
Calling g_type_init() should be enough; there is no direct GTK+ dependency in polkit-gobject. Even g_type_init() may be too much for KDE apps to swallow though, so going directly to the bus is still a good idea.
Thanks, I'll try it. Shouldn't library do the proper initialization? Then it's OK for us and it's better for other nongtk projects (not only KDE) - I think once we have library it's useless to duplicate work. But we agreed with upstream that directly using dbus is best for us but first I tried to do port line by line according to your patches/docs/porting guide...
PK1 should be split into parts - cross-desktop backends should be on freedesktop, gnome specific libraries should be in gnome repository. This should stop confusion.
You mean like
http://cgit.freedesktop.org/PolicyKit http://git.gnome.org/cgit/PolicyKit-gnome
I thought polkit library which depends on glib initialization is not right cross desktop solution...
Jaroslav
Jaroslav Reznik wrote:
How long old PK will be shipped in Fedora?
Shipping old PolicyKit won't really help, as PackageKit etc. are all going to get ported to the new one. The only reasonable thing to do is to BLOCK the upgrade until it can be supported cross desktop. I'm really fed up of having to play catch up with supposedly "shared" technologies getting upgraded under us without anybody talking to KDE upstream or to us (Fedora's KDE SIG) about the schedule. The PolicyKit-kde developer even WANTS to support the new version, but he didn't get the documentation he needs for that (and asked for weeks ago)! (Lack of documentation is a real issue for this stuff. When I did the KDM ConsoleKit patch, I had to look at source code, both of ConsoleKit and of GDM, to figure out what the heck was going on.)
Kevin Kofler
On Sun, 2009-05-24 at 00:33 +0200, Kevin Kofler wrote:
Jaroslav Reznik wrote:
How long old PK will be shipped in Fedora?
Shipping old PolicyKit won't really help, as PackageKit etc. are all going to get ported to the new one. The only reasonable thing to do is to BLOCK the upgrade until it can be supported cross desktop. I'm really fed up of having to play catch up with supposedly "shared" technologies getting upgraded under us without anybody talking to KDE upstream or to us (Fedora's KDE SIG) about the schedule.
The feature page has been out there for all to read for months.
It took me a couple of evenings to write patches for the majority of polkit users in gnome, so I assume it should be possible to do the same for KDE. It is probably even easier, since you have those fabulous abstraction layers on top of all the 'shared' technologies...
The PolicyKit-kde developer even WANTS to support the new version, but he didn't get the documentation he needs for that (and asked for weeks ago)!
I see a single mail by Dario on the PolicyKit mailing list before the one that you consider as 'mounting frustration'. Admittedly, it didn't get a reply, but it was a very general 'lets work together' mail, not asking concrete questions about missing documentation.
As we all know, writing documentation is hard. The current 'porting guide' is the result of Richard and me writing patches to port a bunch of apps to the new PolicyKit, and is really just a collection of notes taken while hacking.
I propose that the best way to improve the docs is to ask concrete questions on the mailing list.
Matthias
Matthias Clasen wrote:
It took me a couple of evenings to write patches for the majority of polkit users in gnome
Several of your "porting patches" just drop PolicyKit support entirely (so it looks to me like either it's actually more work to port to the new PolicyKit than you claim or the new PolicyKit is just not powerful enough to support everything the old one did, both of which would be bad things).
Kevin Kofler
On Sun, 2009-05-24 at 07:53 +0200, Kevin Kofler wrote:
Matthias Clasen wrote:
It took me a couple of evenings to write patches for the majority of polkit users in gnome
Several of your "porting patches" just drop PolicyKit support entirely (so it looks to me like either it's actually more work to port to the new PolicyKit than you claim or the new PolicyKit is just not powerful enough to support everything the old one did, both of which would be bad things).
Look closer then.
The big advantage of the new api is that the PolicyKit interaction is kept entirely on the mechanism side, with no need for clients do a complicated first-call-mechanism-then-polkit-then-mechanism-again dance. The consequence is that porting to the new api often just means dropping polkit-specific code from the clients.
Oh, and I should add:
Matthias Clasen wrote:
It took me a couple of evenings to write patches for the majority of polkit users in gnome, so I assume it should be possible to do the same for KDE. It is probably even easier, since you have those fabulous abstraction layers on top of all the 'shared' technologies...
The only layer between PolicyKit and KDE at the moment is polkit-qt.
Moreover, the affected software portions to port in KDE land are not simple applications like the ones you ported. They are: - polkit-qt: the binding, which needs changes for ALL the API changes, not just the ones affecting a particular application (which is also why Dario is asking for a complete list of API changes, which sadly doesn't seem to exist... rewriting everything without writing down what is being changed and then reconstructing the changes from notes taken when porting applications is a really bad way to document API changes), and changes to polkit-qt's own API may also be needed (and if so, need to be decided upstream, we can't just do random API changes locally in Fedora), - PolicyKit-kde: this has 2 parts: i. the authentication agent, which needs to be basically rewritten (because the way authentication is handled has changed) and ii. the polkit-kde-authorization tool which needs significant changes or a rewrite. The application layer may need porting too if polkit-qt needs API changes, but getting polkit-qt and PolicyKit-kde ported is the big effort (and a working PolicyKit-kde is important for things like PackageKit).
Kevin Kofler
On Sunday 24 May 2009 04:26:10 Matthias Clasen wrote:
On Sun, 2009-05-24 at 00:33 +0200, Kevin Kofler wrote:
Jaroslav Reznik wrote:
How long old PK will be shipped in Fedora?
Shipping old PolicyKit won't really help, as PackageKit etc. are all going to get ported to the new one. The only reasonable thing to do is to BLOCK the upgrade until it can be supported cross desktop. I'm really fed up of having to play catch up with supposedly "shared" technologies getting upgraded under us without anybody talking to KDE upstream or to us (Fedora's KDE SIG) about the schedule.
The feature page has been out there for all to read for months.
Yes, it was - but this is first visible activity with actual results - existing code etc. as I know (sorry if it's not true).
It took me a couple of evenings to write patches for the majority of polkit users in gnome, so I assume it should be possible to do the same for KDE. It is probably even easier, since you have those fabulous abstraction layers on top of all the 'shared' technologies...
Currently it's using polkit-grant and that seems it's not ported to new API yet. Could you take a look to code and suggest us right way to port it? Every help/ideas are appreciate. I'll try to look into deeper and I hope we can do it until Fedora 12 is released.
It lies in http://websvn.kde.org/trunk/kdesupport/polkit-qt/ and http://websvn.kde.org/trunk/KDE/kdebase/workspace/PolicyKit-kde/
Upstream is currently considering writing on pure DBUS implementation even own backend. I hope I can join it and try to help. Main problem is it took some time for PolKit to be accepted by KDE and it's 4.3 feature and it's now beta (and as KDE has very strict freezes). Now there are big API changes and it misses KDE release - it's a work for 4.4 - so next year :(
The PolicyKit-kde developer even WANTS to support the new version, but he didn't get the documentation he needs for that (and asked for weeks ago)!
I see a single mail by Dario on the PolicyKit mailing list before the one that you consider as 'mounting frustration'. Admittedly, it didn't get a reply, but it was a very general 'lets work together' mail, not asking concrete questions about missing documentation.
As we all know, writing documentation is hard. The current 'porting guide' is the result of Richard and me writing patches to port a bunch of apps to the new PolicyKit, and is really just a collection of notes taken while hacking.
I propose that the best way to improve the docs is to ask concrete questions on the mailing list.
I've pointed Dario to this thread. We're in close contact, so I can try to cooperate this efforts as it should be cross desktop one. Feel free to contact me. Complaining don't help - actual code yes ;-)
Matthias
Thanks Jaroslav
On Sunday 24 May 2009 00:33:09 Kevin Kofler wrote:
Jaroslav Reznik wrote:
How long old PK will be shipped in Fedora?
Shipping old PolicyKit won't really help, as PackageKit etc. are all going to get ported to the new one. The only reasonable thing to do is to BLOCK the upgrade until it can be supported cross desktop.
Kevin, I know but it can add some time for us.
Jaroslav
I'm really fed up of having to play catch up with supposedly "shared" technologies getting upgraded under us without anybody talking to KDE upstream or to us (Fedora's KDE SIG) about the schedule. The PolicyKit-kde developer even WANTS to support the new version, but he didn't get the documentation he needs for that (and asked for weeks ago)! (Lack of documentation is a real issue for this stuff. When I did the KDM ConsoleKit patch, I had to look at source code, both of ConsoleKit and of GDM, to figure out what the heck was going on.)
Kevin Kofler
On Wed, 2009-05-13 at 21:00 -0400, Matthias Clasen wrote:
Just a heads-up:
We hope to land a new PolicyKit version (which will turn into 1.0, eventually) in F12 soon.
PolicyKit 0.92 has now landed in rawhide; the package name has changed to polkit and polkit-gnome, to allow it to coexist with PolicyKit 0.9 until the transition is completed. David has put a lot of effort into improving the api docs which are included in polkit-devel, which should help in getting the remaining porting done.
Matthias
devel@lists.stg.fedoraproject.org
-
D. Hugh Redelmeier -
Daniel P. Berrange -
Daniel Veillard -
David Zeuthen -
Jaroslav Reznik -
Kevin Kofler -
Matthias Clasen -
Rex Dieter -
Richard Hughes