15:06:38 #startmeeting kde-sig 15:06:38 Meeting started Tue Feb 17 15:06:38 2015 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:06:38 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:06:40 #meetingname kde-sig 15:06:40 The meeting name has been set to 'kde-sig' 15:06:44 #topic roll call 15:06:46 o/ 15:06:51 \o 15:06:53 hi all, friendly kde-sig meeting, who's present today? 15:07:01 hello 15:07:02 Present. 15:07:38 o/ 15:07:40 * satellit liistening 15:07:49 present 15:08:22 #info rdieter tosky jgrulich Kevin_Kofler pino|work satellit than 15:08:38 * jreznik is here 15:08:40 #info danofsatx, ltinkl send regards 15:08:42 #info jreznik present 15:08:53 #chair jreznik tosky jgrulich Kevin_Kofler pino|work satellit than 15:08:53 Current chairs: Kevin_Kofler jgrulich jreznik pino|work rdieter satellit than tosky 15:08:57 #topic agenda 15:09:11 alright agenda, what to discuss today, topic suggestions? 15:09:50 f22 theming + plasma 5 change progress (deadline is in one week) 15:09:59 hi :) 15:10:08 #info dvratil present 15:10:55 Also how to deal with Applications 15.04 and Plasma 5.3. 15:11:44 See https://fedoraproject.org/wiki/Releases/22/Schedule for how the schedules (don't) align. 15:11:47 ok, that's a good start... 15:11:59 #topic f22 theming + plasma 5 change progress 15:12:03 jreznik: ? 15:12:24 Wouldn't that better be split into 2 topics? 15:12:41 I'd say f22 theming is part of overall plasma 5 change 15:12:57 but theming was discussed a bit on #fedora-kde earlier today 15:13:21 we should make sure we will be ready, check how the old wp works, be prepared 15:13:25 * marcdeop is here... 15:13:40 #info marcdeop present 15:13:42 and reminder - the change has to be in MODIFIED state next Tuesday, it means testable 15:14:21 It's already testable, isn't it? 15:14:34 Unless GCC 5 broke it, but then that's not OUR fault. 15:14:37 It worked before GCC 5. 15:14:50 And GCC 5 also breaks KDE 4. 15:14:51 important pieces that need more work: adapting comps, kickstart/live-image 15:15:42 any other priorities we should be working on? 15:16:04 besides the already-mentioned artwork/theming 15:16:12 * marcdeop wonders what he can help in.... 15:17:20 .bug 1135103 15:17:23 rdieter: Bug 1135103 Plasma 5 Tracker - https://bugzilla.redhat.com/1135103 15:17:45 also have ^^ , plasma5 blocker, anything worth highlighting there? 15:19:11 I'll likely be looking into comps (and kickstart) myself this week 15:19:19 For comps, we should also check the F20 and F21 comps for the package splits done lately. 15:19:29 E.g. kmenuedit split out from kde-workspace. 15:19:30 jreznik: any eta on design team wallpaper selection? 15:20:11 it may take some time, so maybe what I'd do is to use f21 wp to test it/prepare package 15:20:35 shrug, I think we'll just stick to plasma5 upstream default until something is ready (it's less work) 15:21:06 but I suppose preparing something won't hurt either 15:21:10 rdieter: it may work for alpha as it's defined as "wp has to be different to f21" 15:21:27 Shipping the Plasma 5 default, yes, but that doesn't preclude working with the F21 wallpaper to have the processes ready. 15:21:51 But no, we don't want to ship with the F21 wallpaper as the default, that's sure. 15:22:23 (but making the Fn, n<22, wallpapers "just work" when installed from the repo would still be nice) 15:22:40 Kevin_Kofler: that's not a blocker though, we could fix that anytime, including after GA 15:22:41 (Way too much artwork was lost because the format changed and nobody cared about the old artwork.) 15:22:42 maybe if I'd have some spare time, I can take a look on other QML theming part 15:23:09 rdieter: Of course not, but having the processes ready to make the F22 wallpaper work when it comes out IS important. 15:23:20 So jreznik's idea to try with the F21 wallpaper is not bad. 15:23:26 (We just don't want it as the default.) 15:23:50 What's the definition exactly? Different from THE previous release? Or from ALL previous releases? :-) 15:23:54 sure, anyone willing to take the artwork/wallpaper task ? 15:24:20 I ask because if it's only from THE previous release, we could ship the F20 wallpaper, or some nice older one like Solar or Verne. :-) 15:24:35 Kevin_Kofler: previous, so it's clear you're running f22 not f21 15:24:58 So going back to n-k, k≥2 would be valid? :-) 15:25:22 we could pull a gnome3 and insist on shipping the upstream default (once) :-/ 15:25:49 We will be doing that by default anyway until Design comes up with something. 15:25:50 (fallback plan if no one's able to work on it :) ) 15:26:31 We can't package something that doesn't exist (but as jreznik said, we can try with the older wallpapers). 15:26:54 Kevin_Kofler: and then it will be super easy to switch the trigger 15:27:04 Right, that's the point. 15:28:00 just quick fyi, major milestone yesterday resolved a couple important gcc5 issues. fixed qt4 FTBFS and one qt5-related crasher (caused by gold linker) 15:28:28 good to hear and thanks for hunting it 15:28:44 thanks mostly to smani 15:28:53 he found that qt5 one 15:29:22 anyway, we're back down to the startkde can't sync dbus , and same/old qt5 multiple display issue(s) 15:30:00 Has anybody tried reverting dbus to an older build, to see whether it's dbus's fault or not? 15:30:15 original reporter on that bug said it happened with the older dbus too 15:30:23 (that was the original report) 15:30:43 orignal report was with 1.8.14 15:31:26 .bug 1191171 15:31:28 that one 15:31:29 rdieter: Bug 1191171 "Could not sync environment to dbus." (startkde) - https://bugzilla.redhat.com/1191171 15:33:05 https://bugzilla.redhat.com/show_bug.cgi?id=1191171#c7 in particular 15:34:08 anyway, anything else plasma5/feature related to discuss today? otherwise, will move on soon 15:35:12 does it work before (build with gcc <5) ? 15:35:32 than: reportedly yes 15:35:51 probems started as soon as plasma-workspace was built with gcc5 15:36:09 The thing is, startkde is shell code, not C/C++ code. 15:36:31 Either qdbus-qt5 is broken, or some tool startkde is starting to decide what to pass to qdbus-qt5. 15:36:35 it calls /usr/libexec/ksyncdbusenv 15:36:43 and that call returns an error 15:36:56 it looks like new gcc miscompiled the kde code again 15:37:01 Ah, it's not a command-line qdbus call? Then it could be a GCC issue alright. 15:37:37 ltinkl even offerred a workaround patch to change the code a bit, but it didn't help 15:38:03 Ah right, I vaguely remember that. 15:38:22 http://pkgs.fedoraproject.org/cgit/plasma-workspace.git/tree/plasma-workspace-ksyncdbusenv.patch 15:38:33 but apparently the error is the same 15:38:59 I see the patch now. I guess then the error is not the QStringList construction, but the QDBus code. 15:39:06 that said, one person reporting a similar bug said the recent rebuilds fixed things 15:39:12 * rdieter looks 15:39:50 .bug 1190817 15:39:52 rdieter: Bug 1190817 krunner - Segmentation fault - https://bugzilla.redhat.com/1190817 15:40:29 maybe we could try to build with -O0 and see if it works, of course it's not a fix but more a workaround temporary before we know how to fix the issue 15:40:55 maybe, I've no better ideas 15:41:18 i will try next days 15:41:33 At least it'd tell us WHAT is being miscompiled. 15:41:42 Kevin_Kofler: yes 15:41:47 Of course, it's no guarantee that -O0 will help either. 15:42:22 Kevin_Kofler: but it's worth trying to build with -O0 15:42:49 we need to know why the code is miscompiled with gcc-5 15:43:24 or maybe it's the fault in kde code 15:44:45 not sure if it's worth reverting that patch first or not, I'll leave that to you 15:44:53 let's move on to scheduling then 15:44:55 So it's indeed all done in C++ code, the shell script (startkde.cmake, which I'm looking at now) only starts @CMAKE_INSTALL_FULL_LIBEXECDIR@/ksyncdbusenv with no arguments. 15:45:08 That said, there are other things in startkde that I think we should fix. 15:45:17 agreed 15:45:38 yes 15:45:40 1. It prepends the Qt bindir to PATH. We removed that from the KDE 4 startkde, it needs to go away also from the Plasma 5 one. 15:45:42 It breaks Qt 3. 15:45:57 And also qtchooser setups, depending how the user set them up. 15:46:03 Kevin_Kofler: please file a bug (or just patch it) 15:46:28 2. The default font family is Oxygen. Do we really want that? IMHO, we should default to plain "Sans" / "Monospace", which is aliased to DejaVu systemwide. 15:46:30 long term, we should probably just ship our own startkde 15:46:38 +1, as we've done in KDE 4. 15:46:43 That's exactly what I want to do, in fact. 15:47:09 (Fixing 2. also means we could get rid of the Requires: oxygen-fonts.) 15:47:19 I wouldn't mind losing oxygen fonts, they look bad to me (on my screens at least), but I don't feel strongly about that 15:47:36 They also have nowhere near the glyph coverage of DejaVu. 15:47:51 as i remember Oxygen font has rendreing issue, 15:48:08 i'm really against it as default 15:48:09 So, agreed to change the default back to the systemwide default? 15:48:17 Kevin_Kofler: +1 15:48:31 Kevin_Kofler: I don't think we have enough present to decide that now, I'd suggest proposing onlist 15:48:32 (The real systemwide default (DejaVu), of course, not the Cantarell font GNOME Shell uses as the default. :-) ) 15:48:52 but consider me a tentative +1 too 15:49:03 no Cantarell font please :) 15:49:13 I think we definitely all agree on that. :-) 15:49:50 I'm used to Sans Serif, so +1 for not making oxygen-fonts as default or requirement 15:49:59 (The funny thing is that I had to fix a hardcoded reference to Cantarell in Calamares of all things. ^^ Upstream agreed with me that hardcoding a GNOME font is not a good idea. :-) ) 15:50:54 I suppose a compromise of sorts would be to at least continue to install oxygen-fonts by default, so users will always have them available 15:52:34 * than is fixing build issue in qt5-qtwebkit 15:52:53 rdieter: that's not a bad idea 15:53:00 rdieter: I'm opposed to installing anything that's not required by default. 15:53:04 Download sizes matter. 15:53:22 than: I suspect it may suffer the same problem qt4's bundled webkit did 15:53:34 (it tried to detect gcc version, but only checked up to v4) 15:54:33 Kevin_Kofler: it's relatively small in this case 15:54:49 anyway, let's get to scheduling before we run out of time 15:55:01 #topic f22 schedule vs kde-apps/plasma schedule 15:55:14 https://fedoraproject.org/wiki/Releases/22/Schedule references both 15:55:19 #link https://fedoraproject.org/wiki/Releases/22/Schedule 15:55:20 rdieter: it's another issue in qt5-qtwebkit. it loooks like a conflich with new glib in rawhide 15:55:40 s/conflich/conflict 15:55:47 ok 15:55:48 :( 15:56:22 as far as scheduling goes, I think both plasma-5.3 and kde-apps-15.04 are too late to include in f22 GA 15:56:43 that is, unless either includes killer features we *must* have 16:03:08 now, if any slips happen we can certainly reconsider 16:03:20 (The GCC already team tried to help with that, it seems. ;-) ) 16:03:36 Uh, shuffled sentence there… 16:03:41 woo, got confirmation in startkde bug that the latest qt5 build fixes it 16:03:41 (The GCC team already tried to help with that, it seems. ;-) ) 16:03:49 startkde/dbus bug, that is 16:04:01 Good, looks like it was a GCC bug, too. 16:04:19 either gcc or gold(linker) 16:04:37 er, wait, the linker thing was just qt4 16:04:39 Yeah, Qt using gold by default is silly, there's a reason it's not the default. 16:04:56 Oh well, GCC 5 then. 16:05:17 ok, I'm confusing myself again 16:05:25 yes, it was qt5 that used gold 16:05:42 I forgot that qt5-qtbase actually uses a configure script (vs other modules that use qmake) 16:05:51 IMHO, we should just permanently stick to --no-use-gold-linker and use it everywhere. 16:06:00 maybe :-/ 16:06:02 great that startkde/dbus bug is fixed! 16:06:05 I don't see a valid reason why Qt needs to use a different linker than Fedora default. 16:06:24 It saves a few seconds of build time, I guess, but who cares? 16:06:56 alright, hour is up, any last comments before closing meeting? 16:09:58 I'll take that as 'no' 16:10:01 thanks everyone! 16:10:02 #endmeeting