Feb 05 17:02:41 *	rdieter hat das Thema geändert zu: KDE SIG meeting -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-02-05 -- Init
Feb 05 17:02:53 rdieter		kde sig meeting about to start... wee.
Feb 05 17:03:12 rdieter		Who's here today?  ping: than, ltinkl, Kevin_Kofler, svahl, foo*
Feb 05 17:03:17 Kevin_Kofler	Present.
Feb 05 17:03:18 ltinkl		here
Feb 05 17:03:22 svahl		present (partly)
Feb 05 17:03:44 than		present
Feb 05 17:04:16 *	rdieter hat das Thema geändert zu: KDE SIG meeting -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-02-05 -- kde-4.0.1/F9-alpha
Feb 05 17:04:36 rdieter		let's smerge the first two topics:  kde-4.0.1/f9-alpha.
Feb 05 17:04:59 rdieter		f9-alpha is  today (~1 hr ago).
Feb 05 17:05:12 rdieter		kde-4.0.1 is due (officially) tomorrow.
Feb 05 17:05:34 Kevin_Kofler	And it's already in Rawhide. :-)
Feb 05 17:05:50 Kevin_Kofler	Are you going to build it for kde-redhat unstable too? When?
Feb 05 17:06:02 rdieter		one thing I wanted to discuss today, so we might as well get it out of the way, was backported patches/features.
Feb 05 17:06:44 rdieter		all well and good, but I don't want to find ourselves in a position where other distros find themselves...
Feb 05 17:07:01 Kevin_Kofler	This problem should be mostly gone with 4.1.
Feb 05 17:07:09 rdieter		carrying large patchsets, and not really resembling stock/upstream anymore.
Feb 05 17:07:22 Kevin_Kofler	I've been backporting some minor Plasma feature additions from 4.1.
Feb 05 17:07:33 Kevin_Kofler	(2 of them, more precisely)
Feb 05 17:07:46 Kevin_Kofler	I think both should make the panel much nicer to use.
Feb 05 17:07:55 rdieter		If thinks make sense to be backported, I'd rather energy be focussed on getting these backported/merged upstream, imo.
Feb 05 17:08:04 rdieter		s/thinks/things/
Feb 05 17:08:16 Kevin_Kofler	Hopefully with 4.1 and later there won't be as much a need to backport Plasma stuff.
Feb 05 17:08:32 rdieter		true, but 4.1 won't be in time for f9.
Feb 05 17:08:53 ltinkl		agree with the backports, if it gets tested and doesn't break other stuff (also translations)
Feb 05 17:09:27 Kevin_Kofler	We'll probably update F9 to 4.1 when it comes out though.
Feb 05 17:09:40 rdieter		backports here (in fedora) or upstream?  If not upstream, why not?
Feb 05 17:10:23 Kevin_Kofler	These backports might be running afoul of the string freeze. That also answers ltinkl's question about translations: they won't be really broken, but there will be a couple of untranslated messages.
Feb 05 17:10:37 ltinkl		upstream has strict rules about branches being feature- and message-frozen
Feb 05 17:10:53 Kevin_Kofler	The configuration stuff required by the simple menu changes introduces a few messages.
Feb 05 17:11:20 Kevin_Kofler	So that'd need both a feature freeze exemption and a string freeze exemption.
Feb 05 17:11:34 rdieter		ltinkl: and for good reason, what's the rationale for *us* then to not follow that too?  (esp now, so early in f9 developement)
Feb 05 17:11:54 Kevin_Kofler	Why would we want to feature freeze so early in F9 development?
Feb 05 17:12:12 rdieter		Kevin_Kofler: not my point, why care about pushing new features now?
Feb 05 17:12:33 Kevin_Kofler	Because they're unlikely to end up in 4.0 ever, so why not backport them now?
Feb 05 17:12:45 rdieter		just hypothetical mind you, I'd rather focus on big picture stuff.
Feb 05 17:13:04 Kevin_Kofler	IMHO making the simple menu show the actual names of applications is "big picture stuff".
Feb 05 17:13:07 rdieter		Kevin_Kofler: counter question: if 4.1 is to happen soon after f9, why not wait?
Feb 05 17:13:52 warren		what is plasma?
Feb 05 17:13:57 rdieter		I have no vested interest in the final decision, I just want to make sure we konw exactly why we're doing it, and make sure it's a well founded decision.
Feb 05 17:14:08 ltinkl		imo user shouldn't be shown the application name (ktuberling wtf) but some meaningful text, but that's another point
Feb 05 17:14:18 Kevin_Kofler	We'd be hypocrites if we shipped a simple menu showing generic names only while at the same time complaining about the desktop team's "put generic name in Name" practise. ;-)
Feb 05 17:14:56 Kevin_Kofler	ltinkl: They're shown both the descriptive GenericName and the Name by default.
Feb 05 17:15:11 rdieter		warren: http://techbase.kde.org/index.php?title=Projects/Plasma
Feb 05 17:15:11 ltinkl		fine then :)
Feb 05 17:15:19 svahl		well, do we consider simple menu as a replacement for kickoff or as an addon? I remember some discussion in former meetings
Feb 05 17:16:02 Kevin_Kofler	That's another issue. ;-) Even if it's not the default, it should not suck. ;-)
Feb 05 17:17:31 Kevin_Kofler	Oh, and there's another backport I did, which is the Okular system libspectre patch. I did that one because it's part of our packaging guidelines to use system libraries where possible.
Feb 05 17:18:25 rdieter		Kevin_Kofler: not that I disagree with that, I don't, but why not also try pushing that upstream?
Feb 05 17:18:58 Kevin_Kofler	Upstream is very well aware of the situation, but they don't want to introduce the added dependency in the 4.0 branch.
Feb 05 17:19:29 rdieter		Kevin_Kofler: ugh, I don't agree with that, but ok. :)  thx
Feb 05 17:19:44 Kevin_Kofler	See http://tsdgeos.blogspot.com/2008/02/okular-and-libspectre.html
Feb 05 17:20:08 rdieter		alrightly, I think I've beaten this to death enough, move on?
Feb 05 17:20:44 *	rdieter hat das Thema geändert zu: KDE SIG meeting -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-02-05 -- Release note planning http://fedoraproject.org/wiki/Releases/FeatureKDE4#head-f0d9e48dee79abc990b7d055bc4552c1f2395eec
Feb 05 17:20:57 rdieter		topic 2: release notes planning, docs, etc...
Feb 05 17:21:42 Kevin_Kofler	We had this one last week already, but not much was said. If you can think of anything which should be in the release notes and which I didn't list there, please say so.
Feb 05 17:21:58 rdieter		someone (sorry, forget name offhand) from docs is helping out here (esp with DUG) already.
Feb 05 17:22:05 Kevin_Kofler	Otherwise, I'll take it that the list is just fine, I don't think bringing this up every week makes sense. ;-)
Feb 05 17:22:35 Kevin_Kofler	We can always bring it back up if someone can think of something to actually add.
Feb 05 17:22:39 rdieter		blame me, I copied some of the agenda items from last week, end result = bad. :)
Feb 05 17:23:10 *	rdieter hat das Thema geändert zu: KDE SIG meeting -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-02-05 -- kde-l10n status (still busted?)
Feb 05 17:23:20 rdieter		next topic: kde-l10n status (still busted?)
Feb 05 17:23:41 rdieter		than, ltinkl: any updates, or still busted?
Feb 05 17:23:55 ltinkl		busted, working on it (short version)
Feb 05 17:23:58 ltinkl		long version:
Feb 05 17:24:20 *	rdieter is afraid of the long version... :)
Feb 05 17:24:29 ltinkl		the upstream docbook files are broken but the good thing is that the tarballs already contain pregenerated HTML caches
Feb 05 17:24:39 Kevin_Kofler	That's going to be a big problem if it isn't fixed soon, shipping KDE 4 with KDE 3 translations only means we'll have lots of untranslated messages (all of kdelibs, which uses a separate .po file, lots of app messages too).
Feb 05 17:24:48 ltinkl		so we will somehow work around it
Feb 05 17:25:25 rdieter		that's something positive anyway, thx!
Feb 05 17:26:01 Kevin_Kofler	What we'll also have to do is resolve the conflicts with kde-i18n (ship only the parts of kde-i18n which don't conflict).
Feb 05 17:26:34 Kevin_Kofler	Another related question: who should own oktetapart.mo?
Feb 05 17:26:34 rdieter		yup, we'll tackle that as soon as kde-l10n is buildable.
Feb 05 17:26:59 Kevin_Kofler	kde-l10n contains a version matching the sources from the 4.0 branch which aren't actually built.
Feb 05 17:27:09 than		rdieter: i hope to finish kde-l10n build in next hour
Feb 05 17:27:37 rdieter		Kevin_Kofler: kde-l10n?
Feb 05 17:27:37 Kevin_Kofler	The playground-utils translation module contains its own version for the playground/utils/okteta/ version of the oktetapart, but much fewer translation.
Feb 05 17:27:42 Kevin_Kofler	So I guess it's best if kde-l10n owns that file.
Feb 05 17:27:48 ltinkl		definitely
Feb 05 17:28:15 rdieter		well, the remaining topic items are lame from me, so I'll skip those, and open things up for free discussion.
Feb 05 17:28:23 *	rdieter hat das Thema geändert zu: KDE SIG meeting -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-02-05 -- open discussion
Feb 05 17:28:43 rdieter		skipped: "creating our own defaults.list (see also shared-mime-info, XDG_CONFIG_DATA)" since I hadn't actually worked on that yet.
Feb 05 17:28:54 ltinkl		what about the livecd? will it contain the newly imported KDE 4.0.1?
Feb 05 17:29:09 Kevin_Kofler	There's still the "remaining KDE4Status work items" part which I added.
Feb 05 17:29:26 Kevin_Kofler	I updated http://fedoraproject.org/wiki/SIGs/KDE/KDE4Status to reflect what has already been done.
Feb 05 17:29:27 rdieter		ltinkl: I think 4.0.1 missed f9-alpha (but I'm not 100% sure)
Feb 05 17:29:29 svahl		ltinkl, the alpha contains kde-4.0.0 because the freeze was some time ago
Feb 05 17:29:53 Kevin_Kofler	We should check what parts of "MOSTLY DONE" stuff can be marked "DONE", and do the necessary testing for the others.
Feb 05 17:30:02 Kevin_Kofler	And we shouls look at the directory ownership issue.
Feb 05 17:30:25 Kevin_Kofler	Several directories in %{kde4_appsdir} have too many owners.
Feb 05 17:30:58 Kevin_Kofler	But that's a detail, what's more important is testing the upgrade path and working with the feedback we have already.
Feb 05 17:31:33 Kevin_Kofler	fengshaun reported several cases where packages were not upgraded properly, resulting in file conflicts, maybe some well-placed versioned Conflicts: tags can help that.
Feb 05 17:32:01 rdieter		ah, upgrade path: kdebase -> kdebase + kdebase-workspace is one that's not ideal (see recent thread on fedora-testing list).
Feb 05 17:32:20 svahl		I'll submit kiconedit and kcoloredit for review, when I'm back home again (the next days)
Feb 05 17:32:33 Kevin_Kofler	That's one issue. I think having kdebase-workspace require kdebase4 even if not strictly required is the only real way out of this.
Feb 05 17:33:10 rdieter		nod, I can't imagine anyone installing kdebase-workspace and *not* wanting kdebase too. :)
Feb 05 17:33:22 Kevin_Kofler	At least the only one which doesn't involve annoying dummy metapackages.
Feb 05 17:33:25 ltinkl		the workspace in fact requires the rest of kdebase to work properly
Feb 05 17:33:45 rdieter		ltinkl: really?  how so?
Feb 05 17:34:13 rdieter		if true, that's just plain a bug, but maybe not worth worrying about beyond simply adding the Requires: kdebase4
Feb 05 17:34:43 Kevin_Kofler	Well, you'll end up with no file manager, some missing system-settings modules etc. if you have kdebase-workspace and kdebase-runtime only, no kdebase.
Feb 05 17:36:10 rdieter		I guess depends on your definition of "work properly".   ok, any objections to adding to kdebase-workspace: Requires: kdebase4  ?
Feb 05 17:36:41 ltinkl		yup, more like work properly
Feb 05 17:37:45 Kevin_Kofler	No objections here, I was the one who suggested it after all. ;-)
Feb 05 17:37:55 svahl		+1 for Requires: kdebase4
Feb 05 17:38:25 rdieter		+1 here too.
Feb 05 17:38:55 rdieter		I'd say just fo r fun, make it (something like): Requires(hint): kdebase4
Feb 05 17:39:25 Kevin_Kofler	Our RPM is going to ignore that anyway though, isn't it?
Feb 05 17:39:58 rdieter		it'll treat it as a hard requires, until rpm supports soft deps.
Feb 05 17:40:18 Kevin_Kofler	That's what I meant with "ignore", sorry for having been unclear.
Feb 05 17:41:29 rdieter		I'll do the adding of the new dep (unless someone else volunteers).
Feb 05 17:42:25 rdieter		one thing to add as a big TODO item is auditing selinux issues.  it appears kde4 is still throwing lots of selinux exceptions on my box in targeted/permissive.
Feb 05 17:43:13 Kevin_Kofler	Sigh...
Feb 05 17:43:18 *	Kevin_Kofler hates SELinux.
Feb 05 17:43:42 Kevin_Kofler	All it ever does is break things.
Feb 05 17:44:14 *	rdieter wishes for an selinux "learning" mode, in which it could automatically create allow rules as needed.
Feb 05 17:44:17 dgilmore	rdieter: mine is also
Feb 05 17:45:28 *	Kevin_Kofler thinks we should turn off SELinux on the KDE spin, but knows very well that's not going to resonate well with the rest of the Fedora Project.
Feb 05 17:45:44 dgilmore	Kevin_Kofler: thats not really an option
Feb 05 17:47:25 dgilmore	I need to file a bug but ive found that twinkle crashed plasma
Feb 05 17:47:28 dgilmore	crashes
Feb 05 17:49:33 rdieter		something on my rawhide lappy, in xdg/autostart is crashing plasma as well.  ugh.
Feb 05 17:50:20 dgilmore	of course bugzilla is unusable right now on rawhide
Feb 05 17:50:23 Kevin_Kofler	Oh, another question: What's the state of knetworkmanager?
Feb 05 17:50:36 dgilmore	it causes konq and FF to hang with its javascript
Feb 05 17:51:06 rdieter		dgilmore: worksforme (using both konq/ff3)
Feb 05 17:51:09 dgilmore	I've honestly not tried to do a recent svn checkout and see if it even builds
Feb 05 17:51:29 svahl		FYI: ksystemlog was accepted for kde-4.1 (afaik): http://ksystemlog.forum-software.org/  Maybe it is worth to package it for f9 already (I could have a try but will likely need some help with the kdesu/consolehelper stuff)
Feb 05 17:51:38 dgilmore	rdieter: fun  i got both browsers locked up last night trying to add a bug
Feb 05 17:52:04 Kevin_Kofler	If it still fails to build, I'd like some build logs for a recent snapshot from knetworkmanager-0.7 so I can try to fix it.
Feb 05 17:52:21 Kevin_Kofler	I know OpenSUSE got it to build in Factory, so it can't be completely impossible to compile that thing.
Feb 05 17:52:32 dgilmore	Kevin_Kofler: sure.  Last i knew the porting work was still incomplete to the new API
Feb 05 17:52:45 ltinkl		Kevin_Kofler: but it's still a KDE 3 app
Feb 05 17:52:55 dgilmore	Kevin_Kofler: ill try get a build done today
Feb 05 17:53:03 Kevin_Kofler	Yes, but a kdelibs3 applet is still an improvement over a gtk2 one IMHO. ;-)
Feb 05 17:53:13 dgilmore	ltinkl: many things are still kde3
Feb 05 17:53:22 ltinkl		I know, just a remark
Feb 05 17:53:46 Kevin_Kofler	They know a KDE 4 version will be needed, but let them do one port at a time.
Feb 05 17:53:57 Kevin_Kofler	It's already enough work to port to NM 0.7.
Feb 05 17:54:40 dgilmore	new features need adding also
Feb 05 17:57:28 rdieter		a fun new bug to keep an eye on: https://bugzilla.redhat.com/show_bug.cgi?id=431398
Feb 05 17:57:41 buggbot		Bug 431398: medium, low, ---, Ngo Than, ASSIGNED , kdm instantly crashes (without xfs running)
Feb 05 17:58:18 rdieter		from all accounts, would appear some font* pkg scriplets aren't generating fonts.dir (and friends) properly.
Feb 05 17:58:48 svahl		mhh. on the live images there is no xfs since a long time. And I've not seen crashed due to that
Feb 05 18:03:40 rdieter		time's up for today, we can continue on in #fedora-kde
Feb 05 18:03:50 rdieter		kde sig meeting end, thanks all.