15:07:09 <rdieter> #startmeeting kde-sig
15:07:09 <zodbot> Meeting started Tue Apr 14 15:07:09 2015 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:07:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:07:13 <rdieter> #meetingname kde-sig
15:07:13 <zodbot> The meeting name has been set to 'kde-sig'
15:07:17 <rdieter> #topic roll call
15:07:27 <rdieter> hi all, friendly kde-sig meeting about to start, who's present today?
15:07:30 <Kevin_Kofler> Present.
15:07:37 <danofsatx> .hello dmossor
15:07:38 <zodbot> danofsatx: dmossor 'Dan Mossor' <danofsatx@gmail.com>
15:07:54 <jgrulich> hi
15:07:58 * heliocastro here
15:08:02 <heliocastro> for sohrt time
15:08:26 * jreznik is here
15:08:34 * pino|work too
15:08:56 * dvratil is here
15:09:18 <rdieter> #info rdieter Kevin_Kofler  danofsatx jgrulich  heliocastro jreznik pino|work dvratil present
15:09:25 <rdieter> #chair  Kevin_Kofler  danofsatx jgrulich  heliocastro jreznik pino|work dvratil
15:09:25 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich jreznik pino|work rdieter
15:09:31 <rdieter> #topic agenda
15:09:37 <rdieter> what to discuss today?
15:09:50 * rdieter can give kde-apps-15.04.0 status update
15:10:00 <danofsatx> I've got a couple things for open floor.
15:10:18 <heliocastro> where's the screensaver ?
15:10:20 * heliocastro runs
15:10:34 <Kevin_Kofler> Crashes caught by ABRT instead of DrKonqi on F22. (Did we enable that on purpose, as planned? If yes, this needs to be disabled ASAP, so that the release doesn't ship that way. If no, we need to figure out why DrKonqi doesn't catch those crashes.)
15:10:35 <danofsatx> it's off saving less fortunate screens.
15:10:39 <rdieter> and ihatethecashew
15:11:15 <ltinkl> which is still there and called the toolbox :)
15:11:55 <rdieter> anything else?
15:11:57 <Kevin_Kofler> The ihatethecashew plasmoid is dead though, like all the other unported Plasma 4 plasmoids.
15:13:33 <rdieter> #topic kde-apps-15.04.0 status update
15:13:36 <tosky> hi, sorry
15:13:43 <rdieter> #chair tosky present
15:13:43 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich jreznik pino|work present rdieter tosky
15:13:51 <rdieter> #info toksy present
15:13:53 <rdieter> ha
15:13:56 <rdieter> tosky: hi
15:14:16 <rdieter> so, kde-apps-15.04.0, I've started in importing 15.04.0, it includes a lot of new stuff
15:14:21 <Kevin_Kofler> #undo
15:14:21 <zodbot> Removing item from minutes: INFO by rdieter at 15:13:51 : toksy present
15:14:22 <rdieter> including kde telepathy now
15:14:26 <Kevin_Kofler> #info tosky present
15:14:29 <Kevin_Kofler> :-)
15:15:07 <rdieter> dvratil: would you be interested/able to help work on the ktp bits?
15:15:38 <dvratil> I'm not sure I will be able to do much this week :(
15:15:44 <rdieter> I assume it would be easier to start with the ktp copr content, than to work from the kde4 stuff still in fedpkg master/ branch
15:15:57 <rdieter> dvratil: ok
15:16:15 <rdieter> then, any other volunteers for the kf5 ktp packaging task?
15:16:29 <rdieter> else, I'll add it to the end of my own todo list
15:17:03 <rdieter> added new libkface, libkgeomap libkeduvocdocument pkgs reviews over the past few days
15:17:20 <rdieter> and imported already, so can be included in 15.04 updates
15:17:22 <ltinkl> rdieter: I can help with the ktp reviews, if needed
15:17:51 <rdieter> ltinkl: I think all the requisite reviews are done, it's just a matter of updating the packaing .spec's for the newer kf5 versions
15:18:12 <ltinkl> rdieter: ok, I can give it a try, although no promise either, too much other stuff to do
15:18:32 <rdieter> np, like I mentioned, it's probably a good idea to work from dvratil's ktp copr
15:18:48 <rdieter> https://copr.fedoraproject.org/coprs/dvratil/ktp-5/
15:18:58 <rdieter> dvratil: good/bad idea?
15:19:34 <dvratil> +1 from me, the spec files are based on the KDE4 ones, but you won't have to deal with file names changes etc.
15:19:58 <rdieter> good
15:20:17 <heliocastro> _1
15:20:21 <heliocastro> +1
15:20:47 <rdieter> I suppose once the ktp-15.04 pkgs are imported, we can include those in the plasma-5 copr too
15:21:05 <Kevin_Kofler> +1 for starting from the Copr specfiles.
15:21:15 <dvratil> +1, but only for F21
15:21:15 <rdieter> dvratil: unless you'd rather keep using the separate copr?
15:21:33 <dvratil> no, I'm fine with merging it all to plasma Copr
15:21:33 <Kevin_Kofler> As for including the stuff in the plasma-5 Copr, I don't care either way.
15:21:45 <Kevin_Kofler> Do what you think is best there.
15:22:08 <dvratil> it's easier to tell people to just enable dvratil/plasma-5 copr instead of keeping list of coprs to add to get all apps
15:22:25 <rdieter> agreed
15:22:39 <rdieter> that's all I have about 15.04.0 , any other questions or comments?
15:23:27 <Kevin_Kofler> How do we handle libkomparediff2?
15:23:33 <Kevin_Kofler> (and kompare)
15:23:37 <rdieter> Kevin_Kofler: what about it
15:23:47 <Kevin_Kofler> They're now ported to KF5, but KDevelop still needs the KDE 4 libkomparediff2.
15:24:02 <rdieter> oh, yuck
15:24:10 <Kevin_Kofler> Do we just keep the stuff at 14.12 until KDevelop gets ported? (There aren't really any differences of note other than the KF5 port.)
15:24:31 <rdieter> ok, we need to complain to that libkomparediff2 maintainer... :)
15:24:37 <Kevin_Kofler> Or do we package both versions of libkomparediff2? (They SHOULD be able to coexist, but I'll admit that I haven't verified it.)
15:25:07 <Kevin_Kofler> When I had to make the decision what to ship, I was told KDevelop was targeting a release around the 15.04 timeframe.
15:25:14 <rdieter> Kevin_Kofler: I think I may have already updated libkomparediff2, but if it's a port, the build likely failed, so I'll just revert it for now, and review later
15:25:18 <Kevin_Kofler> As usual, promises are not kept.
15:25:42 <Kevin_Kofler> rdieter: kompare needs to be in sync with libkomparediff2 too, of course.
15:25:55 <rdieter> <nod>, we'll hold them both back
15:27:30 <rdieter> #action will hold kf5 libkomparediff2/kompare back until kf5 kdevelop lands (or we come up with a better plan)
15:27:59 * heliocastro still think go bold and use some beta stage code
15:28:09 <rdieter> kdevelop is a (the only?) reason I had to make a okteta4 compat pkg too
15:28:26 <Kevin_Kofler> So ship kdevelop 5 from git master? ^^
15:28:36 <heliocastro> We already using a half breed gcc, with c++ cuts and nobody seens to care
15:28:48 <heliocastro> So, why should we restrain ourselves ?
15:28:49 <Kevin_Kofler> Who cares whether it works, as long as it uses the current libraries? ;-)
15:28:52 <rdieter> I'm sure kdevelop upstream would *love* that
15:29:03 <dvratil> kf5 version of kdevelop has quite a lot of issues
15:29:21 * dvratil is using it, and it's pain :)
15:29:32 <heliocastro> Well, again, we have a unstable intel graphics driver, and again, nobody cares
15:30:27 <rdieter> speaking of the intel issue, I know there's an upstream bug tracking it, do we have any downstream (in bugzilla.redhat.com)?
15:30:27 <Kevin_Kofler> heliocastro: That GCC 5 + old libstdc++ ABI is quite tame (and some other distros ship that way too, in fact we may well be the first ones to ship the new ABI with F23). Remember the GCC 2.96 "release"? :-)
15:30:41 <ltinkl> it's a beta, chances are it'll be updated to a stable one later
15:30:45 <Kevin_Kofler> (That came from Red Hat, though some other distros either did their own 2.96 branch or used Red Hat's.)
15:30:55 <heliocastro> I'm just stating that we are working to make a perfect kde release on top of a imperfect base
15:31:14 * Kevin_Kofler wonders whether we'd be able to pull off something like that for KDevelop.
15:31:17 <heliocastro> And  since we are the frontend, anything wrong would be kde fault
15:31:20 <Kevin_Kofler> (Do our own release branch. ^^)
15:31:41 <ltinkl> heliocastro: right
15:32:25 <rdieter> that's not exactly a valid line of reasoning though.  when/if the base ever gets stable, then we'd still be stuck with unstable release on top of the "stable" base
15:33:50 <danofsatx> heliocastro: its not just Intel, but nouveau also.
15:33:53 <rdieter> I don't think it's worth inviting more trouble
15:34:11 <Kevin_Kofler> I think we agree to not ship a KDevelop snapshot.
15:34:38 <Kevin_Kofler> I just wanted to bring the possibility up, but I agree it's probably not a good idea.
15:34:47 <rdieter> <nod>, there's very little to gain from it, and lots of potential problems
15:35:32 <heliocastro> OK for not push
15:35:43 <rdieter> anything else, or move?
15:35:45 <rdieter> move on?
15:35:49 <heliocastro> move on
15:35:53 <danofsatx> mo
15:36:03 <than> present
15:36:08 <rdieter> #info than present
15:36:10 <rdieter> #chair than
15:36:10 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich jreznik pino|work present rdieter than tosky
15:36:24 <rdieter> #topic kf5 drkonqi, not working?
15:36:28 <danofsatx> can we unchair present? he's absent.
15:36:57 <rdieter> Kevin_Kofler: ?
15:37:47 <Kevin_Kofler> So, I see several ABRT reports for KF5 stuff coming in in F22.
15:38:00 <rdieter> #unchair present
15:38:00 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich jreznik pino|work rdieter than tosky
15:38:17 * danofsatx didn't know that was a command
15:38:21 <Kevin_Kofler> Is that due to an intentional change? (There was a plan to disable DrKonqi for F22, was that ever implemented?) Or why does DrKonqi not catch those crashes?
15:38:35 <rdieter> danofsatx: me either, until i just read the manual now :)  http://meetbot.debian.net/Manual.html
15:38:50 <danofsatx> manual, shmanual.
15:39:09 <rdieter> Kevin_Kofler: having abrt is intentional, but drkonqi should work too (and be prefered for kf5 apps that use it)
15:39:36 <Kevin_Kofler> The thing is, ABRT should only get the crashes DrKonqi is not catching.
15:39:51 <rdieter> right, so something isn't working right :-/
15:39:58 <Kevin_Kofler> So that leaves the question why those crashes get past it.
15:40:22 <Kevin_Kofler> Maybe stuff not using KCrash due to dependencies?
15:40:36 <Kevin_Kofler> In kdelibs4, it was the non-GUI stuff that did/could not use KCrash.
15:40:41 <rdieter> Kevin_Kofler: mind filing a bug first?  (then we can document findings in bz)
15:40:52 * jreznik is starting f22 vm
15:41:02 <Kevin_Kofler> Not sure what exactly I should put into that bug.
15:41:58 <rdieter> bug: kf5 drkonqi doesn't work
15:42:19 <Kevin_Kofler> Hmmm, looking at the bug list, it looks like the same issue as in kdelibs4, non-GUI stuff doesn't get handled.
15:42:38 <Kevin_Kofler> Upstream was talking all this time about enabling KCrash for non-GUI stuff, but it looks like they dropped the ball.
15:42:48 <danofsatx> I finally had drkonqi show up yesterday with a plasmashell crash.
15:42:51 <Kevin_Kofler> Or they didn't end up actually using it due to the dependendency reduction craze.
15:42:59 <Kevin_Kofler> *dependency
15:43:06 <rdieter> danofsatx: yay
15:43:08 <danofsatx> of course, abrt wasn't catching the crashes either...
15:43:11 <jreznik> seem to work for me in f22 beta rc1
15:43:26 <Kevin_Kofler> I guess it works for GUI apps, which means at least it's no worse than in KDE 4.
15:43:27 <jreznik> for gui, I read about non-gui now, sorry
15:43:31 <danofsatx> and of course, it was closed by KDE as a duplicate and "fixed upstream"
15:43:48 <Kevin_Kofler> I'm just sad they didn't follow through on the promise to also make it work for non-GUI KDE stuff.
15:44:35 <rdieter> so... false alarm?  anything else you propose we do?
15:44:45 <jreznik> works for non-gui too... just a quick test - SIGSEGV to kded5
15:44:54 <Kevin_Kofler> See e.g.
15:44:57 <Kevin_Kofler> .bug 1211075
15:45:00 <zodbot> Kevin_Kofler: Bug 1211075 [abrt] kf5-kglobalaccel: qt_message_fatal(): kglobalaccel5 killed by SIGABRT - https://bugzilla.redhat.com/1211075
15:45:05 <jreznik> kdeinit5 crashed then and I got dr konqui
15:45:06 <Kevin_Kofler> .bug 1211024
15:45:09 <zodbot> Kevin_Kofler: Bug 1211024 [abrt] kf5-kactivities: QXcbEventReader::run(): kactivitymanagerd killed by SIGSEGV - https://bugzilla.redhat.com/1211024
15:45:16 <Kevin_Kofler> etc.
15:45:23 <rdieter> I suspect apps may have to explicitly use drkonqi
15:45:56 <rdieter> or... repeated crashed apps get restarted with --no-crash-handler (or whatever it's called), so then abrt gets it eventually
15:46:00 <jreznik> Kevin_Kofler: I just tried kglobalaccel5 and again - dr konqui catched it
15:46:13 <jreznik> so by default, I'd say it works
15:47:03 <Kevin_Kofler> OK, so it looks like it's just the few odd cases where it doesn't work, which is even better than in KDE 4 times.
15:47:19 <jreznik> Looks like
15:47:29 <Kevin_Kofler> So I think we're all set here.
15:47:38 <rdieter> moving on then....
15:47:40 <rdieter> #topic open discussion
15:47:50 <rdieter> danofsatx ?
15:48:15 <rdieter> I believe you mentioned having something for open floor
15:48:53 <jreznik> any help with kde validation of rc2 is appreaciated :) https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC2_Desktop
15:49:28 <jreznik> the other thing I have - jzb asked for more detailed talking points about Plasma 5, I added there something for Beta, will do more for final
15:49:35 <jreznik> same for release notes
15:49:47 <jreznik> we should really sell plasma 5 more :)
15:50:25 <danofsatx> ok, one thing from the mailing lists - I thought we fixed SDDM integration with gnome-keyring in 4. is this a regression?
15:51:16 <Kevin_Kofler> As far as I know, that bug is still open, we "fixed" SDDM by disabling gnome-keyring-pam in its PAM configuration.
15:51:37 <rdieter> that's my understanding as well
15:51:41 <Kevin_Kofler> Making it work properly probably requires some low-level signal hacker.
15:51:43 <Kevin_Kofler> *hackery
15:51:50 <danofsatx> ok then...I was mistaken.
15:52:15 <rdieter> danofsatx: workaround is to use a different DM (ie, anything by sddm)
15:52:16 <danofsatx> and the other thing....am I the only one using Plasma 5 on multiple screens?
15:52:23 * satellit testing KDE disks-restore usb to HD atm RC2
15:52:41 <rdieter> ... anything but sddm, rather
15:52:45 <jreznik> satellit: out hero as always :)
15:52:49 <randomuser> danofsatx, I have, and can help test, but not recently
15:53:15 <rdieter> my only multidisplay box is (still) running f20
15:53:36 <jreznik> danofsatx: I'm using it on three screens :)
15:54:17 <danofsatx> Well, I'm seeing way too many issues which may be the result of the buggy Intel driver, but based on my usage Plasma 5 is not ready for prime time. Single displays, sure, but as soon as you add a second or third, or constantly switch between two and one (like docking a laptop), plasmashell locks up.
15:55:07 <jreznik> danofsatx: I don't see any lockups, Intel, 1 internal hidpi, two external
15:55:10 <jreznik> full hd
15:55:14 <danofsatx> I thought it was just me, but I have a friend that tried it with an NVIDIA chipset and  nouveau, and he had the same problems.
15:55:23 <rdieter> danofsatx: if it's the dri lockup, that's (still) all the driver
15:55:48 <danofsatx> but, like heliocastro said, Plasma is the DE, so it is going to get blamed.
15:55:52 <jreznik> I have some issues, with kscreen mostly, there's still that undock crash bug but it's definitely better now
15:56:04 <rdieter> danofsatx: nouveau may or may not have the same code path, so if you can get a backtrace from your friend, that would be helpful.
15:56:19 <danofsatx> especially when neither drkonqi or abrt catch these crashes and submit a useful backtrace or explanation to the user.
15:56:36 <rdieter> it's not a crash, it's a hang/deadlock
15:56:46 <danofsatx> true...
15:56:55 <rdieter> harder to catch those :-/
15:58:42 <jreznik> danofsatx: are you able to ssh to that machine?
15:58:47 <Kevin_Kofler> "killall -SIGABRT processname" can give you a backtrace for a soft lockup.
15:58:59 <Kevin_Kofler> It doesn't help if it's a hardware-level lockup due to some nasty driver bug.
15:59:10 <rdieter> Kevin_Kofler: nice, I'll try to remember that
15:59:11 <Kevin_Kofler> (or a lockup in some places of the kernel, where userspace scheduling is blocked)
15:59:17 <danofsatx> sometimes. The last time it locked up, I had ssh for about 2 minutes before the entire machine went into lockup.
16:00:05 <rdieter> it's happened to me maybe 3 times now, fwiw, restarting plasmashell usually helps, but it subjectively feels slower until I reboot though
16:00:11 <Kevin_Kofler> danofsatx: Hardware-level lockups are nasty.
16:00:28 <danofsatx> I know they are, which is why they need to be fixed.
16:00:28 <Kevin_Kofler> Another case where you can't do much is the swapping death.
16:00:54 <danofsatx> https://bugzilla.redhat.com/show_bug.cgi?id=1209245
16:00:56 <Kevin_Kofler> (OOM putting the machine into a livelock not doing anything other than swapping.)
16:01:12 <danofsatx> he at least got a segfault out of it. I didn't even get that much.
16:01:25 <Kevin_Kofler> There too, it may not be possible to stop the madness without a hard reset.
16:02:14 * jreznik has to leave
16:03:45 <rdieter> any last thoughts/comments before ending the meeting?
16:03:51 <danofsatx> my question is this - where do we apply the pressure to get this fixed?
16:04:17 <rdieter> danofsatx: to the maintainers of the affected components
16:04:35 <rdieter> so far, we have the intel bug, but only an upstream bug, nothing downstream (yet)
16:04:57 <rdieter> we have 1209245, but that backtrace isn't great (missing -debuginfo)
16:05:24 <rdieter> danofsatx: and you mentioned nouveau problem(s), but no bugs filed yet there (right?)
16:05:41 <danofsatx> I've been lax in not opening a bug for my Intel issues and attaching my backtraces.
16:07:56 <danofsatx> I still have one of my backtraces. I'll go ahead and open bug for Intel.
16:08:21 <rdieter> danofsatx: thanks, give link in #fedora-kde and we can cross-reference the upstream bug
16:08:36 <danofsatx> no prob.
16:08:40 <rdieter> thanks everyone
16:08:42 <danofsatx> I think I'm done...
16:08:42 <rdieter> #endmeeting