Unable to connect to W10 RDP with Protocol Security Negotiation Failure after tsg_check failure

Describe the bug
I have a working RDP file in windows that allows me to connect to a W10 machine remotelly through a gateway. I am unable to make this work with freerdp.
To Reproduce
⇢ xfreerdp /version
This is FreeRDP version 2.0.0-rc4 (n/a)
⇢ xfreerdp Antonio.rdp /gateway-usage-method:direct /gt:rpc /cert-ignore /cert-tofu /log-level:trace
[12:47:01:161] [25457:25458] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[12:47:01:161] [25457:25458] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[12:47:01:161] [25457:25458] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[12:47:01:161] [25457:25458] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[12:47:01:162] [25457:25458] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[12:47:01:162] [25457:25458] [DEBUG][com.freerdp.client.x11] - Pointer device: 6
[12:47:01:165] [25457:25458] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[12:47:01:165] [25457:25458] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[12:47:01:165] [25457:25458] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[12:47:01:165] [25457:25458] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[12:47:01:165] [25457:25458] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[12:47:01:165] [25457:25458] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[12:47:01:165] [25457:25458] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[12:47:01:165] [25457:25458] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[12:47:01:180] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_INITIAL
[12:47:01:180] [25457:25458] [DEBUG][com.freerdp.core] - connecting to peer <IP ADDR 1>
[12:47:01:201] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_CONNECTED
GatewayPassword:
[12:47:07:251] [25457:25458] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[12:47:07:251] [25457:25458] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[12:47:07:252] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_SECURITY
[12:47:07:252] [25457:25458] [DEBUG][com.freerdp.core] - connecting to peer <IP ADDR 1>
[12:47:07:272] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_CONNECTED
[12:47:07:272] [25457:25458] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[12:47:07:272] [25457:25458] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[12:47:07:272] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_SECURITY
[12:47:07:273] [25457:25458] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[12:47:07:273] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_NEGOTIATED
[12:47:07:273] [25457:25458] [DEBUG][com.freerdp.core.gateway.rts] - Sending CONN/B1 RTS PDU
[12:47:07:273] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_OPENED
[12:47:07:277] [25457:25458] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[12:47:07:277] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_NEGOTIATED
[12:47:07:277] [25457:25458] [DEBUG][com.freerdp.core.gateway.rts] - Sending CONN/A1 RTS PDU
[12:47:07:277] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_OPENED
[12:47:07:277] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_OUT_CHANNEL_WAIT
[12:47:07:290] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_WAIT_A3W
[12:47:07:336] [25457:25458] [DEBUG][com.freerdp.core.gateway.rts] - Receiving CONN/A3 RTS PDU: ConnectionTimeout: 120000
[12:47:07:336] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_WAIT_C2
[12:47:07:336] [25457:25458] [DEBUG][com.freerdp.core.gateway.rts] - Receiving CONN/C2 RTS PDU: ConnectionTimeout: 120000 ReceiveWindowSize: 65536
[12:47:07:336] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_OPENED
[12:47:07:336] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - RPC_CLIENT_STATE_ESTABLISHED
[12:47:07:336] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - Sending Bind PDU
[12:47:07:336] [25457:25458] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[12:47:07:336] [25457:25458] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[12:47:07:336] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - RPC_CLIENT_STATE_WAIT_SECURE_BIND_ACK
[12:47:07:340] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - Receiving BindAck PDU
[12:47:07:340] [25457:25458] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[12:47:07:340] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - Sending RpcAuth3 PDU
[12:47:07:340] [25457:25458] [DEBUG][com.freerdp.core.gateway.rpc] - RPC_CLIENT_STATE_CONTEXT_NEGOTIATED
[12:47:07:340] [25457:25458] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyCreateTunnelWriteRequest
[12:47:07:340] [25457:25458] [DEBUG][com.freerdp.core.gateway.tsg] - TSG_STATE_INITIAL
[12:47:07:352] [25457:25458] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyCreateTunnelReadResponse
[12:47:07:352] [25457:25458] [DEBUG][com.freerdp.core.gateway.tsg] - TSG_STATE_CONNECTED
[12:47:07:352] [25457:25458] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyAuthorizeTunnelWriteRequest
[12:47:07:358] [25457:25458] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyAuthorizeTunnelReadResponse
[12:47:07:358] [25457:25458] [DEBUG][com.freerdp.core.gateway.tsg] - TSG_STATE_AUTHORIZED
[12:47:07:358] [25457:25458] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyMakeTunnelCallWriteRequest
[12:47:07:358] [25457:25458] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyCreateChannelWriteRequest
[12:47:07:362] [25457:25458] [ERROR][com.freerdp.core.gateway.rpc] - RPC Fault PDU:
[12:47:07:362] [25457:25458] [ERROR][com.freerdp.core.gateway.rpc] - status: RPC_S_INVALID_TAG (0x000006C5)
[12:47:07:362] [25457:25458] [ERROR][com.freerdp.core.gateway.tsg] - tsg_check failure
[12:47:07:362] [25457:25458] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[12:47:07:362] [25457:25458] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C]
[12:47:07:362] [25457:25458] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

Desktop (please complete the following information):

OS:

⇢ uname -a
Linux X1Arch 5.0.0-arch1-1-ARCH #1 SMP PREEMPT Mon Mar 4 14:11:43 UTC 2019 x86_64 GNU/Linux
⇢ gnome-shell --version
GNOME Shell 3.30.2

Browser:

⇢ firefox -v
Mozilla Firefox 65.0.2

Thank you for your report.
Could you check if it is working with our nightly builds https://github.com/FreeRDP/FreeRDP/wiki/PreBuilds ?
There have been a lot of fixes regarding gateway.

Now using freerdp-git package for Archlinux:
⇢ xfreerdp /version
This is FreeRDP version 2.0.0-dev5 (435872b41)
⇢ xfreerdp /buildconfig
This is FreeRDP version 2.0.0-dev5 (435872b41)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=OFF WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_GSTREAMER_0_10=OFF WITH_GSTREAMER_1_0=ON WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENH264=TRUE WITH_OPENH264=TRUE WITH_OPENH264_LOADING=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PAM=ON WITH_PCSC=OFF WITH_PROFILER=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=ON WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=ON WITH_THIRD_PARTY=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_WAYLAND=ON WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XDAMAGE=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XTEST=ON WITH_XV=ON WITH_ZLIB=ON
Build type:          Release
CFLAGS:              -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -DWINPR_DLL
Compiler:            GNU, 8.2.1
Target architecture: x64

Still not able to connect to my remote machine. Tested NLA, TLS and RDP sec options. Example run:
⇢ xfreerdp Antonio.rdp /gateway-usage-method:direct /gt:rpc /cert-ignore /cert-tofu /log-level:trace /sec:tls
[15:27:22:248] [5338:5339] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[15:27:22:248] [5338:5339] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[15:27:22:248] [5338:5339] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[15:27:22:248] [5338:5339] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[15:27:22:250] [5338:5339] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[15:27:22:250] [5338:5339] [DEBUG][com.freerdp.client.x11] - Pointer device: 6
[15:27:22:252] [5338:5339] [TRACE][com.freerdp.codec] - 4 - [OpenH264] this = 0x0x7f93f402da40, Info:CWelsDecoder::SetOption():DECODER_OPTION_TRACE_CALLBACK callback = 0x7f94010af420.
[15:27:22:255] [5338:5339] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[15:27:22:255] [5338:5339] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[15:27:22:255] [5338:5339] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: FALSE
[15:27:22:255] [5338:5339] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[15:27:22:255] [5338:5339] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: FALSE
[15:27:22:255] [5338:5339] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[15:27:22:255] [5338:5339] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_TLS
[15:27:22:255] [5338:5339] [DEBUG][com.freerdp.core.nego] - Attempting TLS security
[15:27:22:264] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_INITIAL
[15:27:22:264] [5338:5339] [DEBUG][com.freerdp.core] - connecting to peer <IP ADDR 1>
[15:27:22:286] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_CONNECTED
GatewayPassword:
[15:27:26:786] [5338:5339] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[15:27:26:786] [5338:5339] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[15:27:26:786] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_SECURITY
[15:27:26:786] [5338:5339] [DEBUG][com.freerdp.core] - connecting to peer <IP ADDR 1>
[15:27:26:807] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_CONNECTED
[15:27:26:807] [5338:5339] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[15:27:26:807] [5338:5339] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[15:27:26:807] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_SECURITY
[15:27:26:808] [5338:5339] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[15:27:26:808] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_NEGOTIATED
[15:27:26:808] [5338:5339] [DEBUG][com.freerdp.core.gateway.rts] - Sending CONN/B1 RTS PDU
[15:27:26:808] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_IN_CHANNEL_STATE_OPENED
[15:27:26:812] [5338:5339] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[15:27:26:812] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_NEGOTIATED
[15:27:26:812] [5338:5339] [DEBUG][com.freerdp.core.gateway.rts] - Sending CONN/A1 RTS PDU
[15:27:26:812] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - CLIENT_OUT_CHANNEL_STATE_OPENED
[15:27:26:812] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_OUT_CHANNEL_WAIT
[15:27:26:822] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_WAIT_A3W
[15:27:26:865] [5338:5339] [DEBUG][com.freerdp.core.gateway.rts] - Receiving CONN/A3 RTS PDU: ConnectionTimeout: 120000
[15:27:26:865] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_WAIT_C2
[15:27:26:865] [5338:5339] [DEBUG][com.freerdp.core.gateway.rts] - Receiving CONN/C2 RTS PDU: ConnectionTimeout: 120000 ReceiveWindowSize: 65536
[15:27:26:865] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - VIRTUAL_CONNECTION_STATE_OPENED
[15:27:26:865] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - RPC_CLIENT_STATE_ESTABLISHED
[15:27:26:865] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - Sending Bind PDU
[15:27:26:865] [5338:5339] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[15:27:26:865] [5338:5339] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[15:27:26:865] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - RPC_CLIENT_STATE_WAIT_SECURE_BIND_ACK
[15:27:26:869] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - Receiving BindAck PDU
[15:27:26:869] [5338:5339] [TRACE][com.freerdp.core.gateway.ntlm] - InitializeSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
[15:27:26:869] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - Sending RpcAuth3 PDU
[15:27:26:870] [5338:5339] [DEBUG][com.freerdp.core.gateway.rpc] - RPC_CLIENT_STATE_CONTEXT_NEGOTIATED
[15:27:26:870] [5338:5339] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyCreateTunnelWriteRequest
[15:27:26:870] [5338:5339] [DEBUG][com.freerdp.core.gateway.tsg] - TSG_STATE_INITIAL
[15:27:26:881] [5338:5339] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyCreateTunnelReadResponse
[15:27:26:881] [5338:5339] [DEBUG][com.freerdp.core.gateway.tsg] - TSG_STATE_CONNECTED
[15:27:26:881] [5338:5339] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyAuthorizeTunnelWriteRequest
[15:27:26:890] [5338:5339] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyAuthorizeTunnelReadResponse
[15:27:26:890] [5338:5339] [DEBUG][com.freerdp.core.gateway.tsg] - TSG_STATE_AUTHORIZED
[15:27:26:890] [5338:5339] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyMakeTunnelCallWriteRequest
[15:27:26:890] [5338:5339] [DEBUG][com.freerdp.core.gateway.tsg] - TsProxyCreateChannelWriteRequest
[15:27:26:893] [5338:5339] [ERROR][com.freerdp.core.gateway.rpc] - RPC Fault PDU: status=RPC_S_INVALID_TAG [0x000006C5]
[15:27:26:893] [5338:5339] [ERROR][com.freerdp.core.gateway.tsg] - tsg_check failure
[15:27:26:894] [5338:5339] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[15:27:26:894] [5338:5339] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C]
[15:27:26:894] [5338:5339] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure
[15:27:26:895] [5338:5339] [TRACE][com.freerdp.codec] - 4 - [OpenH264] this = 0x0x7f93f402da40, Info:CWelsDecoder::UninitDecoder(), openh264 codec version = .
[15:27:26:895] [5338:5339] [TRACE][com.freerdp.codec] - 4 - [OpenH264] this = 0x0x7f93f402da40, Info:CWelsDecoder::UninitDecoder(), verify memory usage (0 bytes) after free..
[15:27:26:895] [5338:5339] [TRACE][com.freerdp.codec] - 4 - [OpenH264] this = 0x0x7f93f402da40, Info:CWelsDecoder::~CWelsDecoder()

Hmm, too bad.
Two things you can try:
Does connection work using http gateway?
Does connection work with explicit authentication (nla, tls, ...) Instead of nogo?

When I try using a http gateway I get:
[19:53:02:081] [29128:29129] [INFO][com.freerdp.core.gateway.rdg] - RD Gateway does not support HTTP transport.

plus the usual error.
When I disable negotiation I get the following:
⇢ xfreerdp Antonio.rdp /gateway-usage-method:direct /gt:rdp /cert-ignore /cert-tofu /log-level:trace -nego /sec:tls
[19:56:09:745] [29239:29240] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[19:56:09:745] [29239:29240] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[19:56:09:745] [29239:29240] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[19:56:09:745] [29239:29240] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[19:56:09:746] [29239:29240] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[19:56:09:746] [29239:29240] [DEBUG][com.freerdp.client.x11] - Pointer device: 6
[19:56:09:748] [29239:29240] [TRACE][com.freerdp.codec] - 4 - [OpenH264] this = 0x0x7f763c02da40, Info:CWelsDecoder::SetOption():DECODER_OPTION_TRACE_CALLBACK callback = 0x7f764c647420.
[19:56:09:750] [29239:29240] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: FALSE
[19:56:09:750] [29239:29240] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[19:56:09:750] [29239:29240] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: FALSE
[19:56:09:750] [29239:29240] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[19:56:09:750] [29239:29240] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: FALSE
[19:56:09:750] [29239:29240] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[19:56:09:750] [29239:29240] [DEBUG][com.freerdp.core.nego] - Security Layer Negotiation is disabled
[19:56:09:750] [29239:29240] [DEBUG][com.freerdp.core.nego] - Negotiated TLS security
[19:56:09:750] [29239:29240] [DEBUG][com.freerdp.core.nego] - Failed to connect with TLS security
[19:56:09:750] [29239:29240] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C]
[19:56:09:750] [29239:29240] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure
[19:56:09:750] [29239:29240] [TRACE][com.freerdp.codec] - 4 - [OpenH264] this = 0x0x7f763c02da40, Info:CWelsDecoder::UninitDecoder(), openh264 codec version = .
[19:56:09:750] [29239:29240] [TRACE][com.freerdp.codec] - 4 - [OpenH264] this = 0x0x7f763c02da40, Info:CWelsDecoder::UninitDecoder(), verify memory usage (0 bytes) after free..
[19:56:09:750] [29239:29240] [TRACE][com.freerdp.codec] - 4 - [OpenH264] this = 0x0x7f763c02da40, Info:CWelsDecoder::~CWelsDecoder()

This happens also for rdp, tls, nla and ext...

Ok. Can you post the configuration of your gateway?
As you can imagine I've vot seen such issues with our test setups.
Reproducing the error would now be a necessary step for a fix.

I do not have access to the gateway configuration. In case it can provide some info, the RDP file I use and works on windows goes as follows:
screen mode id:i:2
use multimon:i:0
desktopwidth:i:1440
desktopheight:i:900
session bpp:i:32
winposstr:s:0,3,0,0,800,600
compression:i:1
keyboardhook:i:2
audiocapturemode:i:0
videoplaybackmode:i:1
connection type:i:7
networkautodetect:i:1
bandwidthautodetect:i:1
displayconnectionbar:i:1
username:s:<censored>
enableworkspacereconnect:i:0
disable wallpaper:i:0
allow font smoothing:i:0
allow desktop composition:i:0
disable full window drag:i:1
disable menu anims:i:1
disable themes:i:0
disable cursor setting:i:0
bitmapcachepersistenable:i:1
full address:s:<censored>
audiomode:i:0
redirectprinters:i:1
redirectcomports:i:0
redirectsmartcards:i:1
redirectclipboard:i:1
redirectposdevices:i:0
autoreconnection enabled:i:1
authentication level:i:2
prompt for credentials:i:0
negotiate security layer:i:1
remoteapplicationmode:i:0
alternate shell:s:
shell working directory:s:
gatewayhostname:s:<censored>
gatewayusagemethod:i:2
gatewaycredentialssource:i:4
gatewayprofileusagemethod:i:1
promptcredentialonce:i:1
gatewaybrokeringtype:i:0
use redirection server name:i:0
rdgiskdcproxy:i:0
kdcproxyname:s:
drivestoredirect:s:

I may be able to capture a valid connection with Windows and the equivalent attempt in Linux but that would require a way to setup a channel for me to send you the information privately as I cannot make those details public.

@antoniovazquezblanco Client configuration does not help here as we have some server/gateway configurations we test with (which work)
so we need to figure out why yours is not.
you can reach me in freerdp IRC or via matrix, same username as here on github.

I ran into the same issue (at least, I believe it is the same issue. If it's not, I can submit a separate issue): freerdp fails to connect to a 2008 R2 server through an RD Gateway.
This was working as expected in previous freerdp versions. Bisecting the issue revealed it was introduced with this commit.
Here is the output from the first commit with the error:
$ xfreerdp /v:remoteserver /d:company.com /u:myadmin /g:gateway.company.com /gt:auto
[17:03:23:262] [9242:9243] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
GatewayPassword:
[17:03:26:760] [9242:9243] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[17:03:26:760] [9242:9243] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C]
[17:03:26:760] [9242:9243] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure

Also tested with the latest commit, which results in this output:
$ xfreerdp /v:remoteserver /d:company.com /u:myadmin /g:gateway.company.com /gt:auto
[16:01:09:672] [31219:31220] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[16:01:09:672] [31219:31220] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[16:01:09:672] [31219:31220] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
GatewayPassword:
[16:01:13:245] [31219:31220] [INFO][com.freerdp.core.gateway.rdg] - RD Gateway does not support HTTP transport.
[16:01:13:863] [31219:31220] [INFO][com.freerdp.core.gateway.tsg] - TS Gateway Connection Success
[16:01:14:592] [31219:31220] [ERROR][com.freerdp.core.gateway.rpc] - RPC Fault PDU: status=RPC_S_PROTOCOL_ERROR [0x000006C0]
[16:01:14:592] [31219:31220] [ERROR][com.freerdp.core.rdp] - rdp_check_fds: tsg_check_event_handles()
[16:01:14:592] [31219:31220] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[16:01:14:820] [31219:31220] [INFO][com.freerdp.core.gateway.rdg] - RD Gateway does not support HTTP transport.
[16:01:15:489] [31219:31220] [INFO][com.freerdp.core.gateway.tsg] - TS Gateway Connection Success
[16:01:16:275] [31219:31220] [ERROR][com.freerdp.core.gateway.rpc] - RPC Fault PDU: status=RPC_S_PROTOCOL_ERROR [0x000006C0]
[16:01:16:275] [31219:31220] [ERROR][com.freerdp.core.rdp] - rdp_check_fds: tsg_check_event_handles()
[16:01:16:275] [31219:31220] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[16:01:16:275] [31219:31220] [ERROR][com.freerdp.core] - freerdp_post_connect failed

I'm not privy to how the gateway was setup, but I can access the config. It looks like it is an RpcProxy hosted by the "Internet Information Services" feature. Logs on the gateway indicate it is connecting via HTTPS (port 443).

Is there any update on this issue. This issue blocks us since a couple of months and otherwise we have to remove freerdp and replace it with another solution...

@GRme since nobody cared to post a gateway configuration that exposes the issue (and our gateway setups work quite fine) nothing changed...

I was unable to access to our gateway configuration because I didn't had enough credentials to do so in our organization.
@lectrode seems to have found the commit that causes the problem/changes de behaviour and possibly the feature that causes the problem.
@akallabeth have you tried to setup a gateway with that feature enabled?
Thank you very much

@antoniovazquezblanco what feature are you talking about? @lectrode just pointed to a commit where the error output was changed from a generic one to a gateway specific one ( RPC Fault PDU: status=RPC_S_PROTOCOL_ERROR [0x000006C0] is the response from your gateway)
But if that was only a simple permissions problem good to know.

For me it was not a permissions problem. I was saying that I could not get the gateway config due not having access to the infrastructure.
I thought that @lectrode  had found the culprit of the issue but from your answer I guess not.

@antoniovazquezblanco @akallabeth
The commit is where the issue was introduced. I had bisected where freerdp could no longer connect to the gateway. Commits prior to that still worked when accessing the gateway.
I subsequently provided output of both the problem commit and the latest commit at the time. Apologies if that was confusing.

@lectrode

does it work with /gt:http or /gt:rpc instead of /gt:auto or does it fail under all circumstances?
I´ve created branch https://github.com/akallabeth/FreeRDP/tree/gwfix2 reverting most of the additional checks introduced, could you give that a try? (pease attach a connection log with /log-level:trace if not)

Of course, best would be to either get a setup description for the failing gateway setup or a test account, until then I can only guess.

@akallabeth I seem to have the same issue.

does it work with /gt:http or /gt:rpc instead of /gt:auto or does it fail under all circumstances?
It fails under all circumstances.

I´ve created branch https://github.com/akallabeth/FreeRDP/tree/gwfix2 reverting most of the additional checks introduced, could you give that a try? (pease attach a connection log with /log-level:trace if not)
It still fails with this branch. I have attached the output with trace log.
gwfix2.log

It looks like this was caused by MFA. I.e. after I installed MFA on my device, it started to pop-up the request to approve the login and it started to work properly.

I no longer use or have access to the original infrastructure where the issue had place. I am ok with closing the issue if this has been fixed for any other user.
I leave the decission to other users/developers.
Thank you very much!

@antoniovazquezblanco ok, closing then.
A new one can always be created if there are still issues.

Thanks!


Errors re inventory levels falling below a given level should be based on whole bank, not just current storage location.

Summary
Change the comparison in inventory_check_service so that it compares across the whole bank rather than the current storage location
Why?
Per stakeholders,  the quantities are not per storage location, but across the bank.   Doesn't matter a lot for most banks, but consistent use of the values, comparing apples to apples.
Details
Recreation
log in as<EMAIL_ADDRESS>Look at the dashboard and pick an item from the bank-wide low inventory that is well above the minimum quantity.  Note the minimum amount.
Then make a distribution (Distributions|New Distribution).  You'll have to check for a storage location that has more than the minimum quantity (choose the storage location, then check the level shown on that item in the list.)
Make an entry that will reduce the amount in that storage location to just below the minimum amount (but wouldn't take the bank-wide level down below the minimum amount).
Save.
It will show the warning "The following items have fallen below the minimum on hand quantity".
What should happen
That warning should be shown only if the number available on that item falls below the minumum on hand quantity across the whole bank (i.e.  The total across all the bank's storage locations is below the minimum quantity.)
Please also change the error message to begin:  "The following items have fallen below the minimum on hand quantity, bank-wide: ",  and make it show as a warning (black on yellow) rather than an error (white on red).
Hint:  See set_error and set_alert in inventory_check_service for where this comes into effect.
Criteria for completion

[ ] error re minimum values correctly set
[ ] error re recommended values correctly set
[ ] existing tests modified if needed
[ ] tests added if not already there
[ ] warning message changed to "The following items have fallen below the minimum on hand quantity, bank-wide: "
[ ] warning message colour changed to our standard warning colour (blank on yellow) instead of white on red

Hi, is this issue still available?

It is -- I am assigning it to you.

Hi, could I please be assigned to work on this issue?  I saw that the Help Wanted issue was recently added back to the issue.  Thanks!

It's yours!

Hi @cielf and team, I have a clarifying question about this issue.
What is the desired behavior when a distribution causes item1 to fall below the minimum quantity and item2 to fall below the recommended quantity?  Do you want both the minimum quantity and recommended quantity error messages to display?  (My expectation is yes, but I wanted to confirm.)

Yes, please.  Both give useful information.  The more severe one (i.e. the  minimum one) should show first (I think it does already)

That makes sense, thanks!


Add ability to select / unselect repositories

Resolves #184

TODO:

[x]  Display only selected repository dependencies from in monthly-plan page.
[x]  Add a way to remember filtered repositories.

Codecov Report

Merging #245 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master    #245   +/-   ##
======================================
  Coverage    51.6%   51.6%
======================================
  Files          15      15
  Lines         250     250
  Branches       46      46
======================================
  Hits          129     129
  Misses         98      98
  Partials       23      23

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0391fae...1463ecc. Read the comment docs.

Can we find a way to make the "Back My Stack" -> "Continue on Open Collective" link works on Now automated deployments?
I don't think having excludedRepos in the URL is the best solution. Have you considered alternatives?

Can we find a way to make the "Back My Stack" -> "Continue on Open Collective" link works on Now automated deployments?

I'll see to that.

I don't think having excludedRepos in the URL is the best solution. Have you considered alternatives?

It's about persisting excludedRepos in case of page reload and navigating to other pages, without losing them. I had another options of saving them in browser local storage but I felt having them in url provides more flexibility since you can modify them directly there without going to Analyzed Repositories tab.

Overall, the code base starts to be more and more complicated to navigate, what can we do to make it simpler, easier to understand?

That's true, I'll need time to look into this.

Update here:

I'm confused about the getData abstraction, It's clearer to me without it. Let's revert that.

Reverted

Let's not put excludedRepos in the backing.json URL. It should just stay https://backyourstack-keynultlmp.now.sh/znarf/profile/backing.json. Whatever is required should be written in the S3 bucket.

Taken care of.

Let's try to have the excludedRepos state elsewhere than in the URL.

This is difficult, as the data are needed in monthly-plan page,  query string seems like the easiest and simplest way to pass the data, it also has the advantage of quickly excluding repositories from the url instead of going through a  long list of checkboxes so I'm leaving it.

@flickz the PR looks messed up with "Update confirmation page for asynchronous dispatch". https://github.com/opencollective/backyourstack/pull/250
It's complicated to review in this state.

@flickz it seems the version is now messed up, I see a lot of things that are supposed to be addressed (getData, eslint)

I apologized I've reset the HEAD commit back to what it should be.

Looks like there is 3 different endpoints for backing.json, I thought we only had 2 different use cases. Can you detail what are now the use cases for each of these endpoints?

When Backing My Stack using the feature, it's crashing.
Test URL: https://backyourstack-jbcfetvkqg.now.sh/monthly-plan?id=znarf&type=profile&excludedRepos=advent-of-code-2018%2Camateur%2Cbbpress-minimal%2Cblogmarks3%2Cbouncer%2Cdokuwiki-css%2Cdokuwiki-minimal%2Cdokuwiki-openid%2Ch6e-minimal%2Cnvo%2Copencollective-exercise%2Cresume%2Cstatusnet-ladistribution%2Cwordpress-minimal

Closing the PR, too many iterations, too many comments.
When you're ready, please open a new one, on a new a branch, with a single commit.


Shortcut for stopping recording without sending to the API

Hi, first of all, really enjoying the package and the application. It helps a lot and I hope you will continue working on it. I was looking for such an app for a while.
As for the issue, for both the desktop and the extension, it would be pretty important to add a delete message button that stops the recording without sending it to api. You could leave the recording running by mistake and end up paying a large fee for transcribing silence. On the side, a newer version for the windows App should probably make it run as a tray icon, as this way the app is usable without having to have an extra window. Thanks!

Having worried about that myself, I have been clicking the X in the corner of the window when I have accidentally let the recording go for too long. I hope that works. Otherwise I'm going to get large fees at the end of the month. :-)

There is this fantastic fork of Whispering which should at least help with this issue!
https://github.com/braden-w/whispering/issues/69

Hey @AdamSobieszek , thank you for the feature request! I apologize for the late response, but I remembered this feature request and this has been fixed a few months ago since version 4.0! I would recommend checking out the latest release whenever you have the time.
Cheers!


com.flashforge.FlashPrint missing icon

https://flathub.org/apps/details/com.flashforge.FlashPrint
Icons you could use

Reported here too:  https://github.com/flathub/com.flashforge.FlashPrint/issues/1


Set up a "Hello world" project with two apps

Project Setup

Create a new Rails API app called 'hello-rails-back-end'.
Initialize your project with Git.
Make sure that your project has a Postgres database set up.

README.md

Add project information and setup instructions
Include link to React app

Hi @obibaadoma
While you made a great effort in this project, I cannot proceed to review your code.
Invalid Code Review Request

[ ] As stated in the project requirement You are required to setup the backend and the front end repository separately and provide the link to the backend repo on the frontend readme file and also  provide the link to the frontend repo on the backend readme file.

Your Code Review Request will be marked as invalid in your Dashboard, so please submit a new one once you are ready 🙏

Cheers and Happy coding!👏👏👏

Feel free to leave any questions or comments in the PR thread if something is not 100% clear.

Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

Invalid Code Review Request does not count into the code reviews limit.


underscore not displayed correctly

I found out that underscore in not displayed at all in my jquery terminal
But that is in a very rare situation. One have to use --size: 1.2. Even the logo, is messed up.
You could try that jsfiddle: https://jsfiddle.net/jLyvkmta/1/

type echo test_test, and you will not get underscore in the response
type test_underscore, and the command echoed back will not have underscore either.

for --size 1.4 this happens once you have displayed a certain number of underscore, then it fails

I was having the same problem and I just didn't use certain sizes at all, just wanted to write that this is bug in browsers but I think I fixed this. Adding 1px to line-height solved the issue.
https://jsfiddle.net/pwq4s9f8/

Ok. thanks


Feat/create tina app

Basic POC of a create-tina-app command.
This currently

downloads the given example
installs dependencies

Most of the logic is coming from create-next-app
Source: https://github.com/vercel/next.js/tree/canary/packages/create-next-app

Closes https://github.com/tinacms/tinacms/issues/2185


⚠ ClamAV has degraded performance

In 1aab95c, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 78 ms

Resolved: ClamAV performance has improved in 7dab3ce after 5 minutes.


UX Testing deliverables T1-2023

Description
This request is to add the deliverables for UX Testing.
Fixes # (issue)
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as
expected)
[x] Documentation (update or new)

How Has This Been Tested?
Have clicked on each link to confirm they work. As no code is being produced, it is only workable links.
Testing Checklist:

[x] Tested in latest Chrome
[ ] Tested in latest Safari
[ ] Tested in latest Firefox

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have requested a review from Josh Piper on the Pull Request

This needs prettier running on it
Checking formatting...
[warn] docs/DreamBig/UX Testing T1-2023/Deliverables.md
[warn] Code style issues found in the above file. Forgot to run Prettier?
Error: Process completed with exit code 1.


fix: ventura county scraper

Summary

This fixes ventura county scraper from 3-30-20 through 4-14-20.

Thanks, Ty!


Access a Classic Schema from SAP Web IDE Full-Stack

Tutorial URL: https://developers.sap.com/tutorials/haas-dm-access-cross-container-schema.html
Maybe not an issue, but a question.
How can I manage access to a classic schema with VS Code?
After creating and configuring the service,
I added it to the mta.yaml as a ressource and a requirement for the db module.
"cds build" went fine, but "npm start" ended with
Error: service ServiceName_1 not found; the service definition does not exist.
Regards,
Andre
Add:
Using HANA Express 2.0 SPS04 in a VM locally on my laptop together with my VS Code. I tried the example from Exercise 2.6: Non-Container Schemas, User Provided Services & Synonyms from openSAP_hana7.
Btw: a great course, all went well in my environment

Please in the future only use the Tutorial issues for reporting problems directly related to tutorial content. The SAP Community Q&A should be used to ask questions in general.
If you want to do development in VSCode then you must be using a default-env.json to simulate the VCAP environment settings. If you are going to use this approach then you also need a SERVICE_REPLACEMENTS section in the default-env.json to map the alias (like ServiceName_1) to actually target service names. The other option is to not use service name alias at all and just code the actual service name in the hdbgrants.
However I'm closing this issue as its not at all related to the tutorial nor is it about the content of the tutorial.


Clojure character literals \{, \[, and \( wrongly rainbow colorized

Does this issue occur when all extensions are disabled?: Yes/No
Yes

VS Code Version: VS Code Insiders, 1.64.0-insider
OS Version: MacOS 12.0.1

Steps to Reproduce:

Open a new file and paste this text:

(defn auto-complete [open [c & r]]
  (if (empty? r)
    open
    (cond (#{\{ \[ \(}) c
          (recur (conj open c))

          )
    )
  )

(Set the language to Clojure if it doesn't happen automatically.)
Expected. The character literals \{, \[, and \( should not be rainbow colorized, and they should not mess up the colorization of ”real” brackets.
Actual: They are colorized and mess up the colorization of real brackets:

Thanks. I'll check what happens if we mark these as strings for now. I can file a PR if that seems to work OK. I'm unsure since they aren't strings, but we'll see.

I'll check what happens if we mark these as strings for now.

Note that this changes syntax highlighting!


I've created a Hashicorp Vault based ConfigurationProvider implementation

Is that something you'd like to accept as a PR?

Anyone ?

Does anyone care about this ?


Need a solution that can show full url in data static or assets

Is your feature request related to the problem? Please describe.
Yes. I can't use it with full link crawl DOM.
Describe the solution you want
I need a feature that can convert most url matches to absolute for example. <img:src="URL_BASE + ~asset/img.png" />
Or maybe in app.html

Describe the alternatives you have considered
I'm not looking for an alternative other than photos or files to a 3rd server.

You can use publicRuntimeConfig in your nuxt.config file and set a variable as your base url
Then, you can reference it as this.$config.


Grpc.Tools build target precludes Rider inspection on generated files

What version of gRPC and what language are you using?
Grpc.Tools 1.18.0
What operating system (Linux, Windows, …) and version?
MacOs Mojave and Windows 10
What runtime / compiler are you using (e.g. python version or version of gcc)
C# MSBuild on netstandard1.5 and netstandard2.1
dotnet build
What did you do?
Opened the csharp sample solution for helloworld loaded in Rider (the Jetbrains IDE) and built. (First found on a larger project, then repro'd on the sample).
From the sample csproj
  <ItemGroup>
    <Protobuf Include="../../../protos/helloworld.proto" Link="helloworld.proto" />
  </ItemGroup>

What did you expect to see?
A fresh build should result in no build errors and code-inspection indexing of the generated files, followed by symbols resolving as Rider performs indexing and Synchronization (no red).
What did you see instead?
After a fresh build (which succeeds), the generated files in obj/Debug/netstandard1.5/ aren't picked up by code inspection resulting in design-time symbol errors and no intellisense. Subsequent builds, cleans, build targets, don't resolved the issue.
Possible Fix
From https://rider-support.jetbrains.com/hc/en-us/community/posts/360000777140-Rider-ReSharper-ignoring-generated-code, I was able to go into grpc/src/csharp/Grpc.Tools/build/_protobuf/Google.Protobuf.Tools.targets and change line 113 of the _Protobuf_Compile_BeforeCsCompile step from BeforeCompile to ResolveAssemblyReferences. After modifying and testing a local nuget with the change, this resolved the issue on both windows 10 and macos.
Anything else we should know about your project / environment?
It's unclear to me from reading msbuild docs what the negative implications are of moving the build target to run before ResolveAssemblyReferences instead of BeforeCompile.
From https://github.com/grpc/grpc/blob/master/src/csharp/BUILD-INTEGRATION.md
/cc @kkm000

Thanks for the workaround! I've never heard about Rider, but I'll check your pointers. Would you be able to check a nightly build of the Tools package, when available, against this problem?

I have the same problem.
The solution proposed by @calebatwd works with Grpc.Tools Version=1.17.0, but doesn't seem to be working with Grpc.Tools Version=1.18.0.
I'm using Rider 2018.3.3 on Linux (Ubuntu 18.04 if it's important).

The workaround doesn't work Grpc.Tools v1.19.0-pre1 either.

I can confirm the workaround is only working with version 17 using Rider 2018.3.3 on Win 10.

This is a little bit... interesting, since the tooling did not change.
$ git diff v1.17.0..v1.19.1 src/csharp/Grpc.Tools

shows two changes, neither of which could possibly change anything in the build sequence. @gaeshi, @vfrx, do you think anything else could have changed in your setup? Build is composed of a large number of interlocked pieces. For example, if you downgrade the package now, would the workaround still work? I would appreciate if you could test that!
It seems to me that Ryder build hooks up into the wrong point in the MS build tooling. There is a target GenerateAdditionalSources that is run earlier, that we could hook up to, but it won't help us, as it is also executed later. I am a little bit concerned about hooking up into the build process so early as ResolveAsssemblyReferences. Generally, no compilation is supposed to happen at this point; actually, even package conflicts have not been resolved by that time, if you hook to it with a BeforeTargets condition.
Could you please check if at the last hooking after, not before this target helps? Instead of CallTarget (which is actually almost never used), a better way is to have your (perhaps empty) target run by way of After/Before targets and depend on the target you want to actually trigger, like
  <Target Name="_My_Workaround"
          AfterTargets="ResolveAsssemblyReferences"
          DependsOnTargets="Protobuf_Compile"
          Condition=" '$(Language)' == 'C#' " />

This would schedule Protobuf_Compile right after ResolveAsssemblyReferences has completed. I assume that they call this target explicitly, so your AfterTargets will also run before returning results to the caller. Only if that does not help, try BeforeTargets instead. It would be less correct, but if it works for you...
It's not impossible that we add a workaround especially for Ryder, but it seems to me that something in the way it evaluates the build is not exactly right. They do perhaps need assembly references resolved anyway for Intellisense to work. Also, this is apparently part of their design time build. I just cannot think of finding my way around internals in an unfamiliar IDE. For VS I install an extension that allows debugging design-time build. There is a couple of environment variables that I can set which trade its debugginess for performance. But I won't ride a white horse into this unfamiliar territory, for sure. Is it possible that any good soul here helps me get in touch with their engineers?

Thank you, @kkm000 for looking into this, but unfortunately your proposed workaround didn't seem to work on my machine.
As for getting in touch with Rider's engineers - they have a tracker here:
https://youtrack.jetbrains.com/issues/RIDER?q=grpc
Looks like they are aware of the issue and working on it.

In Rider 2019.1 EAP2, the following configuration seems to work fine:
<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <TargetFramework>netstandard1.5</TargetFramework>
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Google.Protobuf" Version="3.7.0" />
        <PackageReference Include="Grpc" Version="1.17.0" />
        <PackageReference Include="Grpc.Tools" Version="1.17.0" PrivateAssets="All" />
    </ItemGroup>

    <ItemGroup>
        <Folder Include="proto"/>
        <Protobuf Include="proto/greet.proto" Link="proto/greet.proto" />
    </ItemGroup>

</Project>

Please note that I'm not doing a CallTarget on the _Protobuf_Compile_BeforeCsCompile before ResolveAssemblyReferences anymore here.
However, updating the version of Grpc and Grpc.Tools to anything above 1.17.0 results in the same behavior (design-time symbol errors and no intellisense).

@gaeshi, thanks much for verifying the issue. I'm going to try to understand what is the difference between the versions then.

I've posted a private comment to one of the issues there asking the devs to chime in here (private only because I do not want to split this discussion into two in separate places; there is much more information here already than there; there are only reports w/o any analysis). I hope there should be a reaction to that.
Nevertheless, if anyone is in a closer contact with the Rider team, in particular people involved with the design-time build, encouraging them to chime in here would be indeed helpful.

I will explain how Rider builds project model and uses msbuild in this comment.
Short summary - Rider 2019.1 works with Grps toolkit fine our of the box if you specify *.proto files in a project.
To build project model Rider runs msbuild as a separate process. Rider tells msbuild which projects it has to load and obtains results. 'Load' means msbuild project evaluation plus some msbuild targets execution.
So Rider has a specific set of targets (like ResolveAssemblyReferences) to execute and also it scans projects and finds targets producing 'Compile' items. In our case it is _Protobuf_AugmentLanguageCompile. But this target has no dependencies (even transitive or implicit) on Protobuf_PrepareCompile / Protobuf_CoreCompile so no items were generated and added into projects.
In 2019.1 we have just included Protobuf_Compile target in default targets set so for now everything should work fine.

@xtmq Thank you very much for looking into this!
As I wrote above, I can confirm it works in Rider 2019.1 EAP2 perfectly fine with Grpc.Tools version 1.17.0. For some reason, the behavior is not the same with the newer releases of Grpc.Tools.
Here is an example project:
https://github.com/gaeshi/grpc-greeting-dotnet/blob/master/Greeter/Greeter.csproj
Updating the version of Grpc.Tools to anything above renders design-time symbol errors and no intellisense.
Rider version:
JetBrains Rider 2019.1 EAP
Build #RD-191.6349.96, built on March 21, 2019
Rider EAP User
Expiration date: April 20, 2019
JRE: 1.8.0_202-release-1483-b40 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.15.0-46-generic

I have the latest Rider (EAP3) and installed Grpc and Grpc.Tools 1.19 into your project and everything seems to work ok...

But I had to remove obj/bin folders and reopen solution after updating packages to 1.19.

Using v1.19.0 of the Grpc and Grpc.Tools packages, and the build of Rider detailed below, everything works OK provided I keep the workaround documented above by @calebatwd. If I remove the workaround, symbol resolution fails. I have not yet tried the EAP, however.
JetBrains Rider 2018.3.4
Build #RD-183.6092.12, built on March 4, 2019
JRE: 1.8.0_152-release-1343-b28 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.3

@xtmq I can confirm that it works on my installation of Rider EAP3 with Grpc.Tools 1.19 fine, too, no workarounds needed. Here is my current csproj:
<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <TargetFramework>netstandard1.5</TargetFramework>
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Google.Protobuf" Version="3.7.0" />
        <PackageReference Include="Grpc" Version="1.19.0" />
        <PackageReference Include="Grpc.Tools" Version="1.19.0" PrivateAssets="All" />
    </ItemGroup>

    <ItemGroup>
        <Folder Include="proto" />
        <Protobuf Include="proto/greet.proto" Link="proto/greet.proto" />
    </ItemGroup>

</Project>

@jen20 Please consider trying EAP3. You can install it side by side with the other versions and launch it easily using Jetbrains Toolbox.

I have confirmed all is well in the EAP - I don't like forcing that on downstream devs so I'll leave the workaround in place for now and wait for the next stable release of Rider.

@xmtq, thanks for chiming in here and fixing the issue so quickly!
First and above all, I'm sure there are deep reasons you have to do the design time build differently from the recommended (and poorly documented!) practice, so please do not perceive the following as an unasked-for advise; I just thought that sharing my experience with MSBuild and common Microsoft's own use of it in their build scripting would prove fruitful.
In general, codegen does not happen before ResolveAssemblyReferences completes, as it might potentially have dependencies on the resolved TFM, for example. It's not generalizable, so it's a rare and nonconformant practice. Note that this limitation does not apply to us, as our codegen depends entirely on .proto files, and does not care about the dependencies or SDK locations. Still, I'm reluctant to hook the codegen to such an early phase, unless specifically for Rider. If you can suggest how to positively determine that we are building under Rider, however (some distinguishable property  set?), then I'm fine with such a hack. But I am worrying about breaking other IDEs (e. g. Xamarin) if I do that unchecked in a general case.
Microsoft's own build extensions scripts that augment the Compile list hook up onto the CoreCompile item as BeforeTargets, or by modifying the CoreCompileDependsOn property. Here's a prime example from from Microsoft.ServiceModel.targets (support for remote Web services metadata, see the Add/Service... item in VS):
  <Target
    Name="PreXsdCodeGen"
    BeforeTargets="CoreCompile">

The same is true for the Workflow Extension, the T4 Text Templating Engine, and Gandalf only knows what else, speaking of MS own tooling. Trying to guess what various MS extensions or 3rd party NuGet packages would add to the Compile list may turn into a never-ending chase.
Unfortunately, this is not all nice and shiny. One notable offender is XAML generation tooling for the classic projects, which infers design-time state not by checking DesignTimeBuild=true or BuildingProject=false, as it is supposed to, but rather by looking only at BuildingInsideVisualStudio=true. For this case, setting the latter is the only option I know of to make it add the files *.i.cs and *.g.cs which are generated from XAML files. The practical hack that I khow of to force build behave as if it were invoked by VS is to invoke either the Compile or of CompileDesignTime target with the following options set:

DesignTimeBuild=true
SkipCompilerExecution=true
BuildingInsideVisualStudio=true (yes, a moderately dangerous hack, but goes a long way)
ProvideCommandLineArgs=true

It is also notable that VS itself calls the Compile target with the above properties set, and avoids the use of CompileDesignTime. I haven't spotted any differences in the behavior, however; I'd rather go the VS way, as this code path is less likely to break.
Also, C++ projects currently use an entirely different scripting and peculiar targets, but I do not know if you guys support C++ builds.
In general, I found the following two tools indispensable for debugging builds, both design/build time in VS and command line MSBuild/dotnet: the Project System Tools extension for VS, which records builds as binlogs inside VS, and the MSBuild Binary and Structured Log Viewer to display the binlogs (both from the above extension and msbuild -bl; the latter are richer).
I believe I shared the most significant points of what I've learned about different build processes in a few different MS environments. Again, having no idea about your engineering constraints, I am not suggesting that you should lean toward use this approach; this road is also far from being rosy and will indeed also ask for certain hacks for peculiarities in different project types. I thought it would be worth sharing what I've learned in hope you could find this informative.

Thank you for so detailed advice, it's really interesting to hear all these thoughts.
First of all I do not think you have to change anything in the targets. The only issue I see - the target _Protobuf_AugmentLanguageCompile does not have any dependencies on related (required) targets.
About design time build. At some point Rider called Compile target with DesignTimeBuild=true. In the same way as omni-sharp did. But we have faced several issues and this year we want to still call some predefined targets + all 'Compile-item-producers' as I wrote above. Probably we will review and enable design time build for msbuild 16.0 but I'm not sure for now =)
The short list of reasons for us do NOT call design time build:

Performance. Our set of targets loads big solutions 2 times (for dotnet core 3 times) faster than the same 'Compile + DesignTimeBuild' run.

Unlike VS Rider uses a user's toolset and does not have its own (Ok, technically it has, but it is a different story).
So you just install Rider on the machine and it discovers all msbuild\xbuild installations from .net framework, VS, mono, unity and so on. Then Rider matches required (by solution/projects) and installed (in a build tool) SDKs, targets and API version and some other things and tries to automatically select the best toolset for the current solution automatically.
Of course you can manually choose the toolset, for example then you are testing msbuild built from sources =) Or then you have a special toolset for the solution (like Roslyn repository).
That all means Rider has to be able to work with various different tools (msbuild from 4.0 to 16.0, win, crossplat and even xbuild). So anyway we have to support the most common subset of targets to load different kind of projects (including cpp, yes).

We had problems with design time build in Xamarin projects. Probably they have fixed all these issues already, but one year ago it was impossible to have a stable load+build+deploy chain with design time build somewhy. But I do not remember exact reasons...

So for now it is better for us to find, analyze and collect toolkits where our approach does not work (like protobuf).
By the way Rider has already bundlelled Structured Log Viewer on Windows, in 192 we will add actions to build\load project and immediately show binary logs in viewer.... Wanted to do it in 191, but have no time unfortunately..

@xtmq, thanks for chiming in. I did not realize the scale of the problems you are facing, really. Supporting such a variety of build tools is a really, really hard problem.
Regarding _Protobuf_AugmentLanguageCompile dependencies, it's a part of sequence that is called by ProtoBuf_Compile target:
https://github.com/grpc/grpc/blob/a339a13591cb1fab70abe41ffa03a31d1b196eab/src/csharp/Grpc.Tools/build/_protobuf/Google.Protobuf.Tools.targets#L98-L107
So we could technically say that Protobuf_ResolvePlatform depends on Protobuf_BeforeCompile, and _Protobuf_SelectFiles depends on bothProtobuf_ResolvePlatform and Protobuf_BeforeCompile etc; but it would be a mess and hard to maintain. Such a sequencing semantics is used in MSBuild quite often, for various reasons (different batching requirements; hook-up extension point targets etc). It would not be the best idea to invoke this target by itself; also, the _ prefix conventionally mark an "internal" target, that external scripts should not hook onto, or explicitly invoke.
I see where you are coming from: you essentially want to run Protobuf_Compile for its side effects only, without actually invoking protoc. This is a very sensible idea. There is currently another project that is integrating the tools, and this code is being changed, too. Currently the invocation is gated by this condition
https://github.com/grpc/grpc/blob/a339a13591cb1fab70abe41ffa03a31d1b196eab/src/csharp/Grpc.Tools/build/_protobuf/Google.Protobuf.Tools.targets#L248-L250
but I remember at one point I asked to rename the variable Protobuf_DisableDesignTimeBuild or similar, to keep the naming convention, so its name may also change. Besides this caution, it would be a step up from invoking only a part of the sequence, including internal _... targets.
I suggest this: Since our codebase is currently changing, and your part is working, let's use your fix as is, since your users are waiting for it. In case we break you later, or you'd find you need a better solution for another reason, please open an issue here and tag me (I do not monitor all issues), and we will figure it out. My best thinking is, if there were a variable that we would know is set only in Rider desgn-time build, it would be fairly easy to augment the condition above condition with e. g.  ... and $(RiderDesignTimeBuild) != 'true'. This would be more robust than depending on yet-unfinalized variable, in a sense that anyone who changes this code would pay attention to the special case and won't break it. With this in place, you could call the much more public Protobuf_Compile, and it would do everything for you end-to-end. This may be just one of possible options; we do not need to design everything right now, just keep it in mind in case there would be an issue later.

Ok agreed =)
I think you can close the issue for now

@jtattermusch, this is fixed, please close.

I had to use this same workaround of adding the Target/CallTarget to my csproj in VS2019 on Mac as well. Otherwise intellisense and the using statements could not be resolved.


get() returns undefined when should retrieve 0

Set a key with value 0:
store.set('key', 0);

try to get the value:
store.get('key');

Returns 'undefined'. Works fine when value is not 0

Ignore this. The error was in my code.
I was trying to wrap the get function like this:
function get(key, defaultValue) {

  var data = store(key);
  return data ? data : defaultValue;
}

Since the value of $data was 0, that condition evaluates to false and $defaultValue was returned. $defaultValue was not defined when calling the function:
wrapStorage.get('key');

Glad it wasn't a problem. FYI, the default get() function already supports a defaultValue argument. :)


Allow drag and drop from other apps

Is your feature request related to a problem? Please describe.
Yes. I'm always frustrated when, for example, I've got a zip file open with WinRar, I can't drag and drop and I'm forced to use the default (ugly) windows file, explorer.
Describe the solution you'd like
I'd like to be able to select a file, drag and drop it, from/to an external app or website, and to be able to move files using drag-and-drop directly in the Files app.
Describe alternatives you've considered
I've considered nothing that better and that fast so far

This feature already exists, although not very intuitive. It works if you drop the file onto one of the address bar folder names. You can also drag a file in the app if you select it first, and then drop the file either on some other app or again on a folder name in the address bar or side bar.

Reading around it appears to be a known uwp limitation. UWP can only receive files if they point to physical location on disk.
If you drag a file from e.g winrar it will crash with a System.Exception Invalid FORMATETC Structure
I wouln't know how to solve this
(Obviously we can at least handle the error to avoid the crash and show an error message instead)

Ok, I found a "very creative" solution to this issue.

In Files DragOver event handle the System.Exception: Invalid FORMATETC Structure that is generated
If the exception was caught, the fulltrust process shows a semitransparent window over the Files app
The user can drop the files
The fulltrust process will copy/move the dropped files to the destination folder

Please, find a better solution :)

Ok, I found a "very creative" solution to this issue.

In Files DragOver event handle the System.Exception: Invalid FORMATETC Structure that is generated
If the exception was caught, the fulltrust process shows a semitransparent window over the Files app
The user can drop the files on this window
The fulltrust process will copy/move the dropped files to the destination folder

Please, find a better solution :)

Edit
In case you decide to proceed as above the code is here.

This doesn't look like such a bad solution, I think we should go for it.

@yaichenbaum if you like it, you can give it a try. The code in the branch "fix_dragdrop" should be already working (though based on an old master)

This issue should be fixed with #2511.


Fix display of headings in summary tables

These headings are only meant to be for screen readers. They are not meant to be shown visually, but at the moment they are:

This commit hides them.
P.S. When I make the pull request on the Marketplace I'll improve the language from key/value!

LGTM. Can you put this change into a separate pull request on the gh-pages branch too?

Done as #23


Ikhapova managing accesspatch 1

Docs Build status updates of commit 2f588bd:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

MicrosoftCollaboratePortal/images/Membership-tab.PNG
:white_check_mark:Succeeded

MicrosoftCollaboratePortal/managing-org-users.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


cannot fetch image descriptor: Get "https://index.docker.io/v2/

Hi there,
We have deployed bank-vaults into a secure environment where there is no external connectivity to dockerhub. We see following error when the admission controller is trying to mutate the pod spec.
vault-secrets-webhook-7857b544ff-r8bvp vault-secrets-webhook time="2022-10-03T10:30:21Z" level=error msg="Admission review request failed" app=vault-secrets-webhook dry-run=false error="cannot fetch image descriptor: Get \"https://index.docker.io/v2/\": dial tcp <IP_ADDRESS>:443: i/o timeout" kind=v1/Pod name= ns=default op=create path=/pods request-id=a64e229b-956-4fed-8f06-e2ef9aed82 webhook-id=vault-secrets-pods webhook-kind=mutating wh-version=v1beta1
How do we configure bank vaults to completely bypass going to the docker hub.
Regards,
Dev

The logic that seems to be messing with vault-secrets-webhook in air gapped environments seems to be the logic found here it doesn't seem to be friendly to air gapped environments. So I tried to find a workaround and found "solution" that worked for me.
First of all, the init container will try and use the same registry as the pods image registry, so if you want to pull from https://my-private-registry.com then you must set the pods image to https://my-private-registry.com/my-image:v1.0.0, this will make vault-secrets-webhook try and ping your private registry instead of index.docker.io.
Then you have to create a secret of type dockerconfigjson and add the secret to the ServiceAccount used by the pod trying to start up the vault init container. The caveat is the registry must match the image that the
Example:
apiVersion: v1
kind: Secret
metadata:
  name: myregistrykey
  namespace: default
stringData:
  .dockerconfigjson: |
    {
        "auths": {
            "https://my-private-registry.com": {
                "auth": "Zm9vOmJhcgo="
            }
        }
    }
type: kubernetes.io/dockerconfigjson
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
imagePullSecrets:
  - name: myregistrykey

Although this solves the issue, I would hope there is a correct solution so the code is air gap friendly.


Fix for #3874: [BUG] Aggregate javadocs not updated

This fixes the issue identified in #3874 by enabling the aggregate javadoc to be published into the 'staging' directory as before. This fixes a regression introduced by 03722f247a7abec87de1f3e286e64498c9aaad9d.

Closing - I believe @srnagar has resolved this and filed appropriate follow-up issues.


CMP implementation, incremental PR chunk 3: CMP ASN.1 structures

Certificate Management Protocol (CMP, RFC 4210) extension to OpenSSL.
Also includes CRMF (RFC 4211) and HTTP transfer (RFC 6712).
CMP and CRMF API is added to libcrypto, and the "cmp" app to the openssl CLI.
Adds extensive man pages and tests.  Integration into build scripts.
3rd chunk: CMP ASN.1 structures (in crypto/cmp/cmp_asn.c) and related files.
Tests will be added with chunk 4 and following.

Checklist

[x] documentation is added or updated

This is the first chunk with contributions also by @Akretsch.
He is going to be the main person handling review comments.

Thanks @mattcaswell and @FdaSilvaYY for your comments.
We have meanwhile handled all of them, performing all requested changes.

@mattcaswell, we have a general question regarding the review process of the CMP chunks.
Chunk 3 is still under review, and it seems likely that even if you approve it soon it will take some further while until it can be merged since a second review (which has not yet started) and approval is needed.
Chunk 4 will be pretty orthogonal to chunk 3 (as it will focus on the OSSL_CMP_CTX structure with its getters and setters, plus some auxiliary and logging functions), and meanwhile we have got pretty far preparing it.
In order to save time (since the overall timeline for the CMP contribution until the release of 3.0.0 is pretty tough), would it make sense to submit chunk 4 somewhat in parallel to chunk 3, for example just after you have approved chunk 3?

Does chunk 4 depend on the chunk 3 commits? It's easier to review if it doesn't because github shows all code that isn't in the target branch when you are reviewing.

Unfortunately, there are a couple of files (at least cmp.h and cmp_int.h and some meta files) where there is a dependency because they get extended by each chunk.

Unfortunately, there are a couple of files (at least cmp.h and cmp_int.h and some meta files) where there is a dependency because they get extended by each chunk.

That is unfortunate. You could create chunk 4 as a WIP PR but github will show it with all the chunk 3 commits. It is possible to click into each individual commit and review each one in turn, but if there are multiple commits this is also problematic because it is difficult to get a "big picture" view.

Another workaround could be to submit at first only the 'meat' of the next chunk, i.e., the new source, doc, and test files, and to add the files that have dependencies later.

Unfortunately, there are a couple of files (at least cmp.h and cmp_int.h and some meta files) where there is a dependency because they get extended by each chunk.

That is unfortunate. You could create chunk 4 as a WIP PR but github will show it with all the chunk 3 commits. It is possible to click into each individual commit and review each one in turn, but if there are multiple commits this is also problematic because it is difficult to get a "big picture" view.

@DDvO you could open a pull request for chunk4 against chunk3 in your own repository for @mattcaswell to (p)review. Doing that, Matt would get to see the big picture, but without the commits from chunk3. To create the pull request, just go to the following comparison page:
https://github.com/mpeylo/cmpossl/compare/cmpossl_incremental3...mpeylo:cmpossl_incremental4?expand=1
(Currently, there seem to be merge conflicts, which you will need to fix first. Best is to rebase chunk4 on top of chunk3 first.)

You could even create two pull requests: an „official“ one against master in our repo, and an incremental one in your repo for reference.

@DDvO you could open a pull request for chunk4 against chunk3 in your own repository for @mattcaswell to (p)review. Doing that, Matt would get to see the big picture, but without the commits from chunk3.

This sounds like a good way to go, thanks @mspncp for this hint!
@mattcaswell, what do you think?

To create the pull request, just go to the following comparison page:
https://github.com/mpeylo/cmpossl/compare/cmpossl_incremental3...mpeylo:cmpossl_incremental4?expand=1

@mattcaswell, would you be able to give review comments in that repository?

(Currently, there seem to be merge conflicts, which you will need to fix first. Best is to rebase chunk4 on top of chunk3 first.)

Yes, this is because (as mentioned in a response to a review comment above: https://github.com/openssl/openssl/pull/8669#discussion_r276321325) I needed to squash (most of) cmpossl_incremental3. We'll rebase our preliminary cmpossl_incremental4 tomorrow.

You could even create two pull requests: an „official“ one against master in our repo, and an incremental one in your repo for reference.

@mspncp, I did not get what you mean here. Also the 'official' one is necessarily incremental.

You could even create two pull requests: an „official“ one against master in our repo, and an incremental one in your repo for reference.

@mspncp, I did not get what you mean here. Also the 'official' one is necessarily incremental.

The idea was that an 'inofficial' pull request in your clone would go unnoticed by most people except for Matt. However, an 'official' pull request against our repo would need to be made against master, so it would have to include the changes from chunk3. So the solution would be to make an official pull request against our master and in the description of the pr include a link to the relative pr on your repo. Whenever you push changes to chunk4, both pull requests would be updated.
Well, it's just an idea. You don't have to do it if it sounds too complicated.

(Note: I'm assuming that your branch for chunk4 will be based on top of the branch for chunk3.)

This sounds like a good way to go, thanks @mspncp for this hint!
@mattcaswell, what do you think?

Sounds like a good idea to me

@mattcaswell, I've just resolved all (new) review comments on this PR, handling all change requests.

This sounds like a good way to go, thanks @mspncp for this hint!
@mattcaswell, what do you think?

Sounds like a good idea to me

@mattcaswell, I've meanwhile rebased both branches, such that as mentioned by @mspncp :
https://github.com/mpeylo/cmpossl/compare/cmpossl_incremental3...mpeylo:cmpossl_incremental4?expand=1
you can have a clean preview of our chunk 4 and could already do a first review pass there.
What we have not yet done for chunk 4 is to add the respective portions of the documentation.

Looks like it needs a rebase.

@mattcaswell, I've meanwhile rebased both branches, such that as mentioned by @mspncp :
https://github.com/mpeylo/cmpossl/compare/cmpossl_incremental3...mpeylo:cmpossl_incremental4?expand=1

Note: If you actually create the pull request, then Matt can add preview comments.

@mattcaswell, I've meanwhile rebased both branches, such that as mentioned by @mspncp :
https://github.com/mpeylo/cmpossl/compare/cmpossl_incremental3...mpeylo:cmpossl_incremental4?expand=1

Note: If you actually create the pull request, then Matt can add preview comments.

@mattcaswell, pleased to see that you have approved chunk 3.
As discussed above, here is a preview of chunk 4: https://github.com/mpeylo/cmpossl/pull/178

The merge commit just pushed will need to be removed. Unfortunately we do not alllow merge commits in the repo. You have to rebase on a fresh master instead.

The merge commit just pushed will need to be removed. Unfortunately we do not alllow merge commits in the repo. You have to rebase on a fresh master instead.

Sorry for that glitch. I've just fixed it, also rebasing https://github.com/mpeylo/cmpossl/pull/178/

@bernd-edlinger, since you already kindly reviewed chunk 1 and 2 (the CRMF portion) of the CMP contribution and we still need a second review for this chunk (ASN.1 portion of CMP), could you do this?

@mattcaswell, meanwhile we have completed our preview of chunk 4: mpeylo#178

I'm against burying such a global change inside this large pull request. Commit 67032c0 should be reverted and a separate pull request created for this change.

@mspncp, as you requested, we have moved this commit containing the mentioned general improvements to a separate PR: #8890.

I'm against burying such a global change inside this large pull request. Commit 67032c0 should be reverted and a separate pull request created for this change.

@mspncp, as you requested, we have moved this commit containing the mentioned general improvements to a separate PR: #8890.

By the way: rereading my change request, it appears to me in hindsight that it was formulated unnecessarily harsh. My apologies, in case you conceived it that way, too.

By the way: rereading my change request, it appears to me in hindsight that it was formulated unnecessarily harsh. My apologies, in case you perceived it that way, too.

Thanks @mspncp. The formulation of your change request was not a problem to us.

@bernd-edlinger, since your last reviewing activity on this PR three weeks have passed.
Could you please have a look at the changes we did 20-21 days ago?
Is there anything more to do (except that we'll rebase this PR on master again when #8890 has been merged, while #8897 has already been merged), or can you give your approval now?

Please re-base to current master.

We have done the rebase.
Travis CI timed out on two builds, but I suspect that this is unrelated to this PR.

Btw: The cla bot is complaining about a missing CLA? Is it because of @Akretsch‘s commits?

Btw: The cla bot is complaining about a missing CLA? Is it because of @Akretsch‘s commits?

I was wondering about this CLA complaint, too.  It is about @Rick113's commits.
I've just double-checked: Roman Schauer sent his CLA already on May 13th,
but apparently is has not yet made its way into the OpenSSL contributors' database.

I've just double-checked: Roman Schauer sent his CLA already on May 13th,
but apparently is has not yet made its way into the OpenSSL contributors' database.

cc @mattcaswell

Close/reopen to kick cla bot

I've just double-checked: Roman Schauer sent his CLA already on May 13th,
but apparently is has not yet made its way into the OpenSSL contributors' database.

Apologies for the delay on this. Roman's email ended up in my spam folder for some reason. All sorted now.

Squashed and pushed. Thanks all!


Does it really work with Xamarin?

Q/A says it'll work with Xamarin, but everyone seems to have problems with getting this to work. Was this answer based on guesswork? Please update that Q/A, or help the community get this working.
More discussion here:
https://github.com/Azure/azure-spatial-anchors-samples/issues/24

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c6c4d018-b95c-2d64-1620-bf47bf86ff65
Version Independent ID: 639519b8-bfd6-2a1a-e862-16438a94a54d
Content: Frequently asked questions about Azure Spatial Anchors
Content Source: articles/spatial-anchors/spatial-anchor-faq.md
Service: azure-spatial-anchors
GitHub Login: @RamonArguelles
Microsoft Alias: rgarcia

@dotMorten Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

@RamonArguelles Please check this issue and update the document if necessary.

It does work, but it's not currently very easy to do. I don't know why we say that in the FAQ as it just causes confusion. We'll remove that question from the FAQ.
We are currently investigating Xamarin bindings that will make Xamarin support easier. Nothing more to share at this point.

I've reworded the answer in the FAQ.

@AshokPeddakotla-MSFT, we can close this issue.

@craigktreasure Thanks for an update.
@dotMorten We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


The size of the exe packaged by forge is ridiculously large. I think this is caused by not using vite build to build the dist directory. Also, all dependencies of dependent libraries are packaged, without distinguishing between used and unused ones.

Pre-flight checklist

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project uses.
[X] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version
7.1
Electron version
27.1
Operating system
win10
Last known working Electron Forge version
No response
Expected behavior
The dist directory built by forge using vite
Actual behavior
Hello, I used electron-forge to package the vite practice project into an exe. The dist directory built through npm run build is only 108kb. But the asar file built through electron-forge reaches 18mb. Is this because I haven't configured it? Or is this how the packager works, without using the dist directory built by vite.
The size of the exe packaged by forge is ridiculously large. I think this is caused by not using vite build to build the dist directory. Also, all dependencies of dependent libraries are packaged, without distinguishing between used and unused ones.
Steps to reproduce
none
Additional information
My project structure:
root
electron: Place main.js and preload.js of electron
src: Place the files of vue and main.js (vue).
index.html file
...
forge.config.js content
module.exports = {
   packagerConfig: {
     asar: true,
     productName: "APp",
   },
   rebuildConfig: {},
   makers: [
     {
       name: '@electron-forge/maker-squirrel',
       config: {},
     },
     {
       name: '@electron-forge/maker-zip',
       platforms: ['darwin'],
     },
     {
       name: '@electron-forge/maker-deb',
       config: {},
     },
     {
       name: '@electron-forge/maker-rpm',
       config: {},
     },
   ],
   plugins: [
     {
       name: '@electron-forge/plugin-auto-unpack-natives',
       config: {},
     },
     {
       name: '@electron-forge/plugin-vite',
       config: {
         // `build` can specify multiple entry builds, which can be
         // Main process, Preload scripts, Worker process, etc.
         build: [
           {
             // `entry` is an alias for `build.lib.entry`
             // in the corresponding file of `config`.
             entry: 'main.js',
             config: 'vite.main.config.js'
           },
           {
             entry: 'preload.js',
             config: 'vite.preload.config.js'
           }
         ],
         renderer: [
           {
             name: 'main_window',
             config: 'vite.renderer.config.js'
           }
         ]
       }
     }
   ],
};

Hi, I had a similar issue, in my case, there were unnecessary files in the project that were added to the .exe, once I told forge to exclude them the .exe sized decreased significantly
All I had to do was add the ignore option to packagerConfig in forge.config.js
It takes a regex object or array of regex objects, in my case it looks like this
packagerConfig: {
 ignore: [/\.angular$/, /src$/];
}

of course you are using vite, I dont know if that means you have to place this somewhere else

Check my answer in the related question - https://github.com/electron/forge/issues/3423#issuecomment-1849085365

Fixed in #3336


Can we transfer the scissors from the bottom to the head? Sometimes it's difficult to locate the enemy's head

Can we transfer the scissors from the bottom to the head? Sometimes it's difficult to locate the enemy's head

skill issue


Plugins added with the ADD command will not be copied.

I tried to add a plugins to a pre baked image.
I found the following answer in the issues.
COPY plugin /plugins
It works as well as expected.
However, unlike COPY commands, ADD commands do not work as expected.
ADD https://<plugin url> /plugins/
I checked the /plugins folder and it was added but not copied to /data/plugins folder.
Is there a way to solve this problem?

I solved this problem.
Files imported from the Web through the ADD command do not have R permission.
I just added a line to the Dockerfile.
RUN chmod +r /plugins/*.jar


[ZEPPELIN-6135] Fix clean goal not removing interpreter/ output(Spark,Flink)

What is this PR for?
The Maven clean goal does not remove some interpreter files in interpreter/ directory as expected.
Specifically, the spark and flink interpreters are not cleaned.
This happens because when extending the pom.xml in the pom.xml of these interpreters, they lack the interpreter.name property.
As a result, the clean target directory configured in zeppelion-interpreter-parent was not properly resolved before.
What type of PR is it?
Bug Fix
Todos

[ ] - Task

What is the Jira issue?

Open an issue on Jira https://issues.apache.org/jira/browse/ZEPPELIN-6135

How should this be tested?

Build Zeppelin
Clean Zeppelin and check if all interpreters are removed in interpreter/

Screenshots (if appropriate)
Questions:

Does the license files need to update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

@Reamer
Thanks for pointing that out. Just to confirm, you're saying that it makes sense for the clean goal to run in the module where the output is created, right? I updated it to run from spark/interpreter based on that.
Also, quick question, is it okay to delete the entire interpreter/spark directory, including the spark-scala interpreter JARs? I used a wildcard for simplicity, but if those files need to stay, I'll adjust it to only delete specific directories.

In general, this interpreter jar cleanup should already work.
The special clean goal in the interpreter parent should be triggered by the Flink submodule flink-scala-2.12 and the Spark submodule spark-interpreter
You can find the cleanup goal here.
https://github.com/apache/zeppelin/blob/ea0802d24b5fd46a6113481cad3a5f53cecec879/zeppelin-interpreter-parent/pom.xml#L163-L174
Maybe it doesn't work because of the special submodule structure. I will check this out.

The path is not correct due to the submodule structure in Flink and Spark. Not to make it too complicated, I would be in favor of your first contribution suggestion. Put the interpreter name in the parent pom.xml of Spark and Flink. Theoretically you could then remove it in the corresponding submodules.
It is desirable that the complete folder is removed.
In general, I don't think it's good that all interpreters store files outside. But this can be adjusted in the future.
Thank you for finding the bug.

@Reamer Thanks for checking things out!
I've reverted the second commit to go with the simpler solution you suggested. I also removed the unnecessary clean tasks in the Spark interpreter submodules.
Could you please check if these changes align with your suggestions?

Just two minor lines.
I think we can delete the following lines
https://github.com/apache/zeppelin/blob/3575a3cf8834cdc0100f0a554846829584df0c30/flink/flink-scala-2.12/pom.xml#L36
https://github.com/apache/zeppelin/blob/3575a3cf8834cdc0100f0a554846829584df0c30/spark/interpreter/pom.xml#L36
What do you think?

@Reamer I agree with you; it's better to keep a single source of truth. I've updated these as you suggested.


disable AsyncDispatcher use for emscripten

I guess it is work in progress since you already implemented the dispatch_seq. it compiles to wasm & works for me after this fix.

Ah, thanks! I didn't check whether or not Specs works with emscripten, but only shred.
bors r+


Add additional toss attributes to Match

toss_choice_team_id
toss_decision
toss_decision_name
toss_winner_team_id

Hi can I send a PR for this?

@salman-bhai Absolutely!


Use hard-coded gas values in the verifications flow

Description
Especially on high latency and slow network connections, gas estimation can regularly take a very long time, often 10-20 seconds, and represents a point of failure if network conditions are degraded.
In this PR, gas values are set statically based on the gas usage of representative transactions. This eliminates the need for gas estimation and will increase performance and reliability of the verifications flow. I've chosen to use 1.5x the highest observed gas usage in representative transactions.
One risk of this change is that it makes the flow fragile to significant future changes to the Attestations flow. If for some reason in the future, the Attestations smart contract requires a significant amount more gas to run the same functions, old client will not be compatible. I am proposing this change now because I see that changes that increase the gas cost by more than 1.5x, without breaking interface, are fairly unlikely and will certainly not be done regularly.
Tested
Tested by running through the verifications flow on Alfajores. Including on my WiFi and on simulated 3G connectivity.
Note:
When testing with simulated 3G connectivity, the flow was completed up to having selected issuers in a little over 1 minute (compared to about 45 seconds on WiFi) but failed on first try and took about 2 minutes 15 seconds on the second try when using master.
Backwards compatibility
100%

Hi @jeanregisser , @nategraf verified task using Test flight build v1.4.0 (28) and Android play store (internal build) v1.4.0<PHONE_NUMBER>) and found the verified failed pop up is shown when user try to verify phone number using 3G connection mobile data.
Verified device: iPhone SE (13.5.1)	Samsung Galaxy A5(7.0).
Please find the logs for the same which may help to fix the issue.
celo_logs.txt


initializeDateFormatting examples in the documentation use null when not allowed

The DateFormat documentation (as of intl 0.18.1) includes examples for calling initializeDateFormatting:

import 'package:intl/date_symbol_data_file.dart';
initializeDateFormatting('de_DE', null).then((_) => runMyCode());

import 'package:intl/date_symbol_data_http_request.dart';
initializeDateFormatting('pt_BR', null).then((_) => runMyCode());

Those examples are no longer legal since those two implementations of initializeDateFormatting take a non-null String as their second argument. (However, note that the implementation from date_symbol_data_local.dart does have nullable parameter types.)

The fact that the documentation is wrong brings me to the problem that I do not understand how to initialize intl correctly.
I alway get the error:

"Locale en_US has not been initialized. Call initializeDateFormatting(en_US, ) first"

But I do not know what to use as "".

But I do not know what to use as "data url".

Is your import for initializeDateFormatting from import 'package:intl/date_symbol_data_local.dart';?

Thanks, my error was using import 'package:intl/date_symbol_data_file.dart'; instead of ..._local


feat(rtc_manager_panel): add rtc all approval

Signed-off-by: taikitanaka3<EMAIL_ADDRESS>Description

add rtc exe mode and wait mode button

https://user-images.githubusercontent.com/65527974/193736296-f37a2bf7-d20b-4b61-9a61-11024817806f.mp4
Related links
resolve https://github.com/autowarefoundation/autoware.universe/pull/2009
'Tier4 INTERNAL LINK'
Tests performed
not yet
Notes for reviewers
this can easily tested by psim
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[ ] I've confirmed the contribution guidelines.
[ ] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

@rej55
Can you review this PR please?

The document is going to look like this.

@rej55
I updated documents with Execute and Wait button. It will be more appropriate expression

I tried this tool.
It is okay for modules included in behavior_velocity_planner.
I think execute button for following modules should be separated from other modules.
Furthermore, it would be better to have separate buttons for individual ids.

Lane change
Avoidance
Pull over
Pull out

@rej55
How about this layout?

All cooperate command
Execute
Wait

Lateral cooperate command
Execute
Wait

Longitudinal cooperate command
Execute
Wait

it would be better to have separate buttons for individual ids
yes I implemented it but it sometimes doesn't work as expected, maybe because of latency of button signal and fast update of rtc status. if it works fine I will add.

Longitudinal command is okay but lateral modules should not be placed all execute command.
This is because most lateral modules cannot be canceled once executed.

I tried this tool. It is okay for modules included in behavior_velocity_planner.
I think execute button for following modules should be separated from other modules. Furthermore, it would be better to have separate buttons for individual ids.

Lane change
Avoidance
Pull over
Pull out

This suggestion will be handled in other PR.


record account freezes, with freeze reason %tags

todo

[x] rename freeze to something that's not a reserved postgres word so people don't need to remember to quote that table's name
[ ] hold on to more than just account name (email, maybe?)

going to merge as-is and we can add more on to this later


Conditional env vars

Hi, not sure if this is implemented already, couldn't find it in the docs:
One common pattern I use is to set cargo-make env variable to corresponding env var if it's defined, or revert to a default value if not set:
QEMU = { value = "${QEMU}", condition = { env_set = ["QEMU"] } }
QEMU = { value = "qemu-system-aarch64", condition = { env_not_set = ["QEMU"] } }

Is there a shorter way to express that? If not, could it be added?

you only need the second line, no?

Hmm, you're probably right, thanks! :)


Enum pin-projections

I'm not sure if there's any nicer API that pin-utils could provide, but I recently had to manually implement pin-projections into an enum, if there's some way to encapsulate this into a macro that ensures most of the safety it would be great. (Maybe a proc-macro-attribute like discussed in #20 could do this with annotated variants? @taiki-e). Here's an example from futures (I don't really care about the exact API here, just something that allows the same operations to be written without any unsafe):
#[derive(Debug)]
enum ElemState<F>
where
    F: Future,
{
    Pending(F),
    Done(Option<F::Output>),
}

impl<F> ElemState<F>
where
    F: Future,
{
    fn pending_pin_mut<'a>(self: Pin<&'a mut Self>) -> Option<Pin<&'a mut F>> {
        // Safety: Basic enum pin projection, no drop + optionally Unpin based
        // on the type of this variant
        match unsafe { self.get_unchecked_mut() } {
            ElemState::Pending(f) => Some(unsafe { Pin::new_unchecked(f) }),
            ElemState::Done(_) => None,
        }
    }

    fn take_done(self: Pin<&mut Self>) -> Option<F::Output> {
        // Safety: Going from pin to a variant we never pin-project
        match unsafe { self.get_unchecked_mut() } {
            ElemState::Pending(_) => None,
            ElemState::Done(output) => output.take(),
        }
    }
}

The current pin-project supports this and can be written as follows:
use pin_project::pin_project;
use std::pin::Pin;

#[pin_project(project = EnumProj)]
enum Enum<T, U> {
    Tuple(#[pin] T),
    Struct { field: U },
    Unit,
}

impl<T, U> Enum<T, U> {
    fn method(self: Pin<&mut Self>) {
        match self.project() {
            EnumProj::Tuple(x) => {
                let _: Pin<&mut T> = x;
            }
            EnumProj::Struct { field } => {
                let _: &mut U = field;
            }
            EnumProj::Unit => {}
        }
    }
}


In RRGL, when using lg and creating layout with Infinity, browser hangs

I just experienced this problem that the browser just hangs when I create a new layout with y: Infinity and layouts={{ lg: myLayouts }}. It works just fine with layouts={{ md: myLayouts }}. My screen width is 1358, so I set it to lg as default. I tried this layouts={{ md: myLayouts, sm: myLayouts, xs: myLayouts }}, and it works fine, but the browser will hang if i add the lg: myLayouts.

I did a little research, this is caused by that when my RRGL mounted, it has no layout, and then later I added the first one with y: Infinity. That runs into an infinite loop in the utils.js here:
export function compactItem(compareWith: Layout, l: LayoutItem, verticalCompact: boolean): LayoutItem {
  if (verticalCompact) {
    // Move the element up as far as it can go without colliding.
    while (l.y > 0 && !getFirstCollision(compareWith, l)) {
      l.y--;
    }
  }
...

A simple fix would be just adding a check to see if the layout is the first or only one here.

Ran into this today. Sort of seems that Infinity is a weird workaround for "adding items at the end". Almost wonder if x: null, y: null, should be supported, and then throw those items at the end by default.


Add Typespecs

I added typespecs to all functions and I hope everything is correct but I think it would be a good idea to look over them, especially because I'm a bit tired right know 🙃.

This fixes #3.

Hm looks like charlist as a type annotation got introduced somewhere between Elixir 1.0.2 and 1.3.1 though I can't find it in the changelogs.
Should I fix this or should we upgrade the elixir version?
--
Note aside: While investigating this I noticed that 1.3.0 soft-deprecated to_char_list which is used in replace_special_characters.

I took your actions as a sign that you want to support elixir from version 1 up 😃 . I switched to char_list.
Obviously all OTP 19 builds fail in here but all others are passing (see #18).
I now really messed up that git history, so if you are going to merge that stuff you really should squash.

Will have a look on it. Thank you very much :)


Targets refactor

Refactors this project to use targets.  Run tar_make() to reproduce all steps.  Splits up code that was previously in azmet-qaqc.qmd into individual functions.

Unfortunately, I don't think reviewing this PR will be very informative because of the extent of the changes.  Instead it might be better to just demonstrate it next time we meet.