14:59:52 <rdieter> #startmeeting kde-sig
14:59:52 <zodbot> Meeting started Tue Dec  6 14:59:52 2016 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:59:52 <zodbot> The meeting name has been set to 'kde-sig'
14:59:56 <rdieter> #topic roll call
15:00:05 <rdieter> hi all, friendly kde-sig meeting, who's present today?
15:00:09 * pino|work rolls
15:00:11 <lupinix> .hello lupinix
15:00:14 <zodbot> lupinix: lupinix 'Christian Dersch' <lupinix@mailbox.org>
15:00:39 <tosky> op
15:00:42 <tosky> hi
15:00:59 <Kevin_Kofler> Present, can give some news about QtWebEngine packaging.
15:01:52 <rdieter> #info rdieter pino|work lupinix tosky Kevin_Kofler present
15:01:57 <rdieter> #chair pino|work lupinix tosky Kevin_Kofler
15:01:57 <zodbot> Current chairs: Kevin_Kofler lupinix pino|work rdieter tosky
15:03:32 <rdieter> may be quick meeting
15:04:11 <mbriza> hello
15:04:18 <rdieter> #info mbriza present
15:04:20 <rdieter> hi
15:04:21 <rdieter> #chair mbriza
15:04:21 <zodbot> Current chairs: Kevin_Kofler lupinix mbriza pino|work rdieter tosky
15:05:19 <rdieter> ok, anyting extra to discuss on top of posted agenda https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/thread/7O6U5YVNN3KNGWRCW4MMFOPL6KC63LHL/
15:05:26 <rdieter> Kevin_Kofler: mentioned QtWebEngine
15:06:25 <rdieter> i've a couple more bugs "plasmaslell freeze bug #1399396", ongoing openssl-1.1/rawhide/Qt issues
15:06:49 <mbriza> nothing from my side
15:07:20 <rdieter> ok, let's get started then, mostly about recent bodhi updates...
15:08:12 <rdieter> first off, f24 plasma-5.8.4/qt-5.6.2 : https://bodhi.fedoraproject.org/updates/FEDORA-2016-ee7faa4b02
15:08:24 <rdieter> any objections to queueing that one for stable updates?
15:08:40 <rdieter> or other comments?
15:08:43 <tosky> I just +1 it
15:08:51 <lupinix> +1
15:08:54 <tosky> my screenlocker issues seems to be fixed (automagically)
15:09:04 <rdieter> tosky: oh... wierd(?), but good
15:09:19 * rdieter hugs magic
15:09:19 <lupinix> it contains security fixes, so we should not wait any longer
15:10:57 <rdieter> anyone present not give that update karma yet?  If so, wait a bit, I'm re-enabling autokarma
15:11:16 <pino|work> makes sense to push at this point
15:11:24 <tosky> unrelated but releted: the bodhi page seems to kill my browser, not sure why; it seems to be reloading
15:11:36 <mbriza> i
15:11:39 <mbriza> i'll +1 it
15:11:51 <rdieter> the incremental loading of tests stuff still isn't great
15:12:12 <mbriza> if bodhi ever loads for me
15:12:30 <rdieter> ok, I think autokarma should be enabled now
15:12:49 <mbriza> well, bodhi didn't kill my browser but it just doesn't load
15:12:55 <rdieter> next up: f23/qt-5.6.2: https://bodhi.fedoraproject.org/updates/FEDORA-2016-f502be0cef
15:12:55 <mbriza> ah, here we go
15:13:28 <than> present
15:13:35 <rdieter> #info than present
15:13:36 <rdieter> hi
15:13:38 <rdieter> #chair than
15:13:38 <zodbot> Current chairs: Kevin_Kofler lupinix mbriza pino|work rdieter than tosky
15:14:24 <rdieter> the f23 qt-5.6.2 update is similar to f24, except only minimal rebuilds are included
15:14:30 <lupinix> i did not test that one @f23, but the security fix argument is also valid here
15:14:34 <rdieter> (no plasma upgrade)
15:15:27 <rdieter> come to think of it, neither have I (tested f23), has anyone been using f23 recently? :)
15:15:40 <tosky> ehm...
15:16:23 <tosky> especially with the KDE spin, there is usually no much reason to stay with the previous version
15:16:28 <rdieter> fwiw, bodhi did have at least one +1
15:17:17 * lupinix would say: push
15:18:09 <Kevin_Kofler> Yeah, ship it!
15:18:19 <rdieter> ok, enabling autokarma there too
15:18:20 <Kevin_Kofler> (speaking in my role as QtWebEngine maintainer)
15:18:48 <rdieter> same as before, if someone could give it karma, then we're good to go there
15:19:14 <rdieter> was hoping to see heliocastro about discussing whether to start work on f25/qt-5.7.1 update or not
15:19:28 <lupinix> bodhi is *really* slow today
15:19:38 <rdieter> on the one hand, qt-5.7.1 isn't officially released yet
15:20:12 <than> rdieter: i think we should wait for official released
15:20:13 <rdieter> what we have is same/close to what qtproject provided as a 5.7.1 release candidate/snapshot
15:20:36 <than> rdieter: it's ok for rwahide
15:21:11 <rdieter> <nod>, there are a handful of semi-important fixes in 5.7.1, and I probably would have backported some to our 5.7.0 packaging before if I'd known 5.7.1 would get delayed this long
15:21:20 <lupinix> yes
15:21:32 <lupinix> qtwebengine security fixes etc.
15:22:28 <rdieter> the ones I had in mind were mostly in qtbase, one is a fix for mis-parsing recent tzdata
15:22:50 <lupinix> IMHO it is not a good idea to couple the release cycle of the webengine stuff with the rest as it is more critical @security aspects typically
15:23:14 <lupinix> karma done @f23
15:23:38 <rdieter> lupinix: agreed, it's probably done that way mostly out of convenience (ie, getting to release everything at once)
15:23:55 <rdieter> (educated guess/speculation)
15:24:50 <rdieter> ok, I'm for waiting for release too, we need to poke someone upstream to get a hint exactly when we can expect that to happen
15:25:08 <Kevin_Kofler> Yes. Unfortunately, they only do the security backports in blocks just before the releases, so even shipping snapshots doesn't help.
15:25:19 <Kevin_Kofler> (We'd have to backport fixes ourselves if we want them out any faster.)
15:25:40 <Kevin_Kofler> But anyway, Qt 5.7.1 also has other fixes that make it worth pushing quickly.
15:26:19 <rdieter> hrm, looks like f23 one needs one more +1, https://bodhi.fedoraproject.org/updates/FEDORA-2016-f502be0cef
15:26:23 <Kevin_Kofler> Though I'm also a bit nervous about shipping only almost-final tarballs. I don't understand why they're sitting on that release for so long.
15:26:46 <rdieter> just noticed that prior +1 was before the last modification, so doesn't count
15:27:58 <rdieter> any other recent updates to discuss?  else, we can move on to webengine/kkofler topic
15:28:45 <Kevin_Kofler> I've given the +1.
15:28:49 <lupinix> http://lists.qt-project.org/pipermail/releasing/2016-November/004379.html
15:29:02 <lupinix> "Qt 5.7.1 status:
15:29:02 <lupinix> - Unfortunately new blocker found from Device Creation testing
15:29:02 <lupinix> * It seems root cause is in Qt side
15:29:02 <lupinix> --> Most probably we need to update qt content once again
15:29:03 <lupinix> --> No Qt 5.7.1 release during this week. New target week 49"
15:29:29 <lupinix> lastest one i've found @ml
15:29:30 <rdieter> week 49 is what exactly?  that should be ~now, right?
15:29:47 <rdieter> (or maybe next week)
15:29:54 <lupinix> this week
15:30:10 <pino|work> (for people with plasma 5.8, there's the option for clock to show week numbers in calendar)
15:30:11 <rdieter> k, either way, soon
15:30:31 <Kevin_Kofler> It sucks that everything is blocking on those mobile devices that we don't give a darn about.
15:30:41 <mbriza> it's not even mobile devices
15:30:44 <mbriza> it's just devices
15:30:44 <rdieter> pino|work: thx, enabled
15:30:54 <mbriza> embedded stuff
15:31:06 <pino|work> Kevin_Kofler: s/we/i/
15:31:13 <Kevin_Kofler> Fedora as a whole.
15:31:27 <rdieter> moving on then...
15:31:30 <Kevin_Kofler> We only ship desktop builds.
15:31:39 <rdieter> #topic QtWebEngine packaging
15:31:43 <rdieter> Kevin_Kofler: go ahead
15:31:45 <Kevin_Kofler> I guess we can just ship what is there now and not wait for device-targeted respins.
15:31:52 <Kevin_Kofler> (for Qt 5.7.1)
15:32:02 <Kevin_Kofler> So for QtWebEngine, there are 2 main updates:
15:32:22 <Kevin_Kofler> 1. I fixed the ARM NEON detection in our 5.7.1 packaging.
15:32:31 <Kevin_Kofler> So now it builds on ARM with NEON enabled, detected at runtime.
15:32:37 <rdieter> woo
15:32:54 <Kevin_Kofler> Unfortunately, Google supports runtime detection of NEON only on Android, so I had to do some fixing to enable it for Fedora.
15:33:15 <Kevin_Kofler> (They also don't really support building without NEON support, but that was easier to fix, so we had that before.)
15:33:57 <Kevin_Kofler> So 5.7.1 is now ready. I also fixed my cleaning script to remove the bundled openh264 sources that are included in the tarball now (since 5.7.0) and that are only built with use_proprietary_codecs enabled.
15:34:17 <Kevin_Kofler> Shipping openh264 outside of the special Cisco repo is problematic, and it was not being built anyway.
15:34:42 <Kevin_Kofler> (It's used for encoding in WebRTC, because ffmpeg does not include a H.264 encoder, only a decoder. They use the FFmpeg decoder for the decoding, even in WebRTC.)
15:35:09 <Kevin_Kofler> (But both are enabled only if use_proprietary_codecs is enabled.)
15:35:31 <Kevin_Kofler> 2. I submitted a qt5-qtwebengine-freeworld to RPM Fusion review.
15:35:43 <Kevin_Kofler> https://bugzilla.rpmfusion.org/show_bug.cgi?id=4368
15:35:50 <rdieter> nice segue :)
15:36:42 <Kevin_Kofler> That one works like freetype-freeworld (ld.so.conf.d override), depends on the main package for the data files (and for the double-built libv8.so on i686), and has use_system_ffmpeg and use_proprietary_codecs enabled.
15:36:53 <Kevin_Kofler> ("proprietary" = patent-encumbered, in this context.)
15:37:09 <Kevin_Kofler> use_system_ffmpeg can be disabled through a spec flag if there are problems with it.
15:37:44 <Kevin_Kofler> With that, those pesky H.264 HTML 5 videos should work. :-)
15:37:54 <Kevin_Kofler> (So you won't have to bring up Konqueror for them.)
15:38:05 <Kevin_Kofler> The drawback is that you end up with 2 versions of the huge shared libraries.
15:38:49 <lupinix> nice :)
15:38:55 <lupinix> Kevin_Kofler++
15:38:55 <zodbot> lupinix: Karma for kkofler changed to 1 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:39:10 <rdieter> Kevin_Kofler++
15:39:10 <zodbot> rdieter: Karma for kkofler changed to 2 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:39:18 <rdieter> definitely needs more nom nom cookies
15:39:28 <lupinix> :D
15:39:58 <lupinix> anybody who can do the review? i'm not yet @rpmfusion…
15:40:18 <rdieter> lupinix: I can/will
15:40:22 <lupinix> nice :)
15:40:22 <rdieter> (I did the fedora review)
15:40:24 <lupinix> rdieter++
15:40:24 <zodbot> lupinix: Karma for rdieter changed to 2 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:40:43 <rdieter> for most anyone else, that package may make their eyes bleed
15:40:55 <Kevin_Kofler> :-)
15:40:58 * rdieter has special glasses
15:41:34 <Kevin_Kofler> rdieter: You may want to take the bug and set the fedora-review? flag.
15:41:34 <rdieter> Kevin_Kofler: thanks for the update
15:41:53 <rdieter> ah, forgot the flag, taken
15:42:21 <Kevin_Kofler> OK, thanks, I hope we can get this in quickly.
15:42:37 <rdieter> anything else on this topic?
15:42:43 <lupinix> nothing here
15:42:57 <Kevin_Kofler> The build time on ARM runs dangerously close to the 24 hour timeout, by the way.
15:43:13 <rdieter> ok, moving on to unfun bugs....
15:43:15 <Kevin_Kofler> My scratch build: http://koji.rpmfusion.org/koji/taskinfo?taskID=57930 took over 17 hours.
15:43:59 <rdieter> #topic f25 plasmashell freezes (nouveau/radeon)
15:44:06 <rdieter> .bug 1399396
15:44:06 <zodbot> rdieter: Bug 1399396 – Plasmashell freezes - https://bugzilla.redhat.com/1399396
15:44:32 <rdieter> fun thing here, is it unfreezes with a vt switch
15:45:22 <rdieter> i've really no idea about this, don't see it myself (obviously)
15:45:42 <rdieter> (though in fairness still use f24 on my primary laptop)
15:45:55 <lupinix> did not see it either, but mostly intel here, only one radeon hd 5770
15:47:05 * lupinix removed the nvidia graphics so cannot test anymore
15:47:11 <lupinix> but was always a mess for me
15:47:12 <mbriza> seems nouveau is pretty problematic now with qt
15:47:25 <lupinix> not only with qt
15:47:28 <mbriza> especially qml
15:47:46 <lupinix> chromium for example also tends to crash it
15:47:52 <Kevin_Kofler> If it were just Nouveau, I'd ask whether this was with my qtwebengine Copr builds, and if so, blame the locking patches, but with Radeon?
15:48:18 <mbriza> Kevin_Kofler: i pointed someone with fmw crashing to your mesa builds and it didn't help for him :/
15:48:18 <Kevin_Kofler> Chromium definitely does crash Nouveau, there is a mesa with fixes in the qtwebengine Copr.
15:48:21 <rdieter> I tried to ask folks piling on with "me toos" to file a separate bug for radeon, but that never happened :(
15:48:30 <Kevin_Kofler> Should fix Chromium, QupZilla, KMail etc.
15:49:00 <rdieter> it's possible this is a Qt 5.7 issue (another reason to be sad 5.7.1 is delayed)
15:49:02 <Kevin_Kofler> But the locking patches can cause lockups (even hard lockups of the system), which is why upstream did not merge them yet.
15:49:15 <Kevin_Kofler> They are not confident that the code as is does not lock up.
15:49:24 <mbriza> btw has someone of you tried 5.8 with the software renderer?
15:49:28 <Kevin_Kofler> (though all the feedback I got was positive, in practice)
15:49:34 <mbriza> i'm wondering what the performance of that is
15:49:49 <rdieter> mbriza: Qt 5.8 ?
15:49:53 <mbriza> yes
15:50:12 <mbriza> they ought to merge the software renderer to qtdeclarative
15:50:15 <rdieter> OK, it's not packaged anywhere I know at least
15:50:57 <Kevin_Kofler> It was proprietary-only up to 5.6, freed but separate in 5.7, it is merged into qtdeclarative in 5.8.
15:51:08 <mbriza> yes
15:51:16 <Kevin_Kofler> We did not package the tarball for 5.7, there was a review request that came in quite late and did not move forward.
15:51:43 <rdieter> we still could work on getting it in, but it's lifetime would be small
15:52:11 <rdieter> well, could be small, depends if we want to do 5.7->5.8 updates for f25 or not
15:52:16 <Kevin_Kofler> I'd rather start work on 5.8 instead.
15:52:17 <mbriza> well, the review's approved
15:52:38 * pino|work brb
15:52:41 <mbriza> and can we trust 5.8 actually releases in january?
15:52:42 <rdieter> ok, sounds like we don't have any good short-term ideas what to do here?
15:52:55 <Kevin_Kofler> QtWebEngine is going to be a PITA as usual (new Chromium with lots of changes, and from what I saw in the chromium.spec so far, they broke unbundling ICU, among other "niceness").
15:53:06 <rdieter> it's probably worth triaging elsewhere, this is almost certainly not a plasma bug
15:53:13 <Kevin_Kofler> Ah well, if the review is approved, then by all means build the tarball!
15:53:33 <Kevin_Kofler> Import the package, build it, send it through Bodhi.
15:53:38 <Kevin_Kofler> Or is the submitter AWOL?
15:53:46 <mbriza> it's heliocastro
15:54:10 <rdieter> any Qt(5) comaintainer can import it, any volunteer?
15:54:26 <rdieter> (at least assuming the pkgdb acls set right)
15:55:50 <Kevin_Kofler> The spellchecking feature that QtWebEngine 5.8 enables is also going to be "fun", Chromium uses a fork of Hunspell modified to use an incompatible dictionary format!
15:55:53 <rdieter> on freezing topic, we can continue discussion after meeting, there's 2 more bugs to get to with limited time left
15:56:10 <rdieter> #topic rawhide/openssl-1.1 issues
15:56:33 <Kevin_Kofler> Fixing it to use the system dictionaries is a lot of work, Debian wants to do it, but didn't last I checked, and everbody else just accepts it and ships the files in Google's crappy proprietary format.
15:56:34 <rdieter> than: status on qt5-qtbase/openssl-1.1 ?
15:56:47 <rdieter> I know it's currently broken
15:56:56 <Kevin_Kofler> This is really stupid, because the whole point of standardizing on Hunspell is that you need only ONE copy of the spellchecking dictionaries.
15:57:30 <rdieter> .bug 1401459
15:57:30 <zodbot> rdieter: Bug 1401459 – QSslSocket: cannot resolve OPENSSL_free (and many more) - https://bugzilla.redhat.com/1401459
15:57:45 <Kevin_Kofler> Can we PLEASE switch back to -openssl-linked?
15:57:52 <rdieter> in the short term, I think it wise to re-enable -openssl-linked (at least in the short-term)
15:58:00 <Kevin_Kofler> That way we immediately notice if it tries to use an API that is not actually available.
15:58:06 <rdieter> <nod>
15:58:10 <Kevin_Kofler> (because it will fail the build and we can then fix it)
15:58:21 <Kevin_Kofler> I also think that -openssl-linked is absolutely the right thing to do in a distro package.
15:58:36 <Kevin_Kofler> It is the only way to get RPM soname and symbol version (!) autodeps working.
15:58:37 <rdieter> I'm starting to think so too
15:58:45 <Kevin_Kofler> So you are sure that the packaged Qt and OpenSSL work together.
15:58:47 <rdieter> I don't see any benefit otherwise
15:59:04 <Kevin_Kofler> With dlopen, you can have only a vague unversioned dep, or a guesstimate on what range of versions MIGHT work.
15:59:06 <rdieter> (the notion that one can mix-n-match openssl is bad)
15:59:14 <Kevin_Kofler> (right now there is no versioning at all, not even >= 1.1)
15:59:53 <Kevin_Kofler> I see absolutely no benefit in dlopening OpenSSL in a distro package.
16:00:09 <mbriza> regarding the qtquick 2d renderer: it's already packaged, i wanted to try rebuilding the srpm, updated with rawhide packages and got qt5-qtdeclarative-render2d too
16:00:54 <rdieter> mbriza: good idea
16:01:09 <rdieter> than: ping ?
16:01:09 <zodbot> rdieter: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
16:01:20 <mbriza> rdieter: what's a good idea?
16:01:39 <rdieter> mbriza: "i wanted to try rebuilding the srpm, updated with rawhide packages and got qt5-qtdeclarative-render2d too"
16:01:59 <rdieter> that part :)
16:02:36 <mbriza> hmmm, i guess i don't understand but nevermind, good thing is we have it already imported :)
16:02:44 <rdieter> on the topic of openssl-1.1, so far, I've switched qt4/kdelibs to using compat-openssl10 for now
16:03:01 <rdieter> unforunately, that leaves kf5-kdelibs4support
16:03:28 <pino|work> make it use openssl10 too, for now?
16:03:50 <rdieter> pino|work: probably not viable, since qt5 is going to be using openssl-1.1
16:04:02 <rdieter> loading to openssl libs into same process would be bad, I think
16:04:08 <rdieter> loading *two* ...
16:04:26 <pino|work> rdieter: iirc it was mentioned in a fedora-devel thread that openssl uses versioned symbols
16:04:53 <rdieter> so it would be safe?
16:05:00 <rdieter> we can try I guess
16:05:13 <pino|work> so loading two openssl should be fine, as long as you don't then pass pointers/structs created by one openssl to the other
16:05:28 <pino|work> iirc kssl links directly to openssl?
16:05:51 <rdieter> I think so
16:06:47 <rdieter> we're over time, any last comments before I close meeting?
16:07:05 <rdieter> can continue in #fedora-kde
16:07:37 <rdieter> for minutes, the last bug I wanted to mention was...
16:07:41 <rdieter> .bug 1396755
16:07:41 <zodbot> rdieter: Bug 1396755 – moc-qt4 issues with boost/glib(?) : Parse error at "defined" - https://bugzilla.redhat.com/1396755
16:07:55 <rdieter> another bad rawhide bug causing lots of FTBFS issues :(
16:08:29 <rdieter> any help there would be appreciated
16:08:33 <rdieter> thanks everyone
16:08:35 <rdieter> #endmeeting