15:05:18 <rdieter> #startmeeting kde-sig 15:05:18 <zodbot> Meeting started Tue May 24 15:05:18 2016 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:05:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:05:18 <zodbot> The meeting name has been set to 'kde-sig' 15:05:23 <rdieter> #topic roll call 15:05:29 <lupinix> .hello lupinix 15:05:29 <zodbot> lupinix: lupinix 'Christian Dersch' <lupinix@mailbox.org> 15:05:34 <rdieter> hi all, friendly kde-sig meeting starting, who's present today? 15:05:37 * pino|work too 15:05:48 <than> present 15:06:21 <rdieter> #info rdieter lupinix pino|work than present 15:06:30 <rdieter> #chair lupinix pino|work than 15:06:30 <zodbot> Current chairs: lupinix pino|work rdieter than 15:06:59 <tosky> hi 15:07:10 <rdieter> #info tosky present 15:07:11 <dvratil> hi 15:07:16 <rdieter> #info dvratil present 15:07:20 <rdieter> #chair tosky dvratil 15:07:20 <zodbot> Current chairs: dvratil lupinix pino|work rdieter than tosky 15:07:35 <rdieter> #topic agenda 15:07:40 <rdieter> ok, what to discuss today? 15:08:18 <jgrulich> hello 15:09:17 <rdieter> #info jgrulich present 15:09:22 <lupinix> current state of stuff for f24? e.g. thinks to be done before release? 15:09:31 <rdieter> fyi, f24 final freeze on may 31 15:09:46 <lupinix> so in one week 15:11:01 <rdieter> would've liked to get kdepim-16.04 stuff done , but it's probably a bit late to push now (can wait for updates after release date) 15:11:26 <rdieter> anything else besides f24 status? 15:11:37 <lupinix> nothing here 15:11:50 <rdieter> #topic f24 status 15:12:12 <rdieter> ok, another topic I'd like some help on, debugging i686 f24 plasma issues 15:12:42 <rdieter> I dug into it myself yesterday, and it's failing down in qtdeclarative jsruntime/qv4 memory-management stuff 15:12:49 <lupinix> hmmm 15:12:56 <rdieter> *may* be sse2-related 15:13:24 <lupinix> is it failing @i686 in general? 15:13:26 <rdieter> to debug properly myself, I'll probably have to install f24 i686 workstation as a starting point, and maybe do some local builds/debugging 15:13:29 <lupinix> or cpu specific 15:13:37 <rdieter> lupinix: i686 in general 15:13:39 <rdieter> afaict 15:13:50 * rdieter finds bug 15:14:27 <rdieter> .bug 1329715 15:14:29 <zodbot> rdieter: Bug 1329715 [abrt] sddm: drainMarkStack(): sddm-greeter killed by SIGSEGV - https://bugzilla.redhat.com/1329715 15:14:30 <rdieter> has good backtrace 15:14:49 <rdieter> .bug 1331593 15:14:50 <zodbot> rdieter: Bug 1331593 Fedora 24 i686 KDE gets stuck at a black screen on login - https://bugzilla.redhat.com/1331593 15:14:54 <rdieter> ^^ essentially a dup 15:15:14 <rdieter> if not fixed, means we cannot ship a usable i686 kde spin 15:15:39 <lupinix> :( 15:16:00 <rdieter> not a huge deal apparently, it's been broken for a long time, and on one has cared much (yet) 15:16:31 <rdieter> anyway, I will work a bit on it later today hopefully, any help would be appreciated 15:16:51 <tosky> if it's a general memory issue exposed by VMs with low memory? The comment from Adam seems to hint it was reproduced on baremetal too 15:17:18 <rdieter> first thing I was going to try: turn off disabling of sse2 stuff in qt5-qtbase and qt5-qtdeclarative 15:17:20 * jreznik_ is around 15:17:35 <rdieter> tosky: it's not, I saw it on bare-metal laptop with plenty of ram too 15:17:49 <rdieter> #info jreznik_ present 15:19:02 <rdieter> otherwise, I'd suspect some other sort of gcc6 incompatibility (since f23/i686 without gcc6 doesn't have this issue) 15:21:27 <rdieter> kde-sig *could* decide too that supporting i686 anymore isn't worth it, since Qt5 (essentially) requires sse2 which we cannot unconditionally support on fedora 15:22:01 <rdieter> we've hacked around that with success, until now 15:24:10 <lupinix> well, if upstream projects like Qt stop supporting non-sse2, there will be the day where we have to stop support too 15:25:02 * jreznik_ is not against dropping i686... 15:25:33 <rdieter> though, honestly, means we have to make qt5-qtdeclarative at least, no longer available on i686 15:25:49 <nchauvet> sse2 is not available on armhfp, do qt5 enforces neon there ? 15:26:04 <rdieter> and the repurcusions that any package depending on qt5-qtdeclarative means ExcludeArch: i686 15:26:35 <rdieter> nchauvet: good questtion, i think it's still runtime detected on arm 15:27:18 <rdieter> it's just that recent Qt5 releases (5.4?) dropped sse2 runtime detection on i686, since it's ~10 years old, they figured everyone should support it by now. 15:27:31 <lupinix> maybe we could ask Kevin_Kofler, he had to deal with that stuff @qtwebengine some weeks ago in detail 15:27:56 <rdieter> I don't like his webengine hacks either, it's a maintenance nightmare 15:28:14 <rdieter> but I don't mind as long as he's doing (most of) the work 15:28:19 * lupinix does not know details there 15:29:27 <rdieter> so in the short term, would be nice to get fixed for f24 if possible, for f25+ we may have to re-evaluate things 15:29:52 <rdieter> but unless this is fixed, we'll have to simply not ship a i686 spin 15:30:19 <rdieter> ship a f24/kde/i686 spin, that is 15:32:24 <rdieter> but, true, Kevin would be a good motivated candidate to help fix what's going on in libQt5Qml 15:35:06 <rdieter> anything else f24-related ? 15:35:33 <lupinix> what is the state of breeze-gtK? i cannot remember our decision 15:35:45 <rdieter> lupinix: it's broken 15:35:56 <rdieter> not much of a decision to make 15:36:06 <lupinix> so we stick with adwaita (or whatever its called) 15:36:08 <rdieter> as such, we don't install it or use it by default 15:36:11 <rdieter> yes 15:36:14 <lupinix> ok, thx 15:36:32 <rdieter> and the breeze-gtk3 package description has a disclaimer saying so 15:36:38 <lupinix> nice 15:37:08 <rdieter> This package is being provided as a tech-preview only, since it is not yet complete and has 15:37:10 <rdieter> known incompatibilities with gtk-3.20.x. See also: https://bugs.kde.org/show_bug.cgi?id=361066 15:38:14 <rdieter> fwiw, I think there's some github fork that supposedly works, but I haven't looked into it myself 15:38:47 * lupinix will try, but he thinks we should wait for the official fix 15:38:53 * rdieter too 15:39:28 <rdieter> even if it did work ok, iirc, devs said it's still not complete and recommend it not be used by default 15:40:20 <rdieter> moving on... 15:40:20 <rdieter> #topic open discussion 15:40:21 <tosky> I was wondering in the meantime: is it possible to not ship a certain spin for a certain arch at release (GA) time and readd it later during the lifetime of that fedora? 15:40:24 <rdieter> anything else worth mentioning today? 15:40:50 <lupinix> tosky: good question 15:40:57 <lupinix> rdieter: nothing else here 15:40:57 <rdieter> tosky: good question, I do know non-blocking spins sometime to release after GA 15:41:11 <rdieter> sometimes do... 15:41:26 <Southern_Gentlem> ! 15:41:32 <rdieter> Southern_Gentlem: go ahead 15:42:02 <Southern_Gentlem> if a spin doesnt build but it builds afterwards i try to include it in my updated lives isos 15:42:18 <rdieter> Southern_Gentlem: ok, thx 15:42:25 <tosky> good to know 15:42:27 <tosky> and a final question about this issue: if it is sse2 related, did the systems were it was reproduced (including VMs) exposed sse2? 15:42:36 <rdieter> so we may have the option of having an unofficial updated spin available after the fact 15:42:55 <rdieter> tosky: mine does sse2, and it still crashed 15:43:11 <tosky> uhm 15:43:11 <rdieter> first thing I'd hoped (that sse2 being available would help) 15:43:18 <lupinix> well it builds fine (except the random failures of lorax...) but doesn't work, so we have to tell releng to exclude? 15:43:49 <Southern_Gentlem> fit lorax 15:43:52 <Southern_Gentlem> fix 15:47:30 <rdieter> alright, looks like things got quiet, thanks everyone 15:47:32 <rdieter> #endmeeting