15:02:00 <rdieter> #startmeeting kde-sig
15:02:00 <zodbot> Meeting started Tue Mar 15 15:02:00 2016 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:00 <zodbot> The meeting name has been set to 'kde-sig'
15:02:03 <rdieter> #meetingname kde-sig
15:02:03 <zodbot> The meeting name has been set to 'kde-sig'
15:02:06 <rdieter> #topic roll call
15:02:12 <rdieter> hi all, friendly kde-sig meeting, who's present today?
15:02:14 <lupinix> .hello lupinix
15:02:14 * jgrulich is present
15:02:15 <zodbot> lupinix: lupinix 'Christian Dersch' <lupinix@mailbox.org>
15:02:19 <than> present
15:02:24 <tosky> hi
15:02:26 <heliocastro> here
15:03:27 <rdieter> #info rdieter lupinix jgrulich than tosky heliocastro present
15:03:35 <rdieter> #chair lupinix jgrulich than tosky heliocastro
15:03:35 <zodbot> Current chairs: heliocastro jgrulich lupinix rdieter than tosky
15:04:39 <rdieter> #topic agenda
15:05:01 <rdieter> ok, stuff to discuss today: mentioned earlier in #fedora-kde:   Qt5 for rhel/epel plans, Qt/Gtk integration test day
15:05:04 <rdieter> anything else?
15:06:02 * lupinix ← testing todays f24 compose quickly to see if there are any obvious problems to be discussed
15:06:21 <rdieter> k, let's get started...
15:06:27 <rdieter> #topic Qt5 for rhel/epel plans
15:06:32 <rdieter> jgrulich: go ahead
15:08:01 <jgrulich> ok, I'll make it short, we might bring Qt 5.6 into RHEL in the next release, but given that it's already provided in EPEL, I wanted to discuss/ask what to do about EPEL
15:08:32 * jreznik is here
15:08:41 <rdieter> ok, given epel policy of not duplicating/replacing anything in rhel, means that Qt5 will need to be removed from epel at that point
15:08:48 <rdieter> #info jreznik present
15:08:50 <rdieter> #chair jreznik
15:08:50 <zodbot> Current chairs: heliocastro jgrulich jreznik lupinix rdieter than tosky
15:09:04 <heliocastro> Agree with rdieter but raises one question
15:09:14 <heliocastro> 5.6.x will be enough for kde future plans ?
15:09:38 <tosky> well, at least for a while
15:09:41 <heliocastro> If we want to push plasma 5 on epel, what happens if we start to use 5.7.x
15:09:52 <tosky> for Frameworks for sure, and probably for most applications
15:10:02 <heliocastro> tosky: For a while until the qml compiler
15:10:05 <tosky> Plasma, probably jgrulich knows the plan better than me
15:10:07 <rdieter> heliocastro: plasma in epel isn't possible really, anyway
15:10:19 <heliocastro> rdieter: Because wayland ?
15:10:24 <rdieter> since it replaces kde4
15:10:51 <rdieter> so only possibility for rhel/plasma is copr (or equivalent)
15:10:55 <jreznik> copr is the answer
15:10:59 <heliocastro> Ok
15:11:01 <tosky> and Software Collections? Anyway, that's for the future future
15:11:15 <rdieter> but brining kf5 to epel is still desirable
15:11:22 <lupinix> the same way as with f21 @copr? worked quite nice
15:11:29 <jreznik> tosky: again, copr would be much easier...
15:11:51 <rdieter> tosky: maybe?  but that's even more work, not sure we'd want to commit to anything that big
15:12:24 <heliocastro> jreznik: Are you in charge of the Qt on rhel ?
15:12:27 <tosky> sure, just thinking aloud
15:12:45 <heliocastro> jgrulich: ^^
15:12:46 <jreznik> heliocastro: nope, at all
15:13:01 <heliocastro> jreznik: Wrong autocompletion
15:13:11 <jgrulich> heliocastro: I'll be the one doing it in case it's going to happen
15:13:42 <heliocastro> Ok, this makes me more relief that you won't create another special package
15:14:23 <rdieter> thanks to prior epel/copr Qt5 efforts, bringing it to rhel should be pretty easy (not much more than rebuilding)
15:14:32 <jgrulich> heliocastro: the packages would be probably identical to current Fedora ones, there is no reason to have different names or whatever
15:14:56 <heliocastro> Ok
15:16:04 <rdieter> anything else Qt5/rhel related?
15:16:24 <lupinix> will webengine be available there too?
15:16:43 <rdieter> or even webkit for that matter?
15:16:46 <rdieter> I'd guess: no
15:17:03 <heliocastro> rdieter: I think there's no choice, if they are goint toward customers
15:17:04 <rdieter> those may end up staying in epel
15:17:13 <jgrulich> lupinix: I don't think so, even qt5-qt3d or qt5-qtquickcontrols2 as those are technical previews
15:17:31 <rdieter> ok, looks like some mixture of rhel/epel will continue
15:17:36 <lupinix> so we are mostly talking about qt5-qtbase
15:19:53 <rdieter> jgrulich: let us know when/if plans solidify, and which qt5 modules will be affected?
15:20:36 <jgrulich> rdieter: will do
15:21:05 <rdieter> thanks, moving on...
15:21:09 <rdieter> #topic https://fedoraproject.org/wiki/Test_Day:2016-03-17_Qt_Gtk_Integration
15:21:19 <rdieter> Qt/Gtk integration test day, fyi ^^
15:22:01 <jgrulich> the test day covers adwaita-qt theme and qgnomeplatform, which doesn't work currently as it should, but I plan to look at it tonight so it's prepared for the test day
15:22:05 <rdieter> jgrulich: anything else worth mentioning?
15:23:34 <lupinix> cc
15:23:43 <lupinix> (wrong window)
15:24:13 <jgrulich> rdieter: that would be all I guess :)
15:24:35 <rdieter> thanks
15:24:42 <rdieter> #topic open discussion
15:24:51 <rdieter> anything else worth mentioning today?
15:25:09 <tosky> quick thing, if anyone want to try, I'm trying to resurrect BasKet
15:25:26 <rdieter> iirc, basket was pretty cool
15:25:41 <tosky> for now it's just a copr and only F23: https://copr.fedorainfracloud.org/coprs/tosky/basket/
15:25:51 <tosky> fail to build with GCC6, I have a fix sent upstream
15:26:18 <tosky> if you want to try, the plan is to go through the combined long processes of new packagers + resurrect dead package
15:26:46 <tosky> </message>
15:27:10 <lupinix> todays f24 compose seems to work fine :)
15:27:19 <rdieter> tosky: thanks, please holler in #fedora-kde or onlist when you have a pkg review ready
15:27:38 <tosky> sure, will do
15:28:03 <rdieter> fyi, I've been working on related updates over the past few days to drop hard kde4 dependencies in plasma packaging
15:28:27 <heliocastro> And we ( at least me ) thank you for that
15:28:41 <rdieter> so now the kde4 deps, kde-style-breeze and kde-platform-plugin, are handled via soft deps and comps
15:29:16 <lupinix> observation with todays compose: qupzilla is less stable @f24 than on f23 with copr, so we should call it "technology preview" so far :D
15:29:31 <jreznik> I probably missed it on #fedora-kde but what are the plans with qt 5.6 as release is tomorrow
15:29:31 <lupinix> rdieter: yes, thank you for erasing these hard dependencies
15:29:36 <rdieter> using rich dependencies would have been ideal, but couldn't , since those are incompatible with yum
15:31:01 <lupinix> :( so thats why i got messages from koschei and boshi?
15:31:05 <lupinix> *bodhi
15:31:32 <rdieter> yes, koschei dep checking still uses yum I believe
15:31:46 <rdieter> (if it complained of broken deps)
15:31:51 <lupinix> yes
15:32:05 <mizdebsk> koschei uses hawkey (the same lib as used by dnf), but koschei is deployed on rhel 7, which has old versions of these libs
15:32:24 <mizdebsk> i'm looking to updating them, which would fix koschei issue with rich deps
15:32:27 <rdieter> mizdebsk: ah, so different problem
15:32:31 <rdieter> thx
15:33:24 <rdieter> anyway, point is that various infrastructure bits are either still yum-based or are not-yet-fully-compatible with rich dependencies
15:33:50 <lupinix> and many users still use yum
15:33:57 <rdieter> that latter part is very fixable
15:34:22 <rdieter> lupinix: <nod>.  fedora will probably have to choose some cut-off for supporting yum though, it cannot be indefinite
15:34:45 <lupinix> yes
15:36:12 <lupinix> another thing: what is the current state of these dbus issues?
15:36:12 <rdieter> well, it could be indefinite, but I think that would be less ideal
15:37:00 <rdieter> lupinix: with latest builds (and patches), all known issues should be fixed
15:37:07 <rdieter> unless there are some new/unknown ones
15:37:24 <lupinix> ok, thx
15:38:03 <rdieter> heliocastro hit some plasmashell startup problems recently, for example, but it's unclear what the cause is (could be dbus related)
15:38:26 <lupinix> what kind of startup problems?
15:38:45 <rdieter> plasmashell didn't fully start, that's all
15:39:03 <heliocastro> Yep
15:39:12 <rdieter> and the backtrace was't conclusive
15:39:50 <rdieter> https://paste.kde.org/pine1secv  in case anyone else can make more sense from it than I
15:40:45 <lupinix> hmm, i never got this right now
15:40:56 <rdieter> me either
15:41:22 <lupinix> on one machine plasma doesn't start completely, but works on all others
15:41:36 <lupinix> (talking about f24 live)
15:41:51 <rdieter> f24 still has pending updates, mind you
15:41:58 <rdieter> not included in f24-live yet
15:42:19 <rdieter> https://bodhi.fedoraproject.org/updates/FEDORA-2016-13bc6572ac
15:42:26 <lupinix> so issue is very new?
15:42:51 <rdieter> new'ish, since qt 5.6.0-rc I think
15:43:30 <lupinix> rc is already on live
15:43:40 <lupinix> 5.6.0-0.38.rc.fc24
15:43:57 <rdieter> Qt subtly changes how dbus events are handled, and it resulted in some libs/applications relying on the old (arguably buggy) behavior to now deadlock
15:45:20 <rdieter> 5.6.0-0.41 includes some candidate fixes for Qt5-internal issues, and the referenced plasma-workspace build includes an upstream fix to avoid using synchronous (blocking) dbus calls during startup
15:48:26 <rdieter> .bug 1317618
15:48:27 <zodbot> rdieter: Bug 1317618 Black screen after logout from KDE - https://bugzilla.redhat.com/1317618
15:48:34 <rdieter> bug tracking it ^^
15:48:50 <heliocastro> rdieter: This fixes are already on my recent submitted final qtbase ?
15:48:59 <rdieter> heliocastro: yes
15:49:10 <heliocastro> :-/
15:49:13 <rdieter> 5.6.0-0.41 builds and newer
15:51:28 <rdieter> heliocastro: just to rule out other issues, what video driver do you use?  use multiple monitors?
15:51:42 <rdieter> if intel or yes, then we can try other things
15:53:04 <heliocastro> nope, nvidia
15:53:07 <heliocastro> 3 screens
15:53:16 <heliocastro> At home, single screen intel works perfectly
15:53:25 <rdieter> heliocastro: ok, see if it's reproducible with 1 screen only
15:53:41 <heliocastro> Will do after the meeting
15:55:46 <rdieter> anything else before we close the meeting?
15:56:10 <heliocastro> nope for me
15:56:18 <lupinix> nope
15:56:56 <lupinix> well, maybe small announcement
15:57:16 <lupinix> astronomy spin based on plasma spin is finally on its way for f24
15:57:27 <rdieter> \o/
15:57:51 <heliocastro> congrats
15:58:19 <lupinix> thx :)
15:59:07 <rdieter> alright, thanks everyone for coming!
15:59:09 <rdieter> #endmeeting