15:03:56 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-04-12
15:03:56 <zodbot> Meeting started Tue Apr 12 15:03:56 2011 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:04:01 <rdieter> #meetingname kde-sig
15:04:01 <zodbot> The meeting name has been set to 'kde-sig'
15:04:07 <rdieter> #topic roll call
15:04:17 <rdieter> who's around today?
15:04:20 * jreznik is here
15:04:38 * rnovacek is here
15:04:56 * than is here
15:04:57 * brutal_chaos is here
15:05:11 <Kevin_Kofler> Present.
15:05:36 * ltinkl is here
15:05:50 <rdieter> #chair jreznik  rnovacek  than  Kevin_Kofler  ltinkl
15:05:50 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter rnovacek than
15:06:04 <rdieter> #info rdieter jreznik  rnovacek  than  Kevin_Kofler ltinkl brutal_chaos  present
15:06:10 <rdieter> #topic kde-4.6.2
15:06:19 <rdieter> onto our short agenda, kde-4.6.2 topic
15:06:44 <Kevin_Kofler> What's the status there?
15:06:53 <rdieter> finished up those builds over the past couple of days
15:07:01 <rdieter> it's all in kde-testing now, and queue'd for updates-testing
15:07:07 <Kevin_Kofler> This is a bugfix release, and most importantly it fixes kdelibs CVE-2011-1168.
15:07:29 <rdieter> an additional fyi, the f14 batch of updates includes an abi-bumped exiv2 too
15:07:40 <Kevin_Kofler> I think we also have a KGet security issue to address though, I think that patch just missed 4.6.2.
15:07:52 <rdieter> Kevin_Kofler: ah, I probably ought to add some bug references for those
15:08:07 <jreznik> #info 4.6.2 builds are ready, available in kde-testing, pushed to updates-testing
15:08:20 <rdieter> jreznik: queue'd , not pushed yet, to be clear
15:08:39 <jreznik> rdieter: ah, sorry, I saw it queued
15:08:47 <jreznik> #info 4.6.2 builds are ready, available in kde-testing, queued to updates-testing
15:09:07 <rdieter> better :)
15:09:31 <jreznik> #info bugfix release, fixes kdelibs CVE-2011-1168
15:09:47 <rdieter> .bug 695398
15:09:48 <zodbot> rdieter: Bug 695398 CVE-2011-1168 kdelibs: partially universal XSS in Konqueror error pages - https://bugzilla.redhat.com/show_bug.cgi?id=695398
15:10:06 <rdieter> should I mark that one fixed, or make a separate bug per fedora release blocking that one?
15:10:29 <Kevin_Kofler> No idea.
15:10:33 * rdieter is spoiled, the security team usually (seems?) to do that latter part for us usually
15:10:34 <Kevin_Kofler> You should also mark the update as security.
15:11:06 <jreznik> should I poke security guys?
15:11:28 <rdieter> jreznik: please do, at least if you can get a quick/easy answer
15:12:35 <rdieter> anyone mind double-checking if we need to patch kget or not?
15:12:48 * rdieter is likely to be a bit swamped today
15:12:53 <than> rdieter: we need it for 4.6.2
15:13:06 <than> i'm working on it
15:14:02 <rdieter> #action than to work on patched kdenetwork(kget)
15:14:17 <than> i think it's enough if we just add info in #695398 so that security team is aware of it
15:14:35 <than> they will close the bug when it's released
15:14:40 <rdieter> than: I agree, a good plan until we hear otherwise
15:15:14 <rdieter> I'll do so, once it update is pushed, and an update ID is assigned
15:16:13 <rdieter> anything else wrt kde462?
15:16:30 * jreznik poked sec response guys, waiting for response
15:16:49 <brutal_chaos> How about
15:16:56 <brutal_chaos> .bug 623996
15:16:58 <zodbot> brutal_chaos: Bug 623996 Granular splitting of kde-multimedia - https://bugzilla.redhat.com/show_bug.cgi?id=623996
15:17:19 <rdieter> that's obviously still a todo item, no one's yet gotten around to it
15:17:26 <than> jreznik: thoger is the securiry guy for kde
15:17:55 <brutal_chaos> I am willing to work on that.
15:18:00 * Kevin_Kofler thinks doing the kdemultimedia split is a bad idea.
15:18:18 <jreznik> than:  I see, he responded but I don't understand his response :)
15:19:23 <jreznik> he says - only one bug if all released versions are affected
15:19:48 <jreznik> but we have f13 already pushed and f14/f15 in 4.6.2 update
15:21:00 <Kevin_Kofler> So, thoughts about the splitting stuff?
15:21:22 <Kevin_Kofler> I've always been opposed to splitting, and I still doubt the benefits are worth the effort.
15:21:56 <brutal_chaos> I see four different packages rolled into one, a split seems reasonable.
15:22:23 <than> jreznik: it's correct
15:22:26 <Kevin_Kofler> FWIW, kdemultimedia and kdemultimedia-libs together are only < 6 MiB uncompressed.
15:22:33 <ltinkl> brutal_chaos: the whole effort is not only about doing the split but also maintaining that
15:22:39 <than> there's is only one bug for fedora
15:22:54 <than> i will take care of it
15:23:02 <ltinkl> brutal_chaos: we just don't have the manpower to maintain hundreds of packages
15:23:29 <jreznik> it makes sense to have basic functionality out of big bundled packages
15:23:42 <brutal_chaos> I am working towards becoming a package maintainer and adding 3 more packages doesn't seem like hundreds imo.
15:23:47 <jreznik> or something we really don't want to ship like JuK
15:24:08 <rdieter> brutal_chaos: it's baby-steps, adding 3 here, 2-3 there, it all adds up... quicly.
15:24:19 <ltinkl> brutal_chaos: I see your point, but we are getting such requests quite often for every base package we have out there
15:24:20 <rdieter> jreznik: that I can agree with
15:25:10 <jreznik> than, rdieter: thoger says that even 4.6.2 update should be marked as security then
15:25:13 <rdieter> *If* we had more folks willing to help with continued maintenance of these split packages, maybe... :)
15:25:32 <brutal_chaos> That's why I am here. :)
15:25:51 <rdieter> brutal_chaos: are you a fedora contributor/packager currently?
15:26:09 <brutal_chaos> I am in the process of being mentored by mether.
15:26:36 <rdieter> brutal_chaos: ok, let's discuss it more after meeting (say in #fedora-kde or whatever)
15:26:55 <brutal_chaos> Alright
15:26:58 <than> jreznik: yes, we have to mark it as security
15:27:59 <rdieter> but, when it comes to core kde packages, we generally set a higher bar to grant commit acls.  you must first demonstrate some experience and aptitude, and willingness to make a semi-long-term commitment
15:28:37 <rdieter> alrightly , I think we've talked kde462 to death.
15:28:49 <rdieter> arg
15:28:54 <rdieter> #topic open discussion
15:29:06 <rdieter> anything else for today?
15:29:11 <Kevin_Kofler> So I had a look at the Phonon DVD menu stuff (for Dragon Player).
15:29:29 <Kevin_Kofler> As I see it, the current status is that Phonon and Phonon-GStreamer now support the required interfaces (in 4.5.0).
15:29:34 <rdieter> yay
15:29:38 <Kevin_Kofler> But Dragon Player hasn't been ported to use them yet. :-(
15:29:43 <rdieter> right.
15:29:48 <Kevin_Kofler> At least not in kdemultimedia trunk.
15:30:06 <rdieter> that's the last item preventing us from dropping xine-lib from our default install
15:30:16 <Kevin_Kofler> Also, Phonon-Xine hasn't been updated to support the interface. (I haven't checked Phonon-VLC, I don't care all that much about that one as long as we can't ship it in Fedora.)
15:30:42 <rdieter> phonon-xine likely won't get love any time soon, from what I can gather
15:31:09 <Kevin_Kofler> I don't know whether we care about Phonon-Xine for F15, but for F14, we'll need it updated to support this interface if we want to ship the Dragon Player patch.
15:31:48 <Kevin_Kofler> Maybe I'm going to have a try at implementing the interface for Phonon-Xine. The required patch for Phonon-GStreamer was quite small.
15:31:54 <rdieter> meh, I wouldn't necessarily consider it a blocker.  our default is gstreamer, even if we did ship both
15:32:02 <Kevin_Kofler> It's just a matter of figuring out the correct xine-lib APIs to use.
15:32:10 <rdieter> but if it can be done, yay
15:32:44 <Kevin_Kofler> I'd say Phonon-Xine support for this API is not a blocker for F15, but it is for shipping the Dragon Player patch in F14 updates.
15:32:53 <ltinkl> Kevin_Kofler: so what about porting Dragon Player instead, that would seem more logical
15:32:53 <Kevin_Kofler> We don't want to regress existing functionality.
15:33:30 <Kevin_Kofler> ltinkl: We need all 4 of Phonon, Phonon-GStreamer, Phonon-Xine and Dragon Player updated for the new API.
15:33:34 <Kevin_Kofler> The first 2 are done.
15:33:53 <Kevin_Kofler> The third, I guess will be up to us, there's no active upstream maintainer for Phonon-Xine.
15:34:16 <Kevin_Kofler> And the last one is what's really needed for the feature.
15:37:18 <Kevin_Kofler> Another thing I wonder is: Is anybody ACTIVELY working on porting kde-plasma-networkmanagement to the NM 0.9 API?
15:37:28 <Kevin_Kofler> The current hack will NOT be supported by NM in the long run.
15:37:42 <Kevin_Kofler> (In fact, the compat patches aren't even applied in current F16 Rawhide.)
15:37:49 <rdieter> Kevin_Kofler: you willing to do some upstream poking to see if dragon will see some patches soon?
15:38:09 <ltinkl> Kevin_Kofler: yes, I'm working on something for F16
15:38:10 <Kevin_Kofler> I looked at the nm-0.9 branch there and it doesn't really have any activity other than merges from master.
15:38:11 <rdieter> wrt nm, I thought jklimes and at least one other upstreamer were working on nm-0.9 branch
15:39:07 <ltinkl> unfortunately, I still haven't seen anything from Bille wrt libnm-qt
15:39:08 <rdieter> ltinkl: your work on plasma-nm or that alternative you showed before?
15:39:13 <ltinkl> rdieter: yup
15:39:17 <Kevin_Kofler> Re Dragon, I guess I'm going to nag the people involved a bit. :-)
15:39:46 <ltinkl> I'm pretty sure I will have something working in a few weeks
15:40:08 <ltinkl> which will be better maintainable for the long term
15:40:09 <Kevin_Kofler> "<rdieter> wrt nm, I thought jklimes and at least one other upstreamer were working on nm-0.9 branch" → I thought so too, but I don't see them actually pushing any commits.
15:40:29 <ltinkl> Kevin_Kofler: the truth is, the current code is one pile of junk
15:40:55 <ltinkl> 90% of the knm code is not reusable/maintainable and cannot rly use the new functionality in NM 0.9
15:41:23 <Kevin_Kofler> Uh, are you sure?
15:41:31 <Kevin_Kofler> They got system connections working already.
15:41:51 <ltinkl> can't blame Bille much, it's just a result of continuous "porting", from NM 0.6 -> 0.7 etc
15:41:57 <Kevin_Kofler> (The (un)funny thing is that those will NOT work in F15 because the compat patches don't support it. :-( )
15:42:09 <ltinkl> Kevin_Kofler: yup, much more than that
15:42:37 <ltinkl> BT devices don't work, Modem devices are completely different now, the storage and secrets have changed as well
15:42:58 <ltinkl> you'd have to literally rewrite most of the code anyway
15:43:09 <Kevin_Kofler> A big problem is that the solidcontrol "abstraction" layer is a joke.
15:43:19 <ltinkl> not talking about the new stuff like wimax or OLPC mesh
15:43:34 <ltinkl> yup, the abstraction mess is the real problem there
15:43:38 <Kevin_Kofler> It only "abstracted" the differences between NM 0.6 and 0.7/0.8, which mostly meant supporting only the ancient 0.6 way of doing things.
15:43:43 <ltinkl> yes
15:43:47 <Kevin_Kofler> (which is how we ended up with only user connection support)
15:44:15 <ltinkl> so the current state is that you can't move forward w/o throwing away 90% of the backend code
15:44:21 <ltinkl> and rewriting the rest
15:44:26 <Kevin_Kofler> They should have done a different backend (e.g. wicd) right from the start, it might have lead to a much better abstraction layer, one that actually works as an abstraction.
15:44:55 <ltinkl> sadly this never materialized
15:44:59 <Kevin_Kofler> Right now the code just has to work around the abstractions and the frontend requires NM directly anyway, so the "abstraction" is useless.
15:45:48 <ltinkl> and some of the backend code isn't needed at all because it's been used only in the monolithic app, which is now deprecated as well
15:46:00 <ltinkl> (altho it still sits in the repo)
15:46:04 <Kevin_Kofler> One impression I also get is that while Solid abstractions worked well on the client application side, solidcontrol just doesn't work.
15:46:28 <Kevin_Kofler> There isn't a single solidcontrol abstraction that worked out well, and now the goal is to get rid of it entirely.
15:46:33 <ltinkl> yup, removing Solid::Control was one of the 4.6 goals as well, never happened either
15:46:44 <rdieter> so, long-term, how worried should we be about getting this into any usable form for f16?
15:46:45 <Kevin_Kofler> Power management is abstractable to some extent, but the abstraction is done within PowerDevil now.
15:47:00 <ltinkl> yup, we did that for 4.6
15:47:14 <Kevin_Kofler> Bluetooth just hardcodes BlueZ now (in BlueDevil), and for networking, we're getting NM hardcoded soon.
15:48:09 <Kevin_Kofler> Management has different (more complex) requirements than client apps, which makes abstracting things properly much harder.
15:48:35 <rdieter> doesn't help when the things you're abstracting continually change too
15:48:54 <ltinkl> http://ktown.kde.org/~lukas/pics/knm9-5.png
15:49:06 <ltinkl> that's the current state of what I'm working on
15:49:11 <ltinkl> basic stuff already works
15:49:19 <rdieter> rock
15:49:35 <Kevin_Kofler> rdieter: Well, if the abstraction worked well, the thing you're abstracting changing shouldn't be a problem at all! ;-)
15:49:55 <Kevin_Kofler> See e.g. Solid-u* instead of Solid-HAL on the client app end.
15:50:01 <ltinkl> by basic stuff I mean wired+wifi
15:50:50 <ltinkl> the good thing about NM 0.9 is the simplified API which makes writing client apps easy
15:50:51 <ltinkl> and
15:51:03 <Kevin_Kofler> ltinkl: Can you talk to the upstream kde-networkmanagement mailing list about this?
15:51:19 <rdieter> nod, don't hide the goodness!
15:51:28 <Kevin_Kofler> Next point: That's a dialog, shouldn't it be a plasmoid? :-)
15:51:40 <ltinkl> NM also does a lot of the stuff automatically so almost no user intervention is required
15:52:08 <Kevin_Kofler> And third point: Assuming upstream likes it (I don't think we should do a Fedora-only thing unless there's no other alternative), when can we expect that stuff in Rawhide?
15:52:11 <ltinkl> Kevin_Kofler: that's one of the things i'm not convinced of
15:52:14 <jreznik> Kevin_Kofler: it's just testing app to play with NM
15:52:40 <Kevin_Kofler> ltinkl: We need either a status notifier icon or a plasmoid.
15:52:44 <ltinkl> jreznik: oh no, not testing :) although it serves that goal as well
15:52:48 <Kevin_Kofler> Something to put into the systray with a popup.
15:52:57 <ltinkl> Kevin_Kofler: it has a systray icon
15:53:08 <Kevin_Kofler> The trend is for plasmoids.
15:53:17 <ltinkl> I'm not convinced Plasma applet is the right way to do this, for several reasons
15:53:17 <jreznik> ltinkl: systray icon does not fit very well to current Plasma
15:53:35 <Kevin_Kofler> Especially now with 0.9, we don't even need the kded4 service anymore.
15:53:45 <Kevin_Kofler> NM 0.9 already does all the things the kded4 service was for.
15:53:59 * rdieter doesn't care if it's a plasmoid or classic/systray , as long as it works
15:53:59 <Kevin_Kofler> (Multiple clients, no disconnection when the client crashes etc.)
15:54:28 <ltinkl> no one really knows the future of Plasma; applet, QML, scene graph?
15:55:00 <ltinkl> the "plain app" approach also makes this usable outside of KDE
15:55:43 <Kevin_Kofler> If you want to go with the systray approach, there should be a popup like in KMix, I don't think bring up a dialog if you want to see details is that great an idea.
15:56:14 <ltinkl> but my plan is to separate it into a general backend with the possibility to write some other frontend on top of it, if someone feels like it
15:56:30 <Kevin_Kofler> The thing is, plasmoids will be Plasma-themed, systray icons will be Qt-themed. Now which is better is something people keep fighting over. (IMHO it sucks that those have different looks in the first place.)
15:57:16 <Kevin_Kofler> (The systray icons themselves will be Plasma-themes, but the popups not. Unless they're plain old menus with DBusMenu. But we're talking about something like the kde-plasma-nm's popup applet now.)
15:57:17 <jreznik> ltinkl: the future is Plasma in QML, you don't have to care about scene graph, libplasma/libplasma2
15:57:45 <Kevin_Kofler> Hmmm, do we really need a backend/frontend separation?
15:57:52 <jreznik> Kevin_Kofler: same reason why Gnome folks wanted a new NM so much
15:57:55 <Kevin_Kofler> As I said, NM 0.9 should make the kded4 service redundant.
15:58:18 <Kevin_Kofler> I don't think we want a new abstraction layer which will become a problem again.
15:58:22 <ltinkl> jreznik: exactly, I can already see knm authors rewrite the applet to QML as soon as they've possibly finished with the backend rewrite ;)
15:58:56 <Kevin_Kofler> FWIW, I also think that you won't get many people upstream favoring a systray approach.
15:58:57 <jreznik> ltinkl: you don't have to rewrite it, it's for new plasmoids
15:59:00 <ltinkl> Kevin_Kofler: there's no kded service, just a "wrapper" around the NM DBUS API
15:59:04 <Kevin_Kofler> They want even KMix and Klipper ported to plasmoids.
15:59:09 <jreznik> but ok, stop here :) let's move to #fedora-kde
15:59:23 <Kevin_Kofler> And having upstream buyin is essential IMHO.
15:59:36 <Kevin_Kofler> We should really work with upstream, not ship something Fedora-only.
15:59:42 <jreznik> Kevin_Kofler: +1
16:00:04 <jreznik> and use the advantage of being upstream in upstream
16:00:16 <zodbot> Announcement from my owner (jsmith): Fedora Board Public IRC meeting in #fedora-board-meeting
16:00:27 <jreznik> ok, it's time :)
16:00:36 <jreznik> #endmeeting