15:06:28 <Kevin_Kofler> #startmeeting KDE SIG Meeting
15:06:28 <zodbot> Meeting started Tue Nov  4 15:06:28 2014 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:06:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:06:32 <Kevin_Kofler> #meetingname kde-sig
15:06:32 <zodbot> The meeting name has been set to 'kde-sig'
15:06:33 * pino|work here
15:06:38 <Kevin_Kofler> #topic Roll call
15:06:44 * Kevin_Kofler present, leading the meeting today.
15:07:05 <dvratil> hi
15:07:16 * jgrulich is present
15:08:12 * jreznik is around
15:09:45 * danofsatx is here
15:10:01 <danofsatx> <-- eating oatmeal. please carry on ;)
15:10:36 * ltinkl is here
15:11:13 <Kevin_Kofler> #chair pino|work dvratil jgrulich jreznik danofsatx ltinkl
15:11:13 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil jgrulich jreznik ltinkl pino|work
15:14:20 <Kevin_Kofler> #info Kevin_Kofler, pino|work, dvratil, jgrulich, jreznik, danofsatx, ltinkl present.
15:14:23 <Kevin_Kofler> #topic Agenda
15:14:50 <Kevin_Kofler> One topic I'd like to bring up is the system-clucene stuff in Qt Assistant.
15:14:52 <than> present
15:15:08 <Kevin_Kofler> #chair than
15:15:08 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil jgrulich jreznik ltinkl pino|work than
15:15:08 <dvratil> I'd like to solve the conflict between KDE 4 and Plasma 5/KDE Applications translations
15:15:24 <dvratil> KF5 5.4 update
15:15:26 * heliocastro here
15:15:29 <Kevin_Kofler> #chair heliocastro
15:15:29 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich jreznik ltinkl pino|work than
15:15:35 <Kevin_Kofler> #info than and heliocastro also present.
15:16:00 <Kevin_Kofler> dvratil: Let's start with your topics.
15:16:28 <dvratil> let's start with the KF5 update, it's just an announcement
15:16:44 <Kevin_Kofler> OK
15:16:46 <Kevin_Kofler> #topic KF5 5.4 update
15:17:05 <dvratil> KDE Frameworks 5.4.0 are currently being built in Koji, so I expect the update to be done later today, or tomorrow morning
15:17:10 <donniezazen_> Hi all.
15:17:40 <dvratil> I create -libs subpackages in two or three frameworks to fix multi-arch conistallability
15:18:01 <dvratil> and that's about all
15:18:36 <Kevin_Kofler> #info KDE Frameworks 5.4.0 are currently being built in Koji, -libs subpackages created in two or three frameworks to fix multi-arch conistallability
15:18:50 <Kevin_Kofler> Thanks for your work on those packages!
15:19:06 <Kevin_Kofler> #topic Conflict between KDE 4 and Plasma 5/KDE Applications translations
15:19:06 <heliocastro> dvratil: There's no conflicts on kglobalaccel and kglobalaccel5 ?
15:19:20 <dvratil> heliocastro: no, the KF5 binary is called kglobalaccel5
15:19:42 <dvratil> Frameworks are 99.9% coinstallable with KDE 4, the only exception being KActivities
15:19:43 <heliocastro> dvratil: I mean, on the startup of both desktops coinstalled
15:19:58 <dvratil> heliocastro:  you can't have both desktops co-installed
15:20:08 <heliocastro> Ok, this answers my question
15:20:13 <heliocastro> thanks
15:20:22 <dvratil> ah, kglobalaccel is provided by kde-runtime,. which you actually can (Should) have installed.
15:20:42 <dvratil> I haven't seen any conflict there yet, but I haven't actually looked for one. I'll check it, thanks heliocastro
15:21:07 <Kevin_Kofler> So we need to make sure that Plasma 5 starts only the services that make sense to start in a Plasma 5 environment, and likewise for Plasma 4.
15:21:18 <Kevin_Kofler> (Even if you have both kdelibs 4 and KF5 installed.)
15:21:22 <heliocastro> Yes
15:21:25 <heliocastro> exactly
15:22:03 <dvratil> you need KDE 4 services when you start a KDE 4 application in Plasma 5 environment
15:22:20 <Kevin_Kofler> Most likely yes.
15:22:35 <Kevin_Kofler> KDE 3 apps definitely still fire up the KDE 3 kded.
15:22:43 <heliocastro> What i saw is that f you start some kde4 application, who will takes care on key shortcuts ?
15:22:50 <Kevin_Kofler> So I'd expect kded4 to also get fired up for KDE 4 apps.
15:25:21 <dvratil> move on?
15:25:28 <heliocastro> Yeah
15:25:39 <Kevin_Kofler> Let me check one thing…
15:25:41 <heliocastro> Nothing we can do before proper verifying
15:26:27 <Kevin_Kofler> I don't seem to have done anything special to kglobalaccel for kdelibs3/kdebase3, did KDE 3 not have such a binary?
15:26:37 <Kevin_Kofler> (I also don't see anything in the kdelibs3 and kdebase3 packages.)
15:26:50 <dvratil> probably not. And if it would, it would be using DCOP, not DBus, so no conflicts
15:27:39 <Kevin_Kofler> So I guess we can move on to what's already in /topic. :-)
15:27:53 <Kevin_Kofler> Still about conflicts, but for translations.
15:28:05 <dvratil> yep
15:28:11 <Kevin_Kofler> Indeed, new workspace and apps stuff conflicts with kde-l10n.
15:28:28 <dvratil> for those who don't know: In KDE 4 all translations are released in one tarball and we package them as one package (kde-l10n-$LANG)
15:28:38 <dvratil> in Plasma 5 each applications and library ships it's own translations
15:28:59 <heliocastro> Maybe change the install directory ?
15:29:03 <Kevin_Kofler> How is this going to work in the Applications 14.12 release, which is mixed KDE 4 and 5?
15:29:18 <Kevin_Kofler> Is kde-l10n going away?
15:29:35 <dvratil> Kevin_Kofler:  not sure, I assume kde-l10n will contain only translations of KDE 4 applications
15:29:35 <heliocastro> We can redirect where kde pick their translations, no ?
15:30:32 <Kevin_Kofler> I think we should probably wait for the Applications 14.12 prereleases that are going to be tagged this week.
15:30:46 <dvratil> ok
15:30:59 <Kevin_Kofler> See what upstream does to kde-l10n, before we spend time on solving a problem upstream may be solving for us.
15:31:16 <dvratil> ok, let's discuss this next week
15:32:22 <Kevin_Kofler> If upstream doesn't have a good solution, IMHO, we should do what I did for kde-i18n vs. kde-l10n, which is to write some scripts to list all the files/directories that conflict, then for each, blacklist the translation that doesn't match the code we ship.
15:32:42 <Kevin_Kofler> It's even easier now with kde-l10n vs. bundled in the package, because if the translation is bundled in the package, it's always the right one.
15:33:19 <Kevin_Kofler> The only drawback is that this means the Plasma 5 Copr needs to carry a different kde-l10n than stock Fedora (probably just a flag set, which would be always 1 in Rawhide too).
15:34:06 <Kevin_Kofler> But it's not worth spending our time on doing those scripts if upstream is dropping kde-l10n or reducing it to kdelibs only in 14.12.
15:35:16 <heliocastro> Again, what halt us to just install kf5 translation in other directory ?
15:36:59 <Kevin_Kofler> /usr/share/locale is a FHS standard directory.
15:37:18 <Kevin_Kofler> And it's stupid to install tons of kde-l10n translations for apps which then ship their own translations.
15:37:18 <heliocastro> but what about usr/share/local/kf5
15:37:27 <Kevin_Kofler> So -1 to the subdirectory.
15:37:40 <Kevin_Kofler> There's only one right translation for any given gettext domain.
15:38:08 <Kevin_Kofler> Conflicting stuff just needs to be blacklisted (and in fact, IMHO, we should have done this weeks ago).
15:38:44 <Kevin_Kofler> It's very easy to blacklist unwanted stuff from kde-l10n: http://pkgs.fedoraproject.org/cgit/kde-l10n.git/tree/kde-l10n.spec#n802
15:39:32 <dvratil> I was also thinking about introducing per-app sub-packages to kde-l10n, that would allow external packages (think Copr) to obsolete them, together with the app they are updating
15:40:42 <heliocastro> dvratil: I can help you on that.
15:40:45 <Kevin_Kofler> (e.g., we're blacklisting kpilot translations because kpilot was deprecated from kdepim and moved to a separate package (that has since become unmaintained upstream again, sadly), but some languages were still shipping conflicting old kpilot translations)
15:40:59 <Kevin_Kofler> dvratil: Ewww!!!
15:41:12 <Kevin_Kofler> kde-l10n is already per language.
15:41:28 <Kevin_Kofler> Per-app subpackages mean we have one package per (app,language) pair, i.e. quadratically many.
15:41:32 <rdieter> here, sorry I'm late
15:41:41 <Kevin_Kofler> #chair rdieter
15:41:41 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich jreznik ltinkl pino|work rdieter than
15:41:43 <dvratil> Kevin_Kofler:  it would be...a lot, yes :)
15:41:47 <Kevin_Kofler> I think those will be more than TeXLive!
15:42:05 <Kevin_Kofler> So IMHO, that approach does not scale.
15:42:42 <heliocastro> dvratil: Like this: http://svnweb.mageia.org/packages/cauldron/kde-l10n/current/SPECS/kde-l10n.spec?revision=787665&view=markup
15:42:44 <Kevin_Kofler> In addition, there would still need to be a kde-l10n-$language metapackage that Requires the subpackages, for upgrade paths, and so you'd still have to maintain a whitelist for the Requires.
15:43:03 <Kevin_Kofler> (The Obsoletes would not help that.)
15:43:51 * rdieter thinks some form of whitelist/blacklist is the way to go
15:43:52 <Kevin_Kofler> I think a blacklist (or even whitelist, that can be done too with just a bit more scripting) that works on the CMakeLists.txt files (like the existing blacklisting that we already do) is the much simpler solution.
15:44:27 <rdieter> we're not planning on shipping both kde4 and kf5 versions of (most) apps, so shipping only one appropriately makes sense
15:44:47 <Kevin_Kofler> It's even possible to do the blacklisting this way: http://pkgs.fedoraproject.org/cgit/kde-i18n.git/tree/kde-i18n.spec#n701
15:44:54 <rdieter> keeping track of that isn't fun, but neither is any other approach fun either
15:44:57 <Kevin_Kofler> but it's better to do it in CMakeLists.txt.
15:45:23 <Kevin_Kofler> (KDE 3 used autocrap which I was too lazy to deal with, so I did that. ;-) )
15:47:09 <rdieter> do we have any bugs yet tracking the translation/conflicts ?
15:47:25 <rdieter> or is that something to worry about later, once plasma5 is introduced into rawhide?
15:47:59 <Kevin_Kofler> I was suggesting to wait a week to see what upstream is doing to kde-l10n with the Applications 14.12 release.
15:48:03 <dvratil> its a problem for my Copr, as people can't have both KDE 4 and Plasma 5 apps localized
15:48:07 <Kevin_Kofler> They're preparing the first prelease now.
15:48:55 <dvratil> but I agree, let's discuss this next week when we know how the tarballs will look like
15:49:08 <dvratil> I guess the only one who knows is tosky, who's not here :)
15:51:07 <Kevin_Kofler> #info Deferred to next week, waiting for what upstream is doing to kde-l10n in 14.12.
15:51:17 <Kevin_Kofler> #topic System CLucene support in Qt Assistant
15:51:40 <Kevin_Kofler> So I worked on the patches, and according to rdieter, they seem to work now.
15:51:47 <Kevin_Kofler> So, how do we proceed with those?
15:52:29 <Kevin_Kofler> The current status is: Qt 4 uses the bundled CLucene in Fedora 19, 20 and 21. In Rawhide, I made it use the system CLucene, not sure whether anybody tested it yet.
15:52:47 <rdieter> I forget, is qt5-qttools-5.3.x fixed or not?  iirc, no.
15:52:49 <Kevin_Kofler> Qt 5 tries to use the system clucene09 in Fedora 19, 20 and 21, but it doesn't work. It should be fixed in Rawhide.
15:53:08 <rdieter> if not, let's wait until 5.4.0 lands
15:53:10 <Kevin_Kofler> I haven't done any fixed 5.3.x builds yet, indeed.
15:53:18 <Kevin_Kofler> But I did the patch against 5.3.2.
15:53:36 <Kevin_Kofler> So from the Qt side, it's just a matter of replacing the patch with the one in master.
15:53:54 <rdieter> Kevin_Kofler: if you want to do it now with 5.3.2, I'm fine with that.  otherwise, I'll handle it later with 5.4.0
15:54:27 <rdieter> batch updates of qt5, qt, and... one other thing depended on clucene09, zarafa ?
15:54:44 <Kevin_Kofler> What needs to be done is merging clucene09 from Rawhide and rebuilding zarafa against it.
15:54:57 <Kevin_Kofler> And qt5-qttools needs to be bootstrapped, because of the soname bump.
15:55:32 <Kevin_Kofler> Another good question is, has anybody tested zarafa with the refcounted clucene09 yet?
15:55:51 <Kevin_Kofler> It SHOULD work, but still, somebody should test it…
15:56:06 <Kevin_Kofler> The problem is, I have no clue about Zarafa and definitely don't want to set an instance up.
15:56:12 <Kevin_Kofler> (It's a webmail/groupware thingy.)
15:58:51 <rdieter> contact their maintainers when prepping the update , and ask for feedback/testing then
15:59:54 <Kevin_Kofler> The Zarafa maintainer is Robert Scheck, who also maintains clucene09.
16:00:33 <Kevin_Kofler> So he already knows about the plans, but I'm not sure what if any testing he has done on the Zarafa side of things.
16:06:28 <Kevin_Kofler> rdieter: And for Qt 4, do we want to enable the system-clucene support there too?
16:06:43 <Kevin_Kofler> (Of course, we can do it only when or after updating clucene09.)
16:07:00 <Kevin_Kofler> I have it in Rawhide and it should be working there.
16:07:20 <rdieter> yes, it's worth trying at least
16:07:29 <rdieter> (assuming testing goes ok)
16:07:31 <Kevin_Kofler> The advantage would be to share the same clucene09 between the Qt 4 and 5 Assistant (~1 MiB saved).
16:10:32 <heliocastro> Kevin_Kofler: Tihs isn't the only advantage
16:10:45 <heliocastro> single point of failure, if any bug appears
16:11:16 <rsc> Kevin_Kofler: To be honest, I don't know how to test that change.
16:11:28 <Kevin_Kofler> Well, there's still the QtCLucene wrapper layer, which is 99% copy&paste between Qt 4 and 5, but which can't be shared/unbundled (because it's built against a different Qt).
16:11:30 <rdieter> Kevin_Kofler: interesting, I have zarafa installed on my f20 box, and I don't see any clucene09-core dependency
16:11:48 <Kevin_Kofler> rdieter: It's a dependency only of the indexer for search.
16:11:57 <rsc> rdieter: only zarafa-search depends on clucene09
16:12:21 <rdieter> ah, ko
16:12:22 <Kevin_Kofler> rsc: Well, does indexing/searching still work after you update clucene09 and zarafa?
16:12:23 <rdieter> ok
16:12:27 <Kevin_Kofler> If it works, we're fine.
16:12:55 <Kevin_Kofler> (I don't see why it wouldn't work, but you know, a software engineer's famous last words. ;-) )
16:13:10 <rdieter> I'll include a new zarafa build in the qt5 copr for testing
16:15:06 <Kevin_Kofler> rdieter: OK
16:15:23 <Kevin_Kofler> Maybe you can also include a qt (4) build with system-clucene?
16:15:33 <rdieter> Kevin_Kofler: yes, will do
16:15:38 <Kevin_Kofler> (Just use the SRPM from Rawhide.)
16:20:14 <Kevin_Kofler> #topic Open discussion
16:20:22 <Kevin_Kofler> So, is there anything else to discuss?
16:20:26 <Kevin_Kofler> We're already over time.
16:21:29 <Kevin_Kofler> Looks like not. :-) So, thanks all for coming, goodbye!
16:21:31 <Kevin_Kofler> #endmeeting