14:06:06 <Kevin_Kofler> #startmeeting KDE SIG Meeting - https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-01
14:06:06 <zodbot> Meeting started Tue Sep  1 14:06:06 2009 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:06:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:06:14 <Kevin_Kofler> #topic Init
14:06:40 <Kevin_Kofler> #chair than rdieter ltinkl jreznik svahl mathstuf SMParrish
14:06:40 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl mathstuf rdieter svahl than
14:07:00 * Kevin_Kofler is present (obviously). ;-)
14:07:08 <than> present
14:07:12 <ltinkl> here
14:07:14 <mathstuf> here
14:07:18 <SMParrish> here
14:07:19 * jreznik is here and there...
14:07:22 <mathstuf> until :40 due to class at 11
14:07:24 * svahl is here
14:07:59 <Kevin_Kofler> OK, anything to add to the agenda?
14:08:09 <than> add KDE 4.3.1
14:08:32 <Kevin_Kofler> Done, anything else?
14:09:23 <Kevin_Kofler> #topic PolicyKit - final decision
14:09:55 <Kevin_Kofler> OK, so it looks like basically nothing uses polkit-qt in Rawhide now that KPK stopped using it. Remaining users:
14:09:58 <jreznik> ok, we should decide what to do with polkit-qt and policykit-kde & PK1
14:10:12 <Kevin_Kofler> * PyKDE4 (but nothing uses the Python bindings to polkit-qt to the best of my knowledge)
14:10:21 <Kevin_Kofler> * PolicyKit-KDE
14:10:32 <than> jreznik, how is the state  polkit-qt with pk1?
14:10:46 <Kevin_Kofler> So my proposal is:
14:10:46 <jreznik> we don't need PolicyKit-KDE as we're going to use Gnome one for now
14:10:52 <Kevin_Kofler> 1. disable the Python bindings for polkit-qt in Rawhide
14:11:07 <Kevin_Kofler> We should do that ASAP, so we catch anything possibly trying to use them.
14:11:42 <Kevin_Kofler> 2. drop the old PolicyKit-KDE and polkit-qt when the "Desktop" (GNOME) Team drops PolicyKit 0.9, which is scheduled before the beta.
14:12:12 <Kevin_Kofler> As long as there's still stuff using PK 0.9 (and I think there are 4 or 5 packages left), it makes sense to keep the auth agent around, but if it's dropped we can just let it die and drop our parts too.
14:12:29 <than> Kevin_Kofler, +1
14:12:33 <Kevin_Kofler> 3. bring in a new polkit-qt only if blessed by upstream and/or needed for the auth agent.
14:12:45 <Kevin_Kofler> 4. bring in a new PolicyKit-KDE once it's actually tested.
14:12:46 <jreznik> looks good, it's better to drop it as I proposed already
14:12:59 <SMParrish> +1 to dropping it
14:13:15 <jreznik> my patch is working, needs polishing but it totally breaks ABI, API & behaviour
14:13:22 <than> jreznik, it's fine with me
14:13:30 <jreznik> and it's not acceptable for me
14:13:31 <Kevin_Kofler> jreznik: We should only package it if we really need it.
14:13:48 <Kevin_Kofler> It doesn't make sense to ship a library only we ship if nothing actually uses it.
14:14:01 <jreznik> for 4.4 KDE are going to use kauth
14:14:06 * thomasj late here
14:14:15 <Kevin_Kofler> It makes sense to ship stuff we need for our own stuff and it makes sense to ship stuff actually used by applications.
14:14:38 <jreznik> for kauth we need pk1 backend too... but firt we need PolicyKit1-qt
14:14:41 <jreznik> first
14:14:53 <jreznik> and auth agent...
14:15:06 <Kevin_Kofler> Well, we'll probably want that polkit-qt port for the kauth backend though.
14:15:10 <Kevin_Kofler> And also for the auth agen.
14:15:13 <Kevin_Kofler> *agent
14:15:18 <Kevin_Kofler> So that might be an argument for shipping it now.
14:15:24 <ltinkl> does the auth agent use polkit-qt1?
14:15:37 <jreznik> ltinkl: from my branch, yes
14:15:37 <ltinkl> or can it eventually use the new libkauth?
14:15:52 <Kevin_Kofler> I think libkauth is not designed to be suitable for writing an auth agent.
14:16:02 <jreznik> ltinkl: you can't use it
14:16:05 <Kevin_Kofler> It's abstracted for apps, it hides the internals the auth agent uses.
14:16:09 <ltinkl> I thought so
14:16:22 <jreznik> as you have to register agent to pk1
14:16:34 <Kevin_Kofler> So I think we will need to ship your code sooner or later anyway.
14:16:53 <jreznik> Kevin_Kofler: I'd like to start from scratch and use DBus directly
14:16:55 <Kevin_Kofler> (or some other code doing the same thing with a different API :-/ )
14:17:00 <Kevin_Kofler> Also for the kauth backend.
14:17:16 <Kevin_Kofler> But we can wait until we actually need it.
14:17:17 <than> jreznik, could you perhaps build the new polkit-qt and upload to somewhere =
14:17:29 <than> so people can test it
14:17:54 <Kevin_Kofler> than: The thing is, you need something to test it with.
14:17:54 <than> http://drfav.wordpress.com/2009/08/31/tokamak-kauth-into-kdelibs/
14:18:03 <than> it looks very good
14:18:07 <jreznik> than: it's not new, it's just port... what we need is new pk-qt
14:18:16 <Kevin_Kofler> We have a non-working auth agent and we don't have a kauth backend yet.
14:18:16 <jreznik> it's first step
14:18:34 <Kevin_Kofler> And nothing in KDE 4.3 uses kauth nor polkit-qt directly (other than the old auth agent).
14:18:35 <jreznik> it's base for auth agent and kauth
14:18:54 <than> yesthe kauth backend for pk1 is still missing
14:19:01 <Kevin_Kofler> So there's no way to really test jreznik's polkit-qt port yet, except for debugging the auth agent.
14:19:03 <jreznik> Kevin_Kofler: Date/Time kcm in KDE 4.4 already uses kauth
14:19:12 <Kevin_Kofler> 4.4, but not 4.3...
14:19:25 <Kevin_Kofler> We're still working on 4.3.x for F12.
14:19:37 <jreznik> it's not worth to work on ported code...
14:19:51 <jreznik> (testing it etc)
14:20:09 <Kevin_Kofler> Why? I'd like to have something working quickly!
14:20:14 <than> jreznik, why?
14:20:15 <Kevin_Kofler> Not wait ages for everything to be rewritten.
14:20:37 <jreznik> ok, so I finish the port
14:20:50 <Kevin_Kofler> And if we get a kauth backend working, all the stuff using kauth now should be able to use the temporary code and later switch to the final one without even a rebuild.
14:20:54 <jreznik> but it's not 1:1 mapping of PK1 API to Qt
14:21:03 <than> Kevin_Kofler, +1
14:21:26 <jreznik> Kevin_Kofler: no, it's not true
14:21:31 <Kevin_Kofler> We'd just need to push a grouped update of polkit-qt, PolicyKit-KDE and kauth.
14:22:12 <Kevin_Kofler> jreznik: Does kauth expose some implementation details from the underlying library as part of its API?
14:22:38 <Kevin_Kofler> (That would make it a poor abstraction layer. We need things like Phonon where you can just plug in another backend at runtime.)
14:22:46 <jreznik> temporary code is not as powerful as current PK1 and it's based on old PK... I'd like to write it around new Authority interface with all functionality...
14:22:57 <jreznik> It's totally abstract
14:23:10 <jreznik> but you have to rewrite backend and rebuild it
14:23:20 <Kevin_Kofler> Well, you'd have to rebuild kauth obviously.
14:23:20 <jreznik> that's all
14:23:29 <Kevin_Kofler> But kauth users shouldn't need to be rebuilt.
14:23:35 <jreznik> yes
14:23:48 <jreznik> I like kauth, it's really very nice, clean
14:23:59 <jreznik> and easy to use, not like all PK :(
14:24:05 <Kevin_Kofler> (It's still not as flexible as Phonon though where you just have to build another backend, not rebuild Phonon.)
14:24:29 <mathstuf> backends would go to workspace i imagine
14:25:03 <Kevin_Kofler> Anyway, I think it doesn't really matter because not much uses kauth yet (in fact we don't even ship it yet).
14:25:36 <Kevin_Kofler> But even if a lot of stuff uses kauth, we'd still just need to rebuild kauth (kdelibs, presumably?) to make it use a better polkit1-qt.
14:25:54 <jreznik> ok, I think we agreed... I'll try to contact Dario... unfortunately they can't work on it, Dario is out of time, Dantti is running Debian...
14:26:50 <Kevin_Kofler> So how will we introduce the new stuff exactly?
14:26:57 <jreznik> it depends on time, maybe port could be used for 4.4 and then new one later... most important thing is to have something
14:27:02 <Kevin_Kofler> I think dropping the current polkit-qt bindings from PyKDE4 is a no brainer.
14:27:17 <Kevin_Kofler> People shouldn't use those at all, they should use bindings to kauth when they get ready.
14:27:30 <Kevin_Kofler> And nothing uses them anyway.
14:27:47 <jreznik> indeed
14:28:00 <Kevin_Kofler> But how do we handle polkit-qt and PolicyKit-KDE? Should I disable PolicyKit-KDE in kdebase-workspace and ask rel-eng to block polkit-qt from dist-f12?
14:28:21 <Kevin_Kofler> Should I do that, but only once PolicyKit 0.9 gets actually dropped (so we still have the auth agent for the remaining users)?
14:28:28 <Kevin_Kofler> (I think the latter makes more sense.)
14:28:50 <Kevin_Kofler> Or do you want to upgrade the stuff in time for F12 so we can skip the blocking entirely?
14:29:05 <jreznik> we can drop once they drop PolicyKit-KDE
14:29:20 <Kevin_Kofler> Once they drop PolicyKit 0.9, you mean?
14:29:26 <jreznik> sorry old PK
14:29:40 <than> Kevin_Kofler, when will PolicyKit 0.9 be droped?
14:29:48 <jreznik> than: before beta
14:29:48 <Kevin_Kofler> They want to do it before F12 Beta.
14:29:49 <than> in F122 beta
14:29:59 <than> s/F122/F12
14:30:09 <Kevin_Kofler> Oh, and should I disable the polkit-qt bindings in kdebindings on all branches or just F12+? (And RHEL6+?)
14:30:21 <jreznik> so there should be no application that needs old PK auth agent in that time
14:30:54 <than> ok, it's better to drop it now
14:31:31 <than> Kevin_Kofler, i think just diable for F12+
14:32:01 <Kevin_Kofler> OK. I'll let you worry about RHEL6. ;-)
14:32:27 <than> it will be disbale for RHEL6 too ;-)
14:32:42 <Kevin_Kofler> #agreed The (apparently unused) polkit-qt bindings in PyKDE4 will be dropped from F12+.
14:34:25 <Kevin_Kofler> So, for the other stuff, we agreed on this, right? "We will disable PolicyKit-KDE in kdebase-workspace and get polkit-qt blocked from dist-f12 in time for F12 Beta, as PolicyKit 0.9 is being dropped. We will work on bringing in PolicyKit 1 versions for F13 and F12 updates."
14:35:04 <jreznik> but in time of KDE 4.4
14:35:21 <than> Kevin_Kofler, yes
14:35:40 <Kevin_Kofler> So: "We will disable PolicyKit-KDE in kdebase-workspace and get polkit-qt blocked from dist-f12 in time for F12 Beta, as PolicyKit 0.9 is being dropped. We will work on bringing in PolicyKit 1 versions and a PolicyKit 1 backend for kauth for F13 and F12 updates (in time for KDE 4.4)." ?
14:35:41 <jreznik> I think I can catch F12 with ported pk1-qt, I just don't like that it's not compatible with KDE 4.3 polkit-qt
14:35:54 <jreznik> yes
14:36:12 <jreznik> it should be solved with upstream... seems I'm upstream now :D
14:36:19 <Kevin_Kofler> #agreed We will disable PolicyKit-KDE in kdebase-workspace and get polkit-qt blocked from dist-f12 in time for F12 Beta, as PolicyKit 0.9 is being dropped. We will work on bringing in PolicyKit 1 versions and a PolicyKit 1 backend for kauth for F13 and F12 updates (in time for KDE 4.4).
14:36:37 <Kevin_Kofler> #topic KDE 4.3.1
14:37:05 <than> we have openssl-1.0 in rawhide
14:37:17 <Kevin_Kofler> So I see ltinkl started syncing the specs to F10/F11. Thanks!
14:37:23 <ltinkl> yup, working on it
14:37:36 <Kevin_Kofler> How's Rawhide going? Is OpenSSL causing any issues?
14:37:49 <than> we need to add openssl-1.0 support in kdelibs
14:38:15 <than> i'm still working on it
14:38:35 <thomasj> Still glibc/prelink issues in rawhide.
14:38:46 <than> the anothe issue in gllibc is now fixed in rawhuide
14:39:07 <than> i even removed the workaround
14:39:15 <Kevin_Kofler> than: OK. spstarr also complained about kdelibs not building with OpenSSL 1.0.
14:39:38 <Kevin_Kofler> We should get the patch into upstream trunk and 4.3 branch if possible.
14:39:48 <than> yes
14:39:52 <Kevin_Kofler> Otherwise KDE developers will complain about having to patch kdelibs to even build at all.
14:40:08 <Kevin_Kofler> And other distros will want to ship to OpenSSL 1.0 sooner or later too.
14:40:21 <Kevin_Kofler> Uh, make that just "ship" or "switch to". ;-)
14:41:18 <Kevin_Kofler> #action than is working on fixing kdelibs to build with OpenSSL 1.0.
14:41:34 <Kevin_Kofler> #action ltinkl is working on F10/F11 updates for KDE 4.3.1.
14:41:35 <mathstuf> wtf
14:41:39 <mathstuf> full disk?
14:41:54 <svahl> are the extragear packages already pre-released?
14:41:56 <mathstuf> i just cleared 8GB
14:41:59 <ltinkl> #info mathstuff has full disk
14:42:01 <mathstuf> ugh
14:42:11 <mathstuf> oops
14:42:13 <thomasj> haha
14:42:14 <ltinkl> :D
14:42:17 <Kevin_Kofler> #undo
14:42:17 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2b21ba0f3c10>
14:42:41 <ltinkl> a little exercise for the meetbot :)
14:42:46 <than> thomasj, andreas is working on the fix for the crash with  LD_BIND_NOW=true
14:43:01 <thomasj> than, cool, thanks for the heads up
14:43:20 <Kevin_Kofler> svahl: I just checked ktown, extragear tarballs for 4.3.1 are up indeed.
14:43:26 <Kevin_Kofler> They got made yesterday.
14:43:41 <Kevin_Kofler> #info KDE 4.3.1 extragear tarballs are now available for packagers.
14:44:06 <svahl> thx. I'll start the work on extragear packages then when ltinkl has prepared the buildroot
14:44:10 <ltinkl> IIRC svahl promised to take care of the extragear stuff
14:44:19 <Kevin_Kofler> Yeah, but he doesn't have access to ktown.
14:44:22 <svahl> ltinkl: right
14:44:37 <ltinkl> aha
14:44:53 <ltinkl> svahl: you should really subscribe to kde-packager and get an account on ktown
14:45:05 <svahl> ltinkl: ok. will try that
14:45:20 <Kevin_Kofler> I think we could just add his SSH key to the ftpuoredhat user.
14:45:55 <than> ltinkl, could you  please upload the extragears packages?
14:45:59 <Kevin_Kofler> Anyway, we'll take care of that stuff after the meeting. :-)
14:46:01 <ltinkl> than: sure
14:46:23 <than> ltinkl, thanks
14:46:43 <Kevin_Kofler> #action ltinkl to upload the extragear tarballs
14:46:57 <Kevin_Kofler> #topic Recent bugs: #520611 - koffice-filters requires koffice-kplato
14:47:09 <Kevin_Kofler> #link https://bugzilla.redhat.com/show_bug.cgi?id=520611
14:47:11 <buggbot> Bug 520611: medium, low, ---, andreas.bierfert, NEW, koffice-filters requires koffice-kplato
14:47:50 <thomasj> svahl, i was interested in packaging skrooge (extragear) is that ok with you?
14:48:20 <svahl> I noticed that because the nightly builds are failing because of a missing requires: http://alt.fedoraproject.org/pub/alt/nightly-composes/kde/logs/20090827.16-FAILED-i386.log
14:48:24 <Kevin_Kofler> thomasj: Packaging new stuff is always welcome. :-)
14:48:44 <thomasj> Kevin_Kofler, cool :) I thought i ask because it's extragear
14:48:47 <svahl> thomasj: sure. I'll just take care of the rebuild for 4.3.1
14:48:55 <Kevin_Kofler> For KOffice, this is the usual problem of filters dragging in everything.
14:49:21 <Kevin_Kofler> We've had that with KOffice 1 too.
14:49:41 <svahl> For the live imges I'd like to reduce koffice to kword, kspread and kpresenter
14:49:55 <Kevin_Kofler> rdieter managed to fix the mess in KOffice 1, we should summon his help again here.
14:49:56 <svahl> s/imges/images
14:50:07 <Kevin_Kofler> Unfortunately, he seems to be absent today.
14:51:45 <svahl> ok. the packages should be fixed until beta freeze. but until then theres no time to hurry
14:52:43 <svahl> so could you ask rdieter for help here?
14:53:30 <Kevin_Kofler> Yes, I will.
14:53:33 <svahl> thx
14:53:59 <Kevin_Kofler> #action Kevin_Kofler will try to sort out koffice-filters dependencies with rdieter.
14:54:45 <Kevin_Kofler> IMHO we should also have a koffice1 package with the stuff not available in KOffice 2 (kinda like kdegames3), at least in time for 0-day updates (we won't be shipping that stuff on the spin anyway).
14:54:51 <Kevin_Kofler> I can have a try at that.
14:55:17 <Kevin_Kofler> But that's all I have to say about KOffice.
14:55:32 <Kevin_Kofler> #topic Open Discussion
14:55:45 <Kevin_Kofler> OK, we're done with the agenda, less than 5 minutes left, anything else to discuss?
14:57:02 <Kevin_Kofler> Looks like not.
14:57:10 <Kevin_Kofler> Closing meeting in 30 seconds.
14:57:39 <Kevin_Kofler> #endmeeting