14:02:16 <rdieter> #startmeeting KDE SIG -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-01-012
14:02:16 <zodbot> Meeting started Tue Jan 12 14:02:16 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:40 <rdieter> #chair Kevin_Kofler than jreznik svahl
14:02:40 <zodbot> Current chairs: Kevin_Kofler jreznik rdieter svahl than
14:03:22 <rdieter> #topic roll call
14:03:31 <rdieter> who's present today?
14:03:31 <Kevin_Kofler> #meetingname kde-sig
14:03:31 <zodbot> The meeting name has been set to 'kde-sig'
14:03:35 <Kevin_Kofler> Present.
14:03:45 <SMParrish> here
14:04:05 <svahl> present
14:04:17 <rdieter> ping: than, jreznik
14:04:39 <ltinkl> hello
14:04:43 * than is present
14:04:52 <jreznik> I'm here
14:05:21 <rdieter> #topic agenda
14:05:33 <rdieter> agenda's pretty light today, any other topics to add ?
14:06:09 <rdieter> if there's time, we can continue discussion from last weeks "requirements for default applications" topic
14:06:13 <svahl> status of plasma-netbook-tracker?
14:06:14 <jreznik> add enablinf JIT
14:07:04 <rdieter> added
14:07:42 <rdieter> #topic kde-l10n srpm split
14:07:48 <rdieter> than ?
14:08:19 <than> the kde-ö10n srpm is too big
14:08:46 <than> it's not good for the update
14:09:03 <than> we should split the srpm out
14:09:09 <Kevin_Kofler> It's better than having a bazillion SRPMs.
14:09:22 <Kevin_Kofler> It's a PITA to file a Bodhi update with dozens of packages.
14:09:27 <ltinkl> I agree, the current situation is a mess hard to maintain and especially to update
14:09:39 <Kevin_Kofler> The current situation is the lesser evil.
14:09:40 <than> Kevin_Kofler: it's more work in  Bodhi update
14:09:43 <jreznik> how big is single srpm? and single update?
14:09:43 <ltinkl> OTOH, Kevin is right with bodhi as well :)
14:09:55 <rdieter> there's obviously  pros/cons here , but I tend to agree with than.
14:10:05 <Kevin_Kofler> than: It's more work if split.
14:10:08 <rdieter> problem being is that a problem in any single locale kills the whole build
14:10:16 <Kevin_Kofler> Currently we only need to list kde-l10n once.
14:10:25 <rdieter> and adding/removing locales is painful too
14:10:27 <ltinkl> isn't there a possibility to have a meta-package in bodhi comprising all the kde-l10n?
14:10:31 <Kevin_Kofler> No.
14:10:35 <ltinkl> too bad
14:10:36 <Kevin_Kofler> Bodhi doesn't support metapackages.
14:10:47 <Kevin_Kofler> You have to list all the SRPM NVRs you want to update.
14:11:11 <jreznik> one easy script can help...
14:11:20 <jreznik> but it's going to be hell big update
14:11:35 <SMParrish> Looks like the only con is with the bodhi updates.
14:11:36 <rdieter> so, downside is that we have more packages (obviously), upside is that we have far more flexibility for building, fixing things, adding (and removing) locales
14:11:53 <Kevin_Kofler> I don't see the upside at all.
14:12:00 <Kevin_Kofler> There'll be a lot of duplication in the specfiles.
14:12:16 <Kevin_Kofler> And it'll just generally be more work for no benefit.
14:12:16 <ltinkl> ye, I'd say having separate SRPMs is actually the lesser evil
14:12:26 <Kevin_Kofler> One SRPM is the lesser evil.
14:12:33 <than> Kevin_Kofler: there's befenit by update
14:12:36 <SMParrish> IMO the pros outweigh the cons
14:12:38 <Kevin_Kofler> All the tarballs are built the same way.
14:12:50 <Kevin_Kofler> than: We won't be updating single locales. Why would we?
14:12:53 <than> you don't have to update the whole kde.l10n
14:12:55 <Kevin_Kofler> Upstream releases all of them at the same time.
14:12:58 <ltinkl> or, there's a third solution
14:13:04 <ltinkl> SUSE does it with a script
14:13:08 <ltinkl> from one SRPM
14:13:08 <Kevin_Kofler> If there's a new version for one locale, there's a new version for all locales.
14:13:22 <Kevin_Kofler> ltinkl: That's what we're doing too, isn't it?
14:13:50 <rdieter> using a script/template is likely a good way forward (heck, that's precisely what I did with separate srpms in kde-redhat ages ago)
14:13:54 <jreznik> Kevin_Kofler: yep - all source tarballs are released together...
14:14:09 <Kevin_Kofler> So why would we benefit from having separate SRPMs?
14:14:12 <jreznik> rdieter: scripting is the must
14:14:27 <Kevin_Kofler> If a language doesn't build, we need to fix it anyway.
14:14:33 * ltinkl goign to look into OBS
14:14:34 <Kevin_Kofler> And it's upstream's fault, really.
14:14:41 <rdieter> Kevin_Kofler: true, but at least this way we don't have to block on it
14:14:53 <jreznik> standalone packages gives us some flexibility but as Kevin_Kofler pointed I don't see that "easier updates" reason
14:14:58 <Kevin_Kofler> That's just sweeping issues under the rug.
14:15:00 <Kevin_Kofler> I hate that.
14:15:06 <Kevin_Kofler> Just fix the bug.
14:15:15 <rdieter> it's not sweeping, it's prioritizing.
14:15:29 <Kevin_Kofler> I can look into the current Catalan mess tonight or tomorrow if needed.
14:15:50 <rdieter> any other pros/cons, and does everyone understand them?
14:16:01 <Kevin_Kofler> (But why the "translation coordinator" can't make his own language build is beyond me.)
14:16:57 <jreznik> Kevin_Kofler: because he's spanish, sorry catalan? :)
14:17:33 <rdieter> ie, are we ready to vote to enable this or not?
14:18:43 <Kevin_Kofler> -1, splitting kde-l10n only gives us a lot more work with little to no practical benefit.
14:19:07 <Kevin_Kofler> It's already split into subpackages.
14:19:14 <ltinkl> I'm undecided, the status quo must be improved but I'm not sure splitting is the right way
14:19:45 <svahl> 0 (no really opinion here)
14:19:48 <than> +1 for splitting
14:19:50 <rdieter> +1
14:20:08 <Kevin_Kofler> Separate SRPMs mean we have to run make build 50+ times.
14:20:12 * thomasj_ late in, just back from kindergarten
14:20:22 <Kevin_Kofler> And fill in 50+ names into Bodhi each time.
14:20:24 * rdieter forgets who's all vote eligible... :(  who's #5 ?
14:20:28 <SMParrish> +1 for split
14:20:37 <rdieter> ah. :)
14:20:47 <ltinkl> jreznik:
14:20:49 <Kevin_Kofler> ltinkl: What's wrong with the status quo?
14:20:52 <jreznik> sorry, my dad called me
14:21:11 <Kevin_Kofler> I'm fed up of all that "the status quo is bad" complaining with no actual practical issue.
14:21:17 <ltinkl> Kevin_Kofler: it's hard to update when a new version comes
14:21:27 <Kevin_Kofler> Splitting only makes it even harder.
14:21:42 <ltinkl> ye :/
14:21:42 <rdieter> Kevin_Kofler: we described the practical issues, you just don't agree with them.  there's a difference. :)
14:21:49 <Kevin_Kofler> You have to do the same work plus do some stuff over 50 times you now have to do once.
14:21:54 <jreznik> it's not easily revertible thing
14:21:59 <ltinkl> I agree on that
14:22:13 <jreznik> I propose - if someone prepare scripts
14:22:15 <rdieter> it's very revertable, why not ?
14:22:18 <ltinkl> bodhi plus building will be worse
14:22:31 <jreznik> making updates/maintaining easier, I'm +1, otherwise I don't like it now
14:22:45 <Kevin_Kofler> rdieter: Because we'll have tons of dead packages in CVS, pkgdb and Bugzilla.
14:23:01 <Kevin_Kofler> We already have enough dinosaurs in Bugzilla confusing users (e.g. kdebase4).
14:23:02 <jreznik> yep
14:23:04 <rdieter> true, that's all part of "more packages"
14:23:30 <rdieter> I wonder if we can poke some folks to see if we can get bz components for EOL'd releases removed
14:23:38 <jreznik> so, can someone try to write the script - if it brings less overhead then, I'm for...
14:23:49 <jreznik> rdieter: good idea
14:24:08 <rdieter> well, looks like a majority is in favor of splitting,
14:24:15 <rdieter> #agreed kde-l10n srpm split
14:24:18 <Kevin_Kofler> rdieter: I don't think that's possible, what will happen to existing (possibly closed) bugs?
14:24:35 <rdieter> Kevin_Kofler: good point, it's worth asking about though
14:24:46 <Kevin_Kofler> rdieter: Uh, we're 9 people on the steering committee, aren't we?
14:24:51 <rdieter> anyone want to work on a template/script for this ?
14:24:52 <jreznik> Kevin_Kofler: that x4 could be changed to x component?
14:25:00 <jreznik> Kevin_Kofler: 7
14:25:16 <Kevin_Kofler> Hmmm, who was on the list again?
14:25:18 <rdieter> I have some experience doing it back in the kde-redhat/kde3 days, it's not hard
14:25:48 <Kevin_Kofler> In any case, I see only 3 +1 votes.
14:25:51 <jreznik> Kevin_Kofler: 3 people from RH - so all RH people working on KDE :D + you, Rex, SMParrish, svahl I think
14:26:15 <rdieter> I thought we had only 5, it's been awhile since we've had to vote
14:26:30 <jreznik> rdieter: no, 7
14:26:34 <SMParrish> 7 was the number
14:26:36 <rdieter> ok, sorry.
14:27:21 <Kevin_Kofler> jreznik: Yeah, that was the list.
14:27:40 <rdieter> alright, no pass then.
14:27:45 <Kevin_Kofler> So OK, we have +1 from than, rdieter, SMParrish, 0 from svahl, -1 from me.
14:28:01 <rdieter> and ltinkl: 0 (undecided, so far)
14:28:02 <Kevin_Kofler> ltinkl, jreznik?
14:28:11 <ltinkl> zarro
14:28:19 <rdieter> jreznik voted +1
14:28:33 <rdieter> [08:22] <jreznik> making updates/maintaining easier, I'm +1, otherwise I don't like it now
14:28:39 <rdieter> unless I'm misinterpreting that...
14:28:39 <jreznik> Kevin_Kofler: as I said - in case of good supporting script I'm +1
14:28:44 <ltinkl> that's four +1's
14:28:44 <Kevin_Kofler> Well, +1 contingent on scripts being there to make it easier.
14:28:55 <Kevin_Kofler> There are no such scripts yet.
14:29:06 <Kevin_Kofler> So that's not a vote for doing that split now. ;-)
14:29:19 <rdieter> I'll revive the sh script I had before.
14:29:21 <Kevin_Kofler> I also don't see how scripts are going to solve the real issues.
14:29:31 <rdieter> I agree, having a template/script is a pre-req
14:29:33 <Kevin_Kofler> Koji is going to be loaded a lot more with the many builds.
14:29:49 <Kevin_Kofler> Also because it needs kdelibs-devel and its huge dependencies in the buildroot.
14:29:50 <rdieter> since we'll have to do a bunch of reviews for the new packages
14:29:57 <Kevin_Kofler> (to build the translated docs)
14:30:06 <jreznik> Kevin_Kofler: at least - script would help us to maintain it - without it, it's unmaintainable
14:30:13 <rdieter> #action rdieter to work on kde-l10n template/script(s)
14:30:20 <Kevin_Kofler> And for the Bodhi update, the issue is not just generating the list.
14:30:22 <Kevin_Kofler> It
14:30:31 <Kevin_Kofler> It's also that Bodhi gets slower the more SRPMs are in the update.
14:30:43 <rdieter> #topic plasma-netbook tracker
14:30:50 <Kevin_Kofler> It's going to take forever and a year to process the update requests.
14:31:13 <rdieter> hrm... I don't recall this (netbook tracker) getting done, not by me anyway, anyone else ?
14:31:14 <Kevin_Kofler> I think this is a huge step backwards and I don't see what we're gaining.
14:31:24 <Kevin_Kofler> (the kde-l10n split)
14:31:59 <svahl> bug #549746
14:32:01 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=549746 medium, low, ---, than, ASSIGNED, Tracker for plasma-netbook related issues
14:32:11 * rdieter yays
14:32:23 <Kevin_Kofler> I just see my serious technical concerns having been ignored and arguments having been used despite me basically proving them void.
14:33:09 <Kevin_Kofler> We already take too long to get a new KDE out.#
14:33:18 <Kevin_Kofler> (Upstream usually already has the next version at that point.)
14:33:26 <Kevin_Kofler> (or almost)
14:33:48 <rdieter> Kevin_Kofler: no one is discounting your concerns, they are indeed valid, but we also have to weight that against the other issues raised (whether you agree with them or not)
14:34:13 <jreznik> Kevin_Kofler: that's another issue we should solve - we need update process, to know who's working on what, not just mess someone is building that, someone committing there...
14:34:37 <Kevin_Kofler> Re plasma-netbook, I think we need someone to volunteer to test and fix things if we want to support it officially.
14:34:48 <rdieter> Kevin_Kofler: indeed
14:35:08 <Kevin_Kofler> Basically a spin maintainer for KDE Netbook, just like svahl signed up for the KDE Desktop spin.
14:35:23 <Kevin_Kofler> I don
14:35:26 <rdieter> #help need volunteers to lead plasma-netbook feature, testing, offer feedback
14:35:26 * jreznik volunteers as he is netbook user
14:35:34 <Kevin_Kofler> I don't think a dual-use spin makes that much sense.
14:35:37 * mefoster too
14:35:44 <mefoster> (helping, not leading)
14:35:45 <svahl> I could help there too
14:36:04 <jreznik> for netbook we need lightweight spin
14:36:32 <jreznik> it does not target common uses but really constrained uses - web, mail...
14:36:33 <ltinkl> OpenOffice anyone? :)
14:36:43 <rdieter> yeah, I'd propose baby step #1, perhaps create a separate comps group for kde-netbook , then eventually consider a separate spin
14:36:50 <Kevin_Kofler> The question is, do you want that netbook interface or do you want a "netbook as mini computer" interface (i.e. plasma-desktop)?
14:36:53 <ltinkl> rdieter: +1
14:36:54 <svahl> BTW: is plasma-netbook considered "official" or is it just a tech preview?
14:37:01 <mefoster> I have actually used eclipse and openoffice.org on my Aspire One -- although with an external monitor :)
14:37:30 <Kevin_Kofler> Did Eclipse allow you to enter more than a character per minute? ;-D
14:37:53 <jreznik> Kevin_Kofler: netbook interface... if I want to use it as netbook - small computer to access net
14:38:05 <rdieter> so, is jreznik volunteering to lead the kde-netbook efforts?
14:38:13 <jreznik> that was the first EEE and then they killed it with WXP
14:38:48 <jreznik> rdieter: I'm interested in and with help from svahl, mefoster we can have nice KDE based system for netbooks
14:38:59 <rdieter> ok, fair enough.
14:39:24 <rdieter> #action jreznik, svahl, mefoster to help work on kde-netbook support, testing
14:39:45 <Kevin_Kofler> jreznik: So start by having a look at the issues currently on the tracker? :-)
14:39:47 <rdieter> #topic re-test enabling qt/webkit jit
14:39:48 <jreznik> I have promise to accept it as spin from spins people :D
14:39:50 <svahl> btw: plasma-netbook is just useless without kdeplasma-addons. but the latter has kdeedu-marble as a requirement which is quite big
14:39:59 <Kevin_Kofler> Some might just be missing packages (e.g. kdeplasma-addons).
14:40:18 <rdieter> svahl: sure,that's an issue in need of resolving somehow
14:40:22 <Kevin_Kofler> svahl: Hmmm, kdeplasma-addons-netbook subpkg?
14:40:54 <svahl> Kevin_Kofler: would be a start
14:41:12 <jreznik> netbook spin would need some "intelligent" cuts/splits/reorganization of packages
14:41:21 <rdieter> svahl: much of the netbook efforts will be around where/how to do prudent package splitting
14:41:32 <rdieter> jreznik: exactly
14:41:33 <Kevin_Kofler> That said, Marble is cool to have on a netbook, with mobile Internet it allows you to use the netbook as a universal city map.
14:41:55 <Kevin_Kofler> But whether that's enough to warrant it being installed by default is another question.
14:42:21 <Kevin_Kofler> The default will have to be minimal for those devices with extremely small SDDs.
14:43:01 <Kevin_Kofler> Re the QtWebKit JIT:
14:43:03 <Kevin_Kofler> https://bugzilla.redhat.com/show_bug.cgi?id=549994
14:43:04 <buggbot> Bug 549994: medium, low, ---, than, CLOSED RAWHIDE, kwin crashes when enabling plasma-netbook workspace and selinux=enforcing
14:43:05 <rdieter> back to /topic , from our discussions around qtwebkit/jit , it appears to indeed still be an issue.
14:43:13 <Kevin_Kofler> This is why I redisabled it.
14:43:14 <jreznik> Kevin_Kofler: it was problem with first netbooks but indeed - it should be less space consuming...
14:43:23 <Kevin_Kofler> It turned out to be due to QtWebKit.
14:43:45 <jreznik> we should contact upstream what they thought
14:43:54 <Kevin_Kofler> (plasma-netbook uses something WebKit-based by default)
14:43:55 <rdieter> I'm surprised that only happens on rawhide, so could be due to it's (rawhide's) more restrictive selinux policy (vs. more-relaxed policy of releases)
14:44:16 <Kevin_Kofler> Maybe it's arch-specific?
14:44:21 <rdieter> who wants to own this issue, and work on poking upstream ?
14:44:27 <Kevin_Kofler> Is the JIT already enabled on x86_64?
14:44:32 <jreznik> Kevin_Kofler: it's arch specific, JIT is enabled only on few archs
14:44:38 <rdieter> Kevin_Kofler: ah, could be.
14:45:04 <Kevin_Kofler> If it's always disabled on x86_64, then there'd be no wonder you can't reproduce it (and it'd just be another reason to keep it off, we don't want 32-bit to be faster than 64-bit ;-) ).
14:45:44 <Kevin_Kofler> 4.6 has some code for x86_64 JIT, but I don't know if it's enabled yet.
14:46:08 <rdieter> #help need to test/evaluate qtwebkit/jit, and poke upstream as necessary
14:46:28 <Kevin_Kofler> FWIW, this is a general WebKit issue and also hits webkitgtk.
14:46:48 <Kevin_Kofler> (Chromium does its own thing for JS, see V8.)
14:47:22 <Kevin_Kofler> (And I don't know how the V8 JIT reacts to SELinux, but that's not our problem.)
14:47:31 <rdieter> moving on...
14:47:34 <jreznik> it's enabled only on 32 bit, my home laptop is 32 bit
14:47:44 <rdieter> #topic #554713: Only "Internal audio analog stereo" present after login
14:47:49 <rdieter> bug #554713
14:47:51 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=554713 medium, low, ---, than, NEW, Only "Internal audio analog stereo" present after login
14:48:15 <rdieter> I asked there what version of kdemultimedia was used, the updated kmix/pa patch in 4.3.90-2 is a bit better
14:48:29 <svahl> I've tested this during the meeting with kdemultimedia-4.3.90-2 on anohter machine: same behaviour
14:48:48 <rdieter> so... it's picking the wrong pa device?
14:48:55 <rdieter> ie, doesn't work ?
14:48:59 <Kevin_Kofler> Uh, this has nothing to do with KMix at all.
14:49:06 <Kevin_Kofler> It's the Phonon KCM at work there.
14:49:09 <svahl> yes, only the internal audio device i shown
14:49:19 <svahl> i=is
14:49:26 <rdieter> oh, I thought the report mentioned what's seen in kmix (sorry)
14:49:45 <Kevin_Kofler> Systemsettings → Multimedia is the Phonon KCM, not KMix.
14:50:30 <rdieter> duh, nevermind me then. -ENOTENOUGHCOFFEE
14:51:11 <than> svahl: does it happen in F12?
14:51:31 <svahl> than: I haven't testet that, yet
14:51:59 <svahl> could it be a wrong starting order of pulseaudio and start-pulseaudio-kde (due to the log entries in messages)?
14:54:18 <rdieter> looks like we're stumpted for now, until we can do some more debugging and reproduce it I guess
14:54:49 <rdieter> #topic open floor
14:55:02 <rdieter> we've about 5 min, left, any parting words ?
14:55:13 <svahl> rdieter: it should be reproducible with the next nightly images
14:55:33 <rdieter> could be rawhide specific, I don't see that on my f12+kde-4.3.90 box
14:55:36 <thomasj> f12, missing my intel hda sound chip. It offers only internal sound and my ati sound chip. If that helps.
14:55:45 <thomasj> kde 4.3.4
14:56:32 <rdieter> I'll take the default apps requirements, http://fedoraproject.org/wiki/User:Rdieter/FUDCon_Toronto_KDE_F13_TODOs , topic to ml for further discussion
14:56:41 <jreznik> ok
14:56:46 <Kevin_Kofler> I think this voting procedure is actually encouraging rushed and bad decisions. Previously we tried to rediscuss things until we got a full consensus, now we just vote and rush things through with too little discussion.
14:57:01 <jreznik> Kevin_Kofler: +1
14:57:03 <jreznik> :)
14:57:25 <rdieter> oh, I thought we had clearly heard everyone's point of view, and opinion already.  Did we miss something ?
14:57:31 <Kevin_Kofler> There's no need to rush changes like the kde-l10n split and I think the unwanted side effects will bite us in the rear.
14:57:55 <rdieter> tell ya what, let's reserve judgement until we have the template/scripts, then we can rediscuss and vote again
14:58:16 <jreznik> I think if we want vote it should be 2 rounded (one meeting propose, then discuss on ml - and get more replies from community, and second meeting to vote)
14:58:51 <mefoster> FYI: progress continues on sesame2 (although it'll soon be obsolete by virtuoso, I fear ...)
14:59:00 <mefoster> akurtakov is being very helpful
14:59:12 <jreznik> rdieter: yep - prepare scripts, prove it's possible, it's a good solution, everyone can think about it in quiet place (toilet :D) and then vote :)
14:59:14 <rdieter> mefoster: thanks, tis true that kde-4.4 nepomuk will use virtuoso by default.
14:59:50 <mefoster> Well, this process is shaking out a lot of old Java packaging stuff anyway ...
14:59:54 <rdieter> mefoster: how many reviews remain?  (rough estimate)
15:00:19 <mefoster> Roughly? Lots ...
15:00:24 <rdieter> heh, ok.
15:00:56 <jreznik> mefoster: I can help with reviews but I'm not java expert
15:00:56 <rdieter> #help reviewers needed for remaining java/soprano-sesame stack
15:01:00 <mefoster> Although once one more package gets through (akurtakov currently reviewing), everything is pretty small and the specs are nearly cut-and-paste identical so should go fast
15:01:23 <rdieter> thanks everyone, time's up.
15:01:26 <rdieter> #endmeeting