15:04:44 #startmeeting kde-sig 15:04:44 Meeting started Tue Jan 19 15:04:44 2016 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:04:44 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:04:44 The meeting name has been set to 'kde-sig' 15:04:52 #meetingname kde-sig 15:04:52 The meeting name has been set to 'kde-sig' 15:05:00 #topic roll call 15:05:09 hi all, friendly kde-sig meeting, who's present today? 15:05:31 hello o/ 15:06:11 * Kevin_Kofler is here, too. 15:07:02 Hi 15:07:08 hi 15:07:44 o/ 15:07:57 #info rdieter jgrulich Kevin_Kofler smdeep tosky pino|work present 15:10:34 dvratil sends regards 15:10:38 #topic agenda 15:10:42 what to discuss today? 15:10:51 Kevin_Kofler offerred to give a qtwebengine status report 15:11:07 .bug 1283348 15:11:09 rdieter: Bug 1283348 Black screen on KDE live session (with qemu-kvm) - https://bugzilla.redhat.com/1283348 15:11:21 I want to highlight ^^ , see if we can get more help to figure out what's going on there 15:11:36 anything else? 15:13:02 *** F23-20160112 updated lives available: http://tinyurl.com/live-respins (.iso & .torrent) Thanks to the community of maintainers and seeders. Addt'l seeders always welcome. *** 15:14:45 #topic Bug 1283348 Black screen on KDE live session (with qemu-kvm) 15:14:47 Southern_Gentlem: Thanks, but why the announcement 1 week later? I already have the 20160112 KDE respin, by the way, it's what I used for my QtWebEngine VM testing. ;-) 15:15:19 anyway, no much new to report with the aforementioned bug, other than to make a call for help testing and debugging what's going wrong there 15:15:59 I hope to find more time to spend on it myself soon 15:16:28 KK when i could be here for the meeting 15:16:56 but i will be tracking the kernel releases and respinning with the kernel updates 15:16:59 There wasn't any meeting last week anyway. 15:17:47 rdieter: That black screen bug is really bizarre. Unfortunately, I don't have any idea what's up either. 15:18:13 The F23 20160112 respin works fine in qemu-kvm, no black screen there. 15:18:22 So is it just Rawhide that's broken? Looks so. 15:18:40 Kevin_Kofler: apparently rawhide specific, yes 15:19:09 only major difference offhand is Qt 5.6.0-beta 15:19:24 (and that everything is built against it) 15:19:24 Well, actually, F23 20160112 is not perfectly fine either, there are crashes in plasmashell inside llvmpipe code every once in a while. 15:19:53 At least if I upgrade Qt to 5.6. I haven't run on 5.5 long enough to see whether it'd happen there too. 15:20:09 there is a discussion on frameworks mailing list about deadlock in kded with Qt 5.6, might be related 15:20:12 and contrary to bug summary, it's not specific to qemu, several folks have confirmed it persists on real hardware too 15:20:24 But the running plasmashell should not upgrade to 5.6 immediately, so I doubt Qt 5.6 is the cause of the llvmpipe crashes. 15:20:28 jgrulich: oh, interesing, can you find any links/references? 15:20:32 It's really a bug in the llvmpipe anyway. 15:20:52 What I haven't tried is starting a new session with 5.6 on F23. 15:20:59 https://mail.kde.org/pipermail/kde-frameworks-devel/2016-January/030429.html 15:21:03 So it may well be 5.6's fault indeed. 15:21:14 Kevin_Kofler: I did, I fixed at least one specific 5.6 issue already 15:22:20 rdieter: and bug report is here https://bugs.kde.org/show_bug.cgi?id=358017 15:24:04 jgrulich: not sure, most reporters (still) claim problem goes away simply by restarting plasmashell, that shouldn't help make kded undeadlock, would it? 15:25:21 I guess the problem I found was with plasma-breeze's kde4breeze.upd script 15:26:15 anyway, that's another thing to look at, thanks. anything else to add? 15:26:30 rdieter: I don't think so, but the problem which can be workarounded by restarting plasmashell would be probably already fixed with your plasma-breeze fix for kde4breeze.upd 15:27:30 sorry I'm late, had to get a new battery for the wife's vehicle 15:27:48 #info danofsatx present 15:27:50 danofsatx: hi 15:28:02 greetings 15:28:12 * danofsatx catches up on scroll back 15:29:07 ok, let's move on... 15:29:14 #topic qtwebengine status 15:29:17 Kevin_Kofler: go ahead 15:31:07 OK 15:31:26 * QtWebEngine is now in Rawhide. 15:31:35 * I unbundled everything that can be unbundled. 15:32:33 * I fixed the issue with HTTPS on Google's sites (including YouTube): It turns out Chromium can be built against 2 SSL implementations: a patched fork of NSS SSL, or "BoringSSL", a patched fork of OpenSSL. 15:33:22 The default in Chromium 45 (on which QtWebEngine 5.6 is based) was NSS SSL, but the code stopped working with NSS 3.21 (only the SSL parts are forked, the rest is used from the system NSS). I tried upgrading the SSL parts to 3.21 to match the system NSS, that didn't help either. 15:33:52 Chromium 47 and newer default to BoringSSL, while still using NSS to get the system certificates (they call that a "chimera build"). This is what my QtWebEngine builds are now. 15:34:15 * I worked on removing the SSE2 requirement on i686, to comply with Fedora's architecture support policies: 15:35:03 - A version that does runtime detection for all SSE2 parts outside of V8, and builds V8 with only the x87 backend, is already in Rawhide. So it should already be working without SSE2. 15:35:41 - I have a version with swappable V8 (x87 vs. SSE2 backends) almost ready, I just need to check that it builds and add the Provides/Requires filtering for the private .so. 15:36:28 (I use the ld.so feature where it tries to look up $rpath/sse2/libfoo.so before $rpath/libfoo.so if the CPU supports SSE2. I tested that it really works even with rpaths.) 15:37:34 * I want to look into backporting the Chromium-GStreamer code from Samsung at some point too, but I don't have that yet. So for now, you get an "ffmpeg" with only Ogg and WebM codecs enabled. 15:37:37 I'm a little concerned about the maintainance burden of carrying the non-upstreamed-sse2-removal patches forward 15:38:15 Well, if at some point we cannot get the runtime detection working anymore, we could do what we did for QtWebKit and just build the whole thing twice. 15:38:36 Removing SSE2 on i686 completely is actually much easier than runtime-detecting it. 15:38:42 Kevin_Kofler: oh, I thought upstream didn't support non-sse2 *at all* ? 15:39:05 It doesn't, but it supports non-i686 architectures, so obviously it needs C versions of the code. :-) 15:39:18 The only exception is V8 (JIT only), but that one has a dedicated x87 backend. 15:39:57 noted, thanks 15:40:44 Another thing I worked on is QupZilla 2. 15:41:07 I submitted 2 patches upstream, which are included in my current Copr builds, and which have already been merged upstream. 15:41:11 , let's poke the bug tracking that for maintainer response one more time, and move forward with importing it within the next few days 15:41:27 One patch fixes the proxy default to NoProxy (can't use HttpProxy without a concrete proxy to default to). 15:41:39 .bug 1298145 15:41:40 rdieter: Bug 1298145 Build Qupzilla with QtWebEngine - https://bugzilla.redhat.com/1298145 15:41:52 The other patch adds a configuration setting to disable autosearch, because I hate autosearch and consider it a privacy issue. 15:42:09 (but autosearch remains enabled by default) 15:43:30 IMHO, what we have now in Rawhide/Copr is ready to be a default browser, and the Change submission deadline for F24 is imminent, so: 15:44:41 Proposal: We file a Change to make QupZilla 2 the default browser on the KDE (and LXQt if it gets done) Spin for F24. I would be the change owner, the KDE SIG would be listed as supporting co-owner. 15:45:08 So, KDE SIG voting members, what do you think? 15:46:22 I still think that Firefox is better option for most users, more widely used than Qupzilla and people who wants to use Qupzilla will install it anyway 15:47:19 * marcdeop cannot vote but believes that Qupzilla better integrates with the KDE environment than Firefox... 15:47:20 I think that, as new major version, the new proposal should stay at least for one cycle 15:47:24 By the way, for the SSE2 issue: What we could do in the absolute worst case, if everything else fails, is just drop the no-sse2 patch at some point, it'd leave us in a no worse state than if we never had it. Though of course pushing that in an update would not really be acceptable. But we should really do a best effort to support non-SSE2 per Fedora policies. 15:47:49 * marcdeop wants to mention that qupzilla 2 hasn't been released yet and won't be until qt 5.6 is... 15:48:16 so I would say it's a non-starter for now 15:48:19 do Chrome plugins work in QtWebEngine? (Specifically, LastPass) 15:48:41 I've said it outside of meetings, but for the record here I think it's premature to consiure qupzilla as a new default browser for several reasons: 15:48:45 jgrulich: QupZilla 2 is just a repackaged Chromium under the hood, the website support is just as good. 15:48:54 * it's not in rawhide or in a (officially) testable state yet 15:49:03 tosky: The Change deadline for F24 is in a few days, so it's NOT too late to submit a change for F24. 15:49:19 Kevin_Kofler: I didn't even mentioned that 15:49:20 I can't support switching it to default until it has been thouroughly tested. 15:49:25 * copr packaged a development snapshot, would like some concrete release schedule/plans 15:49:54 * qupzilla package maintainership (in fedora) is currently a bit lacking 15:49:54 I will whole-heartedly support including it (vice Konquerer) as a secondary, however. 15:49:59 marcdeop: I know that it's not out yet. My builds are 1.9.99 snapshots, which just work. And Rawhide also has Qt 5.6 beta right now. We're set on 5.6 already. 15:50:02 what I wrote above makes it unsuitable *now* even if it's possible to submit it 15:50:28 say, "tech preview" kind of thing 15:51:17 marcdeop: And +1 to the integration thing. Widgets just work, the UI is a standard KDE one, it defaults to showing a menu bar just like Konqueror, it also uses KDE file dialogs, and there is optional KWallet integration (though it currently stores the passwords as blobs in an app-specific directory in KWallet). 15:51:29 Firefox offers NONE of that. 15:51:47 Plus, Firefox no longer complies to the Free Software Definition. 15:51:49 I can endorse a feature that qtwebengine and (tech-preview) enabled-qupzilla being available, *now* 15:52:14 but not yet as default 15:52:18 danofsatx: Chrome plugins are not supported at this time, I think, sorry. 15:52:28 drats... 15:52:56 LastPass is the only way I can get into many sites. I'm currently looking for a different option, though... 15:53:13 rdieter: 1. It can be tested from Copr. 2. The snapshot works. 3. I can sign up as a (co)maintainer for that one package. 15:53:41 Kevin_Kofler: link to copr? I'd like to take a look at it. 15:53:43 danofsatx: It has been tested by at least 3 or 4 people already, feel free to do your own testing! 15:53:49 1. can be fixed within a few days hopefully, once imported 15:54:15 Kevin_Kofler: can you (or some qupzilla maintainer) reach out to upstream to see if there are any concrete plans/schedules ? 15:54:22 * danofsatx can test on i7, i3, and Core 2 Duos 15:54:24 danofsatx: https://copr.fedoraproject.org/coprs/kkofler/qtwebengine/ 15:54:25 (for item 2) 15:54:58 danofsatx: also requires Qt5 copr, https://copr.fedoraproject.org/coprs/g/kdesig/Qt5/ 15:55:00 fwiw 15:55:16 rdieter, tosky: I consider your reactions to be just an attempt to delay things enough to miss the change deadline. 15:55:28 The Change should be submitted NOW. 15:55:42 Kevin_Kofler: I consider your reacion to be just a way to have what YOU want 15:55:44 There is NO requirement that it be testable on the day of submission. 15:55:44 as I wrote, even if it was released now, given the new code, before moving to default I would not promote as default 15:55:53 Kevin_Kofler: if you insist on keeping the proposal as is, then simply consider me -1 15:55:55 for an entire cycle 15:56:15 tosky: Firefox was made default immediately. 15:56:22 Kevin_Kofler: like it's a new software 15:56:23 Same standards for all. 15:56:30 Kevin_Kofler: and firefox has been tested extensively already 15:56:33 it's not the same, it's an existing software 15:56:38 totally existing 15:56:39 we already knew how well it worked 15:56:56 We didn't, it was never on a KDE Spin. 15:56:57 sorry, I got to go, my vote is -1 anyway 15:57:17 oh, so it came from the outer space, it was never packaged on Fedora 15:57:18 (Firefox) 15:57:33 * danofsatx curses at dnf 15:57:43 Sigh… See why I was so strongly against Firefox? Now you are fighting for the temporary solution and blocking the real one. 15:57:51 It was the same with NetworkManager-gnome. 15:58:03 any other kde-sig member(s) want a vote for the record? 15:58:13 Hacks that are supposed to be for one release get prolonged because you don't have the balls to ship the native solution. 15:58:14 +1 15:58:20 -1 15:58:41 I don't understand the idea of waiting a whole release cycle. 15:58:48 The F24 cycle is the cycle. 15:58:48 fwiw, Proposal: We file a Change to make QupZilla 2 the default browser on the KDE (and LXQt if it gets done) Spin for F24. I would be the change owner, the KDE SIG would be listed as supporting co-owner. 15:59:26 The Change deadline has NOT passed. The whole goal of the Change process is to deal with this kind of changes. 15:59:37 So why should we wait for F25 instead? 15:59:48 This is not how Fedora changes work. 15:59:49 Kevin_Kofler: new software throught out in the wild, like putting Plasma 5.0 immediately out as default 16:00:00 (i don't see why lxqt has to depend on what kde does, fwiw) 16:00:11 fwiw, the file structure/naming of the Qt5 copr breaks the 'dnf copr enable' command 16:00:13 Kevin_Kofler: ah, so when Plasma 6 will be out will you vote to ship it as default immediately? Good luck with that 16:00:15 rdieter: I was talking to the qupzilla main developer 16:00:22 pino|work: LXQt can do its own thing, of course. 16:00:30 he plan on release v2 as soon as qt 5.6 is released 16:00:34 *plans 16:00:35 marcdeop: thanks 16:00:51 Hopefully they won't be such cowards. 16:00:56 marcdeop: Thanks. 16:01:05 and no, chrome plugins are not supported 16:01:14 So QupZilla 2 looks like very viable for F24. 16:01:21 About Chrome plugins, I knew that. 16:01:26 rdieter: I want to note that Kevin_Kofler insulted personally all of us, and danofsatx +1 him on that 16:01:43 Kevin_Kofler: viable as new addition, not as default *YET* 16:01:50 tosky: His +1 was to the proposal. 16:02:05 tosky: EVERYTHING's more viable as a default than Firefox. 16:02:10 Even wget is a better browser. 16:02:17 true, Kevin_Kofler keep the discussion technical and professional 16:02:24 Kevin_Kofler: this is not helping your proposal 16:02:28 I stated on the record for F23 that I do not support Firefox on Plasma. I am simply maintaining my position. 16:03:00 I don't understand why people here things that there is a conspiracy to keep Firefox around, like we all enjoy it 16:03:08 Right, Firefox is simply THE WRONG browser for a KDE Spin. 16:03:21 ... for you 16:03:22 And now with the signature enforcement, it is not even Free Software anymore. 16:03:29 ditto 16:03:34 I don't enjoy not having a properly integrated solution, but it simply missing and a) no, throwing in a new software immediately is not the solution 16:03:38 danofsatx: I'm assuming your +1 was just placed in an unfortunate place in the record... not as an affirmation that the kde-sig "don't have the balls..." 16:03:52 pino|work: There's a well-defined Free Software Definition. 16:03:54 note that putting uppercase words don't make them as truth 16:04:14 (just like changing Plasma 5.0 as default immediately on the release, which didn't happen) 16:04:21 Removing the freedom to even RUN software if it is not approved by Mozilla does NOT comply. 16:04:23 everyone stop and breathe a minute 16:04:24 Kevin_Kofler: they said it can be disabled in non-branded builds (hello iceweasel) 16:04:29 rdieter: yes, I was responding to your call for votes - I didn't even see Kevin's statement 16:04:45 pino|work: Then I want to see your proposal to package an unbranded build and ship it as the default on our Spin. 16:04:55 Let me strongly suggest we stop discussion and debate on the topic for now 16:04:56 danofsatx: than I apologize that I called your for that, thanks for the clarification 16:05:00 Right now, there's Firefox and there's QupZilla 2, make your pick. 16:05:07 there is no QupZilla 2 16:05:12 Kevin_Kofler: playing the provoking game is not an option for you 16:05:18 tosky: There will be when F24 gets released. 16:05:22 There is 1.9.99 now. 16:05:23 Kevin_Kofler: new software, give it a cycle, and then let's see for F25 16:05:27 a cycle and see 16:05:31 Just like there's Qt 5.6 beta that's already in Rawhide. 16:05:33 -2 for F24 as default 16:05:59 tosky: understood, thanks. 16:06:05 we obviously have fundamental disagreements, and further discussion won't be changing anyminds (if anything, only makes things worse) 16:06:10 We're even happy to ship a beta of Qt (!) in Rawhide, so why not one of QupZilla, which is only really waiting on Qt to be declared stable? 16:06:46 tosky: I don't understand where in the processes you see that we should be waiting a whole release cycle. 16:06:55 Kevin_Kofler: seems you misunderstand, some of us simply want it in rawhide and tested a bit first. 16:07:06 The Change process is clearly made to get a change developed and shipped in ONE release cycle. 16:07:11 (which is the F24 one now) 16:07:23 Kevin_Kofler: if you don't think testing in rawhide is needed, fine, but don't pretend to not understand our position 16:07:27 Kevin_Kofler: the change is not ready, that's the point, and I don't trust a new browser in one cycle 16:07:44 rdieter: Maybe you see it that way, but tosky clearly wants it punted to F25. 16:07:58 Which is just ridiculous at this stage of the release cycle. 16:08:07 Kevin_Kofler: as *default*, I have nothing against shipping it 16:08:15 The change to Firefox was made much much later in the F23 cycle than we are now in the F24 one. 16:08:20 Kevin_Kofler: we wants even more testing, which I don't find unreasonable, but arguing changes nothing 16:08:30 Kevin_Kofler: you won't change his mind, nor he yours, so please drop it 16:08:31 Kevin_Kofler: Firefox already existed 16:08:39 sorry rdieter 16:08:42 * tosky shuts up 16:08:50 Firefox had ZERO testing on the KDE Spin. 16:08:59 It was rushed in during deep freeze (!!!). 16:09:21 Incorrect - Firefox was tested (at least by me) in every release cycle back to F20. 16:09:45 There's a difference between testing something installed with yum install and testing it as the default. 16:09:51 If I counted right, proposal so far had votes: +1/-3 (did miss any?) 16:10:10 (which is, incidentally, another reason why I want QupZilla to be switched to the default NOW, so that that can be adequately tested) 16:10:13 does Kevin's count as a +1? if so, then it's +2 16:10:26 No, I don't count, I'm no longer in the voting members. 16:10:36 oh, that's right. Sorry :/ 16:10:41 * rdieter didn't remember for sure, but didn't see a +1 either 16:11:21 I'm not going to give one, I stepped down and I'm sticking to that decision. 16:11:21 So, let's move forward with getting qupzilla2 into rawhide asap, I assume there's no disagreement on that 16:12:04 and I'd encourage Kevin_Kofler to apply for qupzilla (co)maintainership 16:12:32 that and qt-5.6 final, and qupzilla formal releases will be a very good start to satisfy most of my own concerns 16:12:36 yes, qupzilla into rawhide 16:12:54 I find it really unfair that we switched to Firefox during Final Freeze, yet now for switching away from Firefox, even the normal Change schedule is not good enough for you. 16:13:00 Well, I want the Change to get in by the Change deadline. 16:13:05 all the things into rawhide, actually... 16:13:06 Waiting for all that means we'll miss it. 16:13:23 Now, it's likely going to pass as self-contained and so will be allowed late, but still. 16:13:24 even shipping qtwebengine and a webengine-enabled qupzilla is worthy of documenting/advertising as a f24 change, imho 16:13:59 agreed 16:14:03 I don't understand why we can't submit the change now. It can always be postponed IF the testing doesn't work out. 16:14:28 Kevin_Kofler: submit change now if fine, just leave out the "ship as default browser" part 16:14:34 That's how the Change process works: 1. You submit the Change. 2. You implement it. 3. You test it. 4. You decide to ship it. 16:14:46 You want to do it backwards. 16:15:18 documenting a change for which the relevant sig disagrees with... is backwards? 16:15:53 Huh? You disagreed because you said it needs testing. I'm saying the testing will be done as part of the Change process. 16:16:07 I disagreed for quite a few reasons 16:16:12 testing was only one of them 16:16:25 (I have more, but those were foremost on my mind) 16:16:51 So what I'm going to do is that I'm going to submit a Change in my name documenting the availability of QtWebEngine and QupZilla 2. 16:17:05 +1 16:17:08 +1 16:17:23 Then whether it will be default or not can always be decided later, even during Final Freeze (there is precedent). 16:17:53 yes, thanks 16:18:02 fine by me 16:18:03 If the KDE SIG or individual KDE SIG members want to add themselves to the Change, feel free, but mostly it'll be stuff I'm doing so it'll be my Change. 16:18:17 The KDE SIG would come into play only for the default thing. 16:18:22 that's fair, you're doing 99% of the work 16:18:37 (maybe closer to 99.9) 16:19:50 getting qtwebengine packaged, reviewed, and working this well in such a short period of time is fantastic 16:20:30 I don't understand why we can't tentatively plan to default to it right now, with the contingency plan of sticking to Firefox (or reverting to Konqueror :-) ), but meh… 16:21:28 #topic open discussion 16:21:40 we're a bit over our time, any last comments before closing the meeting? 16:21:58 By the way, my latest QtWebEngine no-sse2 branch scratch build completed, looks like I really have only the Provides/Requires filtering to sort out and then I'll have dual V8 working. 16:23:09 Kevin_Kofler: I think I've confirmed that f23/i686 Qt5 builds in copr work again, fwiw 16:23:29 Kevin_Kofler: and eventually you can move qtwebengine over to https://copr.fedoraproject.org/coprs/g/kdesig/Qt5/ ? 16:24:31 looks like Qt-5.6/el6 is a dead-end in epel at least, upstream has confirmed that 5.6 will require newer compiler provded only by devtools-3 software collection addon 16:24:56 I would like to apologize for my absence lately. Now that my final school semester has started, my schedule has finally smoothed out and I should generally be available for the foreseeable future. 16:25:16 danofsatx: no worries, life happens, thanks for the heads-up 16:25:40 Well, do I have write access to that Copr? 16:26:01 .fasinfo kkofler 16:26:02 rdieter: User: kkofler, Name: Kevin Kofler, email: kevin@tigcc.ticalc.org, Creation: 2007-04-26, IRC Nick: Kevin_Kofler, Timezone: UTC, Locale: en, GPG key ID: 1634F842, Status: active 16:26:05 rdieter: Approved Groups: +svnfedora-kde-artwork fedorabugs cla_fedora cla_done @gitthemes @svnkde-settings art +packager provenpackager gitspin-kickstarts cla_fpca 16:26:25 Kevin_Kofler: oh crap, you're no longer in kde-sig FAS group right? 16:26:37 if not, then no 16:27:36 ok, I guess someone else will have to do it (occasionally submitting rawhide src.rpm's) 16:27:58 I don't see a problem with having a separate qtwebengine Copr, it's also a good place to put qupzilla builds. 16:28:19 I don't think you'll want the Qt5 Copr to replace QtWebKit QupZilla on F22/F23. 16:29:09 QtWebEngine on its own is not all that useful, without at least one application using it. :-) 16:29:20 Developers will know where to get it, hopefully. 16:30:08 But if you want to build it in the Qt5 Copr, you can, of course. 16:31:24 , qupzilla will likely need to remain elsewhere anyway 16:31:36 ok, let's end meeting, thanks everyone 16:31:38 #endmeeting