340915 2014-11-13 02:21:37 +0000 LibreOffice windows and dialogs do not receive focus/become active upon opening 2015-06-29 14:17:28 +0000 1 1 4 Plasma kwin core 4.11.12 Other Linux RESOLVED INVALID https://www.copy.com/s/ZOtTj31FkSCeDLfy/Screencast%202014-11-12%2020%3A44%3A54.mp4 NOR minor --- 0 searchfgold67899 kwin-bugs-null danikpastushchak90 dernik gordon 0 oldest_to_newest 1480898 0 searchfgold67899 2014-11-13 02:21:37 +0000 When LibreOffice is launched, the window displayed is inactive and behind all other windows. New dialogs (e.g. Print..., Save As..., Convert to PDF) are inactive when displayed. This is LibreOffice v. 4.3.3.2, kwin v. 4.11.12, and KDE v. 4.14.1. Attached: KWin rules, in order, with "1.kwinrule" being the top and "5.kwinrule" at the bottom. None have an effect on LibreOffice specifically. Reproducible: Always Steps to Reproduce: 1. Open LibreOffice or a LibreOffice dialog. Actual Results: Window is inactive Expected Results: Window should be active URL is a video displaying this behavior. There is a rule in effect where inactive windows are semi-transparent and active windows are opaque. Video: https://www.copy.com/s/ZOtTj31FkSCeDLfy/Screencast%202014-11-12%2020%3A44%3A54.mp4 1480899 1 89569 searchfgold67899 2014-11-13 02:25:58 +0000 Created attachment 89569 kwin window rule #1 1480900 2 89570 searchfgold67899 2014-11-13 02:26:15 +0000 Created attachment 89570 kwin window rule #2 1480901 3 89571 searchfgold67899 2014-11-13 02:26:48 +0000 Created attachment 89571 kwin window rule #3 1480902 4 89572 searchfgold67899 2014-11-13 02:27:07 +0000 Created attachment 89572 kwin window rule #4 1480903 5 89573 searchfgold67899 2014-11-13 02:27:21 +0000 Created attachment 89573 kwin window rule #5 1480904 6 searchfgold67899 2014-11-13 02:27:55 +0000 When window rules list is clear, the bug is still present 1480930 7 thomas.luebking 2014-11-13 09:30:27 +0000 please post the output of "qdbus org.kde.KWin /KWin supportInformation", resp. what's your focus stealing prevention level and what happens if you set it to "low" resp. "none" run "kcmshell4 kwinoptions" for configuration 1481656 8 89622 searchfgold67899 2014-11-17 23:03:10 +0000 Created attachment 89622 Output of `qdbus org.kde.KWin /KWin supportInformation` 1481657 9 searchfgold67899 2014-11-17 23:04:06 +0000 Same behavior with focus stealing prevention level set to "none". Output of `qdbus org.kde.KWin /KWin supportInformation` attached. 1481717 10 thomas.luebking 2014-11-18 13:28:50 +0000 That would imply that LibreOffice sets a usertime of "0" (which is an explicit hint to not get the focus) Unfortunately that's hard to debug unless you can recompile kwin w/ an explicit debug statement? 1481918 11 searchfgold67899 2014-11-20 01:20:44 +0000 (In reply to Thomas Lübking from comment #10) > That would imply that LibreOffice sets a usertime of "0" (which is an > explicit hint to not get the focus) > Unfortunately that's hard to debug unless you can recompile kwin w/ an > explicit debug statement? Should I report something against LibreOffice then?... I am more than willing to recompile kwin but am unsure of what additional options I would have to pass. 1481979 12 thomas.luebking 2014-11-20 13:00:21 +0000 (In reply to searchfgold67899 from comment #11) > I am more than willing to recompile kwin but am unsure of what additional > options I would have to pass. No problem: diff --git a/activation.cpp b/activation.cpp index 9662f32..f7e3061 100644 --- a/activation.cpp +++ b/activation.cpp @@ -557,7 +557,10 @@ bool Workspace::allowClientActivation(const KWin::Client *c, xcb_timestamp_t tim ac = last_active_client; } if (time == 0) // explicitly asked not to get focus + { + qDebug() << "Client refuses focus" << c; return false; + } if (level == 0) // none return true; if (level == 4) // extreme > Should I report something against LibreOffice then?... Let's see whether this is the case. In case: yes. (Maybe a java/swing/awt issue, though) 1482012 13 mgraesslin 2014-11-20 16:24:12 +0000 > > Should I report something against LibreOffice then?... > > Let's see whether this is the case. In case: yes. (Maybe a java/swing/awt > issue, though) I just got this reported in private for Firefox and tried it and yes, I got: User timestamp, ASN: 0 User timestamp, final: 'ID: 29433370 ;WMCLASS: "iceweasel" : "navigator" ;Caption: "Iceweasel" ' : 0 !!!!!!!!!!!!!!!!! Client refused focus 'ID: 29433370 ;WMCLASS: "iceweasel" : "navigator" ;Caption: "Iceweasel" ' 1482018 14 mgraesslin 2014-11-20 16:58:14 +0000 Just an update on testing with Firefox. For a new window we get: _NET_WM_USER_TIME(CARDINAL) = 0 _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1c19645 Interesting here is that KWin doesn't support _NET_WM_USER_TIME_WINDOW and also that the window does not have any properties at all. Of course it's possible that there is a bug with our startup notification handling, but then Firefox should delete the property. 1482023 15 mgraesslin 2014-11-20 18:16:59 +0000 There is some wrongness in kdeinit-kstartupnotification interaction with lots of warnings in xsession-errors. The following patch fixes those warnings: diff --git a/src/kxmessages.cpp b/src/kxmessages.cpp index 2e625d2..c5a32fd 100644 --- a/src/kxmessages.cpp +++ b/src/kxmessages.cpp @@ -216,7 +216,7 @@ bool KXMessages::broadcastMessageX(Display *disp, const char *msg_type_P, if (disp == NULL) { return false; } - if (!QX11Info::isPlatformX11()) { + if (QCoreApplication::instance() && !QX11Info::isPlatformX11()) { qWarning() << "KXMessages used on non-X11 platform! This is an application bug."; return false; } explanation: kdeinit is not creating a Q(Core)Application thus our check always failed. 1482028 16 thomas.luebking 2014-11-20 19:22:56 +0000 > Interesting here is that KWin doesn't support _NET_WM_USER_TIME_WINDOW and also that the window does not have any properties at all. I can confirm that for firefox (33.1.1). At least here, LO however doesn't show this behavior. Also FF has a sane _NET_WM_USER_TIME on the actual window (which proposed _NET_WM_USER_TIME_WINDOW) a) I assume FF and LO are not related in this regard b) I assume FF acts "correctly" here - though it promotes _NET_WM_USER_TIME_WINDOW, it understands that this is not supported by the WM and sets _NET_WM_USER_TIME on the actual window > There is some wrongness in kdeinit-kstartupnotification interaction with lots of warnings in xsession-errors. Notice that the original bug is against KWin 4.11.12, not 5 > - if (!QX11Info::isPlatformX11()) { > + if (QCoreApplication::instance() && !QX11Info::isPlatformX11()) { Why would esp. a Q*Core*Application be required, given that the function takes a display as first parameter? Isn't it more likely that *disp is junk (resp. nullptr)? I'd rather expect trouble if KXMessages::broadcastMessage(const char *msg_type_P, const QString &message_P, int screen_P) was invoked before constructing a QGuiApplication instance (to obtain appRootWindow() etc.) 1482089 17 mgraesslin 2014-11-21 09:05:18 +0000 On Thursday 20 November 2014 19:22:56 you wrote: > Why would esp. a Q*Core*Application be required, given that the function > takes a display as first parameter? > Isn't it more likely that *disp is junk (resp. nullptr)? The code in question got called from kdeinit.cpp (kdeinit framework) which is not using a Q*Application, thus the check calling into the QPA always returned false and the message got never broadcasted. Adding the check for QCoreApplication::instance is for keeping the behavior of emitting a warning if the message is mis-used, though one can argue (and I will do that with myself) whether the check is completely wrong. 1485812 18 danikpastushchak90 2014-12-14 20:13:09 +0000 Comment from GCI student: I use Ubuntu 14.10 with KDE 4.14.2, KWin and LibreOffice are the same version as you. I have no problem window is active 1485819 19 thomas.luebking 2014-12-14 21:16:10 +0000 This is most likely sth. in the particular LO The only ways to get an inactive window w/ FSP set to "none" are a) LO hints a usertime "0" b) the currently active window bounces its usertime like hell (ie. it would depend on the currently active window, what does not comply w/ the inactive dialog while LO actually has the focus) A 3rd candidate could be the autohiding launcher. searchfgold67899, you could try to #!/bin/sh export SAL_USE_VCLPLUGIN=gen in an executable script in ~/.kde/env (maybe ~/.kde4/env) This should force LO to start w/o the KDE integration module (which is not available from my distro) 1488252 20 dernik 2014-12-30 10:20:45 +0000 I have the same focus problem with LO on my system: Arch linux - 3.17.6-1-ARCH KDE 3.14.3 LO - 4.2.8.2 This problem has started this year, as usual after update, unfortunately I don't remember exactly date, but currently I work more with LO and it's really annoying. I tried to set "export SAL_USE_VCLPLUGIN=gen", doesn't help. LO has changed it's view, but not focus behavior changes. I tried to set kde rules for LO windows also, "steal focus" settings, doesn't change enything. 1488364 21 thomas.luebking 2014-12-30 21:15:08 +0000 Bug in LibreOffice for pretty much sure. See also: https://forum.kde.org/viewtopic.php?f=66&t=123993&hilit=libreoffice https://www.libreoffice.org/bugzilla/show_bug.cgi?id=75471 1492637 22 searchfgold67899 2015-01-21 04:03:16 +0000 (In reply to Thomas Lübking from comment #21) > Bug in LibreOffice for pretty much sure. > > See also: > https://forum.kde.org/viewtopic.php?f=66&t=123993&hilit=libreoffice > https://www.libreoffice.org/bugzilla/show_bug.cgi?id=75471 It happens with Audacity, too. 1492639 23 searchfgold67899 2015-01-21 04:32:55 +0000 (In reply to Thomas Lübking from comment #19) > This is most likely sth. in the particular LO > > The only ways to get an inactive window w/ FSP set to "none" are > a) LO hints a usertime "0" > b) the currently active window bounces its usertime like hell (ie. it would > depend on the currently active window, what does not comply w/ the inactive > dialog while LO actually has the focus) > > A 3rd candidate could be the autohiding launcher. > > searchfgold67899, you could try to > > #!/bin/sh > export SAL_USE_VCLPLUGIN=gen > > in an executable script in ~/.kde/env (maybe ~/.kde4/env) > This should force LO to start w/o the KDE integration module (which is not > available from my distro) Your script placed in ~/.kde/env (which existed). Rebooted and the software was still behaving as it was before. 1492758 24 thomas.luebking 2015-01-21 16:37:04 +0000 (In reply to searchfgold67899 from comment #22) > It happens with Audacity, too. Which window/dialog in particular? Did you try whether it (or OOo) actively refuses the focus? (comment #12) 1492759 25 searchfgold67899 2015-01-21 16:38:22 +0000 (In reply to searchfgold67899 from comment #23) > (In reply to Thomas Lübking from comment #19) > > This is most likely sth. in the particular LO > > > > The only ways to get an inactive window w/ FSP set to "none" are > > a) LO hints a usertime "0" > > b) the currently active window bounces its usertime like hell (ie. it would > > depend on the currently active window, what does not comply w/ the inactive > > dialog while LO actually has the focus) > > > > A 3rd candidate could be the autohiding launcher. > > > > searchfgold67899, you could try to > > > > #!/bin/sh > > export SAL_USE_VCLPLUGIN=gen > > > > in an executable script in ~/.kde/env (maybe ~/.kde4/env) > > This should force LO to start w/o the KDE integration module (which is not > > available from my distro) > > Your script placed in ~/.kde/env (which existed). Rebooted and the software > was still behaving as it was before. I take this back, because after another reboot, LibreOffice now displays windows focused correctly. 1492760 26 searchfgold67899 2015-01-21 16:41:05 +0000 (In reply to searchfgold67899 from comment #25) > (In reply to searchfgold67899 from comment #23) > > (In reply to Thomas Lübking from comment #19) > > > This is most likely sth. in the particular LO > > > > > > The only ways to get an inactive window w/ FSP set to "none" are > > > a) LO hints a usertime "0" > > > b) the currently active window bounces its usertime like hell (ie. it would > > > depend on the currently active window, what does not comply w/ the inactive > > > dialog while LO actually has the focus) > > > > > > A 3rd candidate could be the autohiding launcher. > > > > > > searchfgold67899, you could try to > > > > > > #!/bin/sh > > > export SAL_USE_VCLPLUGIN=gen > > > > > > in an executable script in ~/.kde/env (maybe ~/.kde4/env) > > > This should force LO to start w/o the KDE integration module (which is not > > > available from my distro) > > > > Your script placed in ~/.kde/env (which existed). Rebooted and the software > > was still behaving as it was before. > > I take this back, because after another reboot, LibreOffice now displays > windows focused correctly. Now, some windows display correctly (Print, Help), while others do not (Save). 1492843 27 thomas.luebking 2015-01-21 22:50:52 +0000 Actually I can (now?) reproduce it pretty much reliably w/ the print dialog. I could not spot a pattern in when it works and when not, but I can assure that when it does not get the focus, that's because: _NET_WM_USER_TIME(CARDINAL) = 0 It *explicitly* asks to not get it. => That's a client bug for sure (the proeperty on the window isn't updated later on either, so this is not about a forgotten XSync() or something) I'll open a RR to invoke the rules here, so that you can override this by setting accept focus to "apply initially" "true", but that will only be available in 5.3 --- Could not reproduce w/ audacity so far. 1492854 28 thomas.luebking 2015-01-22 00:33:00 +0000 -> https://git.reviewboard.kde.org/r/122195/ 1494074 29 thomas.luebking 2015-01-24 22:19:31 +0000 Git commit 6957e1cf1ad5278e7d02daaf95a4bd2c4f10c858 by Thomas Lübking. Committed on 22/01/2015 at 00:11. Pushed by luebking into branch 'master'. consult rulebook on honoring a 0 usertime apparently some clients (randomly?) set _NET_WM_USER_TIME to 0 (recorded for libreoffice, audacity and perhaps firefox), so we allow to forcefully have them accept the focus here REVIEW: 122195 M +4 -2 activation.cpp http://commits.kde.org/kwin/6957e1cf1ad5278e7d02daaf95a4bd2c4f10c858 1528999 30 gordon 2015-06-29 09:18:01 +0000 Hi Thomas, I am having this problem on OpenSUSE 13.2 with KDE 4..14.8. That is, LibreOffice windows do not have focus when opened and are always opened in the background. So, my question is: Has this patch been applied to KDE 4 and how do you recommend that I get this patch for KDE 4.14.8? Thanks, Gordon 1529023 31 thomas.luebking 2015-06-29 14:17:28 +0000 KDE4 is feature frozen (for quite some time) so only security fixes can go upstream. You'll either have to pick the patch and (hand-)apply it and rebuild KWin or ask your distribution to incorporate it downstream. Please notice that the patch doesn't "fix" anything, because there's nothing "broken" - it will just allow you to setup a window rule for libreoffice to "take focus" despite it explicitly says that it doesn't want it (the actual meaning of the "take focus" rule is a bit different, but it's ok to re-use it here) Ideally, a fix would occur in libreoffice. 89569 2014-11-13 02:25:58 +0000 2014-11-17 23:03:10 +0000 kwin window rule #1 1.kwinrule text/plain 285 searchfgold67899 W0FwcGxpY2F0aW9uIHNldHRpbmdzIGZvciBqYWdleGFwcGxldHZpZXdlcl0KRGVzY3JpcHRpb249 QXBwbGljYXRpb24gc2V0dGluZ3MgZm9yIGphZ2V4YXBwbGV0dmlld2VyCmNsaWVudG1hY2hpbmU9 cmljaGllLWRlc2t0b3AKY2xpZW50bWFjaGluZW1hdGNoPTAKZnVsbHNjcmVlbj10cnVlCmZ1bGxz Y3JlZW5ydWxlPTIKdHlwZXM9NDI5NDk2NzI5NQp3bWNsYXNzPXN1bi1hd3QteDExLXhmcmFtZXBl ZXIgamFnZXhhcHBsZXR2aWV3ZXIKd21jbGFzc2NvbXBsZXRlPXRydWUKd21jbGFzc21hdGNoPTEK 89570 2014-11-13 02:26:15 +0000 2014-11-17 23:03:10 +0000 kwin window rule #2 2.kwinrule text/plain 321 searchfgold67899 W1NldHRpbmdzIGZvciBnaW1wLTIuOCBHaW1wLTIuOF0KRGVzY3JpcHRpb249U2V0dGluZ3MgZm9y IGdpbXAtMi44IEdpbXAtMi44CmNsaWVudG1hY2hpbmU9cmljaGllLWRlc2t0b3AKY2xpZW50bWFj aGluZW1hdGNoPTAKb3BhY2l0eWFjdGl2ZT0xMDAKb3BhY2l0eWFjdGl2ZXJ1bGU9MgpvcGFjaXR5 aW5hY3RpdmU9MTAwCm9wYWNpdHlpbmFjdGl2ZXJ1bGU9Mgp0aXRsZT1MYXllcnMgLSBCcnVzaGVz CnRpdGxlbWF0Y2g9MAp0eXBlcz00Mjk0OTY3Mjk1CndtY2xhc3M9Z2ltcC0yLjggZ2ltcC0yLjgK d21jbGFzc2NvbXBsZXRlPXRydWUKd21jbGFzc21hdGNoPTEK 89571 2014-11-13 02:26:48 +0000 2014-11-17 23:03:10 +0000 kwin window rule #3 3.kwinrule text/plain 311 searchfgold67899 W3NwZWNpYWwgcnVsZV0KRGVzY3JpcHRpb249c3BlY2lhbCBydWxlCmNsaWVudG1hY2hpbmU9cmlj aGllLWRlc2t0b3AKY2xpZW50bWFjaGluZW1hdGNoPTAKb3BhY2l0eWFjdGl2ZT0xMDAKb3BhY2l0 eWFjdGl2ZXJ1bGU9MgpvcGFjaXR5aW5hY3RpdmU9MTAwCm9wYWNpdHlpbmFjdGl2ZXJ1bGU9Mgp0 aXRsZT1XaW5kb3dzIDguMSBbUnVubmluZ10gLSBPcmFjbGUgVk0gVmlydHVhbEJveCA6IDEKdGl0 bGVtYXRjaD0wCnR5cGVzPTQyOTQ5NjcyOTUKd21jbGFzcz12aXJ0dWFsYm94CndtY2xhc3Njb21w bGV0ZT1mYWxzZQp3bWNsYXNzbWF0Y2g9MQo= 89572 2014-11-13 02:27:07 +0000 2014-11-17 23:03:10 +0000 kwin window rule #4 4.kwinrule text/plain 171 searchfgold67899 W2JsaW5kIHJ1bGVdCkRlc2NyaXB0aW9uPWJsaW5kIHJ1bGUKb3BhY2l0eWFjdGl2ZT0xMDAKb3Bh Y2l0eWFjdGl2ZXJ1bGU9MgpvcGFjaXR5aW5hY3RpdmU9NTMKb3BhY2l0eWluYWN0aXZlcnVsZT0y CnR5cGVzPTM2MQp3bWNsYXNzPQp3bWNsYXNzY29tcGxldGU9ZmFsc2UKd21jbGFzc21hdGNoPTAK 89573 2014-11-13 02:27:21 +0000 2014-11-17 23:03:10 +0000 kwin window rule #5 5.kwinrule text/plain 210 searchfgold67899 WyhEZWZhdWx0KSBEaXNhYmxlIGZvY3VzIHN0ZWFsaW5nIHByZXZlbnRpb24gZm9yIFhWXQpEZXNj cmlwdGlvbj0oRGVmYXVsdCkgRGlzYWJsZSBmb2N1cyBzdGVhbGluZyBwcmV2ZW50aW9uIGZvciBY Vgpmc3BsZXZlbD0wCmZzcGxldmVscnVsZT0yCnR5cGVzPTQyOTQ5NjcyOTUKd21jbGFzcz1eeHYg LioKd21jbGFzc2NvbXBsZXRlPXRydWUKd21jbGFzc21hdGNoPTMK 89622 2014-11-17 23:03:10 +0000 2014-11-17 23:03:10 +0000 Output of `qdbus org.kde.KWin /KWin supportInformation` supportInformation text/plain 6454 searchfgold67899 S1dpbiBTdXBwb3J0IEluZm9ybWF0aW9uOgpUaGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIHNob3Vs ZCBiZSB1c2VkIHdoZW4gcmVxdWVzdGluZyBzdXBwb3J0IG9uIGUuZy4gaHR0cDovL2ZvcnVtLmtk ZS5vcmcuCkl0IHByb3ZpZGVzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjdXJyZW50bHkgcnVubmlu ZyBpbnN0YW5jZSwgd2hpY2ggb3B0aW9ucyBhcmUgdXNlZCwKd2hhdCBPcGVuR0wgZHJpdmVyIGFu ZCB3aGljaCBlZmZlY3RzIGFyZSBydW5uaW5nLgpQbGVhc2UgcG9zdCB0aGUgaW5mb3JtYXRpb24g cHJvdmlkZWQgdW5kZXJuZWF0aCB0aGlzIGludHJvZHVjdG9yeSB0ZXh0IHRvIGEgcGFzdGUgYmlu IHNlcnZpY2UKbGlrZSBodHRwOi8vcGFzdGUua2RlLm9yZyBpbnN0ZWFkIG9mIHBhc3RpbmcgaW50 byBzdXBwb3J0IHRocmVhZHMuCgo9PT09PT09PT09PT09PT09PT09PT09PT09PQoKVmVyc2lvbgo9 PT09PT09CktXaW4gdmVyc2lvbjogNC4xMS4xMgpLREUgU0MgdmVyc2lvbiAocnVudGltZSk6IDQu MTQuMQpLREUgU0MgdmVyc2lvbiAoY29tcGlsZSk6IDQuMTQuMQpRdCBWZXJzaW9uOiA0LjguNgoK T3B0aW9ucwo9PT09PT09CmZvY3VzUG9saWN5OiAwCm5leHRGb2N1c1ByZWZlcnNNb3VzZTogZmFs c2UKY2xpY2tSYWlzZTogdHJ1ZQphdXRvUmFpc2U6IGZhbHNlCmF1dG9SYWlzZUludGVydmFsOiAw CmRlbGF5Rm9jdXNJbnRlcnZhbDogMApzaGFkZUhvdmVyOiBmYWxzZQpzaGFkZUhvdmVySW50ZXJ2 YWw6IDI1MApzZXBhcmF0ZVNjcmVlbkZvY3VzOiBmYWxzZQpwbGFjZW1lbnQ6IDQKZm9jdXNQb2xp Y3lJc1JlYXNvbmFibGU6IHRydWUKYm9yZGVyU25hcFpvbmU6IDEwCndpbmRvd1NuYXBab25lOiAx MApjZW50ZXJTbmFwWm9uZTogMApzbmFwT25seVdoZW5PdmVybGFwcGluZzogZmFsc2UKc2hvd0Rl c2t0b3BJc01pbmltaXplQWxsOiBmYWxzZQpyb2xsT3ZlckRlc2t0b3BzOiB0cnVlCmZvY3VzU3Rl YWxpbmdQcmV2ZW50aW9uTGV2ZWw6IDAKbGVnYWN5RnVsbHNjcmVlblN1cHBvcnQ6IGZhbHNlCm9w ZXJhdGlvblRpdGxlYmFyRGJsQ2xpY2s6IApjb21tYW5kQWN0aXZlVGl0bGViYXIxOiAwCmNvbW1h bmRBY3RpdmVUaXRsZWJhcjI6IDMwCmNvbW1hbmRBY3RpdmVUaXRsZWJhcjM6IDIKY29tbWFuZElu YWN0aXZlVGl0bGViYXIxOiA0CmNvbW1hbmRJbmFjdGl2ZVRpdGxlYmFyMjogMzAKY29tbWFuZElu YWN0aXZlVGl0bGViYXIzOiAyCmNvbW1hbmRXaW5kb3cxOiA3CmNvbW1hbmRXaW5kb3cyOiA4CmNv bW1hbmRXaW5kb3czOiA4CmNvbW1hbmRXaW5kb3dXaGVlbDogMzEKY29tbWFuZEFsbDE6IDEwCmNv bW1hbmRBbGwyOiAzCmNvbW1hbmRBbGwzOiAxNAprZXlDbWRBbGxNb2RLZXk6IDE2Nzc3MjUxCnNo b3dHZW9tZXRyeVRpcDogZmFsc2UKY29uZGVuc2VkVGl0bGU6IGZhbHNlCmVsZWN0cmljQm9yZGVy TWF4aW1pemU6IHRydWUKZWxlY3RyaWNCb3JkZXJUaWxpbmc6IHRydWUKZWxlY3RyaWNCb3JkZXJD b3JuZXJSYXRpbzogMC4yNQpib3JkZXJsZXNzTWF4aW1pemVkV2luZG93czogZmFsc2UKa2lsbFBp bmdUaW1lb3V0OiA1MDAwCmhpZGVVdGlsaXR5V2luZG93c0ZvckluYWN0aXZlOiB0cnVlCmluYWN0 aXZlVGFic1NraXBUYXNrYmFyOiBmYWxzZQphdXRvZ3JvdXBTaW1pbGFyV2luZG93czogZmFsc2UK YXV0b2dyb3VwSW5Gb3JlZ3JvdW5kOiB0cnVlCmNvbXBvc2l0aW5nTW9kZTogMQp1c2VDb21wb3Np dGluZzogdHJ1ZQpjb21wb3NpdGluZ0luaXRpYWxpemVkOiB0cnVlCmhpZGRlblByZXZpZXdzOiAx CnVucmVkaXJlY3RGdWxsc2NyZWVuOiBmYWxzZQpnbFNtb290aFNjYWxlOiAyCmNvbG9yQ29ycmVj dGVkOiBmYWxzZQp4cmVuZGVyU21vb3RoU2NhbGU6IGZhbHNlCm1heEZwc0ludGVydmFsOiAxNjY2 NjY2NgpyZWZyZXNoUmF0ZTogMAp2QmxhbmtUaW1lOiA2MDAwMDAwCmdsRGlyZWN0OiB0cnVlCmds U3RyaWN0QmluZGluZzogZmFsc2UKZ2xTdHJpY3RCaW5kaW5nRm9sbG93c0RyaXZlcjogdHJ1ZQpn bExlZ2FjeTogZmFsc2UKZ2xDb3JlUHJvZmlsZTogdHJ1ZQpnbFByZWZlckJ1ZmZlclN3YXA6IDEw MQoKU2NyZWVuIEVkZ2VzCj09PT09PT09PT09PQpkZXNrdG9wU3dpdGNoaW5nOiBmYWxzZQpkZXNr dG9wU3dpdGNoaW5nTW92aW5nQ2xpZW50czogZmFsc2UKY3Vyc29yUHVzaEJhY2tEaXN0YW5jZTog CnRpbWVUaHJlc2hvbGQ6IDE1MApyZUFjdGl2YXRlVGhyZXNob2xkOiAzNTAKYWN0aW9uVG9wTGVm dDogMAphY3Rpb25Ub3A6IDAKYWN0aW9uVG9wUmlnaHQ6IDAKYWN0aW9uUmlnaHQ6IDAKYWN0aW9u Qm90dG9tUmlnaHQ6IDAKYWN0aW9uQm90dG9tOiAwCmFjdGlvbkJvdHRvbUxlZnQ6IDAKYWN0aW9u TGVmdDogMAoKU2NyZWVucwo9PT09PT09Ck11bHRpLUhlYWQ6IG5vCkFjdGl2ZSBzY3JlZW4gZm9s bG93cyBtb3VzZTogIG5vCk51bWJlciBvZiBTY3JlZW5zOiAyClNjcmVlbiAwIEdlb21ldHJ5OiAw LDAsMTkyMHgxMDgwClNjcmVlbiAxIEdlb21ldHJ5OiAxOTIwLDAsMTkyMHgxMDgwCgpEZWNvcmF0 aW9uCj09PT09PT09PT0KQ3VycmVudCBQbHVnaW46IGt3aW4zX294eWdlbgpTaGFkb3dzOiB5ZXMK QWxwaGE6IHllcwpBbm5vdW5jZXMgQWxwaGE6IHllcwpUYWJiaW5nOiB5ZXMKRnJhbWUgT3Zlcmxh cDogbm8KQmx1ciBCZWhpbmQ6IG5vCgpDb21wb3NpdGluZwo9PT09PT09PT09PQpRdCBHcmFwaGlj cyBTeXN0ZW06IHJhc3RlcgpDb21wb3NpdGluZyBpcyBhY3RpdmUKQ29tcG9zaXRpbmcgVHlwZTog T3BlbkdMCk9wZW5HTCB2ZW5kb3Igc3RyaW5nOiBYLk9yZwpPcGVuR0wgcmVuZGVyZXIgc3RyaW5n OiBHYWxsaXVtIDAuNCBvbiBBTUQgSlVOSVBFUgpPcGVuR0wgdmVyc2lvbiBzdHJpbmc6IDMuMyAo Q29yZSBQcm9maWxlKSBNZXNhIDEwLjMuMApPcGVuR0wgc2hhZGluZyBsYW5ndWFnZSB2ZXJzaW9u IHN0cmluZzogMy4zMApEcml2ZXI6IFI2MDBHCkdQVSBjbGFzczogRVZFUkdSRUVOCk9wZW5HTCB2 ZXJzaW9uOiAzLjMKR0xTTCB2ZXJzaW9uOiAzLjMwCk1lc2EgdmVyc2lvbjogMTAuMwpYIHNlcnZl ciB2ZXJzaW9uOiAxLjE2CkxpbnV4IGtlcm5lbCB2ZXJzaW9uOiAzLjE2CkRpcmVjdCByZW5kZXJp bmc6IHllcwpSZXF1aXJlcyBzdHJpY3QgYmluZGluZzogbm8KR0xTTCBzaGFkZXJzOiAgeWVzClRl eHR1cmUgTlBPVCBzdXBwb3J0OiAgeWVzClZpcnR1YWwgTWFjaGluZTogIG5vCk9wZW5HTCAyIFNo YWRlcnMgYXJlIHVzZWQKUGFpbnRpbmcgYmxvY2tzIGZvciB2ZXJ0aWNhbCByZXRyYWNlOiAgbm8K CkxvYWRlZCBFZmZlY3RzOgotLS0tLS0tLS0tLS0tLS0Ka3dpbjRfZWZmZWN0X3pvb20Ka3dpbjRf ZWZmZWN0X2RpbXNjcmVlbgprd2luNF9lZmZlY3RfbW91c2VtYXJrCmt3aW40X2VmZmVjdF9zbGlk aW5ncG9wdXBzCmt3aW40X2VmZmVjdF9sb2dpbgprd2luNF9lZmZlY3Rfd29iYmx5d2luZG93cwpr d2luNF9lZmZlY3RfY292ZXJzd2l0Y2gKa3dpbjRfZWZmZWN0X21pbmltaXplYW5pbWF0aW9uCmt3 aW40X2VmZmVjdF9zY3JlZW5zaG90Cmt3aW40X2VmZmVjdF9jdWJlCmt3aW40X2VmZmVjdF9zbGlk ZQprd2luNF9lZmZlY3RfZGVza3RvcGdyaWQKa3dpbjRfZWZmZWN0X2ZsaXBzd2l0Y2gKa3dpbjRf ZWZmZWN0X3RyYW5zbHVjZW5jeQprd2luNF9lZmZlY3RfcmVzaXplCmt3aW40X2VmZmVjdF9tYXhp bWl6ZQprd2luNF9lZmZlY3RfZmFkZQprd2luNF9lZmZlY3Rfc2hlZXQKa3dpbjRfZWZmZWN0X2hp Z2hsaWdodHdpbmRvdwprd2luNF9lZmZlY3RfdGFza2JhcnRodW1ibmFpbAprd2luNF9lZmZlY3Rf ZGlhbG9ncGFyZW50Cmt3aW40X2VmZmVjdF9wcmVzZW50d2luZG93cwprd2luNF9lZmZlY3RfYmx1 cgprd2luNF9lZmZlY3RfbG9nb3V0Cmt3aW40X2VmZmVjdF9kYXNoYm9hcmQKa3dpbjRfZWZmZWN0 X3NjcmVlbmVkZ2UKa3dpbjRfZWZmZWN0X3N0YXJ0dXBmZWVkYmFjawprd2luNF9lZmZlY3Rfa3Nj cmVlbgoKQ3VycmVudGx5IEFjdGl2ZSBFZmZlY3RzOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Cmt3aW40X2VmZmVjdF9ibHVyCgpFZmZlY3QgU2V0dGluZ3M6Ci0tLS0tLS0tLS0tLS0tLS0Ka3dp bjRfZWZmZWN0X3pvb206Cnpvb21GYWN0b3I6IDEuMgptb3VzZVBvaW50ZXI6IDAKbW91c2VUcmFj a2luZzogMAplbmFibGVGb2N1c1RyYWNraW5nOiBmYWxzZQpmb2xsb3dGb2N1czogdHJ1ZQpmb2N1 c0RlbGF5OiAzNTAKbW92ZUZhY3RvcjogMjAKdGFyZ2V0Wm9vbTogMQoKa3dpbjRfZWZmZWN0X2Rp bXNjcmVlbjoKCmt3aW40X2VmZmVjdF9tb3VzZW1hcms6CndpZHRoOiAzCmNvbG9yOiAjZmYwMDAw Cgprd2luNF9lZmZlY3Rfc2xpZGluZ3BvcHVwczoKZmFkZUluVGltZTogMjUwCmZhZGVPdXRUaW1l OiAyNTAKCmt3aW40X2VmZmVjdF9sb2dpbjoKCmt3aW40X2VmZmVjdF93b2JibHl3aW5kb3dzOgpz dGlmZm5lc3M6IDAuMDEKZHJhZzogMC45Nwptb3ZlRmFjdG9yOiAwLjI1CnhUZXNzZWxhdGlvbjog MjAKeVRlc3NlbGF0aW9uOiAyMAptaW5WZWxvY2l0eTogMAptYXhWZWxvY2l0eTogMTAwMApzdG9w VmVsb2NpdHk6IDAuNQptaW5BY2NlbGVyYXRpb246IDAKbWF4QWNjZWxlcmF0aW9uOiAxMDAwCnN0 b3BBY2NlbGVyYXRpb246IDAuNQptb3ZlRWZmZWN0RW5hYmxlZDogdHJ1ZQpvcGVuRWZmZWN0RW5h YmxlZDogZmFsc2UKY2xvc2VFZmZlY3RFbmFibGVkOiBmYWxzZQptb3ZlV29iYmxlOiB0cnVlCnJl c2l6ZVdvYmJsZTogdHJ1ZQoKa3dpbjRfZWZmZWN0X2NvdmVyc3dpdGNoOgphbmltYXRpb25EdXJh dGlvbjogMjAwCmFuaW1hdGVTd2l0Y2g6IHRydWUKYW5pbWF0ZVN0YXJ0OiB0cnVlCmFuaW1hdGVT dG9wOiB0cnVlCnJlZmxlY3Rpb246IHRydWUKd2luZG93VGl0bGU6IHRydWUKelBvc2l0aW9uOiA5 MDAKcHJpbWFyeVRhYkJveDogZmFsc2UKc2Vjb25kYXJ5VGFiQm94OiBmYWxzZQoKa3dpbjRfZWZm ZWN0X21pbmltaXplYW5pbWF0aW9uOgoKa3dpbjRfZWZmZWN0X3NjcmVlbnNob3Q6Cgprd2luNF9l ZmZlY3RfY3ViZToKY3ViZU9wYWNpdHk6IDAuODAwMDAwMDExOTIwOTI5Cm9wYWNpdHlEZXNrdG9w T25seTogZmFsc2UKZGlzcGxheURlc2t0b3BOYW1lOiB0cnVlCnJlZmxlY3Rpb246IHRydWUKcm90 YXRpb25EdXJhdGlvbjogNTAwCmJhY2tncm91bmRDb2xvcjogIzAwMDAwMApjYXBDb2xvcjogI2Nh Y2FkMApwYWludENhcHM6IHRydWUKY2xvc2VPbk1vdXNlUmVsZWFzZTogZmFsc2UKelBvc2l0aW9u OiAxMDAKdXNlRm9yVGFiQm94OiBmYWxzZQppbnZlcnRLZXlzOiBmYWxzZQppbnZlcnRNb3VzZTog ZmFsc2UKY2FwRGVmb3JtYXRpb25GYWN0b3I6IDAKdXNlWk9yZGVyaW5nOiBmYWxzZQp0ZXh0dXJl ZENhcHM6IHRydWUKCmt3aW40X2VmZmVjdF9zbGlkZToKCmt3aW40X2VmZmVjdF9kZXNrdG9wZ3Jp ZDoKem9vbUR1cmF0aW9uOiAzMDAKYm9yZGVyOiAxMApkZXNrdG9wTmFtZUFsaWdubWVudDogMAps YXlvdXRNb2RlOiAwCmN1c3RvbUxheW91dFJvd3M6IDIKdXNlUHJlc2VudFdpbmRvd3M6IHRydWUK Cmt3aW40X2VmZmVjdF9mbGlwc3dpdGNoOgp0YWJCb3g6IGZhbHNlCnRhYkJveEFsdGVybmF0aXZl OiBmYWxzZQpkdXJhdGlvbjogMjAwCmFuZ2xlOiAzMAp4UG9zaXRpb246IDAuMzMwMDAwMDEzMTEz MDIyCnlQb3NpdGlvbjogMQp3aW5kb3dUaXRsZTogdHJ1ZQoKa3dpbjRfZWZmZWN0X3RyYW5zbHVj ZW5jeToKCmt3aW40X2VmZmVjdF9yZXNpemU6CnRleHR1cmVTY2FsZTogdHJ1ZQpvdXRsaW5lOiBm YWxzZQoKa3dpbjRfZWZmZWN0X21heGltaXplOgoKa3dpbjRfZWZmZWN0X2ZhZGU6Cgprd2luNF9l ZmZlY3Rfc2hlZXQ6CmR1cmF0aW9uOiA1MDAKCmt3aW40X2VmZmVjdF9oaWdobGlnaHR3aW5kb3c6 Cgprd2luNF9lZmZlY3RfdGFza2JhcnRodW1ibmFpbDoKCmt3aW40X2VmZmVjdF9kaWFsb2dwYXJl bnQ6Cgprd2luNF9lZmZlY3RfcHJlc2VudHdpbmRvd3M6CmxheW91dE1vZGU6IDAKc2hvd0NhcHRp b25zOiB0cnVlCnNob3dJY29uczogdHJ1ZQpkb05vdENsb3NlV2luZG93czogZmFsc2UKaWdub3Jl TWluaW1pemVkOiBmYWxzZQphY2N1cmFjeTogMjAKZmlsbEdhcHM6IHRydWUKZmFkZUR1cmF0aW9u OiAxNTAKc2hvd1BhbmVsOiBmYWxzZQpsZWZ0QnV0dG9uV2luZG93OiAxCnJpZ2h0QnV0dG9uV2lu ZG93OiAyCm1pZGRsZUJ1dHRvbldpbmRvdzogMApsZWZ0QnV0dG9uRGVza3RvcDogMgptaWRkbGVC dXR0b25EZXNrdG9wOiAwCnJpZ2h0QnV0dG9uRGVza3RvcDogMApkcmFnVG9DbG9zZTogZmFsc2UK Cmt3aW40X2VmZmVjdF9ibHVyOgpibHVyUmFkaXVzOiAxMgpjYWNoZVRleHR1cmU6IHRydWUKCmt3 aW40X2VmZmVjdF9sb2dvdXQ6CnVzZUJsdXI6IHRydWUKCmt3aW40X2VmZmVjdF9kYXNoYm9hcmQ6 CmJyaWdodG5lc3M6IDAuNQpzYXR1cmF0aW9uOiAwLjUKYmx1cjogZmFsc2UKCmt3aW40X2VmZmVj dF9zY3JlZW5lZGdlOgoKa3dpbjRfZWZmZWN0X3N0YXJ0dXBmZWVkYmFjazoKCmt3aW40X2VmZmVj dF9rc2NyZWVuOgoKCg==