13:59:40 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-06-15
13:59:40 <zodbot> Meeting started Tue Jun 15 13:59:40 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:59:44 <rdieter> #meetingname kde-sig
13:59:44 <zodbot> The meeting name has been set to 'kde-sig'
13:59:52 <rdieter> #topic roll call
13:59:55 <rdieter> who's present today?
13:59:55 <Kevin_Kofler> Present.
13:59:59 * jreznik is here
14:00:02 * thomasj is here
14:00:15 * ltinkl is here
14:00:30 * than is present
14:00:37 <rdieter> #chair Kevin_Kofler jreznik thomasj ltinkl than
14:00:37 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter than thomasj
14:00:48 <rdieter> #info Kevin_Kofler jreznik thomasj ltinkl than (and rdieter) present
14:00:58 <SMParrish_mobile> here
14:01:11 <rdieter> #info SMParrish_mobile present too
14:01:18 <rdieter> #topic kde-4.4.4 update status
14:01:40 <rdieter> well, push-to-stable-worthy?
14:02:04 <rdieter> any remaining issues, or builds to do?
14:02:14 <Kevin_Kofler> And why aren't we pushing it to F11? I have it all built, it would be trivial to file the push.
14:02:35 <Kevin_Kofler> I could send it straight to stable along with the F12 and F13 pushes.
14:03:06 <than> rdieter: i think we can push it tp stable
14:03:08 <jreznik> have anyone tested 4.4.4? I was quite busy
14:03:09 <thomasj> Didn't we discuss that already last week?
14:03:29 <rdieter> I've been using 4.4.4 since we had the builds ready, good to go as far as I'm concerned
14:03:47 <rdieter> Kevin_Kofler: I guess we can discuss that again (at the end), if you want
14:04:29 <rdieter> ok, anyone opposed to pushing kde-4.4.4 to stable updates?
14:04:47 <Kevin_Kofler> I'm not aware of any blockers.
14:04:58 <ltinkl> push it I guess
14:05:12 * thomasj is +1 4.4.4 to stable F-12, F-13
14:05:19 <ltinkl> there haven't been any reports of something broken
14:05:31 <rdieter> #agreed kde-4.4.4 updates to be queue'd for stable updates asap
14:05:35 * jreznik does not vote
14:05:38 <rdieter> alrighty
14:06:00 <rdieter> #topic QtWebKit security update status
14:06:09 <rdieter> jreznik, ltinkl : how goes the fun?
14:06:16 <rdieter> wrt QtWebKit security isssues
14:06:22 <ltinkl> rdieter: building atm
14:06:22 <jreznik> rdieter: building latest three patches
14:06:35 <rdieter> ok, I almost hate to ask, but...
14:06:50 <rdieter> do we know if 4.7.0 is affected too or not?
14:06:51 <ltinkl> yes? :) F11? xD
14:07:00 <thomasj> :D
14:07:02 <jreznik> http://koji.fedoraproject.org/koji/taskinfo?taskID=2251574
14:07:04 <Kevin_Kofler> We need to push that stuff to F11, F12 and F13 ASAP.
14:07:10 <Kevin_Kofler> Security fixes really need to be pushed.
14:07:12 <ltinkl> rdieter: we don't atm, haven't even tried
14:07:24 <rdieter> I was afraid of that.
14:07:29 <jreznik> rdieter: 4.7 - it's devel, so not worth to do it right now
14:07:37 <than> ltinkl: we have to fix it for F11 tto
14:07:42 <jreznik> hopefully Nokia releases it with patches
14:07:45 <ltinkl> hopefully :)
14:07:51 <jreznik> it should not regress as it's just webkit
14:08:09 <rdieter> ok, fair 'nuf.  heck, they should be doing this for 4.6.x too
14:08:16 <ltinkl> true
14:08:24 <rdieter> but y'all know my thoughts on that already
14:08:25 <Kevin_Kofler> Well, what we're patching now is 4.6.3, F11 still has 4.6.2.
14:08:34 <ltinkl> they (Nokia) don't seem to care about security bugs in webkit
14:08:52 <jreznik> Kevin_Kofler: does not matter
14:08:54 <Kevin_Kofler> Stable F12 and F13 updates too.
14:08:54 <ltinkl> so what to do with F11?
14:08:59 <jreznik> should be same
14:09:03 <ltinkl> we need the fixes
14:09:11 <Kevin_Kofler> I'd say push the patched 4.6.3 build directly to stable ASAP.
14:09:15 <jreznik> 4.6.2 webkit is the same as 4.6.3
14:09:17 <rdieter> ok, we'll wait for the builds, and get stuff released when ready
14:09:22 <Kevin_Kofler> There's not much time until EOL and there's a metric crapton of CVEs.
14:09:25 <ltinkl> but I don't know how much those 2 webkits differ in 4.6.3 and 4.6.2
14:09:53 <ltinkl> than: I will take care of F11 once the current builds have finished
14:10:02 <rdieter> #info patched 4.6.3 builds are underway, work-in-progress, updates to be submitted when ready.
14:10:06 <than> ltinkl: great, thanks
14:10:25 <ltinkl> #info ltinkl to take care of backporting to F11 (different Qt)
14:10:52 <rdieter> ltinkl: oh, not sync to 4.6.3 ? (I suppose it makes some sense to backport here)
14:11:01 <jreznik> rdieter: +1
14:11:08 <Kevin_Kofler> I'm for syncing to 4.6.3.
14:11:13 <ltinkl> I dont know, that's why I asked
14:11:19 <rdieter> 4.6.3 has gotten 0 testing really
14:11:41 <jreznik> 4.6.2 in F11 with fixes
14:11:54 <rdieter> ltinkl: I'm ok with patchign 4.6.2, provided it's not an undue amount of extra work
14:11:55 <ltinkl> ye but it contains bugfixes, truth is that it also could contain regressions which are dangerous this close to EOL
14:12:00 <jreznik> it does not need backports as webkits are practically the same
14:12:09 <ltinkl> would be ideal then :)
14:12:11 <Kevin_Kofler> I think we should push bugfixes to F11.
14:12:16 <Kevin_Kofler> Which means 4.6.3.
14:12:24 <jreznik> Kevin_Kofler: but security only
14:12:36 <Kevin_Kofler> There's no such rule.
14:12:37 <jreznik> same situation as for 4.4
14:12:40 <rdieter> Kevin_Kofler: there's not enough time for testing 4.6.3
14:12:47 <Kevin_Kofler> Fedora doesn't have a security-only phase.
14:12:55 <Kevin_Kofler> It has a maintained phase and an EOL phase.
14:12:58 <jreznik> again kde 4.4.4 + qt 4.6.3 to kde-redhat
14:13:04 <Kevin_Kofler> It's either supported or not.
14:13:04 <thomasj> +1
14:13:07 <Kevin_Kofler> Right now it is.
14:13:08 <rdieter> jreznik: ok
14:13:12 <thomasj> +1 was to jreznik
14:13:26 <jreznik> Kevin_Kofler: but how do you want to fix bugs in last push?
14:13:39 <rdieter> #info kde-redhat can host unofficial qt-4.6.3 builds for f11
14:13:43 <jreznik> I'm +1 in case we can fix it after EOL
14:13:57 <Kevin_Kofler> Well, we can't.
14:14:11 <Kevin_Kofler> They're quite aggressive at shutting down infrastructure on EOL. :-/
14:14:15 <ltinkl> then pushing 4.6.3 to F11 is a no no
14:14:17 <jreznik> that's the only one problem...
14:14:40 <jreznik> I'd like to support F11, I'd like to push it there...
14:14:43 <Kevin_Kofler> Somehow they see post-EOL updates as a problem to be prevented at all costs. I really don't see the problem.
14:14:50 <Kevin_Kofler> But they own the infra.
14:14:55 <ltinkl> I agree
14:15:16 <ltinkl> but with the current state, the risk of breaking stuff post EOL is too high
14:16:38 <rdieter> ... let's move on...
14:16:49 <rdieter> #topic gstreamer-plugins-good-0.10.23-1 : phonon-backend-gstreamer jittery playback
14:16:51 <than> ltinkl: i'm against pushing 4.6.3 into F11
14:16:57 <ltinkl> than: yup
14:17:04 <rdieter> I finally got this bug filed
14:17:13 <rdieter> .bug 603496
14:17:14 <zodbot> rdieter: Bug 603496 gstreamer-plugins-good-0.10.23-1 : phonon-backend-gstreamer jittery playback - https://bugzilla.redhat.com/show_bug.cgi?id=603496
14:17:37 <rdieter> and maintainer found it was upstreamed already.  I'll be providing some info on the upstream bug after meeting
14:17:45 <rdieter> and help debug/diagnose.
14:17:50 <than> we  push 4.6.2 with only security fixes into F11
14:19:07 <ltinkl> rdieter: I confirm that bug
14:19:14 <jreznik> than: yes, we do
14:19:24 <ltinkl> strange thing is that it only happens here in the KDE sounds, but not in Amarok
14:20:00 <rdieter> I think it may be limited to certain media types, but that's just a hunch I came up while going to sleep last night
14:20:24 <rdieter> that's something I plan on rigorously testing after-meeting too
14:20:26 <ltinkl> rdieter: probably as the login sounds is OGG
14:20:56 <rdieter> right, I think it may be just oggs, but I'll test all I've got to make sure
14:21:24 <rdieter> ltinkl: when/if I find anything, I'll ping you to confirm.
14:21:29 <ltinkl> rdieter: ok
14:22:35 <ltinkl> anything else, move on?
14:22:36 <rdieter> #info rdieter will continue to debug/diagnose, provide information on upstream bug. ltinkl to help confirm findings
14:23:36 <rdieter> next topic...
14:23:51 <rdieter> #topic triaging/upstreaming high-profile bugs (nepomuk, kpackagekit, knetworkmanager)
14:24:57 <rdieter> I think it behooves us to have a plan to be a little more involved, if possible, in triaging/upstreaming some classes of our high-profile bugs being reported.
14:25:31 <rdieter> I mentioned here nepomuk, kpackagedkit primarily, but knetworkmanager is largely in the same class.
14:25:35 <Kevin_Kofler> 1. Who would do the work of forwarding the bugs?
14:25:52 <Kevin_Kofler> 2. Upstream doesn't want to speak to a forwarding drone, they want to talk to whoever is actually experiencing the bug.
14:26:18 <rdieter> Kevin_Kofler: in the case of nepomuk, reporters largely have no knowledge of what went wrong.
14:26:27 <Kevin_Kofler> Neither do we, though.
14:26:36 <ltinkl> :)
14:26:59 <rdieter> right, but, it still needs to get upstreamed, and in the nepomuk case, I think it should be a sig member
14:27:00 <Kevin_Kofler> It's the usual abrt problem.
14:27:24 <Kevin_Kofler> Hopefully the move of KCrash to kdecore will happen soon and Nepomuk will use it.
14:27:33 <Kevin_Kofler> But that will be for 4.6 at the earliest. :-(
14:27:34 <rdieter> Kevin_Kofler: problem = bugs getting reported locally and not upstream?  (if so, I agree)
14:27:40 <Kevin_Kofler> rdieter: Yes.
14:27:55 <Kevin_Kofler> ABRT is broken by design, and will stay so until it learns not to bother packagers with those crashes.
14:27:56 <SMParrish_mobile> If needed I can upstream the big ones, but I will not forward the large # of abrt bugs
14:28:02 <Kevin_Kofler> Those bugs must be filed upstream.
14:28:09 <rdieter> SMParrish_mobile: nod.
14:28:26 <ltinkl> SMParrish_mobile: would be nice
14:28:34 <rdieter> Is abrt finding dups very well yet?  If so, we can start with the crashers with the most dups
14:28:55 <Kevin_Kofler> No.
14:29:03 <rdieter> :(  crap
14:29:07 <SMParrish_mobile> From what I can see dupe checking is not working
14:29:15 <Kevin_Kofler> The duplicate detection has a lot of false negatives.
14:29:30 <Kevin_Kofler> Different version-releases are always considered different.
14:29:43 <Kevin_Kofler> And it often compares too much of the backtrace.
14:29:51 <rdieter> I guess my plan of upstreaming the top 5 (or so) of nepomuk crashers isn't practical
14:30:04 <Kevin_Kofler> It's based on a single hash which must match exactly, it doesn't compute any similarity scores.
14:30:27 <rdieter> ok, we've got 4.3.4 in the wild, and 4.4.4 on the way.
14:30:36 <thomasj> Means upstream will give us a "big hug" if we file/forward a ton of dupes? :)
14:30:42 <Kevin_Kofler> Of course, fetching all the backtraces and comparing to them all would take a very long time.
14:30:55 <Kevin_Kofler> Detecting duplicate backtraces is very hard.
14:31:34 <Kevin_Kofler> There are also many cases where only a human can decide whether the 2 backtraces are the same or not, and sometimes be wrong.
14:31:35 <rdieter> I know this may suck a bit, but for any nepomuk reports for < 4.3.3, how about ask to reproduce against updates ?
14:32:07 <Kevin_Kofler> rdieter: We wait for 4.3.4, then we ask to reproduce, and if no answer within 2 weeks, we close as INSUFFICIENT_DATA.
14:32:08 <rdieter> SMParrish_mobile: does that sound ok to you?
14:32:24 <rdieter> Kevin_Kofler: ok, I can agree to that variant as well.
14:32:31 <SMParrish_mobile> Works for me
14:32:37 <Kevin_Kofler> It's how I handle the Gnash ABRT reports, there's really no way I can do anything better.
14:32:45 <Kevin_Kofler> (Hooray for Bugzilla's mass change feature.)
14:32:51 <rdieter> SMParrish_mobile: do you want/need help?  (I know it's a lot of work here)
14:33:04 <thomasj> I might be able to help
14:33:05 <Kevin_Kofler> Sadly, some software crashes so often that it's impossible to deal with all the crash reports. :-(
14:33:17 <Kevin_Kofler> Both Gnash and Nepomuk are in that category.
14:33:17 <thomasj> Though i'm limited with my time until i moved finally
14:33:49 <SMParrish_mobile> I might   Will generate a list of bugs when I get home and see how many we have.
14:34:10 <rdieter> SMParrish_mobile: ok, let us know.
14:34:23 <SMParrish_mobile> Last I checked was over 100 abrt bugs. But not all are against nepomuk
14:34:50 <rdieter> #info SMParrish_mobile to count up outstanding nepomuk abrt bugs, and request assistance for triaging as needed
14:35:14 <thomasj> SMParrish_mobile, if you need help, feel free to ping me
14:35:38 <SMParrish_mobile> thomasj: Thanks
14:35:42 <thomasj> Triager tools are ready..
14:35:44 <thomasj> np
14:35:44 <rdieter> #info thomasj volunteers triaging help
14:36:05 <rdieter> ok, next troublemaker:   kpackagekit
14:36:39 <rdieter> seems to be, there are lots of broken or missing features in need of upstreaming here too.
14:37:47 <rdieter> wrt knetworkmanager issues, I'll offer to work on that (though any help would be appreciated too).
14:37:48 <Kevin_Kofler> Unfortunately, Kubuntu is considering switching to some apt-based solution (Aptitude-qt or something new entirely), so even that source of upstream development might dry up soon. :-(
14:37:54 * thomasj can help with all troublemakers. Just give him a list and what to do. He will spend about 2 hours/day
14:38:04 <Kevin_Kofler> (re KPackageKit)
14:38:16 <rdieter> thomasj: thanks, I was thinking you may have better immediate impact working on kpk ones
14:38:33 <rdieter> Kevin_Kofler: :(  we'll have to wait-n-see I guess
14:39:15 <Kevin_Kofler> Right now some KPK development is being done for Maverick.
14:39:22 <rdieter> I'd like to see the warts in 0.6.0 get fixed first, but meh
14:40:14 <rdieter> oh, shocker, the auto-install-codecs thing actually worked with phonon-gstreamer + kpk today.  pleasantly surprised.
14:40:58 <thomasj> I hope we will be able to keep the network-managementplasmoid, i prefer this piece much. Of course it needs still some love. But upstream is very active.
14:41:24 <rdieter> thomasj: absolutely, it's very nice indeed.
14:41:35 <Kevin_Kofler> I think the plasmoid is indeed the way to go for F14+.
14:41:42 <rdieter> Kevin_Kofler: yup, +1
14:42:01 <Kevin_Kofler> The monolithic KNM is considered legacy again these days.
14:42:24 <Kevin_Kofler> And you know how I feel about shipping the GNOME nm-applet (please not again!).
14:42:25 <rdieter> sadly the plasmoid stabilized a bit late for us to consider for f13
14:42:33 <thomasj> Kevin_Kofler, :D
14:42:33 <Kevin_Kofler> Right.
14:43:02 <thomasj> No problem. It's fine to have it for F-14
14:43:46 <rdieter> the biggest pieces lacking in knm (monolithic or plasmoid) is:
14:43:53 <rdieter> 1. (good) vpn support
14:44:08 <rdieter> 2.  modemmanager support (work underway)
14:44:35 <ltinkl> VPN management is crucial (for us in Redhat)
14:44:57 <rdieter> if 1 or both of these aren't solid for f14 release, I think we may have to ship nm-applet on the spin too (to have something to fallback to)
14:45:12 <rdieter> too bad I (or we) didn't think of that for f13 too
14:45:25 <rdieter> ltinkl: understood
14:45:28 <jreznik> rdieter: yep
14:46:16 <rdieter> may have to consider a similar plan for kpk/gnome-packagekit if kpk features don't solidify...
14:46:27 <thomasj> To have a fallback is good, even it means to have nm-applet.
14:46:30 <rdieter> but that one is far less critical
14:46:58 <rdieter> #topic open discussion
14:47:07 <rdieter> that's all I've got, anything else for today?
14:47:07 <Kevin_Kofler> Shipping 2 NM applets is not that great an idea, it means you need to disable one by default and so it's not obvious to a new user how to enable it.
14:47:48 <rdieter> Kevin_Kofler: only one is enabled by default already, and we already have documentation on how to enable it.  I don't see either as a big issue to worry about
14:48:36 <Kevin_Kofler> We also have chronical space issues.
14:48:50 <Kevin_Kofler> So shipping stuff which is not enabled doesn't sound like that great an idea to me.
14:48:53 <thomasj> We could get fallback information into Fedora-Tour, once it's ready. That way it's easy to find for the end-user even without a internet connection.
14:49:19 <Kevin_Kofler> Will we even ship Fedora-Tour on the KDE spin in the first place?
14:49:20 <rdieter> that's a concern true, we'll have to weight the issues
14:49:31 <thomasj> Kevin_Kofler, we should
14:49:33 <rdieter> and decide carefully
14:49:33 <Kevin_Kofler> Without KDE-targeted content, it's just a big waste of space.
14:50:06 <thomasj> It will be de-independent, but we can add DE specific stuff as well.
14:50:19 <Kevin_Kofler> It's PyGTK-based.
14:50:32 <Kevin_Kofler> And who will write the KDE content?
14:50:45 <thomasj> Well, we :p
14:50:57 <thomasj> Whoever is "we" in the end.
14:52:14 * jreznik prefers open source KDE based apps but if there are no working ones, I can use proprietary Gtk one too... I hope it's only 1%
14:52:53 <thomasj> Lets think positive, the plasmoid will be ready :)
14:53:01 <Kevin_Kofler> In this case it's not a proprietary app. :-)
14:53:04 <rdieter> whatever happened to rrix's work on fedora-tour using (py?)qt?
14:53:10 <rdieter> or was that something else?
14:53:24 <thomasj> rrix doesn't do much, but others are active.
14:53:31 <Kevin_Kofler> rrix did most of the coding work, but they made him use PyGTK and he did it to make his ambassadors friends happy.
14:53:43 <Kevin_Kofler> These days the coding work may be done by other folks though.
14:53:52 <Kevin_Kofler> (which probably means even more GTK+ bias)
14:54:00 <rdieter> ok.
14:54:10 <thomasj> It's done by some indians, hanging out in #fedora-tour
14:54:18 <thomasj> Kevin_Kofler, no, it's not gtk+ based.
14:54:23 <rdieter> thomasj: thanks
14:54:30 <jreznik> I suppose it's just showing the webpage, isn't it?
14:54:50 <Kevin_Kofler> thomasj: On what is it based then?
14:55:03 * thomasj needs to check
14:55:10 <Kevin_Kofler> Last I heard from rrix was that it was being implemented in PyGTK (and he hated it).
14:55:13 <thomasj> clutter?
14:55:17 <Kevin_Kofler> That's GTK+.
14:55:20 <thomasj> damn
14:55:24 <thomasj> Sorry
14:55:46 <Kevin_Kofler> It's more or less the GTK+ equivalent of QGraphicsView.
14:55:53 <thomasj> Ok, so it's clutter/gtk+
14:56:04 <Kevin_Kofler> But with the added "bonus" that it requires hardware OpenGL to work at all.
14:56:25 <Kevin_Kofler> It doesn't even work with Mesa software rendering and nobody cares enough to fix either Mesa or Clutter.
14:56:42 <thomasj> eeewww
14:57:15 <thomasj> Ok, i will test the latest checkout. Thank god we have some time until F-14
14:57:34 <Kevin_Kofler> I think it's pretty much a GNOME-spin-only feature at this point.
14:57:55 <Kevin_Kofler> I'm also not aware of anyone writing any KDE content for it.
14:58:13 <Kevin_Kofler> And clutter and pyclutter is an additional GNOME dependency we don't have on the spin and don't want dragged in.
14:58:22 <jreznik> Kevin_Kofler: we can make it better (but I don't consider is as top priority project)
14:58:33 <thomasj> Nope. We, the SIG need to write the DE specific content.
14:59:43 <rdieter> looks like we're out of time
14:59:56 <rdieter> thanks everyone, wrapup
15:00:03 <rdieter> #endmeeting