15:03:32 #startmeeting KDE SIG Meeting 15:03:32 Meeting started Tue Feb 10 15:03:32 2015 UTC. The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:32 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:03:35 #meetingname kde-sig 15:03:36 The meeting name has been set to 'kde-sig' 15:03:41 #topic Roll call 15:03:46 * Kevin_Kofler is present, who else? 15:03:51 hello 15:03:52 here (for awhile) 15:04:18 here 15:06:46 me 15:07:08 hi 15:08:55 danofsatx: Ping? 15:08:57 jreznik: Ping? 15:09:04 #chair jgrulich rdieter heliocastro pino|work tosky ltinkl danofsatx jreznik 15:09:04 Current chairs: Kevin_Kofler danofsatx heliocastro jgrulich jreznik ltinkl pino|work rdieter tosky 15:10:11 hi all 15:10:51 #chair dvratil 15:10:51 Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich jreznik ltinkl pino|work rdieter tosky 15:10:58 * jreznik is around 15:11:03 #chair jreznik 15:11:03 Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich jreznik ltinkl pino|work rdieter tosky 15:11:48 agenda? 15:11:55 qt and gcc 5 ? 15:11:58 #info Kevin_Kofler, jgrulich, rdieter, heliocastro, pino|work, tosky, ltinkl, dvratil, jreznik present. 15:12:04 heliocastro: Is there a problem? 15:12:15 I started to get strange segfaults on lxqt-session and panel today 15:12:26 Ewww… 15:12:30 I'm now installing all debug packages, but the gdb points to Qt 15:12:35 OK, we can put that on the agenda. 15:12:49 Otherwise, I guess F22 Plasma 5 status. 15:13:38 *supposedly*. the way gcc5 was introduced to rawhide did not break ABI 15:14:01 (because certain c++-11 features were not enabled) 15:14:12 Aha 15:14:14 Look 15:14:16 https://bugzilla.redhat.com/show_bug.cgi?id=1190817 15:14:23 This matches with my segfault 15:14:53 and is opened after te rebuild 15:14:59 fun :-/ 15:15:01 #topic GCC 5 miscompiling Qt? 15:15:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=1190817 15:15:17 .bug 1190817 15:15:20 Kevin_Kofler: Bug 1190817 krunner - Segmentation fault - https://bugzilla.redhat.com/1190817 15:15:32 Qt was recompiled ? 15:16:08 I don't think we have enough infomation to conclude anything, but possible 15:16:15 So I need a backtrace with at least debugging information. 15:16:28 I don't think this would be GCC-related, I've seen this crash couple times 15:16:33 Disassembly around the program counter $pc might also be helpful to see what's going on. 15:16:34 does the bug as-is not have enought -debuginfo? 15:16:49 The backtrace in the bug has no debuginfo. 15:16:50 if not, heliocastro, can you generate a more useful backtrace and post to the bug? 15:16:57 Well, only MiniDebugInfo, which as you know is entirely useless. 15:17:07 looks related to the screwed up XCB integration 15:17:21 It's telling us things like QMetaObject::activate(QObject*, int, int, void**), but no line number, no variables. 15:17:35 The report also does not include registers and disassembly. 15:17:37 yeah, #2 0x00007fffed5a6fd2 in QXcbConnection::updateScreens() () at /usr/lib64/qt5/plugins/platforms/libqxcb.so 15:17:50 yup 15:17:56 So all I know is that it is crashing SOMEHWERE in QMetaObject::activate. 15:18:02 the QMetaObject::activate crash will be because this is nul 15:18:04 null 15:18:06 fyi, recall we're carrying a non-upstream patch related to screens, which may or may not be related 15:18:09 I need at least debuginfo OR registers/disassembly. Ideally both. 15:18:14 Nope, is qt 15:18:37 Is crashing on signals 15:18:59 Oh, the usual signal-slot use-after-free bug? 15:19:07 (Fix: delete → deleteLater.) 15:19:23 Then we'd just need to know what is being deleted too early, then the fix would be trivial. 15:19:44 QMetaObject::activate 15:19:57 sender->d_func() ( crash ) 15:20:36 It's the sender that's null, not the receiver? 15:20:49 That's fun, it's a new version of the use-after-free bug, not the usual one. 15:20:50 sender 15:20:52 null 15:21:12 Exactly 15:21:40 Ids after ScreenAdded call 15:21:42 Why does QMetaObject::activate need the sender at all? Is that something new in Qt 5 or even 5.n? 15:22:03 (That'd explain why we're now getting this crash, the code might not expect to need the sender be valid at this point.) 15:22:35 screenAdded is calling with null 15:24:25 rdieter: Where is the non upstream patch ? qt5-qtbase ? 15:24:34 yes, http://pkgs.fedoraproject.org/cgit/qt5-qtbase.git/tree/qtbase-opensource-src-5.4.0-QTBUG-42985.patch 15:24:50 see also: 15:24:53 .bug 1083664 15:24:55 * heliocastro recompiles without patch 15:24:56 rdieter: Bug 1083664 Qt5 application crashes when connecting/disconnecting displays - https://bugzilla.redhat.com/1083664 15:25:01 https://bugreports.qt.io/browse/QTBUG-42985 15:25:53 I think there's a later candidate referenced in 42985 too 15:26:37 but heliocastro's suggestion of testing without it makes sense. it's an easy thing to try at least 15:26:59 Already compiling here 15:27:05 (though others' comments imply it's not responsible for this problem) 15:27:13 But it crashes on same code as the patch 15:27:41 heliocastro: ok, report back in the bug if it helps or not. either way, try to get a better backtrace 15:27:48 and post there too, if possible 15:27:58 So maybe the patch is not sufficient to fix the bug and we need some different fix? 15:28:27 the crash the patch fixes should only happen when switching displays 15:28:27 #info GCC 5 probably not to blame (pending further investigation). 15:28:46 #info We suspect a relation to QTBUG-42985 and/or to the patch supposed to fix it. 15:28:47 (if I understand things correctly) 15:28:56 #link https://bugreports.qt.io/browse/QTBUG-42985 15:29:04 #link https://bugzilla.redhat.com/1083664 15:29:10 #link http://pkgs.fedoraproject.org/cgit/qt5-qtbase.git/tree/qtbase-opensource-src-5.4.0-QTBUG-42985.patch 15:29:23 let's see how fast mock will be 15:29:41 #action heliocastro is testing a Qt build without the patch. 15:31:34 we need check too if Qt was rebuilt on gcc5 15:32:06 Because patch can be good, and error could be triggered by gcc5 like comment #16 15:32:15 I can figure that out quickly, let me check Koji. 15:32:30 * rdieter has to go soon, wanted to get https://fedoraproject.org/wiki/SIGs/KDE/Brno_Hackfest_2015 into meeting log, that we had a fruitful hackfest after devconfcz 15:32:44 * rdieter waves bye 15:33:13 i'm not sure that, in the aforementioned patch, removing ~QScreen is the best idea 15:33:17 other folks can give more details, if I missed anything 15:33:23 https://kojipkgs.fedoraproject.org//packages/qt/4.8.6/21.fc22/data/logs/x86_64/root.log 15:33:30 gcc-4.9.2-5.fc22 15:33:34 at most make it empty, but removing a dtor in a public class is a no-go 15:33:49 So no GCC 5 was used. 15:33:49 Oh wait, that's Qt 4, silly me. 15:33:51 Kevin_Kofler: Qt 5, not 4 15:34:07 qt5-qtbase is what I need to check. 15:34:26 https://kojipkgs.fedoraproject.org//packages/qt5-qtbase/5.4.0/11.fc22/data/logs/x86_64/root.log 15:34:34 Same, gcc-4.9.2-5.fc22. 15:35:08 /me is around 15:35:16 #chair than 15:35:16 Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich jreznik ltinkl pino|work rdieter than tosky 15:36:22 plasma-workspace: https://kojipkgs.fedoraproject.org//packages/plasma-workspace/5.2.0/6.fc22/data/logs/x86_64/root.log 15:36:38 This one was built with gcc-5.0.0-0.9.fc22. 15:36:53 Ok, so i will need to do two tests 15:37:01 So there could be either a silent ABI break in GCC or a miscompilation of Qt inlines by GCC 5. 15:37:04 with and without patch compiled on qt5 15:37:07 gcc5 15:37:19 Or of course the bug could be unrelated to GCC 5. 15:37:58 Too many ifs 15:38:34 But the fact that the crash happens on the patch code is a start to look 15:40:30 OK, I suggest we move on, you can report later on the results of your investigations. 15:40:49 #topic F22 Plasma 5 status 15:41:10 Any news there, other than the aforementioned crash? 15:41:25 dvratil: ↑ 15:41:57 dvratil: Did you find a possible solution on the translation files issue ? 15:43:19 I'm working on QXCB patches, that might fix the crash, I don't think this is ABI related 15:43:41 F22 in Plasma 5 seems to work, kinda...we started stripping kde-workspace to bare minimum with rdieter on Sunday 15:44:01 heliocastro: I basically wrote my own RPM macro with much saner sed regex 15:46:32 We should really try to get %find_lang fixed. 15:46:47 The support for .qm files has several issues, this also affects Qt-only packages. 15:48:29 I can try, but for now we need this fixed soon 15:49:11 Sure. 15:52:04 OK. 15:52:07 #topic Open discussion 15:52:39 just minor update: I'm working on KF5 5.7.0 update, which will be oficially released on Thursday 15:52:58 So FYI, I have ufw and ufw-kde now packaged (the Uncomplicated FireWall with its KDE frontend (KCM)). I don't have them through review yet. 15:53:43 One issue for Rawhide is that the KCM is not ported to KF5 yet (at least last I checked). :-( 15:54:21 Also, packaging that stuff was a royal PITA, I had to heavily patch UFW to make it work right. (Upstream does hacks such as hardcoding /lib as the location for writable files.) 15:54:43 In hindsight, my time would have been better spent on trying to write a KDE frontend for firewalld. 15:55:12 Still, if you want a KDE-based firewall, UFW-KDE is there at least for F21. (For F22/Rawhide, it only works through kcmshell4 right now.) 15:56:42 In other news, the qt5-style-oxygen from plasma-oxygen 5.0.2 is now available in F20 and F21 stable updates. I sent the stable push request from the Brno-Vienna train. :-) 15:56:42 as i know Thomas (upstreamer) is porting system-config-firewall in qt 15:57:22 than: you mean firewall-config ? system-config-firewall is dead 15:57:45 system-config-firewall is the one for the deprecated iptables.service, firewall-config is the firewalld one. 15:58:20 I wouldn't be unhappy about an s-c-firewall port (I still refuse to use firewalld), but in the end, a firewall-config port would be more useful to Fedora. 15:58:42 sorry i mean firewall-config for frewalld 15:58:44 Agreed 15:59:30 Yay, so what do you think, should I just let the UFW mess bitrot in my Kannolo Copr and try for the Qt firewalld-config in the long run? 15:59:53 Or is it worth trying to get the UFW stack (well, UFW and UFW-KDE, I don't care about the GTK+ frontend they also have :-p ) into Fedora proper? 16:00:21 See for yourself: http://svn.calcforge.org/viewvc/kannolo/trunk/packages/ – the patches to ufw are not pretty. :-( 16:00:33 But then again, it works now, at least for me in my limited testing. 16:00:36 i'm kinda/sorta here now. Sorry, system updates on my network are taking precedence at $dayjob 16:01:29 This one is particularly ugly: http://svn.calcforge.org/viewvc/kannolo/trunk/packages/ufw/ufw-0.34~rc-libexec-dir.patch?revision=111&view=markup 16:02:01 UFW upstream installs both writable files and libexec files to /lib/ufw, and even uses the same variable for both, where they use variables at all (there are also plenty of hardcoded paths). 16:03:33 ufw-kde doesn't actually need patches (for now… the KF5 port would be a patch if upstream doesn't do it), but it depends on UFW which is heavily patched. 16:04:21 All the pure-KDE distros are currently using ufw-kde as their firewall solution, they usually just ship vanilla upstream and don't care about nasty things such as it writing to /lib. 16:04:58 Nor about the fact that mDNS and UPnP ports are hardcoded open in the handwritten rules files, so they cannot be closed through the KCM (and in fact the KCM doesn't even show that they're open!). 16:05:28 My patches fix that. 16:06:20 (I did keep DHCPv6 in the hardcoded section, unlike firewalld where that's also a normal rule.) 16:07:29 It's just me and my weird OCD, but I'd want that to be user-configurable also. 16:09:17 You can edit /etc/ufw/before6.rules if you want. But I guess I could also make it a normal rule. (I only learned at DevConf that firewalld does it that way.) 16:09:47 The old system-config-firewall had DHCPv6 hardcoded, I think. 16:10:00 Let me check. 16:10:42 Yeah, I don't see a checkbox anywhere, so I guess it's hardcoded open. 16:11:08 So, is anybody interested in seeing UFW and ufw-kde in Fedora? I.e., should I submit it for review? 16:14:45 Doesn't look like a lot of interest. :-( 16:15:20 I guess I can try to submit in anyway, and see if I find a reviewer. 16:15:27 *submit it 16:15:50 But how long I'll be able and willing to support it, I don't know either. 16:16:08 If the firewalld Qt frontend happens soon, UFW can get lost for all I care. 16:16:26 Otherwise, I need UFW-KDE to ship a pure KDE experience. 16:17:10 I don't really trust twoerner's promises because he also promised a C version of firewalld and it did not happen. 16:18:22 Anything else or can I close the meeting? 16:20:08 Argh, qt5-style-oxygen has file conflicts with kde-l10n! 16:20:25 liboxygenstyleconfig.mo 16:20:43 Why was that not caught in the week of testing? 16:20:46 I can't install it now. 16:20:48 Grrr! 16:22:28 #endmeeting