15:10:31 <rdieter> #startmeeting kde-sig
15:10:31 <zodbot> Meeting started Tue Feb 21 15:10:31 2017 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:10:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:10:31 <zodbot> The meeting name has been set to 'kde-sig'
15:10:35 <rdieter> #topic roll call
15:10:43 <rdieter> hi all, friendly kde-sig meeting, who's present today?
15:11:01 * jgrulich is present
15:11:32 <lupinix> .hello lupinix
15:11:34 <zodbot> lupinix: lupinix 'Christian Dersch' <lupinix@mailbox.org>
15:11:56 <than> present
15:12:06 <tosky> hi
15:12:07 <marc84> hi everyone
15:12:26 <rdieter> marc84: hi
15:12:29 <Kevin_Kofler> Present.
15:12:44 <rdieter> #info rdieter jgrulich lupinix than tosky marc84 Kevin_Kofler present
15:13:01 <rdieter> #chair jgrulich lupinix than tosky
15:13:01 <zodbot> Current chairs: jgrulich lupinix rdieter than tosky
15:14:14 <dvratil> hi
15:15:25 <rdieter> #info dvratil present
15:15:28 <rdieter> #chair dvratil
15:15:28 <zodbot> Current chairs: dvratil jgrulich lupinix rdieter than tosky
15:15:31 <rdieter> #topic agenda
15:15:34 <rdieter> ok, what to discuss today?
15:15:59 <Kevin_Kofler> In my role as QtWebEngine maintainer, I have mostly 2 agenda items to suggest: 1. What's the status of Qt 5.8 in Fedora? and 2. Any update on the default browser discussion?
15:15:59 <lupinix> status of plasma 5.9 and qt 5.8?
15:16:36 <rdieter> ok, added to agenda
15:18:38 <rdieter> let's get started
15:18:48 <rdieter> #topic Qt-5.8/plasma-5.9
15:19:07 <rdieter> as far as I know, those 2 are in copr only so far
15:19:18 <rdieter> https://copr.fedorainfracloud.org/coprs/g/kdesig/qt-5.8
15:19:34 <rdieter> and https://copr.fedorainfracloud.org/coprs/mkyral/plasma-5.9.0/
15:19:55 <rdieter> I could probably have time to start on plasma-5.9 for rawhide this week
15:20:19 <Kevin_Kofler> There is no QtWebEngine in the Copr, I suppose my help is needed there?
15:20:23 <rdieter> would like to hear from heliocastro about Qt suitability, but iirc, it should be close to ready to import as well
15:20:30 <rdieter> Kevin_Kofler: likely yes
15:20:49 <rdieter> getting the rest of the stack into rawhide would probably help?
15:21:00 <Kevin_Kofler> Sure.
15:21:23 <Kevin_Kofler> The drawback is that stuff depending on QtWebEngine in Rawhide might be broken for a couple days until I fix it.
15:21:46 <rdieter> when doing either of these, will need to take care merging changes into master/ branch
15:22:01 <Kevin_Kofler> Otherwise, I need write access to the Copr (or I'd have to create a Copr that pulls in the Qt 5.8 Copr, or reuse the qtwebengine Copr that has mostly other stuff at this time, not so nice).
15:22:11 <rdieter> the past couple of Qt merges at least, had some regressions/bugs due to that
15:22:49 <Kevin_Kofler> Building QtWebEngine locally is not something I'm looking forward to (it's just so huge), so it's Copr or Koji.
15:23:13 <rdieter> anyone able/willing to work with heliocastro and Qt 5.8?
15:23:14 <Kevin_Kofler> For the 5.7 rebase, I did it in Rawhide Koji.
15:23:39 <rdieter> (my involvement will probably have to wait until at least next week)
15:24:35 <rdieter> we could also consider asking releng for a f26-kde side tag to work, if that could be helpful (avoid intermittent breakage)
15:25:53 <rdieter> actually, I may well do that ^^ for plasma (we'll likely need a f26 target sooner or later anyway)
15:26:24 <rdieter> has anyone tried either copr and have feedback to offer?
15:27:06 <lupinix> nope, currently working on a deadline-project → not enough time
15:27:10 <lupinix> maybe next week
15:27:23 <rdieter> iirc, Qt 5.8 has a couple of regressions, one is wayland (probably not important yet, we don't use it), and... dang forgot the other
15:28:07 <rdieter> and upstream qtproject appears to be planning on skipping 5.8.1 release, and going straight to 5.9
15:28:20 <rdieter> (wouldn't hurt my feeling to wait for that)
15:28:32 <lupinix> excpected release date?
15:28:36 <lupinix> *expected
15:29:03 <Kevin_Kofler> Still months ahead.
15:29:05 <rdieter> https://wiki.qt.io/Qt_5.9_Release  =alpha Mar 1
15:29:32 <Kevin_Kofler> And that's for 5.9.0, where there is no reason it would be less buggy than 5.8.0.
15:29:43 <Kevin_Kofler> The churn in upstream Qt is really alarming.
15:29:50 * lupinix is not happy with qt release scheduling… especially when he thinks about security fixes for webengine
15:30:02 <Kevin_Kofler> All their focus is on spitting out feature releases with less and less work on quality.
15:30:38 <rdieter> beta Apr 5, final May 31.  So, may not be a good idea to wait afterall
15:31:12 <rdieter> https://fedoraproject.org/wiki/Releases/26/Schedule  first freeze is Mar 7
15:31:30 <rdieter> though, hrm... f26 may skip alpha, so not sure
15:31:49 <lupinix> the skip alpha discussion is about f27 afaik
15:32:15 <rdieter> lupinix: ah, ok
15:32:29 <Kevin_Kofler> Yes, F26 will not skip Alpha, it's F27 at the earliest where that will happen.
15:32:48 <tosky> I would like to point out that Plasma developers have some concerns about Qt 5.8
15:33:44 <rdieter> either way, whatever we update Qt too, 5.8 or 5.9alpha, it needs to be in and ready by early march
15:33:54 <rdieter> 5.8 looks easiest/safest at this point
15:34:04 <lupinix> tosky: which concerns?
15:34:09 <rdieter> tosky: besides the wayland regression(s)?
15:34:51 <tosky> I've seen discussions and I'm asking again
15:34:53 <Kevin_Kofler> For all I care, Wayland can die in a fire. X11 forever!
15:34:58 <rdieter> I thought there was at least one other thing, but we should find out for sure, before proceeding
15:37:16 <rdieter> ok, let's move on (and gather data to make decisions later)
15:37:23 <Kevin_Kofler> The one thing I remember is the build system regression (configuration appended to qmake outside of the ELF structure), but that never made it into a release, it was only on the 5.8.1 branch for a while (and got fixed there AFAIK).
15:37:37 <rdieter> Kevin_Kofler: <nod>
15:37:45 <rdieter> #topic default browser
15:38:12 <Kevin_Kofler> So, I was asking whether there are any news regarding this?
15:38:13 <rdieter> in short, I think we need someone to drive this change (probably not me this time)
15:38:50 <Kevin_Kofler> Unfortunately, as far as I know, the Konqueror 16.12 issues with saving configuration (window positions etc.) and with saving passwords in KWebEnginePart are still not fixed.
15:38:50 <rdieter> Kevin_Kofler: I don't think so
15:38:57 <lupinix> how reliable is kf5-based konqueror now (i think this is the candidate?)
15:38:58 <rdieter> (no news)
15:39:19 <rdieter> konqueror is pretty rough, probably not a good candidate imo
15:39:31 <Kevin_Kofler> I'd give QupZilla another look if I were you.
15:39:53 <rdieter> so the main viable ones are probably qupzilla and maybe chromium
15:39:57 <Kevin_Kofler> I've been using it daily since I upgraded to F24 and now F25.
15:40:09 <Kevin_Kofler> It just works.
15:40:38 <Kevin_Kofler> Website compatibility is comparable with Firefox.
15:41:00 <rdieter> unfortunately, we may have to keep in mind that qupzilla (and webengine) is still pretty bad on nouveau
15:41:25 <Kevin_Kofler> QupZilla 2.1 also has native scrollbars (for non-frame websites – it's application-level, so it cannot work for frames, you still get the Chromium scrollbars there), so that complaint is also obsolete.
15:41:53 <Kevin_Kofler> Hmmmph, that patch should really get into the Fedora mesa, but the maintainers are stubborn.
15:42:17 <Kevin_Kofler> The locking patch just works, I don't see why it does not get applied, at least until there is something better.
15:42:44 <rdieter> I can see both sides on that, it's unfortunate :(
15:44:50 <Kevin_Kofler> Note that Chromium is also hit by this.
15:45:33 <Kevin_Kofler> The sad thing is, if Firefox were affected, the patch would be merged immediately even if it were completely broken.
15:45:54 <Kevin_Kofler> But since it's just the OTHER browsers that are hit, nobody at Fedora cares.
15:46:04 <rdieter> Kevin_Kofler: oh?  I thought this was a side effect of how QtWebEngine was engineered?
15:46:23 <Kevin_Kofler> It is a side effect of how Chromium is engineered.
15:46:31 <Kevin_Kofler> QtWebEngine being based on Chromium, it is affected as well.
15:46:41 <Kevin_Kofler> The issue was found with Chromium before QtWebEngine was even a thing.
15:46:54 <rdieter> ok, I guess I'll take your word on it
15:46:57 * lupinix mumbles libglvnd where breakage is not an issue…
15:47:15 <Kevin_Kofler> Nouveau developers have known about it for a couple years. All they have come up so far is that fix that they don't want to apply as is.
15:47:27 <rdieter> I guess there are workarounds now too, some env vars to set?
15:47:55 <rdieter> (and some other patches, iirc)
15:48:24 <rdieter> that I think essentially resort to software rendering instead
15:48:33 <Kevin_Kofler> We could detect Nouveau and force software rendering on it.
15:48:44 <Kevin_Kofler> There is some proposed hack floating around in the QTBUG.
15:49:01 <Kevin_Kofler> I think it is entirely the wrong solution, but since they don't allow us to fix Nouveau, we may have to do it.
15:49:03 <rdieter> I guess we're getting side-tracked, my first point remains: we need someone leading/driving this effort
15:49:30 <rdieter> Kevin_Kofler: any workaround is probably better than nothing at this point
15:50:02 <rdieter> and also probably a blocker if we want to consider any webengine-based default browser
15:50:09 <lupinix> btw how does this affect the PIM stuff? when reviewing i recognized it makes usage of webengine too
15:50:24 <rdieter> lupinix: pim stuff that links webengine is affected too :(
15:50:25 <Kevin_Kofler> It is screwed up the same way.
15:50:36 <Kevin_Kofler> So this is not even just about the default browser.
15:50:41 <Kevin_Kofler> The whole spin is broken.
15:50:52 <Kevin_Kofler> Have we tried proposing this as a blocker yet?
15:51:05 <rdieter> no
15:51:10 <Kevin_Kofler> If we file it as a blocker and mention the Nouveau patch, we may get QA/FESCo to force it being applied.
15:51:36 <Kevin_Kofler> This breaks KMail on widespread hardware = default app on a release-blocking spin broken on widespread hardware = blocker.
15:51:45 <rdieter> I'd rather apply the qtwebengine patches/workarounds
15:51:57 <rdieter> which are safer, really
15:52:23 <rdieter> (but it's not either/or here, can certainly do both)
15:52:47 <Kevin_Kofler> But they only paper over the issue and will also keep Nouveau at poor performance even when it gets fixed, until somebody remembers to drop the hack.
15:53:05 <Kevin_Kofler> (they = QtWebEngine-level workarounds)
15:53:08 <rdieter> both "fixes" paper over the issue
15:53:23 <Kevin_Kofler> No, the locking fix actually makes Nouveau thread-safe.
15:53:58 <Kevin_Kofler> The issue upstream has with it is that they think there are places that are not locked correctly or that may deadlock, so somehow they want the locking to be done differently.
15:54:20 <Kevin_Kofler> They were pretty low on specifics, and I don't know the Nouveau code well enough to understand such specifics anyway.
15:54:58 <Kevin_Kofler> By the way, the patches don't apply as is to Rawhide's Mesa 17, and upstream deleted the work branch, so I have to rebase them before they can be considered for Rawhide/F26. :-(
15:56:33 <rdieter> ok, let's table this topic for now, continue discussions elsewhere (irc, onlist), almost out of time today
15:56:38 <rdieter> #topic open discussion
15:56:42 <Kevin_Kofler> As for the deadlocks, I did not get any reports of deadlocks caused by the patches.
15:56:49 <rdieter> anything else ot mention before ending meeting?
15:56:56 <lupinix> rdieter: nothing else here
16:00:04 <rdieter> alright then, thanks everyone!
16:00:06 <tosky> o/
16:00:09 <rdieter> #endmeeting