14:13:59 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-04-20
14:14:00 <zodbot> Meeting started Tue Apr 20 14:13:59 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:14:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:14:03 <rdieter> #meetingname kde-sig
14:14:05 <zodbot> The meeting name has been set to 'kde-sig'
14:14:22 <rdieter> #chair Kevin_Kofler than ltinkl jreznik SMParrish
14:14:22 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl rdieter than
14:14:28 <rdieter> #topic roll call
14:14:32 <rdieter> who's present today?
14:14:34 <Kevin_Kofler> Present.
14:14:36 * ltinkl is present
14:14:45 * than is present
14:15:21 <jreznik> jreznik is present
14:15:24 * thomasj_ is here as well
14:15:36 <rdieter> #info Kevin_Kofler ltinkl than jreznik thomasj_ present
14:15:37 * jreznik is jreznik :)
14:15:49 <rdieter> #topic agenda
14:16:05 <rdieter> we have a light agenda today (kimpanel), anything else to discuss today?
14:16:34 * rdieter can give an update on vlc/phonon-vlc status, if folks are interested
14:16:50 <thomasj_> interested yes
14:18:45 <rdieter> #topic vlc/phonon-vlc status
14:18:56 <rdieter> vlc pkg review, https://bugzilla.redhat.com/show_bug.cgi?id=583236
14:19:15 <rdieter> spot was kind enough to do an initial legal review of what needs to be omitted
14:19:29 <rdieter> I've got initial vlc/phonon-backend-vlc builds in kde-unstable repo for testing
14:19:43 <rdieter> the initial builds are non-split vlc-1.1.0 atm
14:19:50 <rdieter> 1.1.0 snapshot that is
14:20:14 <Kevin_Kofler> So this really needs a -libs subpackage.
14:20:22 <Kevin_Kofler> Even vlc-core contains executables.
14:20:39 <rdieter> probably, I'll continue to work with kwizart to get the vlc packaging into shape for fedora
14:20:40 <Kevin_Kofler> Plus, some of the plugins in the GUI portion will also be needed for Phonon.
14:20:46 <ltinkl> rdieter: so are there any legal problems with vlc? how much effort the splitting will take?
14:21:07 <rdieter> ltinkl: the legal items have been identified, and will be removed when moved into fedora
14:21:36 <rdieter> splitting will take a little bit of work (ie, making a vlc-freeworld package for the patented bits)
14:22:12 <rdieter> was a little depressing that some had 'claimed' other distros had done this splitting already and that it was 'easy''
14:22:22 <rdieter> fact is... no one seems to have done it yet afaict.
14:22:24 <than> rdieter: do we have a url to the legal items?
14:22:37 <rdieter> than: see the bz link above
14:22:44 <rdieter> .bug 583236
14:22:47 <zodbot> rdieter: Bug 583236 Review Request: vlc - The cross-platform open-source multimedia framework, player and server - https://bugzilla.redhat.com/show_bug.cgi?id=583236
14:22:57 <than> rdieter: ah, thanks
14:23:09 <Kevin_Kofler> Some files under modules/codec need to be stripped out and of course we can't BR stuff like ffmpeg-devel.
14:23:22 <rdieter> so we''ll likely be blazing a fresh trail here
14:24:18 <rdieter> vlc upstream was receptive (so far) to the idea of possibly splitting out patented bits upstream, so that downstreams (like us) wouldn't have to do it.
14:25:07 <rdieter> my similar request to xine-lib developers was met largely with silence (and one response that they weren't interested in the extra work in doing it)
14:25:27 <rdieter> (even though I volunteered to help with the work)
14:25:52 <rdieter> but, that's a bit offtopic to the topic at hand
14:26:28 <rdieter> any questions, comments?  move on?
14:27:25 <than> move on please
14:27:29 <Kevin_Kofler> So my comment is that we probably need vlc-core-libs and vlc-libs subpackages for the stuff shared with Phonon.
14:27:45 <rdieter> Kevin_Kofler: yes (or something similar to that)
14:27:50 <Kevin_Kofler> (This includes some plugins, not just libs directly in libdir.)
14:28:32 <rdieter> #topic enable kimplanel, https://bugzilla.redhat.com/show_bug.cgi?id=583545
14:28:39 <rdieter> .bug 583545
14:28:42 <zodbot> rdieter: Bug 583545 Enable building Kimpanel and make a subpackage for it - https://bugzilla.redhat.com/show_bug.cgi?id=583545
14:28:48 <rdieter> #topic enable kimpanel, https://bugzilla.redhat.com/show_bug.cgi?id=583545
14:28:53 <rdieter> better. :)
14:29:40 <rdieter> this is out of my league, though sounds vaguely like a reasonable idea.  comments?
14:30:08 <Kevin_Kofler> Yeah, we really want this working.
14:30:15 <Kevin_Kofler> It seems like we're getting somewhere now.
14:30:40 <Kevin_Kofler> Automatic detection of the required IBus backend in ibus.conf, subpackage, build without SCIM etc.
14:31:00 <Kevin_Kofler> I think all we're missing now is a Plasma script to add the plasmoid to the panel (or systray if possible and useful).
14:31:15 <Kevin_Kofler> I guess I can write that script if that's going to be the blocking issue.
14:31:36 <rdieter> ok, based on that, maybe a first step would be to enable a -kimpanel subpkg, and continue working out the remaining details.
14:32:19 <rdieter> who wants or can work on this?   Kevin_Kofler sounds like a good possible candidate. :)
14:33:04 <than> Kevin_Kofler: we should test it well
14:33:10 <Kevin_Kofler> I can work on this together with the folks who are posting the patches to the bug reports.
14:33:40 <Kevin_Kofler> But I'm a poor candidate for the testing part, sure I can install it and try to enter some random characters, but I don't speak a word of any of those languages which use input methods.
14:33:41 <rdieter> based on that bug, it's also becoming clear to me that we could take this opportunity to fix/standardize plasma-related package naming.  Start switching to plasma-* instead of kde-plasma-*
14:34:07 <Kevin_Kofler> Well, there might be one for French diacritics or something, but that's not the one most useful to test with. ;-)
14:34:53 <Kevin_Kofler> What's wrong with kde-plasma-*?
14:35:06 <Kevin_Kofler> I think the plasma-* packages are the ones which need fixing.
14:35:10 <than> Kevin_Kofler: i think the reporter could test it
14:35:15 <rdieter> I'm starting to think the kde- prefix is superfluous is all
14:35:31 <rdieter> but that's a separate issue I guess.
14:36:39 <rdieter> esp if we're going to continue with adding plasma-related Provides for stuff like plasma-dataengine-foo
14:37:23 * jreznik is totally lost in these areas - I'm not even using Czech diacritics...
14:37:56 <Kevin_Kofler> Time to write an FPC guideline for Plasma package naming?
14:38:03 <rdieter> #info Kevin_Kofler will initially lead efforts to get kimpanel into shape
14:38:16 <rdieter> Kevin_Kofler: maybe
14:38:38 <Kevin_Kofler> It may be useful to distinguish the different types of components: applets, dataengines etc.
14:38:53 <rdieter> exactly.
14:39:07 <ltinkl> what if the package ships both?
14:39:21 <ltinkl> dataengine and widget
14:39:28 <rdieter> ltinkl: then split it or add the appropriate Provides:
14:39:47 <rdieter> see ktorrent packaging for example
14:40:01 <jreznik> a little overcomplicated...
14:40:02 <Kevin_Kofler> Maybe have just kde-plasma-{name} for applets/widgets/plasmoids, with or without a dataengine.
14:40:06 <rdieter> the main package provides the dataengine, and there's a plasma applet subpkg
14:40:14 <Kevin_Kofler> And kde-plasma-dataengine-{name} for pure dataengine packages.
14:40:31 <rdieter> #topic plasma pkg/provides naming
14:40:39 * ltinkl too thinks this is too complicated :)
14:40:44 <rdieter> there's more than just applets and dataengines too, mind you
14:40:52 <rdieter> but those are the 2 main cases
14:40:53 <ltinkl> I know
14:40:59 <Kevin_Kofler> Script engines?
14:41:05 <Kevin_Kofler> kde-plasma-scriptengine-{name} :-)
14:41:06 <rdieter> yep, scriptengines too
14:41:30 <Kevin_Kofler> IMHO, plasmoids are the most user-visible stuff and should have simple names.
14:41:39 <ltinkl> what about the ions? are they packaged separately somewhere?
14:41:40 <rdieter> we can keep the kde- prefix I guess, I just think it's not needed.  anyone who doesn't get a know that plasma is associated with kde anymore is living under a rock
14:41:47 <Kevin_Kofler> How they're implemented, with an included dataengine or not, is something the user doesn't care about.
14:42:02 <Kevin_Kofler> There'd just be a Provides for the dataengine in case something else wants to use it too.
14:42:22 <Kevin_Kofler> Stuff like data engines and script engines are used like libraries, so having "dataengine" or "scriptengine" in the name there fully makes sense.
14:42:34 <rdieter> Kevin_Kofler: +1
14:42:35 <Kevin_Kofler> We want to make sure the user doesn't think he's installing a new plasmoid there.
14:42:36 <ltinkl> ok, I agree
14:42:47 <ltinkl> makes sense
14:43:01 <rdieter> maybe I need to do a little more work on my rpm autoprovides script for that stuff
14:43:50 <rdieter> haven't touched that in awhile, but if those items were all automatically generated by rpm, could make our life a lot simpler
14:44:30 <rdieter> prudent splitting out of dataengines and scriptengines still makes sense regardless.
14:45:01 <Kevin_Kofler> Well, in theory, sure.
14:45:42 <rdieter> #link http://rdieter.livejournal.com/14897.html
14:45:49 <rdieter> re my last blog on the topic awhile back
14:45:56 <Kevin_Kofler> In practice, if you have a widget which does something really exotic and which ships its own data engine for some reason, e.g. because the widget is in JavaScript and the data engine in C++, but nothing else ever wants to use that data engine, does it really make sense to split it out?
14:46:09 <Kevin_Kofler> There would be a Provides in case something really wants to require the data engine.
14:46:28 <Kevin_Kofler> But if you think they should always be split out, I'm not opposed to that either.
14:46:48 <Kevin_Kofler> (but core KDE modules should be exceptions to that, it doesn't make sense to split out data engines from kdebase-workspace ;-) )
14:46:52 <rdieter> no, not always split.  Keep things simple where it makes most sense, and split also only where it makes sense to do so
14:47:11 <rdieter> common sense ftw
14:47:46 <thomasj_> Isn't that what we already do?
14:47:54 <thomasj_> Common sense i mean
14:48:35 <jreznik> thomasj_: +1
14:48:39 <rdieter> yes
14:48:57 <rdieter> we're only outlining the pkg naming for when splitting does make sense
14:49:18 <rdieter> and for what Provides/Requires to use accordingly
14:49:20 <thomasj_> Ok, thought it goes deeper :)
14:49:41 <Kevin_Kofler> So the big question is: keep kde-plasma-* as the prefix or use just plasma-*?
14:49:56 * thomasj_ thinks kde-plasma is good
14:50:00 <Kevin_Kofler> All the existing packages would need to be renamed if we switched to plasma-*.
14:50:25 <jreznik> plasma-* is ok but renaming...
14:50:26 <thomasj_> There are lots of users out there who *don't* know that plasma is part of KDE SC.
14:50:29 <rdieter> we've got a bunch of existing Provides/Requires already using plasma-dataengine and plasma-scriptengine too
14:51:11 <rdieter> so switching things to be consistent is going to require a bit of churn/work regardless
14:51:27 <rdieter> though, existing kde-plasma pkgs could just Provides: plasma-* foo in the meantime
14:51:30 * thomasj_ recalls that from #fedora.. Questions like "what is plasma?"
14:51:56 <rdieter> thomasj_: by that logic, we should drop plasma from the naming altogether?
14:52:10 <thomasj_> no
14:52:22 <thomasj_> I just mean keeping kde-plasma-*
14:52:29 <rdieter> perhaps for this (and other?) reasons, it seems kubuntu uses kde-widget-* naming
14:52:45 <than> why can we use kdeplasma-*
14:53:10 <rdieter> I don't like kdeplasma, I'd prefer keeping kde-plasma in that case
14:53:26 <jreznik> another think is - a lot of "plasmoids" are shipped by their upstream as kde-plasma-*
14:53:41 <rdieter> jreznik: really?
14:53:46 <jreznik> rdieter: no, sorry
14:53:51 <jreznik> I'm just tired :)
14:54:19 <rdieter> alright, there seems to be most support for keeping kde-plasma , so let's just do that then I guess
14:55:04 <rdieter> anyone (besides me?) interested in helping to write up a draft of some naming guidelines?
14:55:09 <Kevin_Kofler> If upstream uses Fedora, it's quite conceivable that they'd use our kde-plasma-* naming for their tarballs. :-)
14:55:10 <jreznik> another thing - we have kde-plasma-*, kdeplasma-addons...
14:55:41 <rdieter> consulting with #phonon folks will be part of the job here too
14:55:49 <rdieter> erm... #plasma that is
14:55:50 <jreznik> rdieter: #plasma
14:56:05 * rdieter has been hanging out in #phonon too much lately. :)
14:56:48 <jreznik> I'm not against plasma-*, it makes sense... as there's no other plasma in fedora... I just don't see importance of renaming
14:56:59 <rdieter> #action rdieter to work on drafting some kde/plasma relating naming guidelines
14:57:07 <jreznik> just shorterter package name (that could be useful but)
14:57:20 <rdieter> jreznik: there's going to be change regardless, to make things consistent.
14:57:39 <rdieter> plasma-* is used already too (mostly in Provides/Requires though)
14:58:05 <jreznik> yes, we need it consistent - not only with plasma but other components too... like we have kio_*, kio-* (without plasma prefix...)
14:58:20 <rdieter> could make an exception that applets keep/use kde-plasma-* , and all the other related stuff use plasma-* namespace too
14:58:42 <rdieter> plasma-dataengine-, plasma-scriptengine, etc...
14:59:01 <rdieter> I'll throw these options in when I write up the draft, and consult #plasma folks.
14:59:18 <rdieter> then we can discuss more
14:59:24 <rdieter> #topic open discussion
14:59:34 <rdieter> looks like we're about out of time anyway (so much for a short meeting).
14:59:39 <rdieter> anything else before we end?
15:00:21 <Kevin_Kofler> I'm quite likely to be at https://fedoraproject.org/wiki/Linuxwochen_Wien_2010 at least part of the time.
15:00:45 <Kevin_Kofler> That said, it's mostly an Ambassadors type event, with only 2 tracks of user-oriented talks for the whole event.
15:00:57 <Kevin_Kofler> So I don't expect to be meeting many devs there.
15:01:25 <Kevin_Kofler> (and most of the talks will be in German)
15:01:59 <Kevin_Kofler> So that was that FYI.
15:02:08 <jreznik> I'm not available 8. 5. but maybe depending on schedule (6,7)...
15:02:12 <Kevin_Kofler> I think I don't have anything else. :-)
15:02:19 <rdieter> Kevin_Kofler: thanks, let us know how it goes.
15:02:44 <rdieter> thanks everyone
15:02:46 <rdieter> #endmeeting