14:02:44 <rdieter> #startmeeting KDE SIG Meeting -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-10
14:02:44 <zodbot> Meeting started Tue Nov 10 14:02:44 2009 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:53 <rdieter> #topic roll call
14:02:58 <rdieter> who's present today?
14:03:05 <Kevin_Kofler> Present.
14:03:06 <heliocastro> rdieter: The guest one here
14:03:10 <svahl> present
14:03:20 <rdieter> heliocastro: welcome!
14:03:23 * than is present
14:03:29 * jreznik is present
14:04:01 * ltinkl is here
14:04:41 <rdieter> #topic celebration of f12 going gold
14:05:29 <Kevin_Kofler> Hooray! FTW!
14:05:55 <svahl> :D
14:05:55 <rdieter> congrats all around, we've got a good release, stellar artwork, integration, latest kde technologies
14:06:05 * jreznik is opening champagne :D
14:06:23 <ltinkl> and what's better, F13 looks to be even more promising :)
14:06:38 <rdieter> indeed.
14:06:56 <jreznik> I'm using F12 for some time and it feels like most stable Fedora ever!
14:07:14 <ltinkl> I'm going to install it to my brand new work laptop
14:07:19 <jreznik> big step from alpha to GA, thanks all!
14:07:20 <ltinkl> let's see :)
14:07:31 * SMParrish sorry I'm late but I'm here
14:07:48 <rdieter> while, we're at it and celebrating, I'd like to welcome heliocastro , he's landed on using fedora recently, and has graciously offered to join the team soon
14:07:55 <than> big thank to all!
14:08:05 <jreznik> heliocastro: welcome!
14:08:14 <svahl> heliocastro: welcome, too
14:08:19 <SMParrish> welcome heliocastro
14:08:26 <heliocastro> Thanks all
14:08:35 <Kevin_Kofler> +1
14:08:38 <jreznik> some teams are fighting with community, some teams are growing! great
14:08:48 <ltinkl> I'd also wanted to point out (and thank the whole KDE team) that what we ship is already quite stable
14:09:00 * ltinkl joins and welcomes helio
14:09:14 <ltinkl> heliocastro: hi mate :)
14:09:19 <rdieter> heliocastro: could you introduce yourself (if you don't mind), give a little background for folks not already familiar with your kde/mandriva contributions?
14:09:24 <than> welcome heliocastro
14:09:45 <heliocastro> ok, simple introduction
14:09:52 <heliocastro> 10,5 years in conectiva/mandriva
14:10:02 <heliocastro> been kde lead pacakger ther for 8 years
14:10:11 <heliocastro> stubborn as hell
14:10:17 * rdieter wows, lols
14:10:45 <heliocastro> kde devel for long time too, kmix, arrk, etc..
14:10:56 <ltinkl> I've known helio for like 8 years, he will be a great addition to our team :)
14:11:20 <heliocastro> and now i'm working to Collabora in *projects* and since i decided to use fedora for change reasons i was thinking in help some in free time
14:11:52 <heliocastro> That's pretty much describe introduction
14:12:11 <rdieter> ok, excellent.  again, welcome.
14:12:13 <jreznik> impressive ;-)
14:12:51 <svahl> yeah, nice to have you onboard :)
14:12:52 <rdieter> #info: introduce and welcome heliocastro
14:13:27 <rdieter> ok, enough partying, let's get back to work. :)
14:13:36 <rdieter> #topic kde-4.3.3 status
14:13:40 <rdieter> ltinkl: ?
14:13:47 <ltinkl> yup
14:14:05 <ltinkl> KDE 4.3.3 is imported into CVS for Fedora 10/11
14:14:14 <ltinkl> F12 is being worked on right now
14:14:39 <ltinkl> once I'm done with CVS, I'll launch the builds
14:14:44 * rdieter can serve as tagbot
14:15:12 <ltinkl> that's about it :)
14:15:38 <ltinkl> oh, I also imported a patch to kdenetwork to make it compilable against the new webkitkde
14:15:41 <rdieter> one thing to consider, with f10 so close to eol, do we still want to push kde-4.3.3 there?
14:15:57 <Kevin_Kofler> Yes.
14:16:03 <ltinkl> rdieter: I'd tend to say yes
14:16:05 * rdieter is on the fence
14:16:17 <ltinkl> let's make it the last update, 4.3.3 and finito
14:16:23 <svahl> +1
14:16:34 <ltinkl> besides, it's already done :)
14:16:48 <jreznik> is it allowed to have something in updates-testing in F10 and after eol push it to stable?
14:16:57 <rdieter> not after eol
14:17:02 <jreznik> (or I hope it will go to updates-testing first)
14:17:30 <jreznik> it's not a good idea to push latest stable update and eol...
14:17:37 <jreznik> without testing
14:17:37 <rdieter> it's still got a month, if it doesn't land in stable updates before then, something is very wrong.
14:17:46 <jreznik> ok
14:17:58 <ltinkl> right, if there's some breakage, there won't be any more updates to fix it in F10 ;-)
14:18:37 <rdieter> part of my hesitation, is that we won't have as much chance to test it.  ie, how many of you/us are on f10 these days ?
14:19:00 <Kevin_Kofler> Me.
14:19:11 <rdieter> ok, good enough for me. :)
14:19:21 <svahl> :)
14:19:44 <ltinkl> decided :)
14:19:55 <ltinkl> move on?
14:19:57 <rdieter> #info 4.3.3 in cvs for f 10/11, f12 coming soon.  builds shortly after that
14:20:10 <rdieter> #topic features for f13
14:20:50 <svahl> in addition to that: (existing) extragear packages are also build for f13. I'll do f10-12 when the packages are tagged in buildroot
14:20:55 <ltinkl> this looks to be a pretty long list :)
14:21:02 <ltinkl> which is good
14:21:04 <jreznik> pk-qt-1 feature is ready for fesco - but first we have to meet Dario... I'm not sure it's KDE 4.4 stuff as we're missing response from him
14:21:39 <jreznik> so for kauth we need patch over 4.4 but it's ready, rnovacek finished it
14:22:04 <jreznik> I'll prepare next feature requests later as I didn't have time to do it yet :(
14:22:17 <rdieter> off the top of my head, others to consider are:   phonon/pulseaudio (from mandriva), firefox/kde, openoffice/kde
14:22:30 <jreznik> knetworkmanager
14:22:52 <rdieter> each of these will need an owner to drive them too.
14:23:07 <ltinkl> let's prepare a simple wiki page with a list for the next meeting
14:23:22 <rdieter> I can volunteer for knetworkmanager (if no one else can or wants to do that one)
14:23:27 <rdieter> ltinkl: good idea
14:23:34 <ltinkl> I'll try to drive the Firefox/OpenOffice KDE integration bits
14:23:51 <jreznik> ltinkl is going to report firefox/kde integration bugs, stransky promised to look on it
14:23:56 <ltinkl> jreznik will take the polkit1 bits I assume
14:24:04 <jreznik> ltinkl: yeap
14:24:07 <rdieter> Kevin_Kofler: you had mentioned previously you were interested in phonon/pa, are you still ?
14:24:11 <Kevin_Kofler> Yes.
14:24:14 <ltinkl> ok
14:24:24 <ltinkl> rdieter: I'll prepare the wiki page
14:24:42 <Kevin_Kofler> I really like Colin's work, he's doing all the Phonon part of what I wanted to do during the summer and he's doing it better than I'd have managed to do it. ;-)
14:24:43 <heliocastro> when we suppose to have f12 isos available ?
14:24:47 <ltinkl> with a simple list for now, we will elaborate on the individual pages later
14:25:03 <ltinkl> heliocastro: http://alt.fedoraproject.org/pub/alt/stage/12-RC.4/
14:25:04 <Kevin_Kofler> And he managed to work around Phonon's API's limitations so we don't need an API break.
14:25:13 <Kevin_Kofler> I'm going to drive getting this into Fedora.
14:25:14 <rdieter> #action ltinkl to prepare wiki page outlining f13/kde features to work on
14:25:17 <ltinkl> heliocastro: RC4 is already there, I think it's the final one
14:25:20 <Kevin_Kofler> I'll also write the feature page.
14:26:09 <rdieter> #action Kevin_Kofler to work on phonon/pulseaudio integration
14:26:19 <rdieter> #action rdieter will do knetworkmanager
14:26:33 <rdieter> #action jreznik polkit-1 related goodies
14:26:47 <rdieter> #action ltinkl  firefox/openoffice kde4 integration
14:26:56 <rdieter> whew
14:27:07 <rdieter> that's a good start already
14:27:15 <ltinkl> I'm also wondering about DeviceKit
14:27:22 <ltinkl> but it all depends on the Gnome part
14:27:41 <Kevin_Kofler> heliocasheliocastro: Leaked ISOs are also likely to be posted on certain "highly unofficial" torrent sites once they start getting mirrored out, if you get what I mean. ;-)
14:27:41 <ltinkl> the good part is that we're prepared even for this :)
14:28:23 <rdieter> ltinkl: you mean more solid-devicekit work ?
14:28:35 <ltinkl> rdieter: yup
14:28:46 <rdieter> yeah, good idea too
14:29:08 <rdieter> should be able to ship a kde3-less spin for real this time
14:29:08 <ltinkl> it's more an emergency plan, I don't think DK will replace HAL anytime soon :)
14:29:15 <jreznik> KOffice 2 finally to F13?
14:29:20 <rdieter> jreznik: yep
14:29:27 <ltinkl> k3b
14:29:30 <jreznik> probably k3b too
14:30:19 <svahl> I would like to discuss another possible (and often requested feature): modularized kde packages (like in mandriva or suse). This would also make things easier on the live images.
14:30:32 <rdieter> we'll probably to another generic "kde 4.4" feature too, possibly umbrella much of the other items we just discussed under that
14:30:45 <ltinkl> svahl: but it costs a lot more manpower
14:31:04 <svahl> maybe, but most work would be the initial split
14:31:09 <rdieter> svahl: standard answer: we can consider that, certainly, where it makes sense to do so
14:31:13 <Kevin_Kofler> jreznik: They're already now, we just don't ship them in F12 for no good reasons... :-/
14:31:30 <Kevin_Kofler> (already ready, that is)
14:32:05 <Kevin_Kofler> ltinkl: I think you should start from solid-devicekit-alternate.
14:32:07 <rdieter> too good candidates for some splitting:  kdegraphics, kdemultimedia
14:32:11 <mathstuf> splitting kdelibs into kdelibs and kdelibs-x11 (similar to qt) was mentioned at some earlier point
14:32:12 <rdieter> two even. arg
14:32:15 <svahl> rdieter: I meant eg. one package per app
14:32:19 <jreznik> Kevin_Kofler: K3B is not ready yet for example...
14:32:20 <Kevin_Kofler> You can't work with DeviceKit-disks and -power alone, you need to use libudev too.
14:32:35 <rdieter> svahl: not really an option, we need to take baby steps to get there, I think
14:32:44 <ltinkl> Kevin_Kofler: yup, but as I said, I don't see HAL going away
14:32:47 <Kevin_Kofler> jreznik: It was working just fine for everyone except one crash which I already fixed (the fix is now in SVN).
14:32:53 <Kevin_Kofler> (It = K3b)
14:32:54 <heliocastro> svahl: We used to do this way for years at conectiva/mandriva
14:33:02 <svahl> in some free time in the last two months I've done this (as very first versions) for some packages: http://www.deadbabylon.de/fedora/kde4-modular/
14:33:12 <jreznik> Kevin_Kofler: I met few people complaining on the state of K3b :(
14:33:12 <Kevin_Kofler> I'm against splitting things.
14:33:26 <svahl> heliocastro: I've taken the mandriva specs as a start. :)
14:33:29 <Kevin_Kofler> Subpackage explosion just makes things harder for most users.
14:33:43 <Kevin_Kofler> And it'll increase update metadata downloads for everyone.
14:33:47 <jreznik> we should have more reasons to split packages than just live CD
14:33:53 <Kevin_Kofler> Even non-KDE users and even if KDE didn't actually change in the push.
14:33:55 <mathstuf> im agree with rdieter, kdegraphics and kdemultimedia are probably prime for first splitting (if we do it at all)
14:33:56 <than> i'm against splitting things too
14:34:02 <heliocastro> Kevin_Kofler: Indeed, a meta-package upgrade plan is needed first
14:34:11 <Kevin_Kofler> In fact, we should undo some of our pointless splits.
14:34:19 <rdieter> Kevin_Kofler: that too
14:34:23 <Kevin_Kofler> Like kdebase-workspace-python-applet which is the cause of a lot of user complaints.
14:34:24 <ltinkl> besides, I think the Live CD concept is a bit archaic these days
14:34:30 <ltinkl> most PCs have a DVD drive if any
14:34:32 <rdieter> #topic package splitting
14:34:33 <Kevin_Kofler> heliocastro: That won't solve anything.
14:34:45 <heliocastro> Kevin_Kofler: No, but helps a lot
14:34:47 <Kevin_Kofler> The metadata will still be there slowing down updates.
14:35:00 <Kevin_Kofler> It's going to increase the update metadata by a factor of 5 or 10.
14:35:02 <mathstuf> well, for minimal systems (like my netbook), being able to grab just okular and konqueror would be nice
14:35:09 <mathstuf> Kevin_Kofler: just for KDE packages
14:35:09 <Kevin_Kofler> We're going to flood the metadata with KDE stuff!
14:35:18 <svahl> ltinkl: In german forum I also got complaints that the kde packages aren't splitted in fedora
14:35:18 <mathstuf> have you seen the texlive plan?
14:35:19 <heliocastro> this is coming from someone that already passed for this pain * TWICE *
14:35:19 <Kevin_Kofler> KDE is already a big part of the updates.
14:35:21 <jreznik> mathstuf: good reason
14:35:23 <Kevin_Kofler> It'd make it much worse.
14:35:38 <Kevin_Kofler> mathstuf: TeXLive won't be pushed as updates, at least not every single package of it!
14:35:49 <mathstuf> there's 3000 of them
14:35:52 <mathstuf> or there abouts
14:35:53 <Kevin_Kofler> Everything is not the problem, updates are.
14:36:12 <Kevin_Kofler> It doesn't matter if there are 3000 packages in Everything, but we can't have KDE updates with 3000 subpackages.
14:36:31 <jreznik> if upstream splits packages - we should split but now it would be more difficult
14:36:31 <mathstuf> ah, right
14:36:35 <mathstuf> signing would take a long time
14:36:43 <jreznik> I understand Kevin_Kofler point - updates
14:36:48 <Kevin_Kofler> kdelibs-x11 makes sense as a split, but one package per app, no!
14:36:52 <rdieter> doesn't have to be an all-or-nothing proposition, I'm still of the mind, to incrementally work on the issue, (redudancy alert) where it makes sense to do so
14:36:56 <jreznik> even now we sometimes omit something from updates
14:37:17 <mathstuf> jreznik: we still would have the same number of srpms to list
14:37:31 <Kevin_Kofler> Well, omitting wouldn't be a problem as long as we use subpackages from the same SRPM.
14:37:38 <Kevin_Kofler> But the update metadata size would.
14:38:03 <jreznik> rdieter: +1 all-or-nothing is bad
14:38:19 * rdieter is mildly surprised to see skvidal and Kevin_Kofler on the same side of an issue here.
14:38:27 <Kevin_Kofler> ^^
14:38:50 <Kevin_Kofler> Of course my hidden agenda is that I also don't want the added burden on maintaining file lists. ;-)
14:38:54 <mathstuf> rdieter: s/skvidal/svahl/ ?
14:39:05 <Kevin_Kofler> mathstuf: Nope.
14:39:08 <rdieter> mathstuf: you heard right. :)
14:39:35 <mathstuf> sorry is early, history isn't showing anything here
14:39:36 <Kevin_Kofler> But I think the update metadata is a serious issue too.
14:39:53 <rdieter> anyway, how about for 4.4, we look into at least some prudent splitting for kdegraphics, kdemultimedia, and go from there
14:40:01 <mathstuf> what if we just split out the "popular" packages?
14:40:02 <Kevin_Kofler> I think we need less splitting, not more.
14:40:06 <rdieter> mathstuf: right
14:40:12 <Kevin_Kofler> The only split we aren't doing and probably should is kdelibs-x11.
14:40:25 <rdieter> Kevin_Kofler: and revert some splits that no longer make sense
14:40:26 <Kevin_Kofler> That'll also be mostly transparent to the user as the soname deps are going to take care of it.
14:40:37 <jreznik> I'm not against split when someone really asks split with good reasons
14:40:42 <svahl> rdieter: kdemultimedia is too small for a split these days, imho
14:40:50 <Kevin_Kofler> kdebase-workspace-python-applet sucks, especially with no way to get it installed automatically when neded.
14:41:00 <heliocastro> The reason we initially did the splits in mandriva was completly different than her
14:41:02 <rdieter> svahl: nod, you have a point
14:41:08 <mathstuf> for example, kdegraphics is basically okular, gwenview, and other
14:41:09 <heliocastro> We are aiming to OEM customers
14:41:22 <heliocastro> And the fact that are netbooks with way low disk space
14:41:38 <heliocastro> so, OEM team installed just necessary tools and libs
14:41:48 <heliocastro> sometimes reducing in 70% the size of package
14:41:56 <rdieter> netbooks or platforms with minimal space is a valid target/use-case.  overlaps with worrying about livecd space too
14:42:21 <svahl> heliocastro: my netbook (and the live images) were also part of my motivation
14:42:23 <Kevin_Kofler> The hardware vendors need to fix their netboks, not sell crap with no storage to users. :-/
14:42:36 <heliocastro> Kevin_Kofler: Unfortunately, not works like that
14:42:38 <ltinkl> :DD
14:42:40 * jreznik is running full fedora on eee :) but yes, space is problem - home on 16 gb sd card
14:42:57 <svahl> Kevin_Kofler: ssd are not as cheap as hdds :(
14:43:00 * heliocastro remember in particular some monster called GDIUM
14:43:01 <mathstuf> well, kmix is nice from kdemultimedia, the rest is superceded by extragear
14:43:02 <Kevin_Kofler> Netbooks are a technological step backwards.
14:43:18 <ltinkl> remember kids, "640kb ought to be enough" *g*
14:43:19 <jreznik> Kevin_Kofler: for netbook usage 4 gb is enough, really... it's not PC for full time work, but for web, mail
14:43:20 <Kevin_Kofler> Less storage space, less RAM, slower CPU, and usually even 32-bit only. :-/
14:43:32 <mathstuf> Kevin_Kofler: its a different use case
14:43:40 <Kevin_Kofler> Oh, and LCD pixel counts from 10+ years ago.
14:43:40 <mathstuf> them as your *main* machine is backwards
14:43:47 <mathstuf> as a supplemental, its great
14:44:10 <mathstuf> typically with ssh/vnc to a better machine for heavy liftign
14:44:12 <heliocastro> guys, is all based on your goals
14:44:33 <heliocastro> If you want a small sized controlled packages, go for heavy splitting, even been a burden on packagers side
14:44:42 <heliocastro> If you want less pain and easym management
14:44:46 <mathstuf> the thinkpad is unweildly on a bus for instance
14:44:46 <heliocastro> don't split
14:45:02 <rdieter> well said
14:45:10 <jreznik> heliocastro: right
14:45:31 <ltinkl> I'd leave the status quo
14:45:41 <jreznik> we want full featured KDE desktop, we're not aiming on netbooks now
14:45:41 <heliocastro> As i said, our original goal 9 years was "have the smallest distro possible"
14:45:42 <ltinkl> we can split where we see fit
14:45:47 <Kevin_Kofler> My main concern size-wise is that the update metadata is going to add up to a lot more stuff to download than the updates themselves would!
14:46:04 <Kevin_Kofler> It's going to be redownloaded at every single push, even if we didn't change KDE at all.
14:46:15 <mathstuf> Kevin_Kofler: i don't think it'd be that much impact there
14:46:17 <rdieter> while a concern, I think you're overstating the metadata impact a bit.
14:46:17 * heliocastro counts how much kde packages are in total
14:46:40 <mathstuf> we can split out 75 (rough guess) apps
14:46:41 <jreznik> Kevin_Kofler: then we have to do something with it... it has to be fixed somehow... we can't be constrained by some technical problem
14:46:49 <mathstuf> there's 23000 packages in rawhide
14:46:51 <Kevin_Kofler> We already have ~70 subpackages.
14:47:03 <Kevin_Kofler> I'm worried we'll end up with ~500+.
14:47:22 <rdieter> Kevin_Kofler: not for quite awhile anyway, don't worry. :)
14:47:23 <SMParrish> splitting would make it easier for ppl to file BR against a more precise target, however its going to be a larger burden on packaging
14:47:41 <Kevin_Kofler> Especially if you factor in all the associated -devel (e.g. kompare-devel for the KomparePart) and -libs (because of course multilib pedantry should also still be supported) stuff.
14:48:05 <jreznik> one think is - do we plan support netbook KDE interface in the future?
14:48:06 <rdieter> Kevin_Kofler: I think we're mostly considering just runtime splits, -devel would or could-be monolithic
14:48:11 <Kevin_Kofler> (Multilib-installing something like kdesdk is useless, it's quite silly to have to support it.)
14:48:21 <heliocastro> Ok, we had 854 packages in every kde new release, all splitted
14:48:36 <Kevin_Kofler> So my estimate wasn't off at all!
14:48:39 <heliocastro> devel are monolithics
14:48:40 <mathstuf> oof
14:48:41 <SMParrish> jreznik: I hope so.  Working on a KDE based release for the XO-1.5 atm
14:48:56 <heliocastro> Kevin_Kofler: But we split libraries as well
14:49:05 <heliocastro> one library per package, only the liobrary
14:49:06 <mathstuf> !calc 854/23000
14:49:07 <jreznik> SMParrish: I thought the new Plasma based interface... it looks promising
14:49:10 <rdieter> heliocastro: every shlib ?
14:49:10 <Kevin_Kofler> 90%+ of the update metadata will be KDE with such a system.
14:49:15 <heliocastro> rdieter: Every one
14:49:19 <jreznik> if we want to support it, we need some sort of splits
14:49:41 <Kevin_Kofler> We'll have GNOME, XFCE and LXDE users knocking on our doors with pitchforks in their hands, pissed off at us slowing down their updates by a factor of 10.
14:49:42 <heliocastro> Kevin_Kofler: In fedora yes
14:49:43 <mathstuf> Kevin_Kofler: no more xchat?
14:49:53 <mathstuf> hmm
14:50:07 <jreznik> Kevin_Kofler: we should ask relengs for solution, not to stay on one point because of it...
14:50:08 <mathstuf> wasn't there mention of metadata deltas at some point?
14:50:09 <Kevin_Kofler> mathstuf: This is the notebook, I have Konversation here.
14:50:14 <rdieter> it's a big job, but supporting a minimial runtime for small targets would likely be worthwhile, and I think we can get there without splitting the world
14:50:14 <mathstuf> ah
14:50:37 <Kevin_Kofler> I'd have to install the Yacas stuff too for the !calc to work anyway.
14:51:18 <rdieter> svahl: you've already started a bit of work on the topic, you want to own this one (for now, with help from others welcome of course)?
14:51:28 <svahl> what I've done: splitting out the binaries (including relevant libs) and only create a -common package for all.
14:51:30 <Kevin_Kofler> Anyway, your 854/23000 is irrelevant.
14:51:38 <svahl> http://fpaste.org/s7Dn
14:51:38 <Kevin_Kofler> We're not talking about Everything, but about updates.
14:51:52 <Kevin_Kofler> You need to check how many packages are in updates at the moment, not in Everything.
14:52:03 <svahl> rdieter: maybe. depends on the decision :)
14:52:21 <svahl> but indeed: I haven't thought about the metadata
14:52:27 <Kevin_Kofler> 128 packages just from splitting 5 SRPMs. :-(
14:52:36 <mathstuf> Kevin_Kofler: ah, right
14:52:43 <svahl> Kevin_Kofler: kdegames is a big issue there
14:52:49 <rdieter> there is no decision yet, just a tentative proposal to look at the issue, and find an incremental way forward (ie, get the most bang for our splitting buck)
14:52:53 <mathstuf> kdeedu will as well
14:52:56 <jreznik> as I said - we should talk to people who cares about metadata what they think
14:52:57 <mathstuf> cantor is getting in there
14:53:09 <rdieter> svahl: kdegames upstream already has recommendations on splitting, and it's not on a per game basis
14:53:11 <mathstuf> though i imagine splitting the backends out will be possible
14:53:30 <mathstuf> otherwise...
14:53:35 <Kevin_Kofler> Cantor is going to be a big mess, I can't imagine kdeedu having Requires: sagemath even once we have it packaged, if we ever manage!
14:53:45 <mathstuf> well, there's maxima
14:53:51 <mathstuf> that drags in sbcl
14:54:00 <mathstuf> which is another 60MB or so last i checked
14:54:00 <svahl> rdieter: I would say I put up a wiki page for what I've done yet and we'll discuss this in one of the comming meetings
14:54:02 <Kevin_Kofler> That's tolerable, if annoying.
14:54:04 <rdieter> svahl: see README.PACKAGERS inside kdegames tarball
14:54:14 <Kevin_Kofler> But R or SAGE, ouch!
14:54:14 <rdieter> svahl: cool, please do
14:54:23 <Kevin_Kofler> I guess Maxima should be the default.
14:54:24 <svahl> rdieter: thx. Will do that
14:54:28 <mathstuf> R is smaller than maxima + deps
14:54:31 <mathstuf> i thought
14:54:42 <rdieter> #action svahl to document package splitting work he's done, as a basis for future discussions on topic
14:54:50 <Kevin_Kofler> Well, R-core certainly is, but you can't do much with just that and no other packages.
14:55:46 <mathstuf> hmm
14:55:53 <mathstuf> i thought sbcl was bigger than that
14:56:20 <rdieter> it's on the hefty side (didn't realize it had grown so large)
14:56:31 <Kevin_Kofler> kdeedu already ships a statically-linked OCaml runtime.
14:56:38 <mathstuf> repoquery says 8.5MB
14:56:41 <mathstuf> Kevin_Kofler: ew
14:56:54 <Kevin_Kofler> (OCaml can only link statically for native code, it's the one exception where we don't need FESCo approval for static linking.)
14:57:11 <Kevin_Kofler> Kalzium's chemical equation balancer is based on ocaml-facile.
14:57:25 <Kevin_Kofler> (which is also statically linked, see above)
14:57:54 <svahl> rdieter: can you (or someone else with more knowledge than me) talk to someone about the metadata issue?
14:58:38 <Kevin_Kofler> skvidal is the person to talk to, I guess.
14:58:43 <rdieter> personally, I think the worry about it is overstated, there are bigger issues to consider on whether or not to do package splits, imo
14:58:47 <svahl> and I would also like to ask our users at fedora-kde-ml about this. If they don't want it then there's no need for it
14:58:55 <svahl> any objections to that?
14:59:01 <Kevin_Kofler> But I somehow suspect he'll just label you as insane for even suggesting that many subpackages. ;-)
14:59:05 <rdieter> svahl: good idea
14:59:15 <svahl> Kevin_Kofler: :)
14:59:43 <rdieter> svahl: be sure to outline the pros/cons, more packages = more control, but also more complexity
14:59:43 <heliocastro> svahl: And not ask, do some examples form pros/cons
14:59:52 <rdieter> :)
14:59:55 <heliocastro> *only ask
15:00:01 <svahl> rdieter: nod
15:00:15 <svahl> heliocastro: nod
15:00:15 <Kevin_Kofler> FYI, time's up, we should be thinking of wrapping up.
15:00:38 <rdieter> agreed, thanks everyone, in top 5 of "best kde-sig meetings ever!"
15:00:50 <nucleo> Is it possible to add in KDE 4.3.3 in desktop context menu Konsole not only for Desktop view desktop activity but and for Folder view?
15:00:50 <rdieter> #endmeeting