espcoredump broken pipe

Hi I am trying to use espcoredump, but I am getting a broken pipe issue.
python $COREDUMP_PATH/espcoredump.py info_corefile -t b64 -c coredump.dat build/my_thing.elf

espcoredump.py v0.1-dev
===============================================================
==================== ESP32 CORE DUMP START ====================

================== CURRENT THREAD REGISTERS ===================
/Users/ivan/e/ESPTools/crosstool-NG/.build/src/gdb-7.10/gdb/findvar.c:290: internal-error: struct value *value_of_register_lazy(struct frame_info *, int): Assertion `frame_id_p (get_frame_id (frame))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
/Users/ivan/e/ESPTools/crosstool-NG/.build/src/gdb-7.10/gdb/findvar.c:290: internal-error: struct value *value_of_register_lazy(struct frame_info *, int): Assertion `frame_id_p (get_frame_id (frame))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
GDB/MI command failed (None / None)!

==================== CURRENT THREAD STACK =====================
Traceback (most recent call last):
  File ".../esp-idf/components/espcoredump/espcoredump.py", line 1106, in <module>
    main()
  File ".../esp-idf/components/espcoredump/espcoredump.py", line 1101, in main
    operation_func(args)
  File ".../esp-idf/components/espcoredump/espcoredump.py", line 1009, in info_corefile
    p.stdin.write("-interpreter-exec console \"bt\"\n")
IOError: [Errno 32] Broken pipe

What is in "coredump.dat"?

+CUAAA4AAAB8AQAA
2N/8P8Dc/D/M3/w/
kN78P2Df/D/kpwEAICT8PyAk/D/Y3/w/GCT8PxQAAACkqvw/pKr8P9jf/D8AAAAA
BQAAANDb/D9zZG1fcmVhZGVyX3Rhc2sA////f8zf/D8BAAAAIA4GAAUAAABljp+R
BQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADH2nw=
p9z8PwOSAEA2CAYAJEcIgIDd/D+IAAAAiAAAABAAAAD/////AAAAAOX///80Ivw/
AQAAACQAAAAkAAAACAAAAP////8AAAAA/////wUAAAABAAAAAAAAAEnDAEBrwwBA
/////wgAAAD/////vA8IQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAOIJAAAAAAAAph1APwAAAACaNQiAoN38P2Nvbm4AAAAA
rBAIQPC/AEAwDwYALEMIgMAWCIDQ3fw/BJz+P5wlQD8EnP4/8L8AQDAJBgAsQwiA
nCVAPwAAAAAAAAAAAAAAAGIXCIAQ3vw/BJz+PwEAAACQBfw/AAAAAAEAAAAAAAAA
AAAAAAEAAAABAAAAEwAAAFSc/j8AAAAAAAAAAAwAAACl9A2AQN78P/An/D8jAAYA
rBAIQKxLDkAwAAYANCEOgAEAAAABAAAAAAD/AAAAAP+HGAiAYN78P9bfnbQqSgUA
IAAGAAaoAQALAAAAAgAAAGy8AICA3vw/WOD8P8De/D8oQAiAIMn8PwMAAAAjAAYA
UxgAgKDe/D9Y4Pw/wN78PwAAAAAW3/w/AwAAAAAAAABIIA6AwN78PwAAAAAAAAAA
AAAAAMDS/D8jCQUAAAAAAAAAAADw3vw/AwAAAAAAAMHoAwAA8N78PwAAAMG+pQEA
yKr8PwAAAADkqvw/AAAAAAAAAABg3/w/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAQADAADAAAAAwAAAKAmv1gAAADBAwAAAAAAAAAAAAAA
AAMEAAwAArAqAAAAAAAAwVwp/D8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABs3/w/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
aKD+P2Cf/j9coP4/
YJ/+P/Cf/j+xqQEADCT8Pwwk/D9ooP4/BCT8PxUAAADk4fw/5OH8P2ig/j8AAAAA
BAAAAGCc/j9tZXNzYWdlX3JvdXRlcl8A////f1yg/j8AAAAAIAIGAAwAAAD1ITJQ
BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACPo1A=
AAAAAIs5CIAgAgYAAAAAAAAAAADAn/4/AAAAAAAAAAAAAAAAyaUBACACBgDIsgEA
6AMAAMCf/j8AAAAAAAAAAAji/D8AAAAAAQAAAAUAAAAAAAAA8J/+PwAAAAAAAAAA
AwAAAJ0mv1gAAADBAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD8n/4/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
yMr8P1DJ/D+8yvw/
UMn8P1DK/D/MRg4ovCP8P7wj/D/Iyvw/tCP8PxkAAADxDKXcu7rgX8jK/D8AAAAA
AAAAAIDF/D9JRExFACbTzHOyOI6ymecAAAAAALzK/D8AAAAAIQAGAAMAAADymnZp
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYsDo=
rBAIQIgYDUAwBAYAJEcIgBDK/D8IAAAAAQAAACMCBgDIyvw/AQAAAAAAAAB4Ivw/
8Mn8PwAAAAAgBAYAIAcGAKbSAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAK0SCECm0gAA2FIIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAACAHBgCm0gAAAQAAAAAAAAAAAAAAMMr8PwAAAAAAAAAA
IwIGAMjK/D8BAAAAAAAAAAAAAABQyvw/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXMr8PwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
fBn9PzAY/T9wGf0/
MBj9PxAZ/T8LqAEA7A39PwTE/D98Gf0/oCP8PwcAAABoEP0/aBD9P3wZ/T9gEP0/
EgAAAHQR/T90aVQAxF/P0gVv1LIIER8A////f3AZ/T8AAAAAIAAGAAcAAACr0T3r
EgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAHy//j8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABOcJU=
AAAAAIs5CIAgAAYAAAAAADhLEICQGP0/GGX8P+AY/T8AAAAAp6cBAAAAAAAAAAAA
ZAAAAAEAAAAAAAAAAAAAAIwQ/T8AAAAAAQAAAHgFAABn2g+AwBj9Pxhl/D/gGP0/
Z9oPgMAY/T8YZfw/4Bj9P2QAAACnpwEA9v///wEAAAAAAAAA4Bj9P+x0EEAAAAAA
IEoQQAAAAAABAAAAAAAAAAAAAAAQGf0/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwZ/T8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
5A39PxAN/T/YDf0/
EA39P3AN/T8aqAEA/Kn+P4QZ/T/kDf0/oCP8PxQAAAD0/Pw/9Pz8P+QN/T8AAAAA
BQAAANz9/D9tYW5hZ2VfY29ubmVjdGkA////f9gN/T8AAAAAIA0GAAYAAAAGHJnL
BQAAAAAAAAAwm/4/AAAAAAAAAAAwYRBAAAAAAAAAAAALAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAFhR/z8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgNg4=
AAAAAJRGCIAgDQYAQgAAAAAAAABQDf0/AAAAAAAAAAB0/fw/AAAAACT9/D8BAAAA
AAAAAHAN/T8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAB8Df0/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA=
9Kn+P4Co/j/oqf4/
gKj+P4Cp/j8nqAEAXNT8P+wN/T/0qf4/oCP8PxQAAADadCKX911fEfSp/j8AAAAA
BQAAAOyh/j9wdWJsaXNoZXJfdGFzawAA////f+ip/j8AAAAAIAIGAA0AAABoYA0T
BQAAAAAAAACoT/8/AAAAAAAAAAAwYRBAAAAAAAAAAAAMAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8QUP8/SB0AQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADINP8=
AAAAAJRGCIAgAgYAnacBAAAAAADAqP4/AAAAAGwM/D9kAAAARKn+P8j8/D8GAAAA
AAAAAICp/j8AAAAAAAAAAAAAAAAAACDAMAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAFNvbFNlbnNlQzJEVFNUMDAxAAAAAAAAAAAAAADkDPw/nCa/WAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjKn+PwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
VNT8P2DT/D9I1Pw/
YNP8P+DT/D+wrQEA6L/+P/yp/j9U1Pw/oCP8PxgAAAAUkvw/FJL8P1TU/D8Mkvw/
AQAAAEzM/D9UbXIgU3ZjAJJNoP+QlOkAAAAAAEjU/D8AAAAAIAsGAAQAAADEYKmW
AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2p30=
AAAAAEpRCIAgCwYAAAAAAAAAAACw0/w/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
NocBAPzD/D8BAAAAAAAAAAAAAADg0/w/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOzT/D8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
4L/+P7DV/j981v4/
sNX+PxDW/j/kjwIAqCP8P1zU/D/gv/4/oCP8Pw8AAAAAAAAAAAAAAOC//j8AAAAA
CgAAAIDG/j9tcXR0X2NsaWVudF9sb28A////f3zW/j8AAAAAIAAGABAAAAAAAAAA
CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE=
AAAAAJRGCIAgAAYAAAAAAAAAAADw1f4/AAAAAAAAAAAjCwYA4L/+PwEAAAAAAAAA
AAAAABDW/j8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAc1v4/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
/MP8PwDD/D/ww/w/
AMP8P5DD/D8GqAEAhBn9P6gj/D/8w/w/oCP8PxgAAABuxNVwoRdtifzD/D8AAAAA
AQAAAPSz/D9tYWluADQ6Yu0eSWsffe0AAAAAAPDD/D8AAAAAIAsGAAIAAACe3mpW
AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADxPhg=
AAAAAJRGCIAgCwYABQAAAJEQDYBAw/w/////fwAQAAAAEAAAAAAAAAoAAAAAAAAA
AAAAAHDD/D8AAAAAAAAAAP///38AAAAAAAAAAAAAAAAjAAYAVNT8PwEAAAAAAAAA
AAAAAJDD/D8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAACcw/w/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
YPz9PxCH/j8EiP4/
EIf+P6CH/j/iJPoxbCn9P3iy/D9g/P0/RCP8PwQAAACU+/0/lPv9P2D8/T+M+/0/
FQAAAAiA/j9wbVQAx0OIjQiG+70lfl8A////fwSI/j8AAAAAIA0GAAoAAABHiwCp
FQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEIs0=
AAAAAIs5CIAgDQYA2FIIQAAAAABwh/4/SEf8P+BgQD8AAAAAgaUBAEhH/D/gYEA/
/////wAAAAAAAAAAAAAAALj7/T8AAAAAAQAAAAAAAAAAAAAAoIf+PwAAAAAAAAAA
BgAAAAAAAAAAAAAAAAAAAEhI/D/wAAAASEf8PwAAACAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAACsh/4/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAA==
ZCn9P0Ao/T9YKf0/
QCj9P/Ao/T+9b7Z+IJT+P2j8/T9kKf0/RCP8PwUAAAAsG/0/LBv9P2Qp/T8kG/0/
FAAAAFwh/T9ldmVudFRhc2sAkoWYJfoAAAAAAFgp/T8AAAAAIA0GAAgAAACVBSs9
FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAABCb/j8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBxsA=
AAAAAIs5CIAgDQYAAAAAAAAAAACgKP0/AAAAAAAAAAAAAAAAhKUBACMNBQAAAAAA
/////6Ao/T8AAAAAAAAAAFAb/T8AAAAAAQAAAAAAAAAAAAAA8Cj9PwAAAAAAAAAA
BQAAAFNvbFNlbnNlAKWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlCPCfwj1ZSMiBsgEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPwo/T8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
GJT+PxCT/j8MlP4/
EJP+P6CT/j8o/hmHuCz9P2wp/T8YlP4/RCP8PwMAAABs/v0/bP79PxiU/j9k/v0/
FgAAABCI/j9ydFQAMCwkLcXthI+f+xEA////fwyU/j8AAAAAIAIGAAsAAAC/G1C5
FgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4Fpk=
AAAAAIs5CIAgAgYAAAAAAAAAAABwk/4/fHH8P9lw/D8AAAAA/aUBACMABQAAAAAA
/////3CT/j98cfw/2XD8P5D+/T8AAAAAAQAAAEiD/D8AAAAAoJP+PwAAAAAAAAAA
NHH8PwAAAAAAAAAAAAAAAIAX/D8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAACsk/4/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
sCz9P6BW/T+oV/0/
oFb9P0BX/T/J3HfSTCP8PyCU/j+wLP0/RCP8PwIAAAA8Mf0/PDH9P7As/T80Mf0/
FwAAAKw3/T9wcFQASn9rfaVdXCCOeH8AAAAAAKhX/T8AAAAAIAIGAAkAAABxYQTP
FwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADiUzk=
AAAAAIs5CIAgAgYAWEj8PwAAAAAAV/0/kHj8P1hI/D8AAAAA3qcBAKISKgZYSPw/
/////wBX/T+QePw/WEj8P2Ax/T8AAAAAAQAAABAAAAAAAAAAQFf9PwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAACUePw/GAAAAB9SCUD0dvw/
AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAATFf9PwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
cLL8P4Cx/D9ksvw/
gLH8PwCy/D9zNUEcaPz9P0wj/D9wsvw/RCP8PwEAAAD4rPw/+Kz8P3Cy/D/wrPw/
GAAAACit/D9pcGMwAPMlMKPOvdU42gIAAAAAAGSy/D8AAAAAIAAGAAEAAAA79kJO
GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIf8P4CH/D/oh/w/
AAAAAAAAAAABAAAAAAAAALCeQD8AAAAASB0AQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAshss=
AAAAAIs5CIAgAAYAAAAAAAAAAADgsfw/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
/////wAAAAAAAAAAAAAAAByt/D8AAAAAAQAAAAAAAAAAAAAAALL8PwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAPoKCIAAPP4/NCP8P+wl/D8AAAAAAAAAAAyy/D8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

I just noticed ... it looks like you are using a custom build of the toolchain.  I have been using the distributed binaries of the tool chain found here ...http://esp-idf.readthedocs.io/en/latest/linux-setup.html#step-1-download-binary-toolchain-for-the-esp32
It may be that there are features of the coredump technology that are specific to this downloadable version of the code ... or maybe specific compilation flags or feature flags were enabled.

New toolchain seems to have cleared up my initial issue so I am not sure if this worked. So cheers once again Neil!
I will close when I test the coredump.
How did you tell that I was using an old toolchain? I am pretty sure I downloaded this precompiled from a link on the github readme.
@espressif folks, is there a change I can watch for in the IDF when a new toolchain comes out?

after updating the toolchain I am seeing the same issue.

@forthlightning, It seems to be the same issue as described here https://github.com/espressif/esp-idf/issues/321.
Please, see my explanation and workaround (using 'dbg_corefile' command of core dump script) in that topic.
Let me know if you have further problems.

Ah it looks like that opens up fine. Thanks! Now to learn how to gdb...

Hi forthlightning, is this problem solved? Can we close this issue?

yup, this looks to be all squared away!


Consulting about QEMU VM login & user-defined VM image

Description of problem
Dear kata owners:
Our team is evaluating the use of VM under k8s between kubevirt and kata.  As I known, kata is designed as an oci-runtime and the virtual machine is insensitive to the user.
We recompiled the VM kernel in order to edit required kernel parameters in privileged pod possible,  the ideal scenario is running a kata pod to keep VM lifecycle(let the kata-agent run a permanent lightweight process) and remake a VM image to auto-start sshd. After the user login, they treat it as a normal VM.
I know this is strange, but Is this feasible? Many thanks!

We recompiled the VM kernel in order to edit required kernel parameters in privileged pod possible,

Hi @clarklee92 - I'm afraid I don't understand why you needed to recompile the kernel? Which kernel config options were missing?
You are of course permitted to create your own VM images if you wish, so I'm not entirely sure what you are asking for?

@jodh-intel .Thanks for quick reply. Yes there are some kernel features not exist with default kernel.
VM images must be made specially in kata, so I wonder if the changes lead to potential abnormal condition. (cause I didn‘t find any doc to create custom images).

Hi @clarklee92 - tools to create images (and kernels) live over at https://github.com/kata-containers/osbuilder
There is a guide on how to add a console to the rootfs, which might be a useful reference as it is sort of similar to you adding an SSH daemon: https://github.com/kata-containers/documentation/blob/master/Developer-Guide.md#create-a-custom-image-containing-a-shell
And, if you want to see what the minimum kernel configs are for a Kata kernel (depending on what features you will use etc.), then there is a pending PR that tries to break the kernel config file down to make it easier to both identify what is needed and then add/remove features as necessary:
https://github.com/kata-containers/packaging/pull/314
I think what you are trying to achieve is potentially do-able, but it is a little outside of Kata's normal use case :-)

@grahamwhaley @jodh-intel Thank you very much! I'm sorry that I didn't do enough research on my own. I will try that in coming days.
We (Baidu cloud container team) have been using kata on our products since 1.4 and seen kata growing excellent. I like it and want to use it in edge computing now(hope the POC works well) :-)

@clarklee92 - not a problem - it's a balancing act - sometimes it will be more efficient for us to point you at the right documents than for you to dig around forever. If you get stuck, do ask!

@clarklee92 might be this change https://github.com/kata-containers/agent/pull/547 will do the things easier for you.

@clarklee92 might be this change kata-containers/agent#547 will do the things easier for you.

Good job! Especially helpful for us, thank you!


Planning for 1.0-RC3 release?

It's been over a month since the last release, what's the plan for 1.0-RC3?

cc: @opencontainers/runtime-spec-maintainers

The big blocker is currently #513. And that's blocked on opencontainers/runc#1018, among other things.

Thanks @cyphar, just was curious why I didn't see a 1.0-RC3 milestone here:
https://github.com/opencontainers/runtime-spec/milestones

https://github.com/opencontainers/runtime-spec/milestone/12 there. But how to cross-link to the runc issue?

On Mon, Oct 24, 2016 at 08:31:07AM -0700, Vincent Batts wrote:

https://github.com/opencontainers/runtime-spec/milestone/12 there. But how to cross-link to the runc issue?

Move #513 into the -rc3 milestone and rely on maintainers to remember that it's tied up with opencontainers/runc#1018?

This is being voted upon now and looks like it will pass.
https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/vm9laWGriwE


add default case for object detection to pass through models that have already been wrapped correctly

Currently object detection models that have been wrapped are always getting re-wrapped as a WrappedObjectDetectionModel.  However, this can cause issues for users that have already written their own custom wrapper, as is the case for one of our customers.  In the image model wrapper, we simply return the existing model if we detect that it has already been wrapped, similar to other text and tabular wrappers as well as vision wrappers for other tasks.

Codecov Report

Merging #150 (515913d) into main (d8ba902) will decrease coverage by 40.53%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##             main     #150       +/-   ##
===========================================
- Coverage   75.11%   34.58%   -40.53%
===========================================
  Files          27       27
  Lines        1812     1813        +1
===========================================
- Hits         1361      627      -734
- Misses        451     1186      +735

Flag
Coverage Δ

unittests
34.58% <0.00%> (-40.53%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed
Coverage Δ

python/ml_wrappers/model/image_model_wrapper.py
26.24% <0.00%> (-68.43%)
:arrow_down:

... and 17 files with indirect coverage changes


A script to collect fybrik information using kubectl [new branch]

This PR continues PR #2017, but from a new branch, since the previous one didn't use git commands correctly when merging new commits from master.
Closes #568

@Vicky-Goldin, if you see that support MacOS is too complicated, please just add in the start check OS and in the case of MacOS print a message that it is not supported.
I don't want to spend too much time for the script, it is just a tool for your main task.
Something like:
if [[ "$OSTYPE" != "linux*" ]]; then
  echo "OS '$OSTYPE' is not supported. Aborting." >&2
  exit 1
fi


Add prevState to onLeave hooks

Fixes #3612
Make sure this lands in react-router@next too.

:shipit:
Do you want to update the docs or shall I?

Oh yeah, one sec...

Published on v2.6.0


How to use or-tools and the latest protobuf in the same project?

It seems that the or-tools integrates protobuf 3.2 whose latest version is 3.4.
The GOOGLE_PROTOBUF_VERSION and GOOGLE_PROTOBUF_MIN_PROTOC_VERSION checks are quite strict that both of them require the library and the generated code to be exactly the same version.
Is it possible to use or-tools and the latest protobuf in the same project?

Which language/platform?
python, nuget?
Laurent Perron | Operations Research |<EMAIL_ADDRESS>| (33) 1 42 68 53
00
2017-10-26 13:33 GMT+00:00 Kirk<EMAIL_ADDRESS>
It seems that the or-tools integrates protobuf 3.2 whose latest version is
3.4.
The GOOGLE_PROTOBUF_VERSION and GOOGLE_PROTOBUF_MIN_PROTOC_VERSION checks
are quite strict that both of them require the library and the generated
code to be exactly the same version.
Is it possible to use or-tools and the latest protobuf in the same project?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/or-tools/issues/514, or mute the thread
https://github.com/notifications/unsubscribe-auth/AKj17Q_4zWekCA4jZ-FXyXFfQ8mj8Qujks5swIo6gaJpZM4QHk9j
.

Sorry for that.
I thought the version check on library and the generated code should be consistent in every language/platform so I forgot to mention it.
I was using or-tools 6.5 x64 and protobuf 3.4.1 x64 via C++ interface in Visual Studio 2015 on Windows 10.
There is already a stand-alone protobuf in the project, and I just found out that I could utilize some algorithms in the or-tools. But putting them together and adding them to the include directories lead to compilation errors.
The directory organization looks like:
lib/
  protobuf/
    bin/
    include/
    lib/
  ortools/
    bin/
    include/
    lib/

I see two solutions:

hack the delivered lib to remove the protobuf obj files.
build from source specifying an alternate WINDOWS_PROTOBUF_DIR in
Makefile.local.

The second option may be hacky too as I link with static versions of the
protobuf lib.
I will update the protobuf tag in dependency files for the next release.
Thanks
Laurent Perron | Operations Research |<EMAIL_ADDRESS>| (33) 1 42 68 53
00
2017-10-27 1:09 GMT+00:00 Kirk<EMAIL_ADDRESS>
Sorry for that.
I thought the version check on library and the generated code should be
consistent in every language/platform so I forgot to mention it.
I was using or-tools 6.5 x64 and protobuf 3.4.1 x64 via C++ interface in
Visual Studio 2015 on Windows 10.
There is already a stand-alone protobuf in the project, and I just found
out that I could utilize some algorithms in the or-tools. But putting them
together and adding them to the include directories lead to compilation
errors.
The directory organization looks like:
lib/
protobuf/
bin/
include/
lib/
ortools/
bin/
include/
lib/
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/or-tools/issues/514#issuecomment-339843990,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKj17SlV8bh1mz23N9gwg71HrraDlYpnks5swS05gaJpZM4QHk9j
.

That will be great. Thanks!

Fixed. We use the latest version of protobuf.


ISSUE-167 Add an option to ignore invalid messages while sending messages to a topic in KafkaAvroSerDesApp

This PR closes #167

@michaelandrepearce addressed your comment.

+1


Fix readme gifs and description

The gif alignment is broken.
The wordings in readme are incorrect.
Categorise the readme.

Fixed by #713


[Feature] Favicon and title

Description:
Need to change the website title to Crypto Rankings and add favicon which represents the crypto/ money (coin image)
Please assign this to my name, will work on it.
Please add hacktoberfest label to keep track of my contributions

Hey, I would like to work. Please assign me this task!!

@priyanshu6781 sorry but @jsvigneshkanna is already working on this issue


Clean up the cards classes and styles

@jesseyuen – could you please review this code
Tidied up the code, using naming conventions related to eyfs and cleaned the duplication of code. Still can't figure out how to get the underline to disappear on focus, we can look into it next time.


Refactor selector peeking

Closes #948
Introduced changes

Checklist

[x] Linked relevant issue
[x] Updated relevant documentation
[x] Added relevant tests
[x] Performed self-review of the code
[x] Added changes to CHANGELOG.md

@MaksymilianDemitraszek can you review before merging this?

Would be nice if you included a sentence in the PR description, briefly describing the taken approach.

Dead code: https://github.com/foundry-rs/starknet-foundry/blob/987b1aaa2d4da99624871405e0652c38871cf4c3/crates/cheatnet/src/execution/deprecated/syscalls.rs#L180

Closing in favor of Extended Runtime refactor


Object reference not set to an instance of an object in for of

In the JS file type
for (var 1 of [1..2]) {<PRESS ENTER>
The popup 'Object reference not set to an instance of an object.' appear

Actually just needed for (var 1<PRESS ENTER> for this error to appear

Thanks - potentially related to #684

This seems to be fixed in NTVS 1.2 Alpha, probably by #743. I tried both Full Intellisense and ES6 Preview intellisense and could not repo this behavior.


Issues creating new files/directories from the file tree

If a given filename ends with /, it should create a directory instead (I know there is a separate keymap but this is what my muscle memory does)
Additionally, given a path like path/with/subdirs/file.txt, it should create any necessary directories automatically.

Sounds easy enough, we can just check if the ultimate char in the filename to the 'touch' function is '/' and, perform maybe a vim.fn.fnamemodify to just get the basename and then redirect it to the 'mkdir' function.
Just spit balling.

Throwing together a PR for this.


Naming of cityGMLBase.xsd

Is there a reason, why the XSD file of the Core module has been named cityGMLBase.xsd in CityGML 2.0?
I would find it more intuitive to name the file core.xsd in CityGML 3.0. Also all other XSDs are named according to the module name.

In the web meeting on 8 July we discussed that it would be fine to rename the xsd cityGMLBase.xsd to core.xsd.
In addition, we also discussed that it will be useful to provide a profile schema file that imports all CityGML modules. This profile file already exists for CityGML 2.0 (http://schemas.opengis.net/citygml/profiles/base/2.0/CityGML.xsd) and should also be provided for CityGML 3.0.

Both, renaming of cityGMLBase.xsd to core.xsd and providing a profile file (name: CityGML.xsd) was applied in commit b35e09d80cb4be2c24698c1440ebdbd8edba1538

Issue will be closed, renaming has been done long time ago.


Add boolean variables to enable/disable CSS components

Hi,
When developing with Bootstrap it would be nice if it was possible to turn on/off components in the variables.scss file to keep file sizes down.
Maybe something like this:
$components: (
  alert: true,
  breadcrumb: true,
  ...
) !default;

... and something like this in each component:
@if map-get($components, alert) == true {
  .alert {
    ...
  }
}

+1

This was discussed internally in https://github.com/twbs/derpstrap/pull/127.
The suggestion there was for folks to write their own SCSS file that @imports only the specific Bootstrap components that they want (in other words, write your own https://github.com/twbs/bootstrap/blob/v4-dev/scss/bootstrap.scss).

@cvrebert – Yes, this is what I've been doing up until now, but when including UI components in different projects a variable overwrite would be better than having multiple files with @import in them.

@asnoba You can as well use uncss to remove the unused CSS at a later stage.

Thanks for the tip @simonewebdesign :)

My main reason for it is that it seems to just be a re-implementation of existing CSS core functionality—you import files to use them. Adding variables to also do that seems over-engineered to me.


Remove obsolete invertedIndexConfig.cleanupIntervalSeconds

What's being changed:

Remove the unused invertedIndexConfig.cleanupIntervalSeconds
The prop is not removed from the swagger-generated models.InvertedIndexConfig type. This way Weaviate will not error if a user still provides that property (e.g. because they have a schema created with a previous version). However, Weaviate will no longer parse or set this prop as a default
The above is not to be confused with vectorIndexConfig.cleanupIntervalSeconds which is used to control how often the HNSW cleanup logic runs. This property is not affected by this PR.

Review checklist

[ ] Documentation has been updated, if necessary. Link to changed documentation:
[ ] Chaos pipeline run or not necessary. Link to pipeline:
[ ] All new code is covered by tests where it is reasonable.
[ ] Performance tests have been run or not necessary.

Link to the documentation update


checknotnull locations and new arraylist merge

in BlockInfo，
mLocations = new ArrayList<>(Preconditions.checkNotNull(locations));

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/14398/
Test PASSed.


updated version of the NDK

r? @edunham
I think this gets overridden by the env variables set by the buildbot master.cfg, but it was bugging me to have these incorrect.

This change is

Heads up - sorry about the delay, but I'm almost ready to put in the PR I mentioned about updating Android in #239. Two things:

I'm pretty sure that the bash_profile file is only used to set these environment variables for interactive usage, not buildbot. Does anybody use these? If not, I'd be ok with getting rid of this file.
The changes in my PR will make this PR redundant, so let's hold off on merging this one.

@aneeshusa That's awesome! I didn't want to bug you about the PR, as I assumed you were busy :-) This will be a huge help. @edunham and I have a fairly comprehensive idea about everything that's currently broken in the Android rules, from bloody experience.
I'll just close this in favor of your work.
Also, you're correct that we shouldn't need the bash_profile anymore.

If we don't need the bash_profile, I'll go ahead and get rid of it in the other PR.

Also, feel free to poke me about stuff like that - I did have a busy week but I've got free time this week.
If there's anything else broken with the Android rules that isn't covered by my PR, please open some issues or let me know!


Crash when I have my daily income

Describe the bug
Sometimes when the daily income start, the game crash and when I reload the save, it's always at the same ingame day.
Mod Version

Standard
Numeric Version: <IP_ADDRESS>-1

Evidence

[ ] The mod is present in the callstack;

Crash Report
https://report.butr.link/3AC7D8.html

Same report here .Did You find how to fix it?


Remove everything related to Application

The request and everything related to obtain application info is only used by Lock
Remove everything Application, Connection, Strategy, Strategies, ApplicationInfoRequest, etc
Remove tests
The functionality will be added to Lock.Android v2

@hzalaz We'll need something to start a generic request (like the application info request), IDK if this could be added to AuthenticationAPIClient? The one I removed was in RequestFactory

@nikolaseu not really since it's a simple get using an url and parsing a JSON response. It's just a couple lines of code


Preserve backward compatibility on imports

What is the expected enhancement?
Several paths have been changed as files have moved around, so we should preserve backward compatibility with a deprecation warning.
Examples (need to check against 0.7 for a full list):

qiskit.tools.compiler.execute
qiskit.tools.compiler.compile
qiskit._util ---> qiskit.util (a lot of underscores are removed)

It would be good to verify current master against the existing qiskit-tutorials and the example scripts in terra along with any other scripts people use or have locally that use terra for 0.7. We should find all the places where we're potentially breaking existing users before we release. My basic workflow for running qiskit-tutorials with terra master is:
#!/bin/bash

python3 -m pip install -U virtualenv
virtualenv master-test
source master-test/bin/activate
pip install -U Cython
pip install -e 'git+https://github.com/Qiskit/qiskit-terra.git'
pip install -U jupyter matplotlib nxpd ipywidgets pydot
pip install -U qiskit-ibmq-provider qiskit-ignis
pip install -U qiskit-aer
git clone https://github.com/Qiskit/qiskit-tutorials.git
pushd qiskit-tutorials
BROWSER='' jupyter notebook
popd

That should launch the tutorials repo in your default browser running terra from master.

I also just pushed up the WIP patch for the 0.8 release notes: https://github.com/Qiskit/qiskit/pull/211 any backwards incompatibility we find as part of this (and we don't fix prior to release) we should make sure to add to that

based on feedback received about running prior notebooks, we seem to be ok here. The biggest change is just qiskit.compile --> qiskit.compiler.transpile and qiskit.compiler.assemble


in filename completion, ignore last '/' character when sort filenames

completion candidates should maintain meta data

if completion results contains directory names, ignore last /

completion candidates may contains arbitrary names, as as result, hard to ignore last /
(for example, dir vs dir/ compare)


CVE-2023-6246 vulnerability with latest docker image.

Prerequisites

[X] I am using the latest version of Locust
[X] I am reporting a bug, not asking a question

Description
CVE-2023-6246 vulnerability (High Severity) exists with latest docker image. Vulnerability on glibc package.
Description
A heap-based buffer overflow was found in the __vsyslog_internal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when the openlog function was not called, or called with the ident argument set to NULL, and the program name (the basename of argv[0]) is bigger than 1024 bytes, resulting in an application crash or local privilege escalation. This issue affects glibc 2.36 and newer.
Command line
locust -f mylocustfile.py -t 10s --headless
Locustfile contents
import time
from locust import HttpUser, task, between

class QuickstartUser(HttpUser):
    wait_time = between(1, 5)

    @task
    def hello_world(self):
        self.client.get("/hello")
        self.client.get("/world")

    @task(3)
    def view_items(self):
        for item_id in range(10):
            self.client.get(f"/item?id={item_id}", name="/item")
            time.sleep(1)

    def on_start(self):
        self.client.post("/login", json={"username":"foo", "password":"bar"})

Python version
python3
Locust version
latest
Operating system
locust docker image.

Please provide some details on how this could impact locust? If it requires shell access it probably isnt very relevant.

A heap-based buffer overflow was found in the __vsyslog_internal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when the openlog function was not called, or called with the ident argument set to NULL, and the program name (the basename of argv[0]) is bigger than 1024 bytes, resulting in an application crash or local privilege escalation. This issue affects glibc 2.36 and newer.
The locust image is not for running general purpose code, so being able to achieve local privilege escalation by running specific code is not really relevant. Once an updated glibc is available in the parent image (python:3.11-slim), we'll get it automatically.


Using retrofit2 and recycler view

A PR changing the async task with retrofit (with GSON adapter and parsing). Retrofit with callback isn't perfect (but can be cancellable) and there is still an orientation problem (eventbus, retain instance or RxJava will be of help there).
And showing the results in a recycler view.

Hey  @nhpatt, we are using model classes from https://github.com/craftsmanship-toledo/katangapp-api proyect. Could you use them to avoid duplicating classes?
Thanks!

For the retrofit change, this blogpost will add clarity over it: https://androidtutorialmagic.wordpress.com/android-asynctask-and-its-dark-side/retrofit-networking-in-android-tutorial-replacement-of-asynctask-and-volley/

Yes, I should write down my problems with Android Async Tasks somewhere (maybe writing a post) but there are several posts about the problems Async Tasks have, like this link.
But my main gripes are:

They are not easily cancelable (cancel() does not work as you think)
If you embed them in an activity is really easy to have memory leaks, if you implement them in their own class you have to deal with the burden of passing the context (and memory leaks too)
They are very coupled with the activity! retrofit just needs a callback and you can pass it around layers. If you extract the async task to another class (and you should) you either have to pass the activity and couple all your code :S :S or create a new callback.
Orientation problems. Retrofit also has this problem but a little bit diminished, when you rotate the activity in an async task usually you have code in the post execute manipulating a now-defunt activity (crash!)
Very verbose API that does not help implementing background calls at all
You cannot concatenate, combine... several calls or you would get a huge mess.

Also you are using Apache HTTP that is deprecated in new versions (because other set of problems), the recommended http library is OkHttp (retrofit is already using it).
Retrofit helps with:

Either you use it synchronously or async but it is not aware of the activity by default
It's really easy to set up a REST call

But it doesn't help with the orientation problem. For that the next pull should integrate an event bus, a fragment with retain, RxJava or loaders (that were created specifically because the async tasks problems)...
We can talk about android architecture or this problems in depth by hangout or slack (I have a channel to answer doubs) :)

This PR will work 'as is' if the 'Serializable PR' is merged, it's already updated to use the existing classes instead of GSON annotated ones. It will only need to update the version number, I think.

Updated API version :)

and rebased :P

Closing, sent here for review: https://github.com/nhpatt/katangapp-android/pull/1


edit step content in ide

following properties are allowed to display/edit:

human, write
url, readonly
path, write
csspath, write
custompath, write
uuid, readonly
stepUuid, readonly
value, write


mbp392-411

this pr resolves the following issues:

ODF application out of sync in argocd dashboard
grafana deployment inconsistency
database deployment inconsistency

I will create a separate PR for the inclusion of PR-191 common update.

Seems sane, but common/ is not the latest (i.e. no /values-ocpver-clustergroup.yaml support)? Also don't you want to merge to main first and then push down to the sable-4.11-v2.3 branch?


Check for updates at startup

This is a large change that adds a simple periodic update check. It defaults to disabled (so the app doesn't require internet access).
The app will remember the last time it checked for updates, and also the last version it knows about. There is unusual behavior with this; If the app is closed while there is an update notification and the app is not updated, the persistence will cause the app to not show an update until another version is released. I might want to change this so the last known version is only persisted when the update notification is dismissed. But I also like that dismissal currently doesn't remove the notification from the GUI.

[ ] Tests
[x] Decide on persistence/dismissal behavior

The persistence was updated to save the release notes and update URL so that update notifications can be provided at startup without hitting GitHub's API. This fixes the unusual behavior described above.
I also replaced the async http-client crate with the threaded ureq crate to simplify the dependency tree (removing 140 small crates).


Add extension ip.test.ext to Au Test, with Test method to allocate extra TCP ports.

And change the chunked_encoding_h2 Au test to use this capability.
This PR is dependent on https://github.com/apache/trafficserver/pull/6268

[approve ci autest]

[approve ci autest]

[approve ci autest]

[approve ci autest]

@dragon512 would be good if you could review this.

[approve ci autest]

Needed in 9.0.x for the chunked_encoding test that got updated.

Cherry picked into the 9.0.x branch for the 9.0.0 release.


[Bug] Unable to save 0 in postgresql

Environment:
go version go1.17.1 windows/amd64
bun v1.0.7
PostgreSQL 13.4, compiled by Visual C++ build 1914, 64-bit
Example code:
func main() {
	db := bun.NewDB(....)
	result, err := db.NewInsert().Model(&Temp{ID: 0}).Exec(context.Background())
	if err != nil {
		panic(err)
	}
	fmt.Println(result)
}

type Temp struct {
	ID int64 `bun:",allowzero"`
}

SQL schema:
CREATE TABLE IF NOT EXISTS public.temps
(
    id bigint NOT NULL,
    CONSTRAINT temp_pkey PRIMARY KEY (id)
)

TABLESPACE pg_default;

ALTER TABLE public.temps
    OWNER to postgres;

Expected result:
Record successfully inserted.
Actual result:
panic: ERROR #23502 null value in column "id" of relation "temps" violates not-null constraint

By adding hook, the generated sql query is
INSERT INTO "temps" ("id") VALUES (DEFAULT) RETURNING "id"

Temporary solution:

Change this line from

result, err := db.NewInsert().Model(&Temp{ID: 0}).Exec(context.Background())

to
result, err := db.NewInsert().Model(&Temp{ID: 0}).Value("id", "?", 0).Exec(context.Background())

or
2. Change SQL schema to
CREATE TABLE IF NOT EXISTS public.temps
(
    id bigint NOT NULL DEFAULT 0,
    CONSTRAINT temp_pkey PRIMARY KEY (id)
)

Also in Select/Delete queries, the 0 in struct passed to Model() is transformed to null. I assume there is some problem in Model().

I think BUN tries not to generate primary keys by itself. Usually primary keys are autogenerated by DBMS. In your case, you are manually inserting primary which is pretty rare. I think your workaround is fine.


Bugfix/multiroot cleanup

Requires:
pype-setup https://github.com/pypeclub/pype-setup/pull/24
avalon-core https://github.com/pypeclub/avalon-core/pull/127
avalon-launcher https://github.com/pypeclub/avalon-launcher/pull/18
Issue:
Environment variable AVALON_PROJECTS was kept at few places after multiroot PR merged.
This PR tries to solve most of issues connected with that:

Root environments are also set on pype.install()
removed AVALON_PROJECTS from session schema
- Avalon-launcher can't be used now, requires to set one root which can't be changed after launch this requires more than 30 minutes of time - will create issue
removed one unused plugin
Check of root existence was removed from ftrack action DeleteOldVersion (should be reimplemented in different way)
Nuke and NukeStudio should work now - requires testing @jezscha please test both
Tried to fix validator for Ass relative paths - requires testing @antirotor please test

EDITED:
avalon-launcher  can be used again

I've fixed arnold standin validator for multiplform use - it needs paths as environment variables. So now it's checking and fixing paths to format like:
[PYPE_ROOT_WORK]:[PYPE_ROOT_PUBISH]:/whatever/path/user/has/set

I've fixed arnold standin validator for multiplform use

Aah so there are all root paths and it should work for all platforms the same. Cool

but this is still no ideal solution. See #147


Adding thumb color customisation functionality to CupertinoSlider

Description
Allowing the user to change the thumb color on the CupertinoSlider by passing it as a parameter.
void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return CupertinoApp(
      home: CupertinoSlider(
        thumbColor: CupertinoColors.activeGreen,
        onChanged: (double value) {},
        value: 0,
      ),
    );
  }
}

At first I was considering adding the thumbColor to the CupertinoTheme, but didn't know if it was the right place to put it, so I just defaulted to white (the current only possible color).
Related Issues
Fixes #42088
Tests
I added the following tests:
Creating a CupertinoSlider with a specific thumb color and verifying that the color was actually set.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
[x] No, this is not a breaking change.

Hi @xster, could you take a look on this PR? I read on the Tree hygiene guidelines I was supposed to request you to review changes to Cupertino widgets.


Changed go doc url to new url

Changed instances Go Doc URL from https://godoc.org/ to https://pkg.go.dev/ as requested in the issue #31318
Is this the expected result?
Any feedback and suggestions/criticism are very much welcome/appreciated.

@inductor was this what u meant? This PR consists of only english docs updated

@RayAsh37 You did not create the issue before creating a PR so I believe my PR shall be merged unless you have any objection.


dhclient times out on FreeBSD 14-CURRENT

When I start it with sudo wifibox start it goes until dhclient times out saying DHCPDISCOVER on bridge-wifibox to <IP_ADDRESS> port 67 interval 5.
Config:
> cat /usr/local/etc/wifibox/bhyve.conf

# These are the default values for launching the bhyve(8) guest.  Please
# modify the `passthru` value to match with the slot/bus/function of the
# wireless PCI device, which can be obtained from the output of the
# pciconf(8) tool.

cpus=1
memory=128M
passthru=0/20/3

> cat /usr/local/etc/wifibox/interfaces.conf

# This is an iface stanza for interfaces(5) with relatively sane
# defaults.  Consult http://manpages.org/etc-network-interfaces/5 for
# more.  The purpose is to bring up an interface which would be the
# default gateway.

iface eth0 inet static
  address <IP_ADDRESS>
  netmask <IP_ADDRESS>

> cat /usr/local/etc/wifibox/udhcpd.conf

# This is configuration file for udhcpd(8) with relatively sane
# defaults.  Consult https://udhcp.busybox.net/udhcpd.conf for more.
# The interface should match with the one defined in the
# interfaces.conf file: router is the address and subnet is the
# netmask.

start		<IP_ADDRESS>
end		<IP_ADDRESS>
max_leases	64
interface	eth0
opt	router	<IP_ADDRESS>
opt	subnet	<IP_ADDRESS>
opt	dns	<IP_ADDRESS>
opt	lease	864000

Versions:
> wifibox version

wifibox version 0.2.1
Disk image checksum:<PHONE_NUMBER>58d3d7ac2fd8fe2da73fa3b714828074eb6be57c44674bc3aa9924

> uname -a

FreeBSD FreeBSDY540 14.0-CURRENT FreeBSD 14.0-CURRENT #7 main-n248372-add201e0a9a: Thu Jul 29 18:50:49 EDT 2021     root@FreeBSDY540:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64

Everything looks okay.  Could you please check the contents of the /var/run/wifibox/appliance/log/messages file for potential (udhcpd) errors?  Also, check /var/run/wifibox/appliance/log/dmesg for messages from the Linux kernel -- maybe there is no driver installed for the wireless card on the guest.  Please post the output of the pciconf -lv command.

I think I have found the problem and created a fix for that, please test it in version 0.3.1.

That fixed dhclient, so I have an ip, but any connections out side of the router either can't resolve the name, cause dns isn't working, or says Destination Net Unreachable when ping'd.
/var/run/wifibox/appliance/log/messages:
Aug  8 03:11:03 wifibox syslog.info syslogd started: BusyBox v1.33.1
Aug  8 03:11:03 wifibox daemon.err /etc/init.d/wpa_supplicant[1779]: Could not find a wireless interface
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1783]: Supervisor command line: supervise-daemon wpa_supplicant --start /sbin/wpa_supplicant -- -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1786]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: /sbin/wpa_supplicant, pid 1786, exited with return code 255
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1801]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: /sbin/wpa_supplicant, pid 1801, exited with return code 255
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1804]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: /sbin/wpa_supplicant, pid 1804, exited with return code 255
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1807]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: /sbin/wpa_supplicant, pid 1807, exited with return code 255
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1809]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: /sbin/wpa_supplicant, pid 1809, exited with return code 255
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1811]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: /sbin/wpa_supplicant, pid 1811, exited with return code 255
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1813]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: /sbin/wpa_supplicant, pid 1813, exited with return code 255
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1815]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: /sbin/wpa_supplicant, pid 1815, exited with return code 255
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1817]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: /sbin/wpa_supplicant, pid 1817, exited with return code 255
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1818]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: /sbin/wpa_supplicant, pid 1818, exited with return code 255
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1819]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: /sbin/wpa_supplicant, pid 1819, exited with return code 255
Aug  8 03:11:03 wifibox daemon.warn supervise-daemon[1784]: respawned "/sbin/wpa_supplicant" too many times, exiting
Aug  8 03:11:03 wifibox daemon.info init: starting pid 1946, tty '': '/sbin/openrc default'
Aug  8 03:11:03 wifibox daemon.err /etc/init.d/wpa_supplicant[1965]: Could not find a wireless interface
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1969]: Supervisor command line: supervise-daemon wpa_supplicant --start /sbin/wpa_supplicant -- -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.info supervise-daemon[1972]: Child command line: /sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
Aug  8 03:11:03 wifibox daemon.info chronyd[2074]: chronyd version 4.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
Aug  8 03:11:08 wifibox daemon.warn chronyd[2074]: Could not resolve address of initstepslew server pool.ntp.org
Aug  8 03:11:08 wifibox cron.info crond[2110]: crond (busybox 1.33.1) started, log level 8
Aug  8 03:11:08 wifibox daemon.info init: starting pid 2144, tty '/dev/tty1': '/sbin/getty 38400 tty1'
Aug  8 03:11:08 wifibox daemon.info init: starting pid 2145, tty '/dev/tty2': '/sbin/getty 38400 tty2'
Aug  8 03:11:08 wifibox daemon.info init: starting pid 2149, tty '/dev/tty3': '/sbin/getty 38400 tty3'
Aug  8 03:11:08 wifibox daemon.info init: starting pid 2152, tty '/dev/tty4': '/sbin/getty 38400 tty4'
Aug  8 03:11:08 wifibox daemon.info init: starting pid 2154, tty '/dev/tty5': '/sbin/getty 38400 tty5'
Aug  8 03:11:08 wifibox daemon.info init: starting pid 2155, tty '/dev/tty6': '/sbin/getty 38400 tty6'
Aug  8 03:11:08 wifibox daemon.info init: starting pid 2165, tty '/dev/ttyS0': '/sbin/getty -L 0 ttyS0 vt100'
Aug  8 03:13:51 wifibox daemon.err acpid[1996]: PWRF/00000080
Aug  8 03:13:51 wifibox daemon.info init: starting pid 2179, tty '': '/sbin/openrc shutdown'
Aug  8 03:13:51 wifibox user.debug : Will stop /usr/sbin/udhcpd
Aug  8 03:13:51 wifibox user.debug : Will stop PID 2137
Aug  8 03:13:51 wifibox user.debug : Sending signal 15 to PID 2137
Aug  8 03:13:51 wifibox user.debug : Will stop /usr/sbin/crond
Aug  8 03:13:51 wifibox user.debug : Will stop PID 2110
Aug  8 03:13:51 wifibox user.debug : Sending signal 15 to PID 2110
Aug  8 03:13:51 wifibox user.debug : Will stop PID 2074
Aug  8 03:13:51 wifibox user.debug : Sending signal 15 to PID 2074
Aug  8 03:13:51 wifibox daemon.info chronyd[2074]: chronyd exiting
Aug  8 03:13:51 wifibox daemon.err chronyd[2074]: Could not open /var/lib/chrony/chrony.drift.tmp : Permission denied
Aug  8 03:13:51 wifibox user.debug : Will stop /sbin/syslogd
Aug  8 03:13:51 wifibox user.debug : Will stop PID 1754
Aug  8 03:13:51 wifibox syslog.info syslogd exiting

The log shows that wpa_supplicant on the guest could not find the wireless card:
Aug  8 03:11:03 wifibox daemon.err /etc/init.d/wpa_supplicant[1965]: Could not find a wireless interface
You should also check the /var/run/wifibox/appliance/log/dmesg file to see why the kernel could not initialize the card.  I am inclined to think that there is no driver (firmware) installed for it.
Please post the output of the pciconf -lv command.

dmesg: https://pastebin.com/cf5kj1up
pciconf:
hostb0@pci0:0:0:0:	class=0x060000 rev=0x07 hdr=0x00 vendor=0x8086 device=0x3ec4 subvendor=0x17aa subdevice=0x3807
    vendor     = 'Intel Corporation'
    device     = '8th Gen Core Processor Host Bridge/DRAM Registers'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:1:0:	class=0x060400 rev=0x07 hdr=0x01 vendor=0x8086 device=0x1901 subvendor=0x17aa subdevice=0x3812
    vendor     = 'Intel Corporation'
    device     = '6th-10th Gen Core Processor PCIe Controller (x16)'
    class      = bridge
    subclass   = PCI-PCI
vgapci1@pci0:0:2:0:	class=0x030000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x3e9b subvendor=0x17aa subdevice=0x3ffd
    vendor     = 'Intel Corporation'
    device     = 'CoffeeLake-H GT2 [UHD Graphics 630]'
    class      = display
    subclass   = VGA
none0@pci0:0:4:0:	class=0x118000 rev=0x07 hdr=0x00 vendor=0x8086 device=0x1903 subvendor=0x17aa subdevice=0x382f
    vendor     = 'Intel Corporation'
    device     = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem'
    class      = dasp
none1@pci0:0:8:0:	class=0x088000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x1911 subvendor=0x17aa subdevice=0x3864
    vendor     = 'Intel Corporation'
    device     = 'Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model'
    class      = base peripheral
pchtherm0@pci0:0:18:0:	class=0x118000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa379 subvendor=0x17aa subdevice=0x3802
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH Thermal Controller'
    class      = dasp
xhci1@pci0:0:20:0:	class=0x0c0330 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa36d subvendor=0x17aa subdevice=0x3806
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH USB 3.1 xHCI Host Controller'
    class      = serial bus
    subclass   = USB
none2@pci0:0:20:2:	class=0x050000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa36f subvendor=0x17aa subdevice=0x3824
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH Shared SRAM'
    class      = memory
    subclass   = RAM
ppt0@pci0:0:20:3:	class=0x028000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa370 subvendor=0x8086 subdevice=0x0034
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH CNVi WiFi'
    class      = network
ig4iic0@pci0:0:21:0:	class=0x0c8000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa368 subvendor=0x17aa subdevice=0x3803
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH Serial IO I2C Controller'
    class      = serial bus
ig4iic1@pci0:0:21:1:	class=0x0c8000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa369 subvendor=0x17aa subdevice=0x3804
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH Serial IO I2C Controller'
    class      = serial bus
none3@pci0:0:22:0:	class=0x078000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa360 subvendor=0x17aa subdevice=0x3810
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH HECI Controller'
    class      = simple comms
ahci0@pci0:0:23:0:	class=0x010601 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa353 subvendor=0x17aa subdevice=0x3808
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake Mobile PCH SATA AHCI Controller'
    class      = mass storage
    subclass   = SATA
pcib2@pci0:0:29:0:	class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086 device=0xa330 subvendor=0x17aa subdevice=0x381e
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH PCI Express Root Port'
    class      = bridge
    subclass   = PCI-PCI
pcib3@pci0:0:29:5:	class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086 device=0xa335 subvendor=0x17aa subdevice=0x3823
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH PCI Express Root Port'
    class      = bridge
    subclass   = PCI-PCI
none4@pci0:0:30:0:	class=0x078000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa328 subvendor=0x17aa subdevice=0x3813
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH Serial IO UART Host Controller'
    class      = simple comms
isab0@pci0:0:31:0:	class=0x060100 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa30d subvendor=0x17aa subdevice=0x380e
    vendor     = 'Intel Corporation'
    device     = 'HM470 Chipset LPC/eSPI Controller'
    class      = bridge
    subclass   = PCI-ISA
hdac1@pci0:0:31:3:	class=0x040300 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa348 subvendor=0x17aa subdevice=0x380f
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH cAVS'
    class      = multimedia
    subclass   = HDA
ichsmb0@pci0:0:31:4:	class=0x0c0500 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa323 subvendor=0x17aa subdevice=0x3814
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH SMBus Controller'
    class      = serial bus
    subclass   = SMBus
none5@pci0:0:31:5:	class=0x0c8000 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa324 subvendor=0x17aa subdevice=0x3827
    vendor     = 'Intel Corporation'
    device     = 'Cannon Lake PCH SPI Controller'
    class      = serial bus
vgapci0@pci0:1:0:0:	class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1f11 subvendor=0x17aa subdevice=0x3ffd
    vendor     = 'NVIDIA Corporation'
    device     = 'TU106M [GeForce RTX 2060 Mobile]'
    class      = display
    subclass   = VGA
hdac0@pci0:1:0:1:	class=0x040300 rev=0xa1 hdr=0x00 vendor=0x10de device=0x10f9 subvendor=0x17aa subdevice=0x3ffd
    vendor     = 'NVIDIA Corporation'
    device     = 'TU106 High Definition Audio Controller'
    class      = multimedia
    subclass   = HDA
xhci0@pci0:1:0:2:	class=0x0c0330 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1ada subvendor=0x17aa subdevice=0x3ffd
    vendor     = 'NVIDIA Corporation'
    device     = 'TU106 USB 3.1 Host Controller'
    class      = serial bus
    subclass   = USB
none6@pci0:1:0:3:	class=0x0c8000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1adb subvendor=0x17aa subdevice=0x3ffd
    vendor     = 'NVIDIA Corporation'
    device     = 'TU106 USB Type-C UCSI Controller'
    class      = serial bus
nvme0@pci0:6:0:0:	class=0x010802 rev=0x00 hdr=0x00 vendor=0x144d device=0xa808 subvendor=0x144d subdevice=0xa801
    vendor     = 'Samsung Electronics Co Ltd'
    device     = 'NVMe SSD Controller SM981/PM981/PM983'
    class      = mass storage
    subclass   = NVM
re0@pci0:7:0:0:	class=0x020000 rev=0x15 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x17aa subdevice=0x38cd
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet

Thanks for the logs.  It looks like the VM has a driver for your card and the respective firmware can be loaded.  But wpa_supplicant(8) cannot start up for some reason.  Did you populate the wpa_supplicant.conf(5) file under /usr/local/etc/wifibox?
In the recent versions, there is also the console command that lets you enter the VM and check the status of the running processes directly.  You will need to enable the support for console in /usr/local/etc/wifibox/bhyve.conf first, though.
Once entered the VM (user: root, password: blank), you can check if the wireless interface has been created properly by calling ifconfig.  It may also happen that the wpa_supplicant.conf(5) has a syntax error.  You can verify that one by stopping the respective service and try running the application in the foreground, i.e.:
# /etc/init.d/wpa_supplicant stop
# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

I copied wpa_supplicant.conf from /etc to /usr/local/etc/wifibox, which I use with wpa_supplicant on the host. Running ifconfig in the VM I only see eth0 and lo, not wlan0.

Could the iwlwifi kernel module be loaded?  You can check it as follows:
# lsmod | fgrep iwl

For my wireless card, the last message from the iwlwifi driver talks about the base HW (MAC) address and it appears to be missing in your case.  This might be due to a bug in bhyve's PCI pass-through implementation, which may therefore render the card unusable in the setting.

Just wanted to add a note to this case, if anyone ever searches for it.
I had trouble getting the Intel AX 201 card in my new Dell Precision 7560, running 13-STABLE.
I found this thread; https://bugzilla.kernel.org/show_bug.cgi?id=212371 , and by renaming the file /lib/firmware/iwlwifi-ty-a0-gf-a0.pnvm  (mount -o rw,remount / in console first ofc), this alpine linux picked it up. I did however have to manually run udhcpc -i wlan0 to get adress afterwards. Now everything seems fine.

Hey @henkezan thanks for the hint!
I think you can simply restart the networking service to get an IP address for the wlan0 interface via DHCP (on Alpine Linux):
# rc-service networking restart

I can include this as a kind of a "fix" for the next image release.  However, let me also note that @CRKatri's original problem was about a deficiency in bhyve's PCI pass-through implementation, which has now been addressed in both 14-CURRENT and 13-STABLE (thanks to markj's excellent patches).  In order to make Intel AX cards work on older (e.g. 13.0, 12.3) releases, I would have to improve the sysutils/bhyve+ port to include the corresponding improvements.

@henkezan do you still experience the problem you reported above with the newer images?  I have checked the bug report and it talks about older Linux versions.  In the newer disk images, Linux 5.15.x is used.

@henkezan do you still experience the problem you reported above with the newer images? I have checked the bug report and it talks about older Linux versions. In the newer disk images, Linux 5.15.x is used.

Hello. Sorry for late reply. I just upgraded to 0.7.0 and everything works flawlessly. So thank you very much! Now I don't need to console in and restart network to get going.. everything just works out of the box (and no need to remove that pnvm file).
I had installed extra wireless-tools package, which I did again, but that does not produce any output any more. Strange, but thats not that important.
Also, I missed that it was a Intel AX210 I had, not a 201.
wifibox:~# dmesg | grep wifi [    1.299962] iwlwifi 0000:00:06.0: can't derive routing for PCI INT A [    1.299964] iwlwifi 0000:00:06.0: PCI INT A: not connected [    1.304667] iwlwifi 0000:00:06.0: api flags index 2 larger than supported by driver [    1.304675] iwlwifi 0000:00:06.0: TLV_FW_FSEQ_VERSION: FSEQ Version: <IP_ADDRESS> [    1.304870] iwlwifi 0000:00:06.0: loaded firmware version 66.55c64978.0 ty-a0-gf-a0-66.ucode op_mode iwlmvm [    1.373965] iwlwifi 0000:00:06.0: Detected Intel(R) Wi-Fi 6 AX210 160MHz, REV=0x420 [    1.549397] iwlwifi 0000:00:06.0: loaded PNVM version 0xd35929d8 [    1.564636] iwlwifi 0000:00:06.0: Detected RF GF, rfid=0x10d000 [    1.634403] iwlwifi 0000:00:06.0: base HW address: 84:14:4d:ff:23:50 wifibox:~#


Results window sizing issues

We have written the needed data into your clipboard because it was too large to send. Please paste.
Issue Type: Bug
one sql window, with 2 or more different sql statements
with expected results 10 or more per query
execute them

results pane/window has a scroll bar but cannot scroll to the bottom/end to see the last row in the last result set

attempting to resize results just "moves" the results and message pane not resizing them

occasionally the width of the results pane does not adjust when side bar is on the right
not sure on cause yet, but try having server/search/task on the right and visible
then executing query/queries
eventually gets to the position where the results do not fill the width of ADS
resizinng the ADS window also does not then resize the results width
when rerunning the query

Azure Data Studio version: azuredatastudio 1.6.0 (eb35dae1d1238e03f1cab3bd45e151f381b22aef, 2019-04-17T07:11:15.944Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz (8 x 2808)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
15.89GB (8.16GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions: none

Another related issue, or perhaps covered by the above, is that when resizing the results pane the bottom horizontal scrollbar can become obscured by the Messages section and no longer accessible.  We need to fix as it makes the grid very difficult to work with.
For example, in the below results grid there should be a horizontal scrollbar visible.

@nige6 I've merged a PR #5285 that fixes the first issue you mentioned, probably the second, and I don't have a repro for the third, but it possible address that too.  Please let me know if you are still having problems with the latest insiders build from master or the 1.7.0 release next week.  Thanks!


Bugfix: fix Message::parse_caption_entities

This PR aims to fix a bug in Message::parse_caption_entities caused by using the text and text entities to parse the caption entities, instead of the caption and the caption entities.

Whoops! Didn't notice that, done


[#2PlaysAMonth]: Object detect with tenserflowjs

First thing, PLEASE READ THIS: ReactPlay Code Review Checklist

Description
Object detection using AI model. Here I use TensorFlow.js library.
Fixes #952
Type of change

[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?
Locally tested.
Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

@atapas Resolved the requested changes.


Option to not expose SSH to anonymous visitors

Feature suggestion
I would like to have the ability to not expose the SSH clone URL to anonymous visitors (not signed in).
Why?
People capable of cloning via SSH must provide their public key and hence they are most likely registered members (or some member is sharing his/her account.
On the other hand, an anonymous visitor can't do anything useful with this URL.
Why not?
You might argue that you are not necessarily signed, maybe don't have your two-factor device on hand, but just want to fetch the URL to push via SSH. So it depends on custom needs and workflows.
My suggestion
Add a boolean configuration flag like SSH_EXPOSE_ANON (default true, so it's opt-out), which is checked on markup generation.
I have hardcoded this in a fork project (simply added .IsSigned to the 3 relevant templates), works like a charm. If this change is welcome, I'm willing to provide a complete PR on that.

SSH url for anonymous users are not shown also in GitHub so I think new configuration flag is not needed. Please submit PR

That's the simple solution, OK.
As I pointed out, we don't necessarily have to follow GitHub here as there might be reasons to show anyway, but I personally don't care if I need a confg flag as long as it's gone on my public site... I got both solutions ready in my repo.

Fixed by #2170


create multipart file sdktype for bytes in a multipart formdata model

fixes #165

You can try these changes at https://cadlplayground.z22.web.core.windows.net/typespec-azure/prs/166/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/typespec-azure/prs/166/


Update webpacker

Updates webpacker to resolve some security vulnerabilities induced by its dependencies. Although we updated wepbacker to version 6.0.0-pre.2, we'd like to be on an official release such as 5.4.3. Additionally, we lost LUX styling after updating.
refs #1181

Closing since we're going to do #1377 instead


Add enhancement for suspending and resuming scan schedules

This commit includes an enhancement for implementing a feature that
pauses and resumes existing ComplianceScans.

/retest

I can update to rebase to exclude e2e tests for this patch, since they're not relevant and consume resources.
https://github.com/openshift/release/pull/42834

@Vincent056 let me know if the latest revision addresses your concerns.

/hold for test

I think the proposal looks good overall, just have some concerns on where annotation should be applied.

I think I updated all references for that in the enhancement and implementation. Let me know if you see any other issues.

/unhold
/label qe-approved


yellowstone Korean whitepaper

Added Korean Yellowstone whitepaper.
Added a simple formula to make the translation easier for Koreans to understand.
Discord @drumba3s
X @exit1floor

Yellowstone Compute Model-Korean.md
Embarrassingly, I found two typos in a short period of time and fixed them.

Looks good.


Sometimes Windows installation failed

On the openstack platform, create the virtual machine using the Windows image template processed by sysprep(I used the windows 2012 data center Chinese).
sometimes cloudbase-init reboot the Windows after sethostname when setup.exe is running, although the probability of that happening is very small.
At that time the SYSTEM\Setup\Status\SysprepStatus\GeneralizationState's value is already 7, but the setup of oobe still running, this causes the Windows installation to fail to continue with the exception, and the restart remains the same.
I apologize for not keeping the log file, but please refer to the time in log file of sysprep and cloudbase-init for details.

Hello,
Can you open a bug report on https://bugs.launchpad.net/cloudbase-init and use the git review workflow to push a fix for the bug? Thank you. Let me know if you need help with using 'git review'.

@jiaweien have you tried using the registry keys in HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\ChildCompletion to achieve the same result? I think the process checking can be very brittle in case of newer Windows versions.

I'm sorry.Since I had other work to do, I didn't try to modify the registry to test it. But, when windows installation fails, I had press the shift+F10, open the terminal(I also looked at the cloudbase-init and setup logs in this way and learned that there might be some problems with the execution timing of cloudbase-init), input regedit for open the registry. modify the HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\ChildCompletion/setup.exe value to 3, and reboot the windows, can be accessed the system. The chance of this happening again is extremely low, and I've been testing it ever since, but so far I haven't had one. If I run into it again, I'll upload the screenshot. 发自我的华为手机-------- 原始邮件 --------主题：Re: [cloudbase/cloudbase-init] Sometimes Windows installation failed (#14)发件人：Adrian Vladu 收件人：cloudbase/cloudbase-init 抄送：jiaweien<PHONE_NUMBER>3@163.com,Mention @jiaweien have you tried using the registry keys in HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\ChildCompletion to achieve the same result? I think the process checking can be very brittle in case of newer Windows versions.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

I'm sorry.Since I had other work to do, I didn't try to modify the registry to test it. But, when windows installation fails, I had press the shift+F10, open the terminal(I also looked at the cloudbase-init and setup logs in this way and learned that there might be some problems with the execution timing of cloudbase-init), input regedit for open the registry. modify the HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\ChildCompletion/setup.exe value to 3, and reboot the windows, can be accessed the system. The chance of this happening again is extremely low, and I've been testing it ever since, but so far I haven't had one. If I run into it again, I'll upload the screenshot. 发自我的华为手机-------- 原始邮件 --------主题：Re: [cloudbase/cloudbase-init] Sometimes Windows installation failed (#14)发件人：Adrian Vladu 收件人：cloudbase/cloudbase-init 抄送：jiaweien<PHONE_NUMBER>3@163.com,Mention @jiaweien have you tried using the registry keys in HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\ChildCompletion to achieve the same result? I think the process checking can be very brittle in case of newer Windows versions.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

Hello    I'll do it later. Thanks for your remind. 发自我的华为手机-------- 原始邮件 --------主题：Re: [cloudbase/cloudbase-init] Sometimes Windows installation failed (#14)发件人：Adrian Vladu 收件人：cloudbase/cloudbase-init 抄送：jiaweien<PHONE_NUMBER>3@163.com,Author Hello,
Can you open a bug report on https://bugs.launchpad.net/cloudbase-init and use the git review workflow to push a fix for the bug? Thank you. Let me know if you need help with using 'git review'.
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.

Someone told me recently that he had the same problem，I haven't come up with a better solution yet except process checking. So , could you review it?

@ader1990 Someone told me recently that he had the same problem，I haven't come up with a better solution yet except process checking. So , could you review it?

@jiaweien I understand the issue here, but we need to find a more reliable way to fix this problem, as looking for processes with a hardcoded executable (like setup,exe) can bring to an infinite loop or failure if the admin installed some service that has setup.exe in the path.
If I make a patch using HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\ChildCompletion to test the issue, could you test it?

@ader1990 Okay，I'll be test it later, and tell you the result when it's over.

@ader1990 During this period, I tested Windows server 08 R2 and Windows server 2012 R2 several times(both are in chinese). I checked whether the registry value of SYSTEM\Setup\Status\SetupFinalTasks was 3 to determine whether the initialization had been completed.So far, there have been no initialization failures.But I'm not sure if I haven't tested enough or if I've fixed the problem.I also included my changes in the patches I submitted,I wonder if that's what you suggest.

@ader1990

Just now, I got this log from my test code.In this initialization, when the GeneralizationState value is 7, there are approximately 3 seconds or so after the SetupFinalTasks value is not 3. This should indicate that the initialization work  can be determined by checking the status of SetupFinalTasks.

On a Windows 10, this is what these registry keys contain:
Get-ChildItem -Path HKLM:\system\Setup\Status\

    Hive: HKEY_LOCAL_MACHINE\system\Setup\Status

Name                           Property
----                           --------
ChildCompletion                setup.exe       : 3
                               oobeldr.exe     : 3
                               SetupFinalTasks : 3
SysprepStatus                  GeneralizationState : 7
UnattendPasses                 oobeSystem : 2

I need to check if all Windows versions have these keys to make sure there is no regression when we check the child completion keys.

@jiaweien Here is a suggestion to improve the code (needs refactor or a better placement of code though). I prefer putting the ChildCompletion check just before the plugin reboot, as the current code is not affected, as from my understanding you get this error only if you run the SetHostname Plugin in the normal cloudbase-init run. The cloudbase-init installer configures the SetHostnam Plugin to run during the Sysprep specialize step (which is the recommended way). Your current code will hang forever if cloudbase-init is installed using the default installer from cloudbase.it . The reason is that during the unatted phase, the value of the subkeys from ChildCompletion are: SetupFinalTasks = 0 and setup.exe = 1.
    def wait_for_boot_completion(self):
        try:
            with winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE,
                                "SYSTEM\\Setup\\Status\\SysprepStatus", 0,
                                winreg.KEY_READ) as key:
                while True:
                    gen_state = winreg.QueryValueEx(key,
                                                    "GeneralizationState")[0]
                    if gen_state == 7:
                        break
                    time.sleep(0.1)
                    LOG.info('Waiting for sysprep completion. '
                             'GeneralizationState: %d', gen_state)

            with winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE,
                                "SYSTEM\\Setup\\Status\\ChildCompletion", 0,
                                winreg.KEY_READ) as key:
                steps = 0
                while steps < 1000:
                    setup_state = winreg.QueryValueEx(key,
                                                      "setup.exe")[0]
                    setup_final_state = winreg.QueryValueEx(key,
                                                            "SetupFinalTasks")[0]
                    if setup_state == 3 and setup_final_state == 3:
                        LOG.info('Sysprep entered desired mode for service run.')
                        break
                    if setup_state == 1 and setup_final_state == 0:
                        LOG.info('Sysprep entered desired mode for unattended run.')
                        break
                    time.sleep(0.1)
                    LOG.info('Waiting for sysprep completion. '
                             'setup_state: %(setup_state)d and setup_final_state: %(setup_final_state)d', {"setup_state": setup_state, "setup_final_state": setup_final_state})
                    steps = steps + 1
        except WindowsError as ex:
            if ex.winerror == 2:
                LOG.debug('Sysprep data not found in the registry, '
                          'skipping sysprep completion check.')
            else:
                raise ex

@ader1990 Maybe make the cloudbase-init installer configures the SetHostname Plugin to run during the Sysprep specialize step is the best choice.
The purpose of my current code is to wait until the setup process and its child processes (which contain the parsing and execution of unattention.xml) are complete before starting the cloudbase-init task.
Also, I'm not sure if the code you posted will cause the previous error. For example, in my previous screenshot, when the SYSTEM\Setup\Status\SysprepStatus\GeneralizationState is 7, there are nearly 3 seconds left for the Setup to be truly complete. If cloudbase-init executes to sethostname when setup_state == 1 and setup_final_state == 0 are set, the previous error may be thrown.

When using the cloudbase-init MSI installer, the installer has an option to sysprep the machine at the end of the installation. By default, it configures SetHostname Plugin to run during the Sysprep specialize step.
What my code does is to handle two scenarios:

when cloudbase-init runs during specialize phase, it waits for the GeneralizationState=7, setup.exe = 1 and SetupFinalTasks = 0 (as the childcompletions are not ready at that moment). The reboot is performed by specialize step thorugh the special instruction of the RunSychronousComand - WillReboot https://github.com/cloudbase/cloudbase-init-installer/blob/master/CloudbaseInitSetup/Unattend.xml#L26
when cloudbase-init runs at each boot as a service, it waits for GeneralizationState=7, setup.exe = 3 and SetupFinalTasks = 3 (as the childcompletions should be finished before performing other tasks like reboot, user scripts, etc).

I'm very sorry. I may have misunderstood you.I thought you wanted to use your code without refactoring.
My idea is to complete the hostname setting by modifying unattend.xml, adding sethostname task in unattend.xml, and configuring willreboot as request to complete the hostname update. Is that what you said about changing the sethostname process?
This way, users who want to customize unattend.xml (I used my own generated unattend.xml) will need to add the custom part to the unattend.xml in the cloudbase-init installer directory before proceeding to the last step, sysprep.
I tried it, and it worked.

Hello @jiaweien,
Did you manage to solve this issue per my suggestion from above or did you use a special unattedn.xml? Do you still need some code change in Cloudbase-Init?
Thank you,
Adrian Vladu

I'm sorry. I've been busy lately.
I just tried to modify the architecture of the way what you said the last time , in the unattend.xml file before execution cloudbase-init added a step (my test scripts, not sethostname), it is can be done before the start of the cloubase-init (I reboot the machine in my test script, I saw the completion of sysprep log than cloudbase-init start logging time sooner).
My idea is that, would be replace my script with sethostname, setting the hostname and restarting it before the other steps in cloudbase-init are executed.
However, if this is true, it may be worth noting that sethostname may require a network to retrieve the hostname from the metadata.

Hello @ader1990 ,
A lot has been going on lately, so...Sorry for the late reply
You're right, my code will be hang forever  when using the cloudbase-init MSI installer, the installer has an option to sysprep the machine at the end of the installation..

And I also tested your code, I have tested it many times and it always has completed the initialization of the virtual machine.

But I still wonder if these changes only reduce the likelihood of initialization failure, not prevent it altogether.Because if I choose to use the cloudbase-init service to initialize the server, will there still be GeneralizationState=7, setup.exe = 1 and SetupFinalTasks = 0 at some point-in-time, and then restart the server directly after sethostname plugin completes?(But that's just my suspicion, and it didn't happen during my tests).

if setup_state == 1 and setup_final_state == 0:
LOG.info('Sysprep entered desired mode for unattended run.')
break

Also, I am not sure if I can add a judgment on the existence of the "Cloudbase-init-unattend.log" file to determine whether Cloudbase-init is initiated by the service or by unattended(Because I see that when Cloudbase-init is initiated by unattended. it will log to "Cloudbase-init-unattended. log").

eg.
if GeneralizationState=7:
while steps < 1000:
if C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\cloudbase-init-unattend.log is exist:
if setup.exe = 1 and SetupFinalTasks = 0:
break
else:
if setup_state == 3 and setup_final_state == 3:
break
time.sleep(0.1)
steps = steps + 1
Do you think this is better? Or that it may not be necessary at all. I'd like to hear your thoughts.
Thank you,
jiaweien

Hello @jiaweien ,
You can have a check of the config options that are set in the unattend conf, like https://github.com/cloudbase/cloudbase-init-installer/blob/master/CloudbaseInitSetup/Actions/ConfFileActions.js#L86, but that is a brittle and might change in the future. The best course of action would still be the registry keys check, as those keys are reliable source of identifying in what stage cloudbase-init is run.  Still, checking that stop_service_on_exit is false can reliably tell that cloudbase-init is not running in normal mode, under a Windows service, but this change cannot be included in the upstream codebase, whereas the code I shared can and should be 100% reliable.
In this case, I will create a patch with those checks and would be glad if you could test the new MSI.
Thank you,
Adrian Vladu

Hello @ader1990 ,
Yes, I also noticed allow_reboot is false in cloudbase-init-unattend.conf when I was testing earlier.
In my custom virtual machine image, I manually sysprep after cloudbase-init is installed(C:\windows\system32\sysprep.exe /generalize /oobe /shutdown), instead of selecting Cloudbase-init.msi to complete sysprep and initialize it to the virtual machine image template. This will allow me to have my own custom unattend step, and also not affect the execution of Cloudbase-init as a service.
So I'm not worried about Cloudbase-init running in unattended-mode, just not known if Cloudbase-init running in service mode can completely avoid this problem？
I am looking forward to your new Cloudbase-init.msi and I will test it again then.
Thank you
jiaweien


Each button of device “xiaomi.switch.pro3” is reported as “button_1_single”.

Device Definition: https://home.miot-spec.com/spec/xiaomi.switch.pro3
2024-05-20 22:56:19.893 DEBUG (MainThread) [custom_components.xiaomi_gateway3.mqtt.<IP_ADDRESS>] {'topic': 'miio/report', 'data': b'{"id":695770722,"method":"event_occured","params":{"did":"1081544299","siid":5,"eiid":1,"tid":125,"ts":1716216979,"arguments":[]},"type":16}'}
2024-05-20 22:56:19.893 DEBUG (MainThread) [custom_components.xiaomi_gateway3.gate.<IP_ADDRESS>] {'uid': 'd4f0eaa98edb', 'did': '1081544299', 'msg': 'on_report', 'data': {'action': 'button_1_single'}}
2024-05-20 22:56:19.897 DEBUG (MainThread) [custom_components.xiaomi_gateway3.mqtt.<IP_ADDRESS>] {'topic': 'central/report', 'data': b'{"id":175814574,"_to":128,"type":16,"method":"event_occured","params":{"did":"1081544299","siid":5,"eiid":1,"tid":125,"ts":1716216979,"arguments":[]}}'}

2024-05-20 22:56:20.610 DEBUG (MainThread) [custom_components.xiaomi_gateway3.mqtt.<IP_ADDRESS>] {'topic': 'miio/report', 'data': b'{"id":524763723,"method":"event_occured","params":{"did":"1081544299","siid":6,"eiid":1,"tid":126,"ts":1716216979,"arguments":[]},"type":16}'}
2024-05-20 22:56:20.610 DEBUG (MainThread) [custom_components.xiaomi_gateway3.gate.<IP_ADDRESS>] {'uid': 'd4f0eaa98edb', 'did': '1081544299', 'msg': 'on_report', 'data': {'action': 'button_1_single'}}
2024-05-20 22:56:20.614 DEBUG (MainThread) [custom_components.xiaomi_gateway3.mqtt.<IP_ADDRESS>] {'topic': 'central/report', 'data': b'{"id":1594955576,"_to":128,"type":16,"method":"event_occured","params":{"did":"1081544299","siid":6,"eiid":1,"tid":126,"ts":1716216979,"arguments":[]}}'}

2024-05-20 22:56:21.309 DEBUG (MainThread) [custom_components.xiaomi_gateway3.mqtt.<IP_ADDRESS>] {'topic': 'central/report', 'data': b'{"id":1481788579,"_to":128,"type":16,"method":"event_occured","params":{"did":"1081544299","siid":7,"eiid":1,"tid":127,"ts":1716216980,"arguments":[]}}'}
2024-05-20 22:56:21.309 DEBUG (MainThread) [custom_components.xiaomi_gateway3.gate.<IP_ADDRESS>] {'uid': 'd4f0eaa98edb', 'did': '1081544299', 'msg': 'on_report', 'data': {'action': 'button_1_single'}}
2024-05-20 22:56:21.348 DEBUG (MainThread) [custom_components.xiaomi_gateway3.mqtt.<IP_ADDRESS>] {'topic': 'miio/report', 'data': b'{"id":2117384725,"method":"event_occured","params":{"did":"1081544299","siid":7,"eiid":1,"tid":127,"ts":1716216980,"arguments":[]},"type":16}'}

When I press the buttons of the switch in turn, each action is reported as "button_1_single".I'm sure this is an issue from the version upgrade, I'll roll back the version before the upgrade and collect logs from the old version.

from 'v4.0.5' roll back to 'v3.3.6'
2024-05-20 23:39:22.751 DEBUG (MainThread) [custom_components.xiaomi_gateway3.core.gateway] <IP_ADDRESS> [MQTT] miio/report b'{"id":708313355,"method":"event_occured","params":{"did":"1081544299","siid":5,"eiid":1,"tid":154,"ts":1716219562,"arguments":[]},"type":16}'
2024-05-20 23:39:22.755 DEBUG (MainThread) [custom_components.xiaomi_gateway3.core.gateway] <IP_ADDRESS> [MQTT] central/report b'{"id":1460299037,"_to":128,"type":16,"method":"event_occured","params":{"did":"1081544299","siid":5,"eiid":1,"tid":154,"ts":1716219562,"arguments":[]}}'
2024-05-20 23:39:22.794 DEBUG (MainThread) [custom_components.xiaomi_gateway3.core.gateway] <IP_ADDRESS> [MQTT] miio/report_ack b'{"id":708313355,"result":"ok"}'
2024-05-20 23:39:23.690 DEBUG (MainThread) [custom_components.xiaomi_gateway3.core.gateway] <IP_ADDRESS> [MQTT] miio/report b'{"id":115784356,"method":"event_occured","params":{"did":"1081544299","siid":6,"eiid":1,"tid":155,"ts":1716219563,"arguments":[]},"type":16}'
2024-05-20 23:39:23.693 DEBUG (MainThread) [custom_components.xiaomi_gateway3.core.gateway] <IP_ADDRESS> [MQTT] central/report b'{"id":2000763039,"_to":128,"type":16,"method":"event_occured","params":{"did":"1081544299","siid":6,"eiid":1,"tid":155,"ts":1716219563,"arguments":[]}}'
2024-05-20 23:39:23.734 DEBUG (MainThread) [custom_components.xiaomi_gateway3.core.gateway] <IP_ADDRESS> [MQTT] miio/report_ack b'{"id":115784356,"result":"ok"}'
2024-05-20 23:39:24.968 DEBUG (MainThread) [custom_components.xiaomi_gateway3.core.gateway] <IP_ADDRESS> [MQTT] central/report b'{"id":1579340041,"_to":128,"type":16,"method":"properties_changed","params":[{"did":"1081544299","siid":8,"piid":2,"tid":156,"value":54}]}'
2024-05-20 23:39:24.968 DEBUG (MainThread) [custom_components.xiaomi_gateway3.core.gateway] <IP_ADDRESS> [MQTT] miio/report b'{"id":1382384357,"method":"properties_changed","params":[{"did":"1081544299","siid":8,"piid":2,"tid":156,"value":54}],"type":16}'
2024-05-20 23:39:24.968 DEBUG (MainThread) [custom_components.xiaomi_gateway3.core.gateway] <IP_ADDRESS> [MQTT] miio/report_ack b'{"id":1382384357,"result":"ok"}'
2024-05-20 23:39:24.968 DEBUG (MainThread) [custom_components.xiaomi_gateway3.core.gateway] <IP_ADDRESS> [MQTT] central/report b'{"id":1099821042,"_to":128,"type":16,"method":"properties_changed","params":[{"did":"1081544299","siid":8,"piid":2,"tid":157,"value":86}]}'
2024-05-20 23:39:25.117 DEBUG (MainThread) [custom_components.xiaomi_gateway3.core.gateway] <IP_ADDRESS> [MQTT] miio/report b'{"id":1998356358,"method":"event_occured","params":{"did":"1081544299","siid":7,"eiid":1,"tid":158,"ts":1716219564,"arguments":[]},"type":16}'

https://github.com/AlexxIT/XiaomiGateway3/releases/tag/v4.0.6


SubDyn issue when rigid links are connected to interface and cable

Bug description
Loads and displacements are wrong when rigid links are connected between the interface node and nodes that have cables.
To Reproduce
Use this test case.
https://github.com/OpenFAST/r-test/main/f/SD-Loads/modules/subdyn/SD_Rigid2Interf_Cables
Expected behavior
IntfZss is 4.6e6N where a value of 2.23e7N would be expected.
OpenFAST Version
Dev version as of October 2021. Bug present ever since the rigid link feature was introduced (around OF 2.6).

The test case references above that exposes the bug is now in the main branch at https://github.com/OpenFAST/r-test/tree/main/modules/subdyn/SD_Rigid2Interf_Cables

I do believe the problem is related to defining one beam at the interface joint and, at least, one rigid link to that same interface joint. For example: If I define a rigid link that is used to connect a lumped mass to the interface joint, such a mass is somehow not taken into account. Despite SubDyn reporting the expected mass and inertia in the summary file.


NRN_ENABLE_MPI=(ON|OFF) does not automatically adjust the CORENRN_ENABLE_MPI flag

Should we propagate the NRN_ENABLE_MPI=(ON|OFF) to the coresponding option in CoreNEURON CORENRN_ENABLE_MPI =(ON|OFF) ?
Now the propagation is not happening, i.e. if NRN_ENABLE_MPI=OFF this does not force CORENRN_ENABLE_MPI to be OFF as well.

Didn’t realise this was not taken care in NEURON cmake. One liner change needs to be done here: https://github.com/neuronsimulator/nrn/blob/bcf44f673d43cc9a43458897e4b8264f265fde65/CMakeLists.txt#L415

Fixed upstream.

I agree with the change. But somewhat pedantically, it was  possible to create a CoreNEURON file transfer mode model using serial NEURON and run  with mpi parallel CoreNEURON. Nevertheless, it's nice to not require mpi be turned off explicitly on the
CoreNEURON side when it is turned off explicitly on the NEURON side.

Nevertheless, it's nice to not require mpi be turned off explicitly on the CoreNEURON side when it is turned off explicitly on the NEURON side.

Yeah exactly. And it causes confusion about what are MPI ON/OFF requirements and which libraries are linked etc etc.

I agree with the change. But somewhat pedantically, it was possible to create a CoreNEURON file transfer mode model using serial NEURON and run with mpi parallel CoreNEURON. Nevertheless, it's nice to not require mpi be turned off explicitly on the
CoreNEURON side when it is turned off explicitly on the NEURON side.

The more synergy the better. To be revisited with implementing dynamic MPI support for CoreNEURON  #600


Big typo

@paragonie-security maybe no one noticed
I've found it in WordPress 5.2

See https://github.com/paragonie/sodium_compat/blob/master/psalm.xml#L27

Tip: move from psalm to phpstan.

We use Psalm due to PHP 5.6 support, which phpstan does not offer.

@paragonie-scott Would you welcome a PR that runs PHPStan on PHP 7.3 only?

Sure!


Update stressor for super dao and combined consensus changes

Added creation of super dao
updated consultation versions to reflect the update of exclude vote
added creations combined consensus changes
fixed answer consultation creations

@chasingkirkjufell what do I need to test on this PR?

@chasingkirkjufell what do I need to test on this PR?

just run the stressor and see if it'll finish. probably best running it with the dao_upgrade PR.

approving to merge in the dao branch


DOC Add API client example notebook

This notebook demonstrates the use of all the abstractions and patterns used in the Python API client. It serves as an introduction to the Python API client for technical users of Civis Platform.

Oops. Updated the changelog.


Write sketch capabilities

May need indicator light. Will need sketch "validation" just like the python scripts, but should be a flag. Perhaps the flag disables the validation since it's so important?
Sketch is fine to store in memory; we do for hex2bin and bin2hex.

Duplicate issue