15:06:23 <rdieter> #startmeeting kde-sig
15:06:23 <zodbot> Meeting started Tue Jan 29 15:06:23 2013 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:06:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:06:26 <rdieter> #meetingname kde-sig
15:06:26 <zodbot> The meeting name has been set to 'kde-sig'
15:06:30 <rdieter> #topic roll call
15:06:42 <rdieter> hello all, who's present today?
15:06:45 <Kevin_Kofler> Present.
15:06:53 * jgrulich is present
15:07:00 <than> present
15:07:18 * ltinkl is here
15:07:41 * jreznik is here
15:07:58 <rdieter> #info rdieter Kevin_Kofler jgrulich than ltinkl jreznik present
15:08:04 <rdieter> #chair Kevin_Kofler jgrulich than ltinkl jreznik present
15:08:04 <zodbot> Current chairs: Kevin_Kofler jgrulich jreznik ltinkl present rdieter than
15:08:20 <rdieter> dvratil was around earlier... :)
15:08:24 <rdieter> #topic agenda
15:08:28 <dvratil> still here :)
15:08:30 <rdieter> what to discuss today?
15:08:36 <than> rdieter:  KDE410 feature
15:09:02 <Kevin_Kofler> qtchooser strikes back?
15:09:06 <than> we should check the feature page before jaroslave announces it
15:09:21 <than> https://fedoraproject.org/wiki/Features/KDE410
15:10:14 <rdieter> ok, those are a good start
15:10:34 <rdieter> #topic qtchooser strikes back, revenge of the sith, blah blah
15:10:51 <than> the deadline is tomorrow
15:11:09 <than> so we want to make sure that it's ready to submit
15:11:15 <than> today
15:11:16 <rdieter> ok
15:11:27 <rdieter> we'll do that one next (quickly, hopefully)
15:11:59 <rdieter> So, as we discussed in #fedora-kde channel awhile back, I reworked qtchooser packaging and implementation to be less intrusive and fully opt-in now
15:12:17 <rdieter> Kevin_Kofler still holds philosophical objections
15:12:36 <rdieter> https://bugzilla.redhat.com/show_bug.cgi?id=qtchooser
15:12:38 <rdieter> is the pkg review
15:13:17 <rdieter> see discussion starting at https://bugzilla.redhat.com/show_bug.cgi?id=895149#c5
15:13:20 <Kevin_Kofler> I also hold the objection that packaging qtchooser that way serves no practical purpose.
15:13:34 <rdieter> ^^ the philosophical part. :)
15:13:41 <Kevin_Kofler> If you can set a PATH to enable qtchooser, you can also set it to choose Qt directly.
15:14:21 <Kevin_Kofler> The philosophical part is that qtchooser just assumes the wrong thing, i.e. that it's up to the user to pick his/her Qt as opposed to the build system of the software he/she is building.
15:14:45 <Kevin_Kofler> The fact that the compromise packaging qtchooser is essentially useless is the practical part, not the philosophical part. :-)
15:15:18 <rdieter> I'd argue if upstream provides it, and expects downstreams adopt it, we have an obligation to do so (provided there are no downsides to doing so)
15:15:42 <rdieter> and, as far as I'm aware, given the current implementation, there are no downsides anymore
15:15:47 <Kevin_Kofler> And I'd argue that it makes no sense to package something that serves no practical purpose.
15:15:56 <rdieter> Kevin_Kofler: for *you*
15:16:01 <Kevin_Kofler> For ANYBODY.
15:16:15 <dvratil> as a developer, I'd really welcome such tool to be able to test Qt4 vs Qt5 apps/porting
15:16:17 <than> i have taken a close look at this, but frist question:  is it linux fhs conform
15:16:23 <rdieter> I'm willing to do the work, I dont think you have any right to dictate how I spend my time
15:16:25 <Kevin_Kofler> If they can set PATH=/usr/lib/qtchooser:$PATH, they can also set PATH=/usr/lib/qt4/bin:$PATH directly.
15:16:42 <Kevin_Kofler> What's the point of having the overengineered wrappers?
15:16:51 <rdieter> Kevin_Kofler: we are not here to debate that
15:17:12 <rdieter> My argument is that *it does not matter* (for the most part)
15:17:18 <Kevin_Kofler> dvratil: Please answer how it'd make anything actually simpler, considering that you can already use PATH to get unsuffixed Qt binaries.
15:17:30 <Kevin_Kofler> And for KDE stuff, it uses CMake and CMake will pick up the correct Qt to use in the first place!
15:17:34 <Kevin_Kofler> With no qtchooser at all.
15:17:57 <dvratil> Kevin_Kofler, not having to write my _own_scripts and PATH modifications?
15:18:24 <Kevin_Kofler> dvratil: qtchooser expects YOU to do that anyway! That's exactly why it's broken.
15:18:28 <Kevin_Kofler> Look at its interface.
15:18:32 <rdieter> than: you mean the use of _prefix/lib ?  it's valid, many other pkgs currently use it.  (Kevin thought %_libexecdir may be more appropriate, but I dont care)
15:18:36 <Kevin_Kofler> It's not designed for a build system to automatically use at all.
15:18:47 <Kevin_Kofler> I don't think any build system actually supports it now, and most probably never will.
15:18:58 <Kevin_Kofler> And for CMake, you don't need qtchooser anyway.
15:19:12 <Kevin_Kofler> You just need a properly packaged Qt 5, we're working on that.
15:19:13 <rdieter> I'm not going to participate in any discussion about if qtchooser is a good implementation or not.  again, *it does not matter* really
15:19:25 <Kevin_Kofler> It'll find the suffixed binaries automatically.
15:19:33 <Kevin_Kofler> Just like FindQt4.cmake already does.
15:19:50 <Kevin_Kofler> than: The conformity to file system guidelines is another debate. IMHO, this MUST go to libexec, not lib.
15:19:51 <rdieter> what I'm asking of the kde-sig, is if anyone has objections to its current packaging ?
15:20:02 <Kevin_Kofler> But it's the least of my worries.
15:20:29 <rdieter> Kevin_Kofler: I assume you'll object to basically anything qtchooser-related?
15:20:31 <Kevin_Kofler> The point is that it's stupid to provide user-facing binaries in a non-default path and even more stupid if their one and only stated purpose is to avoid users having to fiddle with PATH.
15:21:03 <rdieter> fwiw, that was the only implemenation which allows easy opt-in (use it if installed, else not)
15:21:11 <rdieter> similar to how ccache works
15:21:12 <Kevin_Kofler> Yes. Having it by default is broken for several reasons, having it not by default is broken because it makes it entirely useless (plus some of the reasons having it by default is broken too).
15:21:21 <rdieter> ok, duly noted.
15:21:23 <rdieter> anyone else?
15:21:28 <Kevin_Kofler> So yes, I object to any qtchooser implementation.
15:22:00 <rdieter> the only extra piece required is that any qt-related package provide a qtchooser .conf file
15:22:23 <Kevin_Kofler> … which is unnecessary pollution in our Qt packages.
15:22:26 <than> imo we should avoid to add new stuff which is useless and could break the our build
15:22:34 <rdieter> than: it doesn't break anything
15:23:15 <rdieter> than: you think its useless too?
15:23:25 <Kevin_Kofler> And the fact that Qt packages are listed by conf files which define even the name/ID of the Qt version is very broken, because it basically prevents build systems from selecting the correct Qt automatically.
15:23:31 <rdieter> Kevin_Kofler: please stop
15:23:44 <rdieter> we know how you feel already.  I'd like to here some comments from others
15:23:48 <Kevin_Kofler> If qtchooser would actually guarantee that QT_VERSION=4 selects Qt 4, it'd allow build systems to make use of that fact.
15:23:54 <Kevin_Kofler> But it will NOT guarantee that.
15:24:12 <Kevin_Kofler> So it's all down to manual fiddling, yuck!
15:24:18 * rdieter wonders why Kevin_Kofler didn't participate in the upstream discussion
15:24:31 <rdieter> theres still time to give feedback you know
15:24:56 <Kevin_Kofler> Because 1. I'm not subscribed to their f***ing mailing list and 2. they won't listen anyway, seeing how they ignored what the distro folks asked entirely and came up with their own broken thing.
15:26:01 <rdieter> it turned into what it did, because the only folks giving feedback were upstream qt devs (and they largely didn't like the idea a parallel-installility to begin with)
15:26:39 <than> rdieter: i don't mean it's useless, but if it works without qtchooser why do we need it for the build?
15:26:43 <Kevin_Kofler> They don't understand at all what parallel installability means and why we want it.
15:27:05 <Kevin_Kofler> "The user has to select 'his' version of Qt before doing a build." is just a totally broken approach.
15:27:07 <than> the most enduser don't care about the build
15:27:21 <rdieter> anyway, if it matters, I've been contacted privately by more than a few Qt/KDE developers asking me about qtchooser, and thanking me for pushing for it's inclusion in fedora.  As a matter of fact, they also expressed that it would be sad and unfortunate if we choose not to ship it
15:27:26 <Kevin_Kofler> I mean, I can see how it can make sense in a qmake-only world, where you need to use the correct qmake, but even there, suffixes are a better solution.
15:27:46 <Kevin_Kofler> It makes no sense whatsoever with any non-qmake build system, where the build system spec should say what version of Qt is needed, NOT the user!!!
15:28:07 <rdieter> than: that's true.  only some (small?) subset of Qt developers will care
15:28:27 <Kevin_Kofler> If they're KDE developers, tell them that they will NOT need qtchooser with our Qt 5 packaging.
15:28:39 <Kevin_Kofler> They use CMake and CMake will find Qt 5 on its own.
15:28:54 <rdieter> Kevin_Kofler: thats a given, please dont raise arguments that aren't relevant
15:29:02 <Kevin_Kofler> (Of course we actually need the trivial CMake config patches to ensure that, I'll take care of it.)
15:29:18 <Kevin_Kofler> rdieter: Well, if people ask you for something they THINK they need when they actually don't, that's not a valid argument.
15:29:32 <Kevin_Kofler> It's a misunderstanding.
15:29:40 <rdieter> fair enough.
15:29:41 <Kevin_Kofler> Which needs to be rectified where it happened.
15:29:45 <Kevin_Kofler> Not abused as an argument.
15:30:03 <rdieter> so, let's get moving on, last chance, anyone else besides Kevin_Kofler object to qtchooser packaging?
15:30:30 <rdieter> (if you want more time, feel free to comment in the pkg review)
15:30:32 <than> i suggest we will vote for this
15:31:00 <rdieter> than: vote on what exactly?  whether or not to ship qtchooser at all?
15:31:04 <Kevin_Kofler> Proposal: Fedora will NOT ship qtchooser in its current form.
15:31:21 <Kevin_Kofler> with obvious +1 from myself
15:31:38 <than> rdieter: to support qtchooser
15:31:59 <rdieter> than: Kevin_Kofler's proposal then?
15:32:16 <than> rdieter: yes
15:32:17 * rdieter will abstain unless there's a tie
15:33:09 <rdieter> jgrulich, jreznik, than, ltinkl, dvratil : your votes to Kevin_Kofler's proposal?
15:33:46 <ltinkl> undecided to be honest
15:34:11 <rdieter> i guess its fine if folks want more time to think about it
15:34:42 <rdieter> Kevin_Kofler: mind posting your proposal to the pkg review, and kde-sig members can vote in bz
15:34:50 <than> rdieter: +1, i would say we move it to next meeting
15:35:28 * rdieter didnt think we'd get bogged down debating the merits of qtchooser, thought we could decide quickly.  :(
15:35:43 <rdieter> moving on...
15:36:00 <rdieter> grr
15:36:04 <rdieter> #topic https://fedoraproject.org/wiki/Features/KDE410
15:36:13 <rdieter> there
15:37:05 <than> please take a look at this. we want to submit it today
15:37:27 * ltinkl did take a look
15:37:54 <Kevin_Kofler> Hmmm, the feature page advertises "Color Correction (based on colord)", where would that be?
15:38:15 <Kevin_Kofler> Upstream implemented color correction in KWin, but based on Oyranos, not colord, and it only works if you build KWin against Oyranos at compile time.
15:38:25 <rdieter> wrt KWin supports global menu , does that mean we should ship (unmaintained pkg by the way) plasma-widget-(menuthingy) ?
15:38:25 <Kevin_Kofler> The code needs to be ported to colord. :-(
15:39:08 <than> Kevin_Kofler: hm i thought it's based colord
15:39:55 <Kevin_Kofler> Some of the emphasis in "How To Test" also sounds obsolete, e.g. PolicyKit-1-related stuff should not need extra attention anymore.
15:40:18 <rdieter> I guess we can fix "wiki bugs" later, I don't anything big or glaringly wrong
15:40:26 <Kevin_Kofler> than: Unfortunately, it's not. It was developed by Oyranos folks.
15:40:36 <than> Kevin_Kofler: oh you are right, it's Implement color correction in kwin!
15:40:37 <Kevin_Kofler> So I guess it's not even enabled in Rawhide.
15:41:16 <Kevin_Kofler> (and I'm not sure we want to… Oyranos is a heavy dep… that stuff really needs to be ported to colord :-( )
15:41:47 <than> this feature should be removed from the page
15:42:07 <Kevin_Kofler> (and I know Kai-Uwe won't like me saying that, but from a practical standpoint Oyranos is really unwanted in Fedora)
15:42:42 <than> does someone want to port it? if not i will drop it
15:42:48 <Kevin_Kofler> I'd say drop it.
15:43:04 <Kevin_Kofler> I doubt this can be done by F19, and if not we can always smuggle it in later. :-)
15:43:06 <ltinkl> ye drop it
15:44:04 <Kevin_Kofler> Don't promise things nobody is working on. :-)
15:44:08 <than> done.
15:45:21 <rdieter> Kevin_Kofler: how is oyranos a heavy dep?
15:45:22 <than> the feature is updated, is it ok now?
15:45:30 <rdieter> looks small as far as I can tell...
15:46:00 <Kevin_Kofler> It drags in Elektra, at least used to.
15:46:08 <Kevin_Kofler> And I think some other things.
15:46:20 <rdieter> true, ok.  elektra is small too though
15:46:36 <Kevin_Kofler> Plus, the question is whether Oyranos and colord won't make a mess if both are running.
15:46:50 <rdieter> true too
15:47:00 <Kevin_Kofler> If both try to color-correct the same things, it can be total chaos. :-(
15:47:15 <jreznik> rdieter: only appmenu-qt
15:47:54 <jreznik> the support is then in kwin, not that plasma-blabla
15:47:57 <Kevin_Kofler> In fact, I wonder whether color correction at KWin level is even necessary, there are at least 2 other possible places to do it (X11 level or toolkit level) and of course things need to be corrected exactly once or they'll be actually messed up.
15:48:01 <rdieter> jreznik: ok, someone please add test-case on how to test/use that global menu thing then
15:48:23 <rdieter> (cause I have no idea, and I bet others are similar)
15:48:41 <jreznik> rdieter: http://blog.martin-graesslin.com/blog/2013/01/4-10-feature-presentation-application-menu-in-window-decoration/
15:48:57 <Kevin_Kofler> Color correction is still a big mess. :-(
15:49:34 <Kevin_Kofler> Now if enabling Oyranos support in KWin really does help and if the dependency bloat is not too bad, I guess we can do it.
15:49:56 <jreznik> "(if not complain to your distribution)"
15:50:01 <rdieter> Kevin_Kofler: if someone has time/interest to investigate, add deps, do builds, then we can add it back perhaps
15:50:03 <Kevin_Kofler> But I think there are going to be issues, like you have to set up Oyranos separately from colord, ugh…
15:50:58 <rdieter> jreznik: so.. add a hard dep, or you think adding to comps is enough?
15:51:39 <rdieter> wrt appmenu-qt that is
15:51:53 <than> imo hard dep is enough
15:51:55 * jreznik was thinking more about comps but hard dep does make sense
15:52:09 <rdieter> could be paranoid and do both
15:52:20 * rdieter will do that part
15:52:24 <Kevin_Kofler> Adding to comps doesn't make sense if it's a hard dep.
15:52:42 <than> Kevin_Kofler: absolute
15:52:44 <rdieter> small bit of sense, ensures anyone doing :  yum install @kde-desktop    always gets the latest build/version
15:53:17 <rdieter> but thats all
15:53:25 <Kevin_Kofler> Now whether we really want a dependency on such an optional feature, I'm not sure, but OTOH, I guess users expect the option to work if they enable it.
15:53:57 <Kevin_Kofler> Oh, and last I checked, appmenu-qt was orphaned, or has it already been picked up?
15:54:50 <rdieter> still unowned last I knew, adding myself now...
15:55:08 <jreznik> Kevin_Kofler: it's not hard dep - build time one
15:55:21 <jreznik> Kevin_Kofler: I picked it up (with rrix)
15:55:47 <jreznik> Kevin_Kofler: it's hidden option when it's missing the dep
15:56:01 <rdieter> jreznik: so add both as BuildRequires and Requires ?
15:56:20 <jreznik> it's just run time requirement
15:56:37 <Kevin_Kofler> If the option is just hidden when the dep is not installed, I think we could just not require it at all.
15:57:00 <rdieter> comps it is! :)
15:57:01 <jreznik> Kevin_Kofler: the main reason is to offer that option to users as martin is featuring it
15:57:03 <Kevin_Kofler> I'm actually not sure we want to ship a feature by default which only work with Qt apps.
15:57:15 <jreznik> Kevin_Kofler: it's not enabled by default
15:57:19 <Kevin_Kofler> appmenu-gtk is still not practical last I checked.
15:57:28 <jreznik> rdieter: well that's why I started with comps :)
15:57:34 <Kevin_Kofler> But that's why we shouldn't ship it by default, we aren't going to enable it by default anyway.
15:57:46 <Kevin_Kofler> Users will only have the option if they have the package installed, which makes perfect sense.
15:57:58 <Kevin_Kofler> I'd put it in comps as optional, actually.
15:58:12 <jreznik> but if you don't ship it, users would not be aware of that options - and after reading blogs/looking on other distros - they would wonder what we did wrong
15:58:22 <Kevin_Kofler> (or however options work now with the new Anaconda)
15:58:39 <Kevin_Kofler> Shipping unnecessary things = bloat.
15:58:46 <Kevin_Kofler> We also don't ship kde-wallpapers by default. :-)
16:00:02 <than> jreznik: i think the kde feature page is ready now
16:00:22 <rdieter> end of hour too, good timing.
16:00:22 <than> jreznik: you can announce it
16:00:30 <rdieter> any final thoughts before I close the meeting?
16:02:07 <Kevin_Kofler> than: How about cleaning up "How To Test"?
16:02:19 <Kevin_Kofler> I think ""root" modules in System Settings (due to pk1)" doesn't need extra testing anymore.
16:02:39 <Kevin_Kofler> "working sound in Phonon, esp. with regards to the PA and GStreamer integration" should also be a given these days.
16:03:01 <Kevin_Kofler> (though I guess verifying that sound hurts can never hurt, it's also one of the release-blocking testcases)
16:03:08 <than> Kevin_Kofler:  we will discuss on fedore-kde
16:03:11 <Kevin_Kofler> *verifying that sound WORKS, of course
16:03:30 <than> rdieter: i think we can close the meeting now
16:03:38 <rdieter> k, thanks everyone
16:03:40 <rdieter> #endmeeting