14:08:57 <rdieter> #startmeeting KDE SIG Meeting -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-15
14:08:57 <zodbot> Meeting started Tue Dec 15 14:08:57 2009 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:08:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:10:16 <rdieter> #chair jreznik
14:10:16 <zodbot> Current chairs: jreznik rdieter
14:10:37 <rdieter> who's present today ?
14:10:53 <svahl> present
14:11:25 <jreznik> here
14:11:36 * than__ is present
14:12:17 <rdieter> #topic agenda
14:12:32 <rdieter> looks like we have a light agenda today, any other topics to add ?
14:12:46 <jreznik> KDE rebranding?
14:12:49 <than__> KDE-4.3.4 status
14:13:30 <svahl> netbook edition?
14:14:16 <rdieter> thanks, added
14:14:29 <rdieter> #topic kde 4.3.4 status
14:14:59 <rdieter> I've composed the f12 update... haven't queued for updates-testing yet... will do so asap
14:15:13 <rdieter> ltinkl was working on f11 last I knew... not sure how far he's gotten
14:15:47 <Kevin_Kofler> Grrr, sorry for being late, technical difficulties all over the place.
14:15:51 <rdieter> Kevin_Kofler: hi!
14:16:18 * rdieter is trying to pull up bodhi... a bit slow.
14:16:34 <Kevin_Kofler> Looks like I didn't miss much (from the meetbot log).
14:16:37 <rdieter> I venture the infrastructure work is still underway a bit
14:17:17 <Kevin_Kofler> Yeah, the Fedora infrastructure appears to still be in chaotic state.
14:17:29 <rdieter> f12 bodhi update:  http://preview.tinyurl.com/kde434-f12-2
14:17:30 <jreznik> it was big move...
14:17:32 <than__> we should finish KDE-4.3.4 build for F11 this week
14:18:08 <rdieter> cool, I'm tempted to wait for an infrastructure green light (and maybe f11 builds) before queuing anything
14:18:25 <rdieter> in the meantime our kde-4.3.4 builds are in the kde-testing repo
14:18:29 <rdieter> for f12 anyway
14:18:49 <rdieter> that's all I've got, anything else 4.3.4-related ?
14:19:33 <Kevin_Kofler> I hope we can get the F11 builds done soon.
14:19:51 <rdieter> yeah
14:19:53 <than__> Kevin_Kofler: yes
14:20:26 <than__> i will check with lukas when he is online again
14:20:54 <rdieter> moving on...
14:21:01 <rdieter> #topic KDE Rebranding, https://bugzilla.redhat.com/show_bug.cgi?id=547361
14:21:02 <bugbot_> Bug 547361: medium, low, ---, rdieter, NEW, Repositioning the KDE Brand
14:21:31 <rdieter> cosmetics, mostly, just renaming package summaries, descriptions to match upstream rebranding efforts
14:21:32 <jreznik> we should fix our SPEC files and spins page
14:21:43 <jreznik> same for KDE/KDE SIG wiki
14:21:44 <rdieter> ah, wiki changes too, right.
14:22:04 <jreznik> I'll take care about wiki/spins page
14:22:11 <rdieter> let's assign some tasks, cool
14:22:27 <rdieter> #action jreznik to work on wiki/spins kde rebranding
14:22:31 <jreznik> and if there's no volunteer for SPEC files, I'll do it too ;-)
14:22:32 <Kevin_Kofler> IMHO adding "Software Compilation" everywhere is just pointless pedantry.
14:23:10 <jreznik> Kevin_Kofler: I think lot of occurences of K Desktop... etc. could be removed...
14:23:16 <rdieter> Kevin_Kofler: there's more to it than just that... I partly agree with you, but we do want to minimize confusion about terminology and messaging
14:23:25 <than__> Kevin_Kofler: +1
14:23:26 <Kevin_Kofler> And to be frank, I don't think that change is going to stick or be followed outside of the inner KDE circles.
14:23:39 <Kevin_Kofler> Everyone everywhere writes just KDE to refer to the software.
14:23:59 <Kevin_Kofler> I don't think this is going to magically change no matter how much wishful thinking is coming from upstream.
14:24:02 <rdieter> except everyone's concept of what "KDE" means, is different.  This will hopefully help
14:24:02 <jreznik> Kevin_Kofler: at least we should get rid of "K Desktop Environment"
14:24:48 <rdieter> and I don't believe in "we can't change anything, so why try" isn't a valid excuse here.  It's an easy enough change
14:25:25 <rdieter> modulo my broken double negative there.  hopefully you know what I mean. :)
14:25:26 <jreznik> rdieter: yep, that's the problem - what 'KDE' means - it should be more clarified
14:25:44 <svahl> +1 for stick with upstream here
14:25:58 <jreznik> I have to admit I don't like "software compilation"
14:26:00 <rdieter> I can help with specs too, anyone else ?
14:26:15 <than__> rdieter: i can help here
14:26:33 <rdieter> #action : than__ , rdieter , jreznik to work on updating specs
14:26:36 <jreznik> users can ask what do I have to "compile" to get KDE running...
14:26:38 <Kevin_Kofler> jreznik: But we don't have any better term and besides, that's what upstream calls it.
14:26:53 <jreznik> Kevin_Kofler: I think collection is better
14:27:09 <rdieter> jreznik: me too. :)  I find myself typing/saying that sometimes
14:27:13 <Kevin_Kofler> "compilation" doesn't have anything to do with compiling in the CS sense here.
14:27:34 <rdieter> hrm... sec
14:27:36 <Kevin_Kofler> It's the traditional English meaning of "compilation".
14:27:46 <Kevin_Kofler> I.e. a compilation of works.
14:28:08 <jreznik> Kevin_Kofler: for you not but users are afraid of compilation... in open source world it becomes something else (for some people better, for newcomers...)
14:28:22 <jreznik> but let's stay with what upstream asks
14:28:40 <Kevin_Kofler> Talk to upstream if you want to get it changed.
14:29:01 <jreznik> Kevin_Kofler: they were considering it but compilation won
14:29:30 <than__> we need to change  comps-f13.xml.in too, who will take care of it?
14:29:37 <Kevin_Kofler> Then they must have their reasons for having called it that way.
14:30:05 <jreznik> it's ok for me, it's not very well name in terms of marketing (too geeky - software and collection) :)
14:30:28 <Kevin_Kofler> comps-f13 is a one-line or two-line change.
14:30:51 <Kevin_Kofler> The question is just what should the group name read?
14:30:56 <Kevin_Kofler> "KDE Software Compilation"?
14:31:04 <than__> Kevin_Kofler: yes
14:31:19 <Kevin_Kofler> It's trivial to change this, I can do it.
14:31:22 <rdieter> umm, arguing about the naming *here* makes little sense, take it to the kde folks, imo
14:32:31 <Kevin_Kofler> I do find it quite silly that a desktop environment doesn't want to be called "desktop environment" anymore.
14:32:50 <Kevin_Kofler> But "K Desktop Environment" always sucked as a group name anyway.
14:33:09 <jreznik> Kevin_Kofler: at least it's better
14:33:13 <Kevin_Kofler> ("yum groupinstall KDE" didn't work. With it being named "KDE Software Compilation", it should work.)
14:34:29 <Kevin_Kofler> So can we move on now?
14:35:49 <jreznik> yep
14:36:52 <Kevin_Kofler> Next topic please!
14:37:37 <jreznik> #topic multilibbing KCMs
14:38:19 <jreznik> #chair Kevin_Kofler
14:38:19 <zodbot> Current chairs: Kevin_Kofler jreznik rdieter
14:38:46 <rdieter> sorry, got pulled away
14:39:00 <Kevin_Kofler> So the issue here is that we don't currently multilib KCMs, i.e. we put them into the main package, not -libs.
14:39:19 <Kevin_Kofler> But that's not a good idea, because KCMs can (and for some of them, definitely are) embedded into applications.
14:39:24 <jreznik> any bug report?
14:39:31 <Kevin_Kofler> If embedded into a 32-bit application, a 32-bit KCM is needed.
14:39:52 <Kevin_Kofler> I noticed this while cleaning up duplicate files in kdebase-runtime.
14:40:00 <Kevin_Kofler> (The KCMs were in both main and -libs.)
14:40:05 <rdieter> umm... I still don't understand... if the 32 bit application is installed (and is in the main pkg), it's available.
14:40:21 <Kevin_Kofler> -libs is supposed to be multilib, the main pkg is not.
14:40:37 <Kevin_Kofler> And I'm talking about apps outside of kdebase-runtime using the KCMs.
14:40:45 <rdieter> ok, so not 32 bit app installed => no need for 32 bit kcm
14:41:02 <Kevin_Kofler> Even KCMs from other modules, like kdebase(-apps), kdebase-workspace etc., end up used in apps.
14:41:03 <rdieter> your talking about 32 bit apps needing 32 bit kcms, right ?
14:41:23 <mathstuf> eg, the phonon one is used by amarok
14:41:24 <rdieter> except on 64bit, there are no 32bit apps (in general)
14:41:29 <Kevin_Kofler> No 32-bit app installed => no 32-bit -libs multilib installed => it doesn't matter for this case at all.
14:41:40 <rdieter> what case then ?
14:42:05 <Kevin_Kofler> The point of deciding what to put in -libs and what in main is exactly when a 32-bit app using the 32-bit multilibs is installed.
14:42:40 <Kevin_Kofler> Now of course arguably the app should just get rebuilt for x86_64, but then why are we supporting multilib at all?
14:42:49 <rdieter> I fail to see a case of anything broken in the status quo.
14:42:58 <Kevin_Kofler> (I don't care a lot about multilib, to be honest.)
14:43:06 <rdieter> Kevin_Kofler: ah, you seem to think multilib means you can install/run *any* 32bit app you want.
14:43:21 <rdieter> including those not in the x86_64 repos... it seems
14:43:32 <Kevin_Kofler> If not that, why do we support multilib at all?
14:43:39 <rdieter> indeed. :)
14:43:51 <Kevin_Kofler> All those 32-bit apps in Fedora have 64-bit versions too (except WINE which doesn't use any KDE libs).
14:44:06 <rdieter> without a foundation of what multilib is and exactly what to support, this discussion is a bit meaningless
14:44:44 <rdieter> ie, when/if fedora multilib policy changes and affects what's available in the repos, then we can discuss this more
14:44:56 <Kevin_Kofler> Then let's drop all the -libs subpackages, put everything into the main package and close all multilib conflict bugs as NOTABUG?
14:45:03 <rdieter> as it is, we support what's in the repos, and as I understand it, as-is, stuff just works
14:45:05 <Kevin_Kofler> I mean, either we care about multilib or we don't.
14:45:36 <rdieter> we care about multilib enough to get 32 bit -devel pkgs to install, that's about it
14:46:07 <Kevin_Kofler> But what for if the apps you're compiling with those -devel packages won't run properly because they're missing their KCMs?
14:46:25 <rdieter> Kevin_Kofler: we deal with it on a case-by-case basis
14:46:41 <Kevin_Kofler> Putting the KCMs into -libs should not hurt anything for the non-multilib usecase.
14:46:57 <rdieter> this is a dangerous slippery slope, you realize. :)
14:47:21 <rdieter> ok, *if* we do this, then there's more to consier:  kio slaves
14:47:42 <rdieter> pretty much everything under %{_libdir}/kde4 ... no ?
14:47:44 <Kevin_Kofler> Those need to be multilib too, indeed.
14:48:02 <Kevin_Kofler> kded4 modules don't need to be multilib.
14:48:10 <rdieter> sure?  ok.
14:48:14 <Kevin_Kofler> Only the native arch kded4 gets run.
14:49:13 <Kevin_Kofler> kioslaves, I'm actually not sure.
14:49:22 <Kevin_Kofler> Isn't kio running out of process?
14:49:38 <rdieter> so what's the best way to approach this?  whitelist items to multilib, or say... everything under %{_libdir}/kde4 *except* blacklist items like kded modules ?
14:49:40 <Kevin_Kofler> I think they'll actually be run native arch only, too.
14:49:59 <mathstuf> kded is dbus right?
14:50:05 <rdieter> ok, I'd propose we vote to accept your proposal then.
14:50:12 <mathstuf> and kio stuff is all under kded iirc
14:50:32 <rdieter> I think I've inadvertantly multilib'd some kio's before, so I can fix that now. :)
14:50:37 <rdieter> +1
14:51:04 <Kevin_Kofler> For the KIO stuff, we should probably test this in some way to be sure.
14:51:12 <Kevin_Kofler> But I guess it's not needed multilib.
14:51:30 * rdieter assumes Kevin_Kofler +1's too.   anyone else ?
14:52:34 <Kevin_Kofler> Yes, I'm +1 to putting KCMs into -libs.
14:52:38 <mathstuf> sounds reasonable
14:52:49 <jreznik> I still don't see clear reason to do it ;-)
14:53:12 <mathstuf> for people who cant get 64bit versions of software that use KCMs
14:53:12 <Kevin_Kofler> Other stuff in libdir/kde4 needs to be checked for whether it's in process (like KCMs) or out of process / systemwide (like kded4).
14:53:35 <jreznik> mathstuf: yep but do we have such software?
14:53:44 <rdieter> jreznik: if we expect the 32bit runtime bits to actually work, we need this (even if it is a bit of a corner-case)
14:53:58 <mathstuf> no, becuase we can just recompile it; others may not be so lucky
14:55:04 <jreznik> I'm not against, so +1
14:55:07 <mathstuf> if something like a KDE frontend for <proprietary app> comes along and it uses the phonon KCM, it wont be able to find it (its not a crash, just an error that the KCM doesnt exist)
14:55:36 <Kevin_Kofler> jreznik: Some fictional cases: Krappy Programmer's 64-bit-unsafe software (e.g. using int* and long* interchangeably due to the programmer being used to 16-bit platforms), Evil Proprietary Kompany's 32-bit-only binary-only Krap, etc.
14:55:42 <svahl> same opinion as jreznik here, +1
14:55:58 <rdieter> than__: have a vote for the record ?
14:56:50 <jreznik> so - kcm, kio, any other uses? as nearly everything is pluggable in KDE (not sure what's already multilibbed)
14:57:27 <rdieter> jreznik: in general, only shlibs are multilib'd (there's a few exceptions where I may have included kio's in the past too)
14:57:32 <rdieter> currently
14:57:35 <Kevin_Kofler> jreznik: Again, AFAIK KIO is out of process.
14:57:57 <Kevin_Kofler> So I doubt it's needed multilib, though I haven't actually checked that.
14:58:15 <rdieter> I had *ass*umed previously that kcm's were out of process too (ie, used something like kcmshell4 <foo>), my bad
14:58:38 <rdieter> #agreed proposal to multilib kcm's adopted (4-0-0)
14:58:41 <Kevin_Kofler> AFAIK KCMs are just dlopened.
14:58:49 <rdieter> ok
14:58:58 <rdieter> dang, running short on time.
14:59:03 <mathstuf> kparts are in -libs i assume
14:59:04 <mathstuf> ?
14:59:08 <Kevin_Kofler> (of course through the KDE plugins mechanisms)
14:59:27 <Kevin_Kofler> mathstuf: Uh, you have a point there too.
14:59:29 <rdieter> mathstuf: ah, needs multilib'ing too
14:59:42 <Kevin_Kofler> KParts are definitely in process.
14:59:43 <mathstuf> Kevin_Kofler: yeah, you can ask to load the widget from  KCM; its in-process
15:00:41 <than> sorry, my vote is +1
15:01:09 <Kevin_Kofler> But if we put the KParts there, some apps will have almost all their logic in -libs. :-(
15:01:23 <mathstuf> khtml, okular, kate, etc
15:01:25 <jreznik> that was my question ;-) in KDE everything is pluggable and you can use nearly everything from your app
15:01:25 <Kevin_Kofler> But it's definitely needed to support loading the KParts into 32-bit apps.
15:03:27 <Kevin_Kofler> Let's discuss KParts at another time.
15:03:38 <Kevin_Kofler> There's no time today.
15:04:18 <jreznik> someone should look what we really have to support in multilib
15:04:26 <rdieter> jreznik: baby steps.
15:04:37 <rdieter> let's wrap up, continue in #fedora-kde, we're over time
15:04:42 <rdieter> #endmeeting