[18:01:10] Join You have joined the channel #fedora-meeting (n=ltinkl@194.212.22.14). [18:01:11] Topic The channel topic is "Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Meeting_channel for meeting schedule". [18:01:11] Topic The topic was set by f13 on 1.6.2009 20:54:11. [18:01:11] Mode Channel modes: no messages from outside, no colors allowed [18:01:11] Created This channel was created on 18.1.2007 20:10:56. [18:01:13] Join jreznik has joined this channel (n=jreznik@nat/redhat/x-aab30951cbb83538). [18:01:41] Join JSchmitt has joined this channel (n=s4504kr@fedora/JSchmitt). [18:01:42] Join tatica has joined this channel (n=tatica@nelug/designer/tatica). [18:02:16] KDE SIG Meeting start, who's present today? [18:02:22] * SMParrish here [18:02:24] * ltinkl here [18:02:29] Present. [18:02:36] Topic rdieter sets the channel topic to "KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-02 -- Init". [18:02:37] Part iarlyy has left this channel. [18:02:44] * jreznik is here [18:02:48] present [18:02:50] * mefoster is back ... [18:02:55] than: welcome back [18:03:21] i was back yesterday [18:03:35] well, agenda item 1, phonon-backend-gstreamer, to ship or not to ship, Kevin_Kofler ? [18:04:02] Join slipp3d has joined this channel (n=Slip@cmg-2-254.r15.mtwgln.infoave.net). [18:04:30] ship it (MHO), there is nothing broken with it, I've been using it for some months already without any major problems [18:04:31] Well, I guess the consensus is to keep shipping it, it's not the default anyway. [18:04:31] half here [18:04:54] my two cents - fedora is gstreamer based distro so ship it... [18:05:04] we ship it but don't make it as default [18:05:19] The thing is just: device selection is implemented in a strange way which bypasses the Phonon API, there's this fun bug: https://bugzilla.redhat.com/show_bug.cgi?id=503260 which is due to that, and the Amarok developers complain about several other bugs. [18:05:19] Bug 503260: medium, low, ---, than, ASSIGNED, qtconfig-qt4 does not recognize that gstreamer backend is around [18:05:59] the bug itself is due to the way we compile Phonon right? [18:06:06] That bug is because qtconfig-qt4 needs to link GStreamer directly to configure Phonon-GStreamer as the information from GStreamer is not abstracted properly by the backend. [18:06:09] ltinkl: how qt is built [18:06:11] (not really a phonon.gstreamer bug) [18:06:37] I don't like several multimedia frameworks, it's better one and well supported - in fedora it's gstreamer... [18:06:41] side issue here is how to build/ship phonon, upstream still doesn't have a clear recommendation. [18:06:53] use qt's phonon, or kde/standalone phonon? [18:06:55] We need to BR gstreamer-devel to fix that, and then qtconfig-qt4 will depend on GStreamer. [18:07:22] Kevin_Kofler: BR is all? that's acceptable... I thought the -gstreamer backend had to be built/enabled too. [18:07:29] This is completely broken, the whole point of Phonon is that the UIs don't have to link a multimedia framework directly. [18:07:49] rdieter: Most likely the backend has to be built or qtconfig's .pro file tweaked to fake it. [18:07:50] Quit openpercept has left this server ("Leaving"). [18:07:55] oh ok. [18:07:57] I agree with Kevin here, the backend abstraction isnt perfect here [18:08:17] what bothers me more is which Phonon to ship? [18:08:27] Qt or KDE's one? [18:08:38] The underlying issue is that Phonon has only one level of devices, GStreamer has 2 ("sink" = the API used and "device" = the device accessed through that API). [18:08:39] seems other distros are starting to use qt's [18:08:39] the KDE version hasn't seen any updates for quite some time [18:09:00] And Phonon-GStreamer works around that with that backend-specific "sink" option. [18:09:18] and if using qt's phonon, what does that mean about phonon-backend-xine's maintainance/support [18:09:19] xine-lib also has those 2 levels, but Phonon-Xine magically turns them into a flat list. [18:09:50] phonon-backend-xine lives in kdesupport only? [18:09:56] Which also means PulseAudio shows up as one device, you can't control where the output goes to through PulseAudio without going to pavucontrol or the like (not sure whether xine-lib would support it, but Phonon definitely doesn't). [18:10:05] Is that why there are so many weird options in the "multimedia" system-settings module? [18:10:17] Kevin_Kofler: I recall you having some discussions with (upstream?) folk to address that, but I suppose none of that led to any fruitful fixes yet? [18:10:27] Join MathStuf__ has joined this channel (n=MathStuf@c-71-58-177-177.hsd1.pa.comcast.net). [18:10:47] ltinkl: Yes, Trolltech/Nokia refused to import it into their copy because xine-lib is GPL and so not acceptable for their commercial customers. [18:11:30] mefoster: it's really mess... [18:11:30] rdieter: Right, my SoC project where I suggested to tackle that as well as KMix PA integration was rejected. [18:11:49] Earlier discussions with Phonon upstream lead to people mostly agreeing with my suggestion, but no movement towards actually implementing it. [18:12:23] looks like we've got 2 issues at least to sort out: 1. how to build support phonon (qt or standalone), 2. depending on 1, how best to build/ship phonon backends [18:12:49] Join ChitleshGoorah has joined this channel (n=chitlesh@40.4-66-87.adsl-static.isp.belgacom.be). [18:12:51] any volunteers to own these items? [18:12:56] mefoster: What weird options? You mean things like having both "PulseAudio" and "PulseAudio sound server"? [18:13:36] Kevin_Kofler: Yeah, and also "default" and about three different "Intel" things [18:13:37] (Yes, that one is an artefact of the coalescing, the former is native PulseAudio which shows up as a single device, the latter is the ALSA pulse device which shows up as a device like the other ALSA devices.) [18:13:47] Quit MathStuf_ has left this server (Read error: 60 (Operation timed out)). [18:13:50] mefoster: Those are the ALSA devices. [18:14:08] Those and "PulseAudio sound server" should really be subitems of "ALSA" in a tree. [18:14:19] And that interface would also allow fixing Phonon-GStreamer properly. [18:15:16] We could "fix" it to work the way Phonon-xine now does, but it'd probably break some use cases the current implementation supports. [18:16:17] ok, I'll take ownership of the phonon issues, I guess. Kevin, do you have the time/interest to work on your fixing-phonon ideas? [18:16:18] last time i tried to ask the phonon upstreamer, but did't get any answer! [18:17:03] than: me too, I was assured it would be sorted out for the kde-4.3 release, but that hasn't happened... yet. I'll make some louder noise, and see what happens [18:17:04] Join fbijlsma has joined this channel (n=fbijlsma@p54B2DFBA.dip.t-dialin.net). [18:17:09] I may end up using some of my free time in the future to fix this properly if the current mess annoys me enough, but I don't have much time and it's a lot of work to fix it properly. [18:17:27] Kevin_Kofler: ok [18:17:40] that would be very much appreciated Kevin, not only by folks in fedora, but also in other distros [18:17:44] Of course I'll have to work with Phonon upstream, I can't just do arbitrary API changes to Phonon. [18:17:45] rdieter: ltinkl is using it and already did some work, so maybe he's volunteer :D [18:18:02] hehe not, not gonna touch anything starting with G [18:18:09] :) [18:18:26] seems mandriva at least is using -gstreamer by default, may be worth talking to them too. [18:18:31] Kevin_Kofler: yes, it needs API changes... so lot of work... [18:19:06] As for which Phonon to ship, that's another big mess. [18:19:21] IMHO, as long as there are standalone tarballs, we should use them. [18:19:30] otoh, rumors have it that rhel6 will only support -gstreamer as well, so maybe rh could help out somehow too. :) [18:20:20] Hmmm, than has been surprisingly silent in this Phonon discussion. [18:21:47] let's move on... we've got a bit to cover today, next: KDE-4.2.4 update status, ltinkl, Kevin_Kofler ? [18:21:58] Topic rdieter sets the channel topic to "KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-02 -- KDE 4.2.4 update status". [18:22:08] KDE 4.2.4 done for F10/F11, builds underway [18:22:37] Kevin is backporting to F9 [18:22:41] For F9, I'm syncing things as I'm building them, and I'm doing the builds for the same packages ltinkl builds. :-) [18:22:56] cool, I'll continue to play tag-bot [18:23:00] I think we're about halfway through the core packages or so. [18:23:05] Join nucleo has joined this channel (n=nucleo@80.73.6.156). [18:23:15] Extragear is not started yet though. [18:23:20] do kdegraphics, then you can get to kdebindings [18:23:21] tag bot won't be needed I guess :) [18:23:26] Are the tarballs out yet? (They're already late.) [18:23:38] rdieter: Hmmm, kdebindings built fine without a kdegraphics override. [18:23:45] Nick stickster is now known as stickster_food. [18:23:47] I'll check the extra tarballs once I'm done with the core stuff [18:23:57] and kde-l10n, not to forget this time [18:24:04] oh, stuff should be bc, ok [18:24:11] Oh, and we'll need kdebase in the buildroot once we have konq-plugins to build (i.e. if extragear gets ready). [18:24:33] konq-plugins need more than kdebase I think [18:24:37] needs * [18:24:55] It needs kdebase for Konqueror for sure. [18:25:02] so... stuff should get finished over the next day or so? [18:25:33] * jreznik has to leave today early... some brave man to prepare summary? [18:25:34] ... and no other KDE stuff, I just checked. [18:25:37] Join petreu| has joined this channel (n=peter@p3EE3FAFC.dip.t-dialin.net). [18:25:52] Only kdebase4-devel, cmake and gettext. [18:26:26] jreznik: I'll do the summary today [18:27:10] next topic: Qt 4.5.1 updates [18:27:15] Topic rdieter sets the channel topic to "KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-02 -- Qt 4.5.1 updates". [18:27:46] mdomsch: ping - can you remove the comment about bug 499321 and F10 in releases.txt? It's wrong and confusing people [18:27:48] Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=499321 medium, medium, ---, anaconda-maint-list, CLOSED RAWHIDE, preupgrade backtrace [18:28:08] the last blocker, imo, is amarok-2.1 landing... , for F-10 at least, means blocking on libgpod-0.7.0 batch update too [18:28:14] augh sorry [18:28:14] wwoods, ok, can we turn F10 updates back on then? [18:28:23] * wwoods mischan [18:28:54] Join fab has joined this channel (n=bellet@bellet.info). [18:29:15] Quit jreznik has left this server ("leaving...."). [18:29:24] rdieter: what's the prob? libgpod not ready? [18:30:08] hm, do we plan to push 4.5.1 in update? [18:30:08] libgpod-0.7.0 update for F-10, being a soname bump, requires a batch update for a bunch of stuff, and that update hasn't been made... yet (should be coming soon though) [18:30:32] I had Amarok 2.1 building with libgpod 0.6, but then the libgpod maintainer decided to do the 0.7 upgrade so things got in some state of confusion. [18:31:02] Kevin_Kofler: I suppose we could do another build against libgpod-0.6, and not wait. [18:31:04] Last I heard, the libgpod group updated was blocking on banshee ACLs. [18:31:20] I guess one of us provenpackagers can fill it in. [18:31:35] otherwise, qt-4.5.1 is ready for stable updates, imo. [18:31:39] Or we could nag the banshee maintainers to give Todd the ACLs he requested. [18:32:10] are the qt blocker bug fixed? [18:32:50] yes (mostly), lemme get the details... [18:33:11] Another issue is the kdelibs and kdeplasma-addons changes in the Qt update group, that can interfere with KDE 4.2.4 if we don't push Qt 4.5.1 to stable right now. [18:33:12] yep [18:33:25] But we need an Amarok 2.1 rebuild against libgpod 0.6 for that. [18:33:30] Kevin_Kofler: nod, those (kdelibs in particular) needs to go stable first [18:33:49] itif the qt blocker bugs are fixed [18:33:58] Most likely with a deflated EVR (0.1.fc10.libgpod06?). [18:33:58] Kevin_Kofler: arg, that means I'll need to temp untag kdelibs-4.2.4, build amarok-2.1 against libgpod-0.6 and kde-4.2.3 [18:34:03] it's fine to push it in stable [18:34:20] rdieter: You need to untag libgpod too if you didn't do so yet. [18:34:24] meh, we can work out the details after meeting, but it sounds like a plan [18:34:32] Kevin_Kofler: right [18:35:04] fyi, https://bugzilla.redhat.com/showdependencytree.cgi?id=Qt451&hide_resolved=1 [18:35:42] rssnow has a temporary hack, amarok-2.1 helps, and the yum issue is worked-around via a well-placed Obsoletes [18:36:37] last item on the agenda was: https://bugzilla.redhat.com/show_bug.cgi?id=502953 [18:36:38] Bug 502953: high, low, ---, than, ASSIGNED, kdm switches manually selected session after entering userid [18:36:49] That's that session-button patch we dropped. [18:37:02] Join tibbs has joined this channel (n=tibbs@fedora/tibbs). [18:37:04] It does the wrong thing. [18:37:05] Topic rdieter sets the channel topic to "KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-02 -- https://bugzilla.redhat.com/show_bug.cgi?id=502953". [18:37:06] does it fix the problem? [18:37:09] Quit petreu has left this server (Connection timed out). [18:37:22] The patch causes the problem. [18:37:31] It resets the button to Default after the user is selected. [18:37:46] That's the wrong time to reset the session type. [18:37:47] it fixes the problem by removing the feature :) [18:38:08] i will take a look at the patch again [18:38:34] it's ok to disable this patch in the meantime [18:38:36] What problem was it intended to fix in the first place? [18:39:22] Quit sdziallas has left this server ("Ex-Chat"). [18:39:33] Topic rdieter sets the channel topic to "KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-02 -- Documenting patches". [18:39:45] Hmmm, good point. :-) [18:39:48] Join RadicalRo has joined this channel (n=radical@193.254.32.144). [18:39:50] yes :) [18:39:51] Kevin_Kofler, if i remenber corectly the item is not selected in the combobox [18:39:56] slides into something else I wanted to discuss, documenting patches. [18:40:13] the patch should resolve the issue [18:40:19] than: OK, so that should be fixed, but where you did it is not the correct time to do it. [18:40:21] preferably via local or upstream bug report, else at least a line or 2 comment about it [18:40:49] it seems so, i will take a look at the patch again [18:40:50] ltinkl: didn't you have other ideas on patch metadata too, you mentioned awhile ago? [18:40:53] Because it'll reset the selection the human user made explicitly after a *nix user is selected from the list. [18:41:13] well, I would go even further with the patch commenting [18:41:21] let me dig some example [18:41:45] Quit warren has left this server ("Leaving"). [18:41:46] I think we also need to agree on the versioning: normally, the version in the patch is the version we're patching. [18:42:14] ltinkl: or if it's something bigger than what we have time to fully cover today, maybe send a proposal to fedora-kde list for discussion. [18:42:15] But ltinkl has been using another format for patch backports recently, which uses the version of the first release the patch will be in upstream. [18:42:48] yup, on the patch numbering: I'd suggest to number the patch to the version in which the bug is fixed [18:42:54] the ucrrent way is too confusing [18:43:06] I can see how that can help rebasing, but my main objection is that such a version doesn't necessarily exist and that it can change. [18:43:26] (e.g. if upstream backports the patch, or possibly even reverts it) [18:43:48] then we can keep it that way, or renumber ours as well [18:44:13] in any case, our patch number will be more informative [18:44:16] The name-versionbeingpatched-patchname.patch format is what almost all packages use in Fedora. [18:44:28] which I don't like [18:44:31] I would gladly support almost anything that provides more information that the status-quo [18:44:35] And versionbeingpatched will change if the package gets rebased. [18:44:35] others' opinions? [18:44:40] *patch [18:44:51] If the patch gets rebased to a new release of the package. [18:44:52] Quit sereinity has left this server. [18:45:22] So different patches will ideally have different names, helping those folks who keep all their patches in ~/rpmbuild/SOURCES. [18:45:29] I like ltinkl's idea, unless Kevin_Kofler, you have a better way of marking which patches have been upstreamed and to what version(s) ? [18:45:42] (AFAIK, that's the logic which lead to that naming.) [18:46:20] I think comments are better places to specify where the patch comes, or patch numbers (Patch10x vs. Patch20x as we've started using in some packages). [18:46:32] anyway, we can discuss that after meeting I guess [18:46:36] *comes from [18:46:44] here's an example of what I thought with patch metadata: [18:46:46] https://build.opensuse.org/package/view_file?file=kdm-dont-grab-mouse.diff&package=kdebase4-workspace&project=openSUSE%3AFactory [18:47:15] "Authentication via a Novell Account is required to access openSUSE.org." Grrr... [18:47:17] IMO it's worth the effort of putting a few lines at the beginning of each patch [18:47:21] oops :) [18:47:32] I'll post the patch somewhere else [18:48:04] Why they can't allow downloading files without a login is beyond me, Fedora lets you do that just fine. [18:48:19] does it work with http? [18:49:05] ltinkl: no [18:49:14] http://lists.opensuse.org/opensuse-commit/2009-01/msg00579.html [18:49:21] This contains that patch. [18:49:37] bah ok, I'll post the complete proposal on patch numbering and patch metadata to the ML [18:50:01] (see the end of the commit message) [18:50:06] what is bad with our naming patch files [18:50:57] than: that it has no informative value as to which version the patch applies to [18:51:04] That it's not consistent, if we backport fixes from 4.2.4 to 4.2.3, most of us use kdefoo-4.2.3-bar.patch, ltinkl likes using kdefoo-4.2.4-bar.patch. [18:51:17] naming is a relatively minor detail, the more important issue to understand is to include information about the patch, what it is, what it fixes, when/where was it upstreamed, etc.... [18:51:32] Nick stickster_food is now known as stickster. [18:51:58] if if the patch name can encapsulate some of that information, even better [18:52:27] yup, and the patch itself should contain that information [18:52:43] useful for backporting/moving the patch across versions [18:52:56] Right, I hate patches with names like kdelibs-4.4.0-fixbug.patch and no comment as to what bug it fixes. ;-) [18:53:07] most our patches already contain the information [18:53:16] I always hate digging thru the spec file to find out what the patch does, what bug it fixes, what version it applies to etc. [18:53:29] I can see keeping the name short, but that's what comments in the specfile or in the patch itself are for. [18:53:54] ltinkl: Strange. I like having that information in the specfile. [18:54:01] better have that info _in_ the patch file, you can immediately see what it does [18:54:02] I'm not so much a fan of sticking it into the patch file. [18:54:02] Kevin_Kofler, +1 [18:54:19] But having it in either place is better than not having it at all (like for the session-button patch). [18:54:20] +1 from me as well. Specfile is best place for it [18:54:23] * rdieter doesn't care, as long as the info is somewhere [18:55:12] mild preference for in-patch, so other folks, like other distros , or upstream can get all that info by only looking at the patch too [18:55:56] it gets more obvious with large packages, like kdebase-workspace with a large spec file and lot of patches [18:56:37] Especially for those it's great to have all the comments in one place and not to have to open dozens of patch files to see what we changed. [18:56:47] I'm definitely against naming patches like: kdebase-workspace-4.2.0-kde#180576.patch [18:57:03] And it also means I have to edit only one file (the specfile), if I need to put comments in the patch, I have to hand-edit the patch file as well. [18:57:24] ltinkl, i don't see any problem with this [18:57:34] just add comment in the specfile [18:57:55] ok, if the info is at least somewhere [18:58:04] as we already did in our specfile [18:59:12] Join JSchmitt_ has joined this channel (n=s4504kr@p4FDD12DD.dip0.t-ipconnect.de). [18:59:13] here's a noble goal I think we can shoot for, for *every* patch in any kde core package, include metadata/documentation about it, a local/upstream bug report, and if not upstreamed, justification why it isn't. [18:59:31] Nick dwmw2 is now known as dwmw2_gonwe. [18:59:32] Nick dwmw2_gonwe is now known as dwmw2_gone. [18:59:48] target before kde-4.3.0 lands [19:00:23] but let's sort out the "how to do it" details first, of course. [19:01:06] looks like we're out of time, KDE SIG Meeting end. [19:01:09] thanks everyone. [19:01:23] Part MathStuf__ has left this channel ("Failure: Success!"). [19:01:25] Just a reminder: if you want KDE SIG represented in FESCo, vote for me! :-) [19:01:46] Topic rdieter sets the channel topic to "Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Meeting_channel for meeting schedule". [19:02:06] * rdieter hands Kevin_Kofler a baby for a photo-op