Re: PolicyKit changes in F12
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
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 Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
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 ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
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 > > | > > | 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 :| -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Mon, May 25, 2009 at 02:22:02PM -0400, D. Hugh Redelmeier wrote: > | From: Rex Dieter > > | 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 -- |: 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 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
| From: Rex Dieter | 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). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
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. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
Caroline Meeks wrote: > Luke and Sasha are working on a new USB format that they feel will allow > more machines to boot and support VM + Stick > > http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/USB_format > > Perhaps the issue you are running into (which we have definitely seen > before) is related to some of the ones they are looking at and part of > why they need two boot partitions that are slightly different. > I don't understand why 128 heads. 64 heads is the more compatible version. I presume the notion of partition 1 and 4 is to deal with things that have an odd notion of zipdisks. I have personally not seen any devices which will only boot with partition 1 or only with partition 4, if you have any such information I would appreciate it. Part of me also wonders if using EXTLINUX might not be easier for you, too. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Mon, 1 Jun 2009, Richard W.M. Jones wrote: On Mon, Jun 01, 2009 at 12:07:45PM -0400, Seth Vidal wrote: The biggest problem is gonna be uploading it over my *$!* ADSL connection. I wasn't looking for hosting, just for somewhere to store the tracker. It's my understanding (possibly incorrect) that the initial seed and the tracker are separate things which don't need to be kept at the same location. They don't and if you want us to serve as the tracker but NOT as primary seed then I think that can be worked out, too. Essentially you'd make a .torrent file with our tracker info in it - send us the .torrent file. We'll drop it in the holding path for the tracker and, ultimately, for our seed. so we'd start downloading it, too. or, alternatively, I could see about setting up a tracker-only non-seed path for our current tracker so that we could just track but not seed. Provided your seed would be doing all the bit-pushing work :) -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
