[11:02] ok, any KDE SIG'ers present? [11:02] Hmm, kde sig moved to just before FPC? That makes it difficult to move FPC time to accommodate Ralf. [11:02] tibbs: we can move, no worries. [11:02] I guess we could open another meeting channel, but then you'd have to split your time. [11:04] rdieter: Hi [11:04] than: looks like it may just be you and me (at our new time slot), for today. [11:04] than: how are things going for you? [11:05] I'm also here, I have a few things to discuss or at least bring up today. [11:05] ok. :) [11:05] what topics would you folks like to discuss today? (I'll gather them+what I have) [11:06] First of all, a heads-up: http://www.redhat.com/archives/fedora-devel-list/2007-April/msg00908.html - Looks like kdm still doesn't work with ConsoleKit, breaking HAL in KDM sessions. :-( [11:08] yuck, than, there's an open bugzilla for ConsoleKit support in kdm, you have anything on that, or will we need to punt? [11:08] punt = using gdm. [11:08] Then there's the redhat-artwork problem and some then KDE 4 packaging (I need a few updates to the Qt 4 packages, but we (rdieter and me) can also discuss this outside of the meeting). [11:08] redhat-artwork problem? [11:08] rdieter: kdm does not yet support Consolkit [11:09] than: I know that, any progress or eta? [11:09] What's needed? A lot of coding? [11:10] * rdieter is guessing no work has been done yet, so at least some coding is required. [11:10] rdieter: i have not yet taken a look at this, bu i guess it will take a lot of coding [11:10] than: how full is your plate/schedule? Is this something you could take a look at before f7 or not? [11:11] i don't see it will be done for Fedora 7 [11:11] I"m not asking for it being done, can/will you at least look at it before f7? [11:12] (I'm not tring to presure you, saying "no, I'm too busy" is ok) [11:13] rdieter: i still have a lot of stuff to do for RHEL update, so i don't think i can take a look at this before f7 [11:13] I'm trying to figure out how much code GDM has to interface with ConsoleKit... [11:14] from davidz's comments, it shouldn't be all that hard, just takes time and understanding. [11:14] Kevin_Kofler: you willing to take a look? [11:14] Yes. [11:14] thanks. [11:14] what exactly is the "redhat-artwork" problem you mentioned? [11:15] and you can summarize the qt4 updates you want/need (for posterity, so it's in the irc log). [11:15] Well, I'd really like to see the Bluecurve KDE theme in F7, but it can't be built because the BR is no longer in Core. [11:15] So I wonder if a redhat-artwork-kde package for Extras with the bits which BR kdelibs-devel would be welcome. [11:16] Kevin_Kolfer: yeah, temporary only, since merge is taking too long, we're gonna push kde -> Extras in the meantime. [11:16] I volunteer to submit it to review, but I need a sponsor. [11:16] redhat-artwork-kde is the stop-gap, -> review please! :) [11:16] I'll sponsor you. [11:16] Oh, is there one submitted already. [11:16] ? [11:16] afaik, no review for it yet. [11:17] I'll submit it. [11:17] I'd say, prioritize the kdm/consolekit work though. [11:17] redhat-artwork-kde should just take a few minutes, if it takes more, I'll look at ConsoleKit first, promised. :-) [11:17] than, Kevin: any other topics you want discussed? [11:18] For Qt 4, I need the following updates to the 4.3 beta in kde-redhat unstable: [11:18] - I need OpenSSL support enabled, as KDE 4 Alpha 1 will require it for the new KNetwork stuff [11:18] See also: http://cniehaus.livejournal.com/36936.html [11:19] kde4 needs strigi too, right? [11:19] rdieter: i will add kde upstream patches (KDE-3.5.7) in next days [11:19] - According to this thread: http://lists.kde.org/?l=kde-core-devel&m=117661384030399&w=2 I need QtDBus (or the entire thing) updated to 20070414 or newer [11:20] than: ok, update in cvs only, don't build anything yet. [11:20] That's the 2 changes I need to Qt 4. Yes, I'll need Strigi too, but I'll take care of that when I package the alpha. [11:20] than: I'd like to see the package splitting happen first/real-soon. [11:21] splitting, as in -extras subpkgs. [11:21] than: sound ok? [11:22] rdieter: yes, i have done for kdegraphic [11:22] do you know which package is still needed to do [11:23] kdeutils [11:23] and kdebase [11:23] that's a start, the rest splits are listed on: http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE [11:23] +kdenetwork, kdemultimedia [11:24] I'm looking at the GDM consolekit code currently, it really looks like just a few lines, I think I can patch that into KDM. [11:24] awesome! [11:25] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228111 post code/patches here [11:25] My last item: kde-settings review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227241 [11:26] rdieter: i will do the package splitting [11:26] than: thanks! [11:26] rdieter: np [11:28] anyone willing to review kde-settings, then we should be pretty well set. [11:30] rdieter: is it ok if we only move kpovmodeler, kfax and kfaxvifew in extras? [11:30] I suppose so, that would be a good start, why only those? [11:32] or do you think the pdf-preview thing is too radical an idea? [11:32] rdieter: i think most people want to have kiconedit, kviewshell, kghostview and kdvi [11:33] in base-package [11:34] ok, we can proceed as you suggest. we can tweak later if needed. [11:35] no takers on reviewing kde-settings? :) [11:36] It should be easy, it's pretty much just a lot of the stuff in /usr/share/config/* /etc/kde/* that *used* to be in kdelibs/kdebase. [11:36] easy, packaging-wise anyway. [11:37] packaging that separately should make modifying those parts much easier (without having to rebuild all or kdelibs and/or kdebase). [11:39] ok, well, we can table that for now, I'll beg (others) later.. :) [11:40] any other topics (otherwise I've got a few to use up the time)? [11:41] ok, since I've got your(than's) ear, a few controversial kde packaging topics.. :) [11:42] since I'm available to actually do the work/cleanup/triaging to make these happen... [11:43] 1. make kdelibs-apidocs noarch. [11:43] pro: save repo space, since we can have a common/shared pkg for all archs [11:44] con: it's packaged separately (ie, separate src.rpm), more packager work. [11:45] pro: speeds core kdelibs builds (since apidocs isn't (re)built *every* respin). [11:45] comments? [11:46] (fyi, the doxygen apidocs generate takes a long time, almost as long as compiling all of kdelibs) [11:46] rdieter: in this case we have to make 2 srpms, it's bad [11:47] depends which you consider more bad: 2 srpms vs. 1 arch-specific rpm for *every* arch, mind you. :) [11:49] imo, 2 srpms is the lesser evil. [11:49] any other comments? [11:50] speed up doxygen? :) [11:50] * rdieter left my "speed-up-doxygen" magic wand in my other pants. [11:51] ok, and controversial topic 2: stripping libtool baggage, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170602 [11:52] than: I know you were against that before, but this time, I'm willing to do the work/implementation, and take the heat for imposed breakage. [11:54] I'd like to at least explore these 2 ideas. [11:54] rdieter: i expect it should be done in KDE upstream [11:55] than: of course, upstream is/would-be best, but kde-3.5.x is pretty much maintainance-mode only now, and they won't touch libtool modifcations with a 10-foot pole. [11:56] than: any other objections? [11:57] rdieter: i have now a meeting, can we talk over this in next meeting? [11:57] than: sure. [11:57] we're out of time anyway for today. [11:57] Thanks!