14:03:57 <rdieter> #startmeeting KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-22
14:03:57 <zodbot> Meeting started Tue Sep 22 14:03:57 2009 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:04:12 <rdieter> #topic roll call
14:04:18 <rdieter> who's present today?
14:04:21 * ltinkl is here
14:04:29 <Kevin_Kofler> Present.
14:04:35 * svahl is here
14:04:36 * thomasj here
14:04:44 * SMParrish here
14:04:58 * jreznik is here
14:05:19 <rdieter> #topic agenda, https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-22#Agenda
14:05:28 <rdieter> look over the agenda, anything else we should discuss today ?
14:05:30 * than is here
14:07:10 <Kevin_Kofler> I guess we don't have anything to add to the agenda. ;-)
14:07:17 <rdieter> well, let's get started then.
14:07:36 <rdieter> #topic  qt4/kde4 based alternative for pinentry-qt?
14:07:50 <rdieter> and, currently pinentry-qt4 seems broken (https://bugzilla.redhat.com/show_bug.cgi?id=523488)
14:07:51 <buggbot> Bug 523488: medium, low, ---, rdieter, ASSIGNED, pinentry-qt4 broken
14:08:03 <Kevin_Kofler> IMHO we really need a fix there.
14:08:13 <Kevin_Kofler> It's pretty annoying to have qt3 just for pinentry-qt.
14:08:22 <Kevin_Kofler> Or does anything else on the live CD require it?
14:08:23 <rdieter> the current scoop is that well, it's broken, and the latest builds in rawhide re-enable the qt3-based pinentry
14:08:39 <svahl> atm it would fit onto the live images
14:08:41 <rdieter> well, we could use pinentry-gtk for the livecd too, to avoid qt3 ironically
14:08:43 <svahl> it's the only one
14:08:49 <svahl> :)
14:09:16 <rdieter> which is what I'd recommend honestly, at least until -qt4 issue is sorted out
14:09:33 <Kevin_Kofler> Latest from upstream in the ML thread is that it's supposed to work.
14:09:33 <rdieter> but I don't have any strong feelings on that
14:09:34 <jreznik> is anybody working on qt4 version?
14:09:55 <rdieter> I'm slowly working on debuging it with upstream, but it's a slow process
14:10:30 <rdieter> fwiw, this also affects the latest pinentry for F-11
14:10:51 <rdieter> which includes pinentry-qt4 too
14:12:08 <Kevin_Kofler> As -qt4 or as -qt?
14:12:49 <rdieter> well, both.  includes -qt4  with -qt symlink pointing to -qt4
14:13:11 <Kevin_Kofler> So it should be reverted to the Qt 3 one too?
14:13:42 <rdieter> probably
14:14:07 <than> rdieter,  we should use -qt3 by default before we have a fix for  523488
14:14:12 <rdieter> odd, is that it's either working for everyone else, or it's broken and noone is reporting it
14:14:56 <than> in which package is pinentry-qt4 included?
14:15:12 <rdieter> pkgname in F-11 is pinentry-qt
14:15:14 <Kevin_Kofler> That or nobody else is using GPG or not with a passphrase. ;-)
14:15:30 <rdieter> in rawhide, I'm shipping 3 subpkgs, pinentry-gtk, pinentry-qt, pinentry-qt4
14:15:46 <rdieter> I'll likely do the same for F-11 too
14:15:54 <Kevin_Kofler> rdieter: I think you should do that on F11 to unless you can come up with a fix for the bug really quickly.
14:16:00 <rdieter> and use the opensuse wrapper now too, instead of alternatives
14:16:01 <Kevin_Kofler> s/to/too/
14:16:10 <rdieter> ok, will do
14:16:18 <rdieter> anything else on this topic ?
14:16:51 <Kevin_Kofler> For the F12 live image, do we use the Qt 3 one or the GTK+ one?
14:17:14 <rdieter> +0.1 for gtk (saves the most space)
14:17:40 <than> probably -gtk+, we will save spaces
14:17:54 <Kevin_Kofler> On the other hand, qt3 is a bit more integrated, especially if the user also uses other kdelibs3 and/or qt3 apps.
14:18:06 <Kevin_Kofler> (though there are none left on the live image)
14:18:31 <than> do we have qt3/kdelibs3 in live image?
14:18:43 <svahl> only qt3 (due to pinentry-qt now)
14:18:54 <mathstuf> there's a qt4 pinentry now
14:19:00 <Kevin_Kofler> mathstuf: It's not working.
14:19:03 <mathstuf> at least that's what's popping up for kdepim
14:19:13 <Kevin_Kofler> Is it working for you?
14:19:13 <rdieter> mathstuf: it works for you?
14:19:15 <rdieter> :)
14:19:16 <mathstuf> yeah
14:19:26 <Kevin_Kofler> It's not working for rdieter: https://bugzilla.redhat.com/show_bug.cgi?id=523488
14:19:27 <buggbot> Bug 523488: medium, low, ---, rdieter, ASSIGNED, pinentry-qt4 broken
14:19:34 <rdieter> #$!$#$, please comment in the aforementioned bug then.
14:19:50 <rdieter> and let's talk after meeting so I can get a clue how to get it to work
14:20:03 <rdieter> if it's just me, I'd be happier
14:20:13 <svahl> would a "-pinentry-qt/+pinentry-gtk" be enough on the live images?
14:20:21 <rdieter> svahl: yes
14:20:26 <Kevin_Kofler> If we can get the Qt 4 one fixed, we should just ship that.
14:20:39 <jreznik> yes
14:20:41 <than> Kevin_Kofler, +1
14:20:43 <rdieter> svahl: go with pinentry-gtk for now, until we can confirm -qt4 works
14:20:48 <Kevin_Kofler> (or if the bug turns out to be due to rdieter's local configuration)
14:20:50 <svahl> ok
14:21:16 <rdieter> can we move on then ?
14:21:26 <Kevin_Kofler> move on++
14:21:28 <svahl> yes, please move on
14:21:34 <rdieter> #topic package list for KDE live images
14:21:49 <rdieter> svahl: I assume this one is for you too. ;)
14:22:12 <mathstuf> http://benboeckel.net/pinentry.png
14:22:39 <svahl> Please have a look at the current package list: http://fedoraproject.org/wiki/SebastianVahl/CurrentPackageList#preview
14:22:48 <Kevin_Kofler> Anything to discuss about the package list?
14:22:54 <svahl> without qt3 there is a few free space to include some more.
14:22:57 <rdieter> mathstuf: purty
14:23:05 <svahl> or maybe I'm missing some important package
14:23:28 <mathstuf> since we done have l10n stugg
14:23:32 <mathstuf> *stuff
14:23:38 <svahl> in my local builds I've added pavucontrol (for better pulseaudio management)
14:23:39 <Kevin_Kofler> Digikam?
14:23:40 <mathstuf> should we get rid of some fonts?
14:24:00 <svahl> mathstuf: only @fonts is included
14:24:05 <mathstuf> ok
14:24:20 <Kevin_Kofler> And the Fonts SIG thinks those are the bare minimum for basic i18n support.
14:24:36 <Kevin_Kofler> We could of course say we don't care about i18n and remove stuff arbitrarily. ;-)
14:24:41 <mathstuf> i usually strip out anythiong that isn't: dejavu, ghostscript, TeX
14:25:04 <rdieter> pavucontrol is good, our spin is admittedly English-only, but support for displaying other stuff is a very nice thing to have
14:25:18 <mathstuf> control-center-filesystem?
14:25:19 <rdieter> svahl: how much free space ?
14:25:26 <Kevin_Kofler> One app I always postinstall is krusader.
14:25:38 <Kevin_Kofler> mathstuf: -filesystem packages take few to no space.
14:25:38 <rdieter> duh, I see now
14:25:41 <mathstuf> k
14:25:45 <Kevin_Kofler> Don't worry about those.
14:25:48 <svahl> rdieter: 3-5 megs of iso space (squashfs compressed)
14:25:51 <mathstuf> glx-utils?
14:26:16 <rdieter> ok, we're pretty tight already, can only consider adding something relatively small then
14:26:26 <mathstuf> k3b is on there?
14:26:33 <Kevin_Kofler> No qt3 will save some space.
14:26:41 <mathstuf> kde4 k3b has crashes when ripping
14:26:44 <svahl> mathstuf: yes it is
14:26:58 <mathstuf> though i haven't had a chance to try it lately
14:27:13 <svahl> I'll add digikam to my list (but it duplicates some functionality with gwenview)
14:27:16 <rdieter> mathstuf: I recall you filing a bug upstream ,right?  I'll have to work to verify that myself too
14:27:25 <Kevin_Kofler> svahl: And Krusader? ;-)
14:27:32 <Kevin_Kofler> Am I the only one who uses that? ;-)
14:27:38 <ltinkl> Kevin_Kofler: yes :p
14:27:51 <svahl> I use it too sometimes. :) but two filemanagers?
14:27:52 <jreznik> svahl: +1 for pavucontrol
14:28:39 <Kevin_Kofler> Move on?
14:28:45 <rdieter> ok...
14:28:46 <svahl> ok
14:28:58 <svahl> +pavucontrol and +digikam then
14:29:12 <rdieter> #topic future of Phonon
14:29:12 <mathstuf> rdieter: yep
14:29:13 <Kevin_Kofler> (if there's room :-) )
14:29:19 <Kevin_Kofler> (to svahl)
14:29:22 <svahl> Kevin_Kofler: sure :)
14:29:39 <svahl> digikam should be ~2-3 megs afair
14:29:49 <Kevin_Kofler> rdieter: Oh, the elephant in the room? ;-)
14:29:52 <rdieter> sandsmark recommends... building/packaging phonon from qt, and building/packaging backends separately
14:30:04 <rdieter> not quite the answer I expected, but there it is...
14:30:16 <Kevin_Kofler> That's quite weird.
14:30:21 <Kevin_Kofler> Won't those get out of sync?
14:30:27 <rdieter> and re-emphasized recommendation to default to xine backend
14:30:45 <Kevin_Kofler> And it won't help if Qt doesn't update their copy of Phonon.
14:30:49 <rdieter> Kevin_Kofler: the core/stable phonon changes very little (he said)
14:31:10 <rdieter> 95%+ of the work goes into backends...
14:31:21 <Kevin_Kofler> But some of that stuff needs new APIs in the core, doesn't it?
14:31:47 <rdieter> apparently not (?)
14:32:50 <rdieter> we could review our own phonon mods/patches, but I don't think any of that touches core phonon either (just backends)
14:33:30 <Kevin_Kofler> At least one of my PA patches touches the core Phonon.
14:33:41 <Kevin_Kofler> It's now applied to the Qt package.
14:33:49 <mathstuf> well, i need to get ready for class
14:34:08 <rdieter> oh ok.
14:34:23 <rdieter> mathstuf: thanks, enjoy class.
14:35:11 <Kevin_Kofler> (It's required for the Xine backend to get its PA device have higher priority than the ALSA devices from the KDE platform plugin.)
14:35:26 <rdieter> anyway, there we have it, I'd propose we follow both recommendations, anyone want to discuss either or make a counter proposal ?
14:36:03 <Kevin_Kofler> So compared to what we have now, we'd just build the GStreamer backend from the phonon package?
14:36:12 <rdieter> Kevin_Kofler: yes
14:36:18 <Kevin_Kofler> Then -xine will prevail as they're both from the same SRPM and -xine is shorter.
14:36:32 <Kevin_Kofler> Oh, and drop our priority patch which makes GStreamer have higher priority.
14:37:08 <Kevin_Kofler> (in case both are installed)
14:37:14 <rdieter> than, ltinkl, jreznik ?
14:37:34 * ltinkl takes a deep breath
14:37:52 <jreznik> rdieter: it's ok for me but I'm not sure about xine as default... I still think it's more broken than gstreamer
14:37:57 <ltinkl> rdieter: I think it's ok for Fedora to go this path if it'đ recommended by upstream
14:38:14 <ltinkl> I'd prefer the gstreamer plugin
14:38:20 <ltinkl> worked better for me
14:38:21 <Kevin_Kofler> That said, there's the qtconfig-qt4 issue...
14:38:33 <Kevin_Kofler> If we build Qt without GStreamer, it won't have Phonon-GStreamer setup.
14:38:40 <ltinkl> yup
14:38:41 <Kevin_Kofler> If we built it with GStreamer, it'll require GStreamer.
14:38:42 <ltinkl> that too
14:38:50 <rdieter> jreznik: they're both broken in their own ways, it's just that -xine is more supportable
14:39:13 <Kevin_Kofler> Because it requires GStreamer directly to get some info Phonon-GStreamer doesn't provide (completely broken design, Phonon is supposed to abstract that stuff!).
14:39:20 <ltinkl> rdieter: I wouldn't say so, far more commits went into the gst backend past months
14:39:21 <rdieter> the qtconfig-qt4 thing is fixable, can enable -gstreamer backend during build, we just won't include in packaging
14:39:23 <SMParrish> Where is most of the work being done?  fixing -gstreamer or -xine
14:39:34 <Kevin_Kofler> rdieter: But won't it drag in GStreamer then?
14:39:37 <rdieter> ltinkl: that's contrary to what sandsmark said
14:39:40 <ltinkl> SMParrish: in -gstreamer
14:39:59 <ltinkl> ok, I'll dig thru the kde-commits archives and do some figures :)
14:40:39 <ltinkl> and furthermore, I think the -gstreamer backend supports video, as opposed to the -xine one
14:41:05 <ltinkl> at least for me, video didn't work with the xine backend
14:41:17 <rdieter> sandsmark has committed to fixing that in -xine (as well as any other issue we find/report), the same can't be said of issues found in -gst
14:41:20 <Kevin_Kofler> I just checked, yes it will. :-/
14:41:31 <Kevin_Kofler> There's no support for dlopening GStreamer in qtconfig.
14:41:40 <Kevin_Kofler> So if you build it with GStreamer support, it'll link it in and require it.
14:41:47 <Kevin_Kofler> If not, you don't get to set up that stuff.
14:42:03 <Kevin_Kofler> They're querying info about the available sinks directly from GStreamer.
14:42:06 <rdieter> Kevin_Kofler: it's a downside we can live with (for now), I think
14:42:11 <Kevin_Kofler> No.
14:42:20 <Kevin_Kofler> We'll have both GStreamer and xine-lib on the live CD...
14:42:30 <Kevin_Kofler> On the other hand, I guess we have that anyway due to libcanberra.
14:42:33 <Kevin_Kofler> Sigh...
14:42:43 <ltinkl> yup, the only thing that worries me here is that we'll have to maintain our own codepath in RHEL, should KDESIG decide to go with xine
14:42:57 <jreznik> why we need xine-lib on CD if we have gstreamer?
14:42:58 <Kevin_Kofler> So switching to Phonon-xine might make us overrun our live CD size constraints. -(
14:43:00 <Kevin_Kofler> :-(
14:43:17 <ltinkl> one reason to go with gts
14:43:22 <ltinkl> gst even
14:43:34 <rdieter> anyway, are we agreed then on the plan moving forward?  I guess I can volunteer to implement the necessary changes
14:43:34 <Kevin_Kofler> We can't get rid of GStreamer anymore because firstboot->metacity->libcanberra->gstreamer. :-(
14:43:36 <ltinkl> furthermore it's a defacto standard in Fedora land
14:43:44 <jreznik> for fedora it's better to go with gst...
14:43:46 <Kevin_Kofler> We might get that stuff split out, as libcanberra has native PA support.
14:43:58 <Kevin_Kofler> But that'll make the anti-PA folks hate us forever.
14:44:10 <jreznik> maybe we can look @ gst phonon and help with development
14:44:29 <Kevin_Kofler> (non-PA output with libcanberra requires GStreamer, so if GStreamer support is split out, GNOME users get no sound events without PA by default)
14:44:36 * mcepl roots for phonon-gst ;)
14:44:51 <rdieter> jreznik: indeed
14:44:54 <Kevin_Kofler> I'd like a GStreamer-free KDE Live CD.
14:45:05 <Kevin_Kofler> But I think we might not be able to pull that off due to freezes and stuff.
14:45:17 <svahl> gstreamer is also required by qt-x11 and opencv
14:45:19 <Kevin_Kofler> If I split out a libcanberra-gst subpackage, folks are going to hate me for that.
14:45:30 <Kevin_Kofler> svahl: For qt-x11, see qtconfig.
14:45:43 <rdieter> Kevin_Kofler: lots of work, for little gain at this point.  there's bigger things to worry about (probably)
14:45:48 <Kevin_Kofler> (discussion further up)
14:46:08 <Kevin_Kofler> How big is the overhead from having both xine-lib and GStreamer on the live image?
14:46:13 <svahl> Kevin_Kofler: ok.
14:46:31 <Kevin_Kofler> If it's not too big, we can just use Phonon-xine, but have qtconfig built with GStreamer support anyway and not worry about the other stuff dragging it in.
14:46:34 <than> sorry, i was on the phone
14:46:38 <Kevin_Kofler> I think we did have both on the F11 live image.
14:46:49 <Kevin_Kofler> (due to libcanberra dragging in GStreamer already)
14:47:18 <Kevin_Kofler> (It was just pavucontrol dragging in libcanberra back then, now it's also metacity which is required by firstboot.)
14:47:36 <Kevin_Kofler> So having both present should not be that big.
14:47:41 <than> what is the gstreamer-backend state now?
14:47:49 <svahl> atm both, xine-lib and gstreamer are on the images.
14:48:10 <Kevin_Kofler> Oh, xine-lib is already present? Then nothing blocks us from using phonon-xine by default. :-p
14:48:26 <than> Kevin_Kofler, i don't agree
14:48:31 <Kevin_Kofler> Oh, I guess I know why, Dragon Player's support for additional features using Xine directly.
14:48:33 <svahl> xine-lib is required by kdemultimedia and kdebase-runtime
14:48:43 <than> i don't see any reason why we have to switch to xine
14:48:44 <rdieter> than: proposal is to build both -gst/-xine backends separately from qt, and use -xine by default
14:48:48 <Kevin_Kofler> We also lose these by using GStreamer by default.
14:48:55 <than> rdieter, why`
14:49:11 <rdieter> than: that's what phonon upstream (sandsmark) recommended
14:49:38 <than> i don't see any problem in phonon-gstreamer-backend
14:49:40 <jreznik> rdieter: but for us it's better to fix gst one
14:49:51 <than> i know he is working on this stuff
14:49:51 <Kevin_Kofler> Because upstream recommends it, because Phonon-GStreamer is not any less buggy than Phonon-Xine (but arguably more buggy), because it integrates better with KDE as it's the KDE backend and because Dragon Player supports more features with Xine.
14:49:58 <jreznik> fedora is gstreamer based, there's better support for it
14:50:03 <rdieter> I don't see any problem with either backend, we're providing both
14:50:29 <rdieter> the issue at hand is what is best supportable by use and upstream
14:50:34 <rdieter> by us...
14:50:35 <Kevin_Kofler> Yeah, but the problem is, what should be the default? ;-)
14:50:37 <than> it's not the reason for us to switch to xine now
14:50:41 <Kevin_Kofler> I'm for xine as default too.
14:50:50 <Kevin_Kofler> More like "not to switch to GStreamer".
14:50:53 <jreznik> by us it's gst, by upstream probably xine
14:50:56 <Kevin_Kofler> xine is the default in all the stable releases.
14:51:02 <Kevin_Kofler> We just tried GStreamer in Rawhide.
14:51:18 <than> Kevin_Kofler, and is default for F12
14:51:26 <Kevin_Kofler> F12 is not released yet.
14:51:42 <than> but we want to have it for F12
14:51:54 <Kevin_Kofler> The discussion is about changing the default for F12 now that it can still be done.
14:52:10 <Kevin_Kofler> Going back to what we always had, which always worked and which upstream recommends.
14:52:22 <Kevin_Kofler> Because there's no benefit from switching.
14:52:23 <SMParrish> IMO since upstream is recommending -xine and it enables additional functionality for KDE apps it should be used as the default for KDE.  We dont have to use -gstreamer just because Fedora Gnome does
14:52:40 <thomasj> +1
14:52:59 <ltinkl> SMParrish: what are the benefits of -xine over -gst?
14:53:03 <rdieter> we've evaluated gstreamer default, and the evaluation wasn't all that bad.  good actually
14:53:53 <rdieter> technically, imo, there's not an overwhelming argument in favor of one backend over the other either
14:54:23 <SMParrish> ltinkl: as I said the 2 that I see are upstream suggests it and is working to fix the issues and 2 the additional functionality in Dragon player and other multimedia apps
14:54:53 <Kevin_Kofler> Well, how long is the GStreamer one being actively maintained if Nokia is losing interest in Phonon (which seems to be the case)?
14:55:07 <ltinkl> SMParrish: I don't see upstream working on it at all and the additional features in Dragon? don't know of any
14:55:22 <rdieter> the smaller issues... fedora in general supports gstreamer better,  kde/phonon in general supports xine better
14:55:34 <ltinkl> Kevin_Kofler: Nokia doesn't matter here, KDE is the upstream for Phonon
14:55:56 <ltinkl> Kevin_Kofler: and Phonon will stay there despite Nokia heading (possibly) elsewhere
14:56:41 <jreznik> rdieter: that's the issue - do we have any info about core xine/gstreamer bugs, related to fedora, pa etc?
14:56:44 <rdieter> so, in my own mind, everything else is relatively even, and we come back to what is generally recommended by sansmark
14:56:56 <ltinkl> Kevin_Kofler: KDE developers will issue a memo on this matter in a short time, so far it's private to KDE e.v.
14:57:04 <ltinkl> can't disclose more info now, sry :)
14:57:21 <rdieter> jreznik: I maintain xine-lib for fedora, generally speaking, we're pretty well off bug-wise (no serious outstanding issues)
14:57:26 <ltinkl> I'm sure rdieterread this too
14:57:33 <Kevin_Kofler> And is KDE going to maintain Phonon-GStreamer as actively as Phonon-Xine?
14:57:44 <Kevin_Kofler> So far -GStreamer was a Trolltech backend.
14:57:49 * ltinkl goes to dig the stats
14:58:26 <rdieter> heck, may end up being more a perception and political thing at this point too.
14:58:56 <than> i don't see any bug report about phonon-gstreamer-backend till now
14:59:01 <rdieter> for example, for issues reported to #phonon and #amarok channels, one of the first debugging steps they always use:  switch to xine backend
14:59:02 <Kevin_Kofler> DVD menus are still xine-lib-only in Dragon Player.
14:59:14 <rdieter> (as well as disable pulseaudio... but that's a separate issue... :) )
14:59:14 <Kevin_Kofler> You need to build it against xine-lib at compile time to get them.
14:59:51 <Kevin_Kofler> Search for HAVE_XINE in src/app/videoWindow.cpp to see for yourself (even in 4.4 trunk).
15:00:00 <Kevin_Kofler> Phonon didn't or still doesn't have an API for it.
15:00:23 <than> rdieter, why don't we get any bug report for this?
15:00:29 <rdieter> dang, time's up
15:01:07 <Kevin_Kofler> than: Because the Amarok folks say the GStreamer backend is completely broken.
15:01:11 <rdieter> than: counter that with, what bug reports do we have about -xine backend ?
15:01:21 <than> Kevin_Kofler, i don't think so
15:01:30 <Kevin_Kofler> So they don't file bugs for individual issues as they just consider it unusable entirely.
15:01:35 <rdieter> than: ask them then, that's the answer you'll get
15:02:13 <rdieter> bugzappers, yell if you're present and you need us to clear out.
15:02:23 <Kevin_Kofler> So any decision on the Phonon topic?
15:02:31 <than> if they don't file  bugs, then it's not a bug!
15:02:31 <rdieter> Kevin_Kofler: nope
15:02:34 <Kevin_Kofler> Should we vote? Defer to next week?
15:02:47 <rdieter> vote for posterity if nothing else.
15:02:57 <ltinkl> vote next week imo
15:02:58 * Kevin_Kofler votes for Xine.
15:03:11 <SMParrish> +1 for Xine
15:03:11 * ltinkl votes fro GST
15:03:22 * thomasj would vote for xine since it just works here
15:03:27 <rdieter> proposal: fedora follow phonon upstream recommendation, use xine backend by default
15:04:03 <rdieter> xine +1
15:04:12 <Kevin_Kofler> I presume than is voting for GStreamer?
15:04:14 <Kevin_Kofler> jreznik?
15:04:50 <Kevin_Kofler> That's gonna be quite close, also because we don't have clear criteria on who's actually allowed to vote. ;-)
15:04:51 <ltinkl> I think they do :)
15:04:52 <jreznik> gst for now - it's working better for me - but I'd like to see response from more people
15:05:42 <svahl> maybe create a bug test day for phonon-gstreamer then?
15:05:46 <jreznik> but let me look @ gst backend to compare it with xine and to see what can we do to match these too in term of functionality/stability
15:05:48 <than> yes we would like to see response from more peoples
15:06:05 <Kevin_Kofler> I'd say we defer the final decision to next week.
15:06:11 * rdieter still thinks it's beyond technical issues at this point
15:06:12 <Kevin_Kofler> We're way over time and there's one more agenda item...
15:06:46 <rdieter> let's keep going until any bugzappers yell (feel free to do so, if you're present and waiting)
15:06:49 <Kevin_Kofler> But so far, it looks like everyone who's not @RH is voting for Xine, whereas the 3 RH folks are for GStreamer.
15:07:02 <Kevin_Kofler> svahl, any opinion?
15:07:09 <rdieter> wait, that's all the agenda I had, was there anything else ?
15:07:16 <Kevin_Kofler> KDM fingerprint support update
15:07:25 <svahl> haven't tried gstreamer yet, xine works fine. so no opinion atm
15:07:29 <rdieter> #topic KDE fingerprint support update
15:07:46 <rdieter> who's reporting KDE fingerprint ?
15:07:56 <jreznik> Kevin_Kofler: yes, one reason for gst is that it's better for us @ rh, but the main reason for me is that it's better with gst for me on my laptop
15:08:00 <jreznik> rdieter: me
15:08:01 <mcepl> Kevin_Kofler: don't worry about time that much, bugzappers have light agenda, we can wait a little.
15:08:23 <Kevin_Kofler> jreznik: So, about those KDM fingerprints?
15:08:30 <jreznik> jbarton/djaara is going to work on it again
15:08:37 <rdieter> yay
15:08:39 <jreznik> ossi just commited the must patch
15:08:53 <Kevin_Kofler> Can we get this into F12?
15:08:53 * rdieter falls over in disbelief  (:
15:08:59 <Kevin_Kofler> Or F12 updates at least?
15:09:09 <jreznik> so it's now possible to do finish it but probably not to F12
15:09:38 <jreznik> I'm trying to prepare patched kdm package for djaara to work on it... we can probably reuse this patch but still there's lot of work
15:10:03 <Kevin_Kofler> OK
15:10:05 <jreznik> but now it's much more closer to get it working - this was the last issue
15:10:07 <rdieter> cool, good news, let us know how things progress, and when there's anything testable.
15:10:16 * Kevin_Kofler would really like the fingerprint reader on his laptop to have a use. ;-)
15:10:25 * rdieter has one too
15:10:46 <rdieter> alright, let's wrap up then, thanks everyone!
15:10:49 <jreznik> that's all from
15:10:49 <rdieter> #endmeeting