14:02:28 <rdieter> #startmeeting KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-01-26
14:02:28 <zodbot> Meeting started Tue Jan 26 14:02:28 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:33 <rdieter> #meetingname kde-sig
14:02:33 <zodbot> The meeting name has been set to 'kde-sig'
14:02:48 <rdieter> #chair Kevin_Kofler jreznik than
14:02:48 <zodbot> Current chairs: Kevin_Kofler jreznik rdieter than
14:02:54 <rdieter> #topic roll call
14:02:58 <rdieter> who's present today
14:03:00 <mathstuf> here
14:03:00 <rdieter> ?
14:03:19 * jreznik is here
14:03:27 * ltinkl is here
14:03:37 <Kevin_Kofler> Present.
14:04:51 <rdieter> #topic kde-4.3.5, kde-4.3.95 status updates
14:04:57 <rdieter> easy one first
14:05:38 <rdieter> re: 4.3.95 , as of this morning, f11 builds are done @ kde-redhat/unstable too, so we're all good for testing there
14:06:09 <rdieter> 4.3.5 builds are going in koji now, should be all done in another hour or 2 or so
14:06:11 <Kevin_Kofler> Re 4.3.5, you synced an old kdegames to F-11, I already handled the rebasing of the trademarks patch!
14:06:24 <rdieter> damn, oops
14:06:32 * SMParrish_away late but here
14:06:46 <rdieter> sorry about that, can fix/revert after meeting
14:07:00 <jreznik> #info 4.3.95 f11 builds are done @ kde-redhat/unstable
14:07:11 <Kevin_Kofler> We should also fix the kde-l10n-sl mess, if that's not Slovenian it shouldn't be called -Slovenian. ;-)
14:07:16 <rdieter> there's also a small complication around 4.3.5 and webkitkde
14:07:44 <Kevin_Kofler> IMHO webkitkde shouldn't be updated again before 4.4.
14:07:47 <ltinkl> Kevin_Kofler: lol what's inside then? :)
14:08:08 <rdieter> Kevin_Kofler: I'd prefer that too, but the alternative is dropping webkit support
14:08:20 <Kevin_Kofler> nucleo?
14:08:29 <Kevin_Kofler> I think it doesn't make sense to update webkitkde now.
14:08:37 <Kevin_Kofler> We'll update it together with KDE 4.4.
14:09:09 <Kevin_Kofler> ltinkl: Reportedly sl = Sierra Leone, si (new in 4.4) = Slovenian. But I haven't verified this.
14:09:38 <ltinkl> Kevin_Kofler: si is Slovenian, ye
14:10:04 <ltinkl> anyway, it's strange to mark the translation packages by the country name (!)
14:10:18 <rdieter> #topic kde-l10n-sl   Slovenian vs Sierra Leone
14:10:42 <Kevin_Kofler> ltinkl: IMHO we should stop doing that entirely.
14:10:50 <Kevin_Kofler> But then we need a transition plan.
14:11:02 <rdieter> related topic is the kde-l10n template I worked on.
14:11:05 <Kevin_Kofler> We should use the upstream names, both for kde-l10n and for the old kde-i18n.
14:11:26 <Kevin_Kofler> It doesn't make sense to do what we do now, and it's even more embarassing when we do it wrong.
14:11:46 <rdieter> at least for kde-l10n, I'd second Kevin_Kofler's suggestion, with 4.4 , switch to kde-l10n-<locale> (upstream) naming
14:11:56 <ltinkl> rdieter: +1
14:12:00 <ltinkl> less confusion
14:12:21 <rdieter> downside is when/if we push updates for < f13, comps will need changing
14:12:35 <rdieter> but that's manageable
14:12:50 <rdieter> well, f13 comps will need changing too, of course. :)
14:12:58 <Kevin_Kofler> We could change kde-i18n for F13 only (for now).
14:13:10 <Kevin_Kofler> It doesn't make sense to push an update just for that.
14:13:23 <rdieter> I agree with that too.
14:13:55 <ltinkl> what do the others think?
14:14:02 <ltinkl> jreznik, than ?
14:14:32 <jreznik> sounds good
14:14:32 <than> Kevin_Kofler: +1
14:15:25 <rdieter> #agreed with kde-4.4, work to rename translations to kde-l10n-<locale>
14:15:51 <Kevin_Kofler> But we should also s/Slovenian/SierraLeone/ for 4.3.5.
14:15:59 <Kevin_Kofler> And fix comps.
14:16:08 <rdieter> and kde-i18n-<locale> rename for f13+ , all agreed there too
14:16:10 <rdieter> ?
14:16:17 <Kevin_Kofler> It's really a bad screwup. :-/
14:16:42 <Kevin_Kofler> rdieter: I think so.
14:17:04 <Kevin_Kofler> I didn't see any complaints.
14:17:06 <rdieter> just checking before marking it agreed for the log
14:17:47 <nucleo> Kevin_Kofler: Ok. No more updates untill 4.4 release.
14:18:00 <rdieter> #agreed for f13+, also rename translations to kde-i18n-<locale>
14:18:17 <Kevin_Kofler> nucleo: FYI, this is just about releases. In Rawhide we want to track the 4.4 stuff of course.
14:18:46 <Kevin_Kofler> For the releases we'll want to group the webkitpart update together with the KDE 4.4 one.
14:19:28 <Kevin_Kofler> But grouping one with 4.3.5 seems to cause more problems than it solves, so just leave it as is for now.
14:19:49 <rdieter> even if "leaving as-is" means disabling webkitpart support ?
14:19:55 <ltinkl> even more confusion: .si is Slovenia (as country code), si is the Sinhala language code
14:20:00 <nucleo> So, in kdebase 4.3.5 webkitpart should be droped temporarily
14:20:10 <Kevin_Kofler> ltinkl: Oh, is it?
14:20:18 <Kevin_Kofler> So what's what language now?
14:20:18 <ltinkl> the Slovenian (as the language) indeed uses sl
14:20:26 <ltinkl> so upstream got it wrong I guess
14:20:30 <rdieter> lol
14:20:46 <Kevin_Kofler> Upstream is using wrong language codes? Are you sure?
14:21:01 <ltinkl> http://websvn.kde.org/trunk/l10n-kde4/sl/messages/entry.desktop?revision=1068128&view=markup
14:21:03 <ltinkl> see
14:21:20 <mathstuf> SierraLeone isnt a language; or at least doesnt sound like one
14:21:22 <rdieter> ltinkl: you mind doing followup with upstream, and get to the bottom of things, before we act?
14:21:25 <ltinkl> "sl" is Slovenian, ".si" is Slovenia
14:21:32 <Kevin_Kofler> rdieter, nucleo: Huh?
14:21:33 <ltinkl> mathstuf: ye, that too
14:21:42 <mathstuf> Krio is its language
14:21:46 <Kevin_Kofler> I thought the problem was that updating webkitpart breaks things?!
14:21:50 <rdieter> Kevin_Kofler: kdebase-4.3.5 + webkitpart-0.0.2 = build fail
14:22:07 <rdieter> so options are update webkitpart to match, or drop support
14:22:07 <Kevin_Kofler> Oh, then we do want to update, I guess!
14:22:19 <ltinkl> well, I'll check with upstream (Dirk & co.) before we start fixing our stuff :)
14:22:35 <than> ltinkl: please check with dirk müller
14:22:39 <Kevin_Kofler> Well yes, if 4.3.5 expects an updated webkitpart now, then we do need to update it!
14:22:41 <rdieter> #task ltinkl to check with kde upstream about locale naming issues (si vs sl)
14:23:02 <Kevin_Kofler> I thought it was the opposite (i.e. it didn't work with the updated one, just with the old one).
14:23:06 <rdieter> oops
14:23:13 <rdieter> #action  ltinkl to check with kde upstream about locale naming issues (si vs sl)
14:23:26 <nucleo> Kevin_Kofler: but then many patches needed backport in konq-plugins to build it with new webkitpart
14:23:28 <rdieter> Kevin_Kofler: sorry for the confusion
14:23:43 <Kevin_Kofler> Oh, so konq-plugins is the trouble?
14:23:46 <rdieter> #topic webkitpart, update or not for 4.3.5
14:24:03 <Kevin_Kofler> Well, as the update seems to be required, let's do it.
14:24:16 <rdieter> Kevin_Kofler: it'll be required sooner or later
14:24:17 <jreznik> it looks like
14:24:18 <Kevin_Kofler> Alternatively, we could revert the patches from 4.3.5 which expect the new version.
14:24:32 <nucleo> Kevin_Kofler: yes, the better is leave old webkitkde and konq-plugins and drop webkitpart in kdebase
14:24:32 <Kevin_Kofler> But I think we should just fix the konq-plugins issue.
14:24:42 <Kevin_Kofler> We should do it for Rawhide anyway.
14:24:43 <rdieter> might as well be sooner, but I'm worried that webkitpart will change/rename things again
14:25:27 <Kevin_Kofler> ltinkl: I checked, upstream uses the correct language codes and we didn't screw up, -sl really is -Slovenian.
14:25:32 <Kevin_Kofler> http://websvn.kde.org/trunk/l10n-kde4/sl/messages/entry.desktop?revision=1068128&view=markup - sl = Slovenian
14:25:41 <Kevin_Kofler> http://websvn.kde.org/trunk/l10n-kde4/si/messages/entry.desktop?revision=1078050&view=markup - si = Sinhala
14:25:48 <rdieter> woo! :)
14:25:50 <Kevin_Kofler> It's whoever claimed that sl = Sierra Leone who screwed up.
14:25:56 <nucleo> there is in kdevase only kttsplugin uses webkitpart
14:26:02 <nucleo> *kdebase
14:26:33 <rdieter> that's mostly harmless then, either (re kdebase/webkitpart).
14:26:49 <rdieter> I'll keep going, as long as nothing else breaks, we can just leave that out of kdebase-4.3.5
14:26:51 <Kevin_Kofler> Well, I can revert the upstream patch expecting the new version.
14:26:58 <Kevin_Kofler> It's probably fairly easy.
14:27:38 <Kevin_Kofler> There's also KGet in kdenetwork, but they're disabling webkitpart support there for 4.4 as "incomplete", so might as well do so in 4.3.5 as well.
14:28:23 <Kevin_Kofler> nucleo: Uh, doesn't Konqueror itself also need to know about the webkitpart?
14:28:42 <nucleo> Kevin_Kofler: no
14:28:46 <rdieter> so, plan a, as long as nothing else breaks, stick with existing webkitkde-0.0.2
14:28:55 <nucleo> you mean revert this http://websvn.kde.org/?view=revision&revision=1071180 ?
14:29:00 <rdieter> otherwise, come up with some sort of plan b. :)
14:29:22 <Kevin_Kofler> nucleo: Yeah, that's the one, thanks.
14:29:29 <Kevin_Kofler> Trivial to revert.
14:29:51 <Kevin_Kofler> Just svn diff -r 1071180:1071179 …
14:30:43 <Kevin_Kofler> Do you want me to handle this?
14:30:47 <rdieter> Kevin_Kofler: you want to patch kdebase then?  (I'll be pretty swamped finishing the remaining 4.3.5 builds and other stuff probably)
14:30:51 <rdieter> yeah
14:30:55 <rdieter> please. :)
14:31:10 <Kevin_Kofler> OK, doing.
14:31:26 <rdieter> #action Kevin_Kofler to patch/revert kdebase to support older/existing webkitpart
14:31:47 <rdieter> #topic kde-l10n  template
14:32:14 <rdieter> I've got a rough first draft, of split/templated kde-l10n
14:32:32 <rdieter> http://rdieter.fedorapeople.org/rpms/kde-l10n.spec
14:32:53 <rdieter> I used de/German as the example here, but it should mostly just-work for pretty much any locale
14:33:21 <rdieter> cleanup to do would be to make excluding stuff simpler
14:33:50 <rdieter> ideally, do something similar for "include" type stuff as well (ie, make the template easier to add/remove stuff)
14:34:17 <rdieter> but you should get the idea, this version already uses the agreed-upon kde-l10n-<locale> style
14:34:57 <Kevin_Kofler> The problem is that all the logic in %build to blacklist stuff has to be copied to every single specfile.
14:34:58 <rdieter> another TODO is a script to generate the spec for all supported locales, but that should be fairly trivial
14:35:06 <ltinkl> rdieter: I wonder how this renaming affects the PackageKit language plugin
14:35:15 <Kevin_Kofler> Plus we need to issue n builds if we change anything in that logic.
14:35:21 <Kevin_Kofler> n > 50, that's quite a lot.
14:35:31 <rdieter> true
14:35:57 <Kevin_Kofler> I recently had to change kde-l10n to get rid of leftover kpilot translations so I could have kpilot ship them all (some of them got removed, some not).
14:36:05 <Kevin_Kofler> I was able to change it in one place.
14:36:18 <rdieter> I was hoping to factor include/exclude/blacklist logic into some common/shared code (in kde-l10n somewhere?)
14:36:40 <rdieter> I''d consider getting that all correct and implemented a requirement before moving forward
14:36:46 <Kevin_Kofler> With split SRPMs, I'd have had to change everything and issue at least a dozen builds, up to >50 if I didn't want to have to check which languages were actually affected (i.e. extra work).
14:37:26 <rdieter> or just do all the builds, which could also could benefit from scripting
14:37:31 <jreznik> Kevin is right here
14:38:03 <rdieter> let's consider *that* also a requirement/blocker, else maintainance would be a much larger burdon, indeed.
14:39:33 <rdieter> my first attempt at doing some of this involved trying to make find-lang.sh smarter to find all this extra stuff, but oi, staring at the sed regular expression hackery there hurt my brane.
14:39:44 <Kevin_Kofler> If we just do all the builds at any change, why bother with separate SRPMs?!
14:40:06 <rdieter> Kevin_Kofler: at least we'd have the flexibility to do it either way, if we so chose.
14:41:03 <rdieter> any other feedback/requirements for the template?
14:41:37 <Kevin_Kofler> rdieter: The thing is, that's worthless in practice and not worth the drawbacks.
14:41:57 <Kevin_Kofler> Bodhi updates for KDE will become huge and Bodhi will take even longer to process them than it already does.
14:42:12 <Kevin_Kofler> It might even time out entirely.
14:42:38 <rdieter> I'd venture it'll be about the same, the amount of content will be the same
14:42:49 <jreznik> yes, need to rebuild all for just a few changed is bad idea...
14:42:53 <rdieter> but I can ask lmacken for sure, if you want
14:43:32 <Kevin_Kofler> The amount of content will be larger as there are more SRPMs, which are also moved.
14:43:54 <Kevin_Kofler> And I think Bodhi works at Koji build level and so it has to move >50 tags rather than 1.
14:43:59 <Kevin_Kofler> That takes >50 times longer, obviously.
14:44:07 <rdieter> except each smaller srpms = approximate the same as the one larger srpm
14:44:21 <Kevin_Kofler> That's irrelevant.
14:44:33 <Kevin_Kofler> The tag move operations are >50 times more.
14:44:44 <rdieter> the time is the moving around of the bits, not the # of srpms, but again, we can get facts instead of conjecture, if you want. :)
14:45:08 <Kevin_Kofler> ~4 times as much if you count all of the KDE update.
14:45:17 <jreznik> ok, rdieter to find out facts ;-)
14:45:44 <Kevin_Kofler> The time it needs between me clicking submit and Bodhi being done is used for tag moves.
14:45:53 <Kevin_Kofler> The more tags to move, the longer it takes.
14:46:03 <Kevin_Kofler> It already takes long enough to time out my browser at times.
14:46:24 <jreznik> we have to check what will more packages do with bodhi for splits too... so it's a good question at all
14:47:20 <rdieter> right, the # of pkgs getting tagged will be approx the same.
14:48:03 <rdieter> #task rdieter to followup with lmacken on pkg split impact on bodhi
14:48:28 <rdieter> anything else, or move on ?
14:49:20 <rdieter> #topic open discussion
14:49:42 <rdieter> SMParrish: you notice the kpk-0.5.4-2 build I did, seems to fix the (self-induced) crashers I was seeing
14:50:08 <Kevin_Kofler> FYI, I issued kdebase builds with that patch reverted, we'll see if they build.
14:50:22 <SMParrish> rdieter: No I hadn't but I'll give it a try
14:50:31 <Kevin_Kofler> Well, they don't. :-(
14:50:31 <rdieter> much happier now, kpk actually works (the basic stuff, notifying of updates, actually installing them..)   :)
14:51:32 <Kevin_Kofler> #info kde-l10n-sl is really Slovenian, so there's nothing we need to fix there for 4.3.5.
14:51:36 <rdieter> I still have my reservations about kpk's apparent lack of upstream love/maintainance (ie, only 1 already-busy developer)
14:51:40 <Kevin_Kofler> (I just wanted this to be logged.)
14:52:33 <Kevin_Kofler> rdieter: There's no real alternative to KPK.
14:52:33 <SMParrish> rdieter: I have concerns about that as well.  Upstream is also not keeping up with PK changes and releases which is becoming a big issue
14:52:46 <Kevin_Kofler> Oh BTW, the ABRT topic was not brought up?!
14:52:59 <rdieter> oops
14:53:03 <jreznik> Kevin_Kofler: yep but it's too late now :(
14:53:14 <rdieter> #topic drop ABRT from the KDE spin?
14:53:15 <Kevin_Kofler> No, we have 7 minutes left.
14:53:15 <jreznik> I've invited ABRT developers to join us but as we were out of time
14:53:17 <rdieter> Kevin_Kofler: go ahead.
14:53:40 <Kevin_Kofler> So I proposed that we drop ABRT from the KDE spin for multiple reasons:
14:53:58 <Kevin_Kofler> * most of our stuff is KDE apps which use KCrash/DrKonqi anyway
14:54:12 <Kevin_Kofler> * it reports crashes to downstream instead of upstream where they belong
14:55:03 <jreznik> for jmoskovc:  * most of our stuff is KDE apps which use KCrash/DrKonqi anyway, * it reports crashes to downstream instead of upstream where they belong
14:55:03 <Kevin_Kofler> * it's a GTK+-based service running in the background, I'd like to avoid GTK+ in memory all the time and with KNM we might be getting there
14:55:27 <nucleo> What about Internet menu in KDE 4.4? Should it be splited on submenus or it should be like in 4.3.x?
14:55:34 <nucleo> in Kickoff
14:55:40 <rdieter> just because abrt isn't ideal *now* in it's infancy, doesn't mean we should abandon it.  I'd suggestion compiling a list of gripes/concerns, and give feedback to abrt developers.  Now, if our feedback/concerns do not get addressed, *then* reconsider our options
14:55:56 <Kevin_Kofler> Well, what needs to be improved:
14:56:02 <rdieter> nucleo: we use kde/upstream menu style choices there
14:56:09 <jreznik> Kevin_Kofler: jmoskovc is a lead developer
14:56:10 <Kevin_Kofler> * reporting to upstream trackers – a lot of work as there are many upstreams!
14:56:22 <Kevin_Kofler> * Qt/KDE frontend
14:57:11 <Kevin_Kofler> * an option to easily ignore classes of crashes (e.g. I don't want to be told for the bazillionth time about some warn_on_slowpath in the kernel)
14:57:53 <rdieter> that ones not really required by us (kde-sig) but a user-desirable feature (by Kevin_Kofler). :)
14:58:36 <Kevin_Kofler> It's true that those are what I'd personally want to see improved, opinions of the other folks here may differ. ;-)
14:58:58 <Kevin_Kofler> But even with that improved, I'm still not convinced we have to ship it on the KDE spin at all.
14:59:12 <Kevin_Kofler> As KDE already has its own solution (DrKonqi).
14:59:24 <jreznik> Kevin_Kofler, rdieter: abrt is very modular/pluggable - so I think everything is possible
14:59:37 <rdieter> Kevin_Kofler: kde's solution only works for kde apps, of course.
14:59:56 <Kevin_Kofler> Oh, another thing I'd like to see changed: actually install -debuginfo packages instead of extracting them into the cache, it makes it easier to remove them later.
15:00:10 <jreznik> Kevin_Kofler: Dr Konqui has other problems - exactly opposite ones - we don't know about crashes - and these crashes could be our problem
15:00:26 <jreznik> and installing debug infos is not very well done right now
15:00:29 <Kevin_Kofler> But that requirement and the "ignore classes of crashes" one aren't really related to KDE, they're nice-to-haves.
15:00:34 <rdieter> makes me wonder, when a kde app crashes, is it true or not that drkonqi gets in first (before abrt)?
15:00:46 <rdieter> it's not clear to me, I thought it was true.
15:00:54 <Kevin_Kofler> AFAICT, DrKonqi catches it and ABRT doesn't see it.
15:00:59 <rdieter> ok
15:01:02 <Kevin_Kofler> (unless you disable DrKonqi)
15:01:04 <jreznik> rdieter: dr. konqui has to be disabled
15:01:18 <Kevin_Kofler> jreznik: Hopefully never.
15:01:25 <Kevin_Kofler> At least not until ABRT can report to bugs.kde.org.
15:01:36 <rdieter> so what's the harm then ?  we're only getting abrt reports for stuff not caught by drkonqi
15:01:37 <jreznik> there's sig* handler in kapplication
15:01:37 <Kevin_Kofler> I don't want all those crash reports in the downstream bugzilla!
15:02:07 <Kevin_Kofler> rdieter: It wastes precious live image space.
15:02:26 <rdieter> ok, I'm open to analyzing the space usage, and make a decision based on that.
15:02:30 <rdieter> Kevin_Kofler: you want to do that ?
15:02:35 <jreznik> Kevin_Kofler: it's not so big - few scripts
15:02:38 <jreznik> jmoskovc: ?
15:03:40 <rdieter> well, now we are out of time, let's continue in #fedora-kde
15:03:54 <rdieter> and perhaps discuss this furhter next week.
15:04:02 <rdieter> thanks everyone
15:04:10 <rdieter> #endmeeting