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