text:
How Do I upload a bootloader to a brand new ESP32-S3 chip on my newly designed and produced Board? (IDFGH-9312)

Hello Everyone,
We made our own board with ESP32-S3 (FN8 Model with 8 MB Flash internal). We see bootloop when we first turn it on. After looading bootloader.bin (and many different *.bin files) we still see bootloop problem and we get the following messages from COM port. We use Windows CMD for esptool.exe to load *.bin files.
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x40043ac8
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd0108,len:0x1634
load:0x403b6000,len:0xe74
load:0x403ba000,len:0x31c8
Checksum failure. Calculated 0x8e stored 0xde
ets_main.c 329
... (loops) ...
How can we solve this problem?
Any help is appreciated.
Thank You

Check the firmware bins size. Does the size match the partition table?
Try earse the flash before flashing.
Try change CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL.

Otherwise, try searching 'Checksum failure' on github, can get lots of help.

Thankyou Shentu.

I think, there should not be size problem. Because we have this problem even after I erase all flash.

I erased the flash:

C:\Pub\BootLoader>esptool -p COM39 --chip esp32s3 erase_flash
esptool.py v4.4
Serial port COM39
Connecting...
Chip is ESP32-S3 (revision v0.1)
Features: WiFi, BLE
Crystal is 40MHz
MAC: f4:12:fa:68:2d:98
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 0.9s
Hard resetting via RTS pin...
When I check serial port COM39:
invalid header: 0xESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x40048839
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
--------(loops)----------
When I checked Device Manager, COM39 disaappear and comes back with a sound from pc speaker continiously.

Can you help me how to change CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL?

By the way we have two flash on the board. First one is 8 MB internal flash of ESP32-S3 FN8 Model Chip. Second one is external 16 MB (W25Q128JVSIQ) beside the ESP32-S3 chip on the board. Is this may be source of problem?
Thank you very much for helping.
Senel

May I know what flash you are using? You can get this information via esptool.py flash_id

Thanks for reporting, will close due to short of feedback, feel free to reopen with more updates, thanks.

repo: espressif/esp-idf


text:
Segmentation fault while building hello_world example on MacOS with M1 chip (IDFGH-11093)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v5.0.4
Operating System used.
macOS
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
What is the expected behavior?
Project configuration window appears after idf.py menuconfig command.
What is the actual behavior?
Segmentation fault while calling idf.py menuconfig  command.
Steps to reproduce.
cd ~/esp/hello_world
idf.py set-target esp32
idf.py menuconfig
Build or installation Logs.
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               Python [28469]
Path:                  /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python
Identifier:            com.apple.python3
Version:               3.9.6 (3.9.6)
Build Info:            python3-141000000000000~696
Code Type:             ARM-64 (Native)
Parent Process:        Exited process [28468]
Responsible:           Terminal [24289]
User ID:               501

Date/Time:             2023-09-19 00:00:40.1363 +0200
OS Version:            macOS 13.5.2 (22G91)
Report Version:        12
Anonymous UUID:        B9BA0CEC-B78E-EF7E-0E04-CE914246E2B6

Sleep/Wake UUID:       0449642F-AE18-4D13-AEB8-61ED949B9C4B

Time Awake Since Boot: 19000 seconds
Time Since Wake:       10874 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes:       0x0000000000000001, 0x0000000000000000

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [28469]

VM Region Info: 0 is not in any region.  Bytes before following region: 4344053760
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->
      __TEXT                      102ed0000-102ed4000    [   16K] r-x/r-x SM=COW  .../MacOS/Python

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   ???                           	               0x0 ???
1   Python3                       	       0x1034f91d0 0x1034b0000 + 299472
2   Python3                       	       0x1035c28b0 0x1034b0000 + 1124528
3   Python3                       	       0x1035bf9cc _PyEval_EvalFrameDefault + 22664
4   Python3                       	       0x1034f0e40 0x1034b0000 + 265792
5   Python3                       	       0x1035c28b0 0x1034b0000 + 1124528
6   Python3                       	       0x1035bfa6c _PyEval_EvalFrameDefault + 22824
7   Python3                       	       0x1034f0e40 0x1034b0000 + 265792
8   Python3                       	       0x1035bfcc8 _PyEval_EvalFrameDefault + 23428
9   Python3                       	       0x1035c3664 0x1034b0000 + 1128036
10  Python3                       	       0x1034f0d88 _PyFunction_Vectorcall + 236
11  Python3                       	       0x1035c28b0 0x1034b0000 + 1124528
12  Python3                       	       0x1035bf9f0 _PyEval_EvalFrameDefault + 22700
13  Python3                       	       0x1034f0e40 0x1034b0000 + 265792
14  Python3                       	       0x1035c28b0 0x1034b0000 + 1124528
15  Python3                       	       0x1035bfa6c _PyEval_EvalFrameDefault + 22824
16  Python3                       	       0x1034f0e40 0x1034b0000 + 265792
17  Python3                       	       0x1035c28b0 0x1034b0000 + 1124528
18  Python3                       	       0x1035bfa6c _PyEval_EvalFrameDefault + 22824
19  Python3                       	       0x1035c3664 0x1034b0000 + 1128036
20  Python3                       	       0x1035ba07c PyEval_EvalCode + 80
21  Python3                       	       0x1035b69d4 0x1034b0000 + 1075668
22  Python3                       	       0x103533000 0x1034b0000 + 536576
23  Python3                       	       0x1035c28b0 0x1034b0000 + 1124528
24  Python3                       	       0x1035bfa6c _PyEval_EvalFrameDefault + 22824
25  Python3                       	       0x1035c3664 0x1034b0000 + 1128036
26  Python3                       	       0x1034f0d88 _PyFunction_Vectorcall + 236
27  Python3                       	       0x1035c28b0 0x1034b0000 + 1124528
28  Python3                       	       0x1035bfa6c _PyEval_EvalFrameDefault + 22824
29  Python3                       	       0x1035c3664 0x1034b0000 + 1128036
30  Python3                       	       0x1034f0d88 _PyFunction_Vectorcall + 236
31  Python3                       	       0x103619c28 0x1034b0000 + 1481768
32  Python3                       	       0x1036194b8 Py_RunMain + 1208
33  Python3                       	       0x103619ab4 0x1034b0000 + 1481396
34  Python3                       	       0x103619b54 Py_BytesMain + 40
35  dyld                          	       0x185d7bf28 start + 2236

Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x0000600003ebc340   x1: 0x0000000102f78040   x2: 0x0000000000000001   x3: 0x0000000000000000
    x4: 0x0000000185f8eab4   x5: 0x000000016cf2cc50   x6: 0x0000000000000100   x7: 0x000000016cf2cb38
    x8: 0x0000000000000000   x9: 0x00000000000003e8  x10: 0x00000000000000a1  x11: 0x00000001035bf9a0
   x12: 0x0000000000000000  x13: 0x0000000000000000  x14: 0x0000000000000018  x15: 0x0000000000000007
   x16: 0x0000000000000000  x17: 0x00000001e5c79778  x18: 0x0000000000000000  x19: 0x0000000103b102d0
   x20: 0x0000000146e9feb0  x21: 0x0000000102f78040  x22: 0x0000000103272860  x23: 0x0000000146e9feb0
   x24: 0x0000000000000001  x25: 0x0000000146e63194  x26: 0x0000000146e9fea8  x27: 0x0000000000000000
   x28: 0x000000014700c048   fp: 0x000000016cf2d1b0   lr: 0x000000010317fb00
    sp: 0x000000016cf2d120   pc: 0x0000000000000000 cpsr: 0x80001000
   far: 0x0000000000000000  esr: 0x82000006 (Instruction Abort) Translation fault

Binary Images:
       0x102ed0000 -        0x102ed3fff com.apple.python3 (3.9.6) <29942a18-9387-3bb5-9b60-b6110e4fd958> /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python
       0x1034b0000 -        0x10370bfff com.apple.python3 (3.9.6) <e104613b-0d1f-36cc-a3a0-46520949a2f4> /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/Python3
       0x1031a8000 -        0x1031affff _heapq.cpython-39-darwin.so (*) <48a5e2dd-b75b-3efe-a3aa-c27bcf032a1f> /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload/_heapq.cpython-39-darwin.so
       0x103178000 -        0x10318ffff _curses.cpython-39-darwin.so (*) <02f073ce-6284-39a7-ac9a-c91f641a555f> /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload/_curses.cpython-39-darwin.so
       0x103374000 -        0x10337bfff zlib.cpython-39-darwin.so (*) <4d29a0db-a622-3a99-ba37-86497fa3770a> /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload/zlib.cpython-39-darwin.so
       0x1033cc000 -        0x1033cffff _bz2.cpython-39-darwin.so (*) <0c018c06-c411-392e-b349-be27ac9df4b7> /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload/_bz2.cpython-39-darwin.so
       0x1033e0000 -        0x1033e7fff _lzma.cpython-39-darwin.so (*) <44d93e8c-1196-3ff5-8e58-0eb8e8474a46> /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload/_lzma.cpython-39-darwin.so
       0x1033f8000 -        0x1033fbfff grp.cpython-39-darwin.so (*) <dbf45a7d-d721-3f55-aaca-b870ef82e12a> /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload/grp.cpython-39-darwin.so
               0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
       0x185d76000 -        0x185e04587 dyld (*) <e7a99595-e0f8-34af-be8b-9347d0d658a4> /usr/lib/dyld

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=916.1M resident=0K(0%) swapped_out_or_unallocated=916.1M(100%)
Writable regions: Total=673.3M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=673.3M(100%)

                                VIRTUAL   REGION
REGION TYPE                        SIZE    COUNT (non-coalesced)
===========                     =======  =======
Kernel Alloc Once                   32K        1
MALLOC                           145.2M       12
MALLOC guard page                   96K        5
MALLOC_MEDIUM (reserved)         120.0M        1         reserved VM address space (unallocated)
MALLOC_NANO (reserved)           384.0M        1         reserved VM address space (unallocated)
STACK GUARD                         16K        1
Stack                             16.0M        1
VM_ALLOCATE                       7936K       31
__AUTH                             309K       59
__AUTH_CONST                      3714K      143
__DATA                            1934K      143
__DATA_CONST                      4238K      153
__DATA_DIRTY                       361K       58
__LINKEDIT                       802.6M        9
__OBJC_RO                         66.4M        1
__OBJC_RW                         2012K        1
__TEXT                           113.5M      159
dyld private memory                272K        1
shared memory                       32K        2
===========                     =======  =======
TOTAL                              1.6G      782
TOTAL, minus reserved VM space     1.1G      782

More Information.
Tried to build v5.0.4 and v5.1.1 - segfault in both versions

@radian997 Can you confirm if you have setup your IDF environment as it is mentioned in the getting started guide and have resolved all Apple M1 issues as per the guide?

Hi @sudeep-mohanty, I was following installation instructions step by step and it happened.

@radian997 From the logs you shared, it seems that you are using the system python instance to run the idf.py script. I suspect that your environment isn't properly setup. If you've setup your environment variables correctly then your idf.py script should execute from the python virtual environment created during the setup process and not use the system python.
An example of the environment -
~/esp/esp-idf  $ which python
/Users/sudeepmohanty/.espressif/python_env/idf5.2_py3.11_env/bin/python

~/esp/esp-idf  $ python --version
Python 3.11.4

I also tried with removing the #!/usr/bin/env python line from idf.py, and then:
/Users/adrian/.espressif/python_env/idf5.0_py3.9_env/bin/python ../../esp-idf/tools/idf.py menuconfig
but it also results with segfault

@radian997 Was it working for you before the upgrade to macOS 13.5.2?
I'm on 13.5.1, have tried to reproduce this with OS-provided copy of Python (also 3.9.6) and it seems to be working fine.
I'm also not sure this is an IDF issue and not a Python interpreter issue, since:
...
0   ???                           	               0x0 ???
1   Python3                       	       0x1034f91d0 0x1034b0000 + 299472
...
    sp: 0x000000016cf2d120   pc: 0x0000000000000000 cpsr: 0x80001000
   far: 0x0000000000000000  esr: 0x82000006 (Instruction Abort) Translation fault
...
       0x1034b0000 -        0x10370bfff com.apple.python3 (3.9.6) <e104613b-0d1f-36cc-a3a0-46520949a2f4> /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/Python3
...

Basically, something in Python3 library is jumping to a function pointer which is NULL. There don't seem to be any 3rd party modules (like curses) in the callstack, so seems like it is an interpreter issue?
Aside from the OS version being different, I don't know why it happens on your computer but not mine, though.

I started digging into the problem and investigated that it happens while make -j10 menuconfig is called. Exactly the cmake command from build.make file:
/opt/homebrew/Cellar/cmake/3.27.5/bin/cmake -E env COMPONENT_KCONFIGS_SOURCE_FILE=/Users/adrian/Workspace/esp32/esp32-cpp/projects/hello_world/build/kconfigs.in COMPONENT_KCONFIGS_PROJBUILD_SOURCE_FILE=/Users/adrian/Workspace/esp32/esp32-cpp/projects/hello_world/build/kconfigs_projbuild.in KCONFIG_CONFIG=/Users/adrian/Workspace/esp32/esp32-cpp/projects/hello_world/sdkconfig IDF_TARGET=esp32 IDF_ENV_FPGA= /Users/adrian/.espressif/python_env/idf5.0_py3.9_env/bin/python -m menuconfig /Users/adrian/Workspace/esp32/esp32-cpp/esp-idf/Kconfig
I tried with cmake 3.23.1 and 3.27.5 but it always ends with segfault.

Please try to install a different Python version (guide is here, using homebrew or macports).

@dobairoland Thank you, I installed python3 with homebrew and it started working. It's weird that it doesn't work with Python3 provided by command line tools.

source: gharchive/issue

authors: dobairoland igrr radian997 sudeep-mohanty

license_type: permissive

license_source: github-api


text:
Heap corruption in BT

Seen this twice already, happens when client is connecting to GATTS
[Dec  7 02:22:47.586] esp32_bt_gatts_ev    CONNECT cid 0 addr a4:5e:60:b8:65:14
[Dec  7 02:22:47.594] esp32_bt_gattc_ev    CONNECT cid 0 addr a4:5e:60:b8:65:14
[Dec  7 02:22:47.603] esp32_bt_gap_ev      ADV_START_COMPLETE st 0
[Dec  7 02:22:47.609] esp32_bt_gap_ev      BLE advertising started
[Dec  7 02:22:47.615] mgos_bt_dbg_svc_ev   MTU 23
[Dec  7 02:22:47.621] mg_rpc_add_channel_i 0x3ffda034 '' GATTS
[Dec  7 02:22:47.630] mg_rpc_ev_handler    0x3ffda034 CHAN OPEN (GATTS if 4 conn 0 peer a4:5e:60:b8:65:14)
[Dec  7 02:22:48.006] led_timer_cb         Tick uptime: 4164.64, RAM: 189868, 118364 free
[Dec  7 02:22:49.006] led_timer_cb         Tock uptime: 4165.64, RAM: 189856, 118340 free
[Dec  7 02:22:50.006] led_timer_cb         Tick uptime: 4166.64, RAM: 189860, 118344 free
[Dec  7 02:22:50.606] esp32_bt_gap_ev      UPDATE_CONN_PARAMS st 16 addr a4:5e:60:b8:65:14 int 48-80 lat 0 conn_int 78 tout 400
[Dec  7 02:22:51.006] led_timer_cb         Tock uptime: 4167.64, RAM: 189856, 118340 free
[Dec  7 02:22:51.580] E (4169575) BT: bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0008
[Dec  7 02:22:51.605] E (4169595) BT: p_conn is NULL in bta_gattc_wait4_service_change_ccc_cback
[Dec  7 02:22:51.605]
[Dec  7 02:22:51.605] CORRUPT HEAP: multi_heap.c:415 detected at 0x3ffda4f4
[Dec  7 02:22:51.605] abort() was called at PC 0x40089b4f on core 0
[Dec  7 02:22:51.605]
[Dec  7 02:22:51.605] Backtrace: 0x4008a30f 0x4008a40f 0x40089b4f 0x40089f21 0x40082029 0x40082489 0x4000bec7 0x401a240d 0x40174a51

backtrace:
(gdb) bt
#0  0x4008a30f in invoke_abort ()
    at /opt/Espressif/esp-idf/components/esp32/./panic.c:139
#1  0x4008a412 in abort ()
    at /opt/Espressif/esp-idf/components/esp32/./panic.c:148
#2  0x40089b52 in multi_heap_assert (condition=false, line=415,
    address=1073587444,
    format=0x3ffc27c5 "CORRUPT HEAP: multi_heap.c:%d detected at 0x%08x\n")
    at /opt/Espressif/esp-idf/components/heap/./multi_heap_platform.h:55
#3  0x40089f24 in multi_heap_free_impl (heap=0x3ffd8508, p=0x3ffda4f8)
    at /opt/Espressif/esp-idf/components/heap/./multi_heap.c:415
#4  0x4008202c in heap_caps_free (ptr=<optimized out>)
    at /opt/Espressif/esp-idf/components/heap/./heap_caps.c:275
#5  0x4008248c in _free_r (r=0x3ffb6e4c, ptr=0x3ffda4f8)
    at /opt/Espressif/esp-idf/components/newlib/./syscalls.c:42
#6  0x4000beca in free ()
#7  0x401a2410 in bta_gattc_wait4_service_change_ccc_cback (

@rojer We have fix this bug now, please update the IDF version, thanks.

ok, thanks!

authors: Yulong-espressif rojer


text:
archive with submodules isn't published (IDFGH-13230)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
Yesterday's mail with the 5.3-rc1 announcement includes a paragraph saying you can download a complete archive, as usually.
It's now 23 hours later and the archive still isn't there.
Download an archive with submodules included

Attached to this release is an esp-idf-v5.3-rc1.zip archive. It includes .git directory and all the submodules, so can be used out of the box. This archive is provided for users who have connectivity issues preventing them from cloning from GitHub.

This archive can also be downloaded from Espressif's download server: https://dl.espressif.com/github_assets/espressif/esp-idf/releases/download/v5.3-rc1/esp-idf-v5.3-rc1.zip

Thanks for reporting, and sorry for the inconvenience, the issue has been fixed. Thanks.


text:
[TW#27054] esp_http_client issue - Wrong content length set

Environment

Development Kit:      [ESP32-DevKitC]
Kit version (DevKitC): [v3]
Core (if using chip or module): [ESP32-Wrover|ESP-WROOM32|ESP32]
IDF version : 11b444b

Problem Description
esp_http_client_open() API should set "Content-Length" header to the passed size. But the content-length header is either not set or it is set to 0.
I am trying to send a file from esp32 as attachment to a server. Here is the same code for the same.
Code to reproduce this issue
FILE *f = fopen(filename, "r");
   if (f == NULL) {
      ESP_LOGE(TAG, "Failed to open file for sending");
      return -1;
   }

   esp_http_client_handle_t client = esp_http_client_init(&config);

   esp_http_client_set_header(client, "User-Agent", "abc-Node");
   esp_http_client_set_header(client, "Content-Disposition", "attachment; filename=chip.log");
   esp_http_client_set_url(client, url);
   esp_http_client_set_method(client, HTTP_METHOD_POST);

   esp_err_t err;
   if ((err = esp_http_client_open(client, size)) != ESP_OK) {
      ESP_LOGE(TAG, "Failed to open HTTP connection: %s", esp_err_to_name(err));
      free(buffer);
      return -1;
   }

   bzero(buffer, MAX_HTTP_RECV_BUFFER);
   printf("Total size : %d\n", size);

   while ((ret = fread(&buffer[0], sizeof(char), MAX_HTTP_RECV_BUFFER, f)) > 0) {
      esp_http_client_write(client, buffer, ret);
      bzero(buffer, MAX_HTTP_RECV_BUFFER);
   }
   int content_length =  esp_http_client_fetch_headers(client);
   int total_read_len = 0, read_len;
   if (total_read_len < content_length && content_length <= MAX_HTTP_RECV_BUFFER) {
      read_len = esp_http_client_read(client, buffer, content_length);
      if (read_len <= 0) {
         ESP_LOGE(TAG, "Error read data");
      }
      buffer[read_len] = 0;
      ESP_LOGI(TAG, "read_len = %d", read_len);
   }
   ESP_LOGI(TAG, "HTTP Status = %d, content_length = %d",
                       esp_http_client_get_status_code(client),
                       esp_http_client_get_content_length(client));
   esp_http_client_close(client);
   esp_http_client_cleanup(client);
   free(buffer);
   fclose(f);

Debug Logs from server
{
	"CONTENT_LENGTH": "0",
	"SERVER_PROTOCOL": "HTTP/1.1",
	"REQUEST_METHOD": "POST",
	"PATH_INFO": "/logs/api/submit",
	"REMOTE_ADDR": "192.168.2.61",
	"CONTENT_TYPE": "text/plain",
	"HTTP_USER_AGENT": "abc-Node",
	"HTTP_HOST": "192.168.2.16",
	"HTTP_CONTENT_DISPOSITION": "attachment; filename=chip.log",
}

You are right, the value is not used at all.  It should do
client->post_len=write_len;
https://github.com/espressif/esp-idf/blob/3977d4b56555289f828a4d5f5d756b7b69783d53/components/esp_http_client/esp_http_client.c#L1085-L1095

Fixed with https://github.com/espressif/esp-idf/commit/2e3f06ece8bffeda95ab9546d4356ed4d4b72ca8, closing.

authors: AadiMehta mahavirj negativekelvin


text:
mbedtls allocated in spiram issue

I am trying to work with new menuconfig->mbedTLS option to allocate from spiram, but i am having problems.
I have free in spiram:
Heap summary for capabilities 0x00000400:
  At 0x3f800000 len 4194303 free 4071380 allocated 122880 min_free 4071380
    largest_free_block 4071380 alloc_blocks 1 free_blocks 1 total_blocks 2
  Totals:
    free 4071380 allocated 122880 min_free 4071380 largest_free_block 4071380

but mbedTLS cant create new connection even if certificate is verified:
E (64702) esp-tls: mbedtls_ssl_handshake returned -0x7780
I (64702) esp-tls: Certificate verified.
E (64711) esp-tls: Failed to open new connection
E (64711) TRANS_SSL: Failed to open a new connection
E (64716) HTTP_CLIENT: Connection failed, sock < 0
E (64722) HTTP_CLIENT: HTTP POST request failed: ESP_ERR_HTTP_CONNECT

This is heap summary internal and spiram memory usage with spiram config Make RAM allocatable using heap_caps_malloc:
Heap summary for capabilities 0x00000800:
  At 0x3ffae6e0 len 6432 free 0 allocated 6284 min_free 0
    largest_free_block 0 alloc_blocks 29 free_blocks 0 total_blocks 29
  At 0x3ffb9d30 len 156368 free 3568 allocated 151912 min_free 0
    largest_free_block 3420 alloc_blocks 210 free_blocks 4 total_blocks 214
  At 0x3ffe0440 len 15296 free 7316 allocated 7844 min_free 5084
    largest_free_block 7260 alloc_blocks 24 free_blocks 2 total_blocks 26
  At 0x3ffe4350 len 113840 free 113804 allocated 0 min_free 113804
    largest_free_block 113804 alloc_blocks 0 free_blocks 1 total_blocks 1
  At 0x40096ca4 len 37724 free 37688 allocated 0 min_free 37680
    largest_free_block 37688 alloc_blocks 0 free_blocks 1 total_blocks 1
  Totals:
    free 162376 allocated 166040 min_free 156568 largest_free_block 113804
Heap summary for capabilities 0x00000400:
  At 0x3f800000 len 4194303 free 4071380 allocated 122880 min_free 4071380
    largest_free_block 4071380 alloc_blocks 1 free_blocks 1 total_blocks 2
  Totals:
    free 4071380 allocated 122880 min_free 4071380 largest_free_block 4071380  //<--- memory allocated by my app only

This is heap summary internal and spiram memory usage with spiram config Make RAM allocatable using malloc() as well:
Heap summary for capabilities 0x00000800:
  At 0x3ffbd32c len 67999 free 61292 allocated 6596 min_free 61292
    largest_free_block 61292 alloc_blocks 18 free_blocks 1 total_blocks 19
  At 0x3ffae6e0 len 6432 free 0 allocated 6276 min_free 0
    largest_free_block 0 alloc_blocks 31 free_blocks 0 total_blocks 31
  At 0x3ffb9d88 len 156280 free 2980 allocated 152672 min_free 0
    largest_free_block 1996 alloc_blocks 145 free_blocks 4 total_blocks 149
  At 0x3ffe0440 len 15296 free 0 allocated 15228 min_free 0
    largest_free_block 0 alloc_blocks 9 free_blocks 0 total_blocks 9
  At 0x3ffe4350 len 113840 free 59664 allocated 53868 min_free 54044
    largest_free_block 59608 alloc_blocks 67 free_blocks 2 total_blocks 69
  At 0x40096dc4 len 37436 free 37400 allocated 0 min_free 37392
    largest_free_block 37400 alloc_blocks 0 free_blocks 1 total_blocks 1
  Totals:
    free 161336 allocated 234640 min_free 152728 largest_free_block 61292
Heap summary for capabilities 0x00000400:
  At 0x3f800000 len 4194303 free 4071380 allocated 122880 min_free 4071380
    largest_free_block 4071380 alloc_blocks 1 free_blocks 1 total_blocks 2
  Totals:
    free 4071380 allocated 122880 min_free 4071380 largest_free_block 4071380 //<--- memory allocated by my app only

All works fine with option allocation strategy -->internal memory.
This is heap summary with mbedTLS internal memory allocation strategy (normal usage):
Heap summary for capabilities 0x00000800:
  At 0x3ffbd32c len 32767 free 26060 allocated 6596 min_free 26060
    largest_free_block 26060 alloc_blocks 18 free_blocks 1 total_blocks 19
  At 0x3ffae6e0 len 6432 free 0 allocated 6276 min_free 0
    largest_free_block 0 alloc_blocks 31 free_blocks 0 total_blocks 31
  At 0x3ffb9d88 len 156280 free 3060 allocated 152560 min_free 0
    largest_free_block 1956 alloc_blocks 149 free_blocks 8 total_blocks 157
  At 0x3ffe0440 len 15296 free 16 allocated 15144 min_free 0
    largest_free_block 16 alloc_blocks 25 free_blocks 1 total_blocks 26
  At 0x3ffe4350 len 113840 free 94892 allocated 18716 min_free 87620
    largest_free_block 94832 alloc_blocks 47 free_blocks 3 total_blocks 50
  At 0x40096dc4 len 37436 free 37400 allocated 0 min_free 37392
    largest_free_block 37400 alloc_blocks 0 free_blocks 1 total_blocks 1
  Totals:
    free 161428 allocated 199292 min_free 151072 largest_free_block 94832  // <--- more free RAM because only 32kB reserved for DMA, in first log no DMA reserved (no option), 2nd example about 64kB reserved
Heap summary for capabilities 0x00000400:
  At 0x3f800000 len 4194303 free 4071380 allocated 122880 min_free 4071380
    largest_free_block 4071380 alloc_blocks 1 free_blocks 1 total_blocks 2
  Totals:
    free 4071380 allocated 122880 min_free 4071380 largest_free_block 4071380

@chegewara Is it possible for you to provide minimal application with sdkconfig that reliably reproduces this issue?

@mahavirj With sdkconfig there is no issue, i can provide copy of mine. There is problem with code, i am working on commercial app and app is connecting to amazon servers. I have to think how to do it.
sdkconfig (just one not working version):
https://gist.github.com/chegewara/a98ed02e54b8b5ecf204fea79b46645d

@mahavirj I think it may have something to do with this issue
https://github.com/espressif/esp-idf/issues/2228#issuecomment-408112657
when i am using option like @igrr is suggesting i cant make big allocations with calloc in spiram i have to use instead heap_caps_calloc instead with MALLOC_CAP_SPIRAM. If i use calloc (malloc probably too) then allocation is in internal memory.

Did you try disabling hw encryption

@mahavirj I think it may have something to do with this issue
#2228 (comment)
when i am using option like @igrr is suggesting i cant make big allocations with calloc in spiram i have to use instead heap_caps_calloc instead with MALLOC_CAP_SPIRAM. If i use calloc (malloc probably too) then allocation is in internal memory.

That will also depend on config option SPIRAM_MALLOC_ALWAYSINTERNAL which has default value of 16384, essentially means all allocations less than that size will happen from internal memory.
Also for mbedTLS we are using heap_caps_calloc API itself, please refer at https://github.com/espressif/esp-idf/blob/bd90f534fb1cdf7d4406767f9067398d51a12305/components/mbedtls/port/esp_mem.c#L21
I suspect something else happening because of error mbedtls_ssl_handshake returned -0x7780 from your log, let me once you can get something that can reproduce this issue.

@mahavirj I think it may have something to do with this issue
#2228 (comment)
when i am using option like @igrr is suggesting i cant make big allocations with calloc in spiram i have to use instead heap_caps_calloc instead with MALLOC_CAP_SPIRAM. If i use calloc (malloc probably too) then allocation is in internal memory.

That will also depend on config option SPIRAM_MALLOC_ALWAYSINTERNAL which has default value of 16384, essentially means all allocations less than that size will happen from internal memory.

I meant really big allocations, like 100-200kB.

Also for mbedTLS we are using heap_caps_calloc API itself, please refer at
esp-idf/components/mbedtls/port/esp_mem.c
Line 21 in bd90f53
IRAM_ATTR void *esp_mbedtls_mem_calloc(size_t n, size_t size)
I suspect something else happening because of error mbedtls_ssl_handshake returned -0x7780 from your log, let me know once you can get something that can reproduce this issue.

I will try to see whats going on here. Thanks.

Did you try disabling hw encryption

Disabling hw encryption leads to many errors like this one, but thanks for suggestion:
/esp-idf/components/esp32/hwcrypto/aes.c:434:5: error: conflicting types for 'esp_aes_xts_setkey_enc'
 int esp_aes_xts_setkey_enc( mbedtls_aes_xts_context *ctx,

@chegewara

Disabling hw encryption leads to many errors like this one, but thanks for suggestion:

Thanks for reporting this, it's a bug in the current master branch. Will fix.

Thanks, will reopen if encounter any issues.

authors: chegewara mahavirj negativekelvin projectgus


text:
I2C not working in 'Release' configuration

When building in Debug configuration, I2C communication is working.
When building in Release configuration, communication gets stuck before it really starts.
This is what the bus looks like at the first communication after reset (Debug config):

This is what the bus looks like at the first communication try after reset (Release config):

Close look at where data is supposed to start:

In error case, i2c_master_cmd_begin() does not return (with time set to portMAX_DELAY) or returns ESP_ERR_TIMEOUT for any smaller value for ticks_.
This is my initialialization.
First I reconfigure GPIO32 + 33 for general use:
i2c_config_t stI2cConfig;
REG_CLR_BIT(RTC_IO_XTAL_32K_PAD_REG, RTC_IO_X32P_MUX_SEL);
REG_CLR_BIT(RTC_IO_XTAL_32K_PAD_REG, RTC_IO_X32N_MUX_SEL);
stI2cConfig.mode = I2C_MODE_MASTER;
stI2cConfig.sda_io_num = GPIO_NUM_33;
stI2cConfig.sda_pullup_en = GPIO_PULLUP_ENABLE;
stI2cConfig.scl_io_num = GPIO_NUM_32;
stI2cConfig.scl_pullup_en = GPIO_PULLUP_ENABLE;
stI2cConfig.master.clk_speed = 400000;
i2c_param_config(I2C_NUM_0, &stI2cConfig);
i2c_set_data_mode(I2C_NUM_0, I2C_DATA_MODE_MSB_FIRST, I2C_DATA_MODE_MSB_FIRST);
i2c_driver_install(I2C_NUM_0, stI2cConfig.mode, 0, 0, 0);
This is how I access the bus:
// I2C access: write register, then read value
// Read register 1: W[0x68] [0x01] R[0x68] [0x00 = Value]
i2c_cmd_handle_t i2cHandle = i2c_cmd_link_create();
i2c_master_start(i2cHandle);
i2c_master_write_byte(i2cHandle, (I2C_ADDRESS << 1), true);
i2c_master_write_byte(i2cHandle, (uint8_t)enRegister, true);
i2c_master_write_byte(i2cHandle, (I2C_ADDRESS << 1) | 0x01, true);
i2c_master_read_byte(i2cHandle, pu8Value, 1);
esp_err_t result = i2c_master_cmd_begin(I2C_NUM_0, i2cHandle, portMAX_DELAY);
i2c_cmd_link_delete(i2cHandle);
return (result == ESP_OK);
I tried to stick with the I2C example as much as possible.
Any hints or reproduction are very welcome - thanks.

I took time to try the esp-idf/examples/peripherals/i2c example, which behaves the same.
I don't have an actual BH1750 sensor, so I set up the example as suggested in the README.md file (by connecting the ESP32's master & slave ports GPIO18<-->GPIO25 and GPIO19<-->GPIO26), and started a run in "debug" configuration, which looks good.
Then I set menuconfig to "release", make clean && make -j8 flash, and the master I2C peripheral is struggeling.
I tried this procedure with two separate ESP-WROOM-32 modules each on a Watterott ESP-WROOM-32-BREAKOUT board.
i2c_example_debug.txt
i2c_example_release.txt

I just spent a good part of the day trying to make an I2C LCD display work and only now found this bug report. Recompiling in DEBUG mode indeed helped and my display now works as expected.
Using esp-idf git b8e2edc99f36 and gcc-5.2.0 [xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-59-g8d95cad) 5.2.0] compiling on ARM [Raspbian GNU/Linux 8 (jessie)]

I will take this issue : )

Could you please explain me how to compile the code whether in DEBUG or RELEASE mode in case of ESP32 code?Thanks!

Right, configure through menuconfig.

I am trying to work with I2C EEPROM (FM24C64) and I can confirm that RELEASE configuration doesn't work at all and I2C bus is stuck on the beginning of any activity.
But, also DEBUG configuration not works so good and after some I2C activity I start getting ERR_TIMEOUT errors from i2c_master_cmd_begin command .
Do you have any idea how to solve this for now?

@bobik78  im also with same issue (i2c matster EEPROM Selective (Random) Read problem #422)

Thanks Santhosh!
On Wed, Mar 15, 2017 at 10:27 PM, santhosh kumar notifications@github.com
wrote:

@bobik78 https://github.com/bobik78 im also with same issue (i2c
matster EEPROM Selective (Random) Read problem #422
https://github.com/espressif/esp-idf/issues/422)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/304#issuecomment-286714700,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AM1DCtTxWLYtgt2L5ILJw_nCfOJGuG3Yks5rl8s3gaJpZM4Luxsl
.

--
Kind Regards,
Firmware Engineer
LIFX

we should thank to @nkolban for that.

I think this one can fix the issue. Try to merge into idk ASAP.
driver/i2c.c
static void IRAM_ATTR i2c_master_cmd_begin_static(i2c_port_t i2c_num)
{
       ......
        if (cmd->op_code == I2C_CMD_WRITE) {
            uint32_t wr_filled = 0;
            //TODO: to reduce interrupt number
            if (cmd->data) {
                while (p_i2c->tx_fifo_remain > 0 && cmd->byte_num > 0) {
                    WRITE_PERI_REG(I2C_DATA_APB_REG(i2c_num), *cmd->data++);
                    p_i2c->tx_fifo_remain--;
                    cmd->byte_num--;
                    wr_filled++;
                }
            } else {
                WRITE_PERI_REG(I2C_DATA_APB_REG(i2c_num), cmd->byte_cmd);
                p_i2c->tx_fifo_remain--;
                cmd->byte_num--;
                wr_filled ++;
            }
            //Workaround for register field operation.
            I2C[i2c_num]->command[p_i2c->cmd_idx].byte_num = wr_filled;
            .......

What is this ??  This is for what ?
On Sun, 19 Mar 2017 at 1:26 PM, costaud notifications@github.com wrote:

I think this one can fix the issue. Try to merge into idk ASAP.
driver/i2c.c
static void IRAM_ATTR i2c_master_cmd_begin_static(i2c_port_t i2c_num)
{
......
if (cmd->op_code == I2C_CMD_WRITE) {
uint32_t wr_filled = 0;
//TODO: to reduce interrupt number
if (cmd->data) {
while (p_i2c->tx_fifo_remain > 0 && cmd->byte_num > 0) {
WRITE_PERI_REG(I2C_DATA_APB_REG(i2c_num), *cmd->data++);
p_i2c->tx_fifo_remain--;
cmd->byte_num--;
wr_filled++;
}
} else {
WRITE_PERI_REG(I2C_DATA_APB_REG(i2c_num), cmd->byte_cmd);
p_i2c->tx_fifo_remain--;
cmd->byte_num--;
wr_filled ++;
}
//Workaround for register field operation.
I2C[i2c_num]->command[p_i2c->cmd_idx].byte_num = wr_filled;
.......
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/304#issuecomment-287600827,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVHlPSsaZWbiQMfgj65lMy9-u8Qqmf0Gks5rnN-wgaJpZM4Luxsl
.

--
Regards,
Santhosh Kumar
EmTantra
2nd floor, nisarga Chamber,MG Road
Mangaluru - 575003 , KA.
09108798051.

Works fine for me - thanks everyone!


text:
localhost:3333 (IDFGH-4213)

----------------------------- Delete below -----------------------------
Reminder: If your issue is a general question, starts similar to "How do I..", or is related to 3rd party development kits/libs, please discuss this on our community forum at https://esp32.com instead.
INSTRUCTIONS
Before submitting a new issue, please follow the checklist and try to find the answer.

[ ] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[ ] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[ ] I have searched the issue tracker for a similar issue and not found a similar issue.

If the issue cannot be solved after the steps before, please follow these instructions so we can get the needed information to help you in a quick and effective fashion.

Fill in all the fields under Environment marked with [ ] by picking the correct option for you in each case and deleting the others.
Describe your problem.
Include debug logs from the "monitor" tool, or coredumps.
Providing as much information as possible under Other items if possible will help us locate and fix the problem.
Use Markdown (see formatting buttons above) and the Preview tab to check what the issue will look like.
Delete these instructions from the above to the below marker lines before submitting this issue.

IMPORTANT: If you do not follow these instructions and provide the necessary details, your issue may not be resolved.
----------------------------- Delete above -----------------------------
Environment

Development Kit:      [ESP32-Wrover-Kit|ESP32-DevKitC|ESP32-PICO-Kit|ESP32-LyraT|ESP32-LyraTD-MSC|none]
Kit version (for WroverKit/PicoKit/DevKitC): [v1|v2|v3|v4]
Module or chip used:  [ESP32-WROOM-32|ESP32-WROOM-32D|ESP32-WROOM-32U|ESP32-WROVER|ESP32-WROVER-I|ESP32-WROVER-B|ESP32-WROVER-IB|ESP32-SOLO-1|ESP32-PICO-D4|ESP32]
IDF version (run git describe --tags to find it):
// v3.2-dev-1148-g96cd3b75c
Build System:         [Make|CMake|idf.py]
Compiler version (run xtensa-esp32-elf-gcc --version to find it):
// 1.22.0-80-g6c4433a
Operating System:     [Windows|Linux|macOS]
(Windows only) environment type: [MSYS2 mingw32|ESP Command Prompt|Plain Command Prompt|PowerShell].
Using an IDE?: [No|Yes (please give details)]
Power Supply:         [USB|external 5V|external 3.3V|Battery]

Problem Description
//Detailed problem description goes here.
Expected Behavior
Actual Behavior
Steps to reproduce

step1
...

// If possible, attach a picture of your setup/wiring here.
Code to reproduce this issue
// the code should be wrapped in the ```cpp tag so that it will be displayed better.
#include "esp_log.h"

void app_main()
{

}

// If your code is longer than 30 lines, GIST is preferred.
Debug Logs
Debug log goes here, should contain the backtrace, as well as the reset source if it is a crash.
Please copy the plain text here for us to search the error log. Or attach the complete logs but leave the main part here if the log is *too* long.

Other items if possible

[ ] sdkconfig file (attach the sdkconfig file from your project folder)
[ ] elf file in the build folder (note this may contain all the code details and symbols of your project.)
[ ] coredump (This provides stacks of tasks.)

Thanks for reporting. Would you please help provide more details as suggested in the issue template? Information like elf, sdk configuration, backtrace, log outputs, commit ID, hardware and etc. would help us debug further. Thanks.

Thanks for reporting, will close due to no issue details provided as per the issue template, feel free to reopen with more details. Thanks.


text:
[TW#13326] SSL_use_certificate and SSL_use_PrivateKey not in openssl/ssl.h

In order to use client certs with openssl, you needs these two functions, but they are not in openssl/ssl.h.  The SSL_CTX version of these calls are in ssl.h, but I have no idea what you would use them for.
The work around is to simply add
int SSL_use_PrivateKey(SSL *ssl, EVP_PKEY *pkey);
int SSL_use_certificate(SSL *ssl, X509 *x);
to you code, and you can use these functions.

You may can user following API instead of those with transforming data to specific data object:
int SSL_use_PrivateKey_ASN1(int type, SSL *ssl, const unsigned char *d, long len);
int SSL_use_certificate_ASN1(SSL *ssl, int len, const unsigned char *d);

Hi @kevinkessler , did the above suggestion help you resolve the issue?

authors: FayeY donghengqaz kevinkessler


text:
Allow custom user agent

Make a configurable parameter for esp_http_client which allows setting the user agent string for Http requests.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 23 committers have signed the CLA.:white_check_mark: suda-morris:white_check_mark: strikosn:x: lly:x: Isl2017:x: gerekon:x: projectgus:x: jack0c:x: igrr:x: kapilkedawat:x: boblane1:x: zhangyanjiaoesp:x: david-cermak:x: dobairoland:x: scottsh:x: xiongyumail:x: KonstantinKondrashov:x: WCCWCC:x: ginkgm:x: GYC-Espressif:x: 0xjakob:x: blueMoodBHD:x: ESP-Marius:x: krzychblly seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

source: gharchive/pull-request

authors: CLAassistant scottsh


text:
Fix deep sleep bug if RTS source is set as 8MD256 (IDFGH-6430)

My issue about a problem: https://github.com/espressif/esp-idf/issues/8007
I firured out two problem on deep sleep:

ESP32 doesn't wake up if RTC source is set as 8MD256. It occurs due these changes:  https://github.com/espressif/esp-idf/commit/73384adfbe3a4365fb8fefdae9b1f9df4e509635
ESP32 has bad console if it wake up after deep sleep:

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks for your contribution.

Please, can we get this crippling issue resolved. Updated ESP-IDF version to Release/4.4 from ESP-IDF 4.3.2 to enable us to use the ESP32-S3.
However after the change deep sleep not activated by Touch Pad #9, nor will it wake from Timer wakeup, for both the the ESP32, and the ESP32-S3, when the RTC clock source set to: Internal 8MHz oscillator, divided by 256 (~32kHz).
CONFIG_ESP32S3_TIME_SYSCALL_USE_RTC_FRC1=y
# CONFIG_ESP32S3_TIME_SYSCALL_USE_RTC is not set
# CONFIG_ESP32S3_TIME_SYSCALL_USE_FRC1 is not set
# CONFIG_ESP32S3_TIME_SYSCALL_USE_NONE is not set
# CONFIG_ESP32S3_RTC_CLK_SRC_INT_RC is not set
# CONFIG_ESP32S3_RTC_CLK_SRC_EXT_CRYS is not set
# CONFIG_ESP32S3_RTC_CLK_SRC_EXT_OSC is not set
CONFIG_ESP32S3_RTC_CLK_SRC_INT_8MD256=y
CONFIG_ESP32S3_RTC_CLK_CAL_CYCLES=1024
CONFIG_ESP32S3_DEEP_SLEEP_WAKEUP_DELAY=2000

Please @boris92git could you consider signing the CLA, however the fix only appears for the ESP32.

Thanks for your contribution.

@Alvin1Zhang
Can someone pick up this fix?

There are two fixes together fix this issue. The first one has been merged to master: cc37f63e14af5a04ce016244cef496c860987a0c (waiting to be synced).
The backport and the second part is on the way. Thanks for reporting and patience.

authors: Alvin1Zhang AxelLin CLAassistant boris92git ginkgm wreyford


text:
BLE:Error writing Characteristics in Chip service on the device when commissioning (CON-770)

Hello
Installed latest ESP-IDF and matter framework as of today on macOS 13.5.2.
Compiling and flashing the light example works fine..and I can connect via serial port to the ESP32_Devkitc_v4 board.
Either through the iOS Espressif app or chiptool I can't commission the device at all, resulting in the same error outputs:
[1694778139060] [22643:294475] [TOO] Command: pairing ble-wifi 0x7283 mySSID myPassword 20202021 3840
[1694778139062] [22643:294477] [CTL] Setting attestation nonce to random value
[1694778139062] [22643:294477] [CTL] Setting CSR nonce to random value
[1694778139065] [22643:294477] [CTL] Generating NOC
[1694778139068] [22643:294477] [FP] Validating NOC chain
[1694778139076] [22643:294477] [FP] NOC chain validation successful
[1694778139076] [22643:294477] [FP] Updated fabric at index: 0x1, Node ID: 0x000000000001B669
[1694778139076] [22643:294477] [TS] Last Known Good Time: 2023-09-15T10:49:58
[1694778139076] [22643:294477] [TS] New proposed Last Known Good Time: 2021-01-01T00:00:00
[1694778139076] [22643:294477] [TS] Retaining current Last Known Good Time
[1694778139078] [22643:294477] [FP] Metadata for Fabric 0x1 persisted to storage.
[1694778139079] [22643:294477] [TS] Committing Last Known Good Time to storage: 2023-09-15T10:49:58
[1694778139080] [22643:294477] [CTL] Joined the fabric at index 1. Fabric ID is 0x0000000000000001 (Compressed Fabric ID: E702B60C0D26E86E)
[1694778139080] [22643:294477] [DIS] Updating services using commissioning mode 0
[1694778139087] [22643:294477] [BLE] NewConnection
[1694778139087] [22643:294477] [CTL] Setting wifi credentials from parameters
[1694778139087] [22643:294477] [CTL] Setting attestation nonce to random value
[1694778139087] [22643:294477] [CTL] Setting CSR nonce to random value
[1694778139087] [22643:294477] [CTL] Commission called for node ID 0x0000000000007283
[1694778139119] [22643:294477] [BLE] CBManagerState: ON
[1694778139154] [22643:294477] [BLE] Connecting to device 0x600003bf81a0 with discriminator: 3840
[1694778140020] [22643:294478] [DIS] Closing all BLE connections
[1694778140020] [22643:294478] [IN] BleConnectionComplete: endPoint 0x102bedf58
[1694778140020] [22643:294478] [BLE] ATT MTU = 256
[1694778140021] [22643:294477] [BLE] BLE:Error writing Characteristics in Chip service on the device: [The specified UUID is not allowed for this operation.]
[1694778140022] [22643:294478] [IN] SecureSession[0x600003cf4200]: Allocated Type:1 LSID:42770
[1694778140022] [22643:294478] [SC] Assigned local session key ID 42770
[1694778140022] [22643:294478] [EM] <<< [E:469i S:0 M:26728876] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:20 (SecureChannel:PBKDFParamRequest)
[1694778140022] [22643:294478] [IN] (U) Sending msg 26728876 to IP address 'BLE'
[1694778140022] [22643:294478] [IN] Message appended to BLE send queue
[1694778140022] [22643:294478] [SC] Sent PBKDF param request
[1694778140022] [22643:294478] [IN] Failed to establish BLE connection: src/platform/Darwin/BleConnectionDelegateImpl.mm:478: Ble Error 0x00000407: GATT write characteristic operation failed
[1694778140022] [22643:294478] [IN] Clearing BLE pending packets.
[1694778140022] [22643:294478] [BLE] Auto-closing end point's BLE connection.
[1694778157024] [22643:294480] [SC] PASESession timed out while waiting for a response from the peer. Expected message type was 33
[1694778157024] [22643:294480] [IN] SecureSession[0x600003cf4200]: Released - Type:1 LSID:42770
[1694778157024] [22643:294480] [TOO] Secure Pairing Failed
[1694778157024] [22643:294480] [TOO] Run command failure: examples/chip-tool/commands/pairing/PairingCommand.cpp:315: CHIP Error 0x00000003: Incorrect state
[1694778157024] [22643:294480] [DIS] Closing all BLE connections
[1694778157024] [22643:294480] [TOO] Pairing Failure: src/protocols/secure_channel/PASESession.cpp:255: CHIP Error 0x00000032: Timeout
[1694778157024] [22643:294480] [TOO] Run command failure: src/protocols/secure_channel/PASESession.cpp:255: CHIP Error 0x00000032: Timeout
>>>

Any hints?

Please take a look at Using chip-tool on macOS, or CHIP Tool on iOS

Yepp...that was it..thanks (o;
Now if there were only examples for sensors (o;

authors: richardklingler shubhamdp

repo: espressif/esp-matter


text:
esp-RFID - Roger

Hello.
I wanna use w rfid reader of roger: prt12em-bk-g
How program them, to work with esprfid?

i try with wiegand 26, and any pf the X
but nothing have to work.
I connect d0 and D1 just to nodemcu.
it should be connect via volatage converter ??
Any help?

In most cases, the esp8266 can tolerate 5V wiegand signal.

In most cases, the esp8266 can tolerate 5V wiegand signal.

Does nodemcu can provide the 3v or 5v inside of GPIO?

It's 3v3 logic.
On Mon, Jan 6, 2020 at 4:59 PM marceltech notifications@github.com wrote:

In most cases, the esp8266 can tolerate 5V wiegand signal.
Does nodemcu can provide the 3v or 5v inside of GPIO?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/esprfid/esp-rfid/issues/349?email_source=notifications&email_token=AAFJ55VLPCFNZFGBAL62CN3Q4NIODA5CNFSM4KCSKQV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIF373A#issuecomment-571195372,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFJ55UZ2NTKWGXPKVAMM6DQ4NIODANCNFSM4KCSKQVQ
.

authors: kambiumdt marceltech nardev

repo: esprfid/esp-rfid

license: MIT


text:
[LCARS] Bugfixes and other improvements

The alarm control (of the sched lib) was broken after the last update. It is fixed now. Also Bangle.getHealthStatus("day").steps is used as fallback if no widget is installed. I still use the steps of widgets to ensure that the behavior does not change with this update.

Thanks!

authors: gfwilliams peerdavid

repo: espruino/BangleApps


text:
openhaystack: store battery status in FindMy packet

This allows a user to know their device's battery, as well as its location
See also:
https://github.com/seemoo-lab/openhaystack/issues/185
https://github.com/MatthewKuKanich/FindMyFlipper/blob/e5a678e33dd17af46bb63050be4c9d10e17f6252/FindMyFlipper/findmy_state.c#L126-L137
@olivierbarriere let me know what you think - I'll be testing this over the next week or so

This looks cool. I'd be fine with merging it anyway.
Interestingly it's nice to have a way to send some data back. For instance if you had a remote letterbox or something it could report battery level as full if there was something in it, or nearly empty if there wasn't.

Yes that would be very cool to repurpose the 4 values as another form of communication - or it'd be interesting to see if "invalid" battery values made it through the network too.
I've had this running but my watch hasn't appeared on the network in a while, so can't confirm yet

authors: bobrippling gfwilliams


text:
Issue with image pull secret in .dockercfg format instead of .dockerconfigjson format

All the image pull secret we use in our cluster are of type .dockercfg so when using k8s-image-swapper, it's not using the image pull secret.
Is there anyway to also use .dockercfg image pull secret type?
Thank you

Hi @JonathanLachapelle ,
Revisiting reported issues. Is. this still something you're having issues with?

Hi, yes it is still something we are facing issue with.

authors: JonathanLachapelle estahn


text:
CSS in JS aka JavaScript styles

https://github.com/rofrischmann/fela is the winner. It's panacea.
We need extract useful pattern from http://jxnblk.com/axs. I bet jxnblk will do something ;-)

I think what ecosystem needs right now is a common meaningful naming and themes. Please discuss.

@steida what do you mean by meaningful naming?

I mean common UI vocabulary like https://github.com/este/este/tree/master/src/browser/app/components.

https://palx.jxnblk.com/f3c

I think a good start would be implementing react-native counterparts for the web.

@Cavitt I want to build a minimal set of components. I think ecosystem needs jsstyled project for common styling, only objects, no concrete implementation. I would love to replace Este with create-react-app, but it's not possible I guess. Let's see.

Ok, after playing with Fela... hmm, devil is in details. Considering styled-components again since there is nothing more popular.

authors: Cavitt steida

repo: este/este

license: mit

license_source: bigquery


text:
add este/localstorage component

Based on https://gist.github.com/steida/5790593364dd8bf55928

redux-storage is better


text:
Revérifier les wordings des questions et du message d'accueil

Certaines questions sont tournées avec une question d'intro et des questions dans les réponses, d'autres ne sont pas adaptée au mode de réponse (ex des formes interrogatives pour les cases à cocher). À voir pour l'harmonisation général (à force de les lire on ne les lit même plus vraiment :) ).

Fait dans https://github.com/etalab/covid19-orientation/pull/27

authors: bzg judbd


text:
Modernise Python packaging

Implement https://peps.python.org/pep-0621/ with https://flit.readthedocs.io/
Add https://pre-commit.com/ to run code formatting/linting, and apply https://black.readthedocs.io, https://pycqa.github.io/isort/ and https://github.com/charliermarsh/ruff

I wasn't too sure what is the best choice for packaging and I went for poetry, do you think flit is a better option?

flit is the simplest option essentially, and maintained by the guys at pip, I like it and use it for all my packages. the problem with poetry is that it does not support PEP 621 (https://github.com/python-poetry/roadmap/issues/3) and is bit overcomplicated for my liking
There is also https://github.com/pypa/hatch, but yeh its not the end of the world either way
Definitely adding the pre-commit would be great.
Also adding mypy checking and type annotations would be very helpful also, particularly the return of API calls using https://docs.python.org/3/library/typing.html#typing.TypedDict, as I started to do in #10
and yeh for the CLI, the main thing is that there is one 😅
FYI, what triggered this is that I was mocking up how it would look like to use pyfirecrest with aiida: https://github.com/chrisjsewell/pyfirecrest/blob/aiida_mock/firecrest/mock_calc.py
Especially getting it to all work with asyncio 😄

I have a made a release today with what I have for now but we will try to add your suggestions from your PRs

yeh no worries, actually I would strongly recommend moving away from poetry and using one of the python standard packaging tools: https://github.com/pypa/flit, https://github.com/pypa/hatch or https://github.com/pdm-project/pdm/
I was playing around with the new release, and poetry makes the developer experience pretty horrible
Also, did you mean to leave the setup.py and requirements.txt files in the repo; these can be removed now no?

repo: eth-cscs/pyfirecrest


text:
[WIP] Carthage support

Added targets and shared schemes so that Carthage compiles on other platforms that iOS

[x] added macOS target
[x] added watchOS target
[x] added tvOS target

fixes #3

all platforms now compile
carthage build
*** Building scheme "CupertinoJWT iOS" in CupertinoJWT.xcodeproj
*** Building scheme "CupertinoJWT macOS" in CupertinoJWT.xcodeproj
*** Building scheme "CupertinoJWT watchOS" in CupertinoJWT.xcodeproj
*** Building scheme "CupertinoJWT tvOS" in CupertinoJWT.xcodeproj

Thanks. I've verify on an example app and it works well.


text:
Sprint 1 Checklist

Self Grading Checklist
All self and by peer grading must be complete prior to Teacher review date(s).  Show a direct link to the tangible(s) for each line item.
Sprint1 Key Objectives
During the sprint you need to complete all of these key objectives and find and complete supporting hacks that show level of command you are declaring.
Rank to Ratio, rank is an integer
0 = .00 work, but faking understanding/accomplishment
1 = .55 incomplete assignment, big gaps
2 = .75 meeting some objectives, multiple little gaps
3 = .85 meeting most objectives, one little gap
4 = .90 meeting all objectives
4+Mastered-Y = .95 exceeding all objectives, requires links and  office hours verification

Skill
Mastered (Y/N)
Rank (1-4)
Ratio
Notes

Laptop Verification or Cloud Workspace
[ ]
0
0.0
verification by Linux commands notebook

VSCode
[ ]
0
0.0
live change code, commit, make, run localhost, test, debug

Show VSCode GitLens
[ ]
0
0.0
verify commits, show change, comments, reset to commit, run on old commit

GitHub student_2025 repo
[ ]
0
0.0
template create, push changes, verify id, review analytics

GitHub Pages Actions
[ ]
0
0.0
review runs and verify runtime, receive demo

Hacks Tools & Equipment Play
[ ]
0
0.0
Hacks

Hacks GitHub Pages Playground
[ ]
0
0.0
Hacks

Hacks SASS Basics
[ ]
0
0.0
Hacks

Hacks Frontend
[ ]
0
0.0
Hacks

Pair Programming
[ ]
0
0.0
tangibles that show coop work

Total

0.0

Average

0.0

Learning Habits Table
Review criteria in habits.  In this review, pairs should rate each other base on their experience with the person on the line item.
Rank to Ratio, rank is an integer
1 = .55
2 = .75
3 = .85
4 = .90
4+Mastered-Y = .95

Skill
Mastered (Y/N)
Rank (1-4)
Ratio
Notes

Attendance
[ ]
0
0.0

Work Habits
[ ]
0
0.0

Behavior
[ ]
0
0.0

Timeliness
[ ]
0
0.0

Tech Sense
[ ]
0
0.0

Tech Talk
[ ]
0
0.0

Tech Growth
[ ]
0
0.0

Advocacy
[ ]
0
0.0

Comm & Collab
[ ]
0
0.0

Integrity
[ ]
0
0.0

Organized
[ ]
0
0.0

Total

0.0

Average

0.0

ls: This command lists out all the files and directories within that directory
pwd: This command shows the name of the directory you are currently in
mkdir: This command is used to create a new directory
cd: This command allows you to change what directory you want to be in
git:
cat:

VsCode

Show VsCode GitLens

GitHub student_2025 repo

GitHub Pages Actions

Hacks Tools & Equipment Play

Hacks Frontend

4
Y

SASS Hacks

Skill
Mastered (Y/N)
Rank (1-4)
Ratio
Notes

Attendance
[ ]
0
0.0

Work Habits
[ ]
0
0.0

Behavior
[ ]
0
0.0

Timeliness
[ ]
0
0.0

Tech Sense
[ ]
0
0.0

Tech Talk
[ ]
0
0.0

Tech Growth
[ ]
0
0.0

Advocacy
[ ]
0
0.0

Comm & Collab
[ ]
0
0.0

Integrity
[ ]
0
0.0

Organized
[ ]
0
0.0

Total

0.0

Average

0.0

0.91

had some cool extra features
score would be higher but pair communication needs to be better


text:
how to add the converted net code to training in tensorflow

i converte the net with convert.py. But when i add the code to the tutorial mnist full_connected_feed.py in the tensorflow, modify the input of LeNet is tensor shape[100,28,28,1] instead of [100, 784], it occurs error:dim not equal.

The solution is that modify the code tf.reshape(images, shape=[-1, 28, 28 1]) and the images_placeholder is [100, 784].

`from mynet import LeNet as MyNet
image = tf.placeholder(tf.float32, [1, 784])
labels = tf.placeholder(tf.float32, [1, 10])
input = tf.reshape(image, shape=[-1, 28, 28, 1])
net = MyNet({'data': input})
#the follow is test code for MNIST
with tf.Session() as sess:
sess.run(tf.initialize_all_variables())
net.load('../mynet.npy', sess)
batch_xs, batch_ys = mnist.train.next_batch(1)
output = sess.run(net.get_output(), feed_dict={image: batch_xs})`

repo: ethereon/caffe-tensorflow


text:
Create core

#225 #224 #199 #105 #223

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

repo: ethereum-oasis-op/baseline-standard


text:
Clarify and improve superchain registry semver validations

Originally from https://github.com/ethereum-optimism/superchain-registry/pull/248#discussion_r1606791275:

@mds1: I still don't (and never fully did) understand the difference between this and semver.yaml.  In this notion doc we recently defined a mapping from op-contracts/vX.Y.Z release to the expected semvers for each contract. Ultimately, the verification we should be doing in the superchain registry is making sure a chain's contracts is on one of those op-contracts tags, as determined by the semvers (and bytecode validation, since a contract can lie about its semver).
So what exactly is supposed to be in each of these files that lists contract versions, in relation to the linked version definitions?

@geoknee: Thanks for raising this, I have also never really understood the role of this file. I think resolving this is very important, but somewhat outside the scope of this PR so if possible would prefer not to block on it.
The document you linked is very clear and I would be happy to overhaul the validation checks and declaration files have in the registry to match it.
Proposal:

semver.yaml -> standard-contract-versions.toml (or some better name), with now encodes the mapping from monorepo tags to a list of (contract,version) pairs as described in your doc. Lives next to the standard config toml files in the validation module, we no longer export that information from superchain.
validation check ensures each chain has a set of contract versions which exactly match 1:1 to at least one monorepo tag mapping entry in the above file. From what I can tell this can be just a dumb string equality check, since the versions are not true semantic versions and we won't do any true semantic version comparisons.
bytecode validation is something which is not yet in scope for the superchain registry checks but we are looking at pulling that in to scope.

The "implementations" yaml files are currently not referenced by any validation check in this repo. They are referenced in one place in  op-chain-ops https://github.com/ethereum-optimism/optimism/blob/69bb36c9ba95705cc730d1e145501a510c448775/op-chain-ops/cmd/op-upgrade/main.go#L226-L246 . You might be better placed than me to suggest how we tidy that up, I would be infavour of reducing complexity if at all possible.

cc @tynes who might have insight into the original intent which would be useful for informing how to best clean this up

Sorry @pegahcarter I put that link on before this issue was migrated to being public. If you're interested in the direction of travel on this issue, please check out this draft PR https://github.com/ethereum-optimism/superchain-registry/pull/297 .

repo: ethereum-optimism/superchain-registry


text:
Regenerated genesis bug

Discoverd in this pr, we found that the regenerated genesis contains storage allocations that have zero as the value field. This causes the genesis allocs test to fail because op-deployer doesn't do this, nor should it.

I'm a bit confused by this change. AFAICT this is not a bug in the validation code, but possibly a bug in the genesis creation code itself. Seems weird to "fix" it here -- wouldn't this risk a valid genesis allocs (valid by our working definition, that it was generated using standard tooling invocations at a specified commit in the monorepo) failing validation (because it would have the the zeros which are now removed from the expectation).

The key point is that for slots that are not set in genesis, the default storage value is zero. So two genesis files, where one omits zero valued slots and one explicitly sets them, are equivalent.
Therefore I think the ideal fix is for the superchain registry to normalize both the provided genesis and the generated genesis, by removing all slots where the value being set in storage is zero. This way it doesn't matter whether or not the provided and generated genesis files have these no-op keys being set, since both versions are equivalent
In op-deployer, we do this same normalization when generating genesis. But you are right that this diff might cause genesis files generated by other scripts that don't normalize to fail. So we could extend this PR to normalize both genesis files to be more robust

Should we remove empty storage slots in the version of the genesis file that gets stored in the repo? Might save us some bytes

authors: bitwiseguy blmalone geoknee mds1


text:
Support type checking for contract Enums

Would be awesome to have type checking on enums. Currently, I have to re-define all enums in typescript and keep those in sync so this would make things that much cleaner!

It's not possible right now because ABI doesn't contain any enum information. Related: https://github.com/ethereum/EIPs/issues/47
I am gonna close this for now as it's not actionable.

repo: ethereum-ts/TypeChain


text:
Support gRPC and protobuf for specs

gRPC should also be added as a supported RPC standard
protobuf should be allowed as an optional specification standard if gRPC is added.
there are clients already doing both.

I think clients can offer additional transports, and even use this as a differentiating factor to garner usage, but I agree we should not officially support anything outside one canonical definition that everyone agrees with. The alternative suggests we have effectively have two specs and I don't think there is enough bandwidth to maintain this long-term.

authors: ralexstokes sambacha

repo: ethereum/execution-apis


text:
Add support for pragma statement

What was wrong?
How was it fixed?
To-Do

[ ] OPTIONAL: Update Spec if applicable

[ ] Add entry to the release notes (may forgo for trivial changes)

[ ] Clean up commit history

More use cases for this:
`#![forbid(dynamic)] // disallow any code that prevents gas analysis

#[target(evm)]
fn deploy() -> Foo:
  return Foo::create2(1, 2)

#[target(ewasm)]
fn deploy() -> Foo:
  ...

Sorry, I realize this discussion should have happened before you started implementing this. We can always change the syntax later, the important part is that we have the compiler version lock functionality.

You are raising good points here. But as you say, we have enough time to change the syntax at a later point in time. My immediate focus is to make sure we support rejecting code that was written to be compiled with a different compiler version so I just followed soliditys pragma <version-requirement> syntax (where <version-requirement> is any semver range syntax that is also valid on Cargo.toml files).

Codecov Report

Merging #426 (5ae3f88) into master (1760025) will decrease coverage by 0.03%.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##           master     #426      +/-   ##
==========================================
- Coverage   86.64%   86.60%   -0.04%
==========================================
  Files          68       68
  Lines        4147     4182      +35
==========================================
+ Hits         3593     3622      +29
- Misses        554      560       +6

Impacted Files
Coverage Δ

analyzer/src/errors.rs
62.50% <0.00%> (-2.32%)
:arrow_down:

parser/src/lexer/token.rs
21.73% <0.00%> (-0.24%)
:arrow_down:

parser/src/parser.rs
74.07% <ø> (ø)

parser/src/grammar/module.rs
80.72% <90.00%> (+5.25%)
:arrow_up:

analyzer/src/traversal/module.rs
100.00% <100.00%> (ø)

compiler/src/lowering/mappers/module.rs
91.30% <100.00%> (+0.39%)
:arrow_up:

compiler/src/yul/mappers/module.rs
78.57% <100.00%> (ø)

Continue to review full report at Codecov.

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

It'd probably be good to have an analyzer error test of the version mismatch case.

Good point, added!

authors: cburgdorf codecov-commenter sbillig

repo: ethereum/fe


text:
Build warp sync based state sync as a plugin

What is wrong?
One of the most challenging problems for all of the existing Ethereum 1 client implementations today is how to keep the state sync fast.
The reason for that is not so much the pure size of the state (currently ~9GB) but rather the number of trie nodes which is somewhere above 200 million. As far as I understand there are various reasons why syncing these is hard:

The networking protocol that is being used does only allow up to n (need to lookup)  trie nodes to be fetched per request

Client nodes that aren't archive nodes prune past state after n bocks which means there is only a limited amount of time until it becomes very hard to find the trie nodes on the network.

How can it be fixed
A while back parity introduces warp sync sync to speed up the entire syncing process.  For the sake of simplicity, I'll focus on how to use warp sync to just sync the state and why this would not compromise security.
Warp sync works by taking a snapshot of the entire chain + state every 5000 blocks and making that available to other peers through an extension of the existing wire protocol.
The snapshot is divided into a snapshot manifest and the actual snapshot data. All of that is RLP encoded data.
Manifest
[
    version: P, // snapshot format version. Must be set to 2.
    state_hashes: [hash_1: B_32, hash_2: B_32, ...], // a list of all the state chunks in this snapshot
    block_hashes: [hash_1: B_32, hash_2: B_32, ...], // a list of all the block chunks in this snapshot
    state_root: B_32, // the root which the rebuilt state trie should have. used to ensure validity
    block_number: P, // the number of the best block in the snapshot; the one which the state coordinates to.
    block_hash: B_32, // the best block in the snapshot's hash.
]

As we can see, the manifest contains the state_root as well as state_hashes for state chunks of 4 MB.
What we can do is to request the state for a given state_root by fetching these 4 MB chunks and then ensuring integrity by recomputing the state_root from the entire state once we've fetched all pieces.
In terms of security this would be pretty identical to the existing state sync and the worst thing that could happen is that we can only fully ensure the integrity once we've finished downloading the entire state.
Or to say cite @AlexeyAkhunov on the topic

Warp sync is pretty much equivalent to fast sync in terms of trust required. What you do when you warp sync, is downloading these (7Gb?) data, then compute Patricia Merkle tree over this, and check that the state root is the same as in the block header. Done. With the fast sync (current geth's method), you build the state trie from the nodes you receive over the network, and in the end you are also sure that you have the state matching the state root in the block header. The main difference is that when you warp sync, you have to download ALL 7Gb before you are sure you are actually downloading the state, and not some random data, wheres with the fast sync, you pretty much know that you are downloading correct stuff as you do it. If the fast sync peer sends you rubbish, you will realise very quickly without having to download gigabytes

I'm not proposing to make this the default state sync strategy (as it is non-standard for the time being) but I think this could be useful as a plugin to give a user an alternative option for a fast(er) state sync.

There is a way of combining advantages of warp sync and fast sync. The rough idea is this. First, you flatten the state as list of pairs (account;account_data) sorted by the hash of the account address (this is how it appears in the Patricia tree). Then, you chunk it up, lets say, in 4Mb each chunk. Each chunk will contain pairs that stand next to each other in the patricia tree. What you add to the chunk is a proof that this chunk is indeed part of the state with the given root. Once you have got all the account, you repeat this procedure for the contract storage. For contracts with small storage, you don't bother making proofs, but just package them into chunks. But for contracts with the large storage, you use the same technique described above.
I almost have a code for this in Turbo-Geth! :) Perhaps I shall try to code it up and give it a go!

Each chunk will contain pairs that stand next to each other in the patricia tree. What you add to the chunk is a proof that this chunk is indeed part of the state with the given root.

Am I write to assume that in order to verify the chunks I need to have them in order? So, if I fetch lots of chunks in parallel, and I have gaps, then I need to fill out the gaps before I can verify those because the proofs do not work individually but only in conjunction with the neighbor. Or am I totally off with that?

I almost have a code for this in Turbo-Geth! :) Perhaps I shall try to code it up and give it a go!

Sounds very exciting! :+1:
But, since this would be a totally new syncing scheme, there are no nodes to seed this.
Where my initial intend was to create a state sync that can benefit from the existing parity nodes that provide warp sync chunks, this would be something entirely new that needs to be adopted (or am I misinterpreting this?)
But if your proposed scheme does indeed work and improve the speed of the state sync, I guess it would be worth drafting an EIP for that :)

Am I write to assume that in order to verify the chunks I need to have them in order? So, if I fetch lots of chunks in parallel, and I have gaps, then I need to fill out the gaps before I can verify those because the proofs do not work individually but only in conjunction with the neighbor. Or am I totally off with that?

No, chunks can be delivered in any order, because each of them have a proof

this would be something entirely new that needs to be adopted

Yes, correct, but if this format turns out to be superior to both others, we can get it adopted reasonably quickly.

But if your proposed scheme does indeed work and improve the speed of the state sync, I guess it would be worth drafting an EIP for that :)

Ok, lets do a quick PoC and then EIP

No, chunks can be delivered in any order, because each of them have a proof

Oh ok. Good to hear!

First, you flatten the state as list of pairs (account;account_data) sorted by the hash of the account address (this is how it appears in the Patricia tree)

Can you elaborate on that for me? Am I right to assume the ordering is to ensure that all clients produce chunks in the same deterministic manner? Because otherwise every client ends up producing different, incompatible chunks.

Ok, lets do a quick PoC and then EIP

Exciting! :+1:

Here is a little doc I have put together: https://github.com/ledgerwatch/eth_state/blob/master/sync/Hybrid_Sync.pdf

authors: AlexeyAkhunov cburgdorf

repo: ethereum/py-evm


text:
Re-organize networking code for Trinity

What is wrong?
Currently, all of the networking code lives under evm.p2p.  The long term plan is to split the core DevP2P components from this code into a separate library (probably the existing devp2p python library).  To prepare for this, we should start drawing firmer lines between the different sections of code that currently live in this repository.

Py-EVM code: deals specifically with the EVM
DevP2P code: deals with the generic DevP2P protocol
Trinity code: deals with running an Ethereum node over the DevP2P protocol using the py-evm EVM.

How can it be fixed
Perform the following code re-organization.  This should be done in multiple steps to keep the pull requests smaller.

Everything from evm.p2p to a new root level module devp2p
Move everything from the new devp2p module which is not strictly DevP2P protocol code to trinity.p2p
Find any imports in either of these sections of code which import from evm.utils.* and change them to use their own local utilities, or migrate the utility to eth-utils so it can be shared.

@gsalgado I also think that means we move most of the work you're currently doing over to the trinity branch (or maybe better, go ahead and merge trinity into master and just build from that common base.

When you say DevP2P I guess you mean the base-protocol (https://github.com/ethereum/wiki/wiki/ÐΞVp2p-Wire-Protocol) plus anything related to discovery and sub-protocols as well? If so, I'd prefer to call the new root-level subpackage just p2p.
Also, I think in trinity it'd make more sense to have separate, meaningfully named subpackages for the individual p2p services (e.g. trinity.lightchain, trinity.sync, etc), but it might make sense to start with everything under trinity.p2p

I'd prefer to call the new root-level subpackage just p2p

👍

Also, I think in trinity it'd make more sense to have separate, meaningfully named subpackages

👍
Once we get #379 merged would you like to do that re-org?

authors: gsalgado pipermerriam


text:
Drop py3.5 support, support py3.8, fix lint test

What was wrong?
fix #96
Also, drop py3.5 support (breaking change, requires major version bump, of course!)
How was it fixed?
Update tox, circle-ci etc.
~While doing that, notice that the lint tests were probably broken.~ Hm, nope, the lint tests were working befdore! It's a mystery to me why, I really thought that tox's testenv didn't support partial matches. In fact, it came up pretty recently in another project and the lint test was getting skipped, which I thought was because of a partial-match issue...
Also, had to upgrade hypothesis to work with py3.8. This meant that warnings about long tests turned into errors, so some tests had to be made shorter and/or the deadline extended.
Cute Animal Picture

Any reason you chose not to run the linter across the different python versions? Otherwise

Well at first I thought that lint wasn't running at all because of the [testenv:lint] definition, which does not trigger in the environment py36-lint for example. This was a problem in https://github.com/ethereum/eth-keys/pull/72 which definitely was not running lint tests before. So I was surprised to find out that py-trie was running lint tests despite this partial match problem.
After some digging, I found: .circleci was running the lint environment instead of py36-lint:
https://github.com/ethereum/py-trie/blob/3be564633ac9ff5f2f3ad5d9b23a42658ef41c6b/.circleci/config.yml#L47-L58
Which means that lots of confusing things were happening:

a local run of tox -e py36-lint would give you a different result than the circleCI job py36-lint (which was really just tox -e lint but in a py36 container)
there were a bunch of listed environments in tox that were never run in CI
the only thing forcing the correct python was in the circleCI config instead of the tox one

So...
I think the right answer is to just stick with the project template standard and only run one linter:
https://github.com/ethereum/ethereum-python-project-template/blob/e38d2349dd9941ac38cae5ab0402a912092fce2d/tox.ini#L4
If the linter itself is giving different results for the same version of flake8 but different versions of python, then I think we can just recognize that as a bug in flake8. That reduces our CI time & noise. I don't think we get much benefit from re-checking lint in a bunch of different pythons.

repo: ethereum/py-trie


text:
More secp256k1 issues.

Checklist

[x] installed pyethapp inside a virtualenv

System/environment

OS: Lubuntu 16.10 (Also Xubuntu 16.04.1)
python version: 2.7.12+
pyethapp version: 1.5.0
installation method (pip & pypi/git & setup.py): pip & git & setup.py
pyethapp branch (if applicable): N/A

Expected behaviour
For pyethapp to... run.
Observed behaviour
(.venv) gijon@gijon:~/ethereum/pyethapp$ pyethapp
Traceback (most recent call last):
File "/home/gijon/ethereum/pyethapp/.venv/bin/pyethapp", line 6, in
from pkg_resources import load_entry_point
File "/home/gijon/ethereum/pyethapp/.venv/local/lib/python2.7/site-packages/pkg_resources/init.py", line 2927, in
@_call_aside
File "/home/gijon/ethereum/pyethapp/.venv/local/lib/python2.7/site-packages/pkg_resources/init.py", line 2913, in _call_aside
f(*args, **kwargs)
File "/home/gijon/ethereum/pyethapp/.venv/local/lib/python2.7/site-packages/pkg_resources/init.py", line 2940, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/home/gijon/ethereum/pyethapp/.venv/local/lib/python2.7/site-packages/pkg_resources/init.py", line 637, in _build_master
return cls._build_from_requirements(requires)
File "/home/gijon/ethereum/pyethapp/.venv/local/lib/python2.7/site-packages/pkg_resources/init.py", line 650, in _build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/home/gijon/ethereum/pyethapp/.venv/local/lib/python2.7/site-packages/pkg_resources/init.py", line 829, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'secp256k1==0.12.1' distribution was not found and is required by devp2p
Steps to reproduce
Followed https://github.com/ethereum/pyethapp/wiki/Getting-Started
With the additon of having to preinstall:
build-essential
libssl-dev
python-pip (not preinstalled with preinstalled py2.7.12)
pkg-config
git
Additional Information
Probably related to https://github.com/ethereum/pyethapp/issues/171
I believe related to issues with secp256k1 getting updated to 0.13.2 in the wild. In a previous attempt I tried to manually install version 0.12.1 via pip install secp256k1==0.12.1 but encountered errors in doing so.
Started over with full sanitized VM.
My pip list...
(.venv) gijon@gijon:~/ethereum/pyethapp$ pip list
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
backports.shutil-get-terminal-size (1.0.0)
bitcoin (1.1.42)
cffi (1.8.3)
click (6.6)
CodernityDB (0.5.0)
coverage (4.2)
decorator (4.0.10)
devp2p (0.8.0)
docutils (0.12)
enum34 (1.1.6)
ethereum (1.6.0)
gevent (1.1.0)
gipc (0.4.0)
greenlet (0.4.10)
ipaddress (1.0.17)
ipython (4.2.1)
ipython-genutils (0.1.0)
leveldb (0.194)
lmdb (0.92)
pathlib2 (2.1.0)
pbkdf2 (1.3)
pexpect (4.2.1)
pickleshare (0.7.4)
pip (9.0.1)
pkg-resources (0.0.0)
pluggy (0.4.0)
ptyprocess (0.5.1)
py (1.4.31)
pycparser (2.17)
pycryptodome (3.4.3)
pyelliptic (1.5.7)
pyethapp (1.5.0, /home/gijon/ethereum/pyethapp)
pyethash (0.1.27)
pysha3 (0.3)
PyYAML (3.12)
repoze.lru (0.6)
requests (2.11.1)
rlp (0.4.6)
scrypt (0.8.0)
secp256k1 (0.13.2)
setuptools (28.8.0)
simplegeneric (0.8.1)
six (1.10.0)
statistics (1.0.3.5)
tinyrpc (0.5)
tox (2.4.1)
traitlets (4.3.1)
virtualenv (15.0.3)
Werkzeug (0.11.11)
wheel (0.30.0a0)
(.venv) gijon@gijon:~/ethereum/pyethapp$

Same problem here. I believe the issue is with the dependency coming from devp2p: pkg_resources.ContextualVersionConflict: (secp256k1 0.13.2 (/Users/alexmiller/eth/python/pyethapp/.venv/lib/python2.7/site-packages), Requirement.parse('secp256k1==0.12.1'), set(['devp2p']))
Not possible to manually install 0.12.1.

There is an open PR for devp2p that would resolve this: https://github.com/ethereum/pydevp2p/pull/53

repo: ethereum/pyethapp


text:
usage on windows

Hey fellows,
I am trying to debug the code
on windows , and have some
problems including leveldb
package, Tried to Google it , no good
alternatives for windows.
Can you suggest me
some king of solution here ?
Thanks in advance.

There is a project to compile leveldb using VC
https://github.com/happynear/py-leveldb-windows
Here there is a similar issue
https://github.com/willyd/caffe-builder/issues/12
Cheers

Also found a fairly recent cmake/win patch here:
https://github.com/google/leveldb/issues/475
Not a visual studio user so someone else will have to test it out.

As of #777 our secp256k1 dep works on Windows.
Perhaps we could replace LevelDB with LMDB https://pypi.python.org/pypi/lmdb

authors: ofek pckilgore romanman vfdev-5

repo: ethereum/pyethereum


text:
Remove non-existing solc argument

Without this change pyethereum will no longer work with solidity >= 0.4.21
Solidity issue: https://github.com/ethereum/solidity/issues/3695

@joeykrug ping. (Just because I saw that you merged the latest PRs)

Looks good, thanks!

authors: LefterisJP joeykrug


text:
Threading concurrency problem: dictionary changed during iteration

What is wrong?
This crashed one of my nodes.
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     raise MultiError(
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/env/lib/python3.8/site-packages/async_service/base.py", line 324, in _run_and_manage_task
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     await task.run()
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/env/lib/python3.8/site-packages/async_service/base.py", line 169, in run
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     await self.child_manager.run()
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/env/lib/python3.8/site-packages/async_service/asyncio.py", line 255, in run
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     raise MultiError(
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/env/lib/python3.8/site-packages/async_service/base.py", line 324, in _run_and_manage_task
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     await task.run()
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/env/lib/python3.8/site-packages/async_service/base.py", line 169, in run
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     await self.child_manager.run()
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/env/lib/python3.8/site-packages/async_service/asyncio.py", line 255, in run
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     raise MultiError(
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/env/lib/python3.8/site-packages/async_service/base.py", line 324, in _run_and_manage_task
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     await task.run()
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/env/lib/python3.8/site-packages/async_service/asyncio.py", line 35, in run
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     await self._async_fn(*self._async_fn_args)
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/env/lib/python3.8/site-packages/trinity/sync/beam/state.py", line 567, in _match_predictive_node_requests_to_peers
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     await self._wakeup_preview_waiters(existing_hashes)
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/env/lib/python3.8/site-packages/trinity/sync/beam/state.py", line 671, in _wakeup_preview_waiters
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     preview_waiters = await asyncio.get_event_loop().run_in_executor(
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/.pyenv/versions/3.8.5/lib/python3.8/concurrent/futures/thread.py", line 57, in run
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     result = self.fn(*self.args, **self.kwargs)
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:   File "/root/env/lib/python3.8/site-packages/trinity/sync/beam/state.py", line 684, in _get_preview_waiters
Sep 30 11:22:33 localhost launch-trinity.sh[10995]:     waiters = tuple(self._preview_events.items())
Sep 30 11:22:33 localhost launch-trinity.sh[10995]: RuntimeError: dictionary changed size during iteration

How can it be fixed
Looks like we need some concurrency protectins/mitigation now that we're running more things in threads.

Hit this one again today.

repo: ethereum/trinity


text:
Create 221020-algos.tweet

I think we should use this format instead of #108

Making a change resets the review but it does not prevent the editor from re-reviewing. I'll let the editor or someone else merge.


text:
Release: v0.1

Goal: this release aims to provide a stable EVM for frontier block range.

[ ] #172
[ ] Finalize documentations, fix missing ones.
[ ] Create release branch release/v0.1

Remove unstable features: HOMESTEAD_PATCH, EIP150_PATCH, EIP160_PATCH.

Due to #175, @sjmackenzie has un-cooperately released v0.1 without going through any ordinary release process. This makes me think that there are some serious issues going on with this repo. So right now, all regression testing process is migrated to https://github.com/ethereumproject/esvm

Due to recent incidents, we're going to skip v0.1 and directly release v0.2.

The release is being handled in the release/v0.2 branch. Note that we're still fixing the documentation before the actual release.

Released https://github.com/ethereumproject/sputnikvm/releases/tag/v0.2.0

repo: ethereumproject/sputnikvm


text:
eprint.iacr.org is slowing down crawl

Need to set fetcher.max.crawl.delay to something like 5 seconds. eprint.iacr.org's robots.txt is imposing a 20 second delay between successive fetches (my default is 1 second).
https://eprint.iacr.org/robots.txt
Here is the log output demonstrating the issue:
FetcherThread 104 fetching https://eprint.iacr.org/2019/1111 (queue crawl delay=20000ms)
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=48, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=49, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=49, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=49, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=49, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=48, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=50, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1
-activeThreads=50, spinWaiting=45, fetchQueues.totalSize=4, fetchQueues.getQueueCount=1

fixed with 1fffae361224c632d6b0b935fc27d0f082c26e98

repo: ethsearch/ethsearch-backend


text:
Doesn't support GeneralizedTime format on V0.3.* and V0.4.*?

I am using python3.5 and pyasn1 library for parse the X509 certficate. I found a issue is the pyasn1 V0.3.* and V0.4.* doesn't support GeneralizedTime format. I can read the valid date when roll back to V0.2.3.

Thank you for reporting this!
Could I have a simple reproducer to understand the issue?

Thank you for quick response. I am using the Atmel AWS IoT Zero Touch python script to parse a certficate. The certificate notBefore is DATEFMT_RFC5280_UTC format. If I set notAfter to over 3000 years in certficate, the notAfter will be DATEFMT_RFC5280_GEN format. I got an error stack as follwing when I using this script:
https://github.com/MicrochipTech/aws-iot-zero-touch-secure-provisioning-kit/blob/802e506bdec57bb21d6c055f7c7818104cbae018/cert2certdef.py#L269
python3 cert2certdef.py --device-cert device.crt
Traceback (most recent call last):
File "cert2certdef.py", line 658, in
main()
File "cert2certdef.py", line 44, in main
print(gen_cert_def_c_device(cert_der))
File "cert2certdef.py", line 129, in gen_cert_def_c_device
not_after  = set_time_params(params, cert, 'notAfter')
File "cert2certdef.py", line 199, in set_time_params
info = cert_time_offset_length(cert, name)
File "cert2certdef.py", line 269, in cert_time_offset_length
time_str = str(cert_mod['tbsCertificate']['validity'][name][idx])
File "/usr/local/lib/python3.5/dist-packages/pyasn1/type/char.py", line 88, in str
return str(self._value)
File "/usr/local/lib/python3.5/dist-packages/pyasn1/type/base.py", line 164, in plug
raise error.PyAsn1Error('Uninitialized ASN.1 value ("%s" attribute looked up)' % name)
pyasn1.error.PyAsn1Error: Uninitialized ASN.1 value ("str" attribute looked up)

Which pyasn1 version you are using?
My guess is that the actual problem is here. When you check for field value presence, starting from pyasn1 0.2.3, you should use the .hasValue() method instead (or along with) the None comparison:
if not cert_mod['tbsCertificate']['validity'][name][idx].hasValue():

BTW, even then the code seems shaky because once you increment idx you do not run any value presence check on the idx+1 field.

authors: KingjZhang etingof


text:
Files in symlinked folder not found on mirror

For historical reasons we have some symlinked folders, like "2016 -> 33c3".
Files in the symlinked location are reported as "not present on any mirror" and served by our fallbacks.

https://cdn.media.ccc.de/congress/2016/h264-hd/33c3-7811-deu-Irren_ist_staatlich.mp4?mirrorlist
https://cdn.media.ccc.de/congress/33c3/h264-hd/33c3-7811-deu-Irren_ist_staatlich.mp4?mirrorlist

Indeed, this should be supported. I don't know what is required to make it work but I'll see what I can do.

Please test the latest master and report back if it works as expected.
Note: I've also added a new configuration field for the Google Maps API key, see here.

Thanks, looks great!

authors: etix manno

repo: etix/mirrorbits


text:
[BUG] Error loading traffic_2008_hourly internal dataset

🐛 Bug Report
load_dataset for traffic_2008 doesn't work in internal_datasets branch.
Expected behavior
It should work.
How To Reproduce
Script:
from etna.datasets import load_dataset
ts = load_dataset("traffic_2008_hourly", rebuild_dataset=True)

Error:
ValueError: Length of values (63504) does not match length of index (144)

Environment
No response
Additional context
No response
Checklist

[X] Bug appears at the latest library version

Closed by https://github.com/etna-team/etna/pull/128.

repo: etna-team/etna


text:
add relational functions

This closes https://github.com/eto-ai/rikai/issues/488
This PR implemented a RelativeBox2d class with minimal function to help users use relative coordinate.
Concerns to not add a field to Box2d:

Fields in Box2d would be serialized to long-term storage. Currently, it has four fields, a 25% volume increment for this function might not be efficient.

Concerns to not implement a fully functional RelativeBox2d:

If we implement all the corresponding methods in Box2d for RelativeBox2d, the logic would be very complex especially when we consider the interaction between Box2d and RelativeBox2d, like Box2d.iou(RelativeBox2d), and UDT related kinds of stuff.
Here we use Box2d as a first-class citizen and give convenient methods to help users convert relative coordinate to it with less pain.

Some notes from our weekly meeting:

We do need to choose a first-class citizen someday, but maybe it's too early to make the decision, so we delay it to later.

repo: eto-ai/rikai


text:
🛑 cr1.prod (IPv4, 5060/TCP) is down

In c937a79, cr1.prod (IPv4, 5060/TCP) (cr1.prod.ettelabs.com) was down:

HTTP code: 0
Response time: 0 ms

pending v0.3.20 deploy

repo: ettelabsinc/ette-uptimejs


text:
[VH] Typo in rule logic parameter name (in ExternalParameters)

Describe the bug
The ExternalParameters class has the attribute issueCountryCode (without r) instead of issuerCountryCode
https://github.com/eu-digital-green-certificates/dgc-certlogic-ios/blob/14bcdce4ed19e151a9a3df1ea253db9a6238eeb7/Sources/CertLogic/ExternalParameter.swift
Expected behaviour
The typo is fixed to align the parameter with the specification
Steps to reproduce the issue
see code
Technical details
n/a
Possible Fix
fix the typo
Additional context
n/a

@mlenkeit fixed in #30

LGTM, thanks for the fix 👍

authors: alexchornyi mlenkeit