kde-sig
LOGS
15:07:56 <Kevin_Kofler> #startmeeting KDE SIG Meeting
15:07:56 <zodbot> Meeting started Tue Nov 26 15:07:56 2013 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:07:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:08:01 <Kevin_Kofler> #meetingname kde-sig
15:08:01 <zodbot> The meeting name has been set to 'kde-sig'
15:08:04 <Kevin_Kofler> #topic Role call
15:08:12 * Kevin_Kofler is present, who else?
15:08:20 * mbriza too
15:08:56 <rdieter> here
15:10:10 <than> present
15:11:54 <Kevin_Kofler> ltinkl: Can I mark you present? :-)
15:12:10 * ltinkl is semi-present ;)
15:12:18 <Kevin_Kofler> jreznik: And you?
15:13:12 * jgrulich is present
15:13:32 <Kevin_Kofler> #chair mbriza rdieter than ltinkl jgrulich jreznik
15:13:32 <zodbot> Current chairs: Kevin_Kofler jgrulich jreznik ltinkl mbriza rdieter than
15:13:56 <Kevin_Kofler> #info Kevin_Kofler, mbriza, rdieter, than, jgrulich present, ltinkl "semi-present".
15:14:01 <Kevin_Kofler> #topic Agenda
15:14:23 <Kevin_Kofler> So I guess the main focus should now be on F20 status.#
15:14:28 <Kevin_Kofler> -#
15:14:28 * jreznik is around - quite a busy
15:14:36 <jreznik> Kevin_Kofler: yep please
15:14:47 <Kevin_Kofler> #info jreznik is around – quite busy.
15:15:12 <Kevin_Kofler> SDDM is the main source of trouble I think, so we'll start with that.
15:15:19 <jreznik> for F20, there are two proposed blocker bugs
15:15:43 <Kevin_Kofler> Otherwise, is there anything else worth discussing? 4.12 prereleases maybe… But F20 is more important right now.
15:16:06 <Kevin_Kofler> jreznik: Do you have the IDs handy?
15:16:41 <mbriza> ok, so, sddm: i tested the image Adam used - it freezes as he said, either we (i) can try fixing it some more or revert to kdm, or, hmmm, crazy idea: use kdm only on live images
15:16:48 <mbriza> rdieter: you said you hit the bug too on your machine?
15:16:58 <Kevin_Kofler> #topic SDDM status
15:17:22 <rdieter> mbriza: not sure it was the same, but at least similar
15:17:42 <mbriza> according to the two logs i saw yesterday in the evening, it's the same, i think
15:17:52 <rdieter> couldn't login with 0.22 build at all, then it would seemingly hang after password (systemctl stop or restart would take ~2 minutes)
15:18:04 <mbriza> and it's something i thought i have fixed (because i had been getting that too while writing the patch)
15:18:56 <rdieter> anyway, yeah, kdm is there waiting and ready if we need a reliable fallback.  question is, are we to the point of implementing fallback plan yet or not?
15:19:27 <rdieter> mbriza: do you have a grasp of what's going wrong yet, and/or an eta to resolve it?
15:19:32 <jreznik> Kevin_Kofler: yep, I have
15:19:35 <mbriza> grasp: yes, ETA, not at all
15:20:30 <rdieter> flipping back to kdm should be fairly easy/trivial, so I'd say continue working on making sddm usable and resolve blockers, until QA/releng forces our hand
15:20:46 <mbriza> when do you think that will happenM
15:20:47 <mbriza> ?
15:21:05 <rdieter> otoh, we could just play it safe, avoid possible panic/rush, and just revert now, and push it off for f21
15:22:15 <rdieter> final release is dec 10, final change deadline today
15:22:20 <rdieter> not much more time to wait
15:22:41 <mbriza> i'm undecided on this, honestly, i'm quite fed up with the problem and seeing it won't probably be end, it seems more sane to include a feature-complete bug-free release in 6 months
15:22:44 <rdieter> after today, only blocker bugs and freeze exceptions are allowed
15:22:54 <mbriza> *be the end
15:23:43 <rdieter> I think I'd propose pushing sddm feature back to f21 then.  comments, votes, objections?
15:24:23 <Kevin_Kofler> +1
15:24:24 <mbriza> no objections from me
15:24:49 <Kevin_Kofler> What is needed to switch back? comps changes for sure, anything else?
15:25:01 <jgrulich> +1
15:25:15 <mbriza> kickstarts
15:25:16 <Kevin_Kofler> Is the theming set up properly for KDM already? I hope so! (It's needed in any case for upgrades from F19.)
15:25:20 <rdieter> Ill have to review it, but I *think* not much more than just comps and maybe kickstart
15:25:31 <Kevin_Kofler> Ah right, the autologin snippet in the live kickstart(s).
15:25:33 <rdieter> kdm theming is good
15:25:34 <mbriza> theme is fine
15:26:33 <rdieter> than, ltinkl, dvratil, jreznik : ^^, any comment on proposal to revert to kdm, push sddm feature back to f21?
15:27:13 <rdieter> another thing, reach out to docs/release notes folks, make sure mention of sddm gets removed there too
15:28:48 <ltinkl> +1 for postponing sddm to F21, life doesn't end at F20 :)
15:28:50 <jreznik> pretty late change, has to be communicated on many places but if it seems to be what we want, I don't have objections
15:28:59 <than> rdieter:i think it's better to push sddm  to f21
15:29:13 <than> +1
15:29:16 <jreznik> and I can take care of that communication to announcement, relnotes
15:29:19 <rdieter> k, sounds like we have a consensus, thanks
15:29:46 <mbriza> it at least got attention to the DM itself :)
15:29:49 <jreznik> and would be great to coordinate with qa - adamw
15:29:56 <rdieter> #agreed sddm blocker bugs not safely resolvable, revert to kdm for f20, push sddm feature back to f21
15:31:33 <Kevin_Kofler> Of course SDDM will stay available as a tech preview, this is just about the default.
15:32:22 <mbriza> sure, and i'll get time to fix the authentication stack properly and separately - it will be a completely separate library over time
15:32:37 <Kevin_Kofler> Yeah, that makes sense.
15:32:45 <Kevin_Kofler> #topic F20 status
15:33:01 <Kevin_Kofler> jreznik: So, are those blockers all SDDM-related or do we have other open issues?
15:33:14 <Kevin_Kofler> The ones I can think of are SDDM's fault, reverting to KDM should "fix" them.
15:33:16 <jreznik> not yet blockers, only proposed
15:33:24 <jreznik> .bug 969524
15:33:30 <zodbot> jreznik: Bug 969524 plasma widgets unclickable on arm - https://bugzilla.redhat.com/show_bug.cgi?id=969524
15:33:38 <Kevin_Kofler> Ah right, that one, argh…
15:33:51 <Kevin_Kofler> (Whose idea was it again to make that thing a primary arch? :-( )
15:34:31 <rdieter> nice followup in the bug that at least the problem seems restricted to systray qml applets
15:34:47 <rdieter> (as weird as that sounds)
15:34:52 <Kevin_Kofler> Probably a Qt Declarative bug then.
15:35:12 <rdieter> than commented otherwise
15:35:41 <rdieter> qml in general works ok (apparently), only plasma qml-based ones in systray are a problem
15:35:43 * Kevin_Kofler goes (re-)read the bug report.
15:36:11 <rdieter> anyone interested/able to investigate this further?
15:36:44 <jgrulich> I tried it on Nexus 7 with PA and only QML applets in panel are broken
15:36:56 <rdieter> sadly, the kde upstream bugs haven't need much upstream comment/feedback either :(
15:37:45 <rdieter> https://bugs.kde.org/show_bug.cgi?id=312578  had a few comments at least
15:37:48 <Kevin_Kofler> Hmmm, I don't have any ARM hardware here. At most I could look at the build logs and maybe the generated assembly if I can get my hands on the .s files.
15:38:10 <rdieter> https://bugs.kde.org/show_bug.cgi?id=282975  less so
15:38:44 <rdieter> I saw the problem way back when in ~f17/f18 getting kde running on my olpc, but assumed it was an olpc'ism :(
15:38:51 <Kevin_Kofler> (Well, realistically, I probably have ARM hardware somewhere, but none I can run Fedora ARM or Plasma Active on. ;-) )
15:39:08 <mbriza> i sold my cubieboard... :/
15:39:31 <jreznik> Kevin_Kofler: it actually works somehow in emulator
15:39:41 <rdieter> hrm, could it be opengl vs egl qt support?
15:39:48 <jgrulich> Kevin_Kofler: I have Nexus 7 with PA, but it's complicated to test there something
15:39:49 <jreznik> and on i7 it's not as slow as I thought it would be
15:40:20 <rdieter> .bug 967365
15:40:23 <rdieter> maybe related?
15:40:24 <zodbot> rdieter: Bug 967365 OpenGL ES 2.0 for qt (on ARM) - https://bugzilla.redhat.com/show_bug.cgi?id=967365
15:41:54 <rdieter> cause pretty sure desktop opengl has no chance of working on arm anyway
15:42:19 * rdieter will ask in upstream bug
15:42:21 <Kevin_Kofler> I actually think it ought to work with the llvmpipe.
15:42:43 <Kevin_Kofler> And Qt 4 QML doesn't use OpenGL, does it?
15:42:58 <Kevin_Kofler> (It's a new feature in Qt 5.)
15:43:26 <rdieter> oh, I thought it did, nvm then
15:44:13 <Kevin_Kofler> I think there's some bug with coordinates related to qreal.
15:44:24 <Kevin_Kofler> Some double * being accessed as a qreal * or similar.
15:44:41 <Kevin_Kofler> Checking the strict-aliasing warnings could give an indication.
15:44:49 <Kevin_Kofler> Let me look at the build logs for Qt and kdelibs on ARM.
15:44:53 <rdieter> k
15:45:39 <Kevin_Kofler> (I don't think it's an aliasing issue per-se, but the strict aliasing warnings are also smoking guns for suspicious pointer casts.)
15:45:59 <rdieter> <nod>
15:46:32 <rdieter> .bug 1034828
15:46:35 <zodbot> rdieter: Bug 1034828 Enable kwallet Silently Create Initial Wallet=true feature by default - https://bugzilla.redhat.com/show_bug.cgi?id=1034828
15:46:39 <rdieter> submitted update implenting ^^
15:46:44 <rdieter> (finally)
15:46:53 <than> perhaps it's worth trying to build qt/kdelib with -O0 on arm
15:47:12 <Kevin_Kofler> 44M build.log, fun…
15:47:51 <Kevin_Kofler> than: That only helps if it's a miscompilation due to either a GCC bug or an aliasing issue or something in the Qt/KDE code.
15:48:15 <Kevin_Kofler> We could try it, but unoptimized Qt scares me…
15:48:31 <Kevin_Kofler> Even more so on ARM.
15:48:40 <than> Kevin_Kofler: i know, it's just workaround before we have a correct fix
15:48:57 <than> it's better than nothing!
15:49:06 <Kevin_Kofler> Well, it's not a given that this works around it at all.
15:49:31 <mkolman> IIRC Qt4 works just fine without OpenGL using the built-in software renderer
15:49:40 <mkolman> but can use OpenGL to speed stuff up
15:49:52 <mkolman> Qt5 depends on OpenGL
15:49:52 <Kevin_Kofler> If the thing is abusing qreal * pointers to point to doubles, then -O0 will only disable the aliasing warnings, but the code will still not work.
15:50:14 <Kevin_Kofler> But of course, if it's something different, -O0 can help.
15:50:28 <Kevin_Kofler> Maybe worth trying in scratch builds / local builds.
15:50:45 <than> Kevin_Kofler: +1
15:51:01 <Kevin_Kofler> What I really don't want is to try getting that hack through the freeze exception process without even knowing whether it works at all.
15:51:01 <than> who can test it?
15:51:42 <than> jgrulich: can you test it?
15:52:00 <jgrulich> than: I don't have device for that
15:52:19 <rdieter> maybe after meeting we can poke folks in #fedora-arm, see if they can give recommendations or hook some kde-sig'ers up with hardware to test
15:52:25 <than> i can do scratch build for qt/kdelibs
15:52:54 <than> rdieter: +1
15:53:28 <ltinkl> qt/kdelibs/kde-workspace, some of the Plasma libs is also in there
15:53:51 <jgrulich> ltinkl: I don't think it's in kde-workspace, there are only Plasma Applets
15:53:58 <jgrulich> ltinkl: qt/kdelibs
15:54:31 <rdieter> kde-workspace has the systray code
15:54:39 <ltinkl> ye and the shell/containments
15:54:57 <Kevin_Kofler> No strict aliasing warnings in the Qt build log for ARM.
15:55:02 <rdieter> but starting with qt, work way up to kdelibs, and then kde-workspace last makes sense
15:55:11 <ltinkl> kde-workspace/plasma/desktop/containments/panel
15:55:43 <Kevin_Kofler> Yeah, kde-workspace could be the offender.
15:58:02 <Kevin_Kofler> Well, I'd do all 3 scratch builds in parallel, then try testing all 3 -O0 builds together to see whether -O0 even helps at all.
15:58:10 <Kevin_Kofler> And if it does, I'd try one at a time to see which one it is.
15:58:23 <Kevin_Kofler> If it doesn't, it's not worth wasting more time on -O0.
15:59:18 <Kevin_Kofler> No suspicious warnings in the kdelibs build.log either, by the way.
16:00:43 <Kevin_Kofler> Nor in kde-workspace.
16:00:49 <Kevin_Kofler> So the GCC warnings aren't going to help us.
16:01:24 <Kevin_Kofler> jreznik: Any other blockers we should discuss?
16:01:42 <rdieter> I think that's the only one I can recall
16:04:02 <Kevin_Kofler> So, what's the conclusion? Do we have a volunteer for looking into this now?
16:04:27 <Kevin_Kofler> (someone with ARM hardware)
16:04:33 <than> i will try to do scratch build
16:05:20 <rdieter> i will reach out to #fedora-arm folks about getting hardware, probably idea to target getting this to folks in brno?
16:05:36 <rdieter> s/probably idea/probably best idea/ that is
16:05:44 <jreznik> Kevin_Kofler: not aware of any
16:05:49 <nirik> we also have https://fedoraproject.org/wiki/Architectures/ARM/qa-machines we can get people access to
16:06:32 <jreznik> rdieter: there's qemu, it works somehow and qa guys should have beaglebone black - not sure if it's usable now or not
16:06:36 <rdieter> that's a start, but that may not be sufficient to test this
16:06:51 <rdieter> (commenting on the qa-machines wiki)
16:07:38 <pwhalen> I'd be happy to test any fixes for arm, provide feedback
16:07:41 <rdieter> worst case, I could possibly document arm users could place widgets outside the systray, but eww.
16:08:05 <rdieter> as a (hopefully temporary) workaround
16:10:31 <rdieter> pwhalen: thanks
16:12:33 <than> pwhalen: thanks  we will ping you later for testing
16:13:01 <pwhalen> awesome, thanks for looking at it
16:15:37 <Kevin_Kofler> #action than will do scratch builds with -O0.
16:15:55 <Kevin_Kofler> #action pwhalen has offered help with testing.
16:15:59 <Kevin_Kofler> Thanks!
16:16:08 <Kevin_Kofler> Now we're 16 minutes over time already…
16:16:11 <Kevin_Kofler> #topic Open discussion
16:16:16 <Kevin_Kofler> Anything else before I close the meeting?
16:16:28 <Kevin_Kofler> Otherwise, closing in 60 seconds.
16:17:24 <Kevin_Kofler> OK, thanks everyone for coming!
16:17:31 <Kevin_Kofler> #endmeeting