15:04:36 <rdieter> #startmeeting kde-sig
15:04:37 <zodbot> Meeting started Tue Aug 25 15:04:36 2015 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:04:41 <rdieter> #meetingname kde-sig
15:04:41 <zodbot> The meeting name has been set to 'kde-sig'
15:04:45 <rdieter> #topic roll call
15:04:52 <rdieter> hi all, friendly kde-sig meeting, who's present today?
15:04:55 * jgrulich is present
15:04:56 <dvratil> hola
15:04:59 <Kevin_Kofler> Present.
15:05:02 <heliocastro> hey
15:06:24 <tosky> hi
15:07:55 <danofsatx> I'm here
15:08:00 <rdieter> #info rdieter jgrulich dvratil Kevin_Kofler heliocastro tosky danofsatx present
15:08:02 * pino|work is there too
15:08:09 <rdieter> #chair jgrulich dvratil Kevin_Kofler heliocastro tosky danofsatx pino|work
15:08:09 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich pino|work rdieter tosky
15:08:12 <rdieter> #info pino|work present
15:08:19 <rdieter> welcome everyone
15:08:21 <rdieter> #topic agenda
15:08:25 <rdieter> what to discuss today?
15:08:36 <dvratil> I can give KF5/P5 update
15:08:47 <rdieter> heliocastro mentioned earlier (in #fedora-kde)... kde4 deps in plasma pkgs
15:09:11 <heliocastro> I want discuss the f22 specific bug of theme plugin
15:09:28 <rdieter> heliocastro: as part of same topic, or separately ?
15:09:37 <heliocastro> different topic
15:09:39 * rdieter assumes separate, ok
15:10:10 <rdieter> than: ping
15:10:10 <zodbot> rdieter: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
15:10:33 <rdieter> #topic kf5/p5 status update
15:10:36 <rdieter> dvratil: go ahead
15:11:01 <dvratil> F21: KF5 5.13 built in f21-kde tag, will submit bodhi update
15:11:18 <dvratil> F22: KF5 5.13 built, finishing Plasma 5.4, will submit bodhi update today
15:11:37 <dvratil> F23: KF5 5.13 built, Plasma 5.4 built, will submit bodhi update today
15:11:56 <dvratil> rawhide: KF5 5.13 built, Plasma 5.4 built, started building Apps 15.08 today
15:12:00 <rdieter> for f22/f23, that will also require at least kio-extras-15.08, right ?
15:12:11 <dvratil> yes, that's going to be included
15:12:23 <rdieter> the rest we can probably do later and/or separately
15:12:39 <dvratil> I also posted some package reviews for the new KDE PIM split and I am currently finalizing Copr (dvratil/kdepim) to test it
15:12:51 * jgrulich is slowly working on them
15:13:03 <dvratil> if you have nothing to do, feel free to do some package reviews (jgrulich already started with some, thanks!)
15:13:50 <rdieter> .bug 1135103
15:13:53 <zodbot> rdieter: Bug 1135103 Plasma 5 Tracker - https://bugzilla.redhat.com/1135103
15:13:57 <jgrulich> well, it should be pretty straightforward as you use same template for all kf5 packages, you have just wrong license everywhere
15:13:59 <rdieter> some are on ^^ tracker
15:14:12 <rdieter> are the others tracked somewhere too?
15:14:12 <dvratil> all should be on the tracker
15:14:32 <dvratil> all the new pkgs are tracked there
15:14:40 <dvratil> jgrulich:  yep, I need to fix my script :-P sorry about that
15:14:45 <rdieter> I don't see them on the plasma5 one, maybe kde-reviews?
15:15:01 <dvratil> ah, sorry
15:15:02 <Kevin_Kofler> dvratil: Have you looked into KNode?
15:15:05 <dvratil> yes, kde-reviews
15:15:09 <jgrulich> dvratil: np, at least it looks I reviewed them properly :)
15:15:13 <dvratil> because they are not plasma5 but Applications
15:15:19 <rdieter> .bug 656997
15:15:21 <rdieter> I see them here ^^
15:15:23 <zodbot> rdieter: Bug 656997 kde-related package review tracker - https://bugzilla.redhat.com/656997
15:15:33 <dvratil> Kevin_Kofler:  not yet, I need to build the new PIM first, then I'll look into it
15:15:45 <dvratil> I'll build and test everything in Copr first before pushing to Fedora, no worries ;)
15:15:53 <Kevin_Kofler> It's not clear to me how hard or easy it is to get KNode packaged without shipping a separate Akonadi (that KNode doesn't even really use, but gets dragged in indirectly according to ldd).
15:16:05 <Kevin_Kofler> We really don't want a compat-akonadi.
15:16:06 * rdieter would be interested in working on knode, but not until at least next week
15:16:17 <dvratil> I have pretty clear idea how to make it work
15:16:25 <dvratil> it should be OK
15:16:31 <Kevin_Kofler> We may have to revert to the kdepim-noakonadi fork, but that's really old.
15:16:42 <Kevin_Kofler> I hope dvratil can make the current version work.
15:16:50 <dvratil> kdepimlibs-compat (without Akonadi server, we don't need that), and knode package
15:17:00 <Kevin_Kofler> OK
15:17:10 <dvratil> we only need one tiny library from Akonadi server which I can build as part of the kdepimlibs-compat package
15:18:08 <Kevin_Kofler> Akonadi client lib?
15:18:22 * jreznik is around
15:18:50 <rdieter> #info jreznik present
15:18:52 <rdieter> jreznik: hi
15:18:56 <rdieter> #chair jreznik
15:18:56 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich jreznik pino|work rdieter tosky
15:19:06 <dvratil> Kevin_Kofler:  Akonadi server shared lib, but that's just a detail, let's not waste time on that
15:19:11 <dvratil> let's move on
15:19:23 <rdieter> moving on...
15:19:39 <rdieter> #topic f22 theme plugin issue(s)
15:19:52 <rdieter> heliocastro: your turn
15:20:00 <heliocastro> rdieter: kk
15:20:04 <heliocastro> Ok, the bug
15:20:46 <heliocastro> After some investigation from me and Thiago, we found out that some, not all, f22 qt systray apps crash becaud platformintegration
15:21:08 <heliocastro> The issue not comes from qt5, but kde code itself dealing with something on the config dir
15:21:18 <heliocastro> A new user just works
15:21:32 <heliocastro> And is not breeze at all the issue
15:21:37 <dvratil> so broken config maybe?
15:21:44 <heliocastro> Good chance
15:22:05 <heliocastro> At this moment, we have two ones among us, myine and jgrulich, that can be traced
15:22:16 <Kevin_Kofler> dvratil: (Sorry, was pulled off for a moment.) I think we really need this going without any Akonadi at all, or it will break when Akonadi 2 comes.
15:22:32 <heliocastro> But several users are reporting the issue now
15:22:41 <dvratil> Kevin_Kofler:  I'll explain on #fedora-kde after meeting
15:22:53 <Kevin_Kofler> dvratil: OK
15:22:55 <heliocastro> The effective bug is this one: https://bugzilla.redhat.com/show_bug.cgi?id=1255902
15:23:35 <rdieter> .bug 155902
15:23:37 <zodbot> rdieter: Bug 155902 After upgrading to kernel 2.6.9-5.0.5 USB hubs no longer work - https://bugzilla.redhat.com/155902
15:23:38 <Kevin_Kofler> Is this also the infamous bug that is the reason why firewalld's firewall-applet uses PyQt4 for now?
15:23:39 <rdieter> .bug 1255902
15:23:40 <rdieter> arg
15:23:41 <zodbot> rdieter: Bug 1255902 crash qt5 apps with QSystemTrayIcon context menu - https://bugzilla.redhat.com/1255902
15:23:49 <rdieter> Kevin_Kofler: maybe
15:24:15 <heliocastro> Kevin_Kofler: Easy to test, just move the plugin temporarily
15:24:31 <rdieter> firewall-applet wasn't crashing, but menus indeed weren't working at least (iirc)
15:25:49 <heliocastro> I'm open to ideas, because this bug will be vanished on f23
15:26:21 <heliocastro> And now we have many users on f22 reporting it
15:26:34 <Kevin_Kofler> Rebuilding didn't help, right?
15:26:38 <heliocastro> I have a list of three apps affected for now, systray example, cutegram and transmission-qt
15:26:48 <heliocastro> Rebuilding didn't help
15:26:58 <heliocastro> I will wait the .13 update
15:27:08 <Kevin_Kofler> I'd try compiling the platform plugin with -O0 for testing, and maybe also the relevant parts of Qt.
15:27:23 <Kevin_Kofler> Of course, -O0 is slow as bloated, we don't want to ship it that way.
15:27:29 <heliocastro> Kevin_Kofler: I already have full qt debug build, is not affected
15:27:33 <Kevin_Kofler> But if -O0 fixes the issue, we know that it is a compiler optimization issue.
15:27:36 <heliocastro> platform will be next one
15:27:54 <Kevin_Kofler> I want only -O2 changed to -O0.
15:28:06 <heliocastro> I know the drill
15:28:08 <Kevin_Kofler> And if that helps, specific -fno-* for various compiler optimizations.
15:28:56 <heliocastro> But that's it on the bug, this is not a blocker for Qt that some tried to apply, but is an issue for existent release
15:29:14 <Kevin_Kofler> If we know what exact file is miscompiled, I'd also like to have a look at the GCC tree and RTL dumps for that file.
15:29:54 <Kevin_Kofler> Speaking of weird compiler bugs, there's also that KDevelop crash that we haven't figured out yet either.
15:30:06 <Kevin_Kofler> For all I know, it could be the same GCC bug, or a different one, I have no idea.
15:30:42 <heliocastro> rdieter: i think we can move on for next topic
15:30:47 * than is present
15:31:03 <rdieter> #info than present
15:31:31 <rdieter> #topic kde4 deps in plasma5 packages, e.g. kde-style-breeze
15:31:49 <rdieter> We'd discussed this a bit prior to the meeting in #fedora-kde
15:32:04 <rdieter> heliocastro: do you have more to say on the matter?
15:32:31 <heliocastro> Well, no, since you did a good reasonable explanation on qt4 issues
15:33:08 <heliocastro> But still, i think some arrangement can be possible to move the dependency on core packages
15:33:36 <heliocastro> Let's explain the issue here to keep records:
15:34:16 <heliocastro> Today plasma-desktop brings kde4-style-breeze as a direct dependency, leading indirectly to have partial kde4 base libraries installed
15:34:37 <heliocastro> This is required for Qt4/kde4 applications to use the plasma 5 theming
15:35:24 <Kevin_Kofler> Yes, and the alternative options would be:
15:35:33 <heliocastro> The issue comes that kde4 libraries and utilities are taking precedence on 5 utilities, leading main system to fail to deal properly with resources like global shortcuts, or even a proper dr. konqi call
15:35:42 <Kevin_Kofler> * move the dependency to the Qt 4 package → would force it onto all users, even non-KDE ones
15:36:02 <heliocastro> Not really feasible
15:36:04 <Kevin_Kofler> * remove the dependency → leaves Plasma users without theming integration for Qt in some cases (e.g. upgrades)
15:36:12 <rdieter> well, we could move it to kdelibs
15:36:15 <Kevin_Kofler> * use a conditional dependency → not possible before at least F24
15:36:29 <rdieter> but the ideal fix is to wait for soft/rich depenedencies to be fully supported
15:36:53 <heliocastro> rdieter: I think different
15:36:54 <Kevin_Kofler> Moving it to kdelibs is a hack that has is wrong in 2 ways.
15:37:18 <Kevin_Kofler> It doesn't help for Qt-only apps in Plasma 5, and it still forces the dep for kdelibs 4 apps in non-Plasma.
15:38:07 <rdieter> well, the odds of someone who's already running plasma5 to have Qt4 but *not* kdelibs, is... small.
15:38:15 <rdieter> but sure. :)
15:38:35 <rdieter> and for non-plasma, meh, it's a single (very) small package
15:38:48 <heliocastro> Yes, agreed
15:39:23 <heliocastro> If we follow this argument, we will ave the dependency ad eternum
15:39:37 <heliocastro> Because we "always have a user" with qt4 app
15:40:10 <heliocastro> If we did some analogy, we need have breeze for kde3
15:40:15 <heliocastro> or qt3
15:40:22 <heliocastro> because someone must be using 3
15:40:24 <heliocastro> etc..
15:40:25 <Kevin_Kofler> We will need the conditional dependency ad eternum.
15:40:38 <Kevin_Kofler> The unconditional one is a workaround until that is supported (it's already there in Rawhide's RPM).
15:40:41 <heliocastro> NO, it need to be in a different package
15:41:25 <Kevin_Kofler> (plasma-desktop + qt) → kde4-style-breeze
15:41:34 <Kevin_Kofler> so there are only 2 possible ways to put it:
15:41:55 <Kevin_Kofler> A. plasma-desktop.spec (or -workspace): Requires: kde4-style-breeze IF qt
15:42:14 <Kevin_Kofler> B. qt.spec Requires: kde4-style-breeze IF plasma-desktop (or -workspace)
15:42:34 <Kevin_Kofler> (syntax subject to change, I need to check what the decision on the final syntax is/was/will be)
15:42:57 <rdieter> again, I personally don't think it worth worrying too much about the case of user having plasma5 and Qt4, but *not* kdelibs-4.x, but that's just me
15:42:57 <Kevin_Kofler> In any other package, it wouldn't make sense.
15:43:30 <Kevin_Kofler> As for Qt 3, I'd welcome a breeze-qt3 backport. :-)
15:43:31 <tibbs|w> FYI, don't try to actually use rich deps in Fedora packages.
15:44:01 <rdieter> tibbs|w: understood, these are all theoretical discussion about when rich deps are supported
15:44:02 <Kevin_Kofler> I tried backporting Oxygen, but I decided that the way I was going at it was wrong and I didn't have time to retry differently.
15:44:19 <tibbs|w> Yeah, just making sure nobody tries to actually do a build with them.
15:44:23 <Kevin_Kofler> tibbs|w: May I ask why not?
15:44:37 <tibbs|w> Because it doesn't actually work through the pipeline.
15:44:46 <tibbs|w> Let the tooling catch up.
15:45:01 <Kevin_Kofler> For soft deps, the way we got some support in was that people just used them despite FPC saying not to, then eventually the OK came.
15:45:14 <tibbs|w> Banned by packaging guidelines as soon as I get around to actually putting that language into the guidelines.
15:45:33 <tibbs|w> And not least, because infra, the dnf developers and releng say not to.
15:45:35 <rdieter> Kevin_Kofler: soft deps are ok
15:45:39 <rdieter> rich deps, not
15:45:58 <Kevin_Kofler> Soft deps are OK *now*. People used them before they were officially OK. :-)
15:46:18 <tibbs|w> And they should not have.  Doesn't make it OK in any case.
15:46:21 <rdieter> rich deps are different, will cause problems (soft deps were mostly harmless)
15:46:24 <tibbs|w> Sorry to derail your meeting.
15:46:50 <Kevin_Kofler> In any case, this dependency issue cannot really be fixed without rich deps.
15:46:59 <Kevin_Kofler> So as long as we can't use them, we can't fix the issue.
15:47:18 <tibbs|w> Which is why it will be great when they work.  They don't work now.
15:47:19 <rdieter> Well, it could be mitigated a bit using soft deps, but using rich deps would be better
15:47:22 <tibbs|w> So don't use them.
15:47:27 <Kevin_Kofler> (and this implies that we will never be able to get this fixed in F22 and F23)
15:47:58 <Kevin_Kofler> As long as the tooling doesn't like the rich deps, we have to leave with the unconditional dep we have now.
15:48:02 <Kevin_Kofler> *live
15:48:11 <rdieter> anyway, anyone with other comments?  else, we can move on
15:50:10 <heliocastro> Yes
15:50:26 <rdieter> #topic open discussion
15:50:27 <heliocastro> If we wil not fix dependency way,
15:50:41 <heliocastro> We need fix the boot
15:50:45 <heliocastro> and the tools loading
15:51:47 <Kevin_Kofler> The bugs caused by those packages need to be fixed no matter what.
15:51:59 <Kevin_Kofler> As I already explained on #fedora-kde.
15:52:36 <heliocastro> Ok, for the open topic, i will be soon updateing the solution idea of splitting startkde
15:52:41 <rdieter> I guess in a constructive vein... are those bugs you mention actively being worked on?  If so, by who?
15:53:21 <Kevin_Kofler> heliocastro says there are bugs.
15:53:45 <heliocastro> 1 - khostkeys from kde4 comes ahead on khotkets 5
15:53:58 <rdieter> heliocastro: thanks for the startkde splitting, seems upstream is receptive to the idea
15:53:59 <heliocastro> Them some qt5 apps not receiving shortcuts
15:54:14 <heliocastro> 2 - dr konqi
15:54:27 <heliocastro> Dr konqi on 5 is never shown, because the intercepted one is 4
15:54:37 <heliocastro> So we just have apps crashing and vanishing
15:54:40 <rdieter> are these bugs documented (either downstream or upstream bugzilla)?
15:54:41 <heliocastro> no possible way to test
15:54:50 <heliocastro> rdieter: Not yet
15:54:55 <heliocastro> I need document
15:55:00 <rdieter> ok, please do, thanks :)
15:55:14 <heliocastro> So, backing to startkde
15:55:17 <rdieter> (else I personally won't remember any details)
15:55:34 <heliocastro> There's good receptivity, martin mentioned that could work
15:56:06 <heliocastro> The two startkde ones ( startplasma ) was created because differences on wayland/x11 stars
15:56:08 <heliocastro> starts
15:56:30 <heliocastro> so, i need tweek the idea to assimilate a way to start one or another with a sequence
15:56:39 <heliocastro> A little more complex, but doable
15:56:48 <heliocastro> I hope have it done on the weekend
15:57:01 <rdieter> woo
15:57:25 <heliocastro> So farm nobody was against it anyway
15:57:31 <heliocastro> #so far
15:57:41 * heliocastro is not typing well again :-P
15:57:52 <heliocastro> But this is an update
15:58:13 <rdieter> heliocastro: thanks
15:59:29 <rdieter> anything else for today?
15:59:40 <Kevin_Kofler> Is there any explanation for the creeping size increase in F21 updates?
16:00:04 <Kevin_Kofler> Kannolo increased from ~720 MiB to ~795 MiB without me changing anything in the package set.
16:00:40 * heliocastro need leave
16:02:07 <pino|work> rdieter: close the meeting?
16:02:24 <rdieter> Kevin_Kofler: ouch
16:02:28 <rdieter> ok, let's wrap up
16:02:31 <rdieter> thanks everyone!
16:02:32 <danrik> rdieter: nope
16:02:38 <rdieter> #endmeeting